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. 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. 9. O-bit Section 3.2: Current text reads as follows: O bit: Setting this bit indicates an Operations, Administration, and Maintenance (OAM) packet. The actual packet format and processing of SFC OAM messages is outside the scope of this specification (see [I- D.ietf-sfc-oam-framework]). 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. Replace entire text as follows: O bit: Setting this bit indicates an Operations, Administration, and Maintenance (OAM) packet. The actual packet format and processing of SFC OAM messages is outside the scope of this specification (see [I- D.ietf-sfc-oam-framework]). 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 forothers, 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. 10. NSH actions Section 4: Update figure 8 to reflect that an SFC-proxy can update context headers. 11. NSH TTL Section 3.2: Update figure 2 as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Add the following text after figure 2: TTL: Indicates the maximum SFF hops for an SFP. The initial TTL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly provided, the default initial TTL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the TTL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a TTL value of 63. The packet MUST NOT be forwarded if TTL is, after decrement, 0. Section 3.4: Update figure 4 to reflect the new base header format as per section 3.2 base header. Section 3.5: Update figure 5 to reflect the new base header format as per section 3.2 base header. Section 12.2.1: Current text is as follows: There are ten bits at the beginning of the NSH Base Header. New bits are assigned via Standards Action [RFC5226]. Bits 0-1 - Version Bit 2 - OAM (O bit) Bit 3 - Critical TLV (C bit) Bits 4-9 - Reserved Replace entire text as follows: There are five reserved bits in the NSH Base Header. New bits are assigned via Standards Action [RFC5226]. Bits 0-1 - Version Bit 2 - OAM (O bit) Bit 3 - Reserved Bits 16-19 - Reserved Section 12.2.3: Current text has the MD-type as 8-bit values. Update text for this section and table 1 to reflect 4-bit values *not* 8-bit values. 12. Flag bits Section 3.2: Current text says: All other flag fields are reserved for future use. Reserved bits MUST be set to zero when sent and MUST be ignored upon receipt. Update text as follows: 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.