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

From: Joel Halpern <[email-masked]>
Date: Sun, 2 Jul 2017 20:13:51 -0400

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

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
[email-masked]
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

---

From: "Duarte Cardoso, Igor" <[email-masked]>
Date: Tue, 4 Jul 2017 17:14:29 +0000

Hi all,

Just read the rfcdiff between -12 and -13 and this was the first time I saw new TTL field (I don't actively follow the mailing list).

Isn't the Service Index field being implicitly/in practice limited to the TTL field?

Let me explain my reasoning:
TTL seems to be implicitly limiting SI to 63 because between each SF there will be at least 1 SFF, and each SFF will decrement TTL before checking the mapping table. So we can't have 255 SF hops without also having at least ~255 SFF hops (potentially many more depending on the topology of SFFs).

Thank you,
Best regards,
Igor.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern
Sent: Monday, July 3, 2017 1:14 AM
To: [email-masked]
Subject: [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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

Abstract:

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 4 Jul 2017 13:17:40 -0400

Yes, in theory we could have reduced the size of the SI field without 
loss of functionality.  As I see it, there seemed no point.

Yours,
Joel

---

From: <[email-masked]>
Date: Wed, 5 Jul 2017 09:30:24 +0000

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:[email-masked]] De la part de Joel Halpern
> Envoyé : lundi 3 juillet 2017 02:14
> À : [email-masked]
> Objet : [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-13.txt
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 15:02:34 +0000

Hi, Med, WG,

Just an early Ack on this email. I am currently working through the points and preparing an item-by-item reply.

Thanks,

— Carlos.

On Jul 5, 2017, at 5:30 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Joel, all,

Major:

NEW:

OLD:

OLD:

OLD:

  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

OLD:
12.1.  NSH EtherType

NEW:
12.1.  NSH EtherType

==
Minor:
==

* Abstract:

OLD:

* Introduction:

(1)

OLD:

NEW:

- expand an acronym

OLD:

NEW:

*  Section 2.1

(1)

OLD:

NEW:

(2)

OLD:

NEW:

(3)

OLD:

NEW:

(4)

OLD:

OLD:

NEW:

* Section 3:

(1)

OLD:

(2)

OLD:

NEW:

* Section 3.1

(1)

OLD:

NEW:

(2)

OLD:

NEW:

* Section 3.2.

(1)

NEW:

(2)

OLD:

NEW:

(3)

OLD:

NEW:

(4)

OLD:

NEW:

(5)

OLD:

NEW:

(6)

OLD:

NEW:

(7)

OLD:

NEW1:

Or
NEW2:

(8)

OLD:

NEW:

* Section 3.3:

(1)

NEW:

(2)

NEW:

(3)

OLD:

NEW:

* Section 3.4:

OLD:

NEW:

OLD:

NEW:

* Section 3.5.1:

(1)

OLD:

NEW:

(2)

OLD:

* Section 4

(1)

OLD:

NEW:

(2)

(1)

OLD:

NEW:

OLD:

* Section 7.1

(1)

OLD:

NEW:

OLD:

NEW:

* Section 9:

NEW:

Cheers,
Med

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de Joel Halpern
Envoyé : lundi 3 juillet 2017 02:14
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-13.txt

We think it is done.
Please take a look.

Yours,
Joel and Jim

-------- Forwarded Message --------
Subject: I-D Action: draft-ietf-sfc-nsh-13.txt
Date: Fri, 30 Jun 2017 04:33:38 -0700
From: [email-masked]<mailto:[email-masked]>
Reply-To: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>

Abstract:

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.

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 7 Jul 2017 20:17:47 +0000

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, [email-masked] wrote:
> 
> Hi Joel, all, 
> 

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.

> 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.
 
@@ -472,6 +412,10 @@
 
+   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

> Further, the document does not include some text about the use of 254/255 values.     

Similarly, agreed. Change made. Proposed text:

   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.

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

> NEW: Network Service Header (NSH)

OK.

>   Service Function Chaining (SFC) architecture (defined in RFC7665).

Done.

>   data center [I-D.ietf-sfc-dc-use-cases], campus, and so forth.

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.

>   Network Service Header (NSH) defines a new service plane protocol specifically for the

Done.

>   1.  Service Function Path identification.

Done.

> - Not sure what is meant by "network traffic”

Traffic from and to the network?

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

>      (the underlay).  Packets are encapsulated or tunneled to create

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

>   with service function deployments.  

Sure.

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

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

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

>   service chain or by an SF that consumes the packet.

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

>   Service Path Header: provides path identification and location within

Done.

>   Context header: carries metadata (a.k.a., context data) along a service

Yes / No.

> Figure 2 depicts the NSH base header:

Thanks. Done.

>   going forward with future NSH specification updates.  It MUST be set to 0x0 by the

OK.

>   SF/SFF/SFC Proxy/Classifier implementations that do not support SFC

Fixed.

>   the meaning of any of these bits MUST NOT modify their actions based

Already done.

>   length Context Header (see Figure 4).

Why?

>   A generic format of the variable length Context Header is provided in Section 3.5.1.

Done.

>   the length is of value 0x2).  

OK, used NEW2.

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

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

OK

> The meaning of these fields is as follows:

Done.

>   path.  Service Index (SI) is also valuable when troubleshooting/

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

> OLD: 

Fixed without misaligning the figure. Thanks.

>   allocated to standards bodies, vendors, and others.

OK...

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

> These nodes have several possible NSH-related

OK.

>   1.  Insert or remove NSH: can occur at the start and

Not changed.

>       Multiple classifiers may exist within a given service

Not changed.

> NEW: 5.  NSH & Transport Encapsulations

OK, without the “&"

>   As described above, NSH contains a Service Path Identifier (SPI) and

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

>   This indirection --- SPI to overlay -- creates a true service

OK.

> 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 forward…

This is a good addition. Thank you!

— Carlos.

>> ftp://ftp.ietf.org/internet-drafts/

—
Carlos Pignataro, [email-masked]

---

From: <[email-masked]>
Date: Mon, 10 Jul 2017 07:46:53 +0000

Hi Carlos, 

Thank you for taking care of the comments. 

Please see inline. 

Cheers,
Med

> De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Envoyé : vendredi 7 juillet 2017 22:18
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joel M. Halpern; [email-masked]
> Objet : Re: [sfc] I-D Action: draft-ietf-sfc-nsh-13.txt
> 
> Hi, Med,
> 
> 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.

[Med] Yes, indeed. I'm happy with this version compared to all those versions that were LCed in the past. 

 Even better quality now
> after applying fixes to all of these.
> 
> > (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:
> 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?).

[Med] Sorry for not explaining it in my initial review. Actually, this is something we discussed during the interim meeting. Below an excerpt from the minutes, fwiw: 

=========
SFC allows changing MD-1 format to MD-2 on a SFP or vice versa. Current document
has not yet made this clear.

..

Room consensus:
o       Allow changing MD-1 format to MD-2 in a SFP or vice
versa.
=========

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

[Med] Some sample use cases are:  
* the mix of a DC and WAN 
* the mix of DC and SFC at Gi interface
* Hierarchical SFC 

> 
> In my view, the text as-is is at the right specification level.

[Med] Cool.

 The
> proposed text above does not add value — it is trying to over specify when
> there’s no need.

[Med] Disagree. Please refer to the minutes of the last interim meeting. 

> 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:
> 

[Med] s/five/four?

> +   discard packets with MD Type 0.

[Med] Two comments here:
* I lost the context why this value was reserved. Adding some words would be helpful. 
* If the value is maintained as "reserved", then I would expect s/SHOULD/MUST because, otherwise an implementation has no guidance to follow for processing such pack (if SHOULD is ignored). 

>     length Context Header (see Figure 4 below).

[Med] Works for me, thanks. 

>     4-bit values.  MD Type values 0, 1, 2, 15, and 16 are specified in

[Med] s/ MD Type values 0, 1, 2, 15, and 16/MD Type values 0, 1, 2, and 15

> +   Review" policy defined in RFC 8126 [RFC8126].

[Med] OK, thanks. 

BTW, it seems that some new text is still needed to address this point discussed during the interim: 

===================
o       It is not clear when receiving a NSH packet, if SF does not
support the MD type, what to do.
o       WG Chairs and document editors to go
through NSH document to clarify the process rules for SFC component to receive
an NSH packet, including SFF, SF, reclassifier, especially if a field value is
not understood.
==================

>    [RFC3692] SHOULD NOT attempt to process Next Protocol values 254 and

[Med] OK, thanks.

> >   IANA is requested to register the IEEE EtherType, 0x894F, for NSH in
> https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml.
> >
> 

[Med] This one is pending.  

> > Minor:

[Med] Those are minor ones. Pick those that you agree with and ignore the rest. Thank you.