Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-sfc-nsh-10.txt Reviewer: Acee Lindem Review Date: 4 January 2014 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: I have some major concerns with the things that are missing from the document that need to be resolved before the document is progressed. I also belive the document could be vastly improved through resolution of the list minor isses. Comments: Refer to other sections. Major Issues: 1) The NSH MD Type 1 has 16 octets of Mandatory context headers but the contents of these headers are not specified anywhere in the document. 2) The example figures in section 8 are of no value since there is no explanation of the various icons and flows. Additionally, the deviate somewhat from the description of service function graphs in section 2.1 of RFC 7665. Minor Issues: 1) The document uses the abbreviation NSH both to refer to the header itself and the procedures for handling the header. For example, in section 2.3 it is the function rather than the NSH itself. Conversely, in section 7.1, NSH refers to the actual header. This is very confusing. 2) Only 2 bits are provided for the NSH version and one value is reserved. Hence, this only leaves a two additional versions. Did the WG carefully consider this limit? 3) 0x1 and 0x0 should not be used for bit values as Hexidecial digits are normally 4 bits. It is preferable to use use "set" and "clear" or "one" and "zero". 4) I find the usage of bytes rather than octets inconsistent with other RFCs and drafts (even if you do indicate that a byte is 8 bits). Also note that a "single byte word" may be referred to as a "byte" (or better yet, an octet). 5) Remove the statement "The NSH header length MUST be ...". This is a tautology since it is a specification of the number of 32-bit words (see RFC 791 IHL for a good example of header length specification). 6) In section 3.5.1, define the cardinality rules for specification of the context headers. Also clean up the inconsistency between the C-bit and Type. If you define the C-bit separately, the range on the type is only 7 bits (0-127). Finally, you should not refer to context headers as TLVs as they are not the format of a classic TLV. 7) RFC 7665 uses the term SFC-unaware for nodes that require an SFC proxy. This document uses several terms including "non-NSH-aware" and "NSH unaware". I'd recommend consistency with RFC 7665 or, at least, consistencyly use "NSH-unaware". 8) In section 7.1, indicate the specification of the load-balancing function is beyond the scope of this document. 9) In section 7.2, the order of the costs and next-hop in the examples is inconsistent. Nits: *** draft-ietf-sfc-nsh-10.txt.orig 2016-12-20 11:33:21.000000000 -0500 --- draft-ietf-sfc-nsh-10.txt 2016-12-20 12:09:49.000000000 -0500 *************** *** 241,252 **** (the underlay). Packets are encapsulated or tunneled to create the overlay network topology. ! Service Classifier: Logical entity providing classification function. Since they are logical, classifiers may be co-resident with SFC elements such as SFs or SFFs. Service classifiers ! perform classification and impose NSH. The initial classifier imposes the initial NSH and sends the NSH packet to the first SFF ! in the path. Non-initial (i.e. subsequent) classification can occur as needed and can alter, or create a new service path. Service Function (SF): Defined in [RFC7665]. --- 241,252 ---- (the underlay). Packets are encapsulated or tunneled to create the overlay network topology. ! Service Classifier: Logical entity providing the classification function. Since they are logical, classifiers may be co-resident with SFC elements such as SFs or SFFs. Service classifiers ! perform classification and impose NSHs. The initial classifier imposes the initial NSH and sends the NSH packet to the first SFF ! in the path. Non-initial, (i.e., subsequent) classification can occur as needed and can alter, or create a new service path. Service Function (SF): Defined in [RFC7665]. *************** *** 345,351 **** and the original packet/frame, for network forwarding. A Service Classifier adds the NSH. The NSH is removed by the last ! SFF in the service chain or by a SF that consumes the packet. 3.1. Network Service Header Format --- 345,351 ---- and the original packet/frame, for network forwarding. A Service Classifier adds the NSH. The NSH is removed by the last ! SFF in the service chain or by an SF that consumes the packet. 3.1. Network Service Header Format *************** *** 370,379 **** Base header: provides information about the service header and the payload protocol. ! Service Path Header: provide path identification and location within a service path. ! Context headers: carry metadata (i.e. context data) along a service path. 3.2. NSH Base Header --- 370,379 ---- Base header: provides information about the service header and the payload protocol. ! Service Path Header: provides path identification and location within a service path. ! Context headers: carries metadata (i.e., context data) along a service path. 3.2. NSH Base Header *************** *** 412,418 **** D.ietf-sfc-oam-framework]). SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC ! OAM procedures, SHALL discard packets with O-bit set. SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to --- 412,418 ---- D.ietf-sfc-oam-framework]). SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC ! OAM procedures, SHALL discard packets with the O-bit set. SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to *************** *** 420,426 **** subset of OAM functions, but can result in unexpected outcomes for others, thus it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior. ! The configurable parameter MUST be disabled by default. For non OAM packets, the O-bit MUST be cleared and MUST NOT be modified along the SFP. --- 420,426 ---- subset of OAM functions, but can result in unexpected outcomes for others, thus it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior. ! This configurable parameter MUST be disabled by default. For non OAM packets, the O-bit MUST be cleared and MUST NOT be modified along the SFP. *************** *** 429,446 **** C bit: Indicates that a critical metadata TLV is present. This bit acts as an indication for hardware implementers to decide how to handle the presence of a critical TLV without necessarily needing to ! parse all TLVs present. For an MD Type of 0x1 (i.e. no variable ! length metadata is present), the C bit MUST be set to 0x0. All other flag fields are reserved for future use. Reserved bits MUST be set to zero when sent and MUST be ignored upon receipt. ! Length: total length, in 4-byte words, of NSH including the Base Header, the Service Path Header and the context headers or optional ! variable length metadata. The Length MUST be of value 0x6 for MD ! Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type ! equal to 0x2. The NSH header length MUST be an integer number of 4 ! bytes. The length field indicates the "end" of NSH and where the --- 429,445 ---- C bit: Indicates that a critical metadata TLV is present. This bit acts as an indication for hardware implementers to decide how to handle the presence of a critical TLV without necessarily needing to ! parse all TLVs present. For an MD Type 1 (i.e., no variable ! length metadata is present), the C bit MUST be clear. All other flag fields are reserved for future use. Reserved bits MUST be set to zero when sent and MUST be ignored upon receipt. ! Length: Total length, in 32-bit words, of NSH including the Base Header, the Service Path Header and the context headers or optional ! variable length metadata. The Length MUST 0x6 for MD ! Type 1 and MUST be 2 or greater for MD Type 2. The length field ! indicates the "end" of NSH and where the original packet/frame begins. *************** *** 449,482 **** Internet-Draft Network Service Header September 2016 - original packet/frame begins. ! MD Type: indicates the format of NSH beyond the mandatory Base Header ! and the Service Path Header. MD Type defines the format of the metadata being carried. Please see IANA Considerations section below. NSH defines two MD types: ! 0x1 - which indicates that the format of the header includes fixed length context headers (see Figure 4 below). ! 0x2 - which does not mandate any headers beyond the Base Header and Service Path Header, but may contain optional variable length context information. The format of the base header and the service path header is invariant, and not affected by MD Type. ! NSH implementations MUST support MD Type = 0x1, and SHOULD support MD ! Type = 0x2. There exists, however, a middle ground, wherein a device ! will support MD Type 0x1 (as per the MUST) metadata, yet be deployed ! in a network with MD Type 0x2 metadata packets. In that case, the MD Type 0x1 node, MUST utilize the base header length field to determine the original payload offset if it requires access to the original packet/frame. ! Next Protocol: indicates the protocol type of the encapsulated data. NSH does not alter the inner payload, and the semantics on the inner protocol remain unchanged due to NSH service function chaining. Please see IANA Considerations section below. --- 448,481 ---- Internet-Draft Network Service Header September 2016 ! ! MD Type: Indicates the format of the NSH beyond the mandatory Base Header ! and the Service Path Header. The MD Type defines the format of the metadata being carried. Please see IANA Considerations section below. NSH defines two MD types: ! 1 - which indicates that the format of the header includes fixed length context headers (see Figure 4 below). ! 2 - which does not mandate any headers beyond the Base Header and Service Path Header, but may contain optional variable length context information. The format of the base header and the service path header is invariant, and not affected by MD Type. ! NSH implementations MUST support MD Type 1, and SHOULD support MD ! Type 2. There exists, however, a middle ground, wherein a device ! will support MD Type 1 (as per the MUST) metadata, yet be deployed ! in a network with MD Type 2 metadata packets. In that case, the MD Type 0x1 node, MUST utilize the base header length field to determine the original payload offset if it requires access to the original packet/frame. ! Next Protocol: Indicates the protocol type of the encapsulated data. NSH does not alter the inner payload, and the semantics on the inner protocol remain unchanged due to NSH service function chaining. Please see IANA Considerations section below. *************** *** 520,536 **** Figure 3: NSH Service Path Header ! Service Path Identifier (SPI): identifies a service path. Participating nodes MUST use this identifier for Service Function Path selection. The initial classifier MUST set the appropriate SPI for a given classification result. ! Service Index (SI): provides location within the SFP. The initial classifier MUST set the appropriate SI value for a given classification result. The initial SI value SHOULD default to 255. However, the classifier MUST allow configuration of other SI values. ! Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services and the new decremented SI value MUST be used in the egress NSH packet. The initial Classifier MUST send the packet to the first SFF in the --- 519,535 ---- Figure 3: NSH Service Path Header ! Service Path Identifier (SPI): Identifies a service path. Participating nodes MUST use this identifier for Service Function Path selection. The initial classifier MUST set the appropriate SPI for a given classification result. ! Service Index (SI): Indicates the location within the SFP. The initial classifier MUST set the appropriate SI value for a given classification result. The initial SI value SHOULD default to 255. However, the classifier MUST allow configuration of other SI values. ! The Service Index MUST be decremented by Service Functions or by SFC Proxy nodes after performing required services and the new decremented SI value MUST be used in the egress NSH packet. The initial Classifier MUST send the packet to the first SFF in the *************** *** 552,558 **** 3.4. NSH MD Type 1 When the Base Header specifies MD Type = 0x1, four Context Headers, ! 4-byte each, MUST be added immediately following the Service Path --- 551,557 ---- 3.4. NSH MD Type 1 When the Base Header specifies MD Type = 0x1, four Context Headers, ! 4-bytes each, MUST be added immediately following the Service Path *************** *** 567,573 **** 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! |Ver|O|C|R|R|R|R|R|R| Length | MD type=0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Identifer | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 566,572 ---- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! |Ver|O|C|R|R|R|R|R|R| Length | MD type = 1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Identifer | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *************** *** 590,599 **** 3.5. NSH MD Type 2 ! When the base header specifies MD Type= 0x2, zero or more Variable Length Context Headers MAY be added, immediately following the Service Path Header. Therefore, Length = 0x2, indicates that only ! the Base Header followed by the Service Path Header are present. The optional Variable Length Context Headers MUST be of an integer number of 4-bytes. The base header length field MUST be used to determine the offset to locate the original packet or frame for SFC nodes that --- 589,598 ---- 3.5. NSH MD Type 2 ! When the base header specifies MD Type 2, zero or more Variable Length Context Headers MAY be added, immediately following the Service Path Header. Therefore, Length = 0x2, indicates that only ! the Base Header and the Service Path Header are present. The optional Variable Length Context Headers MUST be of an integer number of 4-bytes. The base header length field MUST be used to determine the offset to locate the original packet or frame for SFC nodes that *************** *** 678,707 **** +-+-+-+-+-+-+-+-+ ! Figure 7: Critical Bit Placement Within the TLV Type Field ! If an NSH-aware node receives an encapsulated packet containing a TLV ! with the Critical bit set to 0x1 in the Type field and it does not understand how to process the Type, it MUST drop the packet. Transit ! devices (i.e. network nodes that do not participate in the service plane) MUST NOT drop packets based on the setting of this bit. ! Reserved bit: one reserved bit is present for future use. The reserved bits MUST be set to 0x0. ! Length: Length of the variable metadata, in single byte words. In case the metadata length is not an integer number of 4-byte words, the sender MUST add pad bytes immediately following the last metadata byte to extend the metadata to an integer number of 4-byte words. The receiver MUST round up the length field to the nearest 4-byte word boundary, to locate and process the next field in the packet. The receiver MUST access only those bytes in the metadata indicated ! by the length field (i.e. actual number of single byte words) and MUST ignore the remaining bytes up to the nearest 4-byte word boundary. A value of 0x0 or higher can be used. ! A value of 0x0 denotes a TLV header without a Variable Metadata field. --- 677,706 ---- +-+-+-+-+-+-+-+-+ ! Figure 7: Critical Bit Placement Within the Type Field ! If an NSH-aware node receives an encapsulated packet containing a Context ! Header with the Critical bit set in the Type field and it does not understand how to process the Type, it MUST drop the packet. Transit ! devices (i.e., network nodes that do not participate in the service plane) MUST NOT drop packets based on the setting of this bit. ! Reserved bit: One reserved bit is present for future use. The reserved bits MUST be set to 0x0. ! Length: Length of the variable metadata, in bytes. In case the metadata length is not an integer number of 4-byte words, the sender MUST add pad bytes immediately following the last metadata byte to extend the metadata to an integer number of 4-byte words. The receiver MUST round up the length field to the nearest 4-byte word boundary, to locate and process the next field in the packet. The receiver MUST access only those bytes in the metadata indicated ! by the length field (i.e., the actual number of bytes) and MUST ignore the remaining bytes up to the nearest 4-byte word boundary. A value of 0x0 or higher can be used. ! A value of 0x0 denotes a Context Header without a Variable Metadata field. *************** *** 738,747 **** 1. Insert or remove NSH: These actions can occur at the start and end respectively of a service path. Packets are classified, and ! if determined to require servicing, NSH will be imposed. A ! service classifier MUST insert NSH at the start of an SFP. An ! imposed NSH MUST contain valid Base Header and Service Path ! Header. At the end of a service function path, a SFF, MUST be the last node operating on the service header and MUST remove it. Multiple logical classifiers may exist within a given service --- 737,746 ---- 1. Insert or remove NSH: These actions can occur at the start and end respectively of a service path. Packets are classified, and ! if determined to require servicing, an NSH will be imposed. A ! service classifier MUST insert an NSH at the start of an SFP. An ! imposed NSH MUST contain a valid Base Header and Service Path ! Header. At the end of a service function path, an SFF MUST be the last node operating on the service header and MUST remove it. Multiple logical classifiers may exist within a given service *************** *** 797,804 **** +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | ! | | or remove NSH |Service| NSH |policy | ! | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | --- 796,803 ---- +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | ! | | or remove NSH |Service| NSH |Policy | ! | | |Function| |Selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | *************** *** 843,862 **** 5. NSH Encapsulation ! Once NSH is added to a packet, an outer encapsulation is used to forward the original packet and the associated metadata to the start of a service chain. The encapsulation serves two purposes: 1. Creates a topologically independent services plane. Packets are forwarded to the required services without changing the ! underlying network topology ! 2. Transit network nodes simply forward the encapsulated packets as ! is. The service header is independent of the encapsulation used and is ! encapsulated in existing transports. The presence of NSH is ! indicated via protocol type or other indicator in the outer encapsulation. --- 842,861 ---- 5. NSH Encapsulation ! Once an NSH is added to a packet, an outer encapsulation is used to forward the original packet and the associated metadata to the start of a service chain. The encapsulation serves two purposes: 1. Creates a topologically independent services plane. Packets are forwarded to the required services without changing the ! underlying network topology. ! 2. Transit network nodes simply forward the encapsulated packets ! unchanged. The service header is independent of the encapsulation used and is ! encapsulated in existing transports. The presence of an NSH is ! indicated via the protocol type or other indicator in the outer encapsulation. *************** *** 899,905 **** 6. Fragmentation Considerations ! NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. In order to ensure proper forwarding of NSH packets, several options for handling fragmentation and re-assembly --- 898,904 ---- 6. Fragmentation Considerations ! The NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. In order to ensure proper forwarding of NSH packets, several options for handling fragmentation and re-assembly *************** *** 910,916 **** carry SFC traffic without requiring fragmentation. However, there will be cases where the underlay MTU is not large ! enough to carry the NSH traffic. Since NSH does not provide fragmentation support at the service plane, the transport/overlay layer MUST provide the requisite fragmentation handling. Section 9 of [encap-considerations] provides guidance for those scenarios. --- 909,915 ---- carry SFC traffic without requiring fragmentation. However, there will be cases where the underlay MTU is not large ! enough to carry the NSH traffic. Since the NSH does not provide fragmentation support at the service plane, the transport/overlay layer MUST provide the requisite fragmentation handling. Section 9 of [encap-considerations] provides guidance for those scenarios. *************** *** 957,966 **** 7.1. SFFs and Overlay Selection ! As described above, NSH contains a Service Path Identifier (SPI) and a Service Index (SI). The SPI is, as per its name, an identifier. The SPI alone cannot be used to forward packets along a service path. ! Rather the SPI provide a level of indirection between the service path/topology and the network transport. Furthermore, there is no requirement, or expectation of an SPI being bound to a pre-determined or static network path. --- 956,965 ---- 7.1. SFFs and Overlay Selection ! As described above, the NSH contains a Service Path Identifier (SPI) and a Service Index (SI). The SPI is, as per its name, an identifier. The SPI alone cannot be used to forward packets along a service path. ! Rather the SPI provides a level of indirection between the service path/topology and the network transport. Furthermore, there is no requirement, or expectation of an SPI being bound to a pre-determined or static network path. *************** *** 973,992 **** equivalent. In the latter case, the SFF provides load distribution amongst the collection of SFs as needed. ! SI can also serve as a mechanism for loop detection within a service ! path since each SF in the path decrements the index; an Service Index of 0 indicates that a loop occurred and the packet must be discarded. This indirection -- path ID to overlay -- creates a true service plane. That is the SFF/SF topology is constructed without impacting the network topology but more importantly service plane only ! participants (i.e. most SFs) need not be part of the network overlay ! topology and its associated infrastructure (e.g. control plane, routing tables, etc.). As mentioned above, an existing overlay topology may be used provided it offers the requisite connectivity. The mapping of SPI to transport occurs on an SFF (as discussed above, ! the first SFF in the path gets a NSH encapsulated packet from the Classifier). The SFF consults the SPI/ID values to determine the appropriate overlay transport protocol (several may be used within a given network) and next hop for the requisite SF. Figure 9 below --- 972,991 ---- equivalent. In the latter case, the SFF provides load distribution amongst the collection of SFs as needed. ! The SI can also serve as a mechanism for loop detection within a service ! path since each SF in the path decrements the index; a Service Index of 0 indicates that a loop occurred and the packet must be discarded. This indirection -- path ID to overlay -- creates a true service plane. That is the SFF/SF topology is constructed without impacting the network topology but more importantly service plane only ! participants (i.e., most SFs) need not be part of the network overlay ! topology and its associated infrastructure (e.g., control plane, routing tables, etc.). As mentioned above, an existing overlay topology may be used provided it offers the requisite connectivity. The mapping of SPI to transport occurs on an SFF (as discussed above, ! the first SFF in the path gets an NSH encapsulated packet from the Classifier). The SFF consults the SPI/ID values to determine the appropriate overlay transport protocol (several may be used within a given network) and next hop for the requisite SF. Figure 9 below *************** *** 1053,1059 **** | SF34| 198.51.100.34 | UDP | | SF9 | 2001:db8::1 | GRE | +--------------------------+------------- ! = --- 1052,1059 ---- | SF34| 198.51.100.34 | UDP | | SF9 | 2001:db8::1 | GRE | +--------------------------+------------- ! ! Figure 11: SF Locator Mapping Example *************** *** 1065,1079 **** Internet-Draft Network Service Header September 2016 - Figure 11: SF Locator Mapping Example Since the SPI is a representation of the service path, the lookup may return more than one possible next-hop within a service path for a given SF, essentially a series of weighted (equally or otherwise) ! paths to be used (for load distribution, redundancy or policy), see Figure 12. The metric depicted in Figure 12 is an example to help ! illustrated weighing SFs. In a real network, the metric will range ! from a simple preference (similar to routing next- hop), to a true dynamic composite metric based on some service function-centric state (including load, sessions state, capacity, etc.) --- 1065,1078 ---- Internet-Draft Network Service Header September 2016 Since the SPI is a representation of the service path, the lookup may return more than one possible next-hop within a service path for a given SF, essentially a series of weighted (equally or otherwise) ! paths to be used (for load distribution, redundancy, or policy), see Figure 12. The metric depicted in Figure 12 is an example to help ! illustrate weighing SFs. In a real network, the metric will range ! from a simple preference (similar to routing next-hop), to a true dynamic composite metric based on some service function-centric state (including load, sessions state, capacity, etc.) *************** *** 1094,1100 **** ! Figure 12: NSH Weighted Service Path 7.2. Mapping NSH to Network Transport --- 1093,1099 ---- ! Figure 12: NSH Weighted Service Path Example 7.2. Mapping NSH to Network Transport *************** *** 1103,1109 **** Furthermore, the SPI to overlay mapping occurs at each SFF independently. Any combination of topology selection is possible. Please note, there is no requirement to create a new overlay topology ! if a suitable one already existing. NSH packets can use any (new or existing) overlay provided the requisite connectivity requirements are satisfied. --- 1102,1108 ---- Furthermore, the SPI to overlay mapping occurs at each SFF independently. Any combination of topology selection is possible. Please note, there is no requirement to create a new overlay topology ! if a suitable one already exists. NSH packets can use any (new or existing) overlay provided the requisite connectivity requirements are satisfied. *************** *** 1159,1165 **** collection of service function paths, with the interconnection provided by classifiers (in-service path, non-initial re- classification). These internal re-classifiers examine the packet at ! relevant points in the network, and, if needed, SPI and SI are updated (whether this update is a re-write, or the imposition of a new NSH with new values is implementation specific) to reflect the "result" of the classification. These classifiers may also of course --- 1158,1164 ---- collection of service function paths, with the interconnection provided by classifiers (in-service path, non-initial re- classification). These internal re-classifiers examine the packet at ! relevant points in the network, and, if needed, the SPI and SI are updated (whether this update is a re-write, or the imposition of a new NSH with new values is implementation specific) to reflect the "result" of the classification. These classifiers may also of course *************** *** 1200,1206 **** header(s). Service Functions: A classifier co-resident with Service Functions ! often perform very detailed and valuable classification. In some cases they may terminate, and be able to inspect encrypted traffic. --- 1199,1205 ---- header(s). Service Functions: A classifier co-resident with Service Functions ! often performs very detailed and valuable classification. In some cases they may terminate, and be able to inspect encrypted traffic. *************** *** 1209,1217 **** example, a network switch, acting as a classifier, might only be able to classify based on a 5-tuple, whereas, a service function may be able to inspect application information. Regardless of granularity, ! the classification information can be represented in NSH. ! Once the data is added to NSH, it is carried along the service path, NSH-aware SFs receive the metadata, and can use that metadata for local decisions and policy enforcement. The following two examples highlight the relationship between metadata and policy: --- 1208,1216 ---- example, a network switch, acting as a classifier, might only be able to classify based on a 5-tuple, whereas, a service function may be able to inspect application information. Regardless of granularity, ! the classification information can be represented in the NSH. ! Once the data is added to the NSH, it is carried along the service path, NSH-aware SFs receive the metadata, and can use that metadata for local decisions and policy enforcement. The following two examples highlight the relationship between metadata and policy: *************** *** 1234,1244 **** +-------+ +-------+ +-------+ ! | SFF )------->( SFF |------->| SFF | +---^---+ +---|---+ +---|---+ ,-|-. ,-|-. ,-|-. / \ / \ / \ ! ( Class ) SF1 ) ( SF2 ) \ ify / \ / \ / `---' `---' `---' 5-tuple: Permit Inspect --- 1233,1243 ---- +-------+ +-------+ +-------+ ! | SFF |------->| SFF |------->| SFF | +---^---+ +---|---+ +---|---+ ,-|-. ,-|-. ,-|-. / \ / \ / \ ! ( Class ) ( SF1 ) ( SF2 ) \ ify / \ / \ / `---' `---' `---' 5-tuple: Permit Inspect *************** *** 1280,1286 **** considerations may need to be considered. For example, if the metadata conveys tenant information, that information may need to be authenticated and/or encrypted between the originator and the ! intended recipients (which may include intended SFs only) . NSH --- 1279,1285 ---- considerations may need to be considered. For example, if the metadata conveys tenant information, that information may need to be authenticated and/or encrypted between the originator and the ! intended recipients (which may include intended SFs only). The NSH *************** *** 1299,1305 **** Post-initial metadata imposition (typically performed during initial service path determination), metadata may be augmented or updated: ! 1. Metadata Augmentation: Information may be added to NSH's existing metadata, as depicted in Figure 15. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with DPI or SLB) may augment --- 1298,1304 ---- Post-initial metadata imposition (typically performed during initial service path determination), metadata may be augmented or updated: ! 1. Metadata Augmentation: Information may be added to an NSH's existing metadata, as depicted in Figure 15. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with DPI or SLB) may augment *************** *** 1321,1333 **** +-----+ +-----+ +-----+ | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ! ^ | | ! ,---. ,---. ,---. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ / \ / \ / `-+-' `---' `---' ! | Inspect Deny +---+---+ employees employee+ | | Class=AppZ appZ +-------+ --- 1320,1332 ---- +-----+ +-----+ +-----+ | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ! ^ | | ! ,-|-. ,---. ,---. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ / \ / \ / `-+-' `---' `---' ! | Inspect Deny +---+---+ employees employee+ | | Class=AppZ appZ +-------+ *************** *** 1349,1355 **** | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ^ | | ! ,---. ,---. ,---. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ / \ / \ / --- 1348,1354 ---- | SFF |---------> | SFF |----------> | SFF | +--+--+ +--+--+ +--+--+ ^ | | ! ,-|-. ,---. ,---. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) \ / \ / \ / *************** *** 1408,1414 **** ,---. ,---. | ,---. / \ / SF1 \ | / \ ( SCL ) ( + ) | ( SF2 ) ! \ / \SCL2 / | \ / `---' `---' +-----+ `---' 5-tuple: Inspect | SFF | Original Tenant A Tenant A +--+--+ next SF --- 1407,1413 ---- ,---. ,---. | ,---. / \ / SF1 \ | / \ ( SCL ) ( + ) | ( SF2 ) ! \ / \ SCL2/ | \ / `---' `---' +-----+ `---' 5-tuple: Inspect | SFF | Original Tenant A Tenant A +--+--+ next SF *************** *** 1467,1477 **** there, far fewer protection mechanisms are needed in these environments, which are the primary design target of NSH. ! NSH is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity ! (e.g. [ [RFC6071]) can be used between SFF or even to SF. Similarly if confidentiality is required, existing encryption protocols can be ! used in conjunction with encapsulated NSH. Further, existing best practices, such as [RFC2827] should be deployed at the network layer to ensure that traffic entering the --- 1466,1476 ---- there, far fewer protection mechanisms are needed in these environments, which are the primary design target of NSH. ! The NSH is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity ! (e.g., [RFC6071]) can be used between an SFF or even to an SF. Similarly if confidentiality is required, existing encryption protocols can be ! used in conjunction with an encapsulated NSH. Further, existing best practices, such as [RFC2827] should be deployed at the network layer to ensure that traffic entering the *************** *** 1480,1486 **** NSH metadata authenticity and confidentiality must be considered as well. In order to protect the metadata, an operator can leverage the ! aforementioned mechanisms provided the transport layer, authenticity and/or confidentiality. An operator MUST carefully select the transport/underlay services to ensure end to end security services, when those are sought after. For example, if RFC6071 is used, the --- 1479,1485 ---- NSH metadata authenticity and confidentiality must be considered as well. In order to protect the metadata, an operator can leverage the ! aforementioned mechanisms if the transport layer provides authenticity and/or confidentiality. An operator MUST carefully select the transport/underlay services to ensure end to end security services, when those are sought after. For example, if RFC6071 is used, the *************** *** 1493,1504 **** Further, the extensibility of MD Type 2 to add information to packets, and where needed to mark that data as critical, allows for attaching signatures or even encryption keying information to the NSH ! header in the future. Based on the learnings from the work on [nsh- ! sec], it appears likely that this can provide any needed NSH-specific ! security mechanisms in the future. Lastly, SF security, although out of scope of this document, should ! be considered, particularly if an SF needs to access, authenticate or update NSH metadata. Further security considerations are discussed in [nsh-sec]. --- 1492,1502 ---- Further, the extensibility of MD Type 2 to add information to packets, and where needed to mark that data as critical, allows for attaching signatures or even encryption keying information to the NSH ! header in the future. It appears likely that the security mechanisms ! specified in [nsh-sec] can satisfy future NSH-specific requirements. Lastly, SF security, although out of scope of this document, should ! be considered, particularly if an SF needs to access, authenticate, or update NSH metadata. Thanks, Acee