Early Review of draft-ietf-sfc-nsh-10
review-ietf-sfc-nsh-10-rtgdir-early-lindem-2017-01-10-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review. 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-10.txt
Reviewer: Acee Lindem
Review Date: 4 January 2014
IETF LC End Date: N/A
Intended Status: Proposed Standard

Summary:
I have some major concerns with the things that are missing from the document
that need to be resolved before the document is progressed. I also belive the
document could be vastly improved through resolution of the list minor isses.

Comments:
Refer to other sections.

Major Issues:

  1) The NSH MD Type 1 has 16 octets of Mandatory context headers but the
  contents of these headers are not specified anywhere in the document. 2) The
  example figures in section 8 are of no value since there is no explanation of
  the various icons and flows. Additionally, the deviate somewhat from the
  description of service function graphs in section 2.1 of RFC 7665.

Minor Issues:

  1) The document uses the abbreviation NSH both to refer to the header itself
  and the procedures for handling the header. For example, in section 2.3 it is
  the function rather than the NSH itself. Conversely, in section 7.1, NSH
  refers to the actual header. This is very confusing. 2) Only 2 bits are
  provided for the NSH version and one value is reserved. Hence, this only
  leaves a two additional versions. Did the WG carefully consider this limit?
  3) 0x1 and 0x0 should not be used for bit values as Hexidecial digits are
  normally 4 bits. It is preferable to use use "set" and "clear" or "one" and
  "zero". 4) I find the usage of bytes rather than octets inconsistent with
  other RFCs and drafts (even if you do indicate that a byte is 8 bits). Also
  note that a "single byte word" may be referred to as a "byte" (or better yet,
  an octet). 5) Remove the statement "The NSH header length MUST be ...". This
  is a tautology since it is a specification of the number of 32-bit words (see
  RFC 791 IHL for a good example of header length specification). 6) In section
  3.5.1, define the cardinality rules for specification of the context headers.
  Also clean up the inconsistency between the C-bit and Type. If you define the
  C-bit separately, the range on the type is only 7 bits (0-127). Finally, you
  should not refer to context headers as TLVs as they are not the format of a
  classic TLV. 7) RFC 7665 uses the term SFC-unaware for nodes that require an
  SFC proxy. This document uses several terms including "non-NSH-aware" and
  "NSH unaware". I'd recommend consistency with RFC 7665 or, at least,
  consistencyly use "NSH-unaware". 8) In section 7.1, indicate the
  specification of the load-balancing function is beyond the scope of this
  document. 9) In section 7.2, the order of the costs and next-hop in the
  examples is inconsistent.

Nits:
*** draft-ietf-sfc-nsh-10.txt.orig 2016-12-20 11:33:21.000000000 -0500
--- draft-ietf-sfc-nsh-10.txt 2016-12-20 12:09:49.000000000 -0500
***************
*** 241,252 ****
        (the underlay).  Packets are encapsulated or tunneled to create
        the overlay network topology.

!    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].
--- 241,252 ----
        (the underlay).  Packets are encapsulated or tunneled to create
        the overlay network topology.

!    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 NSHs.  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].
***************
*** 345,351 ****
     and the original packet/frame, for network forwarding.

     A Service Classifier adds the NSH.  The NSH is removed by the last
!    SFF in the service chain or by a SF that consumes the packet.

  3.1.  Network Service Header Format

--- 345,351 ----
     and the original packet/frame, for network forwarding.

     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.

  3.1.  Network Service Header Format

***************
*** 370,379 ****
     Base header: provides information about the service header and the
     payload protocol.

!    Service Path Header: provide path identification and location within
     a service path.

!    Context headers: carry metadata (i.e. context data) along a service
     path.

  3.2.  NSH Base Header
--- 370,379 ----
     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 headers: carries metadata (i.e., context data) along a service
     path.

  3.2.  NSH Base Header
***************
*** 412,418 ****
     D.ietf-sfc-oam-framework]).

     SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
!    OAM procedures, SHALL discard packets with O-bit set.

     SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable
     parameter to enable forwarding received SFC OAM packets unmodified to
--- 412,418 ----
     D.ietf-sfc-oam-framework]).

     SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
!    OAM procedures, SHALL discard packets with the O-bit set.

     SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable
     parameter to enable forwarding received SFC OAM packets unmodified to
