Clarifying Ambiguity related to Network Service Header (NSH) OAM Packet

This document clarifies an ambiguity related to the definition of OAM packet discussed in . The processing of the O-bit must follow the updated behavior specified in .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in and .

This document updates RFC8300 as follows:

Setting this bit indicates an SFC OAM packet. Such a packet is any NSH-encapasulated packet that exclusively includes an OAM command and/or OAM data. The OAM command (or data) can be included in the Fixed-Length Context Header, optional Context Headers, or the inner packet. The actual format and processing of SFC OAM packets is outside the scope of this specification. The O bit MUST be set for SFC OAM packets and MUST NOT be set for non-OAM packets. The O bit MUST NOT be modified along the SFP.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 SFC OAM packets unmodified by SFC elements that do not support SFC OAM procedures may be acceptable for a subset of OAM functions, but it can result in unexpected outcomes for others; thus, it is recommended to analyze the impact of forwarding an SFC OAM packet for all OAM functions prior to enabling this behavior. The configurable parameter MUST be disabled by default.

This document does not make any request to IANA.

Data plane SFC-related security considerations, including privacy, are discussed in Section 6 of and Section 8 of . Data icnluded in an SFC OAM packet SHOULD be integrity-protected .

TBC