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

[<[e-mail]>]

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

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

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

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

==
Minor: 
==

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

* 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).
                                  ^^

* 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
- cite the use case drafts to illustrate the use of SFs
- Given that WAN acceleration may not be that clear, citing a reference where this is defined will be helpful.

(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
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   creation of dynamic service chains and is composed of the following
   elements:

   1.  Service Function Path identification.
                                           ^^

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

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

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

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

* 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
                                         ^^^^^^    
       (for a given deployment) network transport encapsulation scheme 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.

* Section 3:

(1)

OLD:
   A Network Service Header (NSH) contains service path information and
   ^^^^^^^^^^^^^^^^^^^^^^^^
   optionally metadata that are added to a packet or frame and used to
   create a service plane.  An outer transport header is imposed, on NSH^
                    ^^^^^^
   and the original packet/frame, for network forwarding.
^
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.
                       ^^

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

(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
                   ^^^^^^^^         ^^^^^^^^ 
   path.

* Section 3.2.

(1)
Add this text before Figure 2

NEW:
Figure 2 depicts the NSH base header:

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

(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

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

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

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

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

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

* Section 3.3:

(1)

Add this new text right before Figure 3: 

NEW:
Figure 3 shows the format of the Service Path Header:

(2)

Add this NEW text right after Figure 3:

NEW:
The meaning of these fields is as follows:

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

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

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

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

* Section 4

(1)

OLD:
These nodes have several possible header related
   actions:

NEW:
These nodes have several possible NSH-related
   actions:

(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

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

* 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

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

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

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


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