***************
*** 420,426 ****
     subset of OAM functions, but can result in unexpected outcomes for
     others, thus it is recommended to analyze the impact of forwarding an
     OAM packet for all OAM functions prior to enabling this behavior.
!    The configurable parameter MUST be disabled by default.

     For non OAM packets, the O-bit MUST be cleared and MUST NOT be
     modified along the SFP.
--- 420,426 ----
     subset of OAM functions, but can result in unexpected outcomes for
     others, thus it is recommended to analyze the impact of forwarding an
     OAM packet for all OAM functions prior to enabling this behavior.
!    This configurable parameter MUST be disabled by default.

     For non OAM packets, the O-bit MUST be cleared and MUST NOT be
     modified along the SFP.
***************
*** 429,446 ****
     C bit: Indicates that a critical metadata TLV is present.  This bit
     acts as an indication for hardware implementers to decide how to
     handle the presence of a critical TLV without necessarily needing to
!    parse all TLVs present.  For an MD Type of 0x1 (i.e. no variable
!    length metadata is present), the C bit MUST be set to 0x0.

     All other flag fields are reserved for future use.  Reserved bits
     MUST be set to zero when sent and MUST be ignored upon receipt.

!    Length: total length, in 4-byte words, of NSH including the Base
     Header, the Service Path Header and the context headers or optional
!    variable length metadata.  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 NSH header length MUST be an integer number of 4
!    bytes.  The length field indicates the "end" of NSH and where the

--- 429,445 ----
     C bit: Indicates that a critical metadata TLV is present.  This bit
     acts as an indication for hardware implementers to decide how to
     handle the presence of a critical TLV without necessarily needing to
!    parse all TLVs present.  For an MD Type 1 (i.e., no variable
!    length metadata is present), the C bit MUST be clear.

     All other flag fields are reserved for future use.  Reserved bits
     MUST be set to zero when sent and MUST be ignored upon receipt.

!    Length: Total length, in 32-bit words, of NSH including the Base
     Header, the Service Path Header and the context headers or optional
!    variable length metadata.  The Length MUST 0x6 for MD
!    Type 1 and MUST be 2 or greater for MD Type 2. The length field
!    indicates the "end" of NSH and where the original packet/frame begins.

***************
*** 449,482 ****
  Internet-Draft           Network Service Header           September 2016

-    original packet/frame begins.

!    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 IANA Considerations section
     below.

     NSH defines two MD types:

!    0x1 - which indicates that the format of the header includes fixed
     length context headers (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
     information.

     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 SHOULD support MD
!    Type = 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 the base header length field to determine
     the original payload offset if it requires access to the original
     packet/frame.

!    Next Protocol: indicates the protocol type of the encapsulated data.
     NSH does not alter the inner payload, and the semantics on the inner
     protocol remain unchanged due to NSH service function chaining.
     Please see IANA Considerations section below.
--- 448,481 ----
  Internet-Draft           Network Service Header           September 2016

!
!    MD Type: Indicates the format of the NSH beyond the mandatory Base Header
!    and the Service Path Header.  The MD Type defines the format of the
     metadata being carried.  Please see IANA Considerations section
     below.

     NSH defines two MD types:

!    1 - which indicates that the format of the header includes fixed
     length context headers (see Figure 4 below).

!    2 - which does not mandate any headers beyond the Base Header and
     Service Path Header, but may contain optional variable length context
     information.

     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 1, and SHOULD support MD
!    Type 2.  There exists, however, a middle ground, wherein a device
!    will support MD Type 1 (as per the MUST) metadata, yet be deployed
!    in a network with MD Type 2 metadata packets.  In that case, the MD
     Type 0x1 node, MUST utilize the base header length field to determine
     the original payload offset if it requires access to the original
     packet/frame.

!    Next Protocol: Indicates the protocol type of the encapsulated data.
     NSH does not alter the inner payload, and the semantics on the inner
     protocol remain unchanged due to NSH service function chaining.
     Please see IANA Considerations section below.
***************
*** 520,536 ****

                       Figure 3: NSH Service Path Header

!    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 MUST set the appropriate SI value for a given
     classification result.  The initial SI value SHOULD default to 255.
     However, the classifier MUST allow configuration of other SI values.

!    Service Index MUST be decremented 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 in the
--- 519,535 ----

                       Figure 3: NSH Service Path Header

!    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): Indicates the location within the SFP.  The initial
     classifier MUST set the appropriate SI value for a given
     classification result.  The initial SI value SHOULD default to 255.
     However, the classifier MUST allow configuration of other SI values.

!    The Service Index MUST be decremented 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 in the
***************
*** 552,558 ****
  3.4.  NSH MD Type 1

     When the Base Header specifies MD Type = 0x1, four Context Headers,
!    4-byte each, MUST be added immediately following the Service Path

--- 551,557 ----
  3.4.  NSH MD Type 1

     When the Base Header specifies MD Type = 0x1, four Context Headers,
!    4-bytes each, MUST be added immediately following the Service Path

***************
*** 567,573 ****

       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|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Service Path Identifer               | Service Index |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- 566,572 ----

       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|C|R|R|R|R|R|R|   Length  |  MD type = 1  | Next Protocol |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Service Path Identifer               | Service Index |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
***************
*** 590,599 ****

  3.5.  NSH MD Type 2

!    When the base header specifies MD Type= 0x2, zero or more Variable
     Length Context Headers MAY be added, immediately following the
     Service Path Header.  Therefore, Length = 0x2, indicates that only
!    the Base Header followed by the Service Path Header are present.  The
     optional Variable Length Context Headers MUST be of an integer number
     of 4-bytes.  The base header length field MUST be used to determine
     the offset to locate the original packet or frame for SFC nodes that
--- 589,598 ----

  3.5.  NSH MD Type 2

!    When the base header specifies MD Type 2, zero or more Variable
     Length Context Headers MAY be added, immediately following the
     Service Path Header.  Therefore, Length = 0x2, indicates that only
!    the Base Header and the Service Path Header are present.  The
     optional Variable Length Context Headers MUST be of an integer number
     of 4-bytes.  The base header length field MUST be used to determine
     the offset to locate the original packet or frame for SFC nodes that
***************
*** 678,707 ****
       +-+-+-+-+-+-+-+-+

!         Figure 7: Critical Bit Placement Within the TLV Type Field

!    If an NSH-aware node receives an encapsulated packet containing a TLV
!    with the Critical bit set to 0x1 in the Type field and it does not
     understand how to process the Type, it MUST drop the packet.  Transit
!    devices (i.e. network nodes that do not participate in the service
     plane) MUST NOT drop packets based on the setting of this bit.

!    Reserved bit: one reserved bit is present for future use.  The
     reserved bits MUST be set to 0x0.

!    Length: 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.  A value of 0x0 or higher can be used.

!    A value of 0x0 denotes a TLV header without a Variable Metadata
     field.

--- 677,706 ----
       +-+-+-+-+-+-+-+-+

!         Figure 7: Critical Bit Placement Within the Type Field

!    If an NSH-aware node receives an encapsulated packet containing a Context
!    Header with the Critical bit set in the Type field and it does not
     understand how to process the Type, it MUST drop the packet.  Transit
!    devices (i.e., network nodes that do not participate in the service
     plane) MUST NOT drop packets based on the setting of this bit.

!    Reserved bit: One reserved bit is present for future use.  The
     reserved bits MUST be set to 0x0.

!    Length: Length of the variable metadata, in bytes.  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., the actual number of bytes) and
     MUST ignore the remaining bytes up to the nearest 4-byte word
     boundary.  A value of 0x0 or higher can be used.

!    A value of 0x0 denotes a Context Header without a Variable Metadata
     field.

***************
*** 738,747 ****

     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, a SFF, MUST be
         the last node operating on the service header and MUST remove it.

         Multiple logical classifiers may exist within a given service
--- 737,746 ----

     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, an NSH will be imposed.  A
!        service classifier MUST insert an NSH at the start of an SFP.  An
!        imposed NSH MUST contain 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 it.

         Multiple logical classifiers may exist within a given service
***************
*** 797,804 ****

   +---------------+------------------+-------+----------------+---------+
   |                |  Insert         |Select |   Update       |Service  |
!  |                |  or remove NSH  |Service|    NSH         |policy   |
!  |                |                 |Function|               |selection|
   | Component      +--------+--------+Path   +----------------+         |
   |                |        |        |       | Dec.   |Update |         |
   |                | Insert | Remove |       |Service |Context|         |
