Re: [sfc] I-D Action: draft-ietf-sfc-nsh-13.txt

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Med,

Thank you for the most comprehensive review and detailed set of comments on rev -13.

The key take-away from such a thorough review for me is that, given the fact that all of these comments are editorial in nature and most are nits, the document is mature, stable, and great quality. Even better quality now after applying fixes to all of these.

Please see inline for item-by-item details and disposition.

> On Jul 5, 2017, at 5:30 AM, [e-mail] wrote:
> 
> Hi Joel, all, 
> 
> The document is almost stable. Below my review of the version:
> 
> Major: 
> 
> (1) Indicate that the spec does not assume nor preclude the MD type can changed on path. For example, this can be added as follows:
> 
> NEW:
>   NSH implementations MUST support MD type =  0x1 and MD Type 0x2 (where
>   the length is of value 0x2).  NSH implementations SHOULD support MD
>   Type 0x2 with length > 0x2.  There exists, however, a middle ground,
>   wherein a device will support MD Type 0x1 (as per the MUST) metadata,
>   yet be deployed in a network with MD Type 0x2 metadata packets.  In
>   that case, the MD Type 0x1 node, MUST utilize the base header length
>   field to determine the original payload offset if it requires access
>   to the original packet/frame. 
> 
> OLD:
>   NSH implementations MUST support MD type 0x1 and MD Type 0x2 (where
>   the length is of value 0x2).  NSH implementations SHOULD support MD
>   Type 0x2 with length > 0x2.  There exists, however, a middle ground,
>   wherein a device will support MD Type 0x1 (as per the MUST) metadata,
>   yet be deployed in a network with MD Type 0x2 metadata packets.  In
>   that case, the MD Type 0x1 node, MUST utilize the base header length
>   field to determine the original payload offset if it requires access
>   to the original packet/frame. This specification does not assume nor
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   preclude that the same MD Type is maintained or changed along
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>   a service path; it is deployment-specific.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I understand the syntax of the change you are proposing but I do not understand the rationale for it (i.e., what is the driver for this change?).

When an application, deployment, or use case wants to concern itself with “MD Type interworking/translation”, then such text can be written but with the added specifics of that use case.

In my view, the text as-is is at the right specification level. The proposed text above does not add value — it is trying to over specify when there’s no need.

> 
> (2) The IANA section is not aligned with the core text with regards to assigned MD type values:
> 
> OLD:
> 
>   This document defines two MD Type values:
> 
>   0x1 - which indicates that the format of the header includes a fixed
>   length Context Header (see Figure 4 below).
> 
>   0x2 - which does not mandate any headers beyond the Base Header and
>   Service Path Header, but may contain optional variable length Context
>   Header(s).  The semantics of the variable length Context Header(s)
>   are not defined in this document
> 
> The text should be updated to refer to these experimental values: 15 (Experiment 1) and 16 (Experiment 2).
> Some words about the usage of those values would be appropriate, too. 

Agreed. Very good catch.

In fact, it should also talk about 0x0 Reserved.

Change accepted and made in the working copy. If you have specific words about the usage, please share on the list.

Please note that this uncovered another bug: MD Type 16 defined for a 4-bit field. I am proposing the removal of 16, one experimental seems enough.

Here’s the change:

-   This document defines two MD Type values:
+   This document specifies the following five MD Type values:
+
+   0x0 - this is a reserved value.  Implementations SHOULD silently
+   discard packets with MD Type 0.
 
    0x1 - which indicates that the format of the header includes a fixed
    length Context Header (see Figure 4 below).
@@ -472,6 +412,10 @@
    Header(s).  The semantics of the variable length Context Header(s)
    are not defined in this document
 
+   0xF - this value is reserved for experimentation and testing, as per
+   [RFC3692].  Implementations not explicitly configured to be part of
+   an experiment SHOULD silently discard packets with MD Type 15.
+
    The format of the Base Header and the Service Path Header is
    invariant, and not affected by MD Type.
 
    IANA is requested to set up a registry of "MD Types".  These are
    4-bit values.  MD Type values 0, 1, 2, 15, and 16 are specified in
    this document.  Registry entries are assigned by using the "IETF
