<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-ippm-ioam-yang-13"ipr="trust200902">number="9617" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="YANG Data Model for IOAM">A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)</title> <!-- [rfced] Document title: We updated the full and running document titles (running title updated per guidance received from Benoit Claise and the YANG Doctors that "YANG data model" is preferred). Please let us know any objections. Original full and running titles: A YANG Data Model for In-SituOAM</title>OAM ... YANG Model for IOAM Currently (running title in PDF output file only): A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) ... YANG Data Model for IOAM --> <seriesInfo name="RFC" value="9617"/> <author fullname="Tianran Zhou" initials="T."surname="Zhou, Ed.">surname="Zhou" role="editor"> <organization>Huawei</organization> <address> <postal> <street>156 Beiqing Rd.</street> <city>Beijing</city> <code>100095</code><region/><country>China</country> </postal> <email>zhoutianran@huawei.com</email> </address> </author> <author fullname="Jim Guichard" initials="J." surname="Guichard"> <organization>Futurewei</organization> <address> <postal><street/> <city/> <code/> <region/><country>United States of America</country> </postal> <email>james.n.guichard@futurewei.com</email> </address> </author> <author fullname="Frank Brockners" initials="F." surname="Brockners"> <organization>Cisco Systems</organization> <address> <postal> <street>Hansaallee 249, 3rd Floor</street><city>Duesseldorf</city> <region>Nordrhein-Westfalen</region><city>Düsseldorf, Nordrhein-Westfalen</city> <code>40549</code> <country>Germany</country> </postal><phone/> <facsimile/><email>fbrockne@cisco.com</email><uri/></address> </author> <author fullname="Srihari Raghavan" initials="S." surname="Raghavan"> <organization>Cisco Systems</organization> <address> <postal> <street>Tril Infopark Sez, Ramanujan IT City</street> <street>Neville Block, 2nd floor, Old Mahabalipuram Road</street> <city>Chennai</city> <region>Tamil Nadu</region> <code>600113</code> <country>India</country> </postal><phone/> <facsimile/><email>srihari@cisco.com</email><uri/></address> </author> <dateday="01" month="March"month="July" year="2024"/><workgroup>IPPM</workgroup><area>OPS</area> <workgroup>ippm</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> <abstract><t>In-situ<t>In situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a methodto producefor producing operational and telemetry information that may be exported using the in-band or out-of-band method.RFC9197RFCs 9197 andRFC93269326 discuss the data fields and associated data types for IOAM. This document defines a YANG module for the configuration of IOAM functions.</t> </abstract> </front> <middle> <sectiontitle="Introduction"> <t>In-situnumbered="true" toc="default"> <name>Introduction</name> <t>In situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a methodto producefor producing operational and telemetry information that may be exported using the in-band or out-of-band method. The data types and data formats for IOAM data records have been defined in <xreftarget="RFC9197"/>target="RFC9197" format="default"/> and <xreftarget="RFC9326"/>.target="RFC9326" format="default"/>. The IOAM data can be embedded in many protocolencapsulationsencapsulations, such as the NetworkServicesService Header (NSH) <xref target="RFC9452"/> and IPv6.</t> <t>This document defines a data model for the configuration of IOAM capabilities using the <xreftarget="RFC7950">YANGtarget="RFC7950" format="default">YANG data modeling language</xref>. This YANG data model supports five IOAM options, whichare:</t> <t><list style="symbols">are as follows:</t> <ul spacing="normal"> <li> <t><xreftarget="RFC9197">Incrementaltarget="RFC9197" format="default">Incremental Tracing Option </xref></t> </li> <li> <t><xreftarget="RFC9197">Pre-allocatedtarget="RFC9197" format="default">Pre-allocated Tracing Option</xref></t> </li> <li> <t><xreftarget="RFC9326">Directtarget="RFC9326" format="default">Direct Export Option</xref></t> </li> <li> <t><xreftarget="RFC9197">Prooftarget="RFC9197" format="default">Proof of Transit(PoT)(POT) Option</xref></t> </li> <li> <t><xreftarget="RFC9197">Edge-to-Edgetarget="RFC9197" format="default">Edge-to-Edge Option</xref></t></list></t> </section> <section title="Conventions</li> <!-- [rfced] Section 1: We see different wordings used in RFCs 9197 and 9326 for the following terms, as compared to this document. Will the different wordings be clear to readers? Original: * Incremental Tracing Option [RFC9197] * Pre-allocated Tracing Option [RFC9197] * Direct Export Option [RFC9326] * Proof of Transit (PoT) Option [RFC9197] * Edge-to-Edge Option [RFC9197] ... We see the following in thisdocument">document's text: preallocated tracing option (we have changed "preallocated" to "pre-allocated") incremental tracing option direct export option proof of transit option (and POT option) edge-to-edge option We see the following in the cited RFCs: Incremental Trace Option-Type (RFC 9197) Pre-allocated Trace Option-Type (RFC 9197) Direct Export (DEX) Option-Type and Direct Exporting (DEX) IOAM-Option-Type (RFC 9326) POT Option-Type (RFC 9197) Edge-to-Edge Option-Type (RFC 9197) --> </ul> </section> <section numbered="true" toc="default"> <name>Conventions Used in This Document</name> <t>Thekeywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP14,BCP 14 <xreftarget="RFC2119"/>,target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>The following terms are defined in <xreftarget="RFC7950"/>target="RFC7950" format="default"/> and are used in this specification:<list style="symbols"></t> <ul spacing="normal"> <li> <t>augment</t> </li> <li> <t>data model</t> </li> <li> <t>data node</t></list>The</li> </ul> <t>The terminology for describing YANG data models is found in <xreftarget="RFC7950"/>.</t>target="RFC7950" format="default"/>.</t> <section anchor="tree-diagrams"title="Tree Diagrams">numbered="true" toc="default"> <name>Tree Diagrams</name> <t>Tree diagrams used in this document follow the notation defined in <xreftarget="RFC8340"/>.</t>target="RFC8340" format="default"/>.</t> </section> </section> <sectiontitle="Designnumbered="true" toc="default"> <name>Design of the IOAM YANG DataModel"> <t/>Model</name> <sectiontitle="Overview">numbered="true" toc="default"> <name>Overview</name> <t>The IOAM model is organized as a list ofprofilesprofiles, as shown in the following figure. Each profile associates with one flow and the corresponding IOAM information.</t><t><figure> <artwork><![CDATA[module:<!-- [rfced] Sourcecode a) We updated <artwork> to <sourcecode> in several instances in the document. Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) does not contain an applicable type, please let us know. Also, it is acceptable to leave the "type" attribute unset. b) Should <artwork> in Appendices A-E be tagged as <sourcecode type="xml">? If so, we will add the following as a normative reference. Please let us know the best placement for the citation in the text. You can see RFCs 9587, 9403, and 8194 for examples. [W3C.REC-xml11-20060816] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>. --> <sourcecode type="yangtree"><![CDATA[module: ietf-ioam +--rw ioam +--ro info | +--ro timestamp-type? identityref | +--ro available-interface* [if-name] | +--ro if-name if:interface-ref +--rw admin-config | +--rw enabled? boolean +--rw profiles +--rw profile* [profile-name] +--rw profile-name string +--rw filter | +--rw filter-type? ioam-filter-type | +--rw ace-name? -> /acl:acls/acl/aces/ace/name +--rw protocol-type? ioam-protocol-type +--rw incremental-tracing-profile {incremental-trace}? | ... +--rw preallocated-tracing-profile {preallocated-trace}? | ... +--rw direct-export-profile {direct-export}? | ... +--rw pot-profile {proof-of-transit}? | ... +--rw e2e-profile {edge-to-edge}?...]]></artwork> </figure></t>]]></sourcecode> <t>The "info" parameter is a container for all the read-only information that assists monitoring systems in the interpretation of the IOAM data.</t> <t>The "enabled" parameter is an administrative configuration. When it is set totrue,"true", IOAM configuration is enabled for the system. Meanwhile, the IOAMdata-planedata plane functionality is enabled.</t> <t>The "filter" parameter is used to identify a flow, where the IOAM profile can apply. There may be multiple filter types. <xreftarget="RFC8519">ACL</xref> istarget="RFC8519" format="default">Access Control Lists (ACLs)</xref> provide a common way to specify a flow. Each IOAM profile can associate with anACE(AccessACE (Access Control Entry). When the matched ACE "forwarding" action is "accept", IOAM actionsMUST<bcp14>MUST</bcp14> be driven by the acceptedpackets, when the matched ACE "forwarding" action is "accept".</t>packets.</t> <t>The IOAM data can be encapsulated into multiple protocols, e.g., <xreftarget="RFC9486">IPv6</xref>target="RFC9486" format="default">IPv6</xref> and <xreftarget="RFC9452">NSH</xref>.target="RFC9452" format="default">the NSH</xref>. The "protocol-type" parameter is used to indicate wheretheIOAM is applied. For example, ifthe"protocol-type" isIPv6,set to "ipv6", the IOAM ingress node will encapsulate the associated flow with the IPv6-IOAM <xreftarget="RFC9486">IPv6-IOAM</xref>target="RFC9486" format="default"/> format.</t> <t>In this document, IOAM data includes five encapsulation types, i.e., incremental tracing data,preallocatedpre-allocated tracing data, direct export data, proof of transitdatadata, andend to endend-to-end data. In practice, multiple IOAM data types can be encapsulated into the same IOAM header. The "profile" parameter contains a set of sub-profiles, each of which relates to one encapsulation type. The configured object may not support all the sub-profiles. The supported sub-profiles are indicated by5five defined features, i.e., "incremental-trace", "preallocated-trace", "direct-export","proof-of-transit""proof-of-transit", and"edge-to-edge".</t>"edge-to-edge". <!-- [rfced] Section 3.1: Does 'IPv6-IOAM [RFC9486] format' mean '"IOAM in IPv6" format, per [RFC9486]' or something else? We ask because we do not see "IPv6-IOAM" used in RFC 9486 or any other published RFC. Original: For example, if the "protocol-type" is IPv6, the IOAM ingress node will encapsulate the associated flow with the IPv6-IOAM [RFC9486] format. --> </t> <t>This document uses the <xreftarget="RFC8519">Access Control Listtarget="RFC8519" format="default">"ietf-access-control-list" YANG module</xref>, the <xreftarget="RFC8343">Interfacestarget="RFC8343" format="default">"ietf-interfaces" YANGmodule</xref>module</xref>, and the <xreftarget="RFC8532">LIME Time Typestarget="RFC8532" format="default">"ietf-lime-time-types" YANG module</xref>.</t> <t>The YANG data model in this documentconformconforms to the Network Management Datastore Architecture (NMDA) defined in <xreftarget="RFC8342"/>.</t>target="RFC8342" format="default"/>.</t> </section> <sectiontitle="Preallocatednumbered="true" toc="default" anchor="prealloc-tracing"> <name>Pre-allocated TracingProfile"> <t>TheProfile</name> <t>To ensure visibility into the entire path that a packet takes within an IOAM domain, the IOAM tracing data is expected to be collected at every node that a packettraverses to ensure visibility into the entire path a packet takes within an IOAM domain.traverses. Thepreallocatedpre-allocated tracing option will create pre-allocated space for each node to populate itsinformation .information. The "preallocated-tracing-profile" parameter contains the detailed information for thepreallocatedpre-allocated tracing data.TheThis information includes:</t><t><list style="symbols"> <t>node-action: indicates<dl spacing="normal"> <dt>node-action:</dt><dd>indicates the operation (e.g., encapsulate the IOAM header, transit the IOAM data, or decapsulate the IOAM header) applied to the dedicatedflow.</t> <t>use-namespace: indicatesflow.</dd> <dt>use-namespace:</dt><dd>indicates the namespace used for the tracetypes.</t> <t>trace-type: indicatestypes.</dd> <dt>trace-type:</dt><dd>indicates the per-hop data to be captured bythe IOAM enabledIOAM-enabled nodes and included in the node datalist.</t> <t>max-length: specifieslist.</dd> <dt>max-length:</dt><dd>specifies the maximum length of the node data list in octets.The max-length "max-length" is only defined at the encapsulationnode.</t> </list><figure align="center"> <artwork><![CDATA[+--rwnode.</dd> </dl> <sourcecode type="yangtree"><![CDATA[+--rw preallocated-tracing-profile {preallocated-trace}? +--rw node-action? ioam-node-action +--rw trace-types | +--rw use-namespace? ioam-namespace | +--rw trace-type* ioam-trace-type +--rw max-length?uint32]]></artwork> </figure></t>uint32 ]]></sourcecode> </section> <sectiontitle="Incrementalnumbered="true" toc="default"> <name>Incremental TracingProfile">Profile</name> <t>The incremental tracing option contains a variable node data fields where each node allocates and pushes its node data immediately following the option header. The "incremental-tracing-profile" parameter contains the detailed information for the incremental tracing data.The detailedThis information is the same as that for thePreallocatedPre-allocated TracingProfile.</t> <t><figure align="center"> <artwork><![CDATA[+--rwProfile; see <xref target="prealloc-tracing"/>. <!-- [rfced] Section 3.3: "a variable node data fields" does not parse. If the suggested text is not correct, please clarify. Original: The incremental tracing option contains a variable node data fields where each node allocates and pushes its node data immediately following the option header. Suggested: The incremental tracing option contains a variable-length list of node data fields, where each node allocates and pushes its node data immediately following the option header. --> </t> <sourcecode type="yangtree"><![CDATA[+--rw incremental-tracing-profile {incremental-trace}? +--rw node-action? ioam-node-action +--rw trace-types | +--rw use-namespace? ioam-namespace | +--rw trace-type* ioam-trace-type +--rw max-length?uint32]]></artwork> </figure></t>uint32 ]]></sourcecode> </section> <sectiontitle="Directnumbered="true" toc="default"> <name>Direct ExportProfile">Profile</name> <t>The direct export option is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The "direct-export-profile" parameter contains the detailed information for the direct export data.The detailedThis information is the same as that for thePreallocatedPre-allocated TracingProfile,Profile (<xref target="prealloc-tracing"/>), but with two more optional variables:</t><t><list style="symbols"> <t>flow-id: is used<dl spacing="normal"> <dt>flow-id:</dt><dd>used to correlate the exported data of the same flow from multiple nodes and from multiplepackets.</t> <t>enable-sequence-number: indicatespackets.</dd> <dt>enable-sequence-number:</dt><dd>indicates whether the sequence number is used in the direct exportoption.</t> </list><figure> <artwork><![CDATA[+--rwoption.</dd> </dl> <sourcecode type="yangtree"><![CDATA[+--rw direct-export-profile {direct-export}? +--rw node-action? ioam-node-action +--rw trace-types | +--rw use-namespace? ioam-namespace | +--rw trace-type* ioam-trace-type +--rw flow-id? uint32 +--rw enable-sequence-number?boolean]]></artwork> </figure></t>boolean ]]></sourcecode> </section> <sectiontitle="Proofnumbered="true" toc="default"> <name>Proof of TransitProfile">Profile</name> <t>The IOAMProofproof ofTransittransit data is used to support the path or service function chain verification use cases. The "pot-profile" parameter is intended to contain the detailed information for the proof of transit data. The "use-namespace" parameter indicates the namespace used for the POT types. The "pot-type" parameter indicates a particular POT variant that specifies the POT data that is included. There may be several POT types,which haveeach having different configuration data. To align with <xreftarget="RFC9197"/>,target="RFC9197" format="default"/>, this document only defines IOAM POT type 0.UserUsers need to augment this module for the configuration of aspecifcspecific POT type.</t><t><figure align="center"> <artwork><![CDATA[+--rw<sourcecode type="yangtree"><![CDATA[+--rw pot-profile {proof-of-transit}? +--rw use-namespace? ioam-namespace +--rw pot-type?ioam-pot-type]]></artwork> </figure></t>ioam-pot-type ]]></sourcecode> </section> <sectiontitle="Edge-to-Edge Profile">numbered="true" toc="default"> <name>Edge-to-Edge Profile</name> <t>The IOAM edge-to-edge option is used to carry data that is added by the IOAM encapsulating node and interpreted by the IOAM decapsulating node. The "e2e-profile" parameter contains the detailed information for the edge-to-edge data.The detailedThis information includes:</t><t><list style="symbols"> <t>node-action is the<dl spacing="normal"> <dt>node-action:</dt><dd>the same semantic as that provided inSection 3.2.</t> <t>use-namespace: indicate<xref target="prealloc-tracing"/>.</dd> <dt>use-namespace:</dt><dd>indicates the namespace used for the edge-to-edgetypes.</t> <t>e2e-type: indicatestypes.</dd> <dt>e2e-type:</dt><dd>indicates data to be carried from the ingress IOAM node to the egress IOAMnode.</t> </list><figure align="center"> <artwork><![CDATA[+--rwnode.</dd> </dl> <sourcecode type="yangtree"><![CDATA[+--rw e2e-profile {edge-to-edge}? +--rw node-action? ioam-node-action +--rw e2e-types +--rw use-namespace? ioam-namespace +--rw e2e-type*ioam-e2e-type]]></artwork> </figure></t>ioam-e2e-type ]]></sourcecode> </section> </section> <sectiontitle="IOAMnumbered="true" toc="default"> <name>IOAM YANGModule"> <t/> <t><figure> <artwork><![CDATA[<CODEModule</name> <t>The "ietf-ioam" module defined in this document imports typedefs from <xref target="RFC8519"/>, <xref target="RFC8343"/>, and <xref target="RFC8532"/>. This document also references <xref target="RFC9197"/>, <xref target="RFC9326"/>, <xref target="RFC9486"/>, and <xref target="RFC9452"/>. <!-- [rfced] Section 4: We updated this paragraph to more closely match comparable introductory paragraphs in other YANG RFCs (i.e., all RFCs mentioned in the YANG module are listed in the introductory paragraph). Please let us know any objections. Original: 4. IOAM YANG Module <CODE BEGINS> file "ietf-ioam@2024-03-01.yang" Currently (assuming that "typedefs" is the correct term): 4. IOAM YANG Module The "ietf-ioam" module defined in this document imports typedefs from [RFC8519], [RFC8343], and [RFC8532]. This document also references [RFC9197], [RFC9326], [RFC9486], and [RFC9452]. <CODE BEGINS> file "ietf-ioam@2024-03-01.yang" --> </t> <!--[rfced] Section 4: May we update the YANG module as shown in this diff file? https://www.rfc-editor.org/authors/ietf-ioam@2024-07-12-rfcdiff.html It compares the current module to the output of the formatting tool. Per guidance from Martin Bjorklund, this is using pyang to format the module (as described on the IETF YANG review tools wiki page (https://wiki.ietf.org/group/ops/yang-review-tools)). To be clear, with or without the formatting updates, the YANG module parses. --> <sourcecode name="ietf-ioam@2024-07-12.yang" type="yang" markers="true"><![CDATA[ module ietf-ioam { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; prefix "ioam"; import ietf-access-control-list { prefix "acl"; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-lime-time-types { prefix "lime"; reference "RFC 8532: Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications"; } organization "IETF IPPM (IP PerformanceMetrics)Measurement) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/ippm> WG List:<ippm@ietf.org><mailto:ippm@ietf.org> Editor:zhoutianran@huawei.comTianran Zhou <mailto:zhoutianran@huawei.com> Editor:james.n.guichard@futurewei.comJim Guichard <mailto:james.n.guichard@futurewei.com> Editor:fbrockne@cisco.comFrank Brockners <mailto:fbrockne@cisco.com> Editor:srihari@cisco.com";Srihari Raghavan <mailto:srihari@cisco.com>"; description "This YANG module specifies a vendor-independent data model fortheIn SituOAMOperations, Administration, and Maintenance (IOAM). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX (https://www.rfc-editor.org/info/rfcXXXX);9617; see the RFC itself for full legal notices."; revision2024-03-012024-07-12 { description "Initial revision."; reference "RFCXXXX:9617: A YANG Data Model forIn-Situ OAM";In Situ Operations, Administration, and Maintenance (IOAM)"; } /* * FEATURES */ feature incremental-trace { description "This featureindicatedindicates that the incremental tracing option is supported."; reference "RFC 9197: Data Fields forIn-situ OAM";In Situ Operations, Administration, and Maintenance (IOAM)"; } feature preallocated-trace { description "This featureindicatedindicates that thepreallocatedpre-allocated tracing option is supported."; reference "RFC 9197: Data Fields forIn-situ OAM";In Situ Operations, Administration, and Maintenance (IOAM)"; } feature direct-export { description "This featureindicatedindicates that the direct export option is supported."; reference "RFC 9326:In-situ OAMIn Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting"; } feature proof-of-transit { description "This featureindicatedindicates that the proof of transit option issupported";supported."; reference "RFC 9197: Data Fields forIn-situ OAM";In Situ Operations, Administration, and Maintenance (IOAM)"; } feature edge-to-edge { description "This featureindicatedindicates that the edge-to-edge option is supported."; reference "RFC 9197: Data Fields forIn-situ OAM";In Situ Operations, Administration, and Maintenance (IOAM)"; } /* * IDENTITIES */ identity filter { description "Base identity to represent a filter. A filter is used to specify the flow to apply the IOAMprofile. ";profile."; } identity acl-filter { base filter; description "ApplyACLAccess Control List (ACL) rules to specify the flow."; } identity protocol { description "Base identity to represent the carrier protocol.It'sIt is used to indicate in what layer and protocol the IOAM data is embedded."; } identity ipv6 { base protocol; description "The described IOAM data is embedded inIPv6 protocol.";IPv6."; reference "RFC 9486:In-situ OAMIPv6Options";Options for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity nsh { base protocol; description "The described IOAM data is embedded inNSH.";the Network Service Header (NSH)."; reference "RFC 9452: Network Service Header (NSH) Encapsulation forIn-situIn Situ OAM (IOAM) Data"; } identity node-action { description "Base identity to represent the node actions.It'sIt is used to indicate what action the node will take."; } identity action-encapsulate { base node-action; description"It"This identity indicates that the node is used to encapsulate the IOAMpacket";packet."; } identity action-decapsulate { base node-action; description"It"This identity indicates that the node is used to decapsulate the IOAMpacket";packet."; } identity action-transit { base node-action; description"It"This identity indicates that the node is used to transit the IOAMpacket";packet."; } identity trace-type { description "Base identity to represent trace types."; } identity trace-hop-lim-node-id { base trace-type; description"It"This identity indicates the presence ofHop_Lim'Hop_Lim' andnode_id'node_id' in the node data."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity trace-if-id { base trace-type; description"It"This identity indicates the presence ofingress_if_id'ingress_if_id' andegress_if_id'egress_if_id' (short format) in the node data."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity trace-timestamp-seconds { base trace-type; description"It"This identity indicates the presence of timestamp seconds in the node data."; } identity trace-timestamp-fraction { base trace-type; description"It"This identity indicates the presence of a timestamp fraction in the node data."; } identity trace-transit-delay { base trace-type; description"It"This identity indicates the presence of transit delay in the node data."; } identity trace-namespace-data { base trace-type; description"It"This identity indicates the presence ofname space specificnamespace-specific data (short format) in the node data."; } identity trace-queue-depth { base trace-type; description"It"This identity indicates the presence of queue depth in the node data."; } identity trace-checksum-complement { base trace-type; description"It"This identity indicates the presence of the Checksum Complement in the node data."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity trace-hop-lim-node-id-wide { base trace-type; description"It"This identity indicates the presence ofHop_Lim'Hop_Lim' andnode_id in wide format'node_id' (wide format) in the node data."; } identity trace-if-id-wide { base trace-type; description"It"This identity indicates the presence ofingress_if_id'ingress_if_id' andegress_if_id in wide format'egress_if_id' (wide format) in the node data."; } identity trace-namespace-data-wide { base trace-type; description"It"This identity indicates the presence ofIOAM-Namespace specificIOAM-namespace-specific datain wide format(wide format) in the node data."; } identity trace-buffer-occupancy { base trace-type; description"It"This identity indicates the presence of buffer occupancy in the node data."; } identity trace-opaque-state-snapshot { base trace-type; description"It"This identity indicates the presence ofvariable lengththe variable-length Opaque State Snapshot field."; } identity pot-type { description "Base identity to represent Proof of Transit(PoT)(POT) types."; } identity pot-type-0 { base pot-type; description "The IOAMPOT Typefield value for the POT type is 0, and POT data is a16 Octet16-octet field to carry data associatedtowith POT procedures."; } identity e2e-type { description "Base identity to represent edge-to-edge types."; } identity e2e-seq-num-64 { base e2e-type; description"It"This identity indicates the presence of a 64-bit sequence number."; } identity e2e-seq-num-32 { base e2e-type; description"It"This identity indicates the presence of a 32-bit sequence number."; } identity e2e-timestamp-seconds { base e2e-type; description"It"This identity indicates the presence of timestamp seconds representing the time at which the packet entered theIOAM-domain.";IOAM domain."; } identity e2e-timestamp-fraction { base e2e-type; description"It"This identity indicates the presence of a timestamp fraction representing the time at which the packet entered theIOAM-domain.";IOAM domain."; } identity namespace { description "Base identity to represent the Namespace-ID."; } identity default-namespace { base namespace; description "The Namespace-ID value of 0x0000 is defined as the Default-Namespace-ID and MUST be known to all the nodes implementing IOAM."; } /* * TYPE DEFINITIONS */ typedef ioam-filter-type { type identityref { base filter; } description"It"This type specifies a known type of filter."; } typedef ioam-protocol-type { type identityref { base protocol; } description"It"This type specifies a known type of carrier protocol for the IOAM data."; } typedef ioam-node-action { type identityref { base node-action; } description"It"This type specifies a known type of node action."; } typedef ioam-trace-type { type identityref { base trace-type; } description"It"This type specifies a known trace type."; } typedef ioam-pot-type { type identityref { base pot-type; } description"It"This type specifies a knownpotPOT type."; } typedef ioam-e2e-type { type identityref { base e2e-type; } description"It"This type specifies a known edge-to-edge type."; } typedef ioam-namespace { type identityref { base namespace; } description"It"This type specifies the supported namespace."; } /* * GROUP DEFINITIONS */ grouping ioam-filter { description "A grouping for IOAM filterdefinition";definitions."; leaf filter-type { type ioam-filter-type; description"filter type";"Filter type."; } leaf ace-name { when "derived-from-or-self(../filter-type, 'ioam:acl-filter')"; type leafref { path "/acl:acls/acl:acl/acl:aces/acl:ace/acl:name"; } description "The Access Control Entry name is used to refer to an ACL specification."; } } grouping encap-tracing { description "A grouping for the generic configuration for the tracing profile."; container trace-types { description"It indicates"This container provides the list of trace types for encapsulation."; leaf use-namespace { type ioam-namespace; default default-namespace; description"It"This object indicates thename spacenamespace used for encapsulation."; } leaf-list trace-type { type ioam-trace-type; description "The trace type is only defined at the encapsulation node."; } } leaf max-length { when "derived-from-or-self(../node-action, 'ioam:action-encapsulate')"; type uint32; units bytes; description "This field specifies the maximum length of the node data list in octets.The max-length'max-length' is only defined at the encapsulation node."; } } grouping ioam-incremental-tracing-profile { description "A grouping forincremental tracing profile.";the Incremental Tracing Profile."; leaf node-action { type ioam-node-action; default action-transit; description "This object indicates the action the nodeneedneeds to take,e.g.e.g., encapsulation."; } uses encap-tracing { when "derived-from-or-self(node-action, 'ioam:action-encapsulate')"; } } grouping ioam-preallocated-tracing-profile { description "A grouping forpre-allocated tracing profile.";the Pre-allocated Tracing Profile."; leaf node-action { type ioam-node-action; default action-transit; description "This object indicates the action the nodeneedneeds to take,e.g.e.g., encapsulation."; } uses encap-tracing { when "derived-from-or-self(node-action, 'ioam:action-encapsulate')"; } } grouping ioam-direct-export-profile { description "A grouping fordirect export profile.";the Direct Export Profile."; leaf node-action { type ioam-node-action; default action-transit; description "This object indicates the action the nodeneedneeds to take,e.g.e.g., encapsulation."; } uses encap-tracing { when "derived-from-or-self(node-action, 'ioam:action-encapsulate')"; } leaf flow-id { when "derived-from-or-self(../node-action, 'ioam:action-encapsulate')"; type uint32; description "A 32-bit flow identifier. The field is set at the encapsulating node. The Flow ID can be uniformly assigned by a central controller or algorithmically generated by the encapsulating node. The latter approach cannot guarantee the uniqueness of the Flow ID, yet theconflictprobability of conflict is small due to the large Flow ID space.flow-id'flow-id' is used to correlate the exported data of the same flow from multiple nodes and from multiple packets."; } leaf enable-sequence-number { when "derived-from-or-self(../node-action, 'ioam:action-encapsulate')"; type boolean; default false; description "This boolean value indicates whether the sequence number is used in the direct exportoptionoption's 32-bit flow identifier. If this value istrue,set to 'true', the sequence number is used.By default, it'sIt is turnedoff.";off by default."; } } grouping ioam-e2e-profile { description "A grouping foredge-to-edge profile.";the Edge-to-Edge Profile."; leaf node-action { type ioam-node-action; default action-transit; description "This object indicates the action the nodeneedneeds to take,e.g.e.g., encapsulation."; } container e2e-types { when "derived-from-or-self(../node-action, 'ioam:action-encapsulate')"; description"It indicates"This container provides the list of edge-to-edge types for encapsulation."; leaf use-namespace { type ioam-namespace; default default-namespace; description"It"This object indicates thename spacenamespace used for encapsulation."; } leaf-list e2e-type { type ioam-e2e-type; description "The edge-to-edge type is only defined at the encapsulation node."; } } } grouping ioam-admin-config { description "IOAM top-level administrative configuration."; leaf enabled { type boolean; default false; description "This object is used to control the availability of configuration. It MUST betrueset to 'true' before anything in the /ioam/profiles/profile subtree can be edited. Iffalse,'false', any configuration in place is not used."; } } /* * DATA NODES */ container ioam { description "IOAMtop level container";top-level container."; container info { config false; description "Describesinformationinformation, such as units or timestampformatformat, that assists monitoring systems in the interpretation of the IOAM data."; leaf timestamp-type { type identityref { base lime:timestamp-type; } description "Type of timestamp, such as Truncated PTP (Precision Time Protocol) or NTP."; } list available-interface { key "if-name"; description "A list of available interfaces that support IOAM."; leaf if-name { type if:interface-ref; description "This is a reference to theInterfaceinterface name."; } } } container admin-config { description "Contains all the administrative configurations related to the IOAM functionalities and all the IOAM profiles."; uses ioam-admin-config; } container profiles { description "Contains a list of IOAM profiles."; list profile { key "profile-name"; description "A list of IOAM profiles that are configured on the node. There is no mandatory type of profile (e.g.,incremental-trace, preallocated-trace.)'incremental-trace', 'preallocated-trace') in the list. But at least one profile should be added."; leaf profile-name { type string{ length "1..300"; } description "Unique identifier for each IOAM profile."; } container filter { uses ioam-filter; description "The filterwhichthat is used to indicate the flow to apply IOAM."; } leaf protocol-type { type ioam-protocol-type; description "Thisitemobject is used to indicate the carrier protocol wheretheIOAM is applied."; } container incremental-tracing-profile { if-feature incremental-trace; presence "Enables the incremental tracing option."; description"It"This container describes the profile for the incremental tracing option."; uses ioam-incremental-tracing-profile; } container preallocated-tracing-profile { if-feature preallocated-trace; presence "Enablespreallocatedthe pre-allocated tracing option."; description"It"This container describes the profile forpreallocatedthe pre-allocated tracing option."; uses ioam-preallocated-tracing-profile; } container direct-export-profile { if-feature direct-export; presence "Enablesdirect-exportthe direct export option."; description"It"This container describes the profile fordirect-export option";the direct export option."; uses ioam-direct-export-profile; } container pot-profile { if-feature proof-of-transit; presence "EnablesProofthe proof ofTransittransit (POT) option."; description"It"This container describes the profile forPoTthe POT option."; leaf use-namespace { type ioam-namespace; default default-namespace; description"It"This object indicates the namespace used for the POT types."; } leaf pot-type { type ioam-pot-type; description "The type of a particular POT variant that specifies the POT data that is included."; } } container e2e-profile { if-feature edge-to-edge; presence "Enables the edge-to-edge option."; description"It"This container describes the profile for the edge-to-edge option."; uses ioam-e2e-profile; } } } } }<CODE ENDS>]]></artwork> </figure></t> <t/>]]></sourcecode> <!-- [rfced] Section 4: a) The contact list in the YANG module does not match the contact/author list on Page 1 of this document. May we update as suggested, or should all authors perhaps have "editor" designations on the front page (in which case we would need AD approval)? Original: contact "WG Web: <https://datatracker.ietf.org/wg/ippm> WG List: <ippm@ietf.org> Editor: zhoutianran@huawei.com Editor: james.n.guichard@futurewei.com Editor: fbrockne@cisco.com Editor: srihari@cisco.com"; Suggested (to match the current front page): contact "WG Web: <https://datatracker.ietf.org/wg/ippm> WG List: <mailto:ippm@ietf.org> Editor: Tianran Zhou <mailto:zhoutianran@huawei.com> Editor: Jim Guichard <mailto:james.n.guichard@futurewei.com> Editor: Frank Brockners <mailto:fbrockne@cisco.com> Editor: Srihari Raghavan <mailto:srihari@cisco.com>"; b) We do not see "Hop_Lim", "node_id", "ingress_if_id", or "egress_if_id" mentioned anywhere else in this document, but we see them mentioned in RFC 9197. For ease of the reader, we added references for RFC 9197 accordingly. Please let us know any objections. Original: identity trace-hop-lim-node-id { base trace-type; description "It indicates the presence of Hop_Lim and node_id in the node data."; } identity trace-if-id { base trace-type; description "It indicates presence of ingress_if_id and egress_if_id (short format) in the node data."; } Currently: identity trace-hop-lim-node-id { base trace-type; description "This identity indicates the presence of 'Hop_Lim' and 'node_id' in the node data."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity trace-if-id { base trace-type; description "This identity indicates the presence of 'ingress_if_id' and 'egress_if_id' (short format) in the node data."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } c) We do not see "Checksum Complement" mentioned anywhere else in this document, but we see it mentioned in RFC 9197. For ease of the reader, we added a reference for RFC 9197 accordingly. Please let us know any objections. Original: identity trace-checksum-complement { base trace-type; description "It indicates presence of the Checksum Complement node data."; } Currently: identity trace-checksum-complement { base trace-type; description "This identity indicates the presence of the Checksum Complement in the node data."; reference "RFC 9197: Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)"; } d) This sentence was missing one or more words. We changed "profiles that configured on" to "profiles that are configured on". If this is incorrect, please clarify the text. Original: list profile { key "profile-name"; description "A list of IOAM profiles that configured on the node. There is no mandatory type of profile (e.g., incremental-trace, preallocated-trace.) in the list. But at least one profile should be added."; Currently: list profile { key "profile-name"; description "A list of IOAM profiles that are configured on the node. There is no mandatory type of profile (e.g., 'incremental-trace', 'preallocated-trace') in the list. But at least one profile should be added."; --> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <!-- YANG security cons. boilerplate paragraph 1 --> <t>The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF <xreftarget="RFC6241">NETCONF</xref>target="RFC6241"/> or RESTCONF <xreftarget="RFC8040">RESTCONF</xref>.target="RFC8040"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is<xref target="RFC6242">SecureSecure Shell(SSH)</xref>.(SSH) <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xreftarget="RFC8446">TLS</xref>.</t>target="RFC8446"/>.</t> <!-- YANG security cons. boilerplate paragraph 2 --> <t>The<xref target="RFC8341">NetworkNetwork Configuration Access Control Model(NACM)</xref>(NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <!-- YANG security cons. boilerplate paragraph 3 --> <t>There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:</t><t><list style="symbols"> <t>/ioam/admin-config:<dl spacing="normal"> <dt>/ioam/admin-config:</dt><dd>The items in the container above include the top-level administrative configurations related to the IOAM functionalities and all the IOAM profiles. Unexpected changes to these items could lead to disruption of IOAM functions and/or misbehaving IOAM profiles.</dd> <dt>/ioam/profiles/profile:</dt><dd>The entries in the list above include the whole IOAM profile configurations. Unexpected changes to these entries could lead to incorrect IOAM behavior for the corresponding flows. Consequently, such changes would impact performance monitoring, data analytics, and the associated reaction to network services.</dd> <!-- [rfced] Section 5: a) Because the YANG module contains several container and list definitions, it is not clear what "the container above" and "the list above" refer to. If the suggested text is not correct, please clarify. Original: * /ioam/admin-config: The items in the container above include the top level administrative configurations related to the IOAM functionalities and all the IOAM profiles. Unexpected changes to these items could lead to the IOAM function disruption and/or misbehavior of all the IOAMprofiles.</t> </list></t> <t><list style="symbols"> <t>/ioam/profiles/profile:profiles. * /ioam/profiles/profile: The entries in the list above include the whole IOAM profile configurations. Unexpected changes to these entries could lead to the mistake of the IOAM behavior for the corresponding flows. Consequently, it will impact the performance monitoring, data analytics, and the associated reaction to network services. Suggested: /ioam/admin-config: The items in the "admin-config" container above include the top-level administrative configurations related to the IOAM functionalities and all the IOAM profiles. Unexpected changes to these items could lead to disruption of IOAM functions and/or misbehaving IOAM profiles. /ioam/profiles/profile: The entries in the "profile" list above include the whole IOAM profile configurations. Unexpected changes to these entries could lead to incorrect IOAM behavior for the corresponding flows. Consequently, such changes would impact performance monitoring, data analytics, and the associated reaction to network services. b) This sentence was difficult to follow. We updated the text as noted below. If this is incorrect, please clarify "the mistake of the IOAM behavior". Original: Unexpected changes to these entries could lead to the mistake of the IOAM behavior for the corresponding flows. Currently: Unexpected changes to these entries could lead to incorrect IOAM behavior for the corresponding flows. c) We had trouble following this sentence. Please clarify the meaning of "reaction to network services". Original: Consequently, it will impact the performance monitoring, data analytics, and the associated reaction to networkservices.</t> </list></t>services. Currently: Consequently, such changes would impact performance monitoring, data analytics, and the associated reaction to network services. Possibly: Consequently, such changes would impact performance monitoring, data analytics, and associated interactions with network services. --> </dl> <!-- YANG security cons. boilerplate paragraph 4 --> <t>Some of the readable data nodes inthesethis YANGmodulesmodule may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:</t><t><list style="symbols"> <t>/ioam/profiles/profile: The<dl spacing="normal"> <dt>/ioam/profiles/profile:</dt><dd>The information contained in this subtree mightgivereveal information about the services deployed forthe customers.Forcustomers. For instance, a customer might be given access to monitor the status of theirservices status.services. Inthat example,this scenario, thecustomercustomer's access should be restricted to nodes representing their services so as not to divulge information about the underlying network structure orservices.</t> </list></t> <t/> </section> <section anchor="IANA" title="IANA Considerations"> <t>RFC Ed.: Inservices.</dd> </dl> <!-- [rfced] Section 5: Authors and *[AD]: It appears that thissection, replace all occurrencesdocument does not define any RPC operations. Please see the "YANG module security considerations" page at <https://wiki.ietf.org/group/ops/yang-security-guidelines>, and confirm that the "Some of'XXXX' withtheactual RFC number (and removeRPC operations in thisnote).</t> <t>IANA is requestedYANG module ..." paragraph does not apply toassign a newthis document. --> </section> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has registered the following URIfromin the <xreftarget="RFC3688">IETFtarget="RFC3688" format="default">"IETF XMLRegistry</xref>. The following URI is suggested:</t> <t><figure> <artwork align="left"><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-ioam Registrant Contact: The IESG. XML: N/A;Registry"</xref>:</t> <dl spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ioam</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace.]]></artwork> </figure></t> <t>Thisnamespace.</dd> </dl> <t>IANA has registered the following YANG module in the <xref target="RFC6020" format="default">"YANG Module Names" registry</xref>: <!-- [rfced] Section 6: Authors and *[AD]: The "YANG Module Names" registry is defined in RFC 6020 and not RFC 7950. We updated this sentence to cite RFC 6020 accordingly. Please see Section 14 of RFC 6020 (https://www.rfc-editor.org/info/rfc6020) and <https://www.iana.org/assignments/yang-parameters/> if you have any questions regarding this update. We have also added RFC 6020 to the Normative References section. Original: This document also requests a new YANG module name in the<xref target="RFC7950">YANGYANG Module Namesregistry</xref>registry [RFC7950] with the followingsuggestion:</t> <t><figure> <artwork align="left"><![CDATA[ name: ietf-ioam namespace: urn:ietf:params:xml:ns:yang:ietf-ioam prefix: ioam reference:suggestion: Currently: IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020]: ... [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFCXXXX]]></artwork> </figure></t> </section> <section anchor="Acknowledgements" title="Acknowledgements"> <t>For their valuable comments, discussions, and feedback, we wish to acknowledge Greg Mirsky, Reshad Rahman, Tom Petch, Mickey Spiegel, Thomas Graf, Alex Huang Feng and Justin Iurman.</t>6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. --> </t> <dl spacing="compact"> <dt>Name:</dt><dd>ietf-ioam</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ioam</dd> <dt>Prefix:</dt><dd>ioam</dd> <dt>Reference:</dt><dd>RFC 9617</dd> </dl> </section> </middle> <back><references title="Normative References"> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.7950'?> <?rfc include='reference.RFC.8340'?> <?rfc include='reference.RFC.8342'?> <?rfc include='reference.RFC.3688'?> <?rfc include='reference.RFC.6241'?> <?rfc include='reference.RFC.8040'?> <?rfc include='reference.RFC.6242'?> <?rfc include='reference.RFC.8446'?> <?rfc include='reference.RFC.8341'?> <?rfc include='reference.RFC.8343'?> <?rfc include='reference.RFC.8519'?> <?rfc include='reference.RFC.8532'?> <?rfc include='reference.RFC.9197'?> <?rfc include='reference.RFC.9326'?> <?rfc include='reference.RFC.9452'?> <?rfc include='reference.RFC.9486'?><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.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8532.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9326.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9452.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9486.xml"/> </references> <sectiontitle="Annumbered="true" toc="default"> <name>An Example of the Incremental TracingProfile">Profile</name> <t>An example ofincremental tracing profilethe Incremental Tracing Profile is depicted in the following figure. This configuration is received by an IOAM ingress node. This node encapsulates the IOAM data in the IPv6 Hop-by-Hop option header. The trace type indicates that eachon pathon-path nodeneedneeds to capture the transitdelay,delay and add the data to the IOAM node data list. The incremental tracing data space isvariable,variable; however, the node data list must not exceed 512 bytes.</t><t><figure> <artwork><![CDATA[<rpc<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <edit-config> <target> <candidate/> </target> <config> <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> <admin-config> <enabled>true</enabled> </admin-config> <profiles> <profile> <profile-name>ietf-test-profile</profile-name> <protocol-type>ipv6</protocol-type> <incremental-tracing-profile> <node-action>action-encapsulate</node-action> <trace-types> <use-namespace>default-namespace</use-namespace> <trace-type>trace-transit-delay</trace-type> </trace-types> <max-length>512</max-length> </incremental-tracing-profile> </profile> </profiles> </ioam> </config> </edit-config></rpc>]]></artwork> </figure></t> <t/></rpc> ]]></artwork> </section> <sectiontitle="Annumbered="true" toc="default"> <name>An Example of the Pre-allocated TracingProfile">Profile</name> <t>An example ofpre-allocated tracing profilethe Pre-allocated Tracing Profile is depicted in the following figure. This configuration is received by an IOAM ingress node. This nodefirstlyfirst identifies the target flow by using the ACL"test-acl",parameter "test-acl" and then encapsulates the IOAM data in theNSH header.NSH. The trace type indicates that eachon pathon-path nodeneedneeds to capture thename space specificnamespace-specific data intheshortformat,format and add the data to the IOAM node data list. This nodepreallocatespre-allocates the node data list in thepackectpacket with 512 bytes.</t><t><figure> <artwork><![CDATA[<rpc<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <edit-config> <target> <candidate/> </target> <config> <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> <admin-config> <enabled>true</enabled> </admin-config> <profiles> <profile> <profile-name>ietf-test-profile</profile-name> <filter> <filter-type>acl-filter</filter-type> <ace-name>test-acl</ace-name> </filter> <protocol-type>nsh</protocol-type> <preallocated-tracing-profile> <node-action>action-encapsulate</node-action> <trace-types> <use-namespace>default-namespace</use-namespace> <trace-type>trace-namespace-data</trace-type> </trace-types> <max-length>512</max-length> </preallocated-tracing-profile> </profile> </profiles> </ioam> </config> </edit-config></rpc>]]></artwork> </figure></t></rpc> ]]></artwork> </section> <sectiontitle="Annumbered="true" toc="default"> <name>An Example of the Direct ExportProfile">Profile</name> <t>An example ofdirect export profilethe Direct Export Profile is depicted in the following figure. This configuration is received by an IOAM egress node. This node detects the IOAM direct export option in the IPv6 extensionheader,header and removes the option to clean all the IOAM data.</t><t><figure> <artwork><![CDATA[<rpc<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <edit-config> <target> <candidate/> </target> <config> <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> <admin-config> <enabled>true</enabled> </admin-config> <profiles> <profile> <profile-name>ietf-test-profile</profile-name> <protocol-type>ipv6</protocol-type> <direct-export-profile> <node-action>action-decapsulate</node-action> </direct-export-profile> </profile> </profiles> </ioam> </config> </edit-config></rpc>]]></artwork> </figure></t></rpc> ]]></artwork> </section> <sectiontitle="Annumbered="true" toc="default"> <name>An Example of the Proof of TransitProfile">Profile</name> <t>The following figure is a simple example of the POT option. This configuration indicates the node to apply POT type 0 with IPv6encapsulation.</t> <t><figure> <artwork><![CDATA[<rpcencapsulation. <!-- [rfced] Appendices D and E: Should the option names in these sentences be profile names instead? Please compare with the first sentence of Appendices A, B, and C. Original: Appendix D. An Example of Proof of Transit Profile The following figure is a simple example of POT option. ... Appendix E. An Example of Edge-to-Edge Profile The following figure shows an example of edge-to-edge option. Possibly: Appendix D. An Example of the Proof of Transit Profile A simple example of the Proof of Transit Profile is depicted in the following figure. ... Appendix E. An Example of the Edge-to-Edge Profile An example of the Edge-to-Edge Profile is depicted in the following figure. --> </t> <artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <edit-config> <target> <candidate/> </target> <config> <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> <admin-config> <enabled>true</enabled> </admin-config> <profiles> <profile> <profile-name>ietf-test-profile</profile-name> <protocol-type>ipv6</protocol-type> <pot-profile> <pot-type>pot-type-0</pot-type> </pot-profile> </profile> </profiles> </ioam> </config> </edit-config></rpc>]]></artwork> </figure></t></rpc> ]]></artwork> </section> <sectiontitle="Annumbered="true" toc="default"> <name>An Example of the Edge-to-EdgeProfile">Profile</name> <t>The following figure shows an example of the edge-to-edge option. This configuration is received by an IOAM egress node. This node detects the IOAM edge-to-edge option in the IPv6 extensionheader,header and removes the option to clean all the IOAM data. As the IOAM egress node, it may collect the edge-to-edge data and deliver it to thedata exportingdata-exporting process.</t><t><figure> <artwork><![CDATA[<rpc<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <edit-config> <target> <candidate/> </target> <config> <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> <admin-config> <enabled>true</enabled> </admin-config> <profiles> <profile> <profile-name>ietf-test-profile</profile-name> <protocol-type>ipv6</protocol-type> <e2e-profile> <node-action>action-decapsulate</node-action> </e2e-profile> </profile> </profiles> </ioam> </config> </edit-config></rpc>]]></artwork> </figure></t></rpc> ]]></artwork> </section> <section anchor="Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>For their valuable comments, discussions, and feedback, we wish to acknowledge <contact fullname="Greg Mirsky"/>, <contact fullname="Reshad Rahman"/>, <contact fullname="Tom Petch"/>, <contact fullname="Mickey Spiegel"/>, <contact fullname="Thomas Graf"/>, <contact fullname="Alex Huang Feng"/>, and <contact fullname="Justin Iurman"/>.</t> </section> </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. --> <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms were used inconsistently in this document. We chose to use the latter forms. Please let us know any objections. direct-export option (2 instances in text) / direct export option (5 instances in text) IOAM-domain / IOAM domain POT Type / pot type / POT type ("POT" per RFCs 9197 and 9326) Proof of Transit data / proof of transit data (Other data types are written in lowercase in running text.) Proof of Transit option / proof of transit option (Other option types are written in lowercase in running text.) incremental tracing profile / Incremental Tracing Profile* pre-allocated tracing profile / Pre-allocated Tracing Profile* * Initial-capitalized, because the profile names appear to be proper terms. Please note: For this reason, we also initial-capitalized "Direct Export Profile" and "Edge-to-Edge Profile". Please let us know any objections. --> </rfc>