--- 796,803 ----

   +---------------+------------------+-------+----------------+---------+
   |                |  Insert         |Select |   Update       |Service  |
!  |                |  or remove NSH  |Service|    NSH         |Policy   |
!  |                |                 |Function|               |Selection|
   | Component      +--------+--------+Path   +----------------+         |
   |                |        |        |       | Dec.   |Update |         |
   |                | Insert | Remove |       |Service |Context|         |
***************
*** 843,862 ****

  5.  NSH 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
!    indicated via protocol type or other indicator in the outer
     encapsulation.

--- 842,861 ----

  5.  NSH Encapsulation

!    Once an 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
!        unchanged.

     The service header is independent of the encapsulation used and is
!    encapsulated in existing transports.  The presence of an NSH is
!    indicated via the protocol type or other indicator in the outer
     encapsulation.

***************
*** 899,905 ****

  6.  Fragmentation Considerations

!    NSH and the associated transport header are "added" to the
     encapsulated packet/frame.  This additional information increases the
     size of the packet.  In order to ensure proper forwarding of NSH
     packets, several options for handling fragmentation and re-assembly
--- 898,904 ----

  6.  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.  In order to ensure proper forwarding of NSH
     packets, several options for handling fragmentation and re-assembly
***************
*** 910,916 ****
     carry SFC traffic without requiring fragmentation.

     However, there will be cases where the underlay MTU is not large
!    enough to carry the NSH traffic.  Since NSH does not provide
     fragmentation support at the service plane, the transport/overlay
     layer MUST provide the requisite fragmentation handling.  Section 9
     of [encap-considerations] provides guidance for those scenarios.
--- 909,915 ----
     carry SFC traffic without requiring fragmentation.

     However, there will be cases where the underlay MTU is not large
!    enough to carry the NSH traffic.  Since the NSH does not provide
     fragmentation support at the service plane, the transport/overlay
     layer MUST provide the requisite fragmentation handling.  Section 9
     of [encap-considerations] provides guidance for those scenarios.
***************
*** 957,966 ****

  7.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 provide a level of indirection between the service
     path/topology and the network transport.  Furthermore, there is no
     requirement, or expectation of an SPI being bound to a pre-determined
     or static network path.
--- 956,965 ----

  7.1.  SFFs and Overlay Selection

!    As described above, the 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
     path/topology and the network transport.  Furthermore, there is no
     requirement, or expectation of an SPI being bound to a pre-determined
     or static network path.
***************
*** 973,992 ****
     equivalent.  In the latter case, the SFF provides load distribution
     amongst the collection of SFs as needed.

!    SI can also serve as a mechanism for loop detection within a service
!    path since each SF in the path decrements the index; an Service Index
     of 0 indicates that a loop occurred and the packet must be discarded.

     This indirection -- path ID 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.).  As mentioned above, an existing overlay
     topology may be used provided it offers the 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.  Figure 9 below
--- 972,991 ----
     equivalent.  In the latter case, the SFF provides load distribution
     amongst the collection of SFs as needed.

!    The SI can also serve as a mechanism for loop detection within a service
!    path since each SF in the path decrements the index; a Service Index
     of 0 indicates that a loop occurred and the packet must be discarded.

     This indirection -- path ID 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.).  As mentioned above, an existing overlay
     topology may be used provided it offers the 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.  Figure 9 below
***************
*** 1053,1059 ****
      |  SF34|  198.51.100.34    |  UDP        |
      |  SF9 |  2001:db8::1      |  GRE        |
      +--------------------------+-------------
!     =

--- 1052,1059 ----
      |  SF34|  198.51.100.34    |  UDP        |
      |  SF9 |  2001:db8::1      |  GRE        |
      +--------------------------+-------------
!
!                    Figure 11: SF Locator Mapping Example

***************
*** 1065,1079 ****
  Internet-Draft           Network Service Header           September 2016

-                    Figure 11: SF Locator Mapping Example

     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
     Figure 12.  The metric depicted in Figure 12 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.)

--- 1065,1078 ----
  Internet-Draft           Network Service Header           September 2016

     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
     Figure 12.  The metric depicted in Figure 12 is an example to help
!    illustrate 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.)

