<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sfc-oam-packet-03" number="9451" submissionType="IETF" category="std" consensus="true" ipr="trust200902"
     updates="8300"> updates="8300" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
sortRefs="true" version="3">

  <front>
<title abbrev="SFC OAM Packet">OAM abbrev="OAM Packet NSH">Operations, Administration, and Maintenance
    (OAM) Packet and Behavior in the Network Service Header (NSH)</title>
    <seriesInfo name="RFC" value="9451"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Rennes</city>

          <region></region>
          <region/>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <date /> year="2023" month="August"/>
    <area>rtg</area>
    <workgroup>sfc</workgroup>
    <keyword>Diagnostic</keyword>
    <keyword>Troubelshooting</keyword>
    <keyword>Service Function Chaining</keyword>
    <keyword>Automation</keyword>
    <keyword>SDN</keyword>
    <keyword>Programmable Networks</keyword>
    <keyword>Service Differentiation</keyword>
    <abstract>
      <t>This document clarifies an ambiguity in the Network Service Header
      (NSH) specification related to the handling of O bit. In particular,
      this document clarifies the meaning of "OAM packet".</t>
      <t>This document updates RFC 8300.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document clarifies an ambiguity related to the definition of
      the Operations, Administration, and Maintenance (OAM) packet discussed in
      <xref target="RFC8300"></xref>.</t>

      <t>The processing target="RFC8300" format="default"/>.</t>
      <t>Processing of the O bit in the Network Service Header (NSH) must
      follow the updated behavior specified in <xref
      target="anupdate"></xref>.</t> target="anupdate"
      format="default"/>.</t>
    </section>
    <section anchor="notation" title="Terminology">
      <t>The numbered="true" toc="default">
      <name>Terminology</name>
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
        NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref>
        target="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.</t> here.
        </t>
      <t>This document makes use of the terms defined in <xref
      target="RFC7665"></xref>
      target="RFC7665" format="default"/> and <xref target="RFC8300"></xref>.</t> target="RFC8300"
      format="default"/>.</t>
      <t>The document defines the following terms:<list style="hanging">
          <t hangText="SFC terms:</t>
      <dl newline="false" spacing="normal">
        <dt>Service Function Chaining (SFC) data plane element:">refers element:</dt>
        <dd>refers to the SFC-aware Service Function (SF), Service Function
        Forwarder (SFF), SFC Proxy, or Classifier as defined in the SFC data
        plane architecture <xref
          target="RFC7665"></xref> target="RFC7665" format="default"/> and
        further refined in <xref
          target="RFC8300"></xref>.</t>

          <t hangText="OAM target="RFC8300" format="default"/>.</dd>
        <dt>OAM control element:">an element:</dt>
        <dd>an NSH-aware element that is capable of generating NSH OAM
        packets. An SFC data plane element may behave as an OAM control element.</t>

          <t hangText="SFC
        element.</dd>
        <dt>SFC OAM data:">refers data:</dt>
        <dd>refers to an OAM request (e.g., Connectivity Verification and
        Continuity Checks <xref
          target="RFC7276"></xref>), target="RFC7276" format="default"/>), any data
        that influences how to execute a companion OAM request (e.g., identity
        of a terminating SF), the output data of an OAM request, and any
        combination thereof.</t>

          <t hangText="User data:">refers thereof.</dd>
        <dt>User data:</dt>
        <dd>refers to user packets cited in Section 5.7
          of <xref target="RFC7665"></xref>.</t>
        </list></t> target="RFC7665"
        sectionFormat="of" section="5.7"/>.</dd>
      </dl>
    </section>
    <section anchor="anupdate" title="An numbered="true" toc="default">
      <name>An Update to RFC8300"> RFC 8300</name>
      <t>This document updates Section 2.2 of <xref target="RFC8300"></xref> target="RFC8300" sectionFormat="of"
      section="2.2"/> as follows:</t>

      <t><list style="hanging">
          <t hangText="OLD: "><vspace blankLines="1" /><list style="hanging">
              <t hangText="O bit:">Setting

        <t>OLD:</t>

<blockquote>
          <dl newline="false" spacing="normal">
            <dt>O bit:</dt>
            <dd><t>Setting this bit indicates an OAM packet (see [RFC6291]). <xref
            target="RFC6291" format="default"/>). 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).<vspace
              blankLines="1" />The
            approach).</t>
            <t>The O bit MUST <bcp14>MUST</bcp14> be set for OAM packets and MUST
              NOT
            <bcp14>MUST NOT</bcp14> be set for non-OAM packets. The O bit MUST NOT
            <bcp14>MUST NOT</bcp14> be modified along the SFP.<vspace blankLines="1" />SF/SFF/SFC SFP.</t>
            <t>SF/SFF/SFC Proxy/Classifier implementations that do not support
            SFC OAM procedures SHOULD <bcp14>SHOULD</bcp14> discard packets with O
            bit set, but MAY <bcp14>MAY</bcp14> 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
            <bcp14>MUST</bcp14> be disabled by default.</t>
            </list></t>

          <t hangText="NEW: "><vspace blankLines="1" /><list style="hanging">
              <t hangText="O bit:">Setting
            </dd>
          </dl>
</blockquote>

        <t>NEW:</t>

<blockquote>
          <dl newline="false" spacing="normal">
            <dt>O bit:</dt>
            <dd><t>Setting this bit indicates an NSH OAM packet. Such a packet
            is any NSH-encapsulated packet that exclusively includes SFC OAM
            data. SFC OAM data can be included in the Fixed-Length Context
            Header, optional Context Headers, and/or the inner packet. <vspace blankLines="1" />The </t>
            <t>The O bit is typically set by an OAM controller or a final
            destination of an NSH OAM packet that triggers a response (e.g., a
            specific SFC-aware SF, SF or the last SFF of an SFP). <vspace
              blankLines="1" />The </t>
            <t>The O bit MUST <bcp14>MUST</bcp14> be set for NSH OAM packets and
              MUST NOT
            <bcp14>MUST NOT</bcp14> be set for non-OAM packets. The O bit MUST NOT
            <bcp14>MUST NOT</bcp14> be modified along the SFP.<vspace blankLines="1" />NSH-encapsulated SFP.</t>
            <t>NSH-encapsulated packets that include user data are not
            considered as NSH OAM packets even if some SFC OAM data (e.g.,
            record route) is also supplied in the packet. <vspace blankLines="1" />When </t>
            <t>When SFC OAM data is included in the inner packet, the Next
            Protocol field is set to reflect the structure of that inner OAM
            packet. The setting and processing of the O bit neither assumes
            nor expects detailed analysis of the content of any inner IP
            packet carried by the NSH. In order to prevent non deterministic non-deterministic
            behaviors, SFC data plane elements MAY <bcp14>MAY</bcp14> support a
            configuration parameter to filter valid Next Protocol values in
            NSH OAM packets. Absent explicit configuration, SFFs, SFC-aware
            SFs, and SFC Proxies
              SHOULD <bcp14>SHOULD</bcp14> discard any NSH packets
            with the O bit set and Next Protocol set to something that is not
            itself an OAM protocol.  This includes discarding the packet when
            the O bit is set and the Next Protocol is set to 0x01 (IPv4), 0x02
            (IPv6), 0x03 (MPLS), or 0x05 (Ethernet). <vspace blankLines="1" />An </t>
            <t>An NSH OAM packet MAY <bcp14>MAY</bcp14> include optional Context
            Headers (e.g., a subscriber identifier <xref target="RFC8979"></xref> target="RFC8979"
            format="default"/> or a flow identifier <xref target="RFC9263"></xref>) target="RFC9263"
            format="default"/>) that are used to influence the processing of
            the packet by SFC data plane elements. <vspace
              blankLines="1" />An </t>
            <t>An NSH OAM packet MAY <bcp14>MAY</bcp14> include SFC OAM data in
            both Context Headers and the inner packet. The processing
              (including the order)
            of the SFC OAM data SHOULD (including the order) <bcp14>SHOULD</bcp14> be
            specified in the relevant OAM or Context Header
            specification. <vspace
              blankLines="1" />SFC-aware SF/SFF/SFC Proxy/Classifier </t>
            <t>SFC-aware implementations of SF, SFF, SFC Proxy, and Classifier
            that do not support SFC OAM procedures SHOULD <bcp14>SHOULD</bcp14>
            discard packets with the O bit set, set but MAY <bcp14>MAY</bcp14> support
            a configurable parameter to enable forwarding received NSH OAM
            packets unmodified to the next element in the chain. Forwarding
            NSH OAM packets unmodified by SFC data plane 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, others.
            Thus, it is recommended to analyze the impact of forwarding an NSH
            OAM packet for all OAM functions prior to enabling this
            behavior. The configurable parameter MUST <bcp14>MUST</bcp14> be
            disabled by default. <vspace blankLines="1" />The </t>
            <t>The actual format and additional processing of NSH OAM packets
            is outside the scope of this specification.</t>
            </list></t>
        </list></t>
            </dd>
          </dl>
</blockquote>
    </section>

    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not make any request to IANA.</t> has no IANA actions.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Data plane SFC-related security considerations, including privacy,
      are discussed in Section 6 of <xref target="RFC7665"></xref> target="RFC7665" sectionFormat="of" section="6"/>
      and Section
      8 of <xref target="RFC8300"></xref>. target="RFC8300" sectionFormat="of" section="8"/>. Additional
      security considerations related to SFC OAM are discussed in Section 9 of <xref
      target="RFC8924"></xref>.</t>
      target="RFC8924" sectionFormat="of" section="9"/>.</t>
      <t>Any data included in an NSH OAM packet SHOULD <bcp14>SHOULD</bcp14> be integrity-protected
      integrity protected <xref target="RFC9145"></xref>.</t> target="RFC9145" format="default"/>.</t>
    </section>

  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9145.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8979.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9263.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8924.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6291.xml"/>
      </references>
    </references>

    <section anchor="ack" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian
      Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners <contact fullname="Jim Guichard"/>, <contact fullname="Greg
      Mirsky"/>, <contact fullname="Joel Halpern"/>, <contact
      fullname="Christian Jacquenet"/>, <contact fullname="Dirk von-Hugo"/>,
      <contact fullname="Carlos Pignataro"/>, and <contact fullname="Frank
      Brockners"/> for the comments.</t>

      <t>Thanks to Barry Leiba <contact fullname="Barry Leiba"/> for the art directorate
      review and Russ Housley <contact fullname="Russ Housley"/> for the security
      directorate review.</t>
      <t>Thanks to Alvaro Retana and Robert Wilton <contact fullname="Alvaro Retana"/> and <contact
      fullname="Robert Wilton"/> for the their IESG review.</t> reviews.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8300'?>

      <?rfc include='reference.RFC.9145'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7665'?>

      <?rfc include='reference.RFC.8979'?>

      <?rfc include='reference.RFC.9263'?>

      <?rfc include='reference.RFC.8924'?>

      <?rfc include='reference.RFC.7276'?>

      <?rfc include='reference.RFC.6291'?>
    </references>
  </back>
</rfc>