rfc9617xml2.original.xml | rfc9617.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 " "> | |||
<?rfc tocdepth="3"?> | <!ENTITY zwsp "​"> | |||
<?rfc tocindent="yes"?> | <!ENTITY nbhy "‑"> | |||
<?rfc symrefs="yes"?> | <!ENTITY wj "⁠"> | |||
<?rfc sortrefs="yes"?> | ]> | |||
<?rfc comments="yes"?> | ||||
<?rfc inline="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie | |||
<?rfc compact="yes"?> | tf-ippm-ioam-yang-13" number="9617" ipr="trust200902" obsoletes="" updates="" su | |||
<?rfc subcompact="no"?> | bmissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3 | |||
<rfc category="std" docName="draft-ietf-ippm-ioam-yang-13" ipr="trust200902"> | " symRefs="true" sortRefs="true" version="3"> | |||
<front> | <front> | |||
<title abbrev="YANG Model for IOAM">A YANG Data Model for In-Situ | <title abbrev="YANG Data Model for IOAM">A YANG Data Model for In Situ | |||
OAM</title> | Operations, Administration, and Maintenance (IOAM)</title> | |||
<author fullname="Tianran Zhou" initials="T." surname="Zhou, Ed."> | <!-- [rfced] Document title: We updated the full and running | |||
<organization>Huawei</organization> | 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-Situ 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" role="editor"> | ||||
<organization>Huawei</organization> | ||||
<address> | <address> | |||
<postal> | <postal> | |||
<street>156 Beiqing Rd.</street> | <street>156 Beiqing Rd.</street> | |||
<city>Beijing</city> | <city>Beijing</city> | |||
<code>100095</code> | <code>100095</code> | |||
<region/> | ||||
<country>China</country> | <country>China</country> | |||
</postal> | </postal> | |||
<email>zhoutianran@huawei.com</email> | <email>zhoutianran@huawei.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Jim Guichard" initials="J." surname="Guichard"> | <author fullname="Jim Guichard" initials="J." surname="Guichard"> | |||
<organization>Futurewei</organization> | <organization>Futurewei</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street/> | ||||
<city/> | ||||
<code/> | ||||
<region/> | ||||
<country>United States of America</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>james.n.guichard@futurewei.com</email> | <email>james.n.guichard@futurewei.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Frank Brockners" initials="F." surname="Brockners"> | <author fullname="Frank Brockners" initials="F." surname="Brockners"> | |||
<organization>Cisco Systems</organization> | <organization>Cisco Systems</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Hansaallee 249, 3rd Floor</street> | <street>Hansaallee 249, 3rd Floor</street> | |||
<city>Düsseldorf, Nordrhein-Westfalen</city> | ||||
<city>Duesseldorf</city> | ||||
<region>Nordrhein-Westfalen</region> | ||||
<code>40549</code> | <code>40549</code> | |||
<country>Germany</country> | <country>Germany</country> | |||
</postal> | </postal> | |||
<phone/> | ||||
<facsimile/> | ||||
<email>fbrockne@cisco.com</email> | <email>fbrockne@cisco.com</email> | |||
<uri/> | ||||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Srihari Raghavan" initials="S." surname="Raghavan"> | <author fullname="Srihari Raghavan" initials="S." surname="Raghavan"> | |||
<organization>Cisco Systems</organization> | <organization>Cisco Systems</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Tril Infopark Sez, Ramanujan IT City</street> | <street>Tril Infopark Sez, Ramanujan IT City</street> | |||
<street>Neville Block, 2nd floor, Old Mahabalipuram Road</street> | <street>Neville Block, 2nd floor, Old Mahabalipuram Road</street> | |||
<city>Chennai</city> | <city>Chennai</city> | |||
<region>Tamil Nadu</region> | <region>Tamil Nadu</region> | |||
<code>600113</code> | <code>600113</code> | |||
<country>India</country> | <country>India</country> | |||
</postal> | </postal> | |||
<phone/> | ||||
<facsimile/> | ||||
<email>srihari@cisco.com</email> | <email>srihari@cisco.com</email> | |||
<uri/> | ||||
</address> | </address> | |||
</author> | </author> | |||
<date month="July" year="2024"/> | ||||
<area>OPS</area> | ||||
<workgroup>ippm</workgroup> | ||||
<date day="01" month="March" year="2024"/> | <!-- [rfced] Please insert any keywords (beyond those that appear in the | |||
title) for use on <https://www.rfc-editor.org/search>. --> | ||||
<workgroup>IPPM</workgroup> | ||||
<abstract> | <abstract> | |||
<t>In-situ Operations, Administration, and Maintenance (IOAM) is an | <t>In situ Operations, Administration, and Maintenance (IOAM) is an | |||
example of an on-path hybrid measurement method. IOAM defines a method | example of an on-path hybrid measurement method. IOAM defines a method | |||
to produce operational and telemetry information that may be exported | for producing operational and telemetry information that may be exported | |||
using the in-band or out-of-band method. RFC9197 and RFC9326 discuss the | using the in-band or out-of-band method. RFCs 9197 and 9326 discuss the | |||
data fields and associated data types for IOAM. This document defines a | data fields and associated data types for IOAM. This document defines a | |||
YANG module for the configuration of IOAM functions.</t> | YANG module for the configuration of IOAM functions.</t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section title="Introduction"> | <section numbered="true" toc="default"> | |||
<t>In-situ Operations, Administration, and Maintenance (IOAM) is an | <name>Introduction</name> | |||
<t>In situ Operations, Administration, and Maintenance (IOAM) is an | ||||
example of an on-path hybrid measurement method. IOAM defines a method | example of an on-path hybrid measurement method. IOAM defines a method | |||
to produce operational and telemetry information that may be exported | for producing operational and telemetry information that may be exported | |||
using the in-band or out-of-band method. The data types and data formats | using the in-band or out-of-band method. The data types and data formats | |||
for IOAM data records have been defined in <xref target="RFC9197"/> and | for IOAM data records have been defined in <xref target="RFC9197" format=" | |||
<xref target="RFC9326"/>. The IOAM data can be embedded in many protocol | default"/> and | |||
encapsulations such as Network Services Header (NSH) and IPv6.</t> | <xref target="RFC9326" format="default"/>. The IOAM data can be embedded i | |||
n many protocol | ||||
encapsulations, such as the Network Service Header (NSH) <xref target="RFC | ||||
9452"/> and IPv6.</t> | ||||
<t>This document defines a data model for the configuration of IOAM | <t>This document defines a data model for the configuration of IOAM | |||
capabilities using the <xref target="RFC7950">YANG data modeling | capabilities using the <xref target="RFC7950" format="default">YANG data m | |||
language</xref>. This YANG model supports five IOAM options, which | odeling | |||
are:</t> | language</xref>. This YANG data model supports five IOAM options, which | |||
are as follows:</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t><xref target="RFC9197" format="default">Incremental Tracing Option | ||||
</xref></t> | ||||
</li> | ||||
<li> | ||||
<t><xref target="RFC9197" format="default">Pre-allocated Tracing Optio | ||||
n</xref></t> | ||||
</li> | ||||
<li> | ||||
<t><xref target="RFC9326" format="default">Direct Export Option</xref> | ||||
</t> | ||||
</li> | ||||
<li> | ||||
<t><xref target="RFC9197" format="default">Proof of Transit (POT) Opti | ||||
on</xref></t> | ||||
</li> | ||||
<li> | ||||
<t><xref target="RFC9197" format="default">Edge-to-Edge Option</xref>< | ||||
/t> | ||||
</li> | ||||
<t><list style="symbols"> | <!-- [rfced] Section 1: We see different wordings used in RFCs 9197 | |||
<t><xref target="RFC9197">Incremental Tracing Option </xref></t> | and 9326 for the following terms, as compared to this document. Will | |||
the different wordings be clear to readers? | ||||
<t><xref target="RFC9197">Pre-allocated Tracing Option</xref></t> | Original: | |||
* Incremental Tracing Option [RFC9197] | ||||
<t><xref target="RFC9326">Direct Export Option</xref></t> | * Pre-allocated Tracing Option [RFC9197] | |||
<t><xref target="RFC9197">Proof of Transit (PoT) Option</xref></t> | * Direct Export Option [RFC9326] | |||
<t><xref target="RFC9197">Edge-to-Edge Option</xref></t> | * Proof of Transit (PoT) Option [RFC9197] | |||
</list></t> | ||||
</section> | ||||
<section title="Conventions used in this document"> | * Edge-to-Edge Option [RFC9197] | |||
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ... | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | We see the following in this document's text: | |||
"OPTIONAL" in this document are to be interpreted as described in BCP14, | preallocated tracing option (we have changed "preallocated" to | |||
<xref target="RFC2119"/>, <xref target="RFC8174"/> when, and only when, | "pre-allocated") | |||
they appear in all capitals, as shown here.</t> | ||||
<t>The following terms are defined in <xref target="RFC7950"/> and are | incremental tracing option | |||
used in this specification: <list style="symbols"> | ||||
<t>augment</t> | ||||
<t>data model</t> | direct export option | |||
<t>data node</t> | proof of transit option (and POT option) | |||
</list>The terminology for describing YANG data models is found in | ||||
<xref target="RFC7950"/>.</t> | ||||
<section anchor="tree-diagrams" title="Tree Diagrams"> | 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>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | ||||
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", | ||||
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", | ||||
"<bcp14>SHOULD NOT</bcp14>", | ||||
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | ||||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document | ||||
are to be interpreted as described in BCP 14 | ||||
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only | ||||
when, they appear in all capitals, as shown here.</t> | ||||
<t>The following terms are defined in <xref target="RFC7950" format="defau | ||||
lt"/> and are | ||||
used in this specification: </t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>augment</t> | ||||
</li> | ||||
<li> | ||||
<t>data model</t> | ||||
</li> | ||||
<li> | ||||
<t>data node</t> | ||||
</li> | ||||
</ul> | ||||
<t>The terminology for describing YANG data models is found in | ||||
<xref target="RFC7950" format="default"/>.</t> | ||||
<section anchor="tree-diagrams" numbered="true" toc="default"> | ||||
<name>Tree Diagrams</name> | ||||
<t>Tree diagrams used in this document follow the notation defined in | <t>Tree diagrams used in this document follow the notation defined in | |||
<xref target="RFC8340"/>.</t> | <xref target="RFC8340" format="default"/>.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Design of the IOAM YANG Data Model"> | <name>Design of the IOAM YANG Data Model</name> | |||
<t/> | <section numbered="true" toc="default"> | |||
<name>Overview</name> | ||||
<section title="Overview"> | <t>The IOAM model is organized as a list of profiles, as shown in the | |||
<t>The IOAM model is organized as list of profiles as shown in the | ||||
following figure. Each profile associates with one flow and the | following figure. Each profile associates with one flow and the | |||
corresponding IOAM information.</t> | corresponding IOAM information.</t> | |||
<t><figure> | <!-- [rfced] Sourcecode | |||
<artwork><![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> | ||||
<t>The "info" is a container for all the read-only information that | ||||
assists monitoring systems in the interpretation of the IOAM data.</t> | ||||
<t>The "enabled" is an administrative configuration. When it is set to | a) We updated <artwork> to <sourcecode> in several instances in the | |||
true, IOAM configuration is enabled for the system. Meanwhile, the | document. Please review the "type" attribute of each sourcecode element in the | |||
IOAM data-plane functionality is enabled.</t> | 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. | ||||
<t>The "filter" is used to identify a flow, where the IOAM profile can | b) Should <artwork> in Appendices A-E be tagged as <sourcecode type="xml">? If | |||
apply. There may be multiple filter types. <xref | so, we will add the following as a normative reference. Please let us know the | |||
target="RFC8519">ACL</xref> is a common way to specify a flow. Each | best placement for the citation in the text. You can see RFCs 9587, 9403, and | |||
IOAM profile can associate with an ACE(Access Control Entry). IOAM | 8194 for examples. | |||
actions MUST be driven by the accepted packets, when the matched ACE | ||||
"forwarding" action is "accept".</t> | ||||
[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}? | ||||
]]></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 i | ||||
s set to | ||||
"true", IOAM configuration is enabled for the system. Meanwhile, the | ||||
IOAM data plane functionality is enabled.</t> | ||||
<t>The "filter" parameter is used to identify a flow, where the IOAM pro | ||||
file can | ||||
apply. There may be multiple filter types. <xref target="RFC8519" format | ||||
="default">Access Control Lists (ACLs)</xref> provide a common way to specify a | ||||
flow. Each | ||||
IOAM profile can associate with an ACE (Access Control Entry). When the | ||||
matched ACE "forwarding" action is "accept", IOAM actions <bcp14>MUST</bcp14> be | ||||
driven by the accepted packets.</t> | ||||
<t>The IOAM data can be encapsulated into multiple protocols, e.g., | <t>The IOAM data can be encapsulated into multiple protocols, e.g., | |||
<xref target="RFC9486">IPv6</xref> and <xref | <xref target="RFC9486" format="default">IPv6</xref> and <xref target="RF | |||
target="RFC9452">NSH</xref>. The "protocol-type" is used to indicate | C9452" format="default">the NSH</xref>. The "protocol-type" parameter is used to | |||
where the IOAM is applied. For example, if the "protocol-type" is | indicate | |||
IPv6, the IOAM ingress node will encapsulate the associated flow with | where IOAM is applied. For example, if "protocol-type" is set to | |||
the <xref target="RFC9486">IPv6-IOAM</xref> format.</t> | "ipv6", the IOAM ingress node will encapsulate the associated flow with | |||
the IPv6-IOAM <xref target="RFC9486" format="default"/> format.</t> | ||||
<t>In this document, IOAM data includes five encapsulation types, | <t>In this document, IOAM data includes five encapsulation types, | |||
i.e., incremental tracing data, preallocated tracing data, direct | i.e., incremental tracing data, pre-allocated tracing data, direct | |||
export data, proof of transit data and end to end data. In practice, | export data, proof of transit data, and end-to-end data. In practice, | |||
multiple IOAM data types can be encapsulated into the same IOAM | multiple IOAM data types can be encapsulated into the same IOAM | |||
header. The "profile" contains a set of sub-profiles, each of which | header. The "profile" parameter contains a set of sub-profiles, each of which | |||
relates to one encapsulation type. The configured object may not | relates to one encapsulation type. The configured object may not | |||
support all the sub-profiles. The supported sub-profiles are indicated | support all the sub-profiles. The supported sub-profiles are indicated | |||
by 5 defined features, i.e., "incremental-trace", | by five defined features, i.e., "incremental-trace", | |||
"preallocated-trace", "direct-export", "proof-of-transit" and | "preallocated-trace", "direct-export", "proof-of-transit", and | |||
"edge-to-edge".</t> | "edge-to-edge". | |||
<t>This document uses the <xref target="RFC8519">Access Control List | <!-- [rfced] Section 3.1: Does 'IPv6-IOAM [RFC9486] format' mean | |||
YANG module</xref>, the <xref target="RFC8343">Interfaces YANG | '"IOAM in IPv6" format, per [RFC9486]' or something else? We ask | |||
module</xref> and the <xref target="RFC8532">LIME Time Types YANG | because we do not see "IPv6-IOAM" used in RFC 9486 or any other | |||
module</xref>.</t> | published RFC. | |||
<t>The YANG data model in this document conform to the Network | Original: | |||
Management Datastore Architecture (NMDA) defined in <xref | For example, if the "protocol-type" is | |||
target="RFC8342"/>.</t> | IPv6, the IOAM ingress node will encapsulate the associated flow with | |||
</section> | the IPv6-IOAM [RFC9486] format. --> | |||
<section title="Preallocated Tracing Profile"> | </t> | |||
<t>The IOAM tracing data is expected to be collected at every node | <t>This document uses the <xref target="RFC8519" format="default">"ietf- | |||
that a packet traverses to ensure visibility into the entire path a | access-control-list" YANG module</xref>, the <xref target="RFC8343" format="defa | |||
packet takes within an IOAM domain. The preallocated tracing option | ult">"ietf-interfaces" YANG | |||
module</xref>, and the <xref target="RFC8532" format="default">"ietf-lim | ||||
e-time-types" YANG module</xref>.</t> | ||||
<t>The YANG data model in this document conforms to the Network | ||||
Management Datastore Architecture (NMDA) defined in <xref target="RFC834 | ||||
2" format="default"/>.</t> | ||||
</section> | ||||
<section numbered="true" toc="default" anchor="prealloc-tracing"> | ||||
<name>Pre-allocated Tracing Profile</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 packet traverses. The pre-allocated tracing option | ||||
will create pre-allocated space for each node to populate its | will create pre-allocated space for each node to populate its | |||
information . The "preallocated-tracing-profile" contains the detailed | information. The "preallocated-tracing-profile" parameter contains the d | |||
information for the preallocated tracing data. The information | etailed | |||
information for the pre-allocated tracing data. This information | ||||
includes:</t> | includes:</t> | |||
<dl spacing="normal"> | ||||
<t><list style="symbols"> | <dt>node-action:</dt><dd>indicates the operation (e.g., encapsulate th | |||
<t>node-action: indicates the operation (e.g., encapsulate IOAM | e IOAM | |||
header, transit the IOAM data, or decapsulate IOAM header) applied | header, transit the IOAM data, or decapsulate the IOAM header) appli | |||
to the dedicated flow.</t> | ed | |||
to the dedicated flow.</dd> | ||||
<t>use-namespace: indicates the namespace used for the trace | <dt>use-namespace:</dt><dd>indicates the namespace used for the trace | |||
types.</t> | types.</dd> | |||
<dt>trace-type:</dt><dd>indicates the per-hop data to be captured by | ||||
<t>trace-type: indicates the per-hop data to be captured by the | IOAM-enabled nodes and included in the node data list.</dd> | |||
IOAM enabled nodes and included in the node data list.</t> | <dt>max-length:</dt><dd>specifies the maximum length of the node data | |||
list | ||||
<t>max-length: specifies the maximum length of the node data list | in octets. "max-length" is only defined at the encapsulation | |||
in octets. The max-length is only defined at the encapsulation | node.</dd> | |||
node.</t> | </dl> | |||
</list><figure align="center"> | <sourcecode type="yangtree"><![CDATA[+--rw preallocated-tracing-profile | |||
<artwork><![CDATA[+--rw preallocated-tracing-profile {preallocated-t | {preallocated-trace}? | |||
race}? | ||||
+--rw node-action? ioam-node-action | +--rw node-action? ioam-node-action | |||
+--rw trace-types | +--rw trace-types | |||
| +--rw use-namespace? ioam-namespace | | +--rw use-namespace? ioam-namespace | |||
| +--rw trace-type* ioam-trace-type | | +--rw trace-type* ioam-trace-type | |||
+--rw max-length? uint32]]></artwork> | +--rw max-length? uint32 | |||
</figure></t> | ]]></sourcecode> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Incremental Tracing Profile"> | <name>Incremental Tracing Profile</name> | |||
<t>The incremental tracing option contains a variable node data fields | <t>The incremental tracing option contains a variable node data fields | |||
where each node allocates and pushes its node data immediately | where each node allocates and pushes its node data immediately | |||
following the option header. The "incremental-tracing-profile" | following the option header. The "incremental-tracing-profile" parameter | |||
contains the detailed information for the incremental tracing data. | contains the detailed information for the incremental tracing data. | |||
The detailed information is the same as the Preallocated Tracing | This information is the same as that for the Pre-allocated Tracing | |||
Profile.</t> | Profile; see <xref target="prealloc-tracing"/>. | |||
<t><figure align="center"> | <!-- [rfced] Section 3.3: "a variable node data fields" does not | |||
<artwork><![CDATA[+--rw incremental-tracing-profile {incremental-tra | parse. If the suggested text is not correct, please clarify. | |||
ce}? | ||||
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 node-action? ioam-node-action | |||
+--rw trace-types | +--rw trace-types | |||
| +--rw use-namespace? ioam-namespace | | +--rw use-namespace? ioam-namespace | |||
| +--rw trace-type* ioam-trace-type | | +--rw trace-type* ioam-trace-type | |||
+--rw max-length? uint32]]></artwork> | +--rw max-length? uint32 | |||
</figure></t> | ]]></sourcecode> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Direct Export Profile"> | <name>Direct Export Profile</name> | |||
<t>The direct export option is used as a trigger for IOAM data to be | <t>The direct export option is used as a trigger for IOAM data to be | |||
directly exported or locally aggregated without being pushed into | directly exported or locally aggregated without being pushed into | |||
in-flight data packets. The "direct-export-profile" contains the | in-flight data packets. The "direct-export-profile" parameter contains t | |||
detailed information for the direct export data. The detailed | he | |||
information is the same as the Preallocated Tracing Profile, but with | detailed information for the direct export data. This | |||
information is the same as that for the Pre-allocated Tracing Profile (< | ||||
xref target="prealloc-tracing"/>), but with | ||||
two more optional variables:</t> | two more optional variables:</t> | |||
<dl spacing="normal"> | ||||
<t><list style="symbols"> | <dt>flow-id:</dt><dd>used to correlate the exported data of the same | |||
<t>flow-id: is used to correlate the exported data of the same | flow from multiple nodes and from multiple packets.</dd> | |||
flow from multiple nodes and from multiple packets.</t> | <dt>enable-sequence-number:</dt><dd>indicates whether the sequence num | |||
ber | ||||
<t>enable-sequence-number: indicates whether the sequence number | is used in the direct export option.</dd> | |||
is used in the direct export option.</t> | </dl> | |||
</list><figure> | <sourcecode type="yangtree"><![CDATA[+--rw direct-export-profile {direct | |||
<artwork><![CDATA[+--rw direct-export-profile {direct-export}? | -export}? | |||
+--rw node-action? ioam-node-action | +--rw node-action? ioam-node-action | |||
+--rw trace-types | +--rw trace-types | |||
| +--rw use-namespace? ioam-namespace | | +--rw use-namespace? ioam-namespace | |||
| +--rw trace-type* ioam-trace-type | | +--rw trace-type* ioam-trace-type | |||
+--rw flow-id? uint32 | +--rw flow-id? uint32 | |||
+--rw enable-sequence-number? boolean]]></artwork> | +--rw enable-sequence-number? boolean | |||
</figure></t> | ]]></sourcecode> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Proof of Transit Profile"> | <name>Proof of Transit Profile</name> | |||
<t>The IOAM Proof of Transit data is to support the path or service | <t>The IOAM proof of transit data is used to support the path or service | |||
function chain verification use cases. The "pot-profile" is intended | function chain verification use cases. The "pot-profile" parameter is in | |||
to contain the detailed information for the proof of transit data. | tended | |||
"use-namespace" indicates the namespace used for the POT types. | to contain the detailed information for the proof of transit data. The | |||
"pot-type" indicates a particular POT variant that specifies the POT | "use-namespace" parameter indicates the namespace used for the POT types | |||
data that is included. There may be several POT types, which have | . | |||
different configuration data. To align with <xref target="RFC9197"/>, | The "pot-type" parameter indicates a particular POT variant that specifi | |||
this document only defines IOAM POT type 0. User need to augment this | es the POT | |||
module for the configuration of a specifc POT type.</t> | data that is included. There may be several POT types, each having | |||
different configuration data. To align with <xref target="RFC9197" forma | ||||
<t><figure align="center"> | t="default"/>, | |||
<artwork><![CDATA[+--rw pot-profile {proof-of-transit}? | this document only defines IOAM POT type 0. Users need to augment this | |||
module for the configuration of a specific POT type.</t> | ||||
<sourcecode type="yangtree"><![CDATA[+--rw pot-profile {proof-of-transit | ||||
}? | ||||
+--rw use-namespace? ioam-namespace | +--rw use-namespace? ioam-namespace | |||
+--rw pot-type? ioam-pot-type]]></artwork> | +--rw pot-type? ioam-pot-type | |||
</figure></t> | ]]></sourcecode> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Edge-to-Edge Profile"> | <name>Edge-to-Edge Profile</name> | |||
<t>The IOAM edge-to-edge option is to carry data that is added by the | <t>The IOAM edge-to-edge option is used to carry data that is added by t | |||
IOAM encapsulating node and interpreted by IOAM decapsulating node. | he | |||
The "e2e-profile" contains the detailed information for the | IOAM encapsulating node and interpreted by the IOAM decapsulating node. | |||
edge-to-edge data. The detailed information includes:</t> | The "e2e-profile" parameter contains the detailed information for the | |||
edge-to-edge data. This information includes:</t> | ||||
<t><list style="symbols"> | <dl spacing="normal"> | |||
<t>node-action is the same semantic as in Section 3.2.</t> | <dt>node-action:</dt><dd>the same semantic as that provided in <xref t | |||
arget="prealloc-tracing"/>.</dd> | ||||
<t>use-namespace: indicate the namespace used for the edge-to-edge | <dt>use-namespace:</dt><dd>indicates the namespace used for the edge-t | |||
types.</t> | o-edge | |||
types.</dd> | ||||
<t>e2e-type: indicates data to be carried from the ingress IOAM | <dt>e2e-type:</dt><dd>indicates data to be carried from the ingress IO | |||
node to the egress IOAM node.</t> | AM | |||
</list><figure align="center"> | node to the egress IOAM node.</dd> | |||
<artwork><![CDATA[+--rw e2e-profile {edge-to-edge}? | </dl> | |||
<sourcecode type="yangtree"><![CDATA[+--rw e2e-profile {edge-to-edge}? | ||||
+--rw node-action? ioam-node-action | +--rw node-action? ioam-node-action | |||
+--rw e2e-types | +--rw e2e-types | |||
+--rw use-namespace? ioam-namespace | +--rw use-namespace? ioam-namespace | |||
+--rw e2e-type* ioam-e2e-type]]></artwork> | +--rw e2e-type* ioam-e2e-type | |||
</figure></t> | ]]></sourcecode> | |||
</section> | </section> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<name>IOAM YANG Module</name> | ||||
<section title="IOAM YANG Module"> | <t>The "ietf-ioam" module defined in this document imports typedefs from <xref | |||
<t/> | target="RFC8519"/>, <xref target="RFC8343"/>, and <xref target="RFC8532"/>. Thi | |||
s document also references <xref target="RFC9197"/>, <xref target="RFC9326"/>, < | ||||
xref target="RFC9486"/>, and <xref target="RFC9452"/>. | ||||
<t><figure> | <!-- [rfced] Section 4: We updated this paragraph to more closely | |||
<artwork><![CDATA[<CODE BEGINS> file "ietf-ioam@2024-03-01.yang" | 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/gro | ||||
up/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 { | module ietf-ioam { | |||
yang-version 1.1; | yang-version 1.1; | |||
namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; | namespace "urn:ietf:params:xml:ns:yang:ietf-ioam"; | |||
prefix "ioam"; | prefix "ioam"; | |||
import ietf-access-control-list { | import ietf-access-control-list { | |||
prefix "acl"; | prefix "acl"; | |||
reference | reference | |||
"RFC 8519: YANG Data Model for Network Access Control | "RFC 8519: YANG Data Model for Network Access Control | |||
Lists (ACLs)"; | Lists (ACLs)"; | |||
skipping to change at line 405 ¶ | skipping to change at line 480 ¶ | |||
import ietf-lime-time-types { | import ietf-lime-time-types { | |||
prefix "lime"; | prefix "lime"; | |||
reference | reference | |||
"RFC 8532: Generic YANG Data Model for the Management of | "RFC 8532: Generic YANG Data Model for the Management of | |||
Operations, Administration, and Maintenance (OAM) Protocols | Operations, Administration, and Maintenance (OAM) Protocols | |||
That Use Connectionless Communications"; | That Use Connectionless Communications"; | |||
} | } | |||
organization | organization | |||
"IETF IPPM (IP Performance Metrics) Working Group"; | "IETF IPPM (IP Performance Measurement) Working Group"; | |||
contact | contact | |||
"WG Web: <https://datatracker.ietf.org/wg/ippm> | "WG Web: <https://datatracker.ietf.org/wg/ippm> | |||
WG List: <ippm@ietf.org> | WG List: <mailto:ippm@ietf.org> | |||
Editor: zhoutianran@huawei.com | Editor: Tianran Zhou | |||
Editor: james.n.guichard@futurewei.com | <mailto:zhoutianran@huawei.com> | |||
Editor: fbrockne@cisco.com | Editor: Jim Guichard | |||
Editor: srihari@cisco.com"; | <mailto:james.n.guichard@futurewei.com> | |||
Editor: Frank Brockners | ||||
<mailto:fbrockne@cisco.com> | ||||
Editor: Srihari Raghavan | ||||
<mailto:srihari@cisco.com>"; | ||||
description | description | |||
"This YANG module specifies a vendor-independent data | "This YANG module specifies a vendor-independent data model | |||
model for the In Situ OAM (IOAM). | for In Situ Operations, Administration, and Maintenance | |||
(IOAM). | ||||
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL | |||
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', | NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', | |||
'MAY', and 'OPTIONAL' in this document are to be interpreted as | 'MAY', and 'OPTIONAL' in this document are to be interpreted as | |||
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, | described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, | |||
they appear in all capitals, as shown here. | they appear in all capitals, as shown here. | |||
Copyright (c) 2024 IETF Trust and the persons identified as | Copyright (c) 2024 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
Redistribution and use in source and binary forms, with or | Redistribution and use in source and binary forms, with or | |||
without modification, is permitted pursuant to, and subject to | without modification, is permitted pursuant to, and subject to | |||
the license terms contained in, the Revised BSD License set | the license terms contained in, the Revised BSD License set | |||
forth in Section 4.c of the IETF Trust's Legal Provisions | forth in Section 4.c of the IETF Trust's Legal Provisions | |||
Relating to IETF Documents | Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info). | (https://trustee.ietf.org/license-info). | |||
This version of this YANG module is part of RFC XXXX | This version of this YANG module is part of RFC 9617; see the | |||
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself | RFC itself for full legal notices."; | |||
for full legal notices."; | ||||
revision 2024-03-01 { | revision 2024-07-12 { | |||
description "Initial revision."; | description | |||
reference "RFC XXXX: A YANG Data Model for In-Situ OAM"; | "Initial revision."; | |||
reference | ||||
"RFC 9617: A YANG Data Model for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
/* | /* | |||
* FEATURES | * FEATURES | |||
*/ | */ | |||
feature incremental-trace | feature incremental-trace | |||
{ | { | |||
description | description | |||
"This feature indicated that the incremental tracing option is | "This feature indicates that the incremental tracing option | |||
supported."; | is supported."; | |||
reference "RFC 9197: Data Fields for In-situ OAM"; | reference | |||
"RFC 9197: Data Fields for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
feature preallocated-trace | feature preallocated-trace | |||
{ | { | |||
description | description | |||
"This feature indicated that the preallocated tracing option is | "This feature indicates that the pre-allocated tracing | |||
supported."; | option is supported."; | |||
reference "RFC 9197: Data Fields for In-situ OAM"; | reference | |||
"RFC 9197: Data Fields for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
feature direct-export | feature direct-export | |||
{ | { | |||
description | description | |||
"This feature indicated that the direct export option is | "This feature indicates that the direct export option is | |||
supported."; | supported."; | |||
reference "RFC 9326: In-situ OAM Direct Exporting"; | reference | |||
"RFC 9326: In Situ Operations, Administration, and | ||||
Maintenance (IOAM) Direct Exporting"; | ||||
} | } | |||
feature proof-of-transit | feature proof-of-transit | |||
{ | { | |||
description | description | |||
"This feature indicated that the proof of transit option is | "This feature indicates that the proof of transit option is | |||
supported"; | supported."; | |||
reference "RFC 9197: Data Fields for In-situ OAM"; | reference | |||
"RFC 9197: Data Fields for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
feature edge-to-edge | feature edge-to-edge | |||
{ | { | |||
description | description | |||
"This feature indicated that the edge-to-edge option is | "This feature indicates that the edge-to-edge option is | |||
supported."; | supported."; | |||
reference "RFC 9197: Data Fields for In-situ OAM"; | reference | |||
"RFC 9197: Data Fields for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
/* | /* | |||
* IDENTITIES | * IDENTITIES | |||
*/ | */ | |||
identity filter { | identity filter { | |||
description | description | |||
"Base identity to represent a filter. A filter is used to | "Base identity to represent a filter. A filter is used to | |||
specify the flow to apply the IOAM profile. "; | specify the flow to apply the IOAM profile."; | |||
} | } | |||
identity acl-filter { | identity acl-filter { | |||
base filter; | base filter; | |||
description | description | |||
"Apply ACL rules to specify the flow."; | "Apply Access Control List (ACL) rules to specify the | |||
flow."; | ||||
} | } | |||
identity protocol { | identity protocol { | |||
description | description | |||
"Base identity to represent the carrier protocol. It's used to | "Base identity to represent the carrier protocol. It is | |||
indicate what layer and protocol the IOAM data is embedded."; | used to indicate in what layer and protocol the IOAM data | |||
is embedded."; | ||||
} | } | |||
identity ipv6 { | identity ipv6 { | |||
base protocol; | base protocol; | |||
description | description | |||
"The described IOAM data is embedded in IPv6 protocol."; | "The described IOAM data is embedded in IPv6."; | |||
reference | reference | |||
"RFC 9486: In-situ OAM IPv6 Options"; | "RFC 9486: IPv6 Options for In Situ Operations, | |||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
identity nsh { | identity nsh { | |||
base protocol; | base protocol; | |||
description | description | |||
"The described IOAM data is embedded in NSH."; | "The described IOAM data is embedded in the Network Service | |||
Header (NSH)."; | ||||
reference | reference | |||
"RFC 9452: Network Service Header (NSH) | "RFC 9452: Network Service Header (NSH) Encapsulation for | |||
Encapsulation for In-situ OAM (IOAM) Data"; | In Situ OAM (IOAM) Data"; | |||
} | } | |||
identity node-action { | identity node-action { | |||
description | description | |||
"Base identity to represent the node actions. It's used to | "Base identity to represent the node actions. It is used to | |||
indicate what action the node will take."; | indicate what action the node will take."; | |||
} | } | |||
identity action-encapsulate { | identity action-encapsulate { | |||
base node-action; | base node-action; | |||
description | description | |||
"It indicates the node is to encapsulate the IOAM packet"; | "This identity indicates that the node is used to | |||
encapsulate the IOAM packet."; | ||||
} | } | |||
identity action-decapsulate { | identity action-decapsulate { | |||
base node-action; | base node-action; | |||
description | description | |||
"It indicates the node is to decapsulate the IOAM packet"; | "This identity indicates that the node is used to | |||
decapsulate the IOAM packet."; | ||||
} | } | |||
identity action-transit { | identity action-transit { | |||
base node-action; | base node-action; | |||
description | description | |||
"It indicates the node is to transit the IOAM packet"; | "This identity indicates that the node is used to transit | |||
the IOAM packet."; | ||||
} | } | |||
identity trace-type { | identity trace-type { | |||
description | description | |||
"Base identity to represent trace types."; | "Base identity to represent trace types."; | |||
} | } | |||
identity trace-hop-lim-node-id { | identity trace-hop-lim-node-id { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates the presence of Hop_Lim and node_id in the | "This identity indicates the presence of 'Hop_Lim' and | |||
node data."; | 'node_id' in the node data."; | |||
reference | ||||
"RFC 9197: Data Fields for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | } | |||
identity trace-if-id { | identity trace-if-id { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of ingress_if_id and egress_if_id | "This identity indicates the presence of 'ingress_if_id' and | |||
(short format) in the node data."; | '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 { | identity trace-timestamp-seconds { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of timestamp seconds in the node data."; | "This identity indicates the presence of timestamp seconds | |||
in the node data."; | ||||
} | } | |||
identity trace-timestamp-fraction { | identity trace-timestamp-fraction { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of timestamp fraction in the node | "This identity indicates the presence of a timestamp | |||
data."; | fraction in the node data."; | |||
} | } | |||
identity trace-transit-delay { | identity trace-transit-delay { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of transit delay in the node data."; | "This identity indicates the presence of transit delay in | |||
the node data."; | ||||
} | } | |||
identity trace-namespace-data { | identity trace-namespace-data { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of name space specific data (short | "This identity indicates the presence of namespace-specific | |||
format) in the node data."; | data (short format) in the node data."; | |||
} | } | |||
identity trace-queue-depth { | identity trace-queue-depth { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of queue depth in the node data."; | "This identity indicates the presence of queue depth in the | |||
node data."; | ||||
} | } | |||
identity trace-checksum-complement { | identity trace-checksum-complement { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of the Checksum Complement node data."; | "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 { | identity trace-hop-lim-node-id-wide { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of Hop_Lim and node_id in wide format | "This identity indicates the presence of 'Hop_Lim' and | |||
in the node data."; | 'node_id' (wide format) in the node data."; | |||
} | } | |||
identity trace-if-id-wide { | identity trace-if-id-wide { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of ingress_if_id and egress_if_id in | "This identity indicates the presence of 'ingress_if_id' and | |||
wide format in the node data."; | 'egress_if_id' (wide format) in the node data."; | |||
} | } | |||
identity trace-namespace-data-wide { | identity trace-namespace-data-wide { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of IOAM-Namespace specific data in wide | "This identity indicates the presence of | |||
format in the node data."; | IOAM-namespace-specific data (wide format) in the | |||
node data."; | ||||
} | } | |||
identity trace-buffer-occupancy { | identity trace-buffer-occupancy { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of buffer occupancy in the node data."; | "This identity indicates the presence of buffer occupancy | |||
in the node data."; | ||||
} | } | |||
identity trace-opaque-state-snapshot { | identity trace-opaque-state-snapshot { | |||
base trace-type; | base trace-type; | |||
description | description | |||
"It indicates presence of variable length Opaque State Snapshot | "This identity indicates the presence of the variable-length | |||
field."; | Opaque State Snapshot field."; | |||
} | } | |||
identity pot-type { | identity pot-type { | |||
description | description | |||
"Base identity to represent Proof of Transit (PoT) types."; | "Base identity to represent Proof of Transit (POT) types."; | |||
} | } | |||
identity pot-type-0 { | identity pot-type-0 { | |||
base pot-type; | base pot-type; | |||
description | description | |||
"The IOAM POT Type field value is 0, and POT data is a 16 | "The IOAM field value for the POT type is 0, and POT data is | |||
Octet field to carry data associated to POT procedures."; | a 16-octet field to carry data associated with POT | |||
procedures."; | ||||
} | } | |||
identity e2e-type { | identity e2e-type { | |||
description | description | |||
"Base identity to represent edge-to-edge types."; | "Base identity to represent edge-to-edge types."; | |||
} | } | |||
identity e2e-seq-num-64 { | identity e2e-seq-num-64 { | |||
base e2e-type; | base e2e-type; | |||
description | description | |||
"It indicates presence of a 64-bit sequence number."; | "This identity indicates the presence of a 64-bit | |||
sequence number."; | ||||
} | } | |||
identity e2e-seq-num-32 { | identity e2e-seq-num-32 { | |||
base e2e-type; | base e2e-type; | |||
description | description | |||
"It indicates the presence of a 32-bit sequence number."; | "This identity indicates the presence of a 32-bit | |||
sequence number."; | ||||
} | } | |||
identity e2e-timestamp-seconds { | identity e2e-timestamp-seconds { | |||
base e2e-type; | base e2e-type; | |||
description | description | |||
"It indicates the presence of timestamp seconds representing | "This identity indicates the presence of timestamp seconds | |||
the time at which the packet entered the IOAM-domain."; | representing the time at which the packet entered the | |||
IOAM domain."; | ||||
} | } | |||
identity e2e-timestamp-fraction { | identity e2e-timestamp-fraction { | |||
base e2e-type; | base e2e-type; | |||
description | description | |||
"It indicates the presence of timestamp fraction representing | "This identity indicates the presence of a timestamp | |||
the time at which the packet entered the IOAM-domain."; | fraction representing the time at which the packet entered | |||
the IOAM domain."; | ||||
} | } | |||
identity namespace { | identity namespace { | |||
description | description | |||
"Base identity to represent the Namespace-ID."; | "Base identity to represent the Namespace-ID."; | |||
} | } | |||
identity default-namespace { | identity default-namespace { | |||
base namespace; | base namespace; | |||
description | description | |||
skipping to change at line 705 ¶ | skipping to change at line 824 ¶ | |||
} | } | |||
/* | /* | |||
* TYPE DEFINITIONS | * TYPE DEFINITIONS | |||
*/ | */ | |||
typedef ioam-filter-type { | typedef ioam-filter-type { | |||
type identityref { | type identityref { | |||
base filter; | base filter; | |||
} | } | |||
description | description | |||
"It specifies a known type of filter."; | "This type specifies a known type of filter."; | |||
} | } | |||
typedef ioam-protocol-type { | typedef ioam-protocol-type { | |||
type identityref { | type identityref { | |||
base protocol; | base protocol; | |||
} | } | |||
description | description | |||
"It specifies a known type of carrier protocol for the IOAM | "This type specifies a known type of carrier protocol for | |||
data."; | the IOAM data."; | |||
} | } | |||
typedef ioam-node-action { | typedef ioam-node-action { | |||
type identityref { | type identityref { | |||
base node-action; | base node-action; | |||
} | } | |||
description | description | |||
"It specifies a known type of node action."; | "This type specifies a known type of node action."; | |||
} | } | |||
typedef ioam-trace-type { | typedef ioam-trace-type { | |||
type identityref { | type identityref { | |||
base trace-type; | base trace-type; | |||
} | } | |||
description | description | |||
"It specifies a known trace type."; | "This type specifies a known trace type."; | |||
} | } | |||
typedef ioam-pot-type { | typedef ioam-pot-type { | |||
type identityref { | type identityref { | |||
base pot-type; | base pot-type; | |||
} | } | |||
description | description | |||
"It specifies a known pot type."; | "This type specifies a known POT type."; | |||
} | } | |||
typedef ioam-e2e-type { | typedef ioam-e2e-type { | |||
type identityref { | type identityref { | |||
base e2e-type; | base e2e-type; | |||
} | } | |||
description | description | |||
"It specifies a known edge-to-edge type."; | "This type specifies a known edge-to-edge type."; | |||
} | } | |||
typedef ioam-namespace { | typedef ioam-namespace { | |||
type identityref { | type identityref { | |||
base namespace; | base namespace; | |||
} | } | |||
description | description | |||
"It specifies the supported namespace."; | "This type specifies the supported namespace."; | |||
} | } | |||
/* | /* | |||
* GROUP DEFINITIONS | * GROUP DEFINITIONS | |||
*/ | */ | |||
grouping ioam-filter { | grouping ioam-filter { | |||
description "A grouping for IOAM filter definition"; | description | |||
"A grouping for IOAM filter definitions."; | ||||
leaf filter-type { | leaf filter-type { | |||
type ioam-filter-type; | type ioam-filter-type; | |||
description "filter type"; | description | |||
"Filter type."; | ||||
} | } | |||
leaf ace-name { | leaf ace-name { | |||
when "derived-from-or-self(../filter-type, 'ioam:acl-filter')"; | when "derived-from-or-self(../filter-type, 'ioam:acl-filter')"; | |||
type leafref { | type leafref { | |||
path "/acl:acls/acl:acl/acl:aces/acl:ace/acl:name"; | path "/acl:acls/acl:acl/acl:aces/acl:ace/acl:name"; | |||
} | } | |||
description "The Access Control Entry name is used to | description | |||
refer to an ACL specification."; | "The Access Control Entry name is used to refer to an ACL | |||
specification."; | ||||
} | } | |||
} | } | |||
grouping encap-tracing { | grouping encap-tracing { | |||
description | description | |||
"A grouping for the generic configuration for | "A grouping for the generic configuration for the | |||
tracing profile."; | tracing profile."; | |||
container trace-types { | container trace-types { | |||
description | description | |||
"It indicates the list of trace types for encapsulation."; | "This container provides the list of trace types for | |||
encapsulation."; | ||||
leaf use-namespace { | leaf use-namespace { | |||
type ioam-namespace; | type ioam-namespace; | |||
default default-namespace; | default default-namespace; | |||
description | description | |||
"It indicates the name space used for encapsulation."; | "This object indicates the namespace used for | |||
encapsulation."; | ||||
} | } | |||
leaf-list trace-type { | leaf-list trace-type { | |||
type ioam-trace-type; | type ioam-trace-type; | |||
description | description | |||
"The trace type is only defined at the encapsulation | "The trace type is only defined at the encapsulation | |||
node."; | node."; | |||
} | } | |||
} | } | |||
leaf max-length { | leaf max-length { | |||
when "derived-from-or-self(../node-action, | when "derived-from-or-self(../node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
type uint32; | type uint32; | |||
units bytes; | units bytes; | |||
description | description | |||
"This field specifies the maximum length of the node data | "This field specifies the maximum length of the node data | |||
list in octets. The max-length is only defined at the | list in octets. 'max-length' is only defined at the | |||
encapsulation node."; | encapsulation node."; | |||
} | } | |||
} | } | |||
grouping ioam-incremental-tracing-profile { | grouping ioam-incremental-tracing-profile { | |||
description | description | |||
"A grouping for incremental tracing profile."; | "A grouping for the Incremental Tracing Profile."; | |||
leaf node-action { | leaf node-action { | |||
type ioam-node-action; | type ioam-node-action; | |||
default action-transit; | default action-transit; | |||
description | description | |||
"This object indicates the action the node need to | "This object indicates the action the node needs to | |||
take, e.g. encapsulation."; | take, e.g., encapsulation."; | |||
} | } | |||
uses encap-tracing { | uses encap-tracing { | |||
when "derived-from-or-self(node-action, | when "derived-from-or-self(node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
} | } | |||
} | } | |||
grouping ioam-preallocated-tracing-profile { | grouping ioam-preallocated-tracing-profile { | |||
description | description | |||
"A grouping for pre-allocated tracing profile."; | "A grouping for the Pre-allocated Tracing Profile."; | |||
leaf node-action { | leaf node-action { | |||
type ioam-node-action; | type ioam-node-action; | |||
default action-transit; | default action-transit; | |||
description | description | |||
"This object indicates the action the node need to | "This object indicates the action the node needs to | |||
take, e.g. encapsulation."; | take, e.g., encapsulation."; | |||
} | } | |||
uses encap-tracing { | uses encap-tracing { | |||
when "derived-from-or-self(node-action, | when "derived-from-or-self(node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
} | } | |||
} | } | |||
grouping ioam-direct-export-profile { | grouping ioam-direct-export-profile { | |||
description | description | |||
"A grouping for direct export profile."; | "A grouping for the Direct Export Profile."; | |||
leaf node-action { | leaf node-action { | |||
type ioam-node-action; | type ioam-node-action; | |||
default action-transit; | default action-transit; | |||
description | description | |||
"This object indicates the action the node need to | "This object indicates the action the node needs to | |||
take, e.g. encapsulation."; | take, e.g., encapsulation."; | |||
} | } | |||
uses encap-tracing { | uses encap-tracing { | |||
when "derived-from-or-self(node-action, | when "derived-from-or-self(node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
} | } | |||
leaf flow-id { | leaf flow-id { | |||
when "derived-from-or-self(../node-action, | when "derived-from-or-self(../node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
type uint32; | type uint32; | |||
description | description | |||
"A 32-bit flow identifier. The field is set at the | "A 32-bit flow identifier. The field is set at the | |||
encapsulating node. The Flow ID can be uniformly assigned | encapsulating node. The Flow ID can be uniformly | |||
by a central controller or algorithmically generated by the | assigned by a central controller or algorithmically | |||
encapsulating node. The latter approach cannot guarantee | generated by the encapsulating node. The latter approach | |||
the uniqueness of Flow ID, yet the conflict probability is | cannot guarantee the uniqueness of the Flow ID, yet the | |||
small due to the large Flow ID space. flow-id is used to | probability of conflict is small due to the large Flow ID | |||
correlate the exported data of the same flow from multiple | space. 'flow-id' is used to correlate the exported data | |||
nodes and from multiple packets."; | of the same flow from multiple nodes and from multiple | |||
packets."; | ||||
} | } | |||
leaf enable-sequence-number { | leaf enable-sequence-number { | |||
when "derived-from-or-self(../node-action, | when "derived-from-or-self(../node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
type boolean; | type boolean; | |||
default false; | default false; | |||
description | description | |||
"This boolean value indicates whether the sequence number is | "This boolean value indicates whether the sequence number | |||
used in the direct export option 32-bit flow identifier. If | is used in the direct export option's 32-bit flow | |||
this value is true, the sequence number is used. By default, | identifier. If this value is set to 'true', the sequence | |||
it's turned off."; | number is used. It is turned off by default."; | |||
} | } | |||
} | } | |||
grouping ioam-e2e-profile { | grouping ioam-e2e-profile { | |||
description | description | |||
"A grouping for edge-to-edge profile."; | "A grouping for the Edge-to-Edge Profile."; | |||
leaf node-action { | leaf node-action { | |||
type ioam-node-action; | type ioam-node-action; | |||
default action-transit; | default action-transit; | |||
description | description | |||
"This object indicates the action the node need to | "This object indicates the action the node needs to | |||
take, e.g. encapsulation."; | take, e.g., encapsulation."; | |||
} | } | |||
container e2e-types { | container e2e-types { | |||
when "derived-from-or-self(../node-action, | when "derived-from-or-self(../node-action, | |||
'ioam:action-encapsulate')"; | 'ioam:action-encapsulate')"; | |||
description | description | |||
"It indicates the list of edge-to-edge types for | "This container provides the list of edge-to-edge types | |||
encapsulation."; | for encapsulation."; | |||
leaf use-namespace { | leaf use-namespace { | |||
type ioam-namespace; | type ioam-namespace; | |||
default default-namespace; | default default-namespace; | |||
description | description | |||
"It indicates the name space used for encapsulation."; | "This object indicates the namespace used for | |||
encapsulation."; | ||||
} | } | |||
leaf-list e2e-type { | leaf-list e2e-type { | |||
type ioam-e2e-type; | type ioam-e2e-type; | |||
description | description | |||
"The edge-to-edge type is only defined at the encapsulation | "The edge-to-edge type is only defined at the | |||
node."; | encapsulation node."; | |||
} | } | |||
} | } | |||
} | } | |||
grouping ioam-admin-config { | grouping ioam-admin-config { | |||
description | description | |||
"IOAM top-level administrative configuration."; | "IOAM top-level administrative configuration."; | |||
leaf enabled { | leaf enabled { | |||
type boolean; | type boolean; | |||
default false; | default false; | |||
description | description | |||
"This object is to control the availability of configuration. | "This object is used to control the availability of | |||
It MUST be true before anything in the | configuration. It MUST be set to 'true' before anything | |||
/ioam/profiles/profile subtree can be edited. | in the /ioam/profiles/profile subtree can be edited. | |||
If false, any configuration in place is not used."; | If 'false', any configuration in place is not used."; | |||
} | } | |||
} | } | |||
/* | /* | |||
* DATA NODES | * DATA NODES | |||
*/ | */ | |||
container ioam { | container ioam { | |||
description "IOAM top level container"; | description | |||
"IOAM top-level container."; | ||||
container info { | container info { | |||
config false; | config false; | |||
description | description | |||
"Describes information such as units or timestamp format that | "Describes information, such as units or timestamp format, | |||
assists monitoring systems in the interpretation of the IOAM | that assists monitoring systems in the interpretation of | |||
data."; | the IOAM data."; | |||
leaf timestamp-type { | leaf timestamp-type { | |||
type identityref { | type identityref { | |||
base lime:timestamp-type; | base lime:timestamp-type; | |||
} | } | |||
description | description | |||
"Type of timestamp, such as Truncated PTP or NTP."; | "Type of timestamp, such as Truncated PTP (Precision | |||
Time Protocol) or NTP."; | ||||
} | } | |||
list available-interface { | list available-interface { | |||
key "if-name"; | key "if-name"; | |||
description | description | |||
"A list of available interfaces that support IOAM."; | "A list of available interfaces that support IOAM."; | |||
leaf if-name { | leaf if-name { | |||
type if:interface-ref; | type if:interface-ref; | |||
description "This is a reference to the Interface name."; | description | |||
"This is a reference to the interface name."; | ||||
} | } | |||
} | } | |||
} | } | |||
container admin-config { | container admin-config { | |||
description | description | |||
"Contains all the administrative configurations related to | "Contains all the administrative configurations related to | |||
the IOAM functionalities and all the IOAM profiles."; | the IOAM functionalities and all the IOAM profiles."; | |||
uses ioam-admin-config; | uses ioam-admin-config; | |||
} | } | |||
container profiles { | container profiles { | |||
description | description | |||
"Contains a list of IOAM profiles."; | "Contains a list of IOAM profiles."; | |||
list profile { | list profile { | |||
key "profile-name"; | key "profile-name"; | |||
description | description | |||
"A list of IOAM profiles that configured on the node. | "A list of IOAM profiles that are configured on the | |||
There is no mandatory type of profile (e.g., | node. There is no mandatory type of profile (e.g., | |||
incremental-trace, preallocated-trace.) in the list. | 'incremental-trace', 'preallocated-trace') in the list. | |||
But at least one profile should be added."; | But at least one profile should be added."; | |||
leaf profile-name { | leaf profile-name { | |||
type string{ | type string{ | |||
length "1..300"; | length "1..300"; | |||
} | } | |||
description | description | |||
"Unique identifier for each IOAM profile."; | "Unique identifier for each IOAM profile."; | |||
} | } | |||
container filter { | container filter { | |||
uses ioam-filter; | uses ioam-filter; | |||
description | description | |||
"The filter which is used to indicate the flow to apply | "The filter that is used to indicate the flow to apply | |||
IOAM."; | IOAM."; | |||
} | } | |||
leaf protocol-type { | leaf protocol-type { | |||
type ioam-protocol-type; | type ioam-protocol-type; | |||
description | description | |||
"This item is used to indicate the carrier protocol where | "This object is used to indicate the carrier protocol | |||
the IOAM is applied."; | where IOAM is applied."; | |||
} | } | |||
container incremental-tracing-profile { | container incremental-tracing-profile { | |||
if-feature incremental-trace; | if-feature incremental-trace; | |||
presence "Enables incremental tracing option."; | presence "Enables the incremental tracing option."; | |||
description | description | |||
"It describes the profile for incremental tracing | "This container describes the profile for the | |||
option."; | incremental tracing option."; | |||
uses ioam-incremental-tracing-profile; | uses ioam-incremental-tracing-profile; | |||
} | } | |||
container preallocated-tracing-profile { | container preallocated-tracing-profile { | |||
if-feature preallocated-trace; | if-feature preallocated-trace; | |||
presence "Enables preallocated tracing option."; | presence "Enables the pre-allocated tracing option."; | |||
description | description | |||
"It describes the profile for preallocated tracing | "This container describes the profile for the | |||
option."; | pre-allocated tracing option."; | |||
uses ioam-preallocated-tracing-profile; | uses ioam-preallocated-tracing-profile; | |||
} | } | |||
container direct-export-profile { | container direct-export-profile { | |||
if-feature direct-export; | if-feature direct-export; | |||
presence "Enables direct-export option."; | presence "Enables the direct export option."; | |||
description | description | |||
"It describes the profile for direct-export option"; | "This container describes the profile for the | |||
direct export option."; | ||||
uses ioam-direct-export-profile; | uses ioam-direct-export-profile; | |||
} | } | |||
container pot-profile { | container pot-profile { | |||
if-feature proof-of-transit; | if-feature proof-of-transit; | |||
presence "Enables Proof of Transit option."; | presence "Enables the proof of transit (POT) option."; | |||
description | description | |||
"It describes the profile for PoT option."; | "This container describes the profile for the | |||
POT option."; | ||||
leaf use-namespace { | leaf use-namespace { | |||
type ioam-namespace; | type ioam-namespace; | |||
default default-namespace; | default default-namespace; | |||
description | description | |||
"It indicates the namespace used for the POT types."; | "This object indicates the namespace used for the | |||
POT types."; | ||||
} | } | |||
leaf pot-type { | leaf pot-type { | |||
type ioam-pot-type; | type ioam-pot-type; | |||
description | description | |||
"The type of a particular POT variant that specifies | "The type of a particular POT variant that specifies | |||
the POT data that is included."; | the POT data that is included."; | |||
} | } | |||
} | } | |||
container e2e-profile { | container e2e-profile { | |||
if-feature edge-to-edge; | if-feature edge-to-edge; | |||
presence "Enables edge-to-edge option."; | presence "Enables the edge-to-edge option."; | |||
description | description | |||
"It describes the profile for edge-to-edge option."; | "This container describes the profile for the | |||
edge-to-edge option."; | ||||
uses ioam-e2e-profile; | uses ioam-e2e-profile; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
<CODE ENDS>]]></artwork> | ]]></sourcecode> | |||
</figure></t> | ||||
<t/> | <!-- [rfced] Section 4: | |||
</section> | ||||
<section anchor="Security" title="Security Considerations"> | a) The contact list in the YANG module does not match the | |||
<t>The YANG module specified in this document defines a schema for data | contact/author list on Page 1 of this document. May we update as | |||
that is designed to be accessed via network management protocols such as | suggested, or should all authors perhaps have "editor" designations | |||
<xref target="RFC6241">NETCONF</xref> or <xref | on the front page (in which case we would need AD approval)? | |||
target="RFC8040">RESTCONF</xref>. The lowest NETCONF layer is the secure | ||||
transport layer, and the mandatory-to-implement secure transport is | ||||
<xref target="RFC6242">Secure Shell (SSH)</xref>. The lowest RESTCONF | ||||
layer is HTTPS, and the mandatory-to-implement secure transport is <xref | ||||
target="RFC8446">TLS</xref>.</t> | ||||
<t>The <xref target="RFC8341">Network Configuration Access Control Model | Original: | |||
(NACM)</xref> provides the means to restrict access for particular | contact | |||
NETCONF or RESTCONF users to a preconfigured subset of all available | "WG Web: <https://datatracker.ietf.org/wg/ippm> | |||
NETCONF or RESTCONF protocol operations and content.</t> | WG List: <ippm@ietf.org> | |||
Editor: zhoutianran@huawei.com | ||||
Editor: james.n.guichard@futurewei.com | ||||
Editor: fbrockne@cisco.com | ||||
Editor: srihari@cisco.com"; | ||||
<t>There are a number of data nodes defined in this YANG module that are | Suggested (to match the current front page): | |||
writable/creatable/deletable (i.e., config true, which is the default). | contact | |||
These data nodes may be considered sensitive or vulnerable in some | "WG Web: <https://datatracker.ietf.org/wg/ippm> | |||
network environments. Write operations (e.g., edit-config) to these data | WG List: <mailto:ippm@ietf.org> | |||
nodes without proper protection can have a negative effect on network | Editor: Tianran Zhou | |||
operations. These are the subtrees and data nodes and their | <mailto:zhoutianran@huawei.com> | |||
sensitivity/vulnerability:</t> | Editor: Jim Guichard | |||
<mailto:james.n.guichard@futurewei.com> | ||||
Editor: Frank Brockners | ||||
<mailto:fbrockne@cisco.com> | ||||
Editor: Srihari Raghavan | ||||
<mailto:srihari@cisco.com>"; | ||||
<t><list style="symbols"> | b) We do not see "Hop_Lim", "node_id", "ingress_if_id", or | |||
<t>/ioam/admin-config: The items in the container above include the | "egress_if_id" mentioned anywhere else in this document, but we see | |||
top level administrative configurations related to the IOAM | them mentioned in RFC 9197. For ease of the reader, we added | |||
functionalities and all the IOAM profiles. Unexpected changes to | references for RFC 9197 accordingly. Please let us know any | |||
these items could lead to the IOAM function disruption and/or | objections. | |||
misbehavior of all the IOAM profiles.</t> | ||||
</list></t> | ||||
<t><list style="symbols"> | Original: | |||
<t>/ioam/profiles/profile: The entries in the list above include the | identity trace-hop-lim-node-id { | |||
whole IOAM profile configurations. Unexpected changes to these | base trace-type; | |||
entries could lead to the mistake of the IOAM behavior for the | description | |||
corresponding flows. Consequently, it will impact the performance | "It indicates the presence of Hop_Lim and node_id in the | |||
monitoring, data analytics, and the associated reaction to network | node data."; | |||
services.</t> | } | |||
</list></t> | ||||
<t>Some readable data nodes in these YANG modules may be considered | identity trace-if-id { | |||
sensitive or vulnerable in some network environments. It is thus | base trace-type; | |||
important to control read access (e.g., via get, get-config, or | description | |||
notification) to these data nodes. These are the subtrees and data nodes | "It indicates presence of ingress_if_id and egress_if_id | |||
and their sensitivity/vulnerability:</t> | (short format) in the node data."; | |||
} | ||||
<t><list style="symbols"> | Currently: | |||
<t>/ioam/profiles/profile: The information contained in this subtree | identity trace-hop-lim-node-id { | |||
might give information about the services deployed for the | base trace-type; | |||
customers.For instance, a customer might be given access to monitor | description | |||
their services status. In that example, the customer access should | "This identity indicates the presence of 'Hop_Lim' and | |||
be restricted to nodes representing their services so as not to | 'node_id' in the node data."; | |||
divulge information about the underlying network structure or | reference | |||
services.</t> | "RFC 9197: Data Fields for In Situ Operations, | |||
</list></t> | Administration, and Maintenance (IOAM)"; | |||
} | ||||
<t/> | identity trace-if-id { | |||
</section> | 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)"; | ||||
} | ||||
<section anchor="IANA" title="IANA Considerations"> | c) We do not see "Checksum Complement" mentioned anywhere else in | |||
<t>RFC Ed.: In this section, replace all occurrences of 'XXXX' with the | this document, but we see it mentioned in RFC 9197. For ease of the | |||
actual RFC number (and remove this note).</t> | reader, we added a reference for RFC 9197 accordingly. Please let us | |||
know any objections. | ||||
<t>IANA is requested to assign a new URI from the <xref | Original: | |||
target="RFC3688">IETF XML Registry</xref>. The following URI is | identity trace-checksum-complement { | |||
suggested:</t> | base trace-type; | |||
description | ||||
"It indicates presence of the Checksum Complement node data."; | ||||
} | ||||
<t><figure> | Currently: | |||
<artwork align="left"><![CDATA[ URI: urn:ietf:params:xml:ns:yan | identity trace-checksum-complement { | |||
g:ietf-ioam | base trace-type; | |||
Registrant Contact: The IESG. | description | |||
XML: N/A; the requested URI is an XML namespace.]]></artwork> | "This identity indicates the presence of the Checksum | |||
</figure></t> | Complement in the node data."; | |||
reference | ||||
"RFC 9197: Data Fields for In Situ Operations, | ||||
Administration, and Maintenance (IOAM)"; | ||||
} | ||||
<t>This document also requests a new YANG module name in the <xref | d) This sentence was missing one or more words. We changed | |||
target="RFC7950">YANG Module Names registry</xref> with the following | "profiles that configured on" to "profiles that are configured on". | |||
suggestion:</t> | If this is incorrect, please clarify the text. | |||
<t><figure> | Original: | |||
<artwork align="left"><![CDATA[ name: ietf-ioam | list profile { | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-ioam | key "profile-name"; | |||
prefix: ioam | description | |||
reference: RFC XXXX]]></artwork> | "A list of IOAM profiles that configured on the node. | |||
</figure></t> | There is no mandatory type of profile (e.g., | |||
</section> | 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 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> | ||||
</section> | </section> | |||
</middle> | <section anchor="Security" 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 <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. | ||||
The lowest NETCONF layer is the secure transport layer, and the | ||||
mandatory-to-implement secure transport is Secure Shell (SSH) | ||||
<xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the | ||||
mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t | ||||
> | ||||
<back> | <!-- YANG security cons. boilerplate paragraph 2 --> | |||
<references title="Normative References"> | <t>The Network Configuration Access Control Model (NACM) <xref target= | |||
<?rfc include='reference.RFC.2119'?> | "RFC8341"/> | |||
provides the means to restrict access for particular NETCONF or RESTCONF us | ||||
ers | ||||
to a preconfigured subset of all available NETCONF or RESTCONF protocol | ||||
operations and content.</t> | ||||
<?rfc include='reference.RFC.8174'?> | <!-- 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). The | ||||
se | ||||
data nodes may be considered sensitive or vulnerable in some network | ||||
environments. Write operations (e.g., edit-config) to these data nodes with | ||||
out | ||||
proper protection can have a negative effect on network operations. These a | ||||
re | ||||
the subtrees and data nodes and their sensitivity/vulnerability:</t> | ||||
<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 includ | ||||
e 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 performan | ||||
ce | ||||
monitoring, data analytics, and the associated reaction to network | ||||
services.</dd> | ||||
<?rfc include='reference.RFC.7950'?> | <!-- [rfced] Section 5: | |||
<?rfc include='reference.RFC.8340'?> | 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. | ||||
<?rfc include='reference.RFC.8342'?> | 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 IOAM profiles. | ||||
<?rfc include='reference.RFC.3688'?> | * /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. | ||||
<?rfc include='reference.RFC.6241'?> | 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. | ||||
<?rfc include='reference.RFC.8040'?> | /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. | ||||
<?rfc include='reference.RFC.6242'?> | 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". | ||||
<?rfc include='reference.RFC.8446'?> | Original: | |||
Unexpected changes to these | ||||
entries could lead to the mistake of the IOAM behavior for the | ||||
corresponding flows. | ||||
<?rfc include='reference.RFC.8341'?> | Currently: | |||
Unexpected changes to these | ||||
entries could lead to incorrect IOAM behavior for the | ||||
corresponding flows. | ||||
<?rfc include='reference.RFC.8343'?> | c) We had trouble following this sentence. Please clarify the | |||
meaning of "reaction to network services". | ||||
<?rfc include='reference.RFC.8519'?> | Original: | |||
Consequently, it will impact the performance | ||||
monitoring, data analytics, and the associated reaction to network | ||||
services. | ||||
<?rfc include='reference.RFC.8532'?> | Currently: | |||
Consequently, such changes would impact | ||||
performance monitoring, data analytics, and the associated | ||||
reaction to network services. | ||||
<?rfc include='reference.RFC.9197'?> | Possibly: | |||
Consequently, such changes would impact | ||||
performance monitoring, data analytics, and associated interactions | ||||
with network services. --> | ||||
<?rfc include='reference.RFC.9326'?> | </dl> | |||
<!-- YANG security cons. boilerplate paragraph 4 --> | ||||
<t>Some of the readable data nodes in this YANG module 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 d | ||||
ata | ||||
nodes. These are the subtrees and data nodes and their | ||||
sensitivity/vulnerability:</t> | ||||
<dl spacing="normal"> | ||||
<dt>/ioam/profiles/profile:</dt><dd>The information contained in this su | ||||
btree | ||||
might reveal information about the services deployed for | ||||
customers. For instance, a customer might be given access to monitor | ||||
the status of their services. In this scenario, the customer's access | ||||
should | ||||
be restricted to nodes representing their services so as not to | ||||
divulge information about the underlying network structure or | ||||
services.</dd> | ||||
</dl> | ||||
<?rfc include='reference.RFC.9452'?> | <!-- [rfced] Section 5: Authors and *[AD]: It appears that this | |||
document 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 the RPC operations in this YANG module ..." | ||||
paragraph does not apply to this document. --> | ||||
<?rfc include='reference.RFC.9486'?> | </section> | |||
</references> | ||||
<section title="An Example of Incremental Tracing Profile"> | <section anchor="IANA" numbered="true" toc="default"> | |||
<t>An example of incremental tracing profile is depicted in the | <name>IANA Considerations</name> | |||
<t>IANA has registered the following URI in the <xref target="RFC3688" for | ||||
mat="default">"IETF XML 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 XML namespace.</dd> | ||||
</dl> | ||||
<t>IANA has registered the following YANG module in the <xref target="RFC6 | ||||
020" 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 YANG Module | ||||
Names registry [RFC7950] with the following 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)", RFC 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> | ||||
<name>Normative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211 | ||||
9.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817 | ||||
4.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.795 | ||||
0.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.602 | ||||
0.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834 | ||||
0.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834 | ||||
2.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.368 | ||||
8.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.624 | ||||
1.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.804 | ||||
0.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.624 | ||||
2.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.844 | ||||
6.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834 | ||||
1.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834 | ||||
3.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.851 | ||||
9.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.853 | ||||
2.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.919 | ||||
7.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.932 | ||||
6.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.945 | ||||
2.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.948 | ||||
6.xml"/> | ||||
</references> | ||||
<section numbered="true" toc="default"> | ||||
<name>An Example of the Incremental Tracing Profile</name> | ||||
<t>An example of the Incremental Tracing Profile is depicted in the | ||||
following figure. This configuration is received by an IOAM ingress | following figure. This configuration is received by an IOAM ingress | |||
node. This node encapsulates the IOAM data in IPv6 Hop-by-Hop option | node. This node encapsulates the IOAM data in the IPv6 Hop-by-Hop option | |||
header. The trace type indicates that each on path node need to capture | header. The trace type indicates that each on-path node needs to capture | |||
the transit delay, and add to the IOAM node data list. The incremental | the transit delay and add the data to the IOAM node data list. The increme | |||
tracing data space is variable, however, the node data list must not | ntal | |||
tracing data space is variable; however, the node data list must not | ||||
exceed 512 bytes.</t> | exceed 512 bytes.</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf | ||||
<t><figure> | :params:xml:ns:netconf:base:1.0" message-id="101"> | |||
<artwork><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | ||||
message-id="101"> | ||||
<edit-config> | <edit-config> | |||
<target> | <target> | |||
<candidate/> | <candidate/> | |||
</target> | </target> | |||
<config> | <config> | |||
<ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | |||
<admin-config> | <admin-config> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
</admin-config> | </admin-config> | |||
<profiles> | <profiles> | |||
skipping to change at line 1258 ¶ | skipping to change at line 1566 ¶ | |||
<use-namespace>default-namespace</use-namespace> | <use-namespace>default-namespace</use-namespace> | |||
<trace-type>trace-transit-delay</trace-type> | <trace-type>trace-transit-delay</trace-type> | |||
</trace-types> | </trace-types> | |||
<max-length>512</max-length> | <max-length>512</max-length> | |||
</incremental-tracing-profile> | </incremental-tracing-profile> | |||
</profile> | </profile> | |||
</profiles> | </profiles> | |||
</ioam> | </ioam> | |||
</config> | </config> | |||
</edit-config> | </edit-config> | |||
</rpc>]]></artwork> | </rpc> | |||
</figure></t> | ]]></artwork> | |||
<t/> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="An Example of Pre-allocated Tracing Profile"> | <name>An Example of the Pre-allocated Tracing Profile</name> | |||
<t>An example of pre-allocated tracing profile is depicted in the | <t>An example of the Pre-allocated Tracing Profile is depicted in the | |||
following figure. This configuration is received by an IOAM ingress | following figure. This configuration is received by an IOAM ingress | |||
node. This node firstly identifies the target flow by using ACL | node. This node first identifies the target flow by using the ACL | |||
"test-acl", and then encapsulates the IOAM data in the NSH header. The | parameter "test-acl" and then encapsulates the IOAM data in the NSH. The | |||
trace type indicates that each on path node need to capture the name | trace type indicates that each on-path node needs to capture the | |||
space specific data in the short format, and add to the IOAM node data | namespace-specific data in short format and add the data to the IOAM node | |||
list. This node preallocates the node data list in the packect with 512 | data | |||
list. This node pre-allocates the node data list in the packet with 512 | ||||
bytes.</t> | bytes.</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf | ||||
<t><figure> | :params:xml:ns:netconf:base:1.0" message-id="101"> | |||
<artwork><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | ||||
message-id="101"> | ||||
<edit-config> | <edit-config> | |||
<target> | <target> | |||
<candidate/> | <candidate/> | |||
</target> | </target> | |||
<config> | <config> | |||
<ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | |||
<admin-config> | <admin-config> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
</admin-config> | </admin-config> | |||
<profiles> | <profiles> | |||
skipping to change at line 1306 ¶ | skipping to change at line 1610 ¶ | |||
<use-namespace>default-namespace</use-namespace> | <use-namespace>default-namespace</use-namespace> | |||
<trace-type>trace-namespace-data</trace-type> | <trace-type>trace-namespace-data</trace-type> | |||
</trace-types> | </trace-types> | |||
<max-length>512</max-length> | <max-length>512</max-length> | |||
</preallocated-tracing-profile> | </preallocated-tracing-profile> | |||
</profile> | </profile> | |||
</profiles> | </profiles> | |||
</ioam> | </ioam> | |||
</config> | </config> | |||
</edit-config> | </edit-config> | |||
</rpc>]]></artwork> | </rpc> | |||
</figure></t> | ]]></artwork> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="An Example of Direct Export Profile"> | <name>An Example of the Direct Export Profile</name> | |||
<t>An example of direct export profile is depicted in the following | <t>An example of the Direct Export Profile is depicted in the following | |||
figure. This configuration is received by an IOAM egress node. This node | figure. This configuration is received by an IOAM egress node. This node | |||
detects the IOAM direct export option in the IPv6 extension header, and | detects the IOAM direct export option in the IPv6 extension header and | |||
removes the option to clean all the IOAM data.</t> | removes the option to clean all the IOAM data.</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf | ||||
<t><figure> | :params:xml:ns:netconf:base:1.0" message-id="101"> | |||
<artwork><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | ||||
message-id="101"> | ||||
<edit-config> | <edit-config> | |||
<target> | <target> | |||
<candidate/> | <candidate/> | |||
</target> | </target> | |||
<config> | <config> | |||
<ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | |||
<admin-config> | <admin-config> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
</admin-config> | </admin-config> | |||
<profiles> | <profiles> | |||
skipping to change at line 1339 ¶ | skipping to change at line 1641 ¶ | |||
<profile-name>ietf-test-profile</profile-name> | <profile-name>ietf-test-profile</profile-name> | |||
<protocol-type>ipv6</protocol-type> | <protocol-type>ipv6</protocol-type> | |||
<direct-export-profile> | <direct-export-profile> | |||
<node-action>action-decapsulate</node-action> | <node-action>action-decapsulate</node-action> | |||
</direct-export-profile> | </direct-export-profile> | |||
</profile> | </profile> | |||
</profiles> | </profiles> | |||
</ioam> | </ioam> | |||
</config> | </config> | |||
</edit-config> | </edit-config> | |||
</rpc>]]></artwork> | </rpc> | |||
</figure></t> | ]]></artwork> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="An Example of Proof of Transit Profile"> | <name>An Example of the Proof of Transit Profile</name> | |||
<t>The following figure is a simple example of POT option. This | <t>The following figure is a simple example of the POT option. This | |||
configuration indicates the node to apply POT type 0 with IPv6 | configuration indicates the node to apply POT type 0 with IPv6 | |||
encapsulation.</t> | encapsulation. | |||
<t><figure> | <!-- [rfced] Appendices D and E: Should the option names in these | |||
<artwork><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | sentences be profile names instead? Please compare with the first | |||
message-id="101"> | 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> | <edit-config> | |||
<target> | <target> | |||
<candidate/> | <candidate/> | |||
</target> | </target> | |||
<config> | <config> | |||
<ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | |||
<admin-config> | <admin-config> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
</admin-config> | </admin-config> | |||
<profiles> | <profiles> | |||
skipping to change at line 1371 ¶ | skipping to change at line 1697 ¶ | |||
<profile-name>ietf-test-profile</profile-name> | <profile-name>ietf-test-profile</profile-name> | |||
<protocol-type>ipv6</protocol-type> | <protocol-type>ipv6</protocol-type> | |||
<pot-profile> | <pot-profile> | |||
<pot-type>pot-type-0</pot-type> | <pot-type>pot-type-0</pot-type> | |||
</pot-profile> | </pot-profile> | |||
</profile> | </profile> | |||
</profiles> | </profiles> | |||
</ioam> | </ioam> | |||
</config> | </config> | |||
</edit-config> | </edit-config> | |||
</rpc>]]></artwork> | </rpc> | |||
</figure></t> | ]]></artwork> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="An Example of Edge-to-Edge Profile"> | <name>An Example of the Edge-to-Edge Profile</name> | |||
<t>The following figure shows an example of edge-to-edge option. This | <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 | configuration is received by an IOAM egress node. This node detects the | |||
IOAM edge-to-edge option in the IPv6 extension header, and removes the | IOAM edge-to-edge option in the IPv6 extension header and removes the | |||
option to clean all the IOAM data. As the IOAM egress node, it may | option to clean all the IOAM data. As the IOAM egress node, it may | |||
collect the edge-to-edge data and deliver to the data exporting | collect the edge-to-edge data and deliver it to the data-exporting | |||
process.</t> | process.</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[<rpc xmlns="urn:ietf | ||||
<t><figure> | :params:xml:ns:netconf:base:1.0" message-id="101"> | |||
<artwork><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" | ||||
message-id="101"> | ||||
<edit-config> | <edit-config> | |||
<target> | <target> | |||
<candidate/> | <candidate/> | |||
</target> | </target> | |||
<config> | <config> | |||
<ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | <ioam xmlns="urn:ietf:params:xml:ns:yang:ietf-ioam"> | |||
<admin-config> | <admin-config> | |||
<enabled>true</enabled> | <enabled>true</enabled> | |||
</admin-config> | </admin-config> | |||
<profiles> | <profiles> | |||
skipping to change at line 1406 ¶ | skipping to change at line 1730 ¶ | |||
<profile-name>ietf-test-profile</profile-name> | <profile-name>ietf-test-profile</profile-name> | |||
<protocol-type>ipv6</protocol-type> | <protocol-type>ipv6</protocol-type> | |||
<e2e-profile> | <e2e-profile> | |||
<node-action>action-decapsulate</node-action> | <node-action>action-decapsulate</node-action> | |||
</e2e-profile> | </e2e-profile> | |||
</profile> | </profile> | |||
</profiles> | </profiles> | |||
</ioam> | </ioam> | |||
</config> | </config> | |||
</edit-config> | </edit-config> | |||
</rpc>]]></artwork> | </rpc> | |||
</figure></t> | ]]></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 R | ||||
ahman"/>, <contact fullname="Tom Petch"/>, <contact fullname="Mickey Spiegel"/>, | ||||
<contact fullname="Thomas Graf"/>, <contact fullname="Alex Huang Feng"/>, | ||||
and <contact fullname="Justin Iurman"/>.</t> | ||||
</section> | </section> | |||
</back> | </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> | </rfc> | |||
End of changes. 223 change blocks. | ||||
567 lines changed or deleted | 1021 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |