Subject: [sfc] WG consensus changes to draft-ietf-sfc-nsh-12

From: James N Guichard <[email-masked]>
Date: Wed, 12 Apr 2017 21:22:16 +0000

Dear WG:

After careful review of draft-ietf-sfc-nsh-12, the following changes have been agreed upon by the WG. Please review carefully and highlight if any changes have been missed so that the chairs can call consensus and ask the editors to make the changes and publish an updated version of the document. Likewise, if you disagree with the changes, now is the time to speak!. Note that the following does not assume that there are no outstanding issues to call consensus on but the chairs would like to see a new document published with all agreed upon changes so that we can better evaluate as a WG what else is outstanding before the document is ready for IESG publication:

1. C-bit changes
Section 3.2:

-          Remove the c bit from the NSH base header (figure 2), returning the bit to "reserved" status.

-          Remove the following text:
   C bit: Indicates that a critical metadata TLV is present.  This bit
   acts as an indication for hardware implementers to decide how to
   handle the presence of a critical TLV without necessarily needing to
   parse all TLVs present.  For an MD Type of 0x1 (i.e. no variable
   length metadata is present), the C bit MUST be set to 0x0.

Section 3.4 and 3.5

-          Remove the c bit and return the bit to "reserved" status (figure 4 and figure 5).

Section 3.5.1

-          Remove the c bit from figure 6 and make "Type" an 8-bit field.

-          Remove the following text:
   Type: the Type field is split into two ranges - 0 to 127 for non-
   critical options and 128-255 for critical options.  While the value
   allocation is the responsibility of the MD Class owner, critical
   options MUST NOT be allocated from the 0 to 127 range and non-
   critical options MUST NOT be allocated from the 128-255 range.

-          Remove figure 7 and associated text.

Section 12.2.1

-          Remove the following text:
   Bit 3 - Critical TLV (C bit)

2. Service Index decrement
Section 3.3:

-          The third sentence describing the Service Index currently reads:
   Service Index MUST be decremented by Service Functions or by SFC
   Proxy nodes after performing required services and the new
   decremented SI value MUST be used in the egress NSH packet.

-          Update the text as follows:
   Service Index MUST be decremented by a value of 1 by Service Functions or by SFC
   Proxy nodes after performing required services and the new
   decremented SI value MUST be used in the egress NSH packet.

3. Metadata processing
Section 3.5.1:

-          As per ticket https://trac.ietf.org/trac/sfc/ticket/21 insert the following text between the 3rd and 2nd to last paragraphs of this section:
   Upon receipt of a packet that belongs to a given SFP, if a mandatory-
   to-process TLV is missing in that packet, the SFC-aware SF MUST NOT
   process the packet and MUST log at least once per the SPI for which
   mandatory metadata is missing.

4. NSH MD Type 1
Section 3.4:

-          The first paragraph of section 3.4 currently reads:
   When the Base Header specifies MD Type = 0x1, four Context Headers,
   4-byte each, MUST be added immediately following the Service Path
   Header, as per Figure 4.  Context Headers that carry no metadata MUST
   be set to zero.

-          Update the text to read as follows:
   When the Base Header specifies MD Type = 0x1, a Fixed Length
   Context Header (16-bytes) MUST be added immediately following the Service Path
   Header, as per Figure 4.  A Fixed Length Context Header that carries no metadata
   MUST be set to zero.

-          The third paragraph of section 3.4 currently reads:
   This specification does not make any assumption about the content
   placed in the mandatory context field of the NSH header, and does not
   describe the structure or meaning of the included metadata.

-          Update the text to read as follows:
   This specification does not make any assumptions about the content
   of the 16 byte Fixed Length Context Header that must be present when
   the MD Type field is set to 0x1, and does not describe the structure
   or meaning of the included metadata.

5. MD class registry
Section 12.2.4:
- Replace existing text with the following:
12.2.4.  MD Class Registry
   IANA is requested to set up a registry of "MD Class".  These are 16-
   bit values. New allocations are to be made according to the
   following policies:
   0x0000 to 0x01ff: IETF Review
   0x0200 to 0xfff5: Expert Review
   0xfff6 to 0xfffe: Experimental
   0xffff: Reserved
   IANA is requested to assign the following value:
   MD Class | Meaning                    | Reference
   ---------+----------------------------+-----------
   0x0000   | IETF Base NSH MD Class     | [This.I-D]
   Designated Experts evaluating new allocation requests
   from the "Expert Review" range should principally
   consider whether a new MD class is needed compared to
   adding MD types to an existing class. The Designated
   Experts should also encourage the existence of an
   associated and publically visible registry of MD types
   although this registry need not be maintained by IANA.

