<?xml version="1.0"encoding="utf-8"?>encoding="UTF-8"?> <!-- pre-edited by ST 03/14/24 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902" docName="draft-ietf-detnet-ip-oam-13" number="9634" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.6.0 --> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><front> <title abbrev="OAM for DetNet over IP">Operations, Administration, and Maintenance (OAM) for DeterministicNetworksNetworking (DetNet) with the IP Data Plane</title> <!-- [rfced] We have updated the document title along the lines of RFC 9546 and other cited RFCs, which define "DetNet" as "Deterministic Networking". Please let us know any concerns. Original: Operations, Administration, and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Currently: Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane --> <seriesInfoname="Internet-Draft" value="draft-ietf-detnet-ip-oam-13"/>name="RFC" value="9634"/> <author initials="G." surname="Mirsky" fullname="Greg Mirsky"> <organization>Ericsson</organization> <address> <email>gregimirsky@gmail.com</email> </address> </author> <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> <organization>Huawei</organization> <address><postal> <street/> <city/> <code/> <country/> </postal><email>mach.chen@huawei.com</email> </address> </author> <authorinitials="D"initials="D." surname="Black" fullname="David Black"> <organization>Dell EMC</organization> <address> <postal> <street>176 South Street</street><city>Hopkinton, MA</city><city>Hopkinton</city><region>MA</region> <code>01748</code> <country>United States of America</country> </postal> <email>david.black@dell.com</email> </address> </author> <date month="August" year="2024"/><area>Routing</area> <workgroup>DetNet Working Group</workgroup> <keyword>Internet-Draft</keyword><area>RTG</area> <workgroup>detnet</workgroup> <keyword>DetNet</keyword> <keyword>OAM</keyword> <abstract> <t> This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. </t> </abstract> </front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> <xref target="RFC8655" format="default"/> introduces and explains the DeterministicNetworksNetworking (DetNet) architecture. </t> <t> Operations, Administration, and Maintenance (OAM) protocols are used to detect and localize defects in the network as well as to monitor network performance. Some OAM functions (e.g., failuredetection),detection) work in the network proactively, while others (e.g., defect localization) are usually performedon-demand.on demand. These tasks are achieved by a combination of active and hybrid OAM methods, as defined in <xref target="RFC7799"/>. </t> <t> <xreftarget="I-D.ietf-detnet-oam-framework"target="RFC9551" format="default"/> lists the OAM functional requirements forDetNet,DetNet and defines the principles for OAM use within DetNet networks utilizing the IP data plane. The functional requirements can be compared against current OAM tools to identify gaps and potential enhancements required to enable proactive and on-demand path monitoring and service validation. </t> <t> This document discusses the use of existing IP OAM protocols and mechanisms in DetNet networks that use the IP data plane. </t> </section> <section numbered="true" toc="default"> <name>ConventionsusedUsed inthis document</name>This Document</name> <section numbered="true" toc="default"> <name>Terminology</name> <t> The term "DetNet OAM" as used in this documentinterchangeably with longer version "setalso means "a set of OAM protocols,methodsmethods, and tools for DeterministicNetworks".Networking". </t><t>DetNet: Deterministic Networks</t> <t>OAM: Operations,<dl spacing="normal"> <dt>DetNet:</dt><dd>Deterministic Networking</dd> <dt>OAM:</dt><dd>Operations, Administration, andMaintenance</t> <t>ICMP: InternetMaintenance</dd> <dt>ICMP:</dt><dd>Internet Control MessageProtocol</t> <t>UnderlayProtocol</dd> <dt>Underlay Network or UnderlayLayer: TheLayer:</dt><dd>The network that provides connectivity between DetNet nodes. MPLS networks providing Label Switched Path (LSP) connectivity between DetNet nodes are an example of the DetNet IP network underlay layer.</dd> <!-- [rfced] Section 2.1: We defined "LSP" as "Label Switched Path" per RFC 9546. If this is incorrect, please provide the correct definition of "LSP". Original: MPLS networks providing LSP connectivity between DetNet nodes are an example of the DetNet IP network underlaylayer.</t> <t>DetNet Node: alayer. Currently: MPLS networks providing Label Switched Path (LSP) connectivity between DetNet nodes are an example of the DetNet IP network underlay layer. --> <dt>DetNet Node:</dt><dd>A node that is an actor in the DetNet domain. DetNet domain edge nodes and nodes that perform the Packet Replication and Elimination Function within the domain are examples of a DetNetnode.</t> </section>node.</dd> <!--<section numbered="true" toc="default"> <name>Keywords</name> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",[rfced] Section 2.1: Does "Packet Replication and Elimination Function" mean "Packet Replication, Elimination, and"OPTIONAL"Ordering Functions" (as used in RFC 9546 and Section 3.3 of thisdocument are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when,document), "Packet Replication Function", "Packet Elimination andonly when, they appear in all capitals, as shown here. </t> </section>Replication Functions", or something else? Original: DetNet domain edge nodes and nodes that perform the Packet Replication and Elimination Function within the domain are examples of a DetNet node. --> </dl> </section> </section> <section anchor="oam-data-plane" numbered="true" toc="default"> <name>Active OAM for DetNet Networks with the IP Data Plane</name> <t> OAM protocols and mechanisms act within the data plane of the particular networking layer. Thus, it is critical that the data plane encapsulationsupportssupport OAM mechanisms andenablesenable them to be configured so that DetNet OAM packets follow the same path (unidirectional or bidirectional) through the network and receive the same forwarding treatment in the DetNet forwarding sub-layer as the DetNet flow being monitored. </t> <t> The DetNet data plane encapsulation in a transport network with IP encapsulations is specified inSection 6 of<xref target="RFC8939"format="default"/>.sectionFormat="of" section="6"/>. For the IP underlay network, DetNet flows are identified by the ordered match to the provisioned information set that, among other elements, includes the IPprotocol,protocol type, source port number, and destination port number. Active IP OAM protocols like Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" format="default"/> or the Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"format="default"/>,format="default"/> use UDP transport and the well-known UDP port numbers as the destination port. For BFD, the UDP destination port is specific to the BFD variant, e.g.,Multihopmultihop BFD uses port 4784 <xref target="RFC5883"/>. <!-- [rfced] Section 3: This sentence reads oddly, as it seems to mix both singular and plural. Should "the well-known UDP port numbers" be "the well-known UDP port number", or should "the destination port" be "the destination ports"? Original: Active IP OAM protocols like Bidirectional Forwarding Detection (BFD) [RFC5880] or Simple Two-way Active Measurement Protocol (STAMP) [RFC8762], use UDP transport and the well-known UDP port numbers as the destination port. --> </t> <t>ThusThus, a DetNet node must be able to associate an IP DetNet flow with the particular test session to ensure that test packets experience the same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality are based on 3-tuples (destination and source IP addresses in combination with the Differentiated Services Code Pointvalue)value), that association can be achieved by having the OAM traffic use the same 3-tuple as the monitored IP DetNet flow. In such a scenario, an IP OAM session between the same pair of IP nodes would share the network treatment with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMPprotocolis used. </t> <t> In IP networks, the majority of on-demand failure detection and localization is achieved through the use ofthe Internet Control Message Protocol (ICMP),ICMP, utilizing Echo Request and Echo Reply messages, along with a set of defined error messages such as Destination Unreachable, which provide detailed information through assigned code points. <xref target="RFC0792"/> and <xref target="RFC4443"/> definetheICMP for IPv4 and IPv6 networks, respectively. To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuring that such ICMP traffic traverses the same interfaces and receivesidenticalQoS treatmentasthat is identical to the monitored DetNet IP flow. Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane. </t> <section anchor="native-ip-section" numbered="true" toc="default"> <name>Mapping Active OAM and IP DetNetflows</name>Flows</name> <t> IP OAM protocols are used to detect failures (e.g., BFD <xref target="RFC5880"/>) and performance degradation (e.g., STAMP <xref target="RFC8762"/>) that affect an IP DetNet flow. It is essential to ensure that specially constructed OAM packets traverse the same set of nodes and links and receive the same network QoS treatment as the monitored data flow, e.g., a DetNet flow, for making active OAM useful. When the UDP destination port number used by the OAM protocol is assigned by IANA,thenjudicious selection of the UDP source port maybe able tohelp achieve co-routedness of OAM with the monitored IP DetNet flow in multipath environments, e.g., Link Aggregation Group or Equal Cost Multipath, via the use of a UDP source port value that results in the OAM traffic and the monitored IP DetNet flow hashing to the same path based on the packet header hashes used for path selection. This does assume that forwarding equipment along the multipath makes consistent hashing decisions, which might not always be true in a heterogeneous environment. (That also applies to the encapsulation techniques described in<xref target="ip-udp-section"/>Sections <xref target="ip-udp-section" format="counter"/> and <xreftarget="detnet-udp-section"/>.)target="detnet-udp-section" format="counter"/>.) To ensure the accuracy of OAM results in detecting failures and monitoring the performance of IP DetNet, it is essential that test packets not only traverse the same path as the monitored IP DetNet flow but also receive the same treatment by the nodes, e.g., shaping, filtering, policing, and availability of the pre-allocated resources, as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow can be achieved by using DetNet provisioning information (e.g., <xreftarget="I-D.ietf-detnet-yang"/>).target="RFC9633"/>). Each IP OAM protocol session is presented as a DetNetApplicationapplication with related service and forwarding sub-layers. The forwarding sub-layer of the IP OAM session is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information in the "ip-header" groupingip-header,item as defined in <xreftarget="I-D.ietf-detnet-yang"/>.target="RFC9633"/>. <!-- [rfced] Section 3.1: We had trouble following what "for making active OAM useful" applies to. If the suggested text is not correct, please provide clarifying text. Original: It is essential to ensure that specially constructed OAM packets traverse the same set of nodes and links and receive the same network QoS treatment as the monitored data flow, e.g., a DetNet flow, for making active OAM useful. Suggested: For active OAM to be useful, it is essential to ensure that specially constructed OAM packets traverse the same set of nodes and links and receive the same network QoS treatment as the monitored data flow, e.g., a DetNet flow. --> </t> </section> <section anchor="ip-udp-section" numbered="true" toc="default"> <name>Active OAM Using IP-in-UDP Encapsulation</name> <t> As described above, active IP OAM is realized through several protocols. Some protocols use UDP transport, while ICMP is a network-layer protocol. The amount of operational work mapping IP OAM protocols to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry IP test packets(<xref target="RFC2003"/>).<xref target="RFC2003"/>. Then, to ensure that OAM packets traverse the same set of nodes and links, the IP/UDP tunnel must be mapped to the monitored DetNet flow. Note that in such a case, the DetNet domain for the test packet is seen as a single IPlink in such a case.link. As a result, transit DetNet IP nodes cannot be traced using the usual traceroute procedure, and a modification of the traceroute may be required. <!-- [rfced] Section 3.2: We couldn't verify this citation, as we don't see "test packets" or "test" mentioned in RFC 2003. Would it help to rephrase as suggested? Original: The amount of operational work mapping IP OAM protocols to the monitored DetNet flow can be reduced by using an IP/UDP tunnel to carry IP test packets ([RFC2003]). Suggested (move the citation): The amount of operational work mapping IP OAM protocols to the monitored DetNet flow can be reduced by using an IP/UDP tunnel [RFC2003] to carry IP test packets. --> </t> </section> <section anchor="detnet-udp-section" numbered="true" toc="default"> <name>Active OAM Using DetNet-in-UDP Encapsulation</name> <t> Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation. Using a DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM test packets follow the same path through the network as the monitored IP DetNet flow packets and receive the same forwarding treatment in the DetNet forwarding sub-layer (seeSection 4.1.2 of<xreftarget="RFC8655"/>)target="RFC8655" sectionFormat="of" section="4.1.2"/>) as the IP DetNet flow being monitored. </t> <t> <xreftarget="I-D.ietf-detnet-mpls-over-ip-preof"/>target="RFC9566"/> describes how DetNet withMPLS over UDP/IPthe MPLS-over-UDP/IP data plane <xref target="RFC9025"/> can be used to support Packet Replication, Elimination, and Ordering Functions (PREOF) to potentially lower packet loss, improve the probability of on-time packetdeliverydelivery, and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored DetNet flow in the DetNet servicesub-layersub-layer, the encapsulation shown in <xref target="ip-detnet-udp-oam"/> is used. </t> <figure anchor="ip-detnet-udp-oam"> <name>DetNet Associated Channel Header Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------------------------------+ | | | DetNet App-Flow | | (original IP) Packet | | | +---------------------------------+ <--\ | DetNet ACH | | +---------------------------------+ +-->PREOF capablePREOF-capable | Service-ID (S-Label) | | DetNet IP data +---------------------------------+ | plane encapsulation | UDP Header | | +---------------------------------+ | | IP Header | | +---------------------------------+ <--/ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+ ]]></artwork> </figure> <t>where:Where: </t><ul empty="true"> <li>DetNet<t indent="3">DetNet ACH is the DetNet Associated Channel Header defined in <xreftarget="I-D.ietf-detnet-mpls-oam"/>.</li> <li>PREOFtarget="RFC9546"/>.</t> <t indent="3">PREOF if DetNet service sub-layer defined in <xref target="RFC8655"/>.</t> <!-- [rfced] Section 3.3: This sentence/phrase does not parse; it appears that some words are missing. If the suggested text is not correct, please clarify what "if" refers to. Original (the previous entry is included for context): DetNet ACH is the DetNet Associated Channel Header defined in [I-D.ietf-detnet-mpls-oam]. PREOF - Packet Replication, Elimination, and Ordering Functions if DetNet service sub-layer defined in<xref target="RFC8655"/>.</li> </ul>[RFC8655]. Suggested: DetNet ACH is the DetNet Associated Channel Header defined in [RFC9546]. PREOF is used for the DetNet service sub-layer as defined in [RFC8655]. --> </section> <section anchor="over-gre-section" numbered="true" toc="default"> <name>The Application of Y.1731/G.8013 Using GRE-in-UDP Encapsulation</name> <t> <xref target="RFC8086" format="default"/> has defined the method of encapsulating GRE (Generic Routing Encapsulation) headers in UDP. GRE-in-UDP encapsulation can be used for IP DetNetOAMOAM, as it eases the task of mapping an OAM test session to a particular IP DetNet flow that is identified by an N-tuple. Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow enables the use of Y.1731/G.8013 <xreftarget="ITU-T.1731"target="ITU.Y1731" format="default"/> as a comprehensive toolset of OAM. The Protocol Type field in the GRE header must be set to 0x8902, assigned by IANA to the IEEE 802.1ag Connectivity Fault Management (CFM)Protocolprotocol / ITU-T Recommendation Y.1731. Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e., continuitycheck,checks, one-way packetlossloss, and packet delaymeasurement.measurements. </t> </section> </section><!-- <section anchor="hybrid-oam" title="Use of Hybrid OAM in DetNet"> <t>Hybrid OAM methods are used in performance monitoring and defined in <xref target="RFC7799"/> as: <list> <t>Hybrid Methods are Methods of Measurement that use a combination of Active Methods and Passive Methods.</t> </list> A hybrid measurement method may produce metrics as close to passive, but it still alters something in a data packet even if that is the value of a designated field in the packet encapsulation. One example of such a hybrid measurement method is the Alternate Marking method (AMM) described in <xref target="RFC8321"/>. One of the advantages of the use of AMM in a DetNet domain with the IP data plane is that the marking is applied to a data flow, thus ensuring that measured metrics are directly applicable to the DetNet flow. </t> </section> --><section anchor="ip-over-tsn-sec" numbered="true" toc="default"> <name>Active OAM for DetNet IP Interworking with OAMof non-IPfor Non-IP DetNetdomains</name>Domains</name> <t> A domain in which the IP data plane provides DetNet service could be used in conjunction with aTSNTime-Sensitive Networking (TSN) network and a DetNet domain with the MPLS data plane to deliver end-to-end service. In such scenarios, the ability to detect defects and monitor performance using OAM is essential. <xreftarget="I-D.ietf-detnet-mpls-oam"target="RFC9546" format="default"/>identifiedidentifies two OAM interworking models--- peering and tunneling. Interworking between DetNet domains with IP and MPLS data planes is analyzed inSection 4.2 of<xreftarget="I-D.ietf-detnet-mpls-oam" format="default"/>.target="RFC9546" sectionFormat="of" section="4.2"/>. In addition, OAM interworking requirements and recommendations that apply between a DetNetDomaindomain with the MPLSdataplanedata plane and an adjacent TSN network also apply between a DetNet domain with the IPdataplanedata plane and an adjacent TSN network. </t> </section> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name> <t> This documentdoes not have any requests forhas no IANAallocation. This section can be deleted before the publication of the draft.actions. </t> </section> <section anchor="security-considerations" numbered="true" toc="default"> <name>Security Considerations</name> <t> This document describes the applicability of the existing Fault Management and Performance Monitoring IP OAM protocols. It does not raise any security concerns or issues in addition toonesthose common to networking or already documented in <xref target="RFC0792"/>, <xref target="RFC4443"/>, <xref target="RFC5880"/>, and <xref target="RFC8762"/> for the referenced DetNet and OAM protocols. </t> </section> </middle> <back><!-- References split into informative and normative --><references> <name>References</name> <references> <name>Normative References</name><!--<xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8086.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8086.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-mpls-oam.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/> <!-- draft-ietf-detnet-mpls-oam-15 (RFC 9546; published) --> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9546.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9025.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8939.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9025.xml"/> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-yang.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/> <!--<?rfc include="reference.RFC.6310"?> <?rfc include="reference.RFC.7023"?> <?rfc include="reference.I-D.ietf-detnet-ip-over-mpls"?> <?rfc include="reference.I-D.ietf-detnet-ip-over-tsn"?>draft-ietf-detnet-yang (RFC YYY1) Note: Title updated per YANG Doctors; should be OK. In AUTH48 as of 8/19/24 --> <reference anchor="RFC9633" target="https://www.rfc-editor.org/info/rfc9633"> <front> <title>Deterministic Networking (DetNet) YANG Data Model</title> <author initials="X." surname="Geng" fullname="Xuesong Geng"> <organization>Huawei Technologies</organization> </author> <author initials="Y." surname="Ryoo" fullname="Yeoncheol Ryoo"> <organization>ETRI</organization> </author> <author initials="D." surname="Fedyk" fullname="Don Fedyk"> <organization>LabN Consulting, L.L.C.</organization> </author> <author initials="R." surname="Rahman" fullname="Reshad Rahman"> <organization>Equinix</organization> </author> <author initials="Z." surname="Li" fullname="Zhenqiang Li"> <organization>China Mobile</organization> </author> <date month="August" year="2024" /> </front> <seriesInfo name="RFC" value="9633"/> <seriesInfo name="DOI" value="10.17487/RFC9633"/> </reference> </references> <references><name>Informational<name>Informative References</name> <referenceanchor="ITU-T.1731">anchor="ITU.Y1731"> <front><title>Operations,<title>Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks</title> <author> <organization>ITU-T</organization> </author> <datemonth="August" year="2015"/>month="June" year="2023"/> </front> <seriesInfoname="ITU-T"name="ITU-T Recommendation" value="G.8013/Y.1731"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/><!--<?rfc include="reference.RFC.8321"?>[rfced] References: The August 2015 version of this specification is marked "Superseded" on <https://www.itu.int/rec/T-REC-G.8013/en>. As the citation in Section 3.4 appears to be general in nature, we updated this listing per RFC 9546 accordingly. Please let us know any concerns. Original: [ITU-T.1731] ITU-T, "Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T G.8013/Y.1731, August 2015. Currently: [ITU.Y1731] ITU-T, "Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation G.8013/Y.1731, June 2023. --> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-oam-framework.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/> <!-- draft-ietf-detnet-oam-framework (RFC 9551; published) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9551.xml"/> <!-- ietf-detnet-mpls-over-ip-preof (RFC 9566; published) --> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-mpls-over-ip-preof.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9566.xml"/> </references> </references> </back> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>