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

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

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, [e-mail]<mailto:[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.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(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]<mailto:[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]<mailto:[e-mail]>
Reply-To: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]>
CC: [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

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