***************
*** 1094,1100 ****

!                    Figure 12: NSH Weighted Service Path

  7.2.  Mapping NSH to Network Transport

--- 1093,1099 ----

!                    Figure 12: NSH Weighted Service Path Example

  7.2.  Mapping NSH to Network Transport

***************
*** 1103,1109 ****
     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.

--- 1102,1108 ----
     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.

***************
*** 1159,1165 ****
     collection of service function paths, with the interconnection
     provided by classifiers (in-service path, non-initial re-
     classification).  These internal re-classifiers examine the packet at
!    relevant points in the network, and, if needed, SPI and SI are
     updated (whether this update is a re-write, or the imposition of a
     new NSH with new values is implementation specific) to reflect the
     "result" of the classification.  These classifiers may also of course
--- 1158,1164 ----
     collection of service function paths, with the interconnection
     provided by classifiers (in-service path, non-initial re-
     classification).  These internal re-classifiers examine the packet at
!    relevant points in the network, and, if needed, the SPI and SI are
     updated (whether this update is a re-write, or the imposition of a
     new NSH with new values is implementation specific) to reflect the
     "result" of the classification.  These classifiers may also of course
***************
*** 1200,1206 ****
        header(s).

        Service Functions: A classifier co-resident with Service Functions
!       often perform very detailed and valuable classification.  In some
        cases they may terminate, and be able to inspect encrypted
        traffic.

--- 1199,1205 ----
        header(s).

        Service Functions: A classifier co-resident with Service Functions
!       often performs very detailed and valuable classification.  In some
        cases they may terminate, and be able to inspect encrypted
        traffic.

***************
*** 1209,1217 ****
     example, a network switch, acting as a classifier, might only be able
     to classify based on a 5-tuple, whereas, a service function may be
     able to inspect application information.  Regardless of granularity,
!    the classification information can be represented in NSH.

!    Once the data is added to NSH, it is carried along the service path,
     NSH-aware SFs receive the metadata, and can use that metadata for
     local decisions and policy enforcement.  The following two examples
     highlight the relationship between metadata and policy:
--- 1208,1216 ----
     example, a network switch, acting as a classifier, might only be able
     to classify based on a 5-tuple, whereas, a service function may be
     able to inspect application information.  Regardless of granularity,
!    the classification information can be represented in the NSH.

!    Once the data is added to the NSH, it is carried along the service path,
     NSH-aware SFs receive the metadata, and can use that metadata for
     local decisions and policy enforcement.  The following two examples
     highlight the relationship between metadata and policy:
***************
*** 1234,1244 ****

      +-------+        +-------+        +-------+
!     |  SFF  )------->(  SFF  |------->|  SFF  |
      +---^---+        +---|---+        +---|---+
        ,-|-.            ,-|-.            ,-|-.
       /     \          /     \          /     \
!     ( Class )           SF1  )        (  SF2  )
       \ ify /          \     /          \     /
        `---'            `---'            `---'
       5-tuple:        Permit             Inspect
--- 1233,1243 ----

      +-------+        +-------+        +-------+
!     |  SFF  |------->|  SFF  |------->|  SFF  |
      +---^---+        +---|---+        +---|---+
        ,-|-.            ,-|-.            ,-|-.
       /     \          /     \          /     \
!     ( Class )        (  SF1  )        (  SF2  )
       \ ify /          \     /          \     /
        `---'            `---'            `---'
       5-tuple:        Permit             Inspect
***************
*** 1280,1286 ****
     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

--- 1279,1285 ----
     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

***************
*** 1299,1305 ****
     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 15.  For example, if the initial
         classification returns the tenant information, a secondary
         classification (perhaps co-resident with DPI or SLB) may augment
--- 1298,1304 ----
     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 an NSH's existing
         metadata, as depicted in Figure 15.  For example, if the initial
         classification returns the tenant information, a secondary
         classification (perhaps co-resident with DPI or SLB) may augment
***************
*** 1321,1333 ****
          +-----+           +-----+            +-----+
          | SFF |---------> | SFF |----------> | SFF |
          +--+--+           +--+--+            +--+--+
!           ^                 |                  |
!          ,---.             ,---.              ,---.
          /     \           /     \            /     \
         ( Class )         (  SF1  )          (  SF2  )
          \     /           \     /            \     /
           `-+-'             `---'              `---'
