An Update to the OAM Behavior in the Network Service Header (NSH)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 August 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document clarifies an ambiguity related to the definition of Operations, Administration, and Maintenance (OAM) packet discussed in [RFC8300].¶

The processing of the O bit in the Network Service Header (NSH) must follow the updated behavior specified in Section 3.¶

2. Terminology

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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document makes use of the terms defined in [RFC7665] and [RFC8300].¶

The document defines the following terms:¶

SFC data plane element:

refers to NSH-aware SF, SFF, SFC Proxy, or Classifier as defined in the SFC data plane architecture [RFC7665] and further refined in [RFC8300].¶

OAM control element:

an NSH-aware elements that is capable of generating NSH OAM packets. An SFC data plane element may behave as an OAM control element.¶

OAM data:

refers to an OAM command (e.g., Connectivity Verification and Continuity Checks [RFC7276]), any data that influences how to execute a companion OAM command (e.g., identity of a terminating Service Function (SF)), the output data of an OAM command, and any combination thereof.¶

User data:

refers to user packets cited in Section 5.7 of [RFC7665].¶

3. An Update to RFC8300

This document updates RFC8300 as follows:¶

OLD:

   O bit:  Setting this bit indicates an OAM packet (see [RFC6291]).
      The actual format and processing of SFC OAM packets is outside the
      scope of this specification (for example, see [SFC-OAM-FRAMEWORK]
      for one approach).

      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.

      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 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 OAM
      packet for all OAM functions prior to enabling this behavior.  The
      configurable parameter MUST be disabled by default.

NEW:

O bit:

Setting this bit indicates an SFC OAM packet. Such a packet is any NSH-encapasulated packet that exclusively includes OAM data. An OAM data can be included in the Fixed-Length Context Header, optional Context Headers, and/or the inner packet.¶

The O bit is typically set by an OAM controller or an ultimate target of an SFC OAM packet that triggers a response.¶

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

NSH-encapsulated packets that include user data are not considered as SFC OAM packets even if some OAM data (e.g., record route) is also supplied in the packet.¶

When an OAM data is included in the inner packet, the Next Protocol field is set to reflect the structure of that inner packet. By default, SFFs SHOULD discard NSH packets with O bit set and Next Protocol set to 0x1 (IPv4), 0x2 (IPv6), 0x3 (MPLS), or 0x5 (Ethernet).¶

An SFC OAM packet MAY include optional Context Headers (e.g., a subscriber identifier [RFC8979] or a flow identifier [I-D.ietf-sfc-nsh-tlv]) that are used to influence the processing of the packet by SFC data plane elements.¶

An SFC OAM packet MAY include OAM data in both Context Headers and the inner packet. The processing (including the order) of the OAM data SHOULD be specified in the relevant OAM or Context Header specification.¶

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

The actual format and additional processing of SFC OAM packets is outside the scope of this specification.¶

5. Security Considerations

Data plane SFC-related security considerations, including privacy, are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300].¶

Data icnluded in an SFC OAM packet SHOULD be integrity-protected [RFC9145].¶

6. Acknowledgements

Thanks to Jim Guichard and Greg Mirsky for the comments.¶

Author's Address