Last Call Review of draft-ietf-sfc-nsh-18
review-ietf-sfc-nsh-18-rtgdir-lc-lindem-2017-08-10-00
review-ietf-sfc-nsh-18-rtgdir-lc-lindem-2017-08-10-00
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, and sometimes on special request. 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-18.txt Reviewer: Acee Lindem Review Date: August 10, 2017 IETF LC End Date: Not started yet. Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. It needs to be consumed along with the Service Function Chaining architecture. Comments: The document is an important piece of the Service Function Chaining work. I think the readability could be greatly improved with the editorial changes I have suggested. For example, using articles, e.g. “the”, when referring to the NSH. Major Issues: N/A Minor Issues: Section 1: Run-on sentense that makes up the entire third paragraph is too hard to parse. Please split it up and avoid cascading so many dependent clauses. Section 2.2: The discussion of meta-data support for MD types 0x1 or 0x3 is out of context. Section 2.4: The MUST's are contradictory. First it says the context header MUST be 16 bytes than it says it MUST be 0 bytes if it contains no meta-data. This is hardly "fixed". Section 2.5.1: Mandating that the unassigned bit MUST NOT be set will without saying it MUST be ignored on receipt is not be backward compatible. Section 11.2.1: List the bits that are assigned. Section 11.2.6: MD types 1 and 2 are assigned by the document yet this section states that no values are assigned. Nits: ACEE-M-G2HR:Desktop acee$ diff -c draft-ietf-sfc-nsh-18.txt.orig draft-ietf-sfc-nsh-18.txt *** draft-ietf-sfc-nsh-18.txt.orig 2017-08-04 07:27:08.000000000 -0400 --- draft-ietf-sfc-nsh-18.txt 2017-08-10 20:50:45.000000000 -0400 *************** *** 18,24 **** This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also ! provides a mechanism for metadata exchange along the instantiated service paths. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) architecture (defined in RFC7665). --- 18,24 ---- This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also ! provides a mechanism for metadata exchange along instantiated service paths. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) architecture (defined in RFC7665). *************** *** 181,187 **** Metadata: Defined in [RFC7665]. ! Network Locator: dataplane address, typically IPv4 or IPv6, used to send and receive network traffic. Network Node/Element: Device that forwards packets or frames based --- 181,187 ---- Metadata: Defined in [RFC7665]. ! Network Locator: Dataplane address, typically IPv4 or IPv6, used to send and receive network traffic. Network Node/Element: Device that forwards packets or frames based *************** *** 191,204 **** (the underlay). Packets are encapsulated or tunneled to create the overlay network topology. ! NSH-aware SFC-encapsulation-aware, or SFC-aware [RFC7665]. ! 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]. --- 191,204 ---- (the underlay). Packets are encapsulated or tunneled to create the overlay network topology. ! NSH-aware: SFC-encapsulation-aware, or SFC-aware [RFC7665]. ! 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 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]. *************** *** 269,277 **** 2. Network Service Header ! NSH contains service path information and optionally metadata that are added to a packet or frame and used to create a service plane. ! An outer transport header is imposed, on NSH and the original packet/ frame, for network forwarding. --- 269,277 ---- 2. Network Service Header ! The NSH contains service path information and optionally metadata that are added to a packet or frame and used to create a service plane. ! An outer transport header is imposed on the NSH and the original packet/ frame, for network forwarding. *************** *** 282,293 **** Internet-Draft Network Service Header (NSH) July 2017 ! A Service Classifier adds NSH. NSH is removed by the last SFF in the service chain or by an SF that consumes the packet. 2.1. Network Service Header Format ! NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header and optional Context Headers, as shown in Figure 1 below. 0 1 2 3 --- 282,293 ---- Internet-Draft Network Service Header (NSH) July 2017 ! 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. 2.1. Network Service Header Format ! The NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header and optional Context Headers, as shown in Figure 1 below. 0 1 2 3 *************** *** 304,316 **** Figure 1: Network Service Header ! 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 header: carries metadata (i.e., context data) along a service path. 2.2. NSH Base Header --- 304,316 ---- Figure 1: Network Service Header ! 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 header: Carries metadata (i.e., context data) along a service path. 2.2. NSH Base Header *************** *** 368,374 **** for service plane loop detection. The initial TTL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly ! provided, the default initial TTL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the TTL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a TTL value of 63. The packet MUST NOT be --- 368,374 ---- for service plane loop detection. The initial TTL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly ! provided, the default initial TTL value of 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the TTL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a TTL value of 63. The packet MUST NOT be *************** *** 380,389 **** elements. Elements which do not understand the meaning of any of these bits MUST NOT modify their actions based on those unknown bits. ! Length: The total length, in 4-byte words, of NSH including the Base Header, the Service Path Header, the Fixed Length Context Header or ! Variable Length Context Header(s). 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 length of the NSH header MUST be an integer --- 380,389 ---- elements. Elements which do not understand the meaning of any of these bits MUST NOT modify their actions based on those unknown bits. ! Length: The total length, in 4-byte words, of the NSH including the Base Header, the Service Path Header, the Fixed Length Context Header or ! Variable Length Context Header(s). The length MUST be 0x6 ! for MD Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to 0x2. The length of the NSH header MUST be an integer *************** *** 397,431 **** multiple of 4 bytes, thus variable length metadata is always padded out to a multiple of 4 bytes. ! 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 the IANA Considerations Section 11.2.3. This document specifies the following four MD Type values: ! 0x0 - this is a reserved value. Implementations SHOULD silently discard packets with MD Type 0x0. ! 0x1 - which indicates that the format of the header includes a fixed length Context Header (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 Header(s). The semantics of the variable length Context Header(s) are not defined in this document. The format of the optional variable length Context Headers is provided in Section 2.5.1. ! 0xF - this value is reserved for experimentation and testing, as per [RFC3692]. Implementations not explicitly configured to be part of an experiment SHOULD silently discard packets with MD Type 0xF. 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 MD Type = 0x2 ! (where the length is of value 0x2). NSH implementations SHOULD ! support MD Type 0x2 with length > 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 --- 397,431 ---- multiple of 4 bytes, thus variable length metadata is always padded out to a multiple of 4 bytes. ! 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 the IANA Considerations Section 11.2.3. This document specifies the following four MD Type values: ! 0x0 - This is a reserved value. Implementations SHOULD silently discard packets with MD Type 0x0. ! 0x1 - This indicates that the format of the header includes a fixed length Context Header (see Figure 4 below). ! 0x2 - This does not mandate any headers beyond the Base Header and Service Path Header, but may contain optional variable length Context Header(s). The semantics of the variable length Context Header(s) are not defined in this document. The format of the optional variable length Context Headers is provided in Section 2.5.1. ! 0xF - This value is reserved for experimentation and testing, as per [RFC3692]. Implementations not explicitly configured to be part of an experiment SHOULD silently discard packets with MD Type 0xF. The format of the Base Header and the Service Path Header is invariant, and not affected by MD Type. ! NSH implementations MUST support MD types 0x1 and 0x2 ! (where the length is 0x2). NSH implementations SHOULD ! support MD Type 0x2 with a length greater than 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 *************** *** 485,503 **** The meaning of these fields is as follows: ! 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 for a given SFP SHOULD set the SI to 255, however the control plane MAY configure the initial value of SI as appropriate (i.e., taking into account the length of the service function path). ! Service Index MUST be decremented by a value of 1 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 --- 485,503 ---- The meaning of these fields is as follows: ! 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 for a given SFP SHOULD set the SI to 255, however the control plane MAY configure the initial value of SI as appropriate (i.e., taking into account the length of the service function path). ! The Service Index MUST be decremented by a value of 1 by Service Functions or by SFC Proxy nodes after performing required services ! and the new decremented SI value MUST be used in the egress packet's ! NSH. The initial Classifier MUST send the packet to the first SFF *************** *** 511,519 **** SPI, the (re)classifier is, in effect, the initial classifier for the resultant SPI. ! The SI is used in conjunction with Service Path Identifier for Service Function Path Selection and for determining the next SFF/SF ! in the path. The SI is also valuable when troubleshooting/ reporting service paths. Additionally, while the TTL field is the main mechanism for service plane loop detection, the SI can also be used for detecting service plane loops. --- 511,519 ---- SPI, the (re)classifier is, in effect, the initial classifier for the resultant SPI. ! The SI is used in conjunction with the Service Path Identifier for Service Function Path Selection and for determining the next SFF/SF ! in the path. The SI is also valuable when troubleshooting/reporting service paths. Additionally, while the TTL field is the main mechanism for service plane loop detection, the SI can also be used for detecting service plane loops. *************** *** 603,609 **** 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | Metadata Class | Type |U| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 603,609 ---- 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! | Metadata Class | Type |U| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *************** *** 618,643 **** Internet-Draft Network Service Header (NSH) July 2017 ! Metadata Class (MD Class): defines the scope of the 'Type' field to provide a hierarchical namespace. The IANA Considerations Section 11.2.4 defines how the MD Class values can be allocated to standards bodies, vendors, and others. ! Type: indicates the explicit type of metadata being carried and is ! the responsibility of the MD Class owner. ! Unassigned bit: one unassigned bit is available for future use. This ! bit MUST be set to 0b. ! Length: indicates the 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. The Length may be 0 or greater. A value of 0 denotes a Context Header without a Variable Metadata --- 618,643 ---- Internet-Draft Network Service Header (NSH) July 2017 ! Metadata Class (MD Class): Defines the scope of the 'Type' field to provide a hierarchical namespace. The IANA Considerations Section 11.2.4 defines how the MD Class values can be allocated to standards bodies, vendors, and others. ! Type: Indicates the explicit type of metadata being carried. Definition ! of the Type is the responsibility of the MD Class owner. ! Unassigned bit: One unassigned bit is available for future use. This ! bit MUST NOT be set. ! Length: Indicates the length of the variable metadata, in bytes. ! When 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 bytes) ! and MUST ignore the remaining bytes up to the nearest 4-byte word boundary. The Length may be 0 or greater. A value of 0 denotes a Context Header without a Variable Metadata *************** *** 647,669 **** that are mandatory-to-implement or those that are mandatory-to- process. These considerations are deployment-specific. However, the control plane is entitled to instruct SFC-aware SFs with the data ! structure of context header together with their scoping (see Section 3.3.3 of [I-D.ietf-sfc-control-plane]). ! Upon receipt of a packet that belong to a given SFP, if a mandatory- to-process context header is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log at least once per the SPI ! for which a mandatory metadata is missing. If multiple mandatory-to-process context headers are required for a ! given SFP, the control plane MAY instruct the SFC-aware SF with the ! order to consume these Context Headers. If no instructions are provided, the SFC-aware SF MUST process these Context Headers in the order their appear in an NSH packet. If multiple instances of the same metadata are included in an NSH packet, but the definition of that context header does not allow for ! it, the SFC-aware SF MUST process first instance and ignore subsequent instances. --- 647,669 ---- that are mandatory-to-implement or those that are mandatory-to- process. These considerations are deployment-specific. However, the control plane is entitled to instruct SFC-aware SFs with the data ! structure of context header together with its scoping (see Section 3.3.3 of [I-D.ietf-sfc-control-plane]). ! Upon receipt of a packet that belongs to a given SFP, if a mandatory- to-process context header is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log at least once per the SPI ! for which the mandatory metadata is missing. If multiple mandatory-to-process context headers are required for a ! given SFP, the control plane MAY instruct the SFC-aware SF ! to consume these Context Headers. If no instructions are provided, the SFC-aware SF MUST process these Context Headers in the order their appear in an NSH packet. If multiple instances of the same metadata are included in an NSH packet, but the definition of that context header does not allow for ! it, the SFC-aware SF MUST process the first instance and ignore subsequent instances. *************** *** 677,693 **** 3. NSH Actions NSH-aware nodes are the only nodes that may alter the content of NSH ! headers. NSH-aware nodes include: service classifiers, SFF, SF and SFC proxies. These nodes have several possible NSH-related actions: ! 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, an SFF, MUST be ! the last node operating on the service header and MUST remove NSH ! before forwarding or delivering the un-encapsulated packet Multiple logical classifiers may exist within a given service path. Non-initial classifiers may re-classify data and that re- --- 677,693 ---- 3. NSH Actions NSH-aware nodes are the only nodes that may alter the content of NSH ! headers. NSH-aware nodes include: service classifiers, SFFs, SFs, and SFC proxies. These nodes have several possible NSH-related actions: ! 1. Insert or remove NSH: These actions can occur respectively at the start or ! end 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 both 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 the NSH ! before forwarding or delivering the un-encapsulated packet. Multiple logical classifiers may exist within a given service path. Non-initial classifiers may re-classify data and that re- *************** *** 696,702 **** classification that results in a change of service path, it MUST remove the existing NSH and MUST impose a new NSH with the Base Header and Service Path Header reflecting the new service path ! information and set the initial SI. Metadata MAY be preserved in the new NSH. --- 696,702 ---- classification that results in a change of service path, it MUST remove the existing NSH and MUST impose a new NSH with the Base Header and Service Path Header reflecting the new service path ! information and MUST set the initial SI. Metadata MAY be preserved in the new NSH. *************** *** 719,725 **** Service Index and MAY update contexts. When an SFC proxy receives an NSH-encapsulated packet, it MUST remove NSH before forwarding it to an NSH unaware SF. When the SFC Proxy receives ! a packet back from an NSH unaware SF, it MUST re-encapsulates it with the correct NSH, and MUST decrement the Service Index by one. --- 719,725 ---- Service Index and MAY update contexts. When an SFC proxy receives an NSH-encapsulated packet, it MUST remove NSH before forwarding it to an NSH unaware SF. When the SFC Proxy receives ! a packet back from an NSH unaware SF, it MUST re-encapsulate it with the correct NSH, and MUST decrement the Service Index by one. *************** *** 763,778 **** 4. NSH Transport 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 --- 763,778 ---- 4. NSH Transport Encapsulation ! Once a 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 ! without modification. The service header is independent of the encapsulation used and is encapsulated in existing transports. The presence of NSH is *************** *** 788,794 **** 5. Fragmentation Considerations ! NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. --- 788,794 ---- 5. 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. *************** *** 806,812 **** 6.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 provides a level of indirection between the service --- 806,812 ---- 6.1. SFFs and Overlay Selection ! As described above, an 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 *************** *** 827,839 **** is incorrect and the packet must be discarded. This indirection -- SPI 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.) SFs need to be able to return a packet to an appropriate SFF ! (i.e., has the requisite NSH information) when service processing is ! complete. This can be via the over or underlay and in some case --- 827,839 ---- is incorrect and the packet must be discarded. This indirection -- SPI 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). SFs need to be able to return a packet to an appropriate SFF ! (i.e., one that has the requisite NSH information) when service processing is ! complete. This can be via the overlay or underlay and, in some case *************** *** 847,853 **** 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. Table 1 below --- 847,853 ---- 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. Table 1 below *************** *** 874,880 **** Additionally, further indirection is possible: the resolution of the required SF network locator may be a localized resolution on an SFF, ! rather than a service function chain control plane responsibility, as per Table 2 and Table 3 below. Please note: VXLAN-gpe and GRE in the above table refer to --- 874,880 ---- Additionally, further indirection is possible: the resolution of the required SF network locator may be a localized resolution on an SFF, ! rather than a service function chain control-plane responsibility, as per Table 2 and Table 3 below. Please note: VXLAN-gpe and GRE in the above table refer to *************** *** 925,934 **** 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 Table 4. The metric depicted in Table 4 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.) --- 925,934 ---- 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 Table 4. The metric depicted in Table 4 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.) *************** *** 981,987 **** 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. --- 981,987 ---- 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. *************** *** 1025,1032 **** The SPI and SI serve an important function for visibility into the service topology. An operator can determine what service path a packet is "on", and its location within that path simply by viewing ! NSH information (packet capture, IPFIX, etc.) The information can be ! used for service scheduling and placement decisions, troubleshooting and compliance verification. 6.4. Service Graphs --- 1025,1032 ---- The SPI and SI serve an important function for visibility into the service topology. An operator can determine what service path a packet is "on", and its location within that path simply by viewing ! NSH information (packet capture, IPFIX, etc). The information can be ! used for service scheduling and placement decisions, troubleshooting, and compliance verification. 6.4. Service Graphs *************** *** 1092,1098 **** +-------+ +-------+ +-------+ | SFF )------->( SFF |------->| SFF | ! +---^---+ +---|---+ +---|---+ ,-|-. ,-|-. ,-|-. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) --- 1092,1099 ---- +-------+ +-------+ +-------+ | SFF )------->( SFF |------->| SFF | ! +---+---+ +---+---+ +---+---+ ! ^ | | ,-|-. ,-|-. ,-|-. / \ / \ / \ ( Class ) ( SF1 ) ( SF2 ) *************** *** 1135,1141 **** +---+---+ employees | | +-------+ ! external system: Employee AppZ --- 1136,1142 ---- +---+---+ employees | | +-------+ ! External system: Employee AppZ *************** *** 1151,1157 **** 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 itself does not provide privacy functions, rather it relies on the transport/overlay layer. An operator can select the appropriate transport to ensure confidentially (and other security) --- 1152,1158 ---- 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 itself does not provide privacy functions, rather it relies on the transport/overlay layer. An operator can select the appropriate transport to ensure confidentially (and other security) *************** *** 1161,1169 **** 7.2. Updating/Augmenting Metadata 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 10. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with DPI or SLB) may augment --- 1162,1170 ---- 7.2. Updating/Augmenting Metadata Post-initial metadata imposition (typically performed during initial ! service path determination) of metadata may be augmented or updated: ! 1. Metadata Augmentation: Information may be added to an NSH's existing metadata, as depicted in Figure 10. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with DPI or SLB) may augment *************** *** 1184,1190 **** 2. Metadata Update: Subsequent classifiers may update the initial classification if it is determined to be incorrect or not descriptive enough. For example, the initial classifier adds ! metadata that describes the traffic as "internet" but a security service function determines that the traffic is really "attack". Figure 11 illustrates an example of updating metadata. --- 1185,1191 ---- 2. Metadata Update: Subsequent classifiers may update the initial classification if it is determined to be incorrect or not descriptive enough. For example, the initial classifier adds ! metadata that describes the traffic as "Internet" but a security service function determines that the traffic is really "attack". Figure 11 illustrates an example of updating metadata. *************** *** 1201,1207 **** +---+---+ employees employee+ | | Class=AppZ appZ +-------+ ! external system: Employee --- 1202,1208 ---- +---+---+ employees employee+ | | Class=AppZ appZ +-------+ ! External system: Employee *************** *** 1290,1296 **** Internet-Draft Network Service Header (NSH) July 2017 ! NSH is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity (e.g., [RFC6071]) can be used. Similarly, if confidentiality is required, existing encryption protocols can be used in conjunction --- 1291,1297 ---- Internet-Draft Network Service Header (NSH) July 2017 ! An NSH is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity (e.g., [RFC6071]) can be used. Similarly, if confidentiality is required, existing encryption protocols can be used in conjunction *************** *** 1303,1314 **** 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 operator MUST ensure it can be supported by the transport/underlay of ! all relevant network segments as well as SFF and SFs. Further, as described in Section 8.1, operators can and should use indirect identification for personally identifying information, thus significantly mitigating the risk of privacy violation. Means to --- 1304,1316 ---- NSH metadata authenticity and confidentiality must be considered as well. In order to protect the metadata, an operator can leverage the ! aforementioned mechanisms provided by the transport layer including authenticity and/or confidentiality. An operator MUST carefully select the ! transport/underlay services to ensure end-to-end security services, ! when those are sought. For example, if [RFC6071] is used, the operator MUST ensure it can be supported by the transport/underlay of ! all relevant network segments as well as SFF and SFs in the service path. ! Further, as described in Section 8.1, operators can and should use indirect identification for personally identifying information, thus significantly mitigating the risk of privacy violation. Means to *************** *** 1318,1324 **** packet upstream. 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. 9. Contributors --- 1320,1326 ---- packet upstream. 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. 9. Contributors *************** *** 1466,1472 **** design. The editors also acknowledge comprehensive reviews and respective ! suggestions by Med Boucadair and Adrian Farrel. Lastly, David Dolson has provides significant review, feedback and suggestions throughout the evolution of this document. His --- 1468,1474 ---- design. The editors also acknowledge comprehensive reviews and respective ! suggestions by Med Boucadair, Adrian Farrel, and Acee Lindem. Lastly, David Dolson has provides significant review, feedback and suggestions throughout the evolution of this document. His Thanks, Acee