-   Review" policy defined in RFC 5226 [RFC5226].
+   Review" policy defined in RFC 8126 [RFC8126].
 
-                +---------+--------------+---------------+
+               +---------+-----------------+---------------+
                 | MD Type | Description  | Reference     |
-                +---------+--------------+---------------+
+               +---------+-----------------+---------------+
                 | 0       | Reserved     | This document |
                 |         |              |               |
-                | 1       | NSH          | This document |
+               | 1       | NSH MD Type 1   | This document |
                 |         |              |               |
-                | 2       | NSH          | This document |
+               | 2       | NSH MD Type 2   | This document |
                 |         |              |               |
                 | 3..14   | Unassigned   |               |
                 |         |              |               |
-                | 15      | Experiment 1 | This document |
-                |         |              |               |
-                | 16      | Experiment 2 | This document |
-                +---------+--------------+---------------+
+               | 15      | Experimentation | This document |
+               +---------+-----------------+---------------+
 
                                   Table 1
 


> 
> (3) The IANA section is not aligned with the core text with regards to assigned Next Protocol values:
> 
> OLD: 
>   This document defines the following Next Protocol values:
> 
>   0x1: IPv4
>   0x2: IPv6
>   0x3: Ethernet
>   0x4: NSH
>   0x5: MPLS
> 
> NEW: 
>   0x1: IPv4
>   0x2: IPv6
>   0x3: Ethernet
>   0x4: NSH
>   0x5: MPLS
>   0xFE: Experiment 1
>   0xFF: Experiment 2
> 
> Further, the document does not include some text about the use of 254/255 values.     
> 


Similarly, agreed. Change made. Proposed text:

   This document defines the following Next Protocol values:

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   An implementation not explicitly configured for a specific experiment
   [RFC3692] SHOULD NOT attempt to process Next Protocol values 254 and
   255.



> (4) The document states the following:
> 
> OLD:
> 12.1.  NSH EtherType
> 
>   An IEEE EtherType, 0x894F, has been allocated for NSH.
> 
> But no entry is found at https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml! 
> 
> Unless I'm mistaken, an action is needed form IANA. Thus, I suggest the following NEW text: 
> 
> NEW: 
> 12.1.  NSH EtherType
> 
>   IANA is requested to register the IEEE EtherType, 0x894F, for NSH in https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml.
> 

Before making this change, let’s figure out exactly the current status and fate of that registration.

> ==
> Minor: 
> ==
> 
> * Title: I suggest this modification
> OLD: Network Service Header 
> NEW: Network Service Header (NSH)
> 

OK.

> * Abstract: 
> 
> OLD: 
>   This document describes a Network Service Header (NSH) inserted onto
>   packets or frames to realize service function paths.  NSH also
>   provides a mechanism for metadata exchange along the instantiated
>   service path.  NSH is the SFC encapsulation required to support the
>   Service Function Chaining (SFC) Architecture (defined in RFC7665).
> NEW:
>   This document describes a Network Service Header (NSH) inserted onto
>   packets or frames to realize service function paths.  NSH also
>   provides a mechanism for metadata exchange along the instantiated
>   service paths.  NSH is the SFC encapsulation required to support the
>               ^^
>   Service Function Chaining (SFC) architecture (defined in RFC7665).
>                                  ^^
> 

Done.

> * Introduction:
> 
> (1)
> 
> OLD: 
>   Service functions are widely deployed and essential in many networks.
>   These service functions provide a range of features such as security,
>   WAN acceleration, and server load balancing.  Service functions may
>   be instantiated at different points in the network infrastructure
>   such as the wide area network, data center, campus, and so forth.
> 
> NEW:
>   Service functions are widely deployed and essential in many networks.
>   These service functions provide a range of features such as security,
>   WAN (Wide Area Network) acceleration (REF), and server load balancing.  Service functions may
>   be instantiated at different points in the network infrastructure
>   such as the wide area network [I-D.ietf-sfc-use-case-mobility], 
>   data center [I-D.ietf-sfc-dc-use-cases], campus, and so forth.
> 
> - expand an acronym

