rfc9451xml2.original.xml   rfc9451.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="4"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sfc-oam-pack
<?rfc compact="yes"?> et-03" number="9451" submissionType="IETF" category="std" consensus="true" ipr="
<?rfc subcompact="no"?> trust200902" updates="8300" obsoletes="" xml:lang="en" tocInclude="true" tocDept
<rfc category="std" docName="draft-ietf-sfc-oam-packet-03" ipr="trust200902" h="4" symRefs="true"
updates="8300"> sortRefs="true" version="3">
<front>
<title abbrev="SFC OAM Packet">OAM Packet and Behavior in the Network
Service Header (NSH)</title>
<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"/>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<region/>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<date year="2023" month="August"/>
<date /> <area>rtg</area>
<workgroup>sfc</workgroup> <workgroup>sfc</workgroup>
<keyword>Diagnostic</keyword> <keyword>Diagnostic</keyword>
<keyword>Troubelshooting</keyword> <keyword>Troubelshooting</keyword>
<keyword>Service Function Chaining</keyword> <keyword>Service Function Chaining</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>SDN</keyword> <keyword>SDN</keyword>
<keyword>Programmable Networks</keyword> <keyword>Programmable Networks</keyword>
<keyword>Service Differentiation</keyword> <keyword>Service Differentiation</keyword>
<abstract> <abstract>
<t>This document clarifies an ambiguity in the Network Service Header <t>This document clarifies an ambiguity in the Network Service Header
(NSH) specification related to the handling of O bit. In particular, (NSH) specification related to the handling of O bit. In particular,
this document clarifies the meaning of "OAM packet".</t> this document clarifies the meaning of "OAM packet".</t>
<t>This document updates RFC 8300.</t> <t>This document updates RFC 8300.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>This document clarifies an ambiguity related to the definition of <t>This document clarifies an ambiguity related to the definition of
Operations, Administration, and Maintenance (OAM) packet discussed in the Operations, Administration, and Maintenance (OAM) packet discussed in
<xref target="RFC8300"></xref>.</t> <xref target="RFC8300" format="default"/>.</t>
<t>Processing of the O bit in the Network Service Header (NSH) must
<t>The processing of the O bit in the Network Service Header (NSH) must follow the updated behavior specified in <xref target="anupdate"
follow the updated behavior specified in <xref format="default"/>.</t>
target="anupdate"></xref>.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
</t>
<t>This document makes use of the terms defined in <xref <t>This document makes use of the terms defined in <xref
target="RFC7665"></xref> and <xref target="RFC8300"></xref>.</t> target="RFC7665" format="default"/> and <xref target="RFC8300"
format="default"/>.</t>
<t>The document defines the following terms:<list style="hanging"> <t>The document defines the following terms:</t>
<t hangText="SFC data plane element:">refers to SFC-aware Service <dl newline="false" spacing="normal">
Function (SF), Service Function Forwarder (SFF), SFC Proxy, or <dt>Service Function Chaining (SFC) data plane element:</dt>
Classifier as defined in the SFC data plane architecture <xref <dd>refers to the SFC-aware Service Function (SF), Service Function
target="RFC7665"></xref> and further refined in <xref Forwarder (SFF), SFC Proxy, or Classifier as defined in the SFC data
target="RFC8300"></xref>.</t> plane architecture <xref target="RFC7665" format="default"/> and
further refined in <xref target="RFC8300" format="default"/>.</dd>
<t hangText="OAM control element:">an NSH-aware element that is <dt>OAM control element:</dt>
capable of generating NSH OAM packets. An SFC data plane element may <dd>an NSH-aware element that is capable of generating NSH OAM
behave as an OAM control element.</t> packets. An SFC data plane element may behave as an OAM control
element.</dd>
<t hangText="SFC OAM data:">refers to an OAM request (e.g., <dt>SFC OAM data:</dt>
Connectivity Verification and Continuity Checks <xref <dd>refers to an OAM request (e.g., Connectivity Verification and
target="RFC7276"></xref>), any data that influences how to execute a Continuity Checks <xref target="RFC7276" format="default"/>), any data
companion OAM request (e.g., identity of a terminating SF), the that influences how to execute a companion OAM request (e.g., identity
output data of an OAM request, and any combination thereof.</t> of a terminating SF), the output data of an OAM request, and any
combination thereof.</dd>
<t hangText="User data:">refers to user packets cited in Section 5.7 <dt>User data:</dt>
of <xref target="RFC7665"></xref>.</t> <dd>refers to user packets cited in <xref target="RFC7665"
</list></t> sectionFormat="of" section="5.7"/>.</dd>
</dl>
</section> </section>
<section anchor="anupdate" numbered="true" toc="default">
<name>An Update to RFC 8300</name>
<t>This document updates <xref target="RFC8300" sectionFormat="of"
section="2.2"/> as follows:</t>
<section anchor="anupdate" title="An Update to RFC8300"> <t>OLD:</t>
<t>This document updates Section 2.2 of <xref target="RFC8300"></xref>
as follows:</t>
<t><list style="hanging"> <blockquote>
<t hangText="OLD: "><vspace blankLines="1" /><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="O bit:">Setting this bit indicates an OAM packet <dt>O bit:</dt>
(see [RFC6291]). The actual format and processing of SFC OAM <dd><t>Setting this bit indicates an OAM packet (see <xref
packets is outside the scope of this specification (for example, target="RFC6291" format="default"/>). The actual format and
see [SFC-OAM-FRAMEWORK] for one approach).<vspace processing of SFC OAM packets is outside the scope of this
blankLines="1" />The O bit MUST be set for OAM packets and MUST specification (for example, see [SFC-OAM-FRAMEWORK] for one
NOT be set for non-OAM packets. The O bit MUST NOT be modified approach).</t>
along the SFP.<vspace blankLines="1" />SF/SFF/SFC <t>The O bit <bcp14>MUST</bcp14> be set for OAM packets and
Proxy/Classifier implementations that do not support SFC OAM <bcp14>MUST NOT</bcp14> be set for non-OAM packets. The O bit
procedures SHOULD discard packets with O bit set, but MAY <bcp14>MUST NOT</bcp14> be modified along the SFP.</t>
support a configurable parameter to enable forwarding received <t>SF/SFF/SFC Proxy/Classifier implementations that do not support
SFC OAM packets unmodified to the next element in the chain. SFC OAM procedures <bcp14>SHOULD</bcp14> discard packets with O
Forwarding OAM packets unmodified by SFC elements that do not bit set, but <bcp14>MAY</bcp14> support a configurable parameter
support SFC OAM procedures may be acceptable for a subset of OAM to enable forwarding received SFC OAM packets unmodified to the
functions, but it can result in unexpected outcomes for others; next element in the chain. Forwarding OAM packets unmodified by
thus, it is recommended to analyze the impact of forwarding an SFC elements that do not support SFC OAM procedures may be
OAM packet for all OAM functions prior to enabling this acceptable for a subset of OAM functions, but it can result in
behavior. The configurable parameter MUST be disabled by unexpected outcomes for others; thus, it is recommended to analyze
default.</t> the impact of forwarding an OAM packet for all OAM functions prior
</list></t> to enabling this behavior. The configurable parameter
<bcp14>MUST</bcp14> be disabled by default.</t>
</dd>
</dl>
</blockquote>
<t hangText="NEW: "><vspace blankLines="1" /><list style="hanging"> <t>NEW:</t>
<t hangText="O bit:">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 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, the last SFF of an SFP). <vspace
blankLines="1" />The O bit MUST be set for NSH OAM packets and
MUST NOT be set for non-OAM packets. The O bit MUST NOT be
modified along the SFP.<vspace blankLines="1" />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 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 MAY 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 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 NSH OAM
packet MAY include optional Context Headers (e.g., a subscriber
identifier <xref target="RFC8979"></xref> or a flow identifier
<xref target="RFC9263"></xref>) that are used to influence the
processing of the packet by SFC data plane elements. <vspace
blankLines="1" />An NSH OAM packet MAY include SFC OAM data in
both Context Headers and the inner packet. The processing
(including the order) of the SFC OAM data SHOULD be specified in
the relevant OAM or Context Header specification. <vspace
blankLines="1" />SFC-aware SF/SFF/SFC Proxy/Classifier
implementations that do not support SFC OAM procedures SHOULD
discard packets with the O bit set, but MAY 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 MUST be
disabled by default. <vspace blankLines="1" />The actual format
and additional processing of NSH OAM packets is outside the
scope of this specification.</t>
</list></t>
</list></t>
</section>
<section title="IANA Considerations"> <blockquote>
<t>This document does not make any request to IANA.</t> <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. </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 or the last SFF of an SFP). </t>
<t>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>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>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>An NSH OAM packet <bcp14>MAY</bcp14> include optional Context
Headers (e.g., a subscriber identifier <xref target="RFC8979"
format="default"/> or a flow identifier <xref target="RFC9263"
format="default"/>) that are used to influence the processing of
the packet by SFC data plane elements. </t>
<t>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>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>The actual format and additional processing of NSH OAM packets
is outside the scope of this specification.</t>
</dd>
</dl>
</blockquote>
</section> </section>
<section anchor="security" title="Security Considerations"> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Data plane SFC-related security considerations, including privacy, <t>Data plane SFC-related security considerations, including privacy,
are discussed in Section 6 of <xref target="RFC7665"></xref> and Section are discussed in <xref target="RFC7665" sectionFormat="of" section="6"/>
8 of <xref target="RFC8300"></xref>. Additional security considerations and <xref target="RFC8300" sectionFormat="of" section="8"/>. Additional
related to SFC OAM are discussed in Section 9 of <xref security considerations related to SFC OAM are discussed in <xref
target="RFC8924"></xref>.</t> target="RFC8924" sectionFormat="of" section="9"/>.</t>
<t>Any data included in an NSH OAM packet <bcp14>SHOULD</bcp14> be
<t>Any data included in an NSH OAM packet SHOULD be integrity-protected integrity protected <xref target="RFC9145" format="default"/>.</t>
<xref target="RFC9145"></xref>.</t>
</section> </section>
<section anchor="ack" title="Acknowledgments">
<t>Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian
Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners for the
comments.</t>
<t>Thanks to Barry Leiba for the art directorate review and Russ Housley
for the security directorate review.</t>
<t>Thanks to Alvaro Retana and Robert Wilton for the IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?> <references>
<name>References</name>
<?rfc include='reference.RFC.8300'?> <references>
<name>Normative References</name>
<?rfc include='reference.RFC.9145'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
145.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
979.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
263.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
924.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
276.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
291.xml"/>
</references>
</references> </references>
<references title="Informative References"> <section anchor="ack" numbered="false" toc="default">
<?rfc include='reference.RFC.7665'?> <name>Acknowledgments</name>
<t>Thanks to <contact fullname="Jim Guichard"/>, <contact fullname="Greg
<?rfc include='reference.RFC.8979'?> Mirsky"/>, <contact fullname="Joel Halpern"/>, <contact
fullname="Christian Jacquenet"/>, <contact fullname="Dirk von-Hugo"/>,
<?rfc include='reference.RFC.9263'?> <contact fullname="Carlos Pignataro"/>, and <contact fullname="Frank
Brockners"/> for the comments.</t>
<?rfc include='reference.RFC.8924'?>
<?rfc include='reference.RFC.7276'?>
<?rfc include='reference.RFC.6291'?> <t>Thanks to <contact fullname="Barry Leiba"/> for the art directorate
</references> review and <contact fullname="Russ Housley"/> for the security
directorate review.</t>
<t>Thanks to <contact fullname="Alvaro Retana"/> and <contact
fullname="Robert Wilton"/> for their IESG reviews.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 35 change blocks. 
192 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.48.