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

[Carlos Pignataro <[e-mail]>]

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) <[e-mail]> 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.
> 
> 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.

Thanks! Of course we will resolve.

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

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

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
>                             0x3 is out of context.
> 

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.


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

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?

> 

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

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



> 
>     Section 11.2.6: MD types 1 and 2 are assigned by the document yet
>                                 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.

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

—
Carlos Pignataro, [e-mail]

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