No. WAN is “well know” as per https://www.rfc-editor.org/materials/abbrev.expansion.txt 

> - cite the use case drafts to illustrate the use of SFs

Which ones specifically?

> - Given that WAN acceleration may not be that clear, citing a reference where this is defined will be helpful.
> 

It should be clear. No change. Otherwise, do you have a citation in mind.

> (2) Expand an acronym on first use: 
> 
> OLD:
>   NSH defines a new service plane protocol specifically for the
>   creation of dynamic service chains and is composed of the following
>   elements:
> 
>   1.  Service Function Path identification
> 
> NEW:
>   Network Service Header (NSH) defines a new service plane protocol specifically for the
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Done.

>   creation of dynamic service chains and is composed of the following
>   elements:
> 
>   1.  Service Function Path identification.
>                                           ^^
> 

Done.

> *  Section 2.1
> 
> (1)
> 
> OLD:
>   Network Locator:  dataplane address, typically IPv4 or IPv6, used to
>      send and receive network traffic.
> 
> NEW:
>   Network Locator:  dataplane address, typically IPv4 or IPv6, used to
>      send and receive traffic.
> 
> - Not sure what is meant by "network traffic”

Traffic from and to the network?

> 
> (2)
> 
> OLD:
>   Network Node/Element:  Device that forwards packets or frames based
>      on outer header (i.e. transport) information.
> 
> NEW:
>   Network Node/Element:  Device that forwards packets or frames based
>      on the outer header (i.e., transport) information.
>         ^^^^                  ^^ 
> 

Done.

And did a global replacement of missing comma after e.g. and i.e., as well as other punctuation nits.

> (3) 
> 
> OLD: 
>   Network Overlay:  Logical network built on top of existing network
>      (the underlay).  Packets are encapsulated or tunneled to create
>                                               ^^^^^^^^^^^^
>      the overlay network topology.
> 
> NEW: 
>   Network Overlay:  Logical network built on top of existing network
>      (the underlay).  Packets are encapsulated to create
>      the overlay network topology.
> 

I do not see any explanation of this proposal, and the current text looks good.

> (4)
> 
> Position the "Service Classifier" entry right after SFP given that the text uses SFs and SFFs acronyms that are introduced later in the section. 
> 
> * Section 2.2: NSH is already expanded. 
> 
> OLD:
>   Network Service Header (NSH) addresses several limitations associated
>   with service function deployments.  
> NEW:
>   NSH addresses several limitations associated
>   with service function deployments.  

Sure.

> 
> * Section 2.3: Transport area folks may be "hurted" by this "network transport protocol" wording. I suggest to use transport encapsulation as per the SFC arch RFC.
> 
> OLD: 
>   5.  Transport Agnostic: NSH is transport independent.  An appropriate
>       (for a given deployment) network transport protocol can be used
>       to transport NSH-encapsulated traffic.  This transport may form
>       an overlay network and if an existing overlay topology provides
>       the required service path connectivity, that existing overlay may
>       be used.
> 
> NEW:
>   5.  Transport Agnostic: NSH is transport-independent.  An appropriate
>                                         ^^^^^^    

Yes. Done.

>       (for a given deployment) network transport encapsulation scheme can be used
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

RFC 7665 says "network transport protocol”. If TSV is hurt, they can let us know.

>       to transport NSH-encapsulated traffic.  This transport may form
>       an overlay network and if an existing overlay topology provides
>       the required service path connectivity, that existing overlay may
>       be used.
> 
> * Section 3:
> 
> (1)
> 
> OLD:
>   A Network Service Header (NSH) contains service path information and
>   ^^^^^^^^^^^^^^^^^^^^^^^^

OK. I am happy to entertain these and they improve the document. However, these level of editorial changes is best done by the RFC Editor.

