Subject: [sfc] Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 11 Aug 2017 01:10:53 +0000

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 10 Aug 2017 22:24:51 -0400

Acee,

Thank you for your review.  I look forward to the editors & WG discussing
how to improve
the draft.

Regards,
Alia

On Thu, Aug 10, 2017 at 9:10 PM, Acee Lindem (acee) <[email-masked]> wrote:

> 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.
>
>     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:
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Aug 2017 03:23:34 +0000

Alia,

On Aug 10, 2017, at 10:24 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Acee,

Seems all these minor review items are fairly localized, clear, and non-contentious.

We have provided responses and diffs on the list, and a new revision is ready to be submitted when Joel / you wants us to pull the trigger (addressing Ops and RTG Dirs).

Thanks,

— Carlos.

Regards,
Alia

On Thu, Aug 10, 2017 at 9:10 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Summary:

Comments:

Major Issues: N/A

Minor Issues:

     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.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 ****

--- 18,24 ----

***************
*** 181,187 ****

--- 269,277 ----

!    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 ****

       0                   1                   2                   3
--- 282,293 ----

!    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.

!    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 ****

 2.2.  NSH Base Header
--- 304,316 ----

 2.2.  NSH Base Header
***************
*** 368,374 ****
    these bits MUST NOT modify their actions based on those unknown bits

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Aug 2017 23:27:03 -0400

I would like to wait until we also get the secdir review and Alia's own 
review before posting the new draft.
Joel

On 8/10/17 11:23 PM, Carlos Pignataro (cpignata) wrote:
> We have provided responses and diffs on the list, and a new revision is 
> ready to be submitted when Joel / you wants us to pull the trigger 
> (addressing Ops and RTG Dirs).
> 
> Thanks,
> 
> — Carlos.
> 
>>
>> Regards,
>> Alia
>>
> Carlos Pignataro, [email-masked] <mailto:[email-masked]>
> 
> /“Sometimes I use big words that I do not fully understand, to make 
> myself sound more photosynthesis."/
>

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 11 Aug 2017 00:06:44 -0400

Hi, Acee,

Many thanks for the thorough review! Certainly can apply this patch :-)

    The editors also acknowledge comprehensive reviews and respective
-    suggestions by Med Boucadair and Adrian Farrel.
+    suggestions by Med Boucadair, Adrian Farrel, and Acee Lindem.

It is encouraging to see that your thorough and comprehensive review found only a handful of Minor issues, nothing Major, and nits.

Please see inline.

> On Aug 10, 2017, at 9:10 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hello,
> 
>    I have some minor concerns about this document that I think should be resolved before publication.

Thanks! Of course we will resolve.

> It needs to be consumed along with the Service Function Chaining architecture. 
> 
> Comments:

Yes, we will fix all nits and editorials. However, in regards to having an article preceding “NSH” (e.g., “the NSH” or “an NSH”), I also wanted to change that earlier when I started actively editing the document — however I was instructed that the earlier WG consensus was to leave “NSH” without articles.

> Major Issues: N/A 

Ack.

>            cascading so many dependent clauses.

OK, reworded as follows, welcome other suggestions if you have:

  New data center network and cloud architectures require more flexible
  service function deployment models.  Additionally, the transition to
  virtual platforms demands an agile service insertion model that
  supports dynamic and elastic service delivery.  Specifically, the
  following functions are necessary:

     The movement of service functions and application workloads in the
     network.

     The ability to easily bind service policy to granular information,
     such as per-subscriber state.

     The capability to steer traffic to the requisite service
     function(s).

>      Section 2.2: The discussion of meta-data support for MD types 0x1 or

It seems to me it is well within the context of the specification of MD Type. Since that is an important piece of text that the WG crafted, do you have a concrete and specific suggestion of where else in the document it might fit better? Otherwise, I recommend leaving it as-is.

>                            it contains no meta-data. This is hardly "fixed”.

You are mis-reading, the text tries to say that the content MBZ. Not the length:

  When the Base Header specifies MD Type = 0x1, a Fixed Length Context
  Header (16-bytes) MUST be present immediately following the Service
  Path Header, as per Figure 4.  A Fixed Length Context Header that
  carries no metadata MUST be set to zero.

I will reword to:

  When the Base Header specifies MD Type = 0x1, a Fixed Length Context
  Header (16-bytes) MUST be present immediately following the Service
  Path Header, as per Figure 4.  The value of a Fixed Length Context
  Header that carries no metadata MUST be set to zero.

