Subject: [sfc] RtgDir QA review: draft-ietf-sfc-nsh-10.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 20 Dec 2016 17:25:23 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. 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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Dec 2016 13:07:47 -0500

Acee,

Thank you very much for your review.  I'm certain that the authors,
shepherd & WG will engage with you in improving the draft.

Regards,
Alia

On Tue, Dec 20, 2016 at 12:25 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review. The purpose of
> the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see ​
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> I have some 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.
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Dec 2016 14:09:26 -0500

I am a bit confused by the two major issues.

Regarding the first major issue, the document is pretty clear that the 
MD-1 content is to be defined in other documents.  Is there a reason you 
consider this a major issue?

On the second issue, is the problem that the figures are not as helpful 
as you would like, or that some other aspect of the section is seriously 
unclear?

Yours,
Joel

On 12/20/16 12:25 PM, Acee Lindem (acee) wrote:
> 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
> 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
> 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.
> somewhat from the description of service function graphs in section 2.1
> of RFC 7665.
>
> Minor Issues:
>
> 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.
> 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).
> 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.
> proxy. This document uses several terms including "non-NSH-aware" and
> "NSH unaware". I'd recommend consistency with RFC 7665 or, at least,
> *** draft-ietf-sfc-nsh-10.txt.orig2016-12-20 11:33:21.000000000 -0500
> --- draft-ietf-sfc-nsh-10.txt2016-12-20 12:09:49.000000000 -0500
> ***************
> *** 241,252 ****

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 20 Dec 2016 20:16:00 +0000

Hi Joel, 

Are you speaking as WG chair or as a contributor?

>consider this a major issue?

It wasn’t clear to me. Having said that, why would the primary SFC
protocol encoding document have mandatory fields that are defined in other
documents?  

>as you would like, or that some other aspect of the section is seriously

The problem is that the reader is to infer both the meaning of the
respective icons and the labels. After reading RFC 7665, I believe I have
some idea of what the examples are suppose to convey. However, I can’t be
sure and I don’t think the document should require the this level of
experience implementing network products. I fully expected the examples to
be explained. 

Thanks,
Acee 

>>as

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 20 Dec 2016 14:56:00 -0600

Hi Acee,

My comment is that
this document is still a WG document, no WG last call has been issued
to my knowledge, is it the right time to do external reviews for such
a document?

I think that the structure of metadata definitions is expected to go
through some changes.

Regards,

Behcet

On Tue, Dec 20, 2016 at 2:16 PM, Acee Lindem (acee) <[email-masked]> wrote:
>>> information about the Routing Directorate, please see

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Dec 2016 16:00:57 -0500

Hi Behcet,

Absolutely, it is a good time to do an external review and get feedback
earlier in the process.
In this case, I asked for a Routing Directorate review with the assumption
that the draft, which was
past WGLC, would shortly be in my publication queue.  That isn't the case
yet, but the review is
quite helpful anyway.

About 2.5 years ago, I and Adrian wrote up the WG Draft Quality Assurance
process for requesting
early Routing Directorate reviews.  Please see
https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa .
The intent of this is to get external reviews early enough that issues can
be identified and
corrected.  A goal is to avoid late surprises of serious technical issues
and avoid only being able
to add explanatory text instead of fixing the technical problem.

Regards,
Alia

On Tue, Dec 20, 2016 at 3:56 PM, Behcet Sarikaya <[email-masked]>
wrote:

> >>>   9) In section 7.2, the order of the costs and next-hop in the
> examples
> >>> is inconsistent.
> >>>
> >>> Nits:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Dec 2016 16:12:34 -0500

At least thus far, I am speaking as a participant involved in these 
documents.  If necessary, I am willing to put on my chair hat, as I 
consider these also to be questions that are reasonable for a chair to ask.

In line below.
Joel

> protocol encoding document have mandatory fields that are defined in other

The approach we are taking to the MD-1 content is that different 
environments will need to carry different information in the metadata. 
Therefore, configuration or control mechanisms need to provide the 
content semantics.  And other drafts can define possible contents.

If you can point to where the document should be clearer about this, 
that would be helpful.

> experience implementing network products. I fully expected the examples to

I agree that the document should be clear.  So I will leave it to others 
to judge whether this description is enough more clear to be actionable.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Dec 2016 16:14:37 -0500

Just to confirm as chair:
1) External reviews, and any other sources of review, are appreciated 
whenever they arrive.  While care must be taken in reviewing documents 
in flux, that is not applicable to this case.
2) The document has actually completed WG last call (before I became 
co-chair.)  There are ongoing issue discussions even though the last 
call is complete.  So again, review is appreciated.