>   optionally metadata that are added to a packet or frame and used to
>   create a service plane.  An outer transport header is imposed, on NSH^
>                    ^^^^^^

No. Why?

>   and the original packet/frame, for network forwarding.
> ^

I do not understand this one.

> NEW:
>   NSH contains service path information and
>   optionally metadata that are added to a packet or frame and used to
>   create a service path.  An outer transport header is imposed, on NSH
>   and the original packet/frame, for network forwarding.
> 
> (2)
> 
> OLD:
>   A Service Classifier adds NSH.  NSH is removed by the last SFF in the
>   service chain or by a SF that consumes the packet.
> 
> NEW:
>   A Service Classifier adds NSH.  NSH is removed by the last SFF in the
>   service chain or by an SF that consumes the packet.
>                       ^^
> 

Done. I also spotted an instance of “a SFF”, which I also fixed.

> * Section 3.1
> 
> (1)
> 
> OLD: 
>   Service Path Header: provide path identification and location within
>   a service path.
> 
> NEW:
>   Service Path Header: provides path identification and location within
>                        ^^^^^^^^
>   a service path.

Done.

> 
> (2)
> 
> OLD:
>   Context header: carry metadata (i.e. context data) along a service
>   path.
> 
> NEW:
>   Context header: carries metadata (a.k.a., context data) along a service
>                   ^^^^^^^^         ^^^^^^^^ 

Yes / No.

>   path.
> 
> * Section 3.2.
> 
> (1)
> Add this text before Figure 2
> 
> NEW:
> Figure 2 depicts the NSH base header:
> 

Thanks. Done.

> (2)
> 
> OLD:
>   Version: The version field is used to ensure backward compatibility
>   going forward with future NSH updates.  It MUST be set to 0x0 by the
>   sender, in this first revision of NSH.  Given the widespread
>   implementation of existing hardware that uses the first nibble after
>   an MPLS label stack for ECMP decision processing, this document
>   reserves version 01 and this value MUST NOT be used in future
>   versions of the protocol.  Please see [RFC7325] for further
>   discussion of MPLS-related forwarding requirements.
> 
> NEW:
>   Version: The version field is used to ensure backward compatibility
>   going forward with future NSH specification updates.  It MUST be set to 0x0 by the
>                             ^^^^^^^^^^^^^^^^^^ 
>   sender, in this first revision of NSH.  Given the widespread
>   implementation of existing hardware that uses the first nibble after
>   an MPLS label stack for ECMP decision processing, this document
>   reserves version 01 and this value MUST NOT be used in future
>   versions of the protocol.  Please see [RFC7325] for further
>   discussion of MPLS-related forwarding requirements.
> 


OK.

> (3)
> 
> OLD:
>   SF/SFF/SFC Proxy/Classifer implementations that do not support SFC
>   OAM procedures SHOULD discard packets with O-bit set, but MAY support
>   a configurable parameter to enable forwarding received SFC OAM
>   packets unmodified to the next element in the chain.  Forwarding OAM
> 
> NEW:
>   SF/SFF/SFC Proxy/Classifier implementations that do not support SFC
>                   ^^^^^^^^^^
>   OAM procedures SHOULD discard packets with O-bit set, but MAY support
>   a configurable parameter to enable forwarding received SFC OAM
>   packets unmodified to the next element in the chain.  Forwarding OAM
> 

Fixed.

> (4)
> 
> OLD:
>   All other flag fields are reserved for future use.  Reserved bits
>   MUST be set to zero upon origination and MUST be preserved unmodified
>   by other NSH supporting elements.  Elements which do not understand
>   the meaning of any of these bits MUST not modify their actions based
>   on those unknown bits.
> 
> NEW:
>   All other flag fields are reserved for future use.  Reserved bits
>   MUST be set to zero upon origination and MUST be preserved unmodified
>   by other NSH supporting elements.  Elements which do not understand
>   the meaning of any of these bits MUST NOT modify their actions based
>                                         ^^^^
>   on those unknown bits.
> 

Already done.


