rfc9089xml2.original.xml   rfc9089.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ospf-mpls-elc-15" ipr="trust200902">
<front>
<title abbrev="Signaling ELC and ERLD using OSPF">Signaling Entropy Label
Capability and Entropy Readable Label Depth Using OSPF</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
<organization>Alibaba Inc</organization>
<address>
<!--
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<country>UK</country> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
</postal> docName="draft-ietf-ospf-mpls-elc-15" number="9089" ipr="trust200902"
obsoletes="" updates="" submissionType="IETF" category="std"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
symRefs="true" sortRefs="true" version="3">
<phone>+44 7889 488 335</phone> <front>
<title abbrev="Signaling ELC and ERLD Using OSPF">Signaling Entropy Label
Capability and Entropy Readable Label Depth Using OSPF</title>
<seriesInfo name="RFC" value="9089"/>
<author fullname="Xiaohu Xu" initials="X." surname="Xu">
<organization>Capitalonline</organization>
<address>
<email>xiaohu.xxh@alibaba-inc.com</email> <email>xiaohu.xu@capitalonline.net</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Sriganesh Kini" initials="S." surname="Kini">
<author fullname="Sriganesh Kini" initials="S.K" surname="Kini">
<organization/> <organization/>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email>sriganeshkini@gmail.com</email> <email>sriganeshkini@gmail.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Peter Psenak" initials="P." surname="Psenak"> <author fullname="Peter Psenak" initials="P." surname="Psenak">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Eurovea Centre, Central 3</street> <extaddr>Eurovea Centre, Central 3</extaddr>
<street>Pribinova Street 10</street> <street>Pribinova Street 10</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>81109</code> <code>81109</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Brussels</city> <city>Brussels</city>
<region/> <region/>
<code/> <code/>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
skipping to change at line 107 skipping to change at line 56
<postal> <postal>
<street/> <street/>
<city>Brussels</city> <city>Brussels</city>
<region/> <region/>
<code/> <code/>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<author fullname="Stephane Litkowski" initials="S.L." surname="Litkowski">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>La Rigourdiere</street> <street>La Rigourdiere</street>
<city>Cesson Sevigne</city> <city>Cesson Sevigne</city>
<code/> <code/>
<country>France</country> <country>France</country>
</postal> </postal>
<email>slitkows@cisco.com</email> <email>slitkows@cisco.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Matthew Bocci" initials="M.B." surname="Bocci"> <author fullname="Matthew Bocci" initials="M." surname="Bocci">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>Shoppenhangers Road</street> <street>Aztec West Business Park</street>
<city>Bristol</city>
<city>Maidenhead, Berks</city> <extaddr>740 Waterside Drive</extaddr>
<code>BS32 4UF</code>
<code/> <country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>matthew.bocci@nokia.com</email> <email>matthew.bocci@nokia.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date/>
<area>Routing Area</area>
<workgroup>LSR Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword> <date year="2021" month="August"/>
<area>RTG</area>
<workgroup>LSR</workgroup>
<abstract> <abstract>
<t>Multiprotocol Label Switching (MPLS) has defined a mechanism to load-ba lance <t>Multiprotocol Label Switching (MPLS) has defined a mechanism to load-ba lance
traffic flows using Entropy Labels (EL). An ingress Label traffic flows using Entropy Labels (EL). An ingress Label
Switching Router (LSR) cannot insert ELs for packets going into a given Switching Router (LSR) cannot insert ELs for packets going into a given
Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the
capability to process ELs, referred to as the Entropy Label Capability capability to process ELs, referred to as the Entropy Label Capability
(ELC), on that LSP. In addition, it would be useful for ingress LSRs (ELC), on that LSP. In addition, it would be useful for ingress LSRs
to know each LSR's capability for reading the maximum label stack depth to know each LSR's capability for reading the maximum label stack depth
and performing EL-based load-balancing, referred to as Entropy Readable and performing EL-based load-balancing, referred to as Entropy Readable
Label Depth (ERLD). This document defines a mechanism to signal these two Label Depth (ERLD). This document defines a mechanism to signal these two
capabilities using OSPFv2 and OSPFv3 and BGP-LS.</t> capabilities using OSPFv2 and OSPFv3, and Border Gateway Protocol - Link
State (BGP-LS).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t><xref target="RFC6790"/> describes a method to load-balance <name>Introduction</name>
<t><xref target="RFC6790" format="default"/> describes a method to load-ba
lance
Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels
(EL). It also introduces the concept of Entropy Label (EL). It also introduces the concept of Entropy Label
Capability (ELC) and defines the signaling of this capability via MPLS Capability (ELC) and defines the signaling of this capability via MPLS
signaling protocols. Recently, mechanisms have been defined to signal signaling protocols. Recently, mechanisms have been defined to signal
labels via link-state Interior Gateway Protocols (IGP) such as OSPFv2 labels via link-state Interior Gateway Protocols (IGP) such as OSPFv2
<xref target="RFC8665"/> and OSPFv3 <xref target="RFC8666"/>. <xref target="RFC8665" format="default"/> and OSPFv3 <xref target="RFC8666
This draft defines a mechanism to signal the ELC using OSPFv2 and OSPFv3.< " format="default"/>.
/t> This document defines a mechanism to signal the ELC using OSPFv2 and OSPFv
3.</t>
<t>In cases where Segment Routing (SR) is used with the MPLS Data Plane <t>In cases where Segment Routing (SR) is used with the MPLS data plane
(e.g., SR-MPLS <xref target="RFC8660"/>), (e.g., SR-MPLS <xref target="RFC8660" format="default"/>), it would be
it would be useful for ingress LSRs to know each intermediate LSR's capabi useful for ingress LSRs to know each intermediate LSR's capability of
lity reading the maximum label stack depth and performing EL-based
of reading the maximum label stack depth and performing EL-based load-bala load-balancing. This capability, referred to as Entropy Readable Label
ncing. Depth (ERLD) as defined in <xref target="RFC8662" format="default"/>,
This capability, referred to as Entropy Readable Label Depth (ERLD) as may be used by ingress LSRs to determine the position of the EL label in
defined in <xref target="RFC8662"/>, may be the stack, and whether it is necessary to insert multiple ELs at
used by ingress LSRs to determine the position of the EL label in the stac different positions in the label stack. This document defines a
k, mechanism to signal the ERLD using OSPFv2 and OSPFv3.</t>
and whether it is necessary to insert multiple ELs at different positions
in the label stack. This document defines a mechanism to signal the ERLD u
sing
OSPFv2 and OSPFv3.</t>
</section> </section>
<section anchor="Teminology" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="Teminology" title="Terminology"> <t>This memo makes use of the terms defined in <xref target="RFC6790"
<t>This memo makes use of the terms defined in <xref target="RFC6790"/>, format="default"/> and <xref target="RFC8662" format="default"/>.</t>
and <xref target="RFC8662"/>.</t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
en, format="default"/> <xref target="RFC8174" format="default"/> when, and
they appear in all capitals, as shown here.</t> only when, they appear in all capitals, as shown here.</t>
<t>The key word OSPF is used throughout the document to refer to both OSPF v2 and <t>The key word OSPF is used throughout the document to refer to both OSPF v2 and
OSPFv3.</t> OSPFv3.</t>
</section> </section>
<section anchor="ELC_ADV" numbered="true" toc="default">
<section anchor="ELC_ADV" title="Advertising ELC Using OSPF"> <name>Advertising ELC Using OSPF</name>
<t>Even though ELC is a property of the node, in some cases it is advantag eous <t>Even though ELC is a property of the node, in some cases it is advantag eous
to associate and advertise the ELC with a prefix. In multi-area networks, to associate and advertise the ELC with a prefix. In multi-area networks,
routers may not know the identity of the prefix originator in a remote are routers may not know the identity of the prefix originator in a remote are
a, a
or may not know the capabilities of such originator. Similarly, in a multi or may not know the capabilities of such an originator. Similarly, in a mu
domain lti-domain
network, the identity of the prefix originator and its capabilities may no t be network, the identity of the prefix originator and its capabilities may no t be
known to the ingress LSR.</t> known to the ingress LSR.</t>
<t>If a router has multiple interfaces, the router <bcp14>MUST NOT</bcp14>
<t>If a router has multiple interfaces, the router MUST NOT announce ELC announce ELC
unless all of its interfaces are capable of processing ELs.</t> unless all of its interfaces are capable of processing ELs.</t>
<t>If the router supports ELs on all of its interfaces, it
<bcp14>SHOULD</bcp14> advertise the ELC with every local host prefix it
advertises in OSPF.</t>
<section anchor="Advertising_OSPFv2" numbered="true" toc="default">
<name>Advertising ELC Using OSPFv2</name>
<t><xref target="RFC7684" format="default"/> defines the OSPFv2
Extended Prefix TLV to advertise additional attributes associated with
a prefix. The OSPFv2 Extended Prefix TLV includes a one-octet Flags
field. A new flag in the Flags field is used to signal the ELC for the
prefix:
<t>If the router supports ELs on all of its interfaces, it SHOULD advertis </t>
e the <dl newline="true" spacing="normal">
ELC with every local host prefix it advertises in OSPF.</t>
<section anchor="Advertising_OSPFv2" title="Advertising ELC Using OSPFv2">
<t><xref target="RFC7684"/> defines the OSPFv2 Extended Prefix TLV to adve
rtise
additional attributes associated with a prefix. The OSPFv2 Extended Prefix
TLV includes a one-octet Flags field. A new flag in the Flags field is use
d
to signal the ELC for the prefix:
<list style="hanging">
<t>0x20 - E-Flag (ELC Flag): Set by the advertising router to
indicate that the prefix originator is capable of processing ELs.</t>
</list></t>
<t>The ELC signaling MUST be preserved when an OSPF Area Border Router (AB
R) distributes
information between areas. To do so, an ABR MUST originate an OSPFv2
Extended Prefix Opaque LSA <xref target="RFC7684"/> including the received
ELC setting.</t>
<t>When an OSPF Autonomous System Boundary Router (ASBR) redistributes a p <dt>0x20 - E-Flag (ELC Flag):</dt><dd> Set by the advertising router
refix to indicate that the prefix originator is capable of processing
from another instance of OSPF or from some other protocol, it SHOULD prese ELs.</dd>
rve </dl>
the ELC signaling for the prefix if it exists. To do so, an ASBR SHOULD or
iginate
an Extended Prefix Opaque LSA <xref target="RFC7684"/> including the ELC s
etting of the
redistributed prefix. The flooding scope of the Extended Prefix Opaque LSA
MUST
match the flooding scope of the LSA that an ASBR originates as a result of
the
redistribution. The exact mechanism used to exchange ELC between protocol
instances
on an ASBR is outside of the scope of this document.</t>
<t>The ELC signaling <bcp14>MUST</bcp14> be preserved when an OSPF
Area Border Router (ABR) distributes information between areas. To do
so, an ABR <bcp14>MUST</bcp14> originate an OSPFv2 Extended Prefix
Opaque Link State Advertisement (LSA) <xref target="RFC7684" format="def
ault"/> including the
received ELC setting.</t>
<t>When an OSPF Autonomous System Border Router (ASBR) redistributes
a prefix from another instance of OSPF or from some other protocol, it
<bcp14>SHOULD</bcp14> preserve the ELC signaling for the prefix if it
exists. To do so, an ASBR <bcp14>SHOULD</bcp14> originate an Extended
Prefix Opaque LSA <xref target="RFC7684" format="default"/> including
the ELC setting of the redistributed prefix. The flooding scope of the
Extended Prefix Opaque LSA <bcp14>MUST</bcp14> match the flooding
scope of the LSA that an ASBR originates as a result of the
redistribution. The exact mechanism used to exchange ELC between
protocol instances on an ASBR is outside of the scope of this
document.</t>
</section> </section>
<section anchor="Advertising_OSPFv3" numbered="true" toc="default">
<name>Advertising ELC Using OSPFv3</name>
<t><xref target="RFC5340" format="default"/> defines the OSPFv3
PrefixOptions field to indicate capabilities associated with a
prefix. A new bit in the OSPFv3 PrefixOptions field is used to signal th
e
ELC for the prefix:
</t>
<section anchor="Advertising_OSPFv3" title="Advertising ELC Using OSPFv3"> <dl newline="true" spacing="normal">
<t><xref target="RFC5340"/> defines the OSPFv3 PrefixOptions field to indi
cate
capabilities associated with a prefix. A new bit in the OSPFv3 PrefixOptio
ns is used
to signal the ELC for the prefix:
<list style="hanging">
<t>0x40 - E-Flag (ELC Flag): Set by the advertising router to
indicate that the prefix originator is capable of processing ELs.</t>
<t>The ELC signaling MUST be preserved when an OSPFv3 Area Border Router ( <dt> 0x40 - E-Flag (ELC Flag):</dt><dd> Set by the advertising router t
ABR) o
distributes information between areas. The setting of the ELC Flag in indicate that the prefix originator is capable of processing ELs.</dd>
the Inter-Area-Prefix-LSA <xref target="RFC5340"/> or in the Inter-Area-Pr </dl>
efix TLV
<xref target="RFC8362"/>, generated by an ABR, MUST be the same as the val
ue the ELC Flag
associated with the prefix in the source area.</t>
<t>When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a <t>The ELC signaling <bcp14>MUST</bcp14> be preserved when an OSPFv3
prefix Area Border Router (ABR) distributes information between areas. The
from another instance of OSPFv3 or from some other protocol, it SHOULD pre setting of the ELC Flag in the Inter-Area-Prefix-LSA <xref
serve target="RFC5340" format="default"/> or in the Inter-Area-Prefix TLV
the ELC signaling for the prefix if it exists. The setting of the ELC Flag <xref target="RFC8362" format="default"/>, generated by an ABR,
in <bcp14>MUST</bcp14> be the same as the value the ELC Flag associated
the AS-External-LSA, NSSA-LSA <xref target="RFC5340"/> or in the External- with the prefix in the source area.</t>
Prefix TLV
<xref target="RFC8362"/>, generated by an ASBR, MUST be the same as the va
lue of the
ELC Flag associated with the prefix in the source domain. The exac
t mechanism
used to exchange ELC between protocol instances on the ASBR is outside of
the scope
of this document.</t>
</list></t> <t>When an OSPFv3 Autonomous System Border Router (ASBR)
redistributes a prefix from another instance of OSPFv3 or from some
other protocol, it <bcp14>SHOULD</bcp14> preserve the ELC signaling
for the prefix if it exists. The setting of the ELC Flag in the
AS-External-LSA, Not-So-Stubby Area LSA (NSSA-LSA) <xref target="RFC53
40" format="default"/>,
or in the External-Prefix TLV <xref target="RFC8362"
format="default"/>, generated by an ASBR, <bcp14>MUST</bcp14> be the
same as the value of the ELC Flag associated with the prefix in the
source domain. The exact mechanism used to exchange ELC between
protocol instances on the ASBR is outside of the scope of this
document.</t>
</section> </section>
</section> </section>
<section anchor="ERLD_ADV" numbered="true" toc="default">
<section anchor="ERLD_ADV" title="Advertising ERLD Using OSPF"> <name>Advertising ERLD Using OSPF</name>
<t>The ERLD is advertised in a Node Maximum SID Depth (MSD) TLV <xref
<t>The ERLD is advertised in a Node MSD TLV [RFC8476] using the ERLD-MSD target="RFC8476"/> using the ERLD-MSD type defined in <xref
type defined in <xref target="I-D.ietf-isis-mpls-elc"/>.</t> target="RFC9088" format="default"/>.</t>
<t>If a router has multiple interfaces with different capabilities of
<t>If a router has multiple interfaces with different capabilities of read reading the maximum label stack depth, the router <bcp14>MUST</bcp14>
ing the advertise the smallest value found across all of its interfaces.</t>
maximum label stack depth, the router MUST advertise the smallest value fo
und
across all of its interfaces.</t>
<t>The absence of ERLD-MSD advertisements indicates only that the advertis ing <t>The absence of ERLD-MSD advertisements indicates only that the advertis ing
node does not support advertisement of this capability.</t> node does not support advertisement of this capability.</t>
<t>When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD sub
<t>When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub -TLV
-TLV <xref target="RFC8476" format="default"/>, it <bcp14>MUST</bcp14> be ignor
<xref target="RFC8476"/>, it MUST be ignored.</t> ed.</t>
<t>The considerations for advertising the ERLD are specified in <t>The considerations for advertising the ERLD are specified in
<xref target="RFC8662"/>.</t> <xref target="RFC8662" format="default"/>.</t>
</section> </section>
<section anchor="BGPLS" numbered="true" toc="default">
<section anchor="BGPLS" title="Signaling ELC and ERLD in BGP-LS"> <name>Signaling ELC and ERLD in BGP-LS</name>
<t>The OSPF extensions defined in this document can be advertised via
<t>The OSPF extensions defined in this document can be advertised via BGP-LS (distribution of Link-State and TE information using BGP) <xref target
BGP-LS (Distribution of Link-State and TE Information Using BGP) <xref target ="RFC7752" format="default"/>
="RFC7752"/>
using existing BGP-LS TLVs.</t> using existing BGP-LS TLVs.</t>
<t>The ELC is advertised using the Prefix Attribute Flags TLV as defined i
n
<xref target="RFC9085" format="default"/>.</t>
<t>The ERLD-MSD is advertised using the Node MSD TLV as defined in
<xref target="RFC8814" format="default"/>.</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has completed the following actions for this document:
</t>
<ul>
<t>The ELC is advertised using the Prefix Attribute Flags TLV as defined in <li> Flag 0x20 in the "OSPFv2 Extended Prefix TLV Flags" registry has be
<xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t> en
allocated to the E-Flag (ELC Flag).</li>
<t>The ERLD-MSD is advertised using the Node MSD TLV as defined in
<xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>Early allocation has been done by IANA for this document as follows:
<list style="hanging">
<t>- Flag 0x20 in the OSPFv2 Extended Prefix TLV Flags registry has been
allocated by IANA to the E-Flag (ELC Flag).</t>
<t>- Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
allocated by IANA to the E-Flag (ELC Flag).</t>
</list></t>
<li> Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
allocated to the E-Flag (ELC Flag).</li>
</ul>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document specifies the ability to advertise additional node <t>This document specifies the ability to advertise additional node
capabilities using OSPF and BGP-LS. As such, the security considerations capabilities using OSPF and BGP-LS. As such, the security
as described in <xref target="RFC5340"/>, <xref target="RFC7770"/>, <xref tar considerations as described in <xref target="RFC5340"
get="RFC7752"/>, format="default"/>, <xref target="RFC7684" format="default"/>, <xref
<xref target="RFC7684"/>, <xref target="RFC8476"/>, <xref target="RFC8662"/>, target="RFC7752" format="default"/>, <xref target="RFC7770"
<xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/> format="default"/>, <xref target="RFC8476" format="default"/>, <xref
and <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/> are applicable t target="RFC8662" format="default"/>, <xref target="RFC8814"
o this document.</t> format="default"/>, and <xref target="RFC9085" format="default"/> are
applicable to this document.</t>
<t>Incorrectly setting the E flag during origination, propagation or redis <t>Incorrectly setting the E-Flag during origination, propagation, or
tribution redistribution may lead to poor or no load-balancing of the MPLS traffic
may lead to poor or no load-balancing of the MPLS traffic or black-holing or to the MPLS traffic being discarded on the egress node.
of the MPLS traffic </t>
on the egress node.</t>
<t>Incorrectly setting of the ERLD value may lead to poor or no load-balan cing of the <t>Incorrectly setting of the ERLD value may lead to poor or no load-balan cing of the
MPLS traffic.</t> MPLS traffic.</t>
</section> </section>
<section anchor="CONTR" title="Contributors"> </middle>
<back>
<t>The following people contributed to the content <references>
of this document and should be considered as co-authors:</t> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6790.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7770.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7684.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8476.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8662.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8362.xml"/>
<t><figure> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
<artwork><![CDATA[ RFC.8814.xml"/>
Gunter Van de Velde (editor) <reference anchor='RFC9088' target='https://www.rfc-editor.org/info/rfc9088'>
Nokia <front>
Antwerp <title>Signaling Entropy Label Capability and Entropy Readable Label Depth U
BE sing IS-IS</title>
Email: gunter.van_de_velde@nokia.com <author initials='X' surname='Xu' fullname='Xiaohu Xu'>
<organization />
</author>
Wim Henderickx <author initials='S' surname='Kini' fullname='Sriganesh Kini'>
Nokia <organization />
Belgium </author>
Email: wim.henderickx@nokia.com <author initials='P' surname='Psenak' fullname='Peter Psenak'>
<organization />
</author>
Keyur Patel <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
Arrcus <organization />
USA </author>
Email: keyur@arrcus.com <author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
<organization />
</author>
]]></artwork> <author initials='M' surname='Bocci' fullname='Matthew Bocci'>
</figure></t> <organization />
</author>
</section> <date month='August' year='2021' />
<section anchor="Acknowledgements" title="Acknowledgements"> </front>
<t>The authors would like to thank Yimin Shen, George Swallow, Acee <seriesInfo name="RFC" value="9088"/>
Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno Decraene <seriesInfo name="DOI" value="10.17487/RFC9088"/>
and Carlos Pignataro for their valuable comments.</t> </reference>
<!----> <reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
</section> <front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Rout
ing</title>
</middle> <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization />
</author>
<back> <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='edit
<references title="Normative References"> or'>
<?rfc include="reference.RFC.2119"?> <organization />
</author>
<?rfc include="reference.RFC.6790"?> <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization />
</author>
<?rfc include="reference.RFC.7770"?> <author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization />
</author>
<?rfc include="reference.RFC.7684"?> <author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
<organization />
</author>
<?rfc include="reference.RFC.5340"?> <date month='August' year='2021' />
<?rfc include="reference.RFC.7752"?> </front>
<seriesInfo name="RFC" value="9085"/>
<seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>
<?rfc include="reference.RFC.8174"?> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8660.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8666.xml"/>
</references>
</references>
<?rfc include="reference.RFC.8476"?> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Yimin Shen"/>,
<contact fullname="George Swallow"/>, <contact fullname="Acee Lindem"/>,
<contact fullname="Les Ginsberg"/>, <contact fullname="Ketan
Talaulikar"/>, <contact fullname="Jeff Tantsura"/> , <contact
fullname="Bruno Decraene"/>, and <contact fullname="Carlos Pignataro"/>
for their valuable comments.</t>
<?rfc include="reference.RFC.8662"?> </section>
<?rfc include="reference.RFC.8362"?> <section anchor="CONTR" numbered="false" toc="default">
<name>Contributors</name>
<t>The following people contributed to the content
of this document and should be considered coauthors:</t>
<?rfc include="reference.I-D.ietf-isis-mpls-elc"?> <contact fullname="Gunter Van de Velde (editor)">
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?> <organization>Nokia</organization>
<address>
<postal>
<city>Antwerp</city>
<country>Belgium</country>
</postal>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-msd"?> <email>gunter.van_de_velde@nokia.com</email>
</address>
</contact>
</references> <contact fullname="Wim Henderickx">
<organization>Nokia</organization>
<address>
<postal>
<country>Belgium</country>
</postal>
<references title="Informative References"> <email>wim.henderickx@nokia.com</email>
</address>
</contact>
<?rfc include="reference.RFC.8660"?> <contact fullname="Keyur Patel">
<organization>Arrcus</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<?rfc include="reference.RFC.8665"?> <email>keyur@arrcus.com</email>
</address>
</contact>
<?rfc include="reference.RFC.8666"?> </section>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 96 change blocks. 
327 lines changed or deleted 316 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/