rfc9714xml2.original.xml   rfc9714.xml 
<?xml version="1.0" encoding="iso-8859-1" ?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-mpls-inband-pm-encapsu <!DOCTYPE rfc [
lation-18" consensus="true" submissionType="IETF"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<title abbrev="Encap for MPLS PM with AMM"> Encapsulation For MPLS Performance docName="draft-ietf-mpls-inband-pm-encapsulation-18" number="9714" consensus="t
Measurement with Alternate-Marking Method </title> rue" submissionType="IETF" tocInclude="true" updates="" obsoletes="" symRefs="tr
ue" sortRefs="true" version="3" xml:lang="en">
<author fullname="Weiqiang Cheng" initials="W" surname="Cheng" role="editor"> <front>
<title abbrev="Encap for MPLS PM with AMM">Encapsulation for MPLS Performanc
e Measurement with the Alternate-Marking Method</title>
<seriesInfo name="RFC" value="9714"/>
<author fullname="Weiqiang Cheng" initials="W" surname="Cheng" role="editor"
>
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Beijing</city>
<country>China</country>
<!-- Reorder these if your country does things differently --> </postal>
<email>chengweiqiang@chinamobile.com</email>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>chengweiqiang@chinamobile.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Xiao Min" initials="X" surname="Min" role="editor">
<author fullname="Xiao Min" initials="X" surname="Min" role="editor">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Nanjing</city>
<country>China</country>
<!-- Reorder these if your country does things differently --> </postal>
<email>xiao.min2@zte.com.cn</email>
<city>Nanjing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>xiao.min2@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Tianran Zhou" initials="T" surname="Zhou">
<author fullname="Tianran Zhou" initials="T" surname="Zhou">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city> <city>Beijing</city>
<country>China</country>
<region></region> </postal>
<phone/>
<code></code> <email>zhoutianran@huawei.com</email>
<country>China</country>
</postal>
<phone></phone>
<email>zhoutianran@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Jinyou Dai" initials="J" surname="Dai">
<author fullname="Jinyou Dai" initials="J" surname="Dai">
<organization>FiberHome</organization> <organization>FiberHome</organization>
<address> <address>
<postal> <postal>
<street></street> <city>Wuhan</city>
<country>China</country>
<!-- Reorder these if your country does things differently --> </postal>
<email>djy@fiberhome.com</email>
<city>Wuhan</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>djy@fiberhome.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Yoav Peleg" initials="Y" surname="Peleg">
<author fullname="Yoav Peleg" initials="Y" surname="Peleg">
<organization>Broadcom</organization> <organization>Broadcom</organization>
<address> <address>
<postal> <postal>
<street></street> <country>United States of America</country>
</postal>
<!-- Reorder these if your country does things differently --> <email>yoav.peleg@broadcom.com</email>
<city></city>
<region></region>
<code></code>
<country>United States of America</country>
</postal>
<phone></phone>
<email>yoav.peleg@broadcom.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2025" month="February"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<date year="2024"/> <keyword>Flow-ID Label Indicator</keyword>
<keyword>Flow-ID Label</keyword>
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>Request for Comments</keyword>
<keyword>RFC</keyword>
<keyword>Internet Draft</keyword>
<keyword>I-D</keyword>
<abstract> <abstract>
<t>This document defines the encapsulation for MPLS performance measurement w <t>This document defines the encapsulation for MPLS performance measuremen
ith the Alternate-Marking method, which performs t with the Alternate-Marking Method, which performs
flow-based packet loss, delay, and jitter measurements on the MPLS traffic.</ flow-based packet loss, delay, and jitter measurements on MPLS traffic.</t>
t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction">
<middle> <name>Introduction</name>
<t> <xref target="RFC9341"/> describes a performance measurement method, w
<section title="Introduction"> hich can be used to measure packet loss, delay, and jitter
<t> <xref target="RFC9341"/> describes a performance measurement method, whic
h can be used to measure packet loss, delay, and jitter
on data traffic. Since this method is based on marking consecutive batches of packets, it is referred to as the Alternate-Marking on data traffic. Since this method is based on marking consecutive batches of packets, it is referred to as the Alternate-Marking
Method. <xref target="RFC8372"/> outlines key considerations for developing a solution for MPLS flow identification, intended for Method. <xref target="RFC8372"/> outlines key considerations for developing a solution for MPLS flow identification, intended for
use in performance monitoring of MPLS flows.</t> use in performance monitoring of MPLS flows.</t>
<t> This document defines the encapsulation for MPLS performance measureme
<t> This document defines the encapsulation for MPLS performance measurement nt with the Alternate-Marking Method, which performs
with the Alternate-Marking method, which performs
flow-based packet loss, delay, and jitter measurements on the MPLS traffic. T he encapsulation defined in this document supports flow-based packet loss, delay, and jitter measurements on the MPLS traffic. T he encapsulation defined in this document supports
performance monitoring at the intermediate nodes and MPLS flow identification at both transport and service layers.</t> performance monitoring at the intermediate nodes and MPLS flow identification at both transport and service layers.</t>
<t>
<t> Note that in parallel to the work of this document, there is ongoing work Note that in parallel to the work of this document, there is ongoing work,
on MPLS Network Actions (MNA) <xref target="RFC9613"/>. e.g., <xref target="I-D.cx-mpls-mna-inband-pm"/>, regarding MPLS Network
The MPLS performance measurement with the Alternate-Marking method can also b Actions (MNAs) <xref target="RFC9613"/>. The MPLS performance measurement
e achieved by MNA encapsulation. In addition, MNA will with the Alternate-Marking Method can also be achieved by MNA
provide a broader use case applicability. That means the MNA encapsulation is encapsulation. In addition, MNA will provide a broader use-case
expected to provide a more advanced solution, when applicability. That means the MNA encapsulation is expected to provide a
published as an RFC and it is agreed that this document will be made Historic more advanced solution. If <xref target="I-D.cx-mpls-mna-inband-pm"/> is
at that time.</t> published as an RFC, the status of this RFC will be reviewed and possibly
changed to Historic.
</section> </t>
<section title="Conventions Used in This Document">
<section title="Abbreviations">
<t> ACL: Access Control List</t>
<t> BoS: Bottom of Stack</t>
<t> cSPL: Composite Special Purpose Label, the combination of the Extension
Label (value 15) and an Extended Special Purpose Label</t>
<t> DSCP: Differentiated Services Code Point</t>
<t> ECMP: Equal-Cost Multipath</t>
<t> ELC: Entropy Label Capability</t>
<t> ERLD: Entropy Readable Label Depth</t>
<t> eSPL: Extended Special Purpose Label, a special-purpose label that is pl
aced in the label stack after the Extension Label (value 15)</t>
<t> FL: Flow-ID Label</t>
<t> FLC: Flow-ID Label Capability</t>
<t> FLI: Flow-ID Label Indicator</t>
<t> FRLD: Flow-ID Readable Label Depth</t>
<t> IPFIX: IP Flow Information Export <xref target="RFC7011"/></t>
<t> LSP: Label Switched Path</t>
<t> LSR: Label Switching Router</t>
<t> MPLS: Multi-Protocol Label Switching</t>
<t> NMS: Network Management System</t>
<t> PHP: Penultimate Hop Popping</t>
<t> PM: Performance Measurement</t>
<t> PW: PseudoWire</t>
<t> SFL: Synonymous Flow Label</t>
<t> SID: Segment ID</t>
<t> SR: Segment Routing</t>
<t> TC: Traffic Class</t>
<t> TTL: Time to Live</t>
<t> VC: Virtual Channel</t>
<t> VPN: Virtual Private Network</t>
<t> XL: Extension Label</t>
</section> </section>
<section anchor="conventions">
<section title="Requirements Language"> <name>Conventions Used in This Document</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <section anchor="abbrevs">
"SHOULD", "SHOULD NOT", <name>Abbreviations</name>
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this documen <dl spacing="normal" newline="false">
t are to be interpreted <dt>ACL:</dt><dd>Access Control List</dd>
as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> <dt>BoS:</dt><dd>Bottom of Stack</dd>
when, and only when, they <dt>cSPL:</dt><dd>Composite Special Purpose Label, the combination of
appear in all capitals, as shown here.</t> the Extension Label (value 15) and an Extended Special Purpose Label</dd>
<dt>DSCP:</dt><dd>Differentiated Services Code Point</dd>
<dt>ELC:</dt><dd>Entropy Label Capability</dd>
<dt>ERLD:</dt><dd>Entropy Readable Label Depth</dd>
<dt>eSPL:</dt><dd>Extended Special Purpose Label, a special-purpose la
bel that is placed in the label stack after the Extension Label (value 15)</dd>
<dt>FL:</dt><dd>Flow-ID Label</dd>
<dt>FLC:</dt><dd>Flow-ID Label Capability</dd>
<dt>FLI:</dt><dd>Flow-ID Label Indicator</dd>
<dt>FRLD:</dt><dd>Flow-ID Readable Label Depth</dd>
<dt>IPFIX:</dt><dd>IP Flow Information Export <xref target="RFC7011"/>
</dd>
<dt>LSP:</dt><dd>Label Switched Path</dd>
<dt>LSR:</dt><dd>Label Switching Router</dd>
<dt>MPLS:</dt><dd>Multi-Protocol Label Switching</dd>
<dt>NMS:</dt><dd>Network Management System</dd>
<dt>PHP:</dt><dd>Penultimate Hop Popping</dd>
<dt>PM:</dt><dd>Performance Measurement</dd>
<dt>PW:</dt><dd>Pseudowire</dd>
<dt>SFL:</dt><dd>Synonymous Flow Label</dd>
<dt>SID:</dt><dd>Segment ID</dd>
<dt>SR:</dt><dd>Segment Routing</dd>
<dt>TC:</dt><dd>Traffic Class</dd>
<dt>TTL:</dt><dd>Time to Live</dd>
<dt>VC:</dt><dd>Virtual Channel</dd>
<dt>VPN:</dt><dd>Virtual Private Network</dd>
<dt>XL:</dt><dd>Extension Label</dd>
</dl>
</section>
<section anchor="requirements">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section anchor="flow-based-pm-encapsulation">
</section> <name>Flow-Based PM Encapsulation in MPLS</name>
<t> This document defines the Flow-based MPLS performance measurement enca
<section title="Flow-based PM Encapsulation in MPLS"> psulation with the Alternate-Marking Method, as shown
in <xref target="Figure_1"/>.</t>
<t> This document defines the Flow-based MPLS performance measurement enc <figure anchor="Figure_1">
apsulation with alternate marking method, as shown <name>Flow-based PM Encapsulation in MPLS</name>
in figure 1.</t> <artwork align="left"><![CDATA[
<figure anchor="Figure_1" title="Flow-based PM Encapsulation in MPLS">
<artwork align="left"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Label (15) | TC |S| TTL | | Extension Label (15) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID Label Indicator (TBA1) | TC |S| TTL | | Flow-ID Label Indicator (18) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow-ID Label |L|D|T|S| TTL | | Flow-ID Label |L|D|T|S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
The Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label (e SPL), which is combined with the Extension The Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label (e SPL), which is combined with the Extension
Label (XL, value 15) to form a Composite Special Purpose Label (cSPL), as defined in <xref target="RFC9017"/>. The Label (XL, value 15) to form a Composite Special Purpose Label (cSPL), as defined in <xref target="RFC9017"/>. The
FLI is defined in this document as value TBA1. FLI is defined in this document as value 18.
</t> </t>
<t> <t>
The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI MU The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI <b
ST use the same values of the label immediately cp14>MUST</bcp14> use the same values of the label immediately
preceding the XL. The Bottom of the Stack (BoS) bit <xref target="RFC3032 preceding the XL. The Bottom of the Stack (BoS) bit <xref target="RFC3032
"/> for the XL and FLI MUST be zero. If any XL or FLI "/> for the XL and FLI <bcp14>MUST</bcp14> be zero. If any XL or FLI
processed by a node has the BoS bit set, the node MUST discard the packet processed by a node has the BoS bit set, the node <bcp14>MUST</bcp14> dis
and MAY log an error. card the packet and <bcp14>MAY</bcp14> log an error.
</t> </t>
<t> <t>
The Flow-ID Label (FL) is used as an MPLS flow identification <xref targe The Flow-ID Label (FL) is used as an MPLS flow identification <xref targe
t="RFC8372"/>. Its value MUST be unique within the t="RFC8372"/>. Its value <bcp14>MUST</bcp14> be unique within the
administrative domain. The Flow-ID Label values MAY be allocated by an ex administrative domain. The FL values <bcp14>MAY</bcp14> be allocated by a
ternal NMS or controller based on the measurement n external NMS or controller based on the measurement
object instances (such as LSP or PW). There is a one-to-one mapping betwe en a Flow-ID and a flow. The specific method object instances (such as LSP or PW). There is a one-to-one mapping betwe en a Flow-ID and a flow. The specific method
on how to allocate the Flow-ID Label values is described in Section 5. on how to allocate the FL values is described in <xref target="procedures
</t> -of-flow-id-alloc"/>.
<t> </t>
<t>
The FL, preceded by a cSPL, can be placed either at the bottom or in the middle, but not at the top, of the MPLS label stack, The FL, preceded by a cSPL, can be placed either at the bottom or in the middle, but not at the top, of the MPLS label stack,
and it MAY appear multiple times within a label stack. Section 3.1 of thi and it <bcp14>MAY</bcp14> appear multiple times within a label stack. <xr
s document provides several examples to illustrate the ef target="examples-for-flow-id"/> of this document provides several examples to
application of FL in a label stack. The TTL for the FL MUST be zero to en illustrate the
sure that it is not used inadvertently for forwarding. application of FL in a label stack. The TTL for the FL <bcp14>MUST</bcp14
> be zero to ensure that it is not used inadvertently for forwarding.
The BoS bit for the FL depends on whether the FL is placed at the bot tom of the MPLS label stack, i.e., the BoS bit for the FL The BoS bit for the FL depends on whether the FL is placed at the bot tom of the MPLS label stack, i.e., the BoS bit for the FL
is set only when the FL is placed at the bottom of the MPLS label stack. is set only when the FL is placed at the bottom of the MPLS label stack.
</t> </t>
<t>
Besides the flow identification, a color-marking field is also necessary <t>
for the Alternate-Marking method. To achieve Besides the flow identification, a color-marking field is also necessary
the purpose of coloring the MPLS traffic, and to distinguish between hop- for the Alternate-Marking Method. To color the MPLS traffic and to distinguish b
by-hop measurement and edge-to-edge measurement, the etween hop-by-hop measurement and edge-to-edge measurement, the
TC for the FL is defined as follows: TC for the FL is defined as follows:
<list style="symbols"> </t>
<t> <ul spacing="normal">
L(oss) bit is used for coloring the MPLS packets for loss measurement. Se <li>
tting the bit means color 1 and unsetting the bit means <t>
L(oss) bit is used for coloring the MPLS packets for loss measurement. Se
tting the bit means color 1, and unsetting the bit means
color 0. color 0.
</t> </t>
<t> </li>
<li>
<t>
D(elay) bit is used for coloring the MPLS packets for delay/jitter measur ement. Setting the bit means color for delay measurement. D(elay) bit is used for coloring the MPLS packets for delay/jitter measur ement. Setting the bit means color for delay measurement.
</t> </t>
<t> </li>
<li>
<t>
T(ype) bit is used to indicate the measurement type. When the T bit is set t o 1, that means edge-to-edge performance T(ype) bit is used to indicate the measurement type. When the T bit is set t o 1, that means edge-to-edge performance
measurement. When the T bit is set to 0, that means hop-by-hop performanc e measurement. measurement. When the T bit is set to 0, that means hop-by-hop performanc e measurement.
</t> </t>
</list> </li>
<t> </ul>
<t>
Considering the FL is not used as a forwarding label, the repurposing of the TC for the FL is feasible and viable. Considering the FL is not used as a forwarding label, the repurposing of the TC for the FL is feasible and viable.
</t> </t>
</t> <section anchor="examples-for-flow-id">
<name>Examples for Applying Flow-ID Label in a Label Stack</name>
<section title="Examples for Applying Flow-ID Label in a label stack"> <t> Three examples of different layouts of the FL (4
octets) are illustrated as follows. Note that more examples may
<t> Three examples of different layouts of the Flow-ID label (4 octets) are exist.</t>
illustrated as follows. Note that more examples may exist.</t>
<t> (1) Layout of the Flow-ID label when applied to MPLS transport.</t>
<figure anchor="Figure_2" title="Applying Flow-ID to MPLS transport"> <section anchor="example-one">
<artwork align="center"><![CDATA[ <name>Layout of the Flow-ID Label when Applied to MPLS Transport</name>
<figure anchor="Figure_2">
<name>Applying Flow-ID to MPLS Transport</name>
<artwork align="center"><![CDATA[
+----------------------+ +----------------------+
| LSP | | LSP |
| Label | | Label |
+----------------------+ <--+ +----------------------+ <--+
| Extension | | | Extension | |
| Label | | | Label | |
+----------------------+ |--- cSPL +----------------------+ |--- cSPL
| Flow-ID Label | | | Flow-ID Label | |
| Indicator | | | Indicator | |
+----------------------+ <--+ +----------------------+ <--+
| Flow-ID | | Flow-ID |
| Label | | Label |
+----------------------+ +----------------------+
| Application | | Application |
| Label | | Label |
+----------------------+ <= Bottom of stack +----------------------+ <= Bottom of stack
| | | |
| Payload | | Payload |
| | | |
+----------------------+ +----------------------+]]></artwork>
]]></artwork> </figure>
</figure> <t> With penultimate hop popping (PHP <xref sectionFormat="of"
section="3.16" target="RFC3031"/>), the top label is "popped at the
<t> With penultimate hop popping (PHP, Section 3.16 of <xref target="RFC303 penultimate LSR of the LSP, rather than at the LSP Egress". The final bu
1"/>) the top label is "popped at the penultimate llet of
LSR of the LSP, rather than at the LSP Egress". Since Section 4 of the p <xref target="procedures-of-encap"/> of the present document requires th
resent document, final bullet, requires that "The at "[t]he processing node <bcp14>MUST</bcp14> pop the
processing node MUST pop the XL, FLI and FL from the MPLS label stack wh XL, FLI, and FL from the MPLS label stack when it needs to pop the
en it needs to pop the preceding forwarding label", preceding forwarding label", which implies that the penultimate Label
this implies that the penultimate Label Switching Router (LSR) needs to Switching Router (LSR) needs to follow the requirement of <xref
follow the requirement of Section 4 in order to support target="procedures-of-encap"/> in order to support this
this specification. If this is done, the egress LSR would be excluded fr specification. If this is done, the egress LSR is excluded from
om the performance measurement. Therefore, when this the performance measurement. Therefore, when this specification is in
specification is in use PHP should be disabled, unless the penultimate L use, PHP should be disabled, unless the penultimate LSR is known to
SR is known to have the necessary support, and unless have the necessary support and unless it's acceptable to exclude the
it's acceptable to exclude the egress LSR.</t> egress LSR.</t>
<t> Also note that in other examples of applying Flow-ID to MPLS
<t> Also note that in other examples of applying Flow-ID to MPLS transport, transport, one LSP label can be substituted by multiple SID labels in
one LSP label can be substituted by multiple the case of using SR Policy, and the combination of cSPL and FL can be p
SID labels in the case of using SR Policy, and the combination of cSPL a laced between SID labels, as specified in <xref
nd Flow-ID label can be placed between SID labels, target="flc-frld-considerations"/>.</t>
as specified in Section 6.</t> </section>
<t> (2) Layout of the Flow-ID label when applied to MPLS service.</t>
<figure anchor="Figure_3" title="Applying Flow-ID to MPLS service"> <section anchor="example-two">
<artwork align="center"><![CDATA[ <name>Layout of the Flow-ID Label when Applied to MPLS Service</name>
<figure anchor="Figure_3">
<name>Applying Flow-ID to MPLS Service</name>
<artwork align="center"><![CDATA[
+----------------------+ +----------------------+
| LSP | | LSP |
| Label | | Label |
+----------------------+ +----------------------+
| Application | | Application |
| Label | | Label |
+----------------------+ <--+ +----------------------+ <--+
| Extension | | | Extension | |
| Label | | | Label | |
+----------------------+ |--- cSPL +----------------------+ |--- cSPL
| Flow-ID Label | | | Flow-ID Label | |
| Indicator | | | Indicator | |
+----------------------+ <--+ +----------------------+ <--+
| Flow-ID | | Flow-ID |
| Label | | Label |
+----------------------+ <= Bottom of stack +----------------------+ <= Bottom of stack
| | | |
| Payload | | Payload |
| | | |
+----------------------+ +----------------------+]]></artwork>
]]></artwork> </figure>
</figure> <t> Note that in this case, the application label can be an MPLS PW
label, MPLS Ethernet VPN label, or MPLS IP VPN label, and it is also
<t> Note that in this case, the application label can be an MPLS PW label, called a VC label as defined in <xref target="RFC4026"/>.</t>
MPLS Ethernet VPN label or MPLS IP VPN label, and </section>
it is also called a VC label as defined in <xref target="RFC4026"/>.</t>
<t> (3) Layout of the Flow-ID label when applied to both MPLS transport and
MPLS service.</t>
<figure anchor="Figure_4" title="Applying Flow-ID to both MPLS transport an <section anchor="example-three">
d MPLS service"> <name>Layout of the Flow-ID Label when Applied to both MPLS Transport an
<artwork align="center"><![CDATA[ d MPLS Service</name>
<figure anchor="Figure_4">
<name>Applying Flow-ID to both MPLS Transport and MPLS Service</name>
<artwork align="center"><![CDATA[
+----------------------+ +----------------------+
| LSP | | LSP |
| Label | | Label |
+----------------------+ <--+ +----------------------+ <--+
| Extension | | | Extension | |
| Label | | | Label | |
+----------------------+ |--- cSPL +----------------------+ |--- cSPL
| Flow-ID Label | | | Flow-ID Label | |
| Indicator | | | Indicator | |
+----------------------+ <--+ +----------------------+ <--+
skipping to change at line 386 skipping to change at line 326
+----------------------+ |--- cSPL +----------------------+ |--- cSPL
| Flow-ID Label | | | Flow-ID Label | |
| Indicator | | | Indicator | |
+----------------------+ <--+ +----------------------+ <--+
| Flow-ID | | Flow-ID |
| Label | | Label |
+----------------------+ <= Bottom of stack +----------------------+ <= Bottom of stack
| | | |
| Payload | | Payload |
| | | |
+----------------------+ +----------------------+]]></artwork>
]]></artwork> </figure>
</figure> <t>Note that for this example, the two FL values appearing
in a label stack must be different. In other words, the FL
<t> Note that for this example, the two Flow-ID Label values appearing in a applied to the MPLS transport and the FL applied to the
label stack must be different. In other words, the MPLS service must be different. Also, note that the two FL
Flow-ID label applied to the MPLS transport and the Flow-ID label applie values are independent of each other. For example, two packets can
d to the MPLS service must be different. Also, note that belong to the same VPN flow but different LSP flows, or two packets
the two Flow-ID label values are independent of each other. For example, can belong to different VPN flows but the same LSP flow.</t>
two packets can belong to the same VPN flow but different </section>
LSP flows, or two packets can belong to different VPN flows but the same </section>
LSP flow.</t>
</section> </section>
</section> <section anchor="procedures-of-encap">
<name>Procedures of Encapsulation, Look-Up, and Decapsulation</name>
<section title="Procedures of Encapsulation, Look-up and Decapsulation"> <t>
The procedures for FL encapsulation, look-up, and decapsulation are summariz
<t> ed as follows:
The procedures for Flow-ID label encapsulation, look-up and decapsulation ar </t>
e summarized as follows: <ul spacing="normal">
<list style="symbols"> <li>
<t> <t>
The MPLS ingress node <xref target="RFC3031"/> inserts the XL, FLI and FL in The MPLS ingress node <xref target="RFC3031"/> inserts the XL, FLI, and FL i
to the MPLS label stack. At the same time, nto the MPLS label stack. At the same time,
the ingress node sets the Flow-ID Label value, the two color-marking bits the ingress node sets the FL value, the two color-marking bits, and the T
and the T bit, as defined in Section 3. bit, as defined in <xref target="flow-based-pm-encapsulation"/>.
</t> </t>
<t> </li>
If the edge-to-edge measurement is applied, i.e., the T bit is set to 1, the <li>
n only the MPLS ingress/egress node <xref target="RFC3031"/> <t>
is the processing node, otherwise all the MPLS nodes along the LSP are th If edge-to-edge measurement is applied, i.e., the T bit is set to 1, then on
e processing nodes. The processing node looks ly the MPLS ingress/egress node <xref target="RFC3031"/>
up the FL with the help of the XL and FLI, and exports the collected data is the processing node; otherwise, all the MPLS nodes along the LSP are t
, such as the Flow-ID, block counters and timestamps, he processing nodes. The processing node looks
to an external NMS/controller, referring to the Alternate-Marking method. up the FL with the help of the XL and FLI, and exports the collected data
Section 6 of <xref target="I-D.ietf-ippm-alt-mark-deployment"/> (such as the Flow-ID, block counters, and timestamps)
describes protocols for collected data export, and the details on how to to an external NMS/controller, referring to the Alternate-Marking Method.
export the collected data are outside the scope Section 6 of <xref target="I-D.ietf-ippm-alt-mark-deployment"/>
of this document. Note that while looking up the Flow-ID label, the trans describes protocols for collected data export; the details on how to expo
it node needs to perform some deep labels inspection rt the collected data are outside the scope
beyond the label (at the top of the label stack) used to make forwarding of this document. Note that
decisions. while looking up the FL, the transit node needs to
</t> inspect beyond the label at the top
<t> of the label stack used to make forwarding decisions.
The processing node MUST pop the XL, FLI and FL from the MPLS label stack wh </t>
en it needs to pop the preceding forwarding label. </li>
The egress node MUST pop the whole MPLS label stack, and this document do <li>
esn't introduce any new process to the decapsulated packet. <t>
</t> The processing node <bcp14>MUST</bcp14> pop the XL, FLI, and FL from the MPL
</list> S label stack when it needs to pop the preceding forwarding label.
</t> The egress node <bcp14>MUST</bcp14> pop the whole MPLS label stack. This
document doesn't introduce any new process to the decapsulated packet.
</section> </t>
</li>
<section title="Procedures of Flow-ID allocation"> </ul>
</section>
<t> <section anchor="procedures-of-flow-id-alloc">
<name>Procedures of Flow-ID Allocation</name>
<t>
There are at least two ways of allocating Flow-ID. One way is to allocate Fl ow-ID by a manual trigger from the network There are at least two ways of allocating Flow-ID. One way is to allocate Fl ow-ID by a manual trigger from the network
operator, and the other way is to allocate Flow-ID by an automatic trigge r from the ingress node. Details are as follows: operator, and the other way is to allocate Flow-ID by an automatic trigge r from the ingress node. Details are as follows:
<list style="symbols"> </t>
<t> <ul spacing="normal">
In the case of a manual trigger, the network operator would manually input t <li>
he characteristics (e.g. IP five <t>
tuples and IP DSCP) of the measured flow, then the NMS/controller would g In the case of a manual trigger, the network operator manually inputs the ch
enerate one or two aracteristics (e.g., IP five
Flow-IDs based on the input from the network operator, and provision the tuples and IP DSCP) of the measured flow; then the NMS/controller generat
ingress node with the characteristics es one or two
Flow-IDs based on the input from the network operator and provisions the
ingress node with the characteristics
of the measured flow and the corresponding allocated Flow-ID(s). of the measured flow and the corresponding allocated Flow-ID(s).
</t> </t>
<t> </li>
In the case of an automatic trigger, the ingress node would identify the flo <li>
w entering the measured path, <t>
export the characteristics of the identified flow to the NMS/controller b In the case of an automatic trigger, the ingress node identifies the flow en
y IPFIX <xref target="RFC7011"/>, tering the measured path and
then the NMS/controller would generate one or two Flow-IDs based on the c exports the characteristics of the identified flow to the NMS/controller
haracteristics exported from the ingress node, by IPFIX <xref target="RFC7011"/>;
and provision the ingress node with the characteristics of the identified then the NMS/controller generates one or two Flow-IDs based on the charac
flow and the corresponding allocated Flow-ID(s). teristics exported from the ingress node
</t> and provisions the ingress node with the characteristics of the identifie
</list> d flow and the corresponding allocated Flow-ID(s).
</t> </t>
<t> </li>
The policy pre-configured at the NMS/controller decides whether one Flow-ID </ul>
or two Flow-IDs would be generated. <t>
If the performance measurement on the MPLS service is enabled, then one F The policy preconfigured at the NMS/controller decides whether one Flow-ID o
low-ID applied to the MPLS service would be generated. r two Flow-IDs are generated.
If the performance measurement on the MPLS transport is enabled, then one If the performance measurement on the MPLS service is enabled, then one F
Flow-ID applied to the MPLS transport would be generated. low-ID applied to the MPLS service is generated.
If both of them are enabled, then two Flow-IDs are respectively applied t If the performance measurement on the MPLS transport is enabled, then one
o the MPLS service and the MPLS transport would be generated. Flow-ID applied to the MPLS transport is generated.
In this case, a transit node needs to look up both of the two Flow-IDs by If both of them are enabled, then two Flow-IDs are respectively applied t
default. However, this behaviour can be changed through o the MPLS service and the MPLS transport are generated.
In this case, a transit node needs to look up both of the two Flow-IDs by
default. However, this behavior can be changed through
configuration, such as by setting it to look up only the Flow-ID applied to the MPLS transport. configuration, such as by setting it to look up only the Flow-ID applied to the MPLS transport.
</t> </t>
<t> <t>
Whether using the two methods mentioned above or other methods to allocate F Whether using the two methods mentioned above or other methods to allocate F
low-ID, the NMS/controller MUST ensure that every low-ID, the NMS/controller <bcp14>MUST</bcp14> ensure that every
generated Flow-ID is unique within the administrative domain and MUST NOT generated Flow-ID is unique within the administrative domain and <bcp14>M
have any value in the reserved label space UST NOT</bcp14> have any value in the reserved label space
(0-15) <xref target="RFC3032"/>. Specifically, the statement of "Flow-ID is unique" means that the values of Flow-ID are distinct (0-15) <xref target="RFC3032"/>. Specifically, the statement of "Flow-ID is unique" means that the values of Flow-ID are distinct
and non-redundant for any flow at any given time within an administrative domain, such that no two flows share the same Flow-ID. and non-redundant for any flow at any given time within an administrative domain, such that no two flows share the same Flow-ID.
This uniqueness ensures that each flow can be individually identified, tr acked, and differentiated from others for accurate performance This uniqueness ensures that each flow can be individually identified, tr acked, and differentiated from others for accurate performance
monitoring and management. monitoring and management.
</t> </t>
</section>
</section> <section anchor="flc-frld-considerations">
<name>FLC and FRLD Considerations</name>
<section title="FLC and FRLD Considerations"> <t> Analogous to the Entropy Label Capability (ELC) defined in <xref secti
onFormat="of" section="5" target="RFC6790"/> and the
<t> Analogous to the Entropy Label Capability (ELC) defined in Section 5 of <x Entropy Readable Label Depth (ERLD) defined in <xref sectionFormat="of" sectio
ref target="RFC6790"/> and the n="4" target="RFC8662"/>, the Flow-ID Label
Entropy Readable Label Depth (ERLD) defined in Section 4 of <xref target="RFC8
662"/>, the Flow-ID Label
Capability (FLC) and the Flow-ID Readable Label Depth (FRLD) are defined in th is document. Both FLC and FRLD have Capability (FLC) and the Flow-ID Readable Label Depth (FRLD) are defined in th is document. Both FLC and FRLD have
similar semantics with the ELC and ERLD to a router, except that the Flow-ID i s used in its flow identification similar semantics with the ELC and ERLD to a router, except that the Flow-ID i s used in its flow identification
function while the Entropy is used in its load-balancing function.</t> function while the Entropy is used in its load-balancing function.</t>
<t> The ingress node <bcp14>MUST</bcp14> insert each FL at an appropriate
<t> The ingress node MUST insert each FL at an appropriate depth, which ensure depth, which ensures the node to which the
s the node to which the FL is exposed has the FLC. The ingress node <bcp14>SHOULD</bcp14> insert each
FL is exposed has the FLC. The ingress node SHOULD insert each FL within an ap FL within an appropriate FRLD, which is the
propriate FRLD, which is the
minimum FRLD of all the on-path nodes that need to read and use the FL in ques tion. How the ingress node knows minimum FRLD of all the on-path nodes that need to read and use the FL in ques tion. How the ingress node knows
the FLC and FRLD of all the on-path nodes is outside the scope of this documen t.</t> the FLC and FRLD of all the on-path nodes is outside the scope of this documen t.</t>
<t> When the SR paths are used for transport, the label stack grows as the
<t> When the SR paths are used for transport, the label stack grows as the num number of on-path segments increases. If
ber of on-path segments increases. If
the number of on-path segments is high, that may become a challenge for the FL to be placed within an the number of on-path segments is high, that may become a challenge for the FL to be placed within an
appropriate FRLD. To overcome this potential challenge, an implementation MAY appropriate FRLD. To overcome this potential challenge, an implementation <bcp
allow 14>MAY</bcp14> allow
the ingress node to place FL between SID labels. This means that multiple iden the ingress node to place FL between SID labels. This means that multiple iden
tical FLs at different depths MAY be tical FLs at different depths <bcp14>MAY</bcp14> be
interleaved with SID labels. When this occurs, sophisticated network planning may be needed, which is beyond the scope of this document.</t> interleaved with SID labels. When this occurs, sophisticated network planning may be needed, which is beyond the scope of this document.</t>
</section>
</section> <section anchor="ecmp">
<name>Equal-Cost Multipath Considerations</name>
<section title="Equal-Cost Multipath Considerations"> <t> Analogous to what's described in <xref sectionFormat="of" section="5"
target="RFC8957"/>, under conditions of equal-cost multipath, the introduction o
<t> Analogous to what's described in Section 5 of <xref target="RFC8957"/>, un f the FL may lead to the same problem that is caused by the Synonymous Flow Labe
der conditions of Equal-Cost Multipath l (SFL) <xref target="RFC8957"/>.
(ECMP), the introduction of the FL may lead to the same problem as caused by t The two solutions proposed for SFL also apply here. Specifically, adding FL to
he Synonymous Flow Label (SFL) <xref target="RFC8957"/>. an existing flow may cause that flow to take a different
The two solutions proposed for SFL would also apply here. Specifically, adding
FL to an existing flow may cause that flow to take a different
path. If the operator expects to resolve this problem, they can choose to appl y entropy labels <xref target="RFC6790"/> or add FL to all flows.</t> path. If the operator expects to resolve this problem, they can choose to appl y entropy labels <xref target="RFC6790"/> or add FL to all flows.</t>
</section>
</section> <section anchor="sec-considerations">
<name>Security Considerations</name>
<section title="Security Considerations"> <t> As specified in <xref sectionFormat="of" section="7.1" target="RFC9341
<t> As specified in Section 7.1 of <xref target="RFC9341"/>, "for security rea "/>, "for security reasons, the Alternate-Marking Method <bcp14>MUST</bcp14> onl
sons, the Alternate-Marking Method MUST only be applied y be applied
to controlled domains". That requirement applies when the MPLS performance mea to controlled domains." This requirement applies when the MPLS performance mea
surement with Alternate-Marking Method is taken into surement with Alternate-Marking Method is taken into
account, which means the MPLS encapsulation and related procedures defined in account, which means the MPLS encapsulation and related procedures defined in
this document MUST only be applied to controlled domains, this document <bcp14>MUST</bcp14> only be applied to controlled domains;
otherwise the potential attacks discussed in Section 10 of <xref target="RFC93 otherwise, the potential attacks discussed in <xref sectionFormat="of" section
41"/> may be applied to the deployed MPLS networks. </t> ="10" target="RFC9341"/> may be applied to the deployed MPLS networks. </t>
<t> As specified in <xref target="flow-based-pm-encapsulation"/>, the valu
<t> As specified in Section 3, the value of a Flow-ID label MUST be unique wit e of an FL <bcp14>MUST</bcp14> be unique within the administrative domain. In ot
hin the administrative domain. In other words, the her words, the
administrative domain is the scope of a Flow-ID label. The method for achievin administrative domain is the scope of an FL. The method for achieving multi-do
g multi-domain performance measurement with the same main performance measurement with the same
Flow-ID label is outside the scope of this document. The Flow-ID label MUST NO FL is outside the scope of this document. The FL <bcp14>MUST NOT</bcp14> be si
T be signaled and distributed outside the administrative gnaled and distributed outside the administrative
domain. Improper configuration that allows the Flow-ID label to be passed from domain. Improper configuration that allows the FL to be passed from one admini
one administrative domain to another would result in strative domain to another would result in
Flow-ID conflicts. </t> Flow-ID conflicts. </t>
<t> To prevent packets carrying FLs from leaking from one domain to anothe
<t> To prevent packets carrying Flow-ID labels from leaking from one domain to r, domain boundary
another, domain boundary nodes <bcp14>MUST</bcp14> deploy policies (e.g., ACL) to filter out these pack
nodes MUST deploy policies (e.g., ACL) to filter out these packets. Specifica ets. Specifically, at the sending edge,
lly, at the sending edge, the domain boundary node <bcp14>MUST</bcp14> filter out the packets that carry
the domain boundary node MUST filter out the packets that carry the Flow-ID La the FLI and are sent
bel Indicator and are sent to other domains. At the receiving edge, the domain boundary node <bcp14>MUST<
to other domains. At the receiving edge, the domain boundary node MUST drop th /bcp14> drop the packets that carry the
e packets that carry the FLI and are from other domains. Note that packet leakage is neither breaching
Flow-ID Label Indicator and are from other domains. Note that packet leakage i privacy
s neither breaching privacy nor a source of DoS.</t>
nor can be a source of DoS.</t>
</section>
<section title="Implementation Status">
<t>[Note to the RFC Editor - remove this section before publication, as well
as remove the reference to <xref target="RFC7942"/>.</t>
<t>This section records the status of known implementations of the protocol
defined by this specification at the time
of posting of this Internet-Draft, and is based on a proposal described i
n <xref target="RFC7942"/>. The description of
implementations in this section is intended to assist the IETF in its dec
ision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here does n
ot imply endorsement by the IETF. Furthermore,
no effort has been spent to verify the information presented here that wa
s supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available impl
ementations or their features. Readers are
advised to note that other implementations may exist.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and wor
king groups to assign due consideration to
documents that have the benefit of running code, which may serve as evide
nce of valuable experimentation and feedback
that have made the implemented protocols more mature. It is up to the ind
ividual working groups to use this information
as they see fit".</t>
<section title="Fiberhome">
<ul spacing="normal">
<li>
<t>Organization: Fiberhome Corporation.</t>
</li>
<li>
<t>Implementation: Fiberhome R82*, R800*, S680*, S780* series routers
are running the common-building block 'Flow-based PM Encapsulation in MPLS'.</t>
</li>
<li>
<t>Maturity Level: Product</t>
</li>
<li>
<t>Coverage: Partial, section 3 and example (2) of section 3.1.</t>
</li>
<li>
<t>Version: Draft-08</t>
</li>
<li>
<t>Licensing: N/A</t>
</li>
<li>
<t>Implementation experience: Nothing specific.</t>
</li>
<li>
<t>Contact: djy@fiberhome.com</t>
</li>
<li>
<t>Last updated: December 25, 2023</t>
</li>
</ul>
</section> </section>
<section title="Huawei Technologies"> <section anchor="iana-considerations">
<ul spacing="normal"> <name>IANA Considerations</name>
<li>
<t>Organization: Huawei Technologies.</t>
</li>
<li>
<t>Implementation: Huawei ATN8XX, ATN910C, ATN980B, CX600-M2, NE40E, M
E60-X1X2, ME60-X3X8X16 Routers running VRPV800R021C00 or above.
Huawei NCE-IP Controller running V1R21C00 or above.</t>
</li>
<li>
<t>Maturity Level: Product</t>
</li>
<li>
<t>Coverage: Partial, section 3 and example (2) of section 3.1.</t>
</li>
<li>
<t>Version: Draft-08</t>
</li>
<li>
<t>Licensing: N/A</t>
</li>
<li>
<t>Implementation experience: Nothing specific.</t>
</li>
<li>
<t>Contact: zhoutianran@huawei.com</t>
</li>
<li>
<t>Last updated: January 10, 2024</t>
</li>
</ul>
</section>
<section title="ZTE Corp"> <t>IANA has assigned the following value in the "Extended Special-Purpose
<ul spacing="normal"> MPLS Label Values" registry within the "Special-Purpose Multiprotocol Label Swit
<li> ching (MPLS) Label Values" registry group: </t>
<t>Organization: ZTE Corporation.</t>
</li>
<li>
<t>Implementation: ZTE ZXCTN 6500-32 routers running V5.00.20 or above
. ZTE ZXCTN 6170H routers running V5.00.30.20 or above. ZTE
ElasticNet UME Controller running V16.22.20 or above.</t>
</li>
<li>
<t>Maturity Level: Product</t>
</li>
<li>
<t>Coverage: Partial, section 3 and example (2) of section 3.1.</t>
</li>
<li>
<t>Version: Draft-08</t>
</li>
<li>
<t>Licensing: N/A</t>
</li>
<li>
<t>Implementation experience: Nothing specific.</t>
</li>
<li>
<t>Contact: xiao.min2@zte.com.cn</t>
</li>
<li>
<t>Last updated: January 22, 2024</t>
</li>
</ul>
</section>
<section title="China Mobile"> <table anchor="Table_1">
<t> China Mobile reported that they have conducted interconnection tests w <name>New Extended Special-Purpose MPLS Label Value for Flow-ID Label In
ith multiple vendors according to this draft. The tests result have proven dicator</name>
that the solutions from multiple vendors are mature and ready for large-scale <thead>
deployment. This report was last updated on January 10, 2024.</t> <tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">18</td>
<td align="left">Flow-ID Label Indicator (FLI)</td>
<td align="left">RFC 9714</td>
</tr>
</tbody>
</table>
</section> </section>
</middle>
<back>
<displayreference target="I-D.ietf-ippm-alt-mark-deployment" to="ALT-MARK"/>
<displayreference target="I-D.cx-mpls-mna-inband-pm" to="MNA-PM-with-AMM"/>
</section> <references>
<name>References</name>
<section title="IANA Considerations"> <references>
<t> From the "Extended Special-Purpose MPLS Label Values" registry in the "Spe <name>Normative References</name>
cial-Purpose Multiprotocol Label Switching (MPLS) Label Values" namespace, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
a new value for the Flow-ID Label Indicator is requested from IANA as follows: 119.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<texttable anchor="Table_1" title="New Extended Special-Purpose MPLS Label 174.xml"/>
Value for Flow-ID Label Indicator"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<ttcol align="left">Value</ttcol> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<ttcol align="left">Description</ttcol> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
017.xml"/>
<ttcol align="left">Reference</ttcol> </references>
<references>
<c>TBA1 (value 18 is recommended)</c> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<c>Flow-ID Label Indicator (FLI)</c> 026.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<c>This Document</c> 011.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</texttable> 372.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
790.xml"/>
<section title="Acknowledgements"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t> The authors would like to acknowledge Loa Andersson, Tarek Saad, Stewart B 662.xml"/>
ryant, Rakesh Gandhi, Greg Mirsky, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
Aihua Liu, Shuangping Zhan, Ming Ke, Wei He, Ximing Dong, Darren Dukes, Tony L 957.xml"/>
i, James Guichard, Daniele Ceccarelli, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
Eric Vyncke, John Scudder, Gunter van de Velde, Roman Danyliw, Warren Kumari, 341.xml"/>
Murray Kucherawy, Deb Cooley, Zaheduzzaman <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
Sarker, and Deboraha Brungard for their careful review and very helpful commen 613.xml"/>
ts.</t> <!-- [I-D.ietf-ippm-alt-mark-deployment] IESG State: I-D Exists as of 10/23/2024
<t> They also wish to acknowledge Italo Busi and Chandrasekar Ramachandran for -->
their insightful MPLS-RT <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ip
review and constructive comments.</t> pm-alt-mark-deployment.xml"/>
<t> Additionally, the authors would like to thank Dhruv Dhody for the English <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-cx-mpls
grammar review.</t> -mna-inband-pm.xml"/>
</section> </references>
</references>
<section title="Contributors">
<t>Minxue Wang<br/>China Mobile<br/>Email: wangminxue@chinamobile.com</t>
<t>Wen Ye<br/>China Mobile<br/>Email: yewen@chinamobile.com</t>
</section>
</middle> <section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t> The authors acknowledge <contact fullname="Loa
Andersson"/>, <contact fullname="Tarek Saad"/>, <contact
fullname="Stewart Bryant"/>, <contact fullname="Rakesh Gandhi"/>,
<contact fullname="Greg Mirsky"/>, <contact fullname="Aihua Liu"/>,
<contact fullname="Shuangping Zhan"/>, <contact fullname="Ming Ke"/>,
<contact fullname="Wei He"/>, <contact fullname="Ximing Dong"/>,
<contact fullname="Darren Dukes"/>, <contact fullname="Tony Li"/>,
<contact fullname="James Guichard"/>, <contact fullname="Daniele
Ceccarelli"/>, <contact fullname="Eric Vyncke"/>, <contact
fullname="John Scudder"/>, <contact fullname="Gunter van de Velde"/>,
<contact fullname="Roman Danyliw"/>, <contact fullname="Warren
Kumari"/>, <contact fullname="Murray Kucherawy"/>, <contact
fullname="Deb Cooley"/>, <contact fullname="Zaheduzzaman Sarker"/>, and
<contact fullname="Deborah Brungard"/> for their careful review and
very helpful comments.</t>
<t> They also acknowledge <contact fullname="Italo Busi"/> and
<contact fullname="Chandrasekar Ramachandran"/> for their insightful
MPLS-RT review and constructive comments.</t>
<t> Additionally, the authors thank <contact
fullname="Dhruv Dhody"/> for the English grammar review.</t>
</section>
<section anchor="contrib" numbered="false">
<name>Contributors</name>
<back> <contact fullname="Minxue Wang">
<organization>China Mobile</organization>
<address>
<email>wangminxue@chinamobile.com</email>
</address>
</contact>
<references title="Normative References"> <contact fullname="Wen Ye">
<?rfc include="reference.RFC.2119"?> <organization>China Mobile</organization>
<?rfc include="reference.RFC.8174"?> <address>
<?rfc include="reference.RFC.3031"?> <email>yewen@chinamobile.com</email>
<?rfc include="reference.RFC.3032"?> </address>
<?rfc include="reference.RFC.9017"?> </contact>
</references>
<references title="Informative References"> </section>
<?rfc include="reference.RFC.4026"?>
<?rfc include="reference.RFC.7011"?>
<?rfc include="reference.RFC.8372"?>
<?rfc include="reference.RFC.6790"?>
<?rfc include="reference.RFC.8662"?>
<?rfc include="reference.RFC.8957"?>
<?rfc include="reference.RFC.7942"?>
<?rfc include="reference.RFC.9341"?>
<?rfc include="reference.RFC.9613"?>
<?rfc include="reference.I-D.ietf-ippm-alt-mark-deployment"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 60 change blocks. 
663 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.48.