> (5)
> 
> OLD: 
>   0x1 - which indicates that the format of the header includes a fixed
>   length Context Header (see Figure 4 below).
> 
> NEW:
>   0x1 - which indicates that the format of the header includes a fixed
>   length Context Header (see Figure 4).
> 

Why?

> (6)
> 
> OLD:
>   0x2 - which does not mandate any headers beyond the Base Header and
>   Service Path Header, but may contain optional variable length Context
>   Header(s).  The semantics of the variable length Context Header(s)
>   are not defined in this document
> 
> NEW:
>   0x2 - which does not mandate any headers beyond the Base Header and
>   Service Path Header, but may contain optional variable length Context
>   Header(s).  The semantics of the variable length Context Header(s)
>   are not defined in this document. 
>                                   ^^
>   A generic format of the variable length Context Header is provided in Section 3.5.1.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 

Done.

> (7)
> 
> OLD:
>   NSH implementations MUST support MD type =  0x1 and MD Type 0x2 (where
>   the length is of value 0x2).  
> 
> NEW1:
>   NSH implementations MUST support MD type 0x1 and MD Type 0x2 (where
>   the length is of value 0x2).  
> 
> Or 
> NEW2:
>   NSH implementations MUST support MD type = 0x1 and MD Type = 0x2 (where
>   the length is of value 0x2).  
> 

OK, used NEW2.

> (8)
> 
> OLD:
>   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.
> 
> NEW:
>   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 12.2.5).
> 

OK… The existing text seems fine… this is really RFC Editor territory… I will change this one...

> * Section 3.3:
> 
> (1)
> 
> Add this new text right before Figure 3: 
> 
> NEW:
> Figure 3 shows the format of the Service Path Header:
> 

OK

> (2)
> 
> Add this NEW text right after Figure 3:
> 
> NEW:
> The meaning of these fields is as follows:
> 

Done.

> (3)
> 
> OLD:
>   SI is used in conjunction with Service Path Identifier for Service
>   Function Path Selection and for determining the next SFF/SF in the
>   path.  Service Index (SI) is also valuable when troubleshooting/
>         ^^^^^^^^^^^^^^^^^^^    
>   reporting service paths.  In addition to indicating the location
>   within a Service Function Path, SI can be used for service plane loop
>   detection.
> 
> NEW:
>   SI is used in conjunction with Service Path Identifier for Service
>   Function Path Selection and for determining the next SFF/SF in the
>   path.  SI is also valuable when troubleshooting/
>   reporting service paths.  In addition to indicating the location
>   within a Service Function Path, SI can be used for service plane loop
>   detection.
> 

OK. I also changed “SI is” to “The SI is” twice.

> * Section 3.4:
> 
> OLD: 
>     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|R|    TTL    |   Length  |R|R|R|R|MD Type| Next Protocol |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Service Path Identifer               | Service Index |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    |                 Fixed Length Context Header                   |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> NEW:
>     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|R|    TTL    |   Length  |R|R|R|R|MD Type| Next Protocol |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Service Path Identifier               | Service Index |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    |                 Fixed Length Context Header                   |
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 

Fixed without misaligning the figure. Thanks.

> * Section 3.5: Figure 5 is not called in the text. 
> 
> OLD:
>   When the base header specifies MD Type= 0x2, zero or more Variable
>   Length Context Headers MAY be added, immediately following the
>   Service Path Header.  
> 
> NEW:
>   When the base header specifies MD Type= 0x2, zero or more Variable
>   Length Context Headers MAY be added, immediately following the
>   Service Path Header (Figure 5).  
> 
> * Section 3.5.1: 
> 
> (1)
> 
> OLD:
>   Metadata Class (MD Class): The MD Class defines the scope of the
>   'Type' field to provide a hierarchical namespace.  The IANA
>   Considerations section defines how the MD Class values can be
>   allocated to standards bodies, vendors, and others.
> 
> NEW:
>   Metadata Class (MD Class): defines the scope of the
>   'Type' field to provide a hierarchical namespace.  Section 12.2.4 defines how the MD Class values can be
>   allocated to standards bodies, vendors, and others.
> 

