| rfc9974.original.xml | rfc9974.xml | |||
|---|---|---|---|---|
| <?xml version="1.0" encoding="utf-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
| <!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
| <!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
| <!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
| <!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
| <!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
| ]> | ]> | |||
| <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 | ||||
| " docName="draft-ietf-bier-oam-requirements-21" obsoletes="" updates="" submissi | ||||
| onType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRe | ||||
| fs="true" version="3"> | ||||
| <!-- xml2rfc v2v3 conversion 3.6.0 --> | ||||
| <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
| <front> | ||||
| <title abbrev="OAM Requirements for BIER">Operations, Administration and | ||||
| Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer</ | ||||
| title> | ||||
| <author initials="G." surname="Mirsky" fullname="Greg Mirsky" role="edito | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 | |||
| r"> | " docName="draft-ietf-bier-oam-requirements-21" number="9974" consensus="true" o | |||
| <organization>Ericsson</organization> | bsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" toc | |||
| <address> | Depth="3" symRefs="true" sortRefs="true" version="3"> | |||
| <email>gregimirsky@gmail.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="N." surname="Kumar" fullname="Nagendra Kumar"> | ||||
| <organization>Oracle</organization> | ||||
| <address> | ||||
| <email>nagendrakumar.nainar@gmail.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="M." surname="Chen" fullname="Mach Chen"> | ||||
| <organization>Huawei Technologies</organization> | ||||
| <address> | ||||
| <email>mach.chen@huawei.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <author initials="S" surname="Pallagatti" fullname="Santosh Pallagatti" r | <front> | |||
| ole="editor"> | <title abbrev="OAM Requirements for BIER">Operations, Administration, and Ma | |||
| <organization>VMware</organization> | intenance (OAM) Requirements for the Bit Index Explicit Replication (BIER) Layer | |||
| <address> | </title> | |||
| <email>santosh.pallagatti@gmail.com</email> | <seriesInfo name="RFC" value="9974"/> | |||
| </address> | <author initials="G." surname="Mirsky" fullname="Greg Mirsky" role="editor"> | |||
| </author> | <organization>Ericsson</organization> | |||
| <address> | ||||
| <email>gregimirsky@gmail.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <date year="2025"/> | <author initials="N." surname="Kumar" fullname="Nagendra Kumar"> | |||
| <organization>Oracle</organization> | ||||
| <address> | ||||
| <email>nagendrakumar.nainar@gmail.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <area>Routing</area> | <author initials="M." surname="Chen" fullname="Mach Chen"> | |||
| <organization>Huawei Technologies</organization> | ||||
| <address> | ||||
| <email>mach.chen@huawei.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <workgroup>BIER Working Group</workgroup> | <author initials="S" surname="Pallagatti" fullname="Santosh Pallagatti" role | |||
| ="editor"> | ||||
| <organization>VMware</organization> | ||||
| <address> | ||||
| <email>santosh.pallagatti@gmail.com</email> | ||||
| </address> | ||||
| </author> | ||||
| <keyword>Internet-Draft</keyword> | <date month="May" year="2026"/> | |||
| <keyword>BIER</keyword> | <area>RTG</area> | |||
| <workgroup>bier</workgroup> | ||||
| <keyword>OAM</keyword> | <keyword>BIER</keyword> | |||
| <keyword>OAM</keyword> | ||||
| <abstract> | <abstract> | |||
| <t> | <t> | |||
| This document specifies a list of functional requirements for Operatio ns, Administration, and Maintenance | This document specifies a list of functional requirements for Operatio ns, Administration, and Maintenance | |||
| mechanisms, protocols, and tools that support operations in the Bit In dex Explicit Replication layer of a network. | mechanisms, protocols, and tools that support operations in the Bit In dex Explicit Replication layer of a network. | |||
| </t> | </t> | |||
| </abstract> | </abstract> | |||
| </front> | </front> | |||
| <middle> | <middle> | |||
| <section anchor="intro" title="Introduction"> | <section anchor="intro"> | |||
| <name>Introduction</name> | ||||
| <t> | <t> | |||
| <xref target="RFC8279"/> specifies a Bit Index Explicit Replication (BIER) | <xref target="RFC8279"/> specifies a Bit Index Explicit Replication (BIER) | |||
| architecture and how it supports forwarding of multicast data packets. | architecture and how it supports forwarding of multicast data packets. | |||
| </t> | </t> | |||
| <t> | <t> | |||
| This document lists the Operations, Administration, and Maintenance (OAM) req uirements for the BIER layer | This document lists the Operations, Administration, and Maintenance (OAM) req uirements for the BIER layer | |||
| (Section 4.2 of <xref target="RFC8279"/>) of the multicast domain. | (see <xref target="RFC8279" section="4.2"/>) of the multicast domain. | |||
| The list can further be used for gap analysis of available OAM tools to ident ify | The list can further be used for gap analysis of available OAM tools to ident ify | |||
| possible enhancements of existing or whether new OAM tools are required to | whether possible enhancements of existing or new OAM tools are required to | |||
| support proactive and on-demand path monitoring and service validation. | support proactive and on-demand path monitoring and service validation. | |||
| </t> | </t> | |||
| <section title="Conventions used in this document"> | <section> | |||
| <section anchor="term-sec" title="Terminology"> | <name>Conventions Used in This Document</name> | |||
| <section anchor="term-sec"> | ||||
| <name>Terminology</name> | ||||
| <t>The reader is expected to be familiar with:</t> | <t>The reader is expected to be familiar with:</t> | |||
| <ul spacing="normal"> | <ul spacing="normal"> | |||
| <li><xref target="RFC7799"/>, particularly definitions of Active, Passive, and H ybrid measurement methods and metrics.</li> | <li><xref target="RFC7799"/>, particularly definitions of Active, Passive, and H ybrid measurement methods and metrics.</li> | |||
| <li>The definitions and calculation of performance metrics, e.g., throughput, lo ss, delay, and delay variation metrics, are defined in <xref target="RFC6374"/>. </li> | <li>The definitions and calculation of performance metrics, e.g., throughput, lo ss, delay, and delay variation metrics, are defined in <xref target="RFC6374"/>. </li> | |||
| <li>The definitions, applicability, and examples of the Continuity Check and Con nectivity Verification mechanisms, components of the Fault Management OAM, | <li>The definitions, applicability, and examples of the Continuity Check and Con nectivity Verification mechanisms, components of the Fault Management OAM, | |||
| can be found in <xref target="RFC5860"/>,<xref target="RFC6371"/>, and <xref ta | can be found in <xref target="RFC5860"/>, <xref target="RFC6371"/>, and <xref t | |||
| rget="RFC7276"/>.</li> | arget="RFC7276"/>.</li> | |||
| <li>A multicast domain is a network segment that defines the scope for the multi | <li>A multicast domain is a network segment that defines the scope for multicast | |||
| cast traffic, allowing it to be exchanged only among systems within the domain < | traffic, allowing it to be exchanged only among systems within the domain <xref | |||
| xref target="RFC8279"/>.</li> | target="RFC8279"/>.</li> | |||
| <li>The term "BIER OAM" is used in this document interchangeably with "a set of OAM protocols, methods, and tools for the BIER layer".</li> | <li>The term "BIER OAM" is used in this document interchangeably with "a set of OAM protocols, methods, and tools for the BIER layer".</li> | |||
| <li>Downstream - is the direction from the ingress toward the egress endpoints o f a multicast distribution tree.</li> | <li>Downstream is the direction from the ingress toward the egress endpoints of a multicast distribution tree.</li> | |||
| <li>Egress endpoint is a router to which the packet needs to be sent <xref targe t="RFC8279"/>.</li> | <li>Egress endpoint is a router to which the packet needs to be sent <xref targe t="RFC8279"/>.</li> | |||
| <li>Ingress endpoint is a router that encapsulates a packet in a BIER header <xr ef target="RFC8279"/>.</li> | <li>Ingress endpoint is a router that encapsulates a packet in a BIER header <xr ef target="RFC8279"/>.</li> | |||
| <li> | <li> | |||
| A BIER OAM session is a communication established between Bit-Forwarding Rout ers (BFR) to perform OAM | A BIER OAM session is a communication established between Bit-Forwarding Rout ers (BFR) to perform OAM | |||
| functions like fault detection, performance monitoring, and localization <xre f target="RFC7276"/>. | functions like fault detection, performance monitoring, and localization <xre f target="RFC7276"/>. | |||
| These sessions can be proactive (continuous, persistent configuration) or on- demand (manual, temporary diagnostics). | These sessions can be proactive (continuous, persistent configuration) or on- demand (manual, temporary diagnostics). | |||
| </li> | </li> | |||
| </ul> | </ul> | |||
| </section> | </section> | |||
| <section title="Requirements Language"> | <section> | |||
| <name>Requirements Language</name> | ||||
| <t> | <t> | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", | |||
| NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", | "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14> | |||
| "MAY", and "OPTIONAL" in this document are to be interpreted as | ", | |||
| described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", | |||
| when, and only when, they appear in all capitals, as shown here. | "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
| </t> | "<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 requirements language is used in <xref target="req-list"/> and applie s to implementations | <t>The requirements language is used in <xref target="req-list"/> and applie s to implementations | |||
| of BIER OAM conformant to the listed requirements.</t> | of BIER OAM conformant to the listed requirements.</t> | |||
| </section> | </section> | |||
| <section title="Acronyms"> | <section> | |||
| <t>BFD: Bidirectional Forwarding Detection <xref target="RFC85 | <name>Acronyms</name> | |||
| 62"/></t> | <dl spacing="normal" newline="false"> | |||
| <t>BFR: Bit-Forwarding Router <xref target="RFC8279"/></t> | <dt>BFD:</dt><dd>Bidirectional Forwarding Detection <xref target="R | |||
| <t>BFER: Bit-Forwarding Egress Router <xref target="RFC8279"/></t | FC8562"/></dd> | |||
| > | <dt>BFR:</dt><dd>Bit-Forwarding Router <xref target="RFC8279"/></dd | |||
| <t>BIER: Bit Index Explicit Replication <xref target="RFC8279"/> | > | |||
| </t> | <dt>BFER:</dt><dd>Bit-Forwarding Egress Router <xref target="RFC827 | |||
| <t>OAM: Operations, Administration, and Maintenance <xref targe | 9"/></dd> | |||
| t="RFC6291"/></t> | <dt>BIER:</dt><dd>Bit Index Explicit Replication <xref target="RFC8 | |||
| <t>PMTUD: Path Maximum Transmission Unit Discovery <xref target="RF | 279"/></dd> | |||
| C1191"/></t> | <dt>OAM:</dt><dd>Operations, Administration, and Maintenance <xref | |||
| <t>p2mp: Point-to-Multipoint <xref target="RFC8562"/></t> | target="RFC6291"/></dd> | |||
| <t>RDI: Remote Defect Indication <xref target="RFC6428"/></t> | <dt>PMTUD:</dt><dd>Path Maximum Transmission Unit Discovery <xref t | |||
| <t>STAMP: Simple Two-way Active Measurement Protocol <xref target= | arget="RFC1191"/></dd> | |||
| "RFC8762"/></t> | <dt>P2MP:</dt><dd>Point-to-Multipoint <xref target="RFC8562"/></dd> | |||
| <dt>RDI:</dt><dd>Remote Defect Indication <xref target="RFC6428"/>< | ||||
| /dd> | ||||
| <dt>STAMP:</dt><dd>Simple Two-way Active Measurement Protocol <xref | ||||
| target="RFC8762"/></dd> | ||||
| </dl> | ||||
| </section> | </section> | |||
| </section> | </section> | |||
| </section> | </section> | |||
| <section anchor="req-list" title="Requirements"> | <section anchor="req-list"> | |||
| <name>Requirements</name> | ||||
| <t> | <t> | |||
| This section lists the requirements for OAM of the BIER layer: | This section lists the requirements for OAM of the BIER layer: | |||
| </t> | </t> | |||
| <ol type="1"> | <ol type="1"> | |||
| <li> | <li>The listed requirements <bcp14>MUST</bcp14> be supported with any | |||
| The listed requirements MUST be supported with any routing underlay <xref targ | routing underlay <xref target="RFC8279"/> over which the BIER layer can be | |||
| et="RFC8279"/> over which the BIER layer can be realized. | realized.</li> | |||
| </li> | <li>It <bcp14>MUST</bcp14> be possible to initialize a BIER OAM session | |||
| <li> | from any BFR of the given BIER domain.</li> | |||
| It MUST be possible to initialize a BIER OAM session from any BFR of the given | <li>It <bcp14>MUST</bcp14> be possible to initialize a BIER OAM session from | |||
| BIER domain. | a controller.</li> | |||
| </li> | <li>BIER OAM <bcp14>MUST</bcp14> support proactive OAM monitoring and measur | |||
| <li> | ement methods.</li> | |||
| It MUST be possible to initialize a BIER OAM session from a controller. | <li>BIER OAM <bcp14>MUST</bcp14> support on-demand OAM monitoring and measur | |||
| </li> | ement methods.</li> | |||
| <li> | <li>BIER OAM <bcp14>MUST</bcp14> support active performance measurement meth | |||
| BIER OAM MUST support proactive OAM monitoring and measurement methods. | ods <xref target="RFC7799"/>.</li> | |||
| </li> | <li>BIER OAM <bcp14>MUST</bcp14> support passive performance measurement met | |||
| hods <xref target="RFC7799"/>.</li> | ||||
| <li> | <li> | |||
| BIER OAM MUST support on-demand OAM monitoring and measurement methods. | <t>BIER OAM <bcp14>MUST</bcp14> support the ability of any BFR in the | |||
| </li> | given BIER domain to proactively monitor Bit-Forwarding Egress Router (BFE | |||
| <li> | R) | |||
| BIER OAM MUST support active performance measurement methods <xref target="RFC | availability.</t> | |||
| 7799"/>. | ||||
| </li> | <t>This requirement provides helpful clarification to the combination of | |||
| <li> | Requirements 2 and 4. The P2MP BFD with active tail support <xref | |||
| BIER OAM MUST support passive performance measurement methods <xref target="RF | target="RFC9780"/> is an example of a protocol that provides | |||
| C7799"/>. | notifications about the loss of connectivity in a multicast distribution | |||
| </li> | tree.</t> | |||
| <li> | </li> | |||
| BIER OAM MUST support the ability of any BFR in the given BIER | ||||
| domain to monitor Bit-Forwarding Egress Router (BFER) availability proactively. | ||||
| </li> | ||||
| </ol> | ||||
| <t> | ||||
| This requirement provides helpful clarification to the combination of Requiremen | ||||
| ts 2 and 4. The p2mp BFD with active tail support <xref target="RFC9780"/> | ||||
| is an example of a protocol that provides notifications about the loss of connec | ||||
| tivity in a multicast distribution tree. | ||||
| </t> | ||||
| <ol start="9" type="1"> | ||||
| <li> | ||||
| BIER OAM MUST support downstream path continuity check. | ||||
| </li> | ||||
| </ol> | ||||
| <t> | ||||
| Bidirectional Forwarding Detection (BFD) <xref target="RFC8562"/> is an exampl | ||||
| e | ||||
| of a protocol that monitors the continuity of a multicast distribution tree. | ||||
| </t> | ||||
| <ol type="1" start="10"> | ||||
| <li> | <li> | |||
| BIER OAM MUST support downstream performance measurement. | <t>BIER OAM <bcp14>MUST</bcp14> support downstream path continuity checkin | |||
| </li> | g.</t> | |||
| </ol> | <t>Bidirectional Forwarding Detection (BFD) <xref target="RFC8562"/> is | |||
| <t> | an example of a protocol that monitors the continuity of a multicast | |||
| Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> | distribution tree.</t> | |||
| is an example | ||||
| of a protocol that supports measurement of performance metrics, e.g., packet l | ||||
| oss ratio, delay, and delay variation. | ||||
| </t> | ||||
| <ol start="11" type="1"> | ||||
| <li> | ||||
| In the downstream direction, a BIER OAM solution MUST support | ||||
| transmission of OAM packets to traverse the same set of nodes and links and | ||||
| receive | ||||
| the same forwarding treatment (including QoS) as the monitored BIER flow. | ||||
| </li> | </li> | |||
| </ol> | ||||
| <t> | ||||
| In some cases, e.g., when monitoring a composite data flow that includes several | ||||
| sub-flows | ||||
| characterized by different CoS marking, an operator may choose to monitor the co | ||||
| ntinuity | ||||
| of the path at the highest CoS, not at every CoS value in the data flow. In that | ||||
| case, BIER OAM packets traverse | ||||
| the same set of nodes and links as the composite data flow while receiving the s | ||||
| ame forwarding treatment | ||||
| as the highest CoS sub-flow. In this scenario, the state of path continuity for | ||||
| lower CoS sub-flows can be derived from the state of the highest CoS, | ||||
| as determined by the BIER OAM protocol performing continuity verification (e.g., | ||||
| BFD). | ||||
| </t> | ||||
| <ol start="12" type="1"> | ||||
| <li> | <li> | |||
| BIER OAM MUST support bidirectional OAM methods. In the downstream direction, th | <t>BIER OAM <bcp14>MUST</bcp14> support downstream performance measurement | |||
| ese methods | .</t> | |||
| of monitoring or measurement MUST conform to Requirement 11. | <t>Simple Two-way Active Measurement Protocol (STAMP) <xref | |||
| In the reverse direction (i.e., from the egress toward the ingress | target="RFC8762"/> is an example of a protocol that supports measurement | |||
| endpoint of the BIER OAM test session), BIER OAM packets MAY deviate from tr | of performance metrics, e.g., packet loss ratio, delay, and delay | |||
| aversing the same set of nodes and links, or | variation.</t> | |||
| receive a different forwarding treatment (including QoS) as the monitored BI | </li> | |||
| ER flow. | <li> | |||
| </li> | <t>In the downstream direction, a BIER OAM solution <bcp14>MUST</bcp14> | |||
| </ol> | support transmission of OAM packets to traverse the same set of nodes | |||
| <t>Point-to-Multipoint (p2mp) BFD with active tail <xref target="RFC9780"/>) i | and links and receive the same forwarding treatment (including QoS) as | |||
| s an example of the bidirectional mechanism of continuity checking. | the monitored BIER flow.</t> | |||
| </t> | <!-- [rfced] Note that we have expanded CoS as "Class-of-Service" upon first use | |||
| . Please let us know if this is incorrect. | ||||
| <ol start="13" type="1"> | Original: | |||
| <li> | In some cases, e.g., when monitoring a composite data flow that | |||
| BIER OAM MUST support Path Maximum Transmission Unit discovery (PMTUD). | includes several sub-flows characterized by different CoS marking, an | |||
| </li> | operator may choose to monitor the continuity of the path at the | |||
| </ol> | highest CoS, not at every CoS value in the data flow. | |||
| <t> | --> | |||
| The PMTUD using ICMP <xref target="RFC1191"/> is an example of the mechanism. | ||||
| </t> | <t>In some cases, e.g., when monitoring a composite data flow that | |||
| <ol start="14" type="1"> | includes several sub-flows characterized by different Class-of-Service (Co | |||
| <li> | S) marking, an | |||
| BIER OAM MUST support an RDI mechanism to notify the BFR, the source of the cont | operator may choose to monitor the continuity of the path at the highest | |||
| inuity checking by BFERs. | CoS, not at every CoS value in the data flow. In that case, BIER OAM | |||
| </li> | packets traverse the same set of nodes and links as the composite data | |||
| </ol> | flow while receiving the same forwarding treatment as the highest CoS | |||
| <t> | sub-flow. In this scenario, the state of path continuity for lower CoS | |||
| The Diagnostic field in p2mp BFD with active tail support, as described in Secti | sub-flows can be derived from the state of the highest CoS, as | |||
| on 5 | determined by the BIER OAM protocol performing continuity verification | |||
| of <xref target="RFC9780"/>, is an example of the RDI mechanism. | (e.g., BFD).</t> | |||
| </t> | </li> | |||
| <ol start="15" type="1"> | <li> | |||
| <li> | <t>BIER OAM <bcp14>MUST</bcp14> support bidirectional OAM methods. In | |||
| BIER OAM MUST support downstream performance measurement method(s) that (togethe | the downstream direction, these methods of monitoring or measurement | |||
| r) calculate performance metrics, e.g., throughput, loss, delay, | <bcp14>MUST</bcp14> conform to Requirement 11. In the reverse direction | |||
| and delay variation metrics <xref target="RFC6374"/>. | (i.e., from the egress toward the ingress endpoint of the BIER OAM test | |||
| </li> | session), BIER OAM packets <bcp14>MAY</bcp14> deviate from traversing | |||
| </ol> | the same set of nodes and links, or receive a different forwarding | |||
| <t> | treatment (including QoS) as the monitored BIER flow.</t> | |||
| STAMP (<xref target="RFC8762"/> and <xref target="RFC8972"/>) | <t>Point-to-Multipoint (P2MP) BFD with active tail <xref | |||
| is an example of an active performance | target="RFC9780"/> is an example of the bidirectional mechanism of | |||
| measurement method of performance metrics that may be applied in a BIER domain. | continuity checking.</t> | |||
| The Alternate Marking Method, | </li> | |||
| described in <xref target="RFC9341"/> and <xref target="RFC9342"/>, | <li> | |||
| is an example of a hybrid measurement method (<xref target="RFC7799"/>) that may | <t>BIER OAM <bcp14>MUST</bcp14> support Path Maximum Transmission Unit | |||
| be applied in a BIER domain. | Discovery (PMTUD).</t> | |||
| </t> | <t>The PMTUD using ICMP <xref target="RFC1191"/> is an example of the | |||
| <ol start="16" type="1"> | mechanism.</t> | |||
| <li> | </li> | |||
| BIER OAM MUST support defect notification mechanism(s). | <li> | |||
| </li> | <t>BIER OAM <bcp14>MUST</bcp14> support an RDI mechanism to notify the | |||
| </ol> | BFR, the source of the continuity checking by BFERs.</t> | |||
| <t>Alarm Indication Signal <xref target="RFC6427"/> is an example of the defect | <t>The Diagnostic field in P2MP BFD with active tail support, as | |||
| notification mechanism.</t> | described in <xref section="5" target="RFC9780"/>, is an example of the | |||
| <ol start="17" type="1"> | RDI mechanism.</t> | |||
| <li> | </li> | |||
| BIER OAM MUST support a way for any BFR in the given BIER domain | <li> | |||
| to originate a fault management message addressed to any subset of BFRs within t | <t>BIER OAM <bcp14>MUST</bcp14> support downstream performance | |||
| he domain. | measurement method(s) that (together) calculate performance metrics, | |||
| </li> | e.g., throughput, loss, delay, and delay variation metrics <xref | |||
| </ol> | target="RFC6374"/>.</t> | |||
| <t><xref target="RFC6427"/> provides an example of a Fault Management messaging | ||||
| mechanism.</t> | <t>STAMP (<xref target="RFC8762"/> and <xref target="RFC8972"/>) is an | |||
| <ol start="18" type="1"> | example of an active performance measurement method of performance | |||
| <li> | metrics that may be applied in a BIER domain. The Alternate-Marking | |||
| BIER OAM MUST support methods to enable the survivability of a BIER layer. | Method, described in <xref target="RFC9341"/> and <xref | |||
| </li> | target="RFC9342"/>, is an example of a hybrid measurement method <xref | |||
| target="RFC7799"/> that may be applied in a BIER domain.</t> | ||||
| </li> | ||||
| <li> | ||||
| <t>BIER OAM <bcp14>MUST</bcp14> support defect notification | ||||
| mechanism(s).</t> | ||||
| <t>Alarm Indication Signal <xref target="RFC6427"/> is an example of the | ||||
| defect notification mechanism.</t> | ||||
| </li> | ||||
| <li> | ||||
| <t>BIER OAM <bcp14>MUST</bcp14> support a way for any BFR in the given | ||||
| BIER domain to originate a fault management message addressed to any | ||||
| subset of BFRs within the domain.</t> | ||||
| <t><xref target="RFC6427"/> provides an example of a Fault Management | ||||
| messaging mechanism.</t> | ||||
| </li> | ||||
| <li> | ||||
| <t>BIER OAM <bcp14>MUST</bcp14> support methods to enable the | ||||
| survivability of a BIER layer.</t> | ||||
| <t>Protection switching and restoration are examples of survivability | ||||
| methods.</t> | ||||
| </li> | ||||
| </ol> | </ol> | |||
| <t>Protection switching and restoration are examples of survivability methods. </t> | ||||
| </section> | </section> | |||
| <section anchor="iana-considerations" title="IANA Considerations"> | <section anchor="iana-considerations"> | |||
| <name>IANA Considerations</name> | ||||
| <t> | <t> | |||
| This document does not propose any IANA consideration. This section may be rem oved. | This document has no IANA actions. | |||
| </t> | </t> | |||
| </section> | </section> | |||
| <section anchor="security-considerations" title="Security Considerations"> | <section anchor="security-considerations"> | |||
| <name>Security Considerations</name> | ||||
| <t> | <t> | |||
| This document lists the OAM requirements for a BIER-enabled domain and | This document lists the OAM requirements for a BIER-enabled domain and | |||
| thus inherits the security considerations discussed in <xref target="RFC8279"/ | it thus inherits the security considerations discussed in <xref target="RFC827 | |||
| > and <xref target="RFC8296"/>. | 9"/> and <xref target="RFC8296"/>. | |||
| Another general security aspect results from using active OAM protocols (<xref | Another general security aspect results from using active OAM protocols <xref | |||
| target="RFC7799"/>) in a multicast network. | target="RFC7799"/> in a multicast network. | |||
| </t> | </t> | |||
| <!-- [rfced] What does the "echo request/reply principle" refer to? Please cons | ||||
| ider whether a reference should be added for the reader. | ||||
| Original: | ||||
| Some | ||||
| active OAM protocols are based on the echo request/reply principle of | ||||
| using those test packets. | ||||
| --> | ||||
| <t> | <t> | |||
| Active OAM protocols inject specially constructed test packets. | Active OAM protocols inject specially constructed test packets. | |||
| Some active OAM protocols are based on the echo request/reply principle of usi ng those test packets. | Some active OAM protocols are based on the echo request/reply principle of usi ng those test packets. | |||
| In the multicast network, test packets are replicated as data packets, | In the multicast network, test packets are replicated as data packets, | |||
| thus creating a possible amplification effect of multiple echo replies being | thus creating a possible amplification effect of multiple echo replies being | |||
| transmitted to the sender of the echo request. Thus, following security-related requirements for BIER OAM: | transmitted to the sender of the echo request. Therefore, the following security -related requirements are defined for BIER OAM: | |||
| </t> | </t> | |||
| <ul spacing="normal"> | <ul spacing="normal"> | |||
| <li>A BIER OAM solution MUST protect the control plane by controlling the rate o | <li>A BIER OAM solution <bcp14>MUST</bcp14> protect the control plane by control | |||
| f echo request transmission.</li> | ling the rate of echo request transmission.</li> | |||
| <li>A BIER OAM solution MUST provide control of the number of BIER OAM messages | <li>A BIER OAM solution <bcp14>MUST</bcp14> provide control of the number of BIE | |||
| sent to the control plane.</li> | R OAM messages sent to the control plane.</li> | |||
| </ul> | </ul> | |||
| </section> | </section> | |||
| <section anchor="Acknowledgements" numbered="true" toc="default"> | ||||
| <name>Acknowledgements</name> | ||||
| <t>The authors would like to thank the comments and suggestions | ||||
| from Gunter van de Velde that helped improve this document.</t> | ||||
| </section> | ||||
| </middle> | </middle> | |||
| <back> | <back> | |||
| <references title="Normative References"> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.2119.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.8174.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.7799.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.6374.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.8279.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
| FC.8296.xml"/> | ||||
| <references> | ||||
| <name>References</name> | ||||
| <references> | ||||
| <name>Normative References</name> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119 | ||||
| .xml"/> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174 | ||||
| .xml"/> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799 | ||||
| .xml"/> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374 | ||||
| .xml"/> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279 | ||||
| .xml"/> | ||||
| <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296 | ||||
| .xml"/> | ||||
| </references> | </references> | |||
| <references title="Informative References"> | <references> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <name>Informative References</name> | |||
| FC.8762.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.876 | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | 2.xml"/> | |||
| FC.8972.xml"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.897 | |||
| 2.xml"/> | ||||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.934 | |||
| FC.9341.xml"/> | 1.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.934 | |||
| C.9342.xml"/> | 2.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.629 | |||
| C.6291.xml"/> | 1.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.727 | |||
| C.7276.xml"/> | 6.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.856 | |||
| C.8562.xml"/> | 2.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.978 | |||
| C.9780.xml"/> | 0.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.119 | |||
| C.1191.xml"/> | 1.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.642 | |||
| C.6428.xml"/> | 8.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.586 | |||
| C.5860.xml"/> | 0.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.637 | |||
| C.6371.xml"/> | 1.xml"/> | |||
| <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.642 | |||
| C.6427.xml"/> | 7.xml"/> | |||
| </references> | ||||
| </references> | </references> | |||
| <section anchor="contr-sec" numbered="false" toc="default"> | <section anchor="Acknowledgements" numbered="false" toc="default"> | |||
| <name>Contributors' Addresses</name> | <name>Acknowledgements</name> | |||
| <author initials="E." surname="Nordmark" fullname="Erik Nordmark" | <t>The authors would like to thank <contact fullname="Gunter van de Velde" | |||
| > | /> for the comments and suggestions that helped improve this | |||
| <organization/> | document.</t> | |||
| <address> | </section> | |||
| <email>nordmark@acm.org</email> | ||||
| </address> | <section anchor="contr-sec" numbered="false" toc="default"> | |||
| <name>Contributors</name> | ||||
| <author initials="E." surname="Nordmark" fullname="Erik Nordmark"> | ||||
| <organization/> | ||||
| <address> | ||||
| <email>nordmark@acm.org</email> | ||||
| </address> | ||||
| </author> | </author> | |||
| <author initials="S." surname="Aldrin" fullname="Sam Aldrin"> | <author initials="S." surname="Aldrin" fullname="Sam Aldrin"> | |||
| <organization>Google</organization> | <organization>Google</organization> | |||
| <address> | <address> | |||
| <email>aldrin.ietf@gmail.com</email> | <email>aldrin.ietf@gmail.com</email> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| <author initials="L." surname="Zheng" fullname="Lianshu Zheng"> | <author initials="L." surname="Zheng" fullname="Lianshu Zheng"> | |||
| <organization/> | <organization/> | |||
| <address> | <address> | |||
| <email>veronique_cheng@hotmail.com</email> | <email>veronique_cheng@hotmail.com</email> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| <author initials="N." surname="Akiya" fullname="Nobo Akiya"> | <author initials="N." surname="Akiya" fullname="Nobo Akiya"> | |||
| <organization/> | <organization/> | |||
| <address> | <address> | |||
| <email>nobo.akiya.dev@gmail.com</email> | <email>nobo.akiya.dev@gmail.com</email> | |||
| </address> | </address> | |||
| </author> | </author> | |||
| </section> | </section> | |||
| <!-- [rfced] Please review the "Inclusive Language" portion of the online | ||||
| Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | ||||
| and let us know if any changes are needed. Updates of this nature typically | ||||
| result in more precise language, which is helpful for readers. | ||||
| Note that our script did not flag any words in particular, but this should | ||||
| still be reviewed as a best practice. | ||||
| --> | ||||
| </back> | </back> | |||
| </rfc> | </rfc> | |||
| End of changes. 45 change blocks. | ||||
| 316 lines changed or deleted | 324 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||