<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-ietf-sfc-oam-packet-03" number="9451" submissionType="IETF" category="std" consensus="true" ipr="trust200902" updates="8300" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2023-08-11T18:18:22" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-packet-03" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9451" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="OAM Packet NSH">Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH)</title>
    <seriesInfo name="RFC" value="9451" stream="IETF"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <region/>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <date month="08" year="2023"/>
    <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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 indent="0" pn="section-abstract-2">This document updates RFC 8300.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9451" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-an-update-to-rfc-8300">An Update to RFC 8300</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document clarifies an ambiguity related to the definition of
      the Operations, Administration, and Maintenance (OAM) packet discussed in
      <xref target="RFC8300" format="default" sectionFormat="of" derivedContent="RFC8300"/>.</t>
      <t indent="0" pn="section-1-2">Processing of the O bit in the Network Service Header (NSH) must
      follow the updated behavior specified in <xref target="anupdate" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
    </section>
    <section anchor="notation" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1"> The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">This document makes use of the terms defined in <xref target="RFC7665" format="default" sectionFormat="of" derivedContent="RFC7665"/> and <xref target="RFC8300" format="default" sectionFormat="of" derivedContent="RFC8300"/>.</t>
      <t indent="0" pn="section-2-3">The document defines the following terms:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-4">
        <dt pn="section-2-4.1">Service Function Chaining (SFC) data plane element:</dt>
        <dd pn="section-2-4.2">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" format="default" sectionFormat="of" derivedContent="RFC7665"/> and
        further refined in <xref target="RFC8300" format="default" sectionFormat="of" derivedContent="RFC8300"/>.</dd>
        <dt pn="section-2-4.3">OAM control element:</dt>
        <dd pn="section-2-4.4">an NSH-aware element that is capable of generating NSH OAM
        packets. An SFC data plane element may behave as an OAM control
        element.</dd>
        <dt pn="section-2-4.5">SFC OAM data:</dt>
        <dd pn="section-2-4.6">refers to an OAM request (e.g., Connectivity Verification and
        Continuity Checks <xref target="RFC7276" format="default" sectionFormat="of" derivedContent="RFC7276"/>), 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.</dd>
        <dt pn="section-2-4.7">User data:</dt>
        <dd pn="section-2-4.8">refers to user packets cited in <xref target="RFC7665" sectionFormat="of" section="5.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7665#section-5.7" derivedContent="RFC7665"/>.</dd>
      </dl>
    </section>
    <section anchor="anupdate" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-an-update-to-rfc-8300">An Update to RFC 8300</name>
      <t indent="0" pn="section-3-1">This document updates <xref target="RFC8300" sectionFormat="of" section="2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8300#section-2.2" derivedContent="RFC8300"/> as follows:</t>
      <t indent="0" pn="section-3-2">OLD:</t>
      <blockquote pn="section-3-3">
        <dl newline="false" spacing="normal" indent="3" pn="section-3-3.1">
          <dt pn="section-3-3.1.1">O bit:</dt>
          <dd pn="section-3-3.1.2">
            <t indent="0" pn="section-3-3.1.2.1">Setting this bit indicates an OAM packet (see <xref target="RFC6291" format="default" sectionFormat="of" derivedContent="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).</t>
            <t indent="0" pn="section-3-3.1.2.2">The O bit <bcp14>MUST</bcp14> be set for OAM packets and
            <bcp14>MUST NOT</bcp14> be set for non-OAM packets. The O bit
            <bcp14>MUST NOT</bcp14> be modified along the SFP.</t>
            <t indent="0" pn="section-3-3.1.2.3">SF/SFF/SFC Proxy/Classifier implementations that do not support
            SFC OAM procedures <bcp14>SHOULD</bcp14> discard packets with O
            bit set, but <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
            <bcp14>MUST</bcp14> be disabled by default.</t>
          </dd>
        </dl>
      </blockquote>
      <t indent="0" pn="section-3-4">NEW:</t>
      <blockquote pn="section-3-5">
        <dl newline="false" spacing="normal" indent="3" pn="section-3-5.1">
          <dt pn="section-3-5.1.1">O bit:</dt>
          <dd pn="section-3-5.1.2">
            <t indent="0" pn="section-3-5.1.2.1">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. </t>
            <t indent="0" pn="section-3-5.1.2.2">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 or the last SFF of an SFP). </t>
            <t indent="0" pn="section-3-5.1.2.3">The O bit <bcp14>MUST</bcp14> be set for NSH OAM packets and
            <bcp14>MUST NOT</bcp14> be set for non-OAM packets. The O bit
            <bcp14>MUST NOT</bcp14> be modified along the SFP.</t>
            <t indent="0" pn="section-3-5.1.2.4">NSH-encapsulated packets that include user data are not
            considered NSH OAM packets even if some SFC OAM data (e.g.,
            record route) is also supplied in the packet. </t>
            <t indent="0" pn="section-3-5.1.2.5">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
            behaviors, SFC data plane elements <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 <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). </t>
            <t indent="0" pn="section-3-5.1.2.6">An NSH OAM packet <bcp14>MAY</bcp14> include optional Context
            Headers (e.g., a subscriber identifier <xref target="RFC8979" format="default" sectionFormat="of" derivedContent="RFC8979"/> or a flow identifier <xref target="RFC9263" format="default" sectionFormat="of" derivedContent="RFC9263"/>) that are used to influence the processing of
            the packet by SFC data plane elements. </t>
            <t indent="0" pn="section-3-5.1.2.7">An NSH OAM packet <bcp14>MAY</bcp14> include SFC OAM data in
            both Context Headers and the inner packet. The processing
            of the SFC OAM data (including the order) <bcp14>SHOULD</bcp14> be
            specified in the relevant OAM or Context Header
            specification. </t>
            <t indent="0" pn="section-3-5.1.2.8">SFC-aware implementations of SF, SFF, SFC Proxy, and Classifier
            that do not support SFC OAM procedures <bcp14>SHOULD</bcp14>
            discard packets with the O bit set but <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, 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 <bcp14>MUST</bcp14> be
            disabled by default. </t>
            <t indent="0" pn="section-3-5.1.2.9">The actual format and additional processing of NSH OAM packets
            is outside the scope of this specification.</t>
          </dd>
        </dl>
      </blockquote>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">This document has no IANA actions.</t>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">Data plane SFC-related security considerations, including privacy,
      are discussed in <xref target="RFC7665" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7665#section-6" derivedContent="RFC7665"/>
      and <xref target="RFC8300" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8300#section-8" derivedContent="RFC8300"/>. Additional
      security considerations related to SFC OAM are discussed in <xref target="RFC8924" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8924#section-9" derivedContent="RFC8924"/>.</t>
      <t indent="0" pn="section-5-2">Any data included in an NSH OAM packet <bcp14>SHOULD</bcp14> be
      integrity protected <xref target="RFC9145" format="default" sectionFormat="of" derivedContent="RFC9145"/>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8300" target="https://www.rfc-editor.org/info/rfc8300" quoteTitle="true" derivedAnchor="RFC8300">
          <front>
            <title>Network Service Header (NSH)</title>
            <author fullname="P. Quinn" initials="P." role="editor" surname="Quinn"/>
            <author fullname="U. Elzur" initials="U." role="editor" surname="Elzur"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <date month="January" year="2018"/>
            <abstract>
              <t indent="0">This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8300"/>
          <seriesInfo name="DOI" value="10.17487/RFC8300"/>
        </reference>
        <reference anchor="RFC9145" target="https://www.rfc-editor.org/info/rfc9145" quoteTitle="true" derivedAnchor="RFC9145">
          <front>
            <title>Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <date month="December" year="2021"/>
            <abstract>
              <t indent="0">This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9145"/>
          <seriesInfo name="DOI" value="10.17487/RFC9145"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC6291" target="https://www.rfc-editor.org/info/rfc6291" quoteTitle="true" derivedAnchor="RFC6291">
          <front>
            <title>Guidelines for the Use of the "OAM" Acronym in the IETF</title>
            <author fullname="L. Andersson" initials="L." surname="Andersson"/>
            <author fullname="H. van Helvoort" initials="H." surname="van Helvoort"/>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
            <author fullname="S. Mansfield" initials="S." surname="Mansfield"/>
            <date month="June" year="2011"/>
            <abstract>
              <t indent="0">At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.</t>
              <t indent="0">This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="161"/>
          <seriesInfo name="RFC" value="6291"/>
          <seriesInfo name="DOI" value="10.17487/RFC6291"/>
        </reference>
        <reference anchor="RFC7276" target="https://www.rfc-editor.org/info/rfc7276" quoteTitle="true" derivedAnchor="RFC7276">
          <front>
            <title>An Overview of Operations, Administration, and Maintenance (OAM) Tools</title>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
            <author fullname="E. Bellagamba" initials="E." surname="Bellagamba"/>
            <author fullname="Y. Weingarten" initials="Y." surname="Weingarten"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.</t>
              <t indent="0">This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.</t>
              <t indent="0">The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7276"/>
          <seriesInfo name="DOI" value="10.17487/RFC7276"/>
        </reference>
        <reference anchor="RFC7665" target="https://www.rfc-editor.org/info/rfc7665" quoteTitle="true" derivedAnchor="RFC7665">
          <front>
            <title>Service Function Chaining (SFC) Architecture</title>
            <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <date month="October" year="2015"/>
            <abstract>
              <t indent="0">This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7665"/>
          <seriesInfo name="DOI" value="10.17487/RFC7665"/>
        </reference>
        <reference anchor="RFC8924" target="https://www.rfc-editor.org/info/rfc8924" quoteTitle="true" derivedAnchor="RFC8924">
          <front>
            <title>Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework</title>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <author fullname="N. Kumar" initials="N." role="editor" surname="Kumar"/>
            <author fullname="R. Krishnan" initials="R." surname="Krishnan"/>
            <author fullname="A. Ghanwani" initials="A." surname="Ghanwani"/>
            <date month="October" year="2020"/>
            <abstract>
              <t indent="0">This document provides a reference framework for Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8924"/>
          <seriesInfo name="DOI" value="10.17487/RFC8924"/>
        </reference>
        <reference anchor="RFC8979" target="https://www.rfc-editor.org/info/rfc8979" quoteTitle="true" derivedAnchor="RFC8979">
          <front>
            <title>Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)</title>
            <author fullname="B. Sarikaya" initials="B." surname="Sarikaya"/>
            <author fullname="D. von Hugo" initials="D." surname="von Hugo"/>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">This document defines the Subscriber and Performance Policy Identifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriate Service Function Chaining (SFC) operations. The structure of each Context Header and their use and processing by NSH-aware nodes are described.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8979"/>
          <seriesInfo name="DOI" value="10.17487/RFC8979"/>
        </reference>
        <reference anchor="RFC9263" target="https://www.rfc-editor.org/info/rfc9263" quoteTitle="true" derivedAnchor="RFC9263">
          <front>
            <title>Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers</title>
            <author fullname="Y. Wei" initials="Y." role="editor" surname="Wei"/>
            <author fullname="U. Elzur" initials="U." surname="Elzur"/>
            <author fullname="S. Majee" initials="S." surname="Majee"/>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context metadata (MD) with each packet. Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers. This document specifies several such Context Headers that can be used within a Service Function Path (SFP).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9263"/>
          <seriesInfo name="DOI" value="10.17487/RFC9263"/>
        </reference>
      </references>
    </references>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to <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 indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Barry Leiba"/> for the art directorate
      review and <contact fullname="Russ Housley"/> for the security
      directorate review.</t>
      <t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Alvaro Retana"/> and <contact fullname="Robert Wilton"/> for their IESG reviews.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city>Rennes</city>
            <region/>
            <code>35000</code>
            <country>France</country>
          </postal>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