Yours,
Joel

---

From: Jim Guichard <[email-masked]>
Date: Tue, 20 Dec 2016 16:39:49 -0500

Hi Acee,

Thank you for your review.

For the first major issue you provided we have addressed it with some new
text that will be added to the next version of the draft. Please see
https://trac.ietf.org/trac/sfc/ticket/21

Jim

On Tue, Dec 20, 2016 at 12:25 PM Acee Lindem (acee) <[email-masked]> wrote:

> the review is
> to provide assistance to the Routing ADs. For more information about the
> Routing Directorate, please see ​http://trac.tools.ietf.org/ar
> ea/rtg/trac/wiki/RtgDir
>
>
>
>
>
>
>
> discussion or by
> updating the draft.
> 7.1, NSH refers
> to the actual header. This is very confusing.
>
>
> bits (0-127).
> Finally, you should not refer to context headers as TLVs as they are not
> the format of a classic TLV.
>
>
> *** 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 ****
>
>

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 21 Dec 2016 09:01:49 +0000

A few words to agree with Acee’s routing directorate review on the first major issue he points out.
(fwiw I made exactly same remark when I went through an earlier version of the document 6 months ago. I do recommend the SFC chairs to take this major comment into serious consideration and not handwave away the real problem. It pop’d up multiple times, and it will become the Achilles heel of the NSH standard)

The aspect of defining MD1 with mandatory 16 octets AND the apparently intentional lack of specifying the 16-byte context structure has been part of discussions many time.
It was decided before my time (+6 months ago) that out-of-band mechanisms should be used for context structure signalling for MD1 should be used, instead
of using few bits within the MD1 header itself. The problem with this is that the MD1 is not very meaningful as the context is not inside the packet header, and hence the solution needs i.e. some degree of
orchestration of context distribution when different service domains are involved. It really is operationally complex and non-trivial orchestration process and has potential for many problems for interoperability due to under specification.

It looks that there is significant number of people finding that the MD1 specification is broken, and also consider this as a major flaw in the NSH specification. The text from Lucy takes away some concern on
documenting the context definition glitch of MD1, however I still believe that as Working group it is a poor work around to solve the real problem of MD1 under-specification.
In current specification, MD1 is intended as carrier of an opaque entity of 16 octets context data. How the 16 octets are constructed is up to the user of the MD1.
If something is in base document specified as opaque, then why specifying it in other standard documents with focus upon MD1? It makes little sense and is very confusing to consumers of NSH packets. We should just leave it as being Opaque 16 octets and for vendor/operator specific purposes, so that there is no interop concern at all.

That being said, it does make more sense to specify 16 octets for MD2 and at the same time propose a context type number to go along with it and just keep MD1 opaque and up to vendor to use, without any add on or extra documents making efforts trying to specify those 16 octets. (but re-publish those add-on/extra documents as MD2 context type constructs instead).

Looking at this discussion again, maybe SFC chairs can perform the brave act of putting on their chair-hats, look at the MD1 issue in greater detail. The goal being to address the architectural complications embodied in current SFC NSH-10 proposal.

G/

From: sfc <[email-masked]> on behalf of Jim Guichard <[email-masked]>
Date: Tuesday, 20 December 2016 at 22:39
To: "Acee Lindem (acee)" <[email-masked]>, Routing ADs <[email-masked]>
Cc: Routing Directorate <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] RtgDir QA review: draft-ietf-sfc-nsh-10.txt

Hi Acee,

For the first major issue you provided we have addressed it with some new text that will be added to the next version of the draft. Please see https://trac.ietf.org/trac/sfc/ticket/21

Jim

On Tue, Dec 20, 2016 at 12:25 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. 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.

Reviewer: Acee Lindem

IETF LC End Date: N/A

Summary:

Comments:

Refer to other sections.

Major Issues:

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

  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.

Nits:

***************

*** 241,252 ****

--- 241,252 ----

***************

*** 345,351 ****

--- 345,351 ----

***************

*** 370,379 ****

     payload protocol.

     a service path.

     path.

  3.2.  NSH Base Header

--- 370,379 ----

     payload protocol.

     a service path.

     path.

  3.2.  NSH Base Header

***************

*** 412,418 ****

--- 412,418 ----

***************

*** 420,426 ****

     modified along the SFP.

--- 420,426 ----

     modified along the SFP.

***************

*** 429,446 ****

--- 429,445 ----

***************

*** 449,482 ****

     below.

     information.

     packet/frame.

--- 448,481 ----

!

     below.

     information.

     packet/frame.

***************

*** 520,536 ****

--- 519,535 ----

***************

