Last Call Review of draft-ietf-sfc-nsh-18
review-ietf-sfc-nsh-18-rtgdir-lc-lindem-2017-08-10-00

Request Review of draft-ietf-sfc-nsh
Requested rev. no specific revision (document currently at 28)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-08-11
Requested 2017-07-26
Requested by Alia Atlas
Authors Paul Quinn, Uri Elzur, Carlos Pignataro
Draft last updated 2017-08-10
Completed reviews Rtgdir Early review of -10 by Acee Lindem (diff)
Secdir Last Call review of -18 by Christian Huitema (diff)
Opsdir Last Call review of -18 by Jürgen Schönwälder (diff)
Rtgdir Last Call review of -18 by Acee Lindem (diff)
Opsdir Last Call review of -19 by Jürgen Schönwälder (diff)
Tsvart Last Call review of -19 by Wesley Eddy (diff)
Genart Last Call review of -19 by Dan Romascanu (diff)
Secdir Telechat review of -25 by Christian Huitema (diff)
Comments
Requesting in parallel with doing my AD review.  Earlier reviews appreciated!
Assignment Reviewer Acee Lindem
State Completed
Review review-ietf-sfc-nsh-18-rtgdir-lc-lindem-2017-08-10
Reviewed rev. 18 (document currently at 28)
Review result Has Issues
Review completed: 2017-08-10

Review
review-ietf-sfc-nsh-18-rtgdir-lc-lindem-2017-08-10

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