OK...

> (2)
> 
> OLD:
>   Length: Length of the variable metadata, in single byte words.  
> NEW:
>   Length: indicates the length of the variable metadata, in single byte words.  
> 

OK.

I am also moved the definition of Bytes to Section 1.1, instead of %s/byte/octet/g, to be machine independent.

> * Section 4
> 
> (1)
> 
> OLD:
> These nodes have several possible header related
>   actions:
> 
> NEW:
> These nodes have several possible NSH-related
>   actions:
> 

OK.

> (2) 
> 
> (1)
> 
> OLD:
>   1.  Insert or remove NSH: These actions can occur at the start and
> 
> NEW:
>   1.  Insert or remove NSH: can occur at the start and
> 

Not changed.

> (2) a classifier is a function, so "logical classifier" sounds weird to me.
> 
> OLD: 
>       Multiple logical classifiers may exist within a given service
>       path.  
> NEW:
>       Multiple classifiers may exist within a given service
>       path.  

Not changed.

> 
> * Section 5: Not sure I would maintain this section. At least, the title should be updated to reflect the few points that are cited.  
> 
> OLD: 5.  NSH Encapsulations
> NEW: 5.  NSH & Transport Encapsulations
> 

OK, without the “&"

> * Section 7.1
> 
> (1)
> 
> OLD: 
>   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.
> 
> NEW:
>   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 and the network transport.  Furthermore, there is no
>   requirement, or expectation of an SPI being bound to a pre-determined
>   or static network path.
> 

Accepted “provides”, the other two proposals not accepted.

> (2) Use consistent terminology:
> 
> OLD: 
> 
>  This indirection --- path ID to overlay -- creates a true service
>                       ^^^^^^^^
>   plane.
> 
> NEW:
>   This indirection --- SPI to overlay -- creates a true service
>   plane.    

OK.

> 
> * Section 9:
> 
> Add this NEW text at the end of the 4th paragraph:
> 
> NEW:
> 
> Means to prevent leaking privacy-related information outside an administrative domain are supported by NSH given that the last SFF of a path will systematically remove the NSH header before forwarding a packet upstream.
> 

This is a good addition. Thank you!

— Carlos.

> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : sfc [mailto:[e-mail]] De la part de Joel Halpern
>> Envoyé : lundi 3 juillet 2017 02:14
>> À : [e-mail]
>> Objet : [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-13.txt
>> 
>> Below is the announcement of -13 of the NSH document.
>> To the best of the chairs and editors ability, this reflects all
>> comments we have received, in accordance with the rough consensus of the
>> WG as best the chairs were able to determine it.
>> 
>> We think it is done.
>> Please take a look.
>> 
>> Our goal is to hand this document to the IESG by the IETF meeting.  As
>> such, we would like all comments to be in by 14-July-2017.
>> 
>> Yours,
>> Joel and Jim
>> 
>> PS: Unless someone objects, we will accept the OAM clarification Andy
>> Malis sent to the list.
>> 
>> 
>> -------- Forwarded Message --------
>> Subject: I-D Action: draft-ietf-sfc-nsh-13.txt
>> Date: Fri, 30 Jun 2017 04:33:38 -0700
>> From: [e-mail]
>> Reply-To: [e-mail]
>> To: [e-mail]
>> CC: [e-mail]
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Service Function Chaining of the IETF.
>> 
>>         Title           : Network Service Header
>>         Authors         : Paul Quinn
>>                           Uri Elzur
>> 	Filename        : draft-ietf-sfc-nsh-13.txt
>> 	Pages           : 37
>> 	Date            : 2017-06-30
>> 
>> Abstract:
>>    This document describes a Network Service Header (NSH) inserted onto
>>    packets or frames to realize service function paths.  NSH also
>>    provides a mechanism for metadata exchange along the instantiated
>>    service path.  NSH is the SFC encapsulation required to support the
>>    Service Function Chaining (SFC) Architecture (defined in RFC7665).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-13
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-13
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc

—
Carlos Pignataro, [e-mail]

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