*** 552,558 ****

  3.4.  NSH MD Type 1

--- 551,557 ----

  3.4.  NSH MD Type 1

***************

*** 567,573 ****

--- 566,572 ----

***************

*** 590,599 ****

  3.5.  NSH MD Type 2

--- 589,598 ----

  3.5.  NSH MD Type 2

***************

*** 678,707 ****

       +-+-+-+-+-+-+-+-+

     field.

--- 677,706 ----

       +-+-+-+-+-+-+-+-+

     field.

***************

*** 738,747 ****

--- 737,746 ----

***************

*** 797,804 ****

--- 796,803 ----

***************

*** 843,862 ****

  5.  NSH Encapsulation

!        is.

     encapsulation.

--- 842,861 ----

  5.  NSH Encapsulation

!        unchanged.

     encapsulation.

***************

*** 899,905 ****

--- 898,904 ----

***************

*** 910,916 ****

--- 909,915 ----

***************

*** 957,966 ****

     or static network path.

--- 956,965 ----

     or static network path.

***************

*** 973,992 ****

--- 972,991 ----

***************

*** 1053,1059 ****

!     =

--- 1052,1059 ----

!

***************

*** 1065,1079 ****

--- 1065,1078 ----

***************

*** 1094,1100 ****

--- 1093,1099 ----

***************

*** 1103,1109 ****

     are satisfied.

--- 1102,1108 ----

     are satisfied.

***************

*** 1159,1165 ****

--- 1158,1164 ----

***************

*** 1200,1206 ****

        header(s).

        traffic.

--- 1199,1205 ----

        header(s).

        traffic.

***************

*** 1209,1217 ****

--- 1208,1216 ----

***************

*** 1234,1244 ****

        ,-|-.            ,-|-.            ,-|-.

       /     \          /     \          /     \

       \ ify /          \     /          \     /

        `---'            `---'            `---'

       5-tuple:        Permit             Inspect

--- 1233,1243 ----

        ,-|-.            ,-|-.            ,-|-.

       /     \          /     \          /     \

       \ ify /          \     /          \     /

        `---'            `---'            `---'

       5-tuple:        Permit             Inspect

***************

*** 1280,1286 ****

--- 1279,1285 ----

***************

*** 1299,1305 ****

--- 1298,1304 ----

***************

*** 1321,1333 ****

          +-----+           +-----+            +-----+

          +--+--+           +--+--+            +--+--+

!           ^                 |                  |

!          ,---.             ,---.              ,---.

          /     \           /     \            /     \

          \     /           \     /            \     /

           `-+-'             `---'              `---'

!           |              Inspect           Deny

         |       |          Class=AppZ        appZ

         +-------+

--- 1320,1332 ----

          +-----+           +-----+            +-----+

          +--+--+           +--+--+            +--+--+

!            ^                 |                  |

!          ,-|-.             ,---.              ,---.

          /     \           /     \            /     \

          \     /           \     /            \     /

           `-+-'             `---'              `---'

!            |              Inspect           Deny

         |       |          Class=AppZ        appZ

         +-------+

***************

*** 1349,1355 ****

         +--+--+           +--+--+            +--+--+

            ^                 |                  |

!         ,---.             ,---.              ,---.

         /     \           /     \            /     \

         \     /           \     /            \     /

--- 1348,1354 ----

         +--+--+           +--+--+            +--+--+

            ^                 |                  |

!         ,-|-.             ,---.              ,---.

         /     \           /     \            /     \

         \     /           \     /            \     /

***************

*** 1408,1414 ****

          ,---.             ,---.       |      ,---.

         /     \           / SF1 \      |     /     \

        (  SCL  )         (   +   )     |    (  SF2  )

!        \     /           \SCL2 /      |     \     /

--- 1407,1413 ----

          ,---.             ,---.       |      ,---.

         /     \           / SF1 \      |     /     \

        (  SCL  )         (   +   )     |    (  SF2  )

!        \     /           \ SCL2/      |     \     /

***************

*** 1467,1477 ****

--- 1466,1476 ----

***************

*** 1480,1486 ****

--- 1479,1485 ----

***************

*** 1493,1504 ****

     update NSH metadata.

--- 1492,1502 ----

     update NSH metadata.

Thanks,

Acee

sfc mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 22 Dec 2016 14:31:03 +0000

Hi Acee,

Thank you for the review.  Some replies/comments below.

Paul

On Dec 20, 2016, at 12:25 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Summary:

Comments:
Refer to other sections.

Major Issues:

NSH simply defines the "envelop" for MD-1.  There is not mandatory semantics for the metadata, nor should there be.  Rather, a control plane conveys that requisite information to participating nodes.  This allows NSH to be "simple" (i.e. fixed length), as well as "flexible" (i.e. depending on environment you can carry what's needed in this envelop).  The reliance on a control plane to signal the meaning of metadata is documents (perhaps not clearly enough) in the draft.

I'll review section 8 in the context of section 2.1 and ensure that they are sync.  As to your first point: in general, those figures seem to be helpful to the reader and help explain usage.  Can you please help me understand what you think is missing?

Minor Issues:

I re-read both sections and I'm not sure what the confusion is, perhaps it is that NSH is often user as a protocol ("NSH enables service chaining per [RFC7665].") and as a header ("NSH contains a Service Path Identifier (SPI)"). Is that double-use the issue?

I defer to the chairs here but I believe this was considered.

Thank you.

Thank you, I'll clean that up.

They contain the 3 elements of a TLV: type, length and value, although they are scoped by class so in effect they are TLVs, with an other descriptor.  The title of the section was updated along the way to reflect that: "Variable Length Metadata". Once with the scope of a class, I think it's correct to call it a TLV.

Thank you, will clean that up.

Will do.

Can you please elaborate?

Nits:

I'll go through the nits as I updated the draft.

Thanks again and happy holidays!
Paul

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Dec 2016 19:22:27 +0000

Hi Jim.
This is better. In this context, where is the term “allocation schema” defined? Also, could tense and grammatical errors in the suggested text be correct? Finally, how did you arrive at exactly 16 octets of mandatory context headers when the content are undefined? Did this just seem like a useful amount for a standard meta data type? Perhaps, the decision could be discussed and how to handle applications where this is less (it is either zero’ed or the allocation schema must specify the contents of all 16 octets).
Thanks,
Acee

From: Jim Guichard <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 20, 2016 at 4:39 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Routing ADs <[email-masked]<mailto:[email-masked]>>
Cc: Routing Directorate <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] RtgDir QA review: draft-ietf-sfc-nsh-10.txt

Hi Acee,

Jim

Hello,

updating the draft.

Reviewer: Acee Lindem

IETF LC End Date: N/A

Summary:

Comments:

Refer to other sections.

Major Issues:

Minor Issues:

Nits:

***************

*** 241,252 ****

--- 241,252 ----

***************

*** 345,351 ****

--- 345,351 ----

***************

*** 370,379 ****

     payload protocol.

     a service path.

     path.

  3.2.  NSH Base Header

--- 370,379 ----

     payload protocol.

     a service path.

     path.

  3.2.  NSH Base Header

***************

*** 412,418 ****

--- 412,418 ----

***************

*** 420,426 ****

     modified along the SFP.

--- 420,426 ----

     modified along the SFP.

***************

*** 429,446 ****

--- 429,445 ----

***************

*** 449,482 ****

     below.

     information.

     packet/frame.

--- 448,481 ----

!

     below.

     information.

     packet/frame.

***************

*** 520,536 ****

--- 519,535 ----

***************

*** 552,558 ****

  3.4.  NSH MD Type 1

--- 551,557 ----

  3.4.  NSH MD Type 1

***************

*** 567,573 ****

--- 566,572 ----

***************

*** 590,599 ****

  3.5.  NSH MD Type 2

--- 589,598 ----

  3.5.  NSH MD Type 2

***************

*** 678,707 ****

       +-+-+-+-+-+-+-+-+

     field.

--- 677,706 ----

       +-+-+-+-+-+-+-+-+

     field.

***************

*** 738,747 ****

--- 737,746 ----

***************

*** 797,804 ****

--- 796,803 ----

***************

*** 843,862 ****

  5.  NSH Encapsulation

!        is.

     encapsulation.

--- 842,861 ----

  5.  NSH Encapsulation

!        unchanged.

     encapsulation.

***************

*** 899,905 ****

--- 898,904 ----

***************

*** 910,916 ****

--- 909,915 ----

***************

*** 957,966 ****

     or static network path.

--- 956,965 ----

     or static network path.

***************

*** 973,992 ****

--- 972,991 ----

***************

*** 1053,1059 ****

!     =

--- 1052,1059 ----

!

***************

*** 1065,1079 ****

--- 1065,1078 ----

***************

*** 1094,1100 ****

--- 1093,1099 ----

***************

*** 1103,1109 ****

     are satisfied.

--- 1102,1108 ----

     are satisfied.

***************

*** 1159,1165 ****

--- 1158,1164 ----

***************

*** 1200,1206 ****

        header(s).

        traffic.

--- 1199,1205 ----

        header(s).

        traffic.

***************

*** 1209,1217 ****