Better?

>                               not be backward compatible.

OK, changed:

  Unassigned bit: one unassigned bit is available for future use.  This
  bit MUST be set to 0b.

To:

  Unassigned bit: one unassigned bit is available for future use.  This
  bit MUST be set to 0b and MUST be ignored on receipt.

>     Section 11.2.1: List the bits that are assigned. 

The whole header is not a bit mask:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I can add the “O” bit, but otherwise those are fields and not bits.

Happy to do this for completeness.

OLD:

11.2.1.  NSH Base Header Unassigned Bits

  There are five unassigned bits in the NSH Base Header.  New bits are
  assigned via Standards Action [RFC8126].
  Bit 3 - Unassigned
  Bits 16-19 - Unassigned

NEW:

11.2.1.  NSH Base Header Bits

  There are five unassigned bits in the NSH Base Header, and one bit
  assigned (O-bit).  New bits are assigned via Standards Action
  [RFC8126].

  Bit 2 - O (OAM) bit
  Bit 3 - Unassigned
  Bits 16-19 - Unassigned

>                                 this section states that no values are assigned. 

This is about Section 2.5.1, not about MD Type. The title is incorrect.

NEW:

11.2.6.  New IETF Assigned Optional Variable Length Metadata Type
        Registry

  This document requests IANA to create a registry for the type values
  owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF
  Assigned Optional Variable Length Metadata Type Registry", as
  specified in Section 2.5.1.

  The type values are assigned via Standards Action [RFC8126].

  No initial values are assigned at the creation of the registry.

> Nits:

Will take care of these nits, except “article NSH”.

Thanks!

Carlos.

> *** draft-ietf-sfc-nsh-18.txt.orig

—
Carlos Pignataro, [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Aug 2017 04:12:38 +0000

Sounds good — current diffs (so Acee a d Jurgen can verify) hereby attached.

Thanks,

— Carlos.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 11 Aug 2017 15:58:47 +0000

Hi Carlos, 

On 8/11/17, 12:06 AM, "Carlos Pignataro on behalf of Carlos Pignataro
(cpignata)" <[email-masked] on behalf of [email-masked]> wrote:

>It is encouraging to see that your thorough and comprehensive review
>found only a handful of Minor issues, nothing Major, and nits.
>
>Please see inline.
>
>
>> 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
>>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.
>
>Yes, we will fix all nits and editorials. However, in regards to having
>an article preceding “NSH” (e.g., “the NSH” or “an NSH”), I also wanted
>to change that earlier when I started actively editing the document —
>however I was instructed that the earlier WG consensus was to leave “NSH”
>without articles.
>
>> 
>> Major Issues: N/A
>> 
>
>Ack.
>
>> Minor Issues:
>> 

This is much better.

>It seems to me it is well within the context of the specification of MD
>Type. Since that is an important piece of text that the WG crafted, do
>you have a concrete and specific suggestion of where else in the document
>it might fit better? Otherwise, I recommend leaving it as-is.

Perhaps then you could add a forward reference to section.
>>"fixed”.

Much better. 

>  bit MUST be set to 0b and MUST be ignored on receipt.

Yes - except capitalize “One”.
>The whole header is not a bit mask:

Ok. 
>  No initial values are assigned at the creation of the registry.

This clears up the confusion.
>Will take care of these nits, except “article NSH”.

I think this has always been confusing in this draft since the Network
Service Header is nothing more than a protocol construct in the Service
Chaining Architecture. NSH is not an architecture itself. However, I’ll
leave it to thew WG.

Thanks,
Acee 

>>as

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 11 Aug 2017 16:24:11 +0000

Hi, Acee,

> On Aug 11, 2017, at 11:58 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Carlos, 
> 

Great.

> Perhaps then you could add a forward reference to section.

Sure, I added: “NSH MD Type 1 and MD Type 2 are described in detail in Sections 2.4 and 2.5, respectively."

Thanks!

> Yes - except capitalize “One”.

I missed it here, but I did capitalize it in the working copy (and diffs I sent).

Ack.

> This clears up the confusion.

Thanks.

> Chaining Architecture. NSH is not an architecture itself. However, I’ll

Yes, the architecture is RFC 7665. See the last sentence of the Abstract.

Thanks, Acee! All covered in our working copy.

— Carlos.

—