!           |              Inspect           Deny
         +---+---+          employees         employee+
         |       |          Class=AppZ        appZ
         +-------+
--- 1320,1332 ----
          +-----+           +-----+            +-----+
          | SFF |---------> | SFF |----------> | SFF |
          +--+--+           +--+--+            +--+--+
!            ^                 |                  |
!          ,-|-.             ,---.              ,---.
          /     \           /     \            /     \
         ( Class )         (  SF1  )          (  SF2  )
          \     /           \     /            \     /
           `-+-'             `---'              `---'
!            |              Inspect           Deny
         +---+---+          employees         employee+
         |       |          Class=AppZ        appZ
         +-------+
***************
*** 1349,1355 ****
         | SFF |---------> | SFF |----------> | SFF |
         +--+--+           +--+--+            +--+--+
            ^                 |                  |
!         ,---.             ,---.              ,---.
         /     \           /     \            /     \
        ( Class )         (  SF1  )          (  SF2  )
         \     /           \     /            \     /
--- 1348,1354 ----
         | SFF |---------> | SFF |----------> | SFF |
         +--+--+           +--+--+            +--+--+
            ^                 |                  |
!         ,-|-.             ,---.              ,---.
         /     \           /     \            /     \
        ( Class )         (  SF1  )          (  SF2  )
         \     /           \     /            \     /
***************
*** 1408,1414 ****
          ,---.             ,---.       |      ,---.
         /     \           / SF1 \      |     /     \
        (  SCL  )         (   +   )     |    (  SF2  )
!        \     /           \SCL2 /      |     \     /
          `---'             `---'    +-----+   `---'
       5-tuple:            Inspect   | SFF |    Original
       Tenant A            Tenant A  +--+--+    next SF
--- 1407,1413 ----
          ,---.             ,---.       |      ,---.
         /     \           / SF1 \      |     /     \
        (  SCL  )         (   +   )     |    (  SF2  )
!        \     /           \ SCL2/      |     \     /
          `---'             `---'    +-----+   `---'
       5-tuple:            Inspect   | SFF |    Original
       Tenant A            Tenant A  +--+--+    next SF
***************
*** 1467,1477 ****
     there, far fewer protection mechanisms are needed in these
     environments, which are the primary design target of NSH.

!    NSH is always encapsulated in a transport protocol and therefore,
     when required, existing security protocols that provide authenticity
!    (e.g. [ [RFC6071]) can be used between SFF or even to SF.  Similarly
     if confidentiality is required, existing encryption protocols can be
!    used in conjunction with encapsulated NSH.

     Further, existing best practices, such as [RFC2827] should be
     deployed at the network layer to ensure that traffic entering the
--- 1466,1476 ----
     there, far fewer protection mechanisms are needed in these
     environments, which are the primary design target of NSH.

!    The NSH is always encapsulated in a transport protocol and therefore,
     when required, existing security protocols that provide authenticity
!    (e.g., [RFC6071]) can be used between an SFF or even to an SF.  Similarly
     if confidentiality is required, existing encryption protocols can be
!    used in conjunction with an encapsulated NSH.

     Further, existing best practices, such as [RFC2827] should be
     deployed at the network layer to ensure that traffic entering the
***************
*** 1480,1486 ****

     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
--- 1479,1485 ----

     NSH metadata authenticity and confidentiality must be considered as
     well.  In order to protect the metadata, an operator can leverage the
!    aforementioned mechanisms if the transport layer provides 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
***************
*** 1493,1504 ****
     Further, the extensibility of MD Type 2 to add information to
     packets, and where needed to mark that data as critical, allows for
     attaching signatures or even encryption keying information to the NSH
!    header in the future.  Based on the learnings from the work on [nsh-
!    sec], it appears likely that this can provide any needed NSH-specific
!    security mechanisms in the future.

     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.

     Further security considerations are discussed in [nsh-sec].
--- 1492,1502 ----
     Further, the extensibility of MD Type 2 to add information to
     packets, and where needed to mark that data as critical, allows for
     attaching signatures or even encryption keying information to the NSH
!    header in the future.  It appears likely that  the security mechanisms
!    specified in [nsh-sec] can satisfy future NSH-specific requirements.

     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.

Thanks,
Acee