--- 1208,1216 ----

***************

*** 1234,1244 ****

        ,-|-.            ,-|-.            ,-|-.

       /     \          /     \          /     \

       \ ify /          \     /          \     /

        `---'            `---'            `---'

       5-tuple:        Permit             Inspect

--- 1233,1243 ----

        ,-|-.            ,-|-.            ,-|-.

       /     \          /     \          /     \

       \ ify /          \     /          \     /

        `---'            `---'            `---'

       5-tuple:        Permit             Inspect

***************

*** 1280,1286 ****

--- 1279,1285 ----

***************

*** 1299,1305 ****

--- 1298,1304 ----

***************

*** 1321,1333 ****

          +-----+           +-----+            +-----+

          +--+--+           +--+--+            +--+--+

!           ^                 |                  |

!          ,---.             ,---.              ,---.

          /     \           /     \            /     \

          \     /           \     /            \     /

           `-+-'             `---'              `---'

!           |              Inspect           Deny

         |       |          Class=AppZ        appZ

         +-------+

--- 1320,1332 ----

          +-----+           +-----+            +-----+

          +--+--+           +--+--+            +--+--+

!            ^                 |                  |

!          ,-|-.             ,---.              ,---.

          /     \           /     \            /     \

          \     /           \     /            \     /

           `-+-'             `---'              `---'

!            |              Inspect           Deny

         |       |          Class=AppZ        appZ

         +-------+

***************

*** 1349,1355 ****

         +--+--+           +--+--+            +--+--+

            ^                 |                  |

!         ,---.             ,---.              ,---.

         /     \           /     \            /     \

         \     /           \     /            \     /

--- 1348,1354 ----

         +--+--+           +--+--+            +--+--+

            ^                 |                  |

!         ,-|-.             ,---.              ,---.

         /     \           /     \            /     \

         \     /           \     /            \     /

***************

*** 1408,1414 ****

          ,---.             ,---.       |      ,---.

         /     \           / SF1 \      |     /     \

        (  SCL  )         (   +   )     |    (  SF2  )

!        \     /           \SCL2 /      |     \     /

--- 1407,1413 ----

          ,---.             ,---.       |      ,---.

         /     \           / SF1 \      |     /     \

        (  SCL  )         (   +   )     |    (  SF2  )

!        \     /           \ SCL2/      |     \     /

***************

*** 1467,1477 ****

--- 1466,1476 ----

***************

*** 1480,1486 ****

--- 1479,1485 ----

***************

*** 1493,1504 ****

     update NSH metadata.

--- 1492,1502 ----

     update NSH metadata.

Thanks,

Acee

sfc mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 23 Dec 2016 16:43:53 +0000

Hi Paul,

From: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 22, 2016 at 9:31 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Routing ADs <[email-masked]<mailto:[email-masked]>>, Routing Directorate <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: RtgDir QA review: draft-ietf-sfc-nsh-10.txt

Hi Acee,

Paul

Hello,

Summary:

Comments:
Refer to other sections.

Major Issues:

There is some text in the tracker to remedy the clarification: https://trac.ietf.org/trac/sfc/ticket/21 I think this is along the lines of what is needed. Here was my response to Jim Guichard.

An Explanation of the SFC examples, SF by SF rather than assuming that they stand on their own. I believe I can infer what they are conveying but I can’t be sure and would not expect the my level of understanding for general IETF target audience. Fewer examples that are explained are better than more that are left to the readers imagination.

Minor Issues:

Yes – NSH is used interchangeably. In fact, I think the draft should be titled “NSH Encapsulation and Protocol Processing” or something similar rather than simply “NSH”. In my nits, I tried to preceded the “NSH” with an article (e.g., “an” or “the”)  when it was being used as the header itself and did not add an article when it was being used as the generic capability.

Ok – I just noticed there were more reserved bits that could have be devoted to the version field and wondered why the WG chose to limit the values to 0, 2, or 3.

Thank you.

They contain the 3 elements of a TLV: type, length and value, although they are scoped by class so in effect they are TLVs, with an other descriptor.

The title of the section was updated along the way to reflect that: "Variable Length Metadata". Once with the scope of a class, I think it's correct to call it a TLV.

I would still disagree as you can't use standard 1 or 2 byte TLV logic to parse them. For example, RFC 3630 uses standard TLV encoding with padding to 32-bit word boundaries. However, I don’t feel that strongly on this minor issue.

Will do.

I mean in one case the costs is paired with each next-hop and in the other the term “equal-cost” follows all the next-hops. I probably should have included this in the Nits.

Nits:

Thanks and you have a great holiday as well!

Acee