6. New IETF assigned MD TLV Type Registry
- Add a new section 12.2.6 entitled "IETF Assigned MD TLV Type Registry" with the following text:

   This document requests IANA to create a registry for the type values
   owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF Assigned
   MD TLV Type Registry."

   The type values are assigned via Standards Action [RFC5226].

   No initial values are assigned at the creation of the registry.

7. NSH base header length field
Section 3.2:

-          Replace all of the existing text for the "length" field with the following:

   Length: The total length, in 4-byte words, of the NSH including the
   Base Header, the Service Path Header, the Fixed Length Context Header
   or Optional Variable Length Metadata that is present. Then length MUST
   be of value 0x6 for MD Type equal to 0x1, and MUST be of value 0x2 or
   greater for MD Type equal to 0x2. The length of the NSH header MUST
   be an integer multiple of 4 bytes, thus variable length metadata is
   always padded out to a multiple of 4 bytes.

8. Mandatory support for MD Type 2 no metadata
Section 3.2:

-          Current text for the first sentence for implementation support of metadata reads:
   NSH implementations MUST support MD Type = 0x1, and SHOULD support MD
   Type = 0x2.

-          Suggestion to replace this text with the following as wG consensus for this change:
   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.

Thanks!

Jim & Joel

---

From: <[email-masked]>
Date: Thu, 13 Apr 2017 08:24:19 +0000

Hi Jim,

Thank you for this summary.

There is an item that was not included in your list:

OLD :

   SF/SFF/SFC Proxy/Classifer implementations, which do not support SFC
   OAM procedures, SHALL discard packets with O-bit set.

   SF/SFF/SFC Proxy/Classifer implementations MAY support a configurable
   parameter to enable forwarding received SFC OAM packets unmodified to
   the next element in the chain.  Such behavior may be acceptable for a
   subset of OAM functions, but can result in unexpected outcomes for
   others, thus it is recommended to analyze the impact of forwarding an
   OAM packet for all OAM functions prior to enabling this behavior.
   The configurable parameter MUST be disabled by default.

   For non OAM packets, the O-bit MUST be cleared and MUST NOT be
   modified along the SFP.

NEW :

    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
    packets unmodified by SFC elements that do not support SFC OAM procedures
    may be acceptable for a subset of OAM functions, but can result in unexpected outcomes for
   others, thus it is recommended to analyze the impact of forwarding an
   OAM packet for all OAM functions prior to enabling this behavior.
   The configurable parameter MUST be disabled by default.

   The O-bit MUST be set for OAM packets and MUST NOT be set for non-OAM
   packets. The O-bit MUST NOT be modified along the SFP.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : mercredi 12 avril 2017 23:22
À : [email-masked]
Cc : [email-masked]
Objet : [sfc] WG consensus changes to draft-ietf-sfc-nsh-12

Dear WG:

1. C-bit changes
Section 3.2:

Section 3.4 and 3.5

Section 3.5.1

Section 12.2.1

3. Metadata processing
Section 3.5.1:

4. NSH MD Type 1
Section 3.4:

5. MD class registry
Section 12.2.4:

Thanks!

Jim & Joel

---

From: James N Guichard <[email-masked]>
Date: Thu, 13 Apr 2017 13:05:16 +0000

Hi Med,

Thank you. I have captured this and will add it to the list of items for the NSH document editors.

Jim

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 13, 2017 4:24 AM
To: James N Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: WG consensus changes to draft-ietf-sfc-nsh-12

Hi Jim,

OLD :

NEW :

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : mercredi 12 avril 2017 23:22
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : [sfc] WG consensus changes to draft-ietf-sfc-nsh-12

Dear WG:

1. C-bit changes
Section 3.2:

Section 3.4 and 3.5

Section 3.5.1

Section 12.2.1

3. Metadata processing
Section 3.5.1:

4. NSH MD Type 1
Section 3.4:

5. MD class registry
Section 12.2.4:

Thanks!

Jim & Joel