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="January"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<date year="2024"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>Request for Comments</keyword> <keyword>example</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>
<!-- [rfced] The following is somewhat tough to parse. May we update as follows? Otherwise, please clarify.
<t> Note that in parallel to the work of this document, there is ongoing work Original:
on MPLS Network Actions (MNA) <xref target="RFC9613"/>. That means the MNA encapsulation is expected to
The MPLS performance measurement with the Alternate-Marking method can also b provide a more advanced solution, when published as an RFC and it is
e achieved by MNA encapsulation. In addition, MNA will agreed that this document will be made Historic at that time.
provide a broader use case applicability. That means the MNA encapsulation is
expected to provide a more advanced solution, when
published as an RFC and it is agreed that this document will be made Historic
at that time.</t>
</section>
<section title="Conventions Used in This Document"> Perhaps:
That means the MNA encapsulation is expected to
provide a more advanced solution. Once published as an RFC, it is
agreed that this document will be made Historic.
-->
<section title="Abbreviations"> <t> Note that in parallel to the work of this document, there is ongoing w
<t> ACL: Access Control List</t> ork on MPLS Network Actions (MNA) <xref target="RFC9613"/>.
<t> BoS: Bottom of Stack</t> The MPLS performance measurement with the Alternate-Marking Method can also b
<t> cSPL: Composite Special Purpose Label, the combination of the Extension e achieved by MNA encapsulation. In addition, MNA will
Label (value 15) and an Extended Special Purpose Label</t> provide a broader use-case applicability. That means the MNA encapsulation is
<t> DSCP: Differentiated Services Code Point</t> expected to provide a more advanced solution, when
<t> ECMP: Equal-Cost Multipath</t> published as an RFC and it is agreed that this document will be made Historic
<t> ELC: Entropy Label Capability</t> at that time.</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>ECMP:</dt><dd>Equal-Cost Multipath</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 Flow-ID Label values <bcp14>MAY</bcp14> be all
ternal NMS or controller based on the measurement ocated by an 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 Flow-ID Label values is described in <xref target=
</t> "procedures-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> <!-- [rfced] For readability, we have updated the sentence below. Please let us
Besides the flow identification, a color-marking field is also necessary know if updates are needed.
for the Alternate-Marking method. To achieve
the purpose of coloring the MPLS traffic, and to distinguish between hop- Original:
by-hop measurement and edge-to-edge measurement, the To achieve the purpose
of coloring the MPLS traffic, and to distinguish between hop-by-hop
measurement and edge-to-edge measurement, the TC for the FL is
defined as follows:
Current:
To color the MPLS
traffic and to distinguish between hop-by-hop measurement and edge-
to-edge measurement, the TC for the FL is defined as follows:
-->
<t>
Besides the flow identification, a color-marking field is also necessary
for the Alternate-Marking Method. To color the MPLS traffic and to distinguish b
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 Flow-ID label (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 Flow-ID
SID labels in the case of using SR Policy, and the combination of cSPL a label can be placed 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 349
+----------------------+ |--- 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 Flow-ID Label values appearing
in a label stack must be different. In other words, the Flow-ID label
<t> Note that for this example, the two Flow-ID Label values appearing in a applied to the MPLS transport and the Flow-ID label applied to the
label stack must be different. In other words, the MPLS service must be different. Also, note that the two Flow-ID label
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>
<t>
The procedures for Flow-ID label encapsulation, look-up, and decapsulation a
re summarized as follows:
</t>
<ul spacing="normal">
<li>
<t>
The MPLS ingress node <xref target="RFC3031"/> inserts the XL, FLI, and FL i
nto the MPLS label stack. At the same time,
the ingress node sets the Flow-ID Label value, the two color-marking bits
, and the T bit, as defined in <xref target="flow-based-pm-encapsulation"/>.
</t>
</li>
<li>
<!-- [rfced] "perform some deep labels inspection beyond the label" reads oddly.
Please review.
<section title="Procedures of Encapsulation, Look-up and Decapsulation"> Original:
Note that
while looking up the Flow-ID label, the transit node needs to
perform some deep labels inspection beyond the label (at the top
of the label stack) used to make forwarding decisions.
<t> Perhaps:
The procedures for Flow-ID label encapsulation, look-up and decapsulation ar Note that
e summarized as follows: while looking up the Flow-ID label, the transit node needs to
<list style="symbols"> inspect beyond the label at the top
<t> of the label stack used to make forwarding decisions.
The MPLS ingress node <xref target="RFC3031"/> inserts the XL, FLI and FL in -->
to the MPLS label stack. At the same time, <t>
the ingress node sets the Flow-ID Label value, the two color-marking bits If edge-to-edge measurement is applied, i.e., the T bit is set to 1, then on
and the T bit, as defined in Section 3. ly the MPLS ingress/egress node <xref target="RFC3031"/>
</t> is the processing node; otherwise, all the MPLS nodes along the LSP are t
<t> he processing nodes. The processing node looks
If the edge-to-edge measurement is applied, i.e., the T bit is set to 1, the up the FL with the help of the XL and FLI, and exports the collected data
n only the MPLS ingress/egress node <xref target="RFC3031"/> (such as the Flow-ID, block counters, and timestamps)
is the processing node, otherwise all the MPLS nodes along the LSP are th to an external NMS/controller, referring to the Alternate-Marking Method.
e processing nodes. The processing node looks Section 6 of <xref target="I-D.ietf-ippm-alt-mark-deployment"/>
up the FL with the help of the XL and FLI, and exports the collected data describes protocols for collected data export; the details on how to expo
, such as the Flow-ID, block counters and timestamps, rt the collected data are outside the scope
to an external NMS/controller, referring to the Alternate-Marking method.
Section 6 of <xref target="I-D.ietf-ippm-alt-mark-deployment"/>
describes protocols for collected data export, and the details on how to
export the collected data are outside the scope
of this document. Note that while looking up the Flow-ID label, the trans it node needs to perform some deep labels inspection of this document. Note that while looking up the Flow-ID label, the trans it node needs to perform some deep labels inspection
beyond the label (at the top of the label stack) used to make forwarding decisions. beyond the label (at the top of the label stack) used to make forwarding decisions.
</t> </t>
<t> </li>
The processing node MUST pop the XL, FLI and FL from the MPLS label stack wh <li>
en it needs to pop the preceding forwarding label. <t>
The egress node MUST pop the whole MPLS label stack, and this document do The processing node <bcp14>MUST</bcp14> pop the XL, FLI, and FL from the MPL
esn't introduce any new process to the decapsulated packet. 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
</list> document doesn't introduce any new process to the decapsulated packet.
</t> </t>
</li>
</section> </ul>
</section>
<section title="Procedures of Flow-ID allocation"> <section anchor="procedures-of-flow-id-alloc">
<name>Procedures of Flow-ID Allocation</name>
<t> <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
<t> Analogous to what's described in Section 5 of <xref target="RFC8957"/>, un (ECMP), the introduction of the FL may lead to the same problem that is caused
der conditions of Equal-Cost Multipath by the Synonymous Flow Label (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 a Flow-ID label <bcp14>MUST</bcp14> be unique within the administrative dom
hin the administrative domain. In other words, the ain. In other words, the
administrative domain is the scope of a Flow-ID label. The method for achievin g multi-domain performance measurement with the same administrative domain is the scope of a Flow-ID label. The method for achievin g multi-domain performance measurement with the same
Flow-ID label is outside the scope of this document. The Flow-ID label MUST NO T be signaled and distributed outside the administrative Flow-ID label is outside the scope of this document. The Flow-ID label <bcp14> MUST NOT</bcp14> be signaled and distributed outside the administrative
domain. Improper configuration that allows the Flow-ID label to be passed from one administrative domain to another would result in domain. Improper configuration that allows the Flow-ID label to be passed from one administrative domain to another would result in
Flow-ID conflicts. </t> Flow-ID conflicts. </t>
<t> To prevent packets carrying Flow-ID labels from leaking from one domai
<t> To prevent packets carrying Flow-ID labels from leaking from one domain to n to another, 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 Flow-ID Label Indicator 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
Flow-ID Label Indicator and are from other domains. Note that packet leakage i s neither breaching privacy Flow-ID Label Indicator and are from other domains. Note that packet leakage i s neither breaching privacy
nor can be a source of DoS.</t> nor a source of DoS.</t>
</section> </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 <section anchor="iana-considerations">
king groups to assign due consideration to <name>IANA Considerations</name>
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"> <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: 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 title="Huawei Technologies"> <table anchor="Table_1">
<ul spacing="normal"> <name>New Extended Special-Purpose MPLS Label Value for Flow-ID Label In
<li> dicator</name>
<t>Organization: Huawei Technologies.</t> <thead>
</li> <tr>
<li> <th align="left">Value</th>
<t>Implementation: Huawei ATN8XX, ATN910C, ATN980B, CX600-M2, NE40E, M <th align="left">Description</th>
E60-X1X2, ME60-X3X8X16 Routers running VRPV800R021C00 or above. <th align="left">Reference</th>
Huawei NCE-IP Controller running V1R21C00 or above.</t> </tr>
</li> </thead>
<li> <tbody>
<t>Maturity Level: Product</t> <tr>
</li> <td align="left">18</td>
<li> <td align="left">Flow-ID Label Indicator (FLI)</td>
<t>Coverage: Partial, section 3 and example (2) of section 3.1.</t> <td align="left">RFC 9714</td>
</li> </tr>
<li> </tbody>
<t>Version: Draft-08</t> </table>
</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>
</middle>
<back>
<displayreference target="I-D.ietf-ippm-alt-mark-deployment" to="ALT-MARK"/>
<section title="ZTE Corp"> <references>
<ul spacing="normal"> <name>References</name>
<li> <references>
<t>Organization: ZTE Corporation.</t> <name>Normative References</name>
</li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<li> 119.xml"/>
<t>Implementation: ZTE ZXCTN 6500-32 routers running V5.00.20 or above <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
. ZTE ZXCTN 6170H routers running V5.00.30.20 or above. ZTE 174.xml"/>
ElasticNet UME Controller running V16.22.20 or above.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</li> 031.xml"/>
<li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<t>Maturity Level: Product</t> 032.xml"/>
</li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<li> 017.xml"/>
<t>Coverage: Partial, section 3 and example (2) of section 3.1.</t> </references>
</li> <references>
<li> <name>Informative References</name>
<t>Version: Draft-08</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</li> 026.xml"/>
<li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>Licensing: N/A</t> 011.xml"/>
</li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<li> 372.xml"/>
<t>Implementation experience: Nothing specific.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</li> 790.xml"/>
<li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>Contact: xiao.min2@zte.com.cn</t> 662.xml"/>
</li> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<li> 957.xml"/>
<t>Last updated: January 22, 2024</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</li> 341.xml"/>
</ul> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</section> 613.xml"/>
<!-- [I-D.ietf-ippm-alt-mark-deployment] IESG State: I-D Exists as of 10/23/2024
-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ip
pm-alt-mark-deployment.xml"/>
</references>
</references>
<section title="China Mobile"> <!-- [rfced] Note the following regarding terminology:
<t> China Mobile reported that they have conducted interconnection tests w
ith multiple vendors according to this draft. The tests result have proven
that the solutions from multiple vendors are mature and ready for large-scale
deployment. This report was last updated on January 10, 2024.</t>
</section>
</section> A) The following term appears with inconsistent capitalization. Perhaps FL can be used throughout once the abbreviated form is introduced? This avoids the cap italization issue.
<section title="IANA Considerations"> Flow-ID Label vs Flow-ID label
<t> From the "Extended Special-Purpose MPLS Label Values" registry in the "Spe
cial-Purpose Multiprotocol Label Switching (MPLS) Label Values" namespace,
a new value for the Flow-ID Label Indicator is requested from IANA as follows:
</t>
<texttable anchor="Table_1" title="New Extended Special-Purpose MPLS Label
Value for Flow-ID Label Indicator">
<ttcol align="left">Value</ttcol> B) "ECMP" is only used in connection with its expanded form. Perhaps the abbrev iated form does not need to be introduced/used in this document?
<ttcol align="left">Description</ttcol> Originals from
<ttcol align="left">Reference</ttcol> - Section 2.1:
ECMP: Equal-Cost Multipath
<c>TBA1 (value 18 is recommended)</c> - Section 7:
Analogous to what's described in Section 5 of [RFC8957], under
conditions of Equal-Cost Multipath (ECMP), the introduction of the FL
may lead to the same problem as caused by the Synonymous Flow Label
(SFL) [RFC8957].
<c>Flow-ID Label Indicator (FLI)</c> C) We updated the capitalization as follows for consistency with RFC 9341. Plea se let us know if you disagree.
<c>This Document</c> Alternate-Marking method -> Alternate-Marking Method
</texttable> -->
</section>
<section title="Acknowledgements"> <section anchor="acknowledgements" numbered="false">
<t> The authors would like to acknowledge Loa Andersson, Tarek Saad, Stewart B <name>Acknowledgements</name>
ryant, Rakesh Gandhi, Greg Mirsky, <t> The authors acknowledge <contact fullname="Loa
Aihua Liu, Shuangping Zhan, Ming Ke, Wei He, Ximing Dong, Darren Dukes, Tony L Andersson"/>, <contact fullname="Tarek Saad"/>, <contact
i, James Guichard, Daniele Ceccarelli, fullname="Stewart Bryant"/>, <contact fullname="Rakesh Gandhi"/>,
Eric Vyncke, John Scudder, Gunter van de Velde, Roman Danyliw, Warren Kumari, <contact fullname="Greg Mirsky"/>, <contact fullname="Aihua Liu"/>,
Murray Kucherawy, Deb Cooley, Zaheduzzaman <contact fullname="Shuangping Zhan"/>, <contact fullname="Ming Ke"/>,
Sarker, and Deboraha Brungard for their careful review and very helpful commen <contact fullname="Wei He"/>, <contact fullname="Ximing Dong"/>,
ts.</t> <contact fullname="Darren Dukes"/>, <contact fullname="Tony Li"/>,
<t> They also wish to acknowledge Italo Busi and Chandrasekar Ramachandran for <contact fullname="James Guichard"/>, <contact fullname="Daniele
their insightful MPLS-RT Ceccarelli"/>, <contact fullname="Eric Vyncke"/>, <contact
review and constructive comments.</t> fullname="John Scudder"/>, <contact fullname="Gunter van de Velde"/>,
<t> Additionally, the authors would like to thank Dhruv Dhody for the English <contact fullname="Roman Danyliw"/>, <contact fullname="Warren
grammar review.</t> Kumari"/>, <contact fullname="Murray Kucherawy"/>, <contact
</section> fullname="Deb Cooley"/>, <contact fullname="Zaheduzzaman Sarker"/>, and
<contact fullname="Deboraha 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>
<section title="Contributors"> <contact fullname="Minxue Wang">
<t>Minxue Wang<br/>China Mobile<br/>Email: wangminxue@chinamobile.com</t> <organization>China Mobile</organization>
<t>Wen Ye<br/>China Mobile<br/>Email: yewen@chinamobile.com</t> <address>
</section> <email>wangminxue@chinamobile.com</email>
</address>
</contact>
</middle> <contact fullname="Wen Ye">
<organization>China Mobile</organization>
<address>
<email>yewen@chinamobile.com</email>
</address>
</contact>
<back> </section>
<references title="Normative References"> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<?rfc include="reference.RFC.2119"?> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<?rfc include="reference.RFC.8174"?> and let us know if any changes are needed. Updates of this nature typically
<?rfc include="reference.RFC.3031"?> result in more precise language, which is helpful for readers.
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.9017"?>
</references>
<references title="Informative References"> Note that our script did not flag any words in particular, but this should
<?rfc include="reference.RFC.4026"?> still be reviewed as a best practice.
<?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. 81 change blocks. 
635 lines changed or deleted 548 lines changed or added

This html diff was produced by rfcdiff 1.48.