rfc9088xml2.original.xml   rfc9088.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-isis-mpls-elc-13" ipr="trust200902">
<front>
<title abbrev="Signaling ELC and ERLD using IS-IS">Signaling Entropy Label
Capability and Entropy Readable Label Depth Using IS-IS</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Alibaba Inc</organization>
<address> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
category="std" consensus="true" docName="draft-ietf-isis-mpls-elc-13"
number="9088" ipr="trust200902" obsoletes="" updates="" xml:lang="en"
tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
version="3">
<email>xiaohu.xxh@alibaba-inc.com</email> <front>
<title abbrev="Signaling ELC and ERLD Using IS-IS">Signaling Entropy Label
Capability and Entropy Readable Label Depth Using IS-IS</title>
<seriesInfo name="RFC" value="9088"/>
<author fullname="Xiaohu Xu" initials="X." surname="Xu">
<organization>Capitalonline</organization>
<address>
<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> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<phone/> <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 88 skipping to change at line 63
<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 year="2020"/>
<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 IS-IS and BGP-LS.</t> capabilities using IS-IS 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>
Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels <t><xref target="RFC6790" format="default"/> describes a method to
(EL). It also introduces the concept of Entropy Label load-balance Multiprotocol Label Switching (MPLS) traffic flows using
Entropy Labels (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 IS-IS labels via link-state Interior Gateway Protocols (IGP) such as IS-IS
<xref target="RFC8667"/>. <xref target="RFC8667" format="default"/>. This document defines a
This draft defines a mechanism to signal the ELC using IS-IS. </t> mechanism to signal the ELC using IS-IS. </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" format="default"/>), it would be
(e.g., SR-MPLS <xref target="RFC8660"/>), useful for ingress LSRs to know each intermediate LSR's capability of
it would be useful for ingress LSRs to know each intermediate LSR's capabi reading the maximum label stack depth and performing EL-based
lity load-balancing. This capability, referred to as Entropy Readable Label
of reading the maximum label stack depth and performing EL-based load-bala Depth (ERLD) as defined in <xref target="RFC8662" format="default"/>,
ncing. may be used by ingress LSRs to determine the position of the EL label in
This capability, referred to as Entropy Readable Label Depth (ERLD) as the stack, and whether it's necessary to insert multiple ELs at
defined in <xref target="RFC8662"/>, may be used by ingress LSRs to determ different positions in the label stack. This document defines a
ine mechanism to signal the ERLD using IS-IS.</t>
the position of the EL label in the stack, and whether it's necessary to i
nsert
multiple ELs at different positions in the label stack. This document defi
nes
a mechanism to signal the ERLD using IS-IS.</t>
</section> </section>
<section anchor="Teminology" numbered="true" toc="default">
<name>Terminology</name>
<t>This memo makes use of the terms defined in <xref target="RFC6790" form
at="default"/>,
and <xref target="RFC8662" format="default"/>.</t>
<section anchor="Teminology" title="Terminology"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>This memo makes use of the terms defined in <xref target="RFC6790"/>, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
and <xref target="RFC8662"/>.</t> 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"
format="default"/> <xref target="RFC8174" format="default"/> when, and
only when, they appear in all capitals, as shown here.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all
capitals, as shown here.</t>
</section> </section>
<section anchor="ELC_ADV" title="Advertising ELC Using IS-IS"> <section anchor="ELC_ADV" numbered="true" toc="default">
<t>Even though ELC is a property of the node, in some cases it is advantag <name>Advertising ELC Using IS-IS</name>
eous to <t>Even though ELC is a property of the node, in some cases it is
associate and advertise the ELC with a prefix. In a multi-area network, advantageous to associate and advertise the ELC with a prefix. In a
routers may not know the identity of the prefix originator in a remote multi-area network, routers may not know the identity of the prefix
area, originator in a remote area or may not know the capabilities of such
or may not know the capabilities of such originator. Similarly, in a originator. Similarly, in a multi-domain network, the identity of the
multi-domain network, the identity of the prefix originator and its prefix originator and its capabilities may not be known to the ingress
capabilities may not be known to the ingress LSR.</t> LSR.</t>
<t> Bit 3 in the Prefix Attribute Flags <xref target="RFC7794 <t> Bit 3 in the Prefix Attribute Flags <xref target="RFC7794"
"/> is used as the format="default"/> is used as the ELC Flag (E-Flag), as shown in <xref
ELC Flag (E-flag), as shown in Figure 1. If a router has target="prefix-flags"/>. If a router has multiple interfaces, the router
multiple interfaces, <bcp14>MUST NOT</bcp14> announce the ELC for any local host prefixes
the router MUST NOT announce the ELC for any local host p unless all of its interfaces are capable of processing ELs. If a router
refixes unless all supports ELs on all of its interfaces, it <bcp14>SHOULD</bcp14> set the
of its interfaces are capable of processing ELs. If a rou ELC for every local host prefix it advertises in IS-IS.</t>
ter supports ELs on
all of its interfaces, it SHOULD set the ELC for every lo
cal host prefix
it advertises in IS-IS.</t>
<figure> <figure anchor="prefix-flags">
<artwork> <name> Prefix Attribute Flags </name>
<artwork name="" type="" align="left" alt="">
0 1 2 3 4 5 6 7... 0 1 2 3 4 5 6 7...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
|X|R|N|E| ... |X|R|N|E| ...
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
Figure 1: Prefix Attribute Flags </artwork>
E-flag: ELC Flag (Bit 3) - Set for local host prefix of the
originating node if it supports ELC on all interfaces.
</artwork>
</figure>
<t>The ELC signaling MUST be preserved when a router propagates a prefi
x
between ISIS levels <xref target="RFC5302"/>.
</t>
<t>When redistributing a prefix between two IS-IS protocol instances or r
edistributing
from another protocol to an IS-IS protocol instance, a router SHOULD prese
rve the
ELC signaling for that prefix if it exists. The exact mechanism used to ex
change ELC between
protocol instances running on an Autonomous System Boundary Router is outs
ide
of the scope of this document.</t>
</section> </figure>
<section anchor="ERLD_ADV" title="Advertising ERLD Using IS-IS"> <dl newline="true">
<dt>E-Flag:
</dt>
<dd>ELC Flag (Bit 3) - Set for local host prefix of the originating node if it
supports ELC on all interfaces.
</dd>
</dl>
<t>A new MSD-Type <xref target="RFC8491"/>, called ERLD-MSD, is defined to <t>The ELC signaling <bcp14>MUST</bcp14> be preserved when a router propag
advertise the ERLD <xref target="RFC8662"/> of a given router. A MSD-Type ates a prefix
code 2 between IS-IS levels <xref target="RFC5302" format="default"/>.
has been assigned by IANA for ERLD-MSD. The MSD-Value field is set to the </t>
ERLD in the <t>When redistributing a prefix between two IS-IS protocol instances or
range between 0 to 255. The scope of the advertisement depends on the appl redistributing from another protocol to an IS-IS protocol instance, a
ication. router <bcp14>SHOULD</bcp14> preserve the ELC signaling for that prefix
If a router has multiple interfaces with different capabilities of reading if it exists. The exact mechanism used to exchange ELC between protocol
the instances running on an Autonomous System Border Router is outside of
maximum label stack depth, the router MUST advertise the smallest value fo the scope of this document.</t>
und across
all its interfaces.</t>
</section>
<section anchor="ERLD_ADV" numbered="true" toc="default">
<name>Advertising ERLD Using IS-IS</name>
<t>A new MSD-Type <xref target="RFC8491" format="default"/>, called
ERLD-MSD, is defined to advertise the ERLD <xref target="RFC8662"
format="default"/> of a given router. An MSD-Type code 2 has been
assigned by IANA for ERLD-MSD. The MSD-Value field is set to the ERLD in
the range between 0 to 255. The scope of the advertisement depends on
the application. If a router has multiple interfaces with different
capabilities of reading the maximum label stack depth, the router
<bcp14>MUST</bcp14> advertise the smallest value found across all 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>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>
<t>If the ERLD-MSD type is received in the Link MSD sub-TLV,
<t>If the ERLD-MSD Type is received in the Link MSD Sub-TLV, it <bcp14>MUST</bcp14> be ignored.</t>
it MUST be ignored.</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 IS-IS extensions defined in this document can be advertised via
<t>The IS-IS 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>Bit 3 in the "Bit Values for Prefix Attribute Flags Sub-TLV" registr
<xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t> y has
been assigned to the ELC Flag. IANA has updated the registry to
<t>The ERLD-MSD is advertised using the Node MSD TLV as defined in reflect the name used in this document: ELC Flag (E-Flag).</li>
<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>- Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV registry h
as
been assigned to the ELC Flag. IANA is asked to update the registry to
reflect the name used in this document: ELC Flag (E-flag).</t>
<t>- Type 2 in the IGP MSD-Types registry has been assigned for the ERLD-M <li> Type 2 in the "IGP MSD-Types" registry has been assigned for the ER
SD. LD-MSD.
IANA is asked to update the registry to reflect the name used in this IANA has updated the registry to reflect the name used in this
document: ERLD-MSD.</t> document: ERLD-MSD.</li>
</list></t> </ul>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<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 IS-IS and BGP-LS. As such, the security considerations capabilities using IS-IS and BGP-LS. As such, the security
as described in <xref target="RFC7981"/>, <xref target="RFC7752"/>, considerations as described in <xref target="RFC7752"
<xref target="RFC7794"/>, <xref target="RFC8491"/>, <xref target="RFC8662"/>, format="default"/>, <xref target="RFC7794" format="default"/>, <xref
<xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/> target="RFC7981" format="default"/>, <xref target="RFC8491"
and <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/> are applicable t format="default"/>, <xref target="RFC8662" format="default"/>, <xref
o this document.</t> target="RFC8814" 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 MPLS traffic being discarded on the egress node.</t>
of the MPLS traffic
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 the ERLD value may lead to poor or no load-balancin g of the
MPLS traffic.</t> MPLS traffic.</t>
</section> </section>
<section anchor="CONTR" title="Contributors"> </middle>
<back>
<references>
<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.7981.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.5302.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.7794.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.8491.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8662.xml"/>
<t>The following people contributed to the content <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
of this document and should be considered as co-authors:</t> FC.8814.xml"/>
<t><figure> <reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
<artwork><![CDATA[ <front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Rout
ing</title>
Gunter Van de Velde (editor) <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
Nokia <organization />
Antwerp </author>
BE
Email: gunter.van_de_velde@nokia.com <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='edit
or'>
<organization />
</author>
Wim Henderickx <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
Nokia <organization />
Belgium </author>
Email: wim.henderickx@nokia.com <author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization />
</author>
Keyur Patel <author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
Arrcus <organization />
USA </author>
Email: keyur@arrcus.com <date month='August' year='2021' />
]]></artwork> </front>
</figure></t> <seriesInfo name="RFC" value="9085"/>
<seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>
</section> </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.8667.xml"/>
</references>
</references>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="Acknowledgements" numbered="false" toc="default">
<t>The authors would like to thank Yimin Shen, George Swallow, Acee <name>Acknowledgements</name>
Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene <t>The authors would like to thank <contact fullname="Yimin
Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their valuabl Shen"/>, <contact fullname="George Swallow"/>, <contact
e comments.</t> fullname="Acee Lindem"/>, <contact fullname="Les Ginsberg"/>,
<contact fullname="Ketan Talaulikar"/>, <contact fullname="Jeff
Tantsura"/>, <contact fullname="Bruno Decraene"/>, <contact
fullname="Carlos Pignataro"/>, <contact fullname="Wim Hendrickx"/>,
and <contact fullname="Gunter Van de Velde"/> for their valuable comments.
</t>
<!---->
</section> </section>
</middle> <section anchor="CONTR" numbered="false" toc="default">
<name>Contributors</name>
<back> <t>The following people contributed to the content
<references title="Normative References"> of this document and should be considered as coauthors:</t>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.7981"?>
<?rfc include="reference.RFC.6790"?>
<?rfc include="reference.RFC.5302"?>
<?rfc include="reference.RFC.7752"?>
<?rfc include="reference.RFC.7794"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8491"?>
<?rfc include="reference.RFC.8662"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?> <contact fullname=" Gunter Van de Velde (editor)">
<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.8667"?> <email>keyur@arrcus.com</email>
</address>
</contact>
</references> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 81 change blocks. 
265 lines changed or deleted 255 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/