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

[Alia Atlas <[e-mail]>]

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