rfc8661xml2.original.xml   rfc8661.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
nsus="true" docName="draft-ietf-spring-segment-routing-ldp-interop-15" indexIncl
]> ude="true" ipr="trust200902" number="8661" prepTime="2019-12-04T20:41:37" script
<rfc number="8661" category="std" consensus="yes" s="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="
submissionType="IETF" ipr="trust200902"> 3" tocInclude="true" xml:lang="en">
<?rfc compact="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing
-ldp-interop-15" rel="prev"/>
<?rfc text-list-symbols="-o*+"?> <link href="https://dx.doi.org/10.17487/rfc8661" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="Segment Routing and LDP">Segment Routing Interworking with <title abbrev="Segment Routing and LDP">Segment Routing MPLS Interworking wi
LDP</title> th LDP</title>
<seriesInfo name="RFC" value="8661" stream="IETF"/>
<author fullname="Ahmed Bashandy" initials="A." role="editor" <author fullname="Ahmed Bashandy" initials="A." role="editor" surname="Basha
surname="Bashandy"> ndy">
<organization>Individual</organization> <organization showOnFrontPage="true">Individual</organization>
<address> <address>
<postal> <postal>
<street>United States of America</street> <street>United States of America</street>
</postal> </postal>
<email>abashandy.ietf@gmail.com</email> <email>abashandy.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." role="editor" surname="Fi
<author fullname="Clarence Filsfils" initials="C." role="editor" lsfils">
surname="Filsfils"> <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Brussels</street> <street>Brussels</street>
<street>Belgium</street> <street>Belgium</street>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc.</organization> <organization showOnFrontPage="true">Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Italy</street> <street>Italy</street>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> <author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization> <organization showOnFrontPage="true">Orange</organization>
<address> <address>
<postal> <postal>
<street>France</street> <street>France</street>
</postal> </postal>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski"> <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization>Orange</organization> <organization showOnFrontPage="true">Orange</organization>
<address> <address>
<postal> <postal>
<street>France</street> <street>France</street>
</postal> </postal>
<email>slitkows.ietf@gmail.com</email>
<email>stephane.litkowski@orange.com</email>
</address> </address>
</author> </author>
<date month="12" year="2019"/>
<date month="September" year="2019"/> <keyword>SR-MPLS</keyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">A Segment Routing (SR) node steers a packet thr
<t>A Segment Routing (SR) node steers a packet through a controlled set ough a controlled set
of instructions, called segments, by prepending the packet with an SR of instructions, called segments, by prepending the packet with an SR
header. A segment can represent any instruction, topological or header. A segment can represent any instruction, topological or
service based. SR allows enforcing a flow through any topological path service based. SR allows enforcing a flow through any topological path
while maintaining per-flow state only at the ingress node to the SR while maintaining per-flow state only at the ingress node to the SR
domain.</t> domain.</t>
<t pn="section-abstract-2">The Segment Routing architecture can be directl
<t>The Segment Routing architecture can be directly applied to the MPLS y applied to the MPLS
data plane with no change in the forwarding plane. This document data plane with no change in the forwarding plane. This document
describes how Segment Routing operates in a network where LDP is describes how Segment Routing MPLS operates in a network where LDP is
deployed and in the case where SR-capable and non-SR-capable nodes deployed and in the case where SR-capable and non-SR-capable nodes
coexist.</t> coexist.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8661" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-requirements-
language">Requirements Language</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-sr-ldp-ships-in-the-night
-c">SR-LDP Ships-in-the-Night Coexistence</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-mpls2mpls-mpl
s2ip-and-ip2mp">MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-sr-and-ldp-interworking">
SR and LDP Interworking</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derive
dContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-ldp-to-sr">LD
P to SR</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.1.2">
<li pn="section-toc.1-1.3.2.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.1.2.1.1"><xre
f derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-l
dp-to-sr-behavior">LDP to SR Behavior</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.2">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derive
dContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sr-to-ldp">SR
to LDP</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.1.1"><xre
f derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-s
egment-routing-mapping-ser">Segment Routing Mapping Server (SRMS)</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.2.1"><xre
f derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-s
r-to-ldp-behavior">SR to LDP Behavior</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.3">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.3.1"><xre
f derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2
.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-i
nteroperability-of-multipl">Interoperability of Multiple SRMSes and Prefix-SID A
dvertisements</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-sr-ldp-interworking-use-c
as">SR-LDP Interworking Use Cases</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derive
dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sr-protection
-of-ldp-based-">SR Protection of LDP-Based Traffic</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derive
dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-eliminating-t
argeted-ldp-se">Eliminating Targeted LDP Sessions</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derive
dContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-guaranteed-fr
r-coverage">Guaranteed FRR Coverage</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derive
dContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-inter-as-opti
on-c-carriers-">Inter-AS Option C, Carrier's Carrier</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-manageability-considerati
on">Manageability Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derive
dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sr-and-ldp-co
existence">SR and LDP Coexistence</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derive
dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-data-plane-ve
rification">Data-Plane Verification</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-security-considerations">
Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-references">References</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derive
dContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
erences">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derive
dContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
eferences">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-migrati
on-from-ldp-to-sr">Migration from LDP to SR</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
Content="" format="title" sectionFormat="of" target="name-acknowledgements">Ackn
owledgements</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
Content="" format="title" sectionFormat="of" target="name-contributors">Contribu
tors</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
hors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="section-1" title="Introduction"> <section anchor="sec-1" numbered="true" toc="include" removeInRFC="false" pn
<t>Segment Routing, as described in <xref ="section-1">
target="RFC8402"/>, can be used on top of the <name slugifiedName="name-introduction">Introduction</name>
MPLS data plane without any modification as described in <xref <t pn="section-1-1">Segment Routing, as described in <xref target="RFC8402
target="RFC8660"/>.</t> " format="default" sectionFormat="of" derivedContent="RFC8402"/>, can be used on
top of the
<t>Segment Routing control plane can coexist with current label MPLS data plane without any modification as described in <xref target="RFC
distribution protocols such as LDP <xref target="RFC5036"/>.</t> 8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>.</t>
<t pn="section-1-2">Segment Routing control plane can coexist with current
<t>This document outlines the mechanisms through which SR interworks label
distribution protocols such as LDP <xref target="RFC5036" format="default"
sectionFormat="of" derivedContent="RFC5036"/>.</t>
<t pn="section-1-3">This document outlines the mechanisms through which SR
interworks
with LDP in cases where a mix of SR-capable and non-SR-capable routers with LDP in cases where a mix of SR-capable and non-SR-capable routers
coexist within the same network and more precisely in the same routing coexist within the same network and more precisely in the same routing
domain.</t> domain.</t>
<t pn="section-1-4"><xref target="sec-2" format="default" sectionFormat="o
<t><xref target="section-2"/> describes the coexistence of SR with f" derivedContent="Section 2"/> describes the coexistence of SR with
other MPLS control-plane protocols. <xref target="section-4"/> documents other MPLS control-plane protocols. <xref target="sec-4" format="default"
sectionFormat="of" derivedContent="Section 3"/> documents
the interworking between SR and LDP in the case of nonhomogeneous the interworking between SR and LDP in the case of nonhomogeneous
deployment. <xref target="section-5"/> describes how a partial SR deployment. <xref target="sec-5" format="default" sectionFormat="of" deriv edContent="Section 4"/> describes how a partial SR
deployment can be used to provide SR benefits to LDP-based traffic deployment can be used to provide SR benefits to LDP-based traffic
including a possible application of SR in the context of interdomain including a possible application of SR in the context of interdomain
MPLS use cases. <xref target="Appendix-A"/> documents a method to MPLS use cases. <xref target="Appendix-A" format="default" sectionFormat=" of" derivedContent="Appendix A"/> documents a method to
migrate from LDP to SR-based MPLS tunneling.</t> migrate from LDP to SR-based MPLS tunneling.</t>
<t pn="section-1-5">Typically, an implementation will allow an operator to
<t>Typically, an implementation will allow an operator to select select
(through configuration) which of the described modes of SR and LDP (through configuration) which of the described modes of SR and LDP
coexistence to use.</t> coexistence to use.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1
<section title="Requirements Language"> ">
<name slugifiedName="name-requirements-language">Requirements Language</
<t> name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t pn="section-1.1-1">
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here. when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-2" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="section-2" title="SR/LDP Ships-in-the-Night Coexistence"> ="section-2">
<t>"MPLS Control-Plane Client (MCC)" refers to any control-plane <name slugifiedName="name-sr-ldp-ships-in-the-night-c">SR-LDP Ships-in-the
-Night Coexistence</name>
<t pn="section-2-1">"MPLS Control-Plane Client (MCC)" refers to any contro
l-plane
protocol installing forwarding entries in the MPLS data plane. SR, LDP protocol installing forwarding entries in the MPLS data plane. SR, LDP
<xref target="RFC5036"/>, RSVP-TE <xref target="RFC3209"/>, BGP <xref <xref target="RFC5036" format="default" sectionFormat="of" derivedContent=
target="RFC8277"/>, etc., are examples of MCCs.</t> "RFC5036"/>, RSVP-TE <xref target="RFC3209" format="default" sectionFormat="of"
derivedContent="RFC3209"/>, BGP <xref target="RFC8277" format="default" sectionF
<t>An MCC, operating at node N, must ensure that the incoming label it ormat="of" derivedContent="RFC8277"/>, etc., are examples of MCCs.</t>
installs in the MPLS data plane of node N has been uniquely allocated to <t pn="section-2-2">An MCC, operating at Node N, must ensure that the inco
ming label it
installs in the MPLS data plane of Node N has been uniquely allocated to
itself.</t> itself.</t>
<t pn="section-2-3">Segment Routing makes use of the Segment Routing Globa
<t>Segment Routing makes use of the Segment Routing Global Block (SRGB, l Block (SRGB,
as defined in <xref target="RFC8402"/>) for the as defined in <xref target="RFC8402" format="default" sectionFormat="of" d
erivedContent="RFC8402"/>) for the
label allocation. The use of the SRGB allows SR to coexist with any label allocation. The use of the SRGB allows SR to coexist with any
other MCC.</t> other MCC.</t>
<t pn="section-2-4">This is clearly the case for the adjacency segment: it
<t>This is clearly the case for the adjacency segment: it is a local is a local
label allocated by the label manager, as is the case for for any MCC.</t> label allocated by the label manager, as is the case for any MCC.</t>
<t pn="section-2-5">This is clearly the case for the prefix segment: the l
<t>This is clearly the case for the prefix segment: the label manager abel manager
allocates the SRGB set of labels to the SR MCC client, and the operator allocates the SRGB set of labels to the SR MCC client, and the operator
ensures the unique allocation of each global prefix segment or label ensures the unique allocation of each global prefix segment or label
within the allocated SRGB set.</t> within the allocated SRGB set.</t>
<t pn="section-2-6">Note that this static label-allocation capability of t
<t>Note that this static label-allocation capability of the label he label
manager has existed for many years across several vendors and is manager has existed for many years across several vendors and is
therefore not new. Furthermore, note that the label manager's ability to therefore not new. Furthermore, note that the label manager's ability to
statically allocate a range of labels to a specific application is not statically allocate a range of labels to a specific application is not
new either. This is required for MPLS-TP operation. In this case, the new either. This is required for MPLS-TP operation. In this case, the
range is reserved by the label manager, and it is the MPLS-TP <xref range is reserved by the label manager, and it is the MPLS-TP <xref target
target="RFC5960"/> Network Management System (acting as an MCC) that ensur ="RFC5960" format="default" sectionFormat="of" derivedContent="RFC5960"/> Networ
es the unique k Management System (acting as an MCC) that ensures the unique
allocation of any label within the allocated range and the creation of allocation of any label within the allocated range and the creation of
the related MPLS forwarding entry.</t> the related MPLS forwarding entry.</t>
<t pn="section-2-7">Let us illustrate an example of ship-in-the-night (SIN
<t><list hangIndent="-1" style="hanging"> ) coexistence.
<t </t>
hangText="Let us illustrate an example of ship-in-the-night (SIN) coex <figure anchor="ref-sin-coexistence" align="left" suppress-title="false" p
istence."><vspace n="figure-1">
blankLines="0"/></t> <name slugifiedName="name-sin-coexistence">SIN Coexistence</name>
</list></t> <artwork name="" type="" align="left" alt="" pn="section-2-8.1">
<figure anchor="ref-sin-coexistence" title="SIN Coexistence">
<artwork><![CDATA[
PE2 PE4 PE2 PE4
\ / \ /
PE1----A----B---C---PE3 PE1----A----B---C---PE3
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-2-9">The EVEN VPN service is supported by PE2 and PE4 while
<t>The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN the ODD VPN
service is supported by PE1 and PE3. The operator wants to tunnel the service is supported by PE1 and PE3. The operator wants to tunnel the
ODD service via LDP and the EVEN service via SR.</t> ODD service via LDP and the EVEN service via SR.</t>
<t pn="section-2-10">This can be achieved in the following manner:
<t><list hangIndent="3" style="hanging"> </t>
<t hangText="This can be achieved in the following manner:"><vspace <ul bare="false" empty="false" spacing="normal" pn="section-2-11">
blankLines="1"/> The operator configures PE1, PE2, PE3, and PE4 with <li pn="section-2-11.1">The operator configures PE1, PE2, PE3, and PE4 w
respective loopbacks 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, ith respective loopbacks
and 192.0.2.204/32. These PEs advertised their VPN routes with next-ho 192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, and 192.0.2.204/32. These PEs
p set on their respective loopback address. <vspace advertised their VPN routes with next hop set on their respective loopback
blankLines="1"/> The operator configures A, B, C with respective address.
loopbacks 192.0.2.1/32, 192.0.2.2/32, 192.0.2.3/32. <vspace </li>
blankLines="1"/> The operator configures PE2, A, B, C, and PE4 with <li pn="section-2-11.2">The operator configures A, B, C with respective
SRGB [100, 300]. <vspace blankLines="1"/> The operator attaches the loopbacks 192.0.2.1/32,
respective Node Segment Identifiers (Node-SIDs, as defined in <xref 192.0.2.2/32, 192.0.2.3/32.
target="RFC8402"/>), 202, 101, 102, 103, and </li>
204, to the loopbacks of nodes PE2, A, B, C, and PE4. The Node-SIDs <li pn="section-2-11.3">The operator configures PE2, A, B, C, and PE4 wi
are configured to request Penultimate Hop Popping. <vspace th SRGB [100, 300].
blankLines="1"/> PE1, A, B, C, and PE3 are LDP capable. <vspace </li>
blankLines="1"/> PE1 and PE3 are not SR capable.</t> <li pn="section-2-11.4">The operator attaches the respective Node Segmen
</list></t> t Identifiers (Node SIDs,
as defined in <xref target="RFC8402" format="default" sectionFormat="of" derived
<t>PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN Content="RFC8402"/>), 202, 101, 102, 103,
and 204, to the loopbacks of nodes PE2, A, B, C, and PE4. The Node SIDs are
configured to request Penultimate Hop Popping.
</li>
<li pn="section-2-11.5">PE1, A, B, C, and PE3 are LDP capable.
</li>
<li pn="section-2-11.6">PE1 and PE3 are not SR capable.
</li>
</ul>
<t pn="section-2-12">PE3 sends an ODD VPN route to PE1 with next-hop 192.0
.2.203 and VPN
label 10001.</t> label 10001.</t>
<t pn="section-2-13">From an LDP viewpoint, PE1 received an LDP label bind
<t>From an LDP viewpoint, PE1 received an LDP label binding (1037) for a ing (1037) for a
forwarding equivalence class (FEC) 192.0.2.203/32 from its next-hop A; A Forwarding Equivalence Class (FEC) 192.0.2.203/32 from its next-hop A; A
received an LDP label binding (2048) for that FEC from its next-hop B; B received an LDP label binding (2048) for that FEC from its next-hop B; B
received an LDP label binding (3059) for that FEC from its next-hop C; received an LDP label binding (3059) for that FEC from its next-hop C;
and C received implicit-null LDP binding from its next-hop PE3.</t> and C received implicit NULL LDP binding from its next-hop PE3.</t>
<t pn="section-2-14">As a result, PE1 sends its traffic to the ODD service
<t>As a result, PE1 sends its traffic to the ODD service route route
advertised by PE3 to next-hop A with two labels: the top label is 1037 advertised by PE3 to next-hop A with two labels: the top label is 1037
and the bottom label is 10001. Node A swaps 1037 with 2048 and forwards and the bottom label is 10001. Node A swaps 1037 with 2048 and forwards
to B; B swaps 2048 with 3059 and forwards to C; C pops 3059 and forwards to B; B swaps 2048 with 3059 and forwards to C; C pops 3059 and forwards
to PE3.</t> to PE3.</t>
<t pn="section-2-15">PE4 sends an EVEN VPN route to PE2 with next-hop 192.
<t>PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN 0.2.204 and VPN
label 10002.</t> label 10002.</t>
<t pn="section-2-16">From an SR viewpoint, PE2 maps the IGP route 192.0.2.
<t>From an SR viewpoint, PE2 maps the IGP route 192.0.2.204/32 onto 204/32 onto
Node-SID 204; node A swaps 204 with 204 and forwards to B; B swaps 204 Node SID 204; Node A swaps 204 with 204 and forwards to B; B swaps 204
with 204 and forwards to C; and C pops 204 and forwards to PE4.</t> with 204 and forwards to C; and C pops 204 and forwards to PE4.</t>
<t pn="section-2-17">As a result, PE2 sends its traffic to the VPN service
<t>As a result, PE2 sends its traffic to the VPN service route route
advertised by PE4 to next-hop A with two labels: the top label is 204 advertised by PE4 to next-hop A with two labels: the top label is 204
and the bottom label is 10002. Node A swaps 204 with 204 and forwards to and the bottom label is 10002. Node A swaps 204 with 204 and forwards to
B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to
PE4.</t> PE4.</t>
<t pn="section-2-18">The two modes of MPLS tunneling coexist.
<t><list hangIndent="3" style="hanging"> </t>
<t hangText="The two modes of MPLS tunneling coexist."><vspace <ul empty="false" bare="false" spacing="normal" pn="section-2-19">
blankLines="1"/> The ODD service is tunneled from PE1 to PE3 through <li pn="section-2-19.1">The ODD service is tunneled from PE1 to PE3 thro
a continuous LDP LSP traversing A, B, and C. <vspace blankLines="1"/> ugh a continuous LDP LSP
The EVEN service is tunneled from PE2 to PE4 through a continuous SR traversing A, B, and C.
node segment traversing A, B, and C.</t> </li>
</list></t> <li pn="section-2-19.2">The EVEN service is tunneled from PE2 to PE4 thr
ough a continuous SR node
<section anchor="section-2.1" segment traversing A, B, and C.
title="MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence"> </li>
<t>MPLS2MPLS refers to the forwarding behavior where a router receives </ul>
<section anchor="sec-2.1" numbered="true" toc="include" removeInRFC="false
" pn="section-2.1">
<name slugifiedName="name-mpls2mpls-mpls2ip-and-ip2mp">MPLS2MPLS, MPLS2I
P, and IP2MPLS Coexistence</name>
<t pn="section-2.1-1">MPLS2MPLS refers to the forwarding behavior where
a router receives
a labeled packet and switches it out as a labeled packet. Several a labeled packet and switches it out as a labeled packet. Several
MPLS2MPLS entries may be installed in the data plane for the same MPLS2MPLS entries may be installed in the data plane for the same
prefix.</t> prefix.</t>
<t pn="section-2.1-2">Let us examine A's MPLS forwarding table as an exa
<t><list hangIndent="3" style="hanging"> mple:</t>
<t <ul empty="true" bare="false" spacing="normal" pn="section-2.1-3">
hangText="Let us examine A's MPLS forwarding table as an example:">< <li pn="section-2.1-3.1">
vspace <t pn="section-2.1-3.1.1">Incoming label: 1037</t>
blankLines="1"/> Incoming label: 1037</t> <ul empty="false" bare="false" spacing="normal" pn="section-2.1-3.1.
</list></t> 2">
<li pn="section-2.1-3.1.2.1">Outgoing label: 2048</li>
<figure> <li pn="section-2.1-3.1.2.2">Outgoing next hop: B</li>
<artwork><![CDATA[ </ul>
- outgoing label: 2048 <t pn="section-2.1-3.1.3">Note: This entry is programmed by LDP for
- outgoing next-hop: B 192.0.2.203/32.</t>
Note: this entry is programmed by LDP for 192.0.2.203/32 </li>
</ul>
Incoming label: 203 <ul empty="true" bare="false" spacing="normal" pn="section-2.1-4">
<li pn="section-2.1-4.1">
- outgoing label: 203 <t pn="section-2.1-4.1.1">Incoming label: 203</t>
- outgoing next-hop: B <ul empty="false" bare="false" spacing="normal" pn="section-2.1-4.1.
Note: this entry is programmed by SR for 192.0.2.203/32 2">
]]></artwork> <li pn="section-2.1-4.1.2.1">Outgoing label: 203</li>
</figure> <li pn="section-2.1-4.1.2.2">Outgoing next hop: B</li>
</ul>
<t>These two entries can coexist because their incoming label is <t pn="section-2.1-4.1.3">Note: This entry is programmed by SR for 1
92.0.2.203/32.</t>
</li>
</ul>
<t pn="section-2.1-5">These two entries can coexist because their incomi
ng label is
unique. The uniqueness is guaranteed by the label manager allocation unique. The uniqueness is guaranteed by the label manager allocation
rules.</t> rules.</t>
<t pn="section-2.1-6">The same applies for the MPLS2IP forwarding entrie
<t>The same applies for the MPLS2IP forwarding entries. MPLS2IP is the s. MPLS2IP is the
forwarding behavior where a router receives a labeled IPv4/IPv6 packet forwarding behavior where a router receives a labeled IPv4/IPv6 packet
with one label only, pops the label, and switches the packet out as with one label only, pops the label, and switches the packet out as
IPv4/IPv6. For IP2MPLS coexistence, refer to <xref IPv4/IPv6. For IP2MPLS coexistence, refer to <xref target="sec-7.1" form
target="section-7.1"/>.</t> at="default" sectionFormat="of" derivedContent="Section 6.1"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-4" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="section-4" title="SR and LDP Interworking"> ="section-3">
<t>This section analyzes the case where SR is available in one part of <name slugifiedName="name-sr-and-ldp-interworking">SR and LDP Interworking
</name>
<t pn="section-3-1">This section analyzes the case where SR is available i
n one part of
the network and LDP is available in another part. It describes how a the network and LDP is available in another part. It describes how a
continuous MPLS tunnel can be built throughout the network.</t> continuous MPLS tunnel can be built throughout the network.</t>
<figure anchor="ref-sr-and-ldp-interworking" align="left" suppress-title="
<figure anchor="ref-sr-and-ldp-interworking" false" pn="figure-2">
title="SR and LDP Interworking"> <name slugifiedName="name-sr-and-ldp-interworking-2">SR and LDP Interwor
<artwork><![CDATA[ king</name>
<artwork name="" type="" align="left" alt="" pn="section-3-2.1">
PE2 PE4 PE2 PE4
\ / \ /
PE1----P5--P6--P7--P8---PE3 PE1----P5--P6--P7--P8---PE3
]]></artwork>
</figure>
<t><list hangIndent="3" style="hanging"> &lt;-----SR----&gt;
<t hangText="Let us analyze the following example:"><vspace &lt;------LDP------&gt;
blankLines="1"/> P6, P7, P8, PE4, and PE3 are LDP capable. <vspace </artwork>
blankLines="1"/> PE1, PE2, P5, and P6 are SR capable. PE1, PE2, P5, </figure>
and P6 are configured with SRGB (100, 200) and respectively with <t pn="section-3-3">Let us analyze the following example:
node segments 101, 102, 105, and 106. <vspace blankLines="1"/> A </t>
service flow must be tunneled from PE1 to PE3 over a continuous MPLS <ul bare="false" empty="false" spacing="normal" pn="section-3-4">
tunnel encapsulation and therefore, SR and LDP need to interwork.</t> <li pn="section-3-4.1">P6, P7, P8, PE4, and PE3 are LDP capable.
</list></t> </li>
<li pn="section-3-4.2">PE1, PE2, P5, and P6 are SR capable. PE1, PE2, P5
<t/> , and P6 are configured
with SRGB (100, 200) and with node segments 101, 102, 105, and 106, respectively
<section anchor="section-4.1" title="LDP to SR"> .
<t>In this section, a right-to-left traffic flow is analyzed.</t> </li>
<li pn="section-3-4.3">A service flow must be tunneled from PE1 to PE3 o
<t>PE3 has learned a service route whose next-hop is PE1. PE3 has an ver a continuous MPLS
tunnel encapsulation; therefore, SR and LDP need to interwork.
</li>
</ul>
<section anchor="sec-4.1" numbered="true" toc="include" removeInRFC="false
" pn="section-3.1">
<name slugifiedName="name-ldp-to-sr">LDP to SR</name>
<t pn="section-3.1-1">In this section, a right-to-left traffic flow is a
nalyzed.</t>
<t pn="section-3.1-2">PE3 has learned a service route whose next hop is
PE1. PE3 has an
LDP label binding from the next-hop P8 for the FEC "PE1". Therefore, PE3 LDP label binding from the next-hop P8 for the FEC "PE1". Therefore, PE3
sends its service packet to P8 as per classic LDP behavior.</t> sends its service packet to P8 as per classic LDP behavior.</t>
<t pn="section-3.1-3">P8 has an LDP label binding from its next-hop P7 f
<t>P8 has an LDP label binding from its next-hop P7 for the FEC "PE1" or the FEC "PE1"
and therefore, P8 forwards to P7 as per classic LDP behavior.</t> and therefore, P8 forwards to P7 as per classic LDP behavior.</t>
<t pn="section-3.1-4">P7 has an LDP label binding from its next-hop P6 f
<t>P7 has an LDP label binding from its next-hop P6 for the FEC "PE1" or the FEC "PE1"
and therefore, P7 forwards to P6 as per classic LDP behavior.</t> and therefore, P7 forwards to P6 as per classic LDP behavior.</t>
<t pn="section-3.1-5">P6 does not have an LDP binding from its next-hop
<t>P6 does not have an LDP binding from its next-hop P5 for the FEC P5 for the FEC
"PE1". However, P6 has an SR node segment to the IGP route "PE1". "PE1". However, P6 has an SR node segment to the IGP route "PE1".
Hence, P6 forwards the packet to P5 and swaps its local LDP label for Hence, P6 forwards the packet to P5 and swaps its local LDP label for
FEC "PE1" by the equivalent node segment (i.e., 101).</t> FEC "PE1" by the equivalent node segment (i.e., 101).</t>
<t pn="section-3.1-6">P5 pops 101 (assuming PE1 advertised its node segm
<t>P5 pops 101 (assuming PE1 advertised its node segment 101 with the ent 101 with the
penultimate-pop flag set) and forwards to PE1.</t> penultimate-pop flag set) and forwards to PE1.</t>
<t pn="section-3.1-7">PE1 receives the tunneled packet and processes the
<t>PE1 receives the tunneled packet and processes the service service
label.</t> label.</t>
<t pn="section-3.1-8">The end-to-end MPLS tunnel is built by stitching a
<t>The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6 n LDP LSP from PE3 to P6
and the related node segment from P6 to PE1.</t> and the related node segment from P6 to PE1.</t>
<section anchor="sec-4.1.1" numbered="true" toc="include" removeInRFC="f
<section anchor="section-4.1.1" title="LDP to SR Behavior"> alse" pn="section-3.1.1">
<t>It has to be noted that no additional signaling or state is <name slugifiedName="name-ldp-to-sr-behavior">LDP to SR Behavior</name
>
<t pn="section-3.1.1-1">It has to be noted that no additional signalin
g or state is
required in order to provide interworking in the direction LDP to required in order to provide interworking in the direction LDP to
SR.</t> SR.</t>
<t pn="section-3.1.1-2">An SR node having LDP neighbors <bcp14>MUST</b
<t>An SR node having LDP neighbors MUST create LDP bindings for each cp14> create LDP bindings for each
Prefix SID learned in the SR domain by treating SR-learned labels as Prefix-SID learned in the SR domain by treating SR-learned labels as
if they were learned through an LDP neighbor. In addition, for each if they were learned through an LDP neighbor. In addition, for each
FEC, the SR node stitches the incoming LDP label to the outgoing SR FEC, the SR node stitches the incoming LDP label to the outgoing SR
label. This has to be done in both LDP-independent and ordered label label. This has to be done in both LDP-independent and ordered label
distribution control modes as defined in <xref distribution control modes as defined in <xref target="RFC5036" format
target="RFC5036"/>.</t> ="default" sectionFormat="of" derivedContent="RFC5036"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-4.2" numbered="true" toc="include" removeInRFC="false
<section anchor="section-4.2" title="SR to LDP"> " pn="section-3.2">
<t>In this section, the left-to-right traffic flow is analyzed.</t> <name slugifiedName="name-sr-to-ldp">SR to LDP</name>
<t pn="section-3.2-1">In this section, the left-to-right traffic flow is
<t>This section defines the Segment Routing Mapping Server (SRMS). The analyzed.</t>
<t pn="section-3.2-2">This section defines the Segment Routing Mapping S
erver (SRMS). The
SRMS is an IGP node advertising mapping between Segment Identifiers SRMS is an IGP node advertising mapping between Segment Identifiers
(SID) and prefixes advertised by other IGP nodes. The SRMS uses a (SID) and prefixes advertised by other IGP nodes. The SRMS uses a
dedicated IGP extension (IS-IS, OSPFv2, and OSPFv3), which is protocol dedicated IGP extension (IS-IS, OSPFv2, and OSPFv3), which is protocol
specific and defined in <xref specific and defined in <xref target="RFC8665" format="default" sectionF
target="RFC8665"/>, <xref ormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="default" s
target="RFC8666"/>, and <xref ectionFormat="of" derivedContent="RFC8666"/>, and <xref target="RFC8667" format=
target="RFC8667"/>.</t> "default" sectionFormat="of" derivedContent="RFC8667"/>.</t>
<t pn="section-3.2-3">The SRMS function of an SR-capable router allows d
<t>The SRMS function of an SR-capable router allows distribution of istribution of
mappings for prefixes not locally attached to the advertising router mappings for prefixes not locally attached to the advertising router
and therefore allows advertisement of mappings on behalf of and therefore allows advertisement of mappings on behalf of
non-SR-capable routers.</t> non-SR-capable routers.</t>
<t pn="section-3.2-4">The SRMS is a control-plane-only function that may
<t>The SRMS is a control-plane-only function that may be located be located
anywhere in the IGP flooding scope. At least one SRMS server MUST anywhere in the IGP flooding scope. At least one SRMS server <bcp14>MUST
exist in a routing domain to advertise Prefix SIDs on behalf of non&nbhy </bcp14>
;SR exist in a routing domain to advertise Prefix-SIDs on behalf of non‑SR
nodes, thereby allowing non-LDP routers to send and receive labeled nodes, thereby allowing non-LDP routers to send and receive labeled
traffic from LDP-only routers. Multiple SRMSes may be present in the traffic from LDP-only routers. Multiple SRMSes may be present in the
same network (for redundancy). This implies that there are multiple same network (for redundancy). This implies that there are multiple
ways a prefix-to-SID mapping can be advertised. Conflicts resulting ways a prefix-to-SID mapping can be advertised. Conflicts resulting
from inconsistent advertisements are addressed by <xref from inconsistent advertisements are addressed by <xref target="RFC8660"
target="RFC8660"/>.</t> format="default" sectionFormat="of" derivedContent="RFC8660"/>.</t>
<t pn="section-3.2-5">The example depicted in <xref target="ref-sr-and-l
<t>The example depicted in <xref target="ref-sr-and-ldp-interworking"/> dp-interworking" format="default" sectionFormat="of" derivedContent="Figure 2"/>
assumes that the operator assumes that the operator
configures P5 to act as a Segment Routing Mapping Server (SRMS) and configures P5 to act as a Segment Routing Mapping Server and
advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103), advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103),
and (PE4, 104).</t> and (PE4, 104).</t>
<t pn="section-3.2-6">The mappings advertised by one or more SRMSes resu
<t>The mappings advertised by one or more SRMSes result from local lt from local
policy information configured by the operator.</t> policy information configured by the operator.</t>
<t pn="section-3.2-7">If PE3 had been SR capable, the operator would hav
<t>If PE3 had been SR capable, the operator would have configured PE3 e configured PE3
with node segment 103. Instead, as PE3 is not SR capable, the operator with node segment 103. Instead, as PE3 is not SR capable, the operator
configures that policy at the SRMS and it is the latter that configures that policy at the SRMS and it is the latter that
advertises the mapping.</t> advertises the mapping.</t>
<t pn="section-3.2-8">The Mapping Server Advertisements are only underst
<t>The mapping server advertisements are only understood by SR-capable ood by SR-capable
routers. The SR-capable routers install the related node segments in routers. The SR-capable routers install the related node segments in
the MPLS data plane exactly like the node segments had been advertised the MPLS data plane exactly like the node segments had been advertised
by the nodes themselves.</t> by the nodes themselves.</t>
<t pn="section-3.2-9">For example, PE1 installs the node segment 103 wit
<t>For example, PE1 installs the node segment 103 with next-hop P5 h next-hop P5
exactly as if PE3 had advertised node segment 103.</t> exactly as if PE3 had advertised node segment 103.</t>
<t pn="section-3.2-10">PE1 has a service route whose next hop is PE3. PE
<t>PE1 has a service route whose next-hop is PE3. PE1 has a node 1 has a node
segment for that IGP route: 103 with next-hop P5. Hence, PE1 sends its segment for that IGP route: 103 with next-hop P5. Hence, PE1 sends its
service packet to P5 with two labels: the bottom label is the service service packet to P5 with two labels: the bottom label is the service
label and the top label is 103.</t> label and the top label is 103.</t>
<t pn="section-3.2-11">P5 swaps 103 for 103 and forwards to P6.</t>
<t>P5 swaps 103 for 103 and forwards to P6.</t> <t pn="section-3.2-12">P6's next hop for the IGP route "PE3" is not SR c
apable (P7 does
<t>P6's next-hop for the IGP route "PE3" is not SR capable (P7 does
not advertise the SR capability). However, P6 has an LDP label binding not advertise the SR capability). However, P6 has an LDP label binding
from that next-hop for the same FEC (e.g., LDP label 1037). Hence, P6 from that next hop for the same FEC (e.g., LDP label 1037). Hence, P6
swaps 103 for 1037 and forwards to P7.</t> swaps 103 for 1037 and forwards to P7.</t>
<t pn="section-3.2-13">P7 swaps this label with the LDP label received f
<t>P7 swaps this label with the LDP label received from P8 and rom P8 and
forwards to P8.</t> forwards to P8.</t>
<t pn="section-3.2-14">P8 pops the LDP label and forwards to PE3.</t>
<t>P8 pops the LDP label and forwards to PE3.</t> <t pn="section-3.2-15">PE3 receives the tunneled packet and processes th
e service
<t>PE3 receives the tunneled packet and processes the service
label.</t> label.</t>
<t pn="section-3.2-16">The end-to-end MPLS tunnel is built by stitching
<t>The end-to-end MPLS tunnel is built from an SR node segment from an SR node segment from
PE1 to P6 and an LDP LSP from P6 to PE3.</t> PE1 to P6 and an LDP LSP from P6 to PE3.</t>
<t pn="section-3.2-17">SR-mapping advertisement for a given prefix provi
<t>SR-mapping advertisement for a given prefix provides no information des no information
about Penultimate Hop Popping. Other mechanisms, such as IGP-specific about Penultimate Hop Popping. Other mechanisms, such as IGP-specific
mechanisms (<xref target="RFC8665"/>, mechanisms (<xref target="RFC8665" format="default" sectionFormat="of" d
<xref target="RFC8666"/> and <xref erivedContent="RFC8665"/>,
target="RFC8667"/>), MAY be <xref target="RFC8666" format="default" sectionFormat="of" derivedConten
t="RFC8666"/>, and <xref target="RFC8667" format="default" sectionFormat="of" de
rivedContent="RFC8667"/>), <bcp14>MAY</bcp14> be
used to determine the Penultimate Hop Popping in such case.</t> used to determine the Penultimate Hop Popping in such case.</t>
<aside pn="section-3.2-18">
<t>Note: In the previous example, Penultimate Hop Popping is not <t pn="section-3.2-18.1">Note: In the previous example, Penultimate Ho
performed at the SR/LDP border for segment 103 (PE3), because none of p Popping is not
performed at the SR-LDP border for segment 103 (PE3), because none of
the routers in the SR domain are Penultimate Hop for segment 103. In the routers in the SR domain are Penultimate Hop for segment 103. In
this case, P6 requires the presence of the segment 103 such as to map this case, P6 requires the presence of the segment 103 such as to map
it to the LDP label 1037.</t> it to the LDP label 1037.</t>
</aside>
<section anchor="section-4.2.1" <section anchor="sec-4.2.1" numbered="true" toc="include" removeInRFC="f
title="Segment Routing Mapping Server (SRMS)"> alse" pn="section-3.2.1">
<t>This section specifies the concept and externally visible <name slugifiedName="name-segment-routing-mapping-ser">Segment Routing
functionality of a segment routing mapping server (SRMS).</t> Mapping Server (SRMS)</name>
<t pn="section-3.2.1-1">This section specifies the concept and externa
<t>The purpose of SRMS functionality is to support the lly visible
advertisement of Prefix SIDs to a prefix without the need to functionality of a Segment Routing Mapping Server (SRMS).</t>
<t pn="section-3.2.1-2">The purpose of SRMS functionality is to suppor
t the
advertisement of Prefix-SIDs to a prefix without the need to
explicitly advertise such assignment within a prefix reachability explicitly advertise such assignment within a prefix reachability
advertisement. Examples of explicit Prefix SID advertisement are the advertisement. Examples of explicit Prefix-SID Advertisement are the
Prefix SID sub-TLVs defined in <xref Prefix-SID sub-TLVs defined in <xref target="RFC8665" format="default"
target="RFC8665"/>, <xref sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="d
target="RFC8666"/>, and <xref efault" sectionFormat="of" derivedContent="RFC8666"/>, and <xref target="RFC8667
target="RFC8667"/>.</t> " format="default" sectionFormat="of" derivedContent="RFC8667"/>.</t>
<t pn="section-3.2.1-3">The SRMS functionality allows assigning of Pre
<t>The SRMS functionality allows assigning of Prefix SIDs to fix-SIDs to
prefixes owned by non-SR-capable routers as well as to prefixes prefixes owned by non-SR-capable routers as well as to prefixes
owned by SR-capable nodes. It is the former capability that is owned by SR-capable nodes. It is the former capability that is
essential to the SR-LDP interworking described later in this essential to the SR-LDP interworking described later in this
section.</t> section.</t>
<t pn="section-3.2.1-4">The SRMS functionality consists of two functio
<t>The SRMS functionality consists of two functional blocks: the nal blocks: the
Mapping Server (MS) and Mapping Client (MC).</t> Mapping Server (MS) and Mapping Client (MC).</t>
<t pn="section-3.2.1-5">An MS is a node that advertises an SR mappings
<t>An MS is a node that advertises an SR mappings. Advertisements . Advertisements
sent by an MS define the assignment of a Prefix SID to a prefix sent by an MS define the assignment of a Prefix-SID to a prefix
independent of the advertisement of reachability to the prefix independent of the advertisement of reachability to the prefix
itself. An MS MAY advertise SR mappings for any prefix whether or itself. An MS <bcp14>MAY</bcp14> advertise SR mappings for any prefix whether or
not it advertises reachability for the prefix and irrespective of not it advertises reachability for the prefix and irrespective of
whether that prefix is advertised by or even reachable through any whether that prefix is advertised by or even reachable through any
router in the network.</t> router in the network.</t>
<t pn="section-3.2.1-6">An MC is a node that receives and uses the MS
<t>An MC is a node that receives and uses the MS mapping mapping
advertisements. Note that a node may be both an MS and an MC. An MC advertisements. Note that a node may be both an MS and an MC. An MC
interprets the SR-mapping advertisement as an assignment of a interprets the SR-mapping advertisement as an assignment of a
Prefix SID to a prefix. For a given prefix, if an MC receives an Prefix-SID to a prefix. For a given prefix, if an MC receives an
SR-mapping advertisement from a mapping server and also has received SR-mapping advertisement from a Mapping Server and also has received
a Prefix SID advertisement for that same prefix in a prefix a Prefix-SID Advertisement for that same prefix in a prefix
reachability advertisement, then the MC MUST prefer the SID reachability advertisement, then the MC <bcp14>MUST</bcp14> prefer the
SID
advertised in the prefix reachability advertisement over the advertised in the prefix reachability advertisement over the
mapping server advertisement, i.e., the mapping server advertisement Mapping Server Advertisement, i.e., the Mapping Server Advertisement
MUST be ignored for that prefix. Hence, assigning a Prefix SID to a <bcp14>MUST</bcp14> be ignored for that prefix. Hence, assigning a Pre
fix-SID to a
prefix using the SRMS functionality does not preclude assigning the prefix using the SRMS functionality does not preclude assigning the
same or different Prefix SID(s) to the same prefix using explicit same or different Prefix-SID(s) to the same prefix using explicit
Prefix SID advertisement such as the aforementioned Prefix SID Prefix-SID Advertisement such as the aforementioned Prefix-SID
sub-TLVs.</t> sub-TLVs.</t>
<t pn="section-3.2.1-7">For example, consider an IPv4 prefix advertise
<t>For example, consider an IPv4 prefix advertisement received by an ment received by an
IS&nbhy;IS router in the Extended IP reachability TLV (TLV 135). Suppo IS‑IS router in the Extended IP reachability TLV (TLV 135). Suppose
se TLV 135 contained the Prefix-SID sub-TLV. If the router that
TLV 135 contained the Prefix SID sub-TLV. If the router that receives TLV 135 with the Prefix-SID sub-TLV also received an
receives TLV 135 with the Prefix SID sub-TLV also received an
SR-mapping advertisement for the same prefix through the SR-mapping advertisement for the same prefix through the
SID/Label Binding TLV, then the receiving router must prefer the SID/Label Binding TLV, then the receiving router must prefer the
Prefix SID sub-TLV over the SID/Label Binding TLV for that Prefix-SID sub-TLV over the SID/Label Binding TLV for that
prefix. Refer to <xref prefix. Refer to <xref target="RFC8667" format="default" sectionFormat
target="RFC8667"/> for details ="of" derivedContent="RFC8667"/> for details
about the Prefix SID sub-TLV and SID/Label Binding TLV.</t> about the Prefix-SID sub-TLV and SID/Label Binding TLV.</t>
</section> </section>
<section anchor="sec-4.2.2" numbered="true" toc="include" removeInRFC="f
<section anchor="section-4.2.2" title="SR to LDP Behavior"> alse" pn="section-3.2.2">
<t>SR to LDP interworking requires an SRMS as defined above.</t> <name slugifiedName="name-sr-to-ldp-behavior">SR to LDP Behavior</name
>
<t>Each SR-capable router installs in the MPLS data-plane Node-SIDs <t pn="section-3.2.2-1">SR to LDP interworking requires an SRMS as def
learned from the SRMS exactly like if these SIDs had been advertised ined above.</t>
<t pn="section-3.2.2-2">Each SR-capable router installs in the MPLS da
ta-plane Node SIDs
learned from the SRMS exactly as if these SIDs had been advertised
by the nodes themselves.</t> by the nodes themselves.</t>
<t pn="section-3.2.2-3">An SR node having LDP-only neighbors <bcp14>MU
<t>An SR node having LDP neighbors MUST stitch the incoming SR label ST</bcp14> stitch the incoming SR label
(whose SID is advertised by the SRMS) to the outgoing LDP label.</t> (whose SID is advertised by the SRMS) to the outgoing LDP label.</t>
<t pn="section-3.2.2-4">It has to be noted that the SR to LDP behavior
<t>It has to be noted that the SR to LDP behavior does not propagate does not propagate
the status of the LDP FEC that was signaled if LDP was configured the status of the LDP FEC that was signaled by LDP when configured
to use the ordered mode.</t> in ordered mode.</t>
<t pn="section-3.2.2-5">It has to be noted that in the case of SR to L
<t>It has to be noted that in the case of SR to LDP, the label DP, the label
binding is equivalent to the independent LDP Label Distribution binding is equivalent to the independent LDP Label Distribution
Control Mode <xref target="RFC5036"/> where a label is bound to a Control Mode <xref target="RFC5036" format="default" sectionFormat="of " derivedContent="RFC5036"/> where a label is bound to a
FEC independently from the received binding for the same FEC.</t> FEC independently from the received binding for the same FEC.</t>
</section> </section>
<section anchor="sec-4.2.3" numbered="true" toc="include" removeInRFC="f
<section anchor="section-4.2.3" alse" pn="section-3.2.3">
title="Interoperability of Multiple SRMSes and Prefix SID Adver <name slugifiedName="name-interoperability-of-multipl">Interoperabilit
tisements"> y of Multiple SRMSes and Prefix-SID Advertisements</name>
<t>In the case of SR/LDP interoperability through the use of an SRMS, <t pn="section-3.2.3-1">In the case of SR-LDP interoperability through
the use of an SRMS,
mappings are advertised by one or more SRMSes.</t> mappings are advertised by one or more SRMSes.</t>
<t pn="section-3.2.3-2">SRMS functionality is implemented in the link-
<t>SRMS functionality is implemented in the link-state protocol (such state protocol (such as
as
IS-IS and OSPF). Link-state protocols allow propagation of updates IS-IS and OSPF). Link-state protocols allow propagation of updates
across area boundaries and, therefore, SRMS advertisements are across area boundaries and, therefore, SRMS advertisements are
propagated through the usual inter-area advertisement procedures in propagated through the usual inter-area advertisement procedures in
link-state protocols.</t> link-state protocols.</t>
<t pn="section-3.2.3-3">Multiple SRMSes can be provisioned in a networ
<t>Multiple SRMSes can be provisioned in a network for redundancy. k for redundancy.
Moreover, a preference mechanism may also be used among SRMSes to Moreover, a preference mechanism may also be used among SRMSes to
deploy a primary/secondary SRMS scheme allowing controlled deploy a primary/secondary SRMS scheme allowing controlled
modification or migration of SIDs.</t> modification or migration of SIDs.</t>
<t pn="section-3.2.3-4">The content of SRMS advertisement (i.e., mappi
<t>The content of SRMS advertisement (i.e., mappings) are a matter ngs) are a matter
of local policy determined by the operator. When multiple SRMSes are of local policy determined by the operator. When multiple SRMSes are
active, it is necessary that the information (mappings) advertised active, it is necessary that the information (mappings) advertised
by the different SRMSes is aligned and consistent. The following by the different SRMSes is aligned and consistent. The following
mechanism is applied to determine the preference of SRMS mechanism is applied to determine the preference of SRMS
advertisements:</t> advertisements:</t>
<t pn="section-3.2.3-5">If a node acts as an SRMS, it <bcp14>MAY</bcp1
<t>If a node acts as an SRMS, it MAY advertise a preference to be 4> advertise a preference to be
associated with all SRMS SID advertisements sent by that node. The associated with all SRMS SID Advertisements sent by that node. The
means of advertising the preference is defined in the means of advertising the preference is defined in the
protocol-specific documents, e.g., <xref protocol-specific documents, e.g., <xref target="RFC8665" format="defa
target="RFC8665"/>, <xref ult" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" forma
target="RFC8666"/>, and <xref t="default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref target="RFC
target="RFC8667"/>. The 8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>. The
preference value is an unsigned 8-bit integer with the following preference value is an unsigned 8-bit integer with the following
properties:</t> properties:</t>
<table anchor="table_1" align="center" pn="table-1">
<t><list style="hanging"> <tbody>
<t>0 - Reserved value indicating advertisements from that node <tr>
MUST NOT be used.</t> <td align="center" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">Reserved value indicati
<t>1 - 255 Preference value (255 is most preferred)</t> ng advertisements from that
</list>Advertisement of a preference value is optional. Nodes node <bcp14>MUST NOT</bcp14> be used</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">1-255</td>
<td align="left" colspan="1" rowspan="1">Preference value (255 i
s most preferred)</td>
</tr>
</tbody>
</table>
<t pn="section-3.2.3-7">Advertisement of a preference value is optiona
l. Nodes
that do not advertise a preference value are assigned a preference that do not advertise a preference value are assigned a preference
value of 128.</t> value of 128.</t>
<t pn="section-3.2.3-8">An MCC on a node receiving one or more SRMS ma
<t>An MCC on a node receiving one or more SRMS mapping advertisements pping advertisements
applies them as follows:</t> applies them as follows:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.2.3-9">
<t><list style="symbols"> <li pn="section-3.2.3-9.1">For any prefix for which it did not recei
<t>For any prefix for which it did not receive a Prefix SID ve a Prefix-SID
advertisement, the MCC applies the SRMS mapping advertisements Advertisement, the MCC applies the SRMS mapping advertisements
with the highest preference. The mechanism by which a Prefix SID with the highest preference. The mechanism by which a Prefix-SID
is advertised for a given prefix is defined in the protocol is advertised for a given prefix is defined in the protocol
specifications <xref target="RFC8665"/>, specifications <xref target="RFC8665" format="default" sectionForm
<xref target="RFC8666"/>, and at="of" derivedContent="RFC8665"/>,
<xref <xref target="RFC8666" format="default" sectionFormat="of" derived
target="RFC8667"/>.</t> Content="RFC8666"/>, and
<xref target="RFC8667" format="default" sectionFormat="of" derived
<t>If there is an incoming label collision as specified in <xref Content="RFC8667"/>.</li>
target="RFC8660"/>, apply the <li pn="section-3.2.3-9.2">If there is an incoming label collision a
steps specified in <xref s specified in <xref target="RFC8660" format="default" sectionFormat="of" derive
target="RFC8660"/> to resolve the dContent="RFC8660"/>, apply the
collision.</t> steps specified in <xref target="RFC8660" format="default" section
</list></t> Format="of" derivedContent="RFC8660"/> to resolve the
collision.</li>
<t>When the SRMS advertises mappings, an implementation should </ul>
<t pn="section-3.2.3-10">When the SRMS advertises mappings, an impleme
ntation should
provide a mechanism through which the operator determines which of provide a mechanism through which the operator determines which of
the IP2MPLS mappings are preferred among the one advertised by the the IP2MPLS mappings are preferred among the one advertised by the
SRMS and the ones advertised by LDP.</t> SRMS and the ones advertised by LDP.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-5" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="section-5" title="SR/LDP Interworking Use Cases"> ="section-4">
<t>SR can be deployed, for example, to enhance LDP transport. The SR <name slugifiedName="name-sr-ldp-interworking-use-cas">SR-LDP Interworking
Use Cases</name>
<t pn="section-4-1">SR can be deployed, for example, to enhance LDP transp
ort. The SR
deployment can be limited to the network region where the SR benefits deployment can be limited to the network region where the SR benefits
are most desired.</t> are most desired.</t>
<section anchor="sec-5.1" numbered="true" toc="include" removeInRFC="false
<section anchor="section-5.1" title="SR Protection of LDP-Based Traffic"> " pn="section-4.1">
<t>In <xref target="ref-sr-ldp-interworking-example"/>, let us assume: <name slugifiedName="name-sr-protection-of-ldp-based-">SR Protection of
<list style="empty"> LDP-Based Traffic</name>
<t> <t pn="section-4.1-1">In <xref target="ref-sr-ldp-interworking-example"
All link costs are 10 except FG, which is 30.</t> format="default" sectionFormat="of" derivedContent="Figure 3"/>, let us assume:
<t> All routers are LDP capable.</t> </t>
<t> X, Y, and Z are PEs participating in an important service S.</t> <ul empty="false" spacing="normal" bare="false" pn="section-4.1-2">
<t> The operator requires 50 msec link-based Fast Reroute (FRR) for ser <li pn="section-4.1-2.1">
vice S.</t> All link costs are 10 except FG, which is 30.</li>
<t> A, B, C, D, E, F, and G are SR capable.</t> <li pn="section-4.1-2.2"> All routers are LDP capable.</li>
<t> X, Y, and Z are not SR capable, e.g., as part of a <li pn="section-4.1-2.3"> X, Y, and Z are PEs participating in an impo
rtant service S.</li>
<li pn="section-4.1-2.4"> The operator requires 50 msec link-based Fas
t Reroute (FRR) for service S.</li>
<li pn="section-4.1-2.5"> A, B, C, D, E, F, and G are SR capable.</li>
<li pn="section-4.1-2.6"> X, Y, and Z are not SR capable, e.g., as par
t of a
staged migration from LDP to SR, the operator deploys SR first in staged migration from LDP to SR, the operator deploys SR first in
a subpart of the network and then everywhere.</t> a subpart of the network and then everywhere.</li>
</list></t> </ul>
<figure anchor="ref-sr-ldp-interworking-example" align="left" suppress-t
<figure anchor="ref-sr-ldp-interworking-example" itle="false" pn="figure-3">
title="SR/LDP Interworking Example"> <name slugifiedName="name-sr-ldp-interworking-example">SR-LDP Interwor
<artwork><![CDATA[ king Example</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-3.1">
X X
| |
Y--A---B---E--Z Y--A---B---E--Z
| | \ | | \
D---C--F--G D---C--F--G
30 30
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.1-4">The operator would like to resolve the following i
<t><list hangIndent="3" style="hanging"> ssues:
<t </t>
hangText="The operator would like to resolve the following issues:"> <ul empty="false" spacing="normal" bare="false" pn="section-4.1-5">
<vspace <li pn="section-4.1-5.1">To protect the link BA along the shortest-pat
blankLines="1"/> To protect the link BA along the shortest-path of h of the important flow XY,
the important flow XY, B requires a Remote Loop-Free Alternate B requires a Remote Loop-Free Alternate (RLFA; see <xref target="RFC7490" format
(RLFA; see <xref target="RFC7490"/>) repair tunnel to D and, therefo ="default" sectionFormat="of" derivedContent="RFC7490"/>) repair tunnel to D and
re, a , therefore, a targeted LDP session
targeted LDP session from B to D. Typically, network operators from B to D. Typically, network operators prefer avoiding these dynamically
prefer avoiding these dynamically established multi-hop LDP established multi-hop LDP sessions in order to reduce the number of protocols
sessions in order to reduce the number of protocols running in the running in the network and, therefore, simplify network operations.
network and, therefore, simplify network operations. <vspace </li>
blankLines="1"/> There is no LFA/RLFA solution to protect the link <li pn="section-4.1-5.2">There is no LFA/RLFA solution to protect the
BE along the shortest path of the important flow XZ. The operator link BE along the shortest
wants a guaranteed link-based FRR solution.</t> path of the important flow XZ. The operator wants a guaranteed link-based FRR so
</list></t> lution.
</li>
<t>The operator can meet these objectives by deploying SR only on A, </ul>
<t pn="section-4.1-6">The operator can meet these objectives by deployin
g SR only on A,
B, C, D, E, F, and G:</t> B, C, D, E, F, and G:</t>
<ul bare="false" empty="false" spacing="normal" pn="section-4.1-7">
<t><list hangIndent="3" style="hanging"> <li pn="section-4.1-7.1">The operator configures A, B, C, D, E, F, and
<t>The operator configures A, B, C, D, E, F, and G with SRGB [100, G with SRGB [100, 200] and
200] and respective node segments 101, 102, 103, 104, 105, 106, and with node segments 101, 102, 103, 104, 105, 106, and 107, respectively.
107.</t> </li>
</list></t> <li pn="section-4.1-7.2">The operator configures D as an SR Mapping Se
rver with the following
<t><list hangIndent="3" style="hanging"> policy mapping: (X, 201), (Y, 202), and (Z, 203).
<t>The operator configures D as an SR Mapping Server with the </li>
following policy mapping: (X, 201), (Y, 202), and (Z, 203).</t> <li pn="section-4.1-7.3">Each SR node automatically advertises a local
</list></t> adjacency segment for its
IGP adjacencies. Specifically, F advertises adjacency segment 9001 for its
<t><list hangIndent="3" style="hanging"> adjacency FG.
<t>Each SR node automatically advertises a local adjacency segment </li>
for its IGP adjacencies. Specifically, F advertises adjacency </ul>
segment 9001 for its adjacency FG.</t> <t pn="section-4.1-8">A, B, C, D, E, F, and G keep their LDP capability.
</list></t> Therefore, the
<t>A, B, C, D, E, F, and G keep their LDP capability. Therefore, the
flows XY and XZ are transported over end-to-end LDP LSPs.</t> flows XY and XZ are transported over end-to-end LDP LSPs.</t>
<t pn="section-4.1-9">For example, LDP at B installs the following MPLS
<t>For example, LDP at B installs the following MPLS data-plane data-plane
entries:</t> entries:</t>
<ul empty="true" bare="false" spacing="normal" pn="section-4.1-10">
<t><list hangIndent="3" style="hanging"> <li pn="section-4.1-10.1">
<t <t pn="section-4.1-10.1.1">Incoming label: local LDP label bound by
hangText="Incoming label: local LDP label bound by B for FEC Y"><vsp B for FEC Y</t>
ace <ul empty="false" bare="false" spacing="normal" pn="section-4.1-10.1
blankLines="0"/> Outgoing label: LDP label bound by A for FEC .2">
Y<vspace blankLines="0"/> Outgoing next-hop: A</t> <li pn="section-4.1-10.1.2.1">Outgoing label: LDP label bound by A
for FEC Y</li>
<t <li pn="section-4.1-10.1.2.2">Outgoing next hop: A</li>
hangText="Incoming label: local LDP label bound by B for FEC Z"><vsp </ul>
ace </li>
blankLines="0"/>Outgoing label: LDP label bound by E for FEC <li pn="section-4.1-10.2">
Z<vspace blankLines="0"/>Outgoing next-hop: E</t> <t pn="section-4.1-10.2.1">Incoming label: local LDP label bound by
</list></t> B for FEC Z</t>
<ul empty="false" bare="false" spacing="normal" pn="section-4.1-10.2
<t>The novelty comes from how the backup chains are computed for these .2">
<li pn="section-4.1-10.2.2.1">Outgoing label: LDP label bound by E
for FEC Z </li>
<li pn="section-4.1-10.2.2.2">Outgoing next hop: E </li>
</ul>
</li>
</ul>
<t pn="section-4.1-11">The novelty comes from how the backup chains are
computed for these
LDP-based entries. While LDP labels are used for the primary next- hop LDP-based entries. While LDP labels are used for the primary next- hop
and outgoing labels, SR information is used for the FRR construction. and outgoing labels, SR information is used for the FRR construction.
In steady state, the traffic is transported over LDP LSP. In transient In steady state, the traffic is transported over LDP LSP. In transient
FRR state, the traffic is backup thanks to the SR-enhanced FRR state, the traffic is backup thanks to the SR-enhanced
capabilities.</t> capabilities.</t>
<t pn="section-4.1-12">The RLFA paths are dynamically precomputed as def
<t>The RLFA paths are dynamically precomputed as defined in <xref ined in <xref target="RFC7490" format="default" sectionFormat="of" derivedConten
target="RFC7490"/>. Typically, implementations allow to enable an RLFA t="RFC7490"/>. Typically, implementations allow to enable an RLFA
mechanism through a simple configuration command that triggers both mechanism through a simple configuration command that triggers both
the precomputation and installation of the repair path. The details the precomputation and installation of the repair path. The details
on how RLFA mechanisms are implemented and configured is outside the on how RLFA mechanisms are implemented and configured is outside the
scope of this document and not relevant to the aspects of SR/LDP scope of this document and not relevant to the aspects of SR-LDP
interwork explained in this document.</t> interwork explained in this document.</t>
<t pn="section-4.1-13">This helps meet the requirements of the operator:
<!-- hmm how about "maintain guaranteed FRR coverage"?--> </t>
<t><list hangIndent="3" style="hanging"> <ul bare="false" empty="false" spacing="normal" pn="section-4.1-14">
<t <li pn="section-4.1-14.1">Eliminate targeted LDP sessions.
hangText="This helps meet the requirements of the operator:"><vspace </li>
blankLines="1"/> Eliminate targeted LDP sessions. <vspace <li pn="section-4.1-14.2">Provide guaranteed FRR coverage.
blankLines="1"/> Guaranteed FRR coverage. <vspace blankLines="1"/> </li>
Keep the traffic over LDP LSP in steady state. <vspace <li pn="section-4.1-14.3">Keep the traffic over LDP LSP in steady stat
blankLines="1"/> Partially deploy SR only where needed.</t> e.
</list></t> </li>
<li pn="section-4.1-14.4">Partially deploy SR only where needed.
</li>
</ul>
</section> </section>
<section anchor="sec-5.2" numbered="true" toc="include" removeInRFC="false
<section anchor="section-5.2" title="Eliminating Targeted LDP Sessions"> " pn="section-4.2">
<t>B's MPLS entry to Y becomes:</t> <name slugifiedName="name-eliminating-targeted-ldp-se">Eliminating Targe
ted LDP Sessions</name>
<figure> <t pn="section-4.2-1">B's MPLS entry to Y becomes:</t>
<artwork><![CDATA[ <ul empty="true" bare="false" spacing="normal" pn="section-4.2-2">
- Incoming label: local LDP label bound by B for FEC Y <li pn="section-4.2-2.1">
Outgoing label: LDP label bound by A for FEC Y <t pn="section-4.2-2.1.1">Incoming label: local LDP label bound by B
Backup outgoing label: SR node segment for Y {202} for FEC Y</t>
Outgoing next-hop: A <ul empty="false" bare="false" spacing="normal" pn="section-4.2-2.1.
Backup next-hop: repair tunnel: node segment to D {104} 2">
with outgoing next-hop: C <li pn="section-4.2-2.1.2.1">Outgoing label: LDP label bound by A
]]></artwork> for FEC Y</li>
</figure> <li pn="section-4.2-2.1.2.2">Backup outgoing label: SR node segmen
t for Y {202}</li>
<t>It has to be noted that D is selected as a Remote Loop-Free Alternate <li pn="section-4.2-2.1.2.3">Outgoing next hop: A</li>
(RLFA) as defined in <xref target="RFC7490"/>.</t> <li pn="section-4.2-2.1.2.4">Backup next hop: repair tunnel: node
segment to D {104} with outgoing
<t>In steady state, X sends its Y-destined traffic to B with a top next hop: C</li>
</ul>
</li>
</ul>
<t pn="section-4.2-3">It has to be noted that D is selected as a Remote
Loop-Free Alternate
(RLFA) as defined in <xref target="RFC7490" format="default" sectionForm
at="of" derivedContent="RFC7490"/>.</t>
<t pn="section-4.2-4">In steady state, X sends its Y-destined traffic to
B with a top
label, which is the LDP label bound by B for FEC Y. B swaps that top label, which is the LDP label bound by B for FEC Y. B swaps that top
label for the LDP label bound by A for FEC Y and forwards to A. A pops label for the LDP label bound by A for FEC Y and forwards to A. A pops
the LDP label and forwards to Y.</t> the LDP label and forwards to Y.</t>
<t pn="section-4.2-5">Upon failure of the link BA, B swaps the incoming
<t>Upon failure of the link BA, B swaps the incoming top label with top label with
the node segment for Y (202) and sends the packet onto a repair tunnel the node segment for Y (202) and sends the packet onto a repair tunnel
to D (node segment 104). Thus, B sends the packet to C with the label to D (node segment 104). Thus, B sends the packet to C with the label
stack {104, 202}.&nbsp; C pops the node segment 104 and forwards to D. D stack {104, 202}.  C pops the node segment 104 and forwards to D. D
swaps 202 for 202 and forwards to A. A's next-hop to Y is not SR swaps 202 for 202 and forwards to A. A's next hop to Y is not SR
capable, and therefore, node A swaps the incoming node segment 202 to th capable, and therefore, Node A swaps the incoming node segment 202 to th
e e
LDP label announced by its next-hop (in this case, implicit null).</t> LDP label announced by its next hop (in this case, implicit NULL).</t>
<t pn="section-4.2-6">After IGP convergence, B's MPLS entry to Y will be
<t>After IGP convergence, B's MPLS entry to Y will become:</t> come:</t>
<ul empty="true" bare="false" spacing="normal" pn="section-4.2-7">
<figure> <li pn="section-4.2-7.1">
<artwork><![CDATA[ <t pn="section-4.2-7.1.1">Incoming label: local LDP label bound by B
- Incoming label: local LDP label bound by B for FEC Y for FEC Y</t>
Outgoing label: LDP label bound by C for FEC Y <ul empty="false" bare="false" spacing="normal" pn="section-4.2-7.1.
Outgoing next-hop: C]]></artwork> 2">
</figure> <li pn="section-4.2-7.1.2.1">Outgoing label: LDP label bound by C
for FEC Y</li>
<t/> <li pn="section-4.2-7.1.2.2">Outgoing next hop: C</li>
</ul>
<t>And the traffic XY travels again over the LDP LSP.</t> </li>
</ul>
<t>Conclusion: the operator has eliminated the need for targeted LDP <t pn="section-4.2-8">And the traffic XY travels again over the LDP LSP.
</t>
<t pn="section-4.2-9">Conclusion: the operator has eliminated the need f
or targeted LDP
sessions (no longer required) and the steady-state traffic is still sessions (no longer required) and the steady-state traffic is still
transported over LDP. The SR deployment is confined to the area where transported over LDP. The SR deployment is confined to the area where
these benefits are required.</t> these benefits are required.</t>
<t pn="section-4.2-10">Despite that, in general, an implementation would
<t>Despite that, in general, an implementation would not require a not require a
manual configuration of targeted LDP sessions. However, it is always a manual configuration of targeted LDP sessions. However, it is always a
gain if the operator is able to reduce the set of protocol sessions gain if the operator is able to reduce the set of protocol sessions
running on the network infrastructure.</t> running on the network infrastructure.</t>
</section> </section>
<section anchor="sec-5.3" numbered="true" toc="include" removeInRFC="false
<section anchor="section-5.3" title="Guaranteed FRR Coverage"> " pn="section-4.3">
<t>As mentioned in <xref target="section-5.1"/>, in the example <name slugifiedName="name-guaranteed-frr-coverage">Guaranteed FRR Covera
topology described in <xref target="ref-sr-ldp-interworking-example"/>, ge</name>
there is no RLFA-based solution for <t pn="section-4.3-1">As mentioned in <xref target="sec-5.1" format="def
ault" sectionFormat="of" derivedContent="Section 4.1"/>, in the example
topology described in <xref target="ref-sr-ldp-interworking-example" for
mat="default" sectionFormat="of" derivedContent="Figure 3"/>, there is no RLFA-b
ased solution for
protecting the traffic flow YZ against the failure of link BE because protecting the traffic flow YZ against the failure of link BE because
there is no intersection between the extended P-space and Q-space (see there is no intersection between the extended P-space and Q-space (see
<xref target="RFC7490"/> for details). However:</t> <xref target="RFC7490" format="default" sectionFormat="of" derivedConten
t="RFC7490"/> for details). However:</t>
<t><list style="symbols"> <ul spacing="normal" bare="false" empty="false" pn="section-4.3-2">
<t>G belongs to the Q space of Z.</t> <li pn="section-4.3-2.1">G belongs to the Q space of Z.</li>
<li pn="section-4.3-2.2">G can be reached from B via a "repair SR path
<t>G can be reached from B via a "repair SR path" {106, 9001} that " {106, 9001} that
is not affected by failure of link BE. (The method by which G and is not affected by failure of link BE. (The method by which G and
the repair tunnel to it from B are identified are outside the scope of the repair tunnel to it from B are identified are outside the scope of
this document.)</t> this document.)</li>
</list></t> </ul>
<t pn="section-4.3-3">B's MPLS entry to Z becomes:</t>
<t>B's MPLS entry to Z becomes:</t> <ul empty="true" bare="false" spacing="normal" pn="section-4.3-4">
<li pn="section-4.3-4.1">
<figure> <t pn="section-4.3-4.1.1">Incoming label: local LDP label bound by B
<artwork><![CDATA[ for FEC Z</t>
- Incoming label: local LDP label bound by B for FEC Z <ul empty="false" bare="false" spacing="normal" pn="section-4.3-4.1.
Outgoing label: LDP label bound by E for FEC Z 2">
Backup outgoing label: SR node segment for Z {203} <li pn="section-4.3-4.1.2.1">Outgoing label: LDP label bound by E
Outgoing next-hop: E for FEC Z</li>
Backup next-hop: repair tunnel to G: {106, 9001} <li pn="section-4.3-4.1.2.2">Backup outgoing label: SR node segmen
]]></artwork></figure> t for Z {203}</li>
<li pn="section-4.3-4.1.2.3">Outgoing next hop: E</li>
<t> <li pn="section-4.3-4.1.2.4">Backup next hop: repair tunnel to G:
<list style="empty"><t><list style="empty"><t> {106, 9001}</li>
</ul>
</li>
</ul>
<ul empty="true" spacing="normal" bare="false" pn="section-4.3-5">
<li pn="section-4.3-5.1">
G is reachable from B via the combination of a G is reachable from B via the combination of a
node segment to F {106} and an adjacency segment node segment to F {106} and an adjacency segment
FG {9001} FG {9001}.
</t> </li>
<t> <li pn="section-4.3-5.2">
Note that {106, 107} would have equally work. Note that {106, 107} would have equally worked.
Indeed, in many cases, P's shortest path to Q is Indeed, in many cases, P's shortest path to Q is
over the link PQ. The adjacency segment from P to over the link PQ. The adjacency segment from P to
Q is required only in very rare topologies where Q is required only in very rare topologies where
the shortest-path from P to Q is not via the link the shortest-path from P to Q is not via the link
PQ. PQ.
</t> </li>
</list></t></list> </ul>
<t pn="section-4.3-6">
In steady state, X sends its Z-destined traffic to B with a top In steady state, X sends its Z-destined traffic to B with a top
label, which is the LDP label bound by B for FEC Z. B swaps that top label, which is the LDP label bound by B for FEC Z. B swaps that top
label for the LDP label bound by E for FEC Z and forwards to E. E pops label for the LDP label bound by E for FEC Z and forwards to E. E pops
the LDP label and forwards to Z.</t> the LDP label and forwards to Z.</t>
<t pn="section-4.3-7">Upon failure of the link BE, B swaps the incoming
<t>Upon failure of the link BE, B swaps the incoming top label with top label with
the node segment for Z (203) and sends the packet onto a repair tunnel the node segment for Z (203) and sends the packet onto a repair tunnel
to G (node segment 106 followed by adjacency segment 9001). Thus, B to G (node segment 106 followed by adjacency segment 9001). Thus, B
sends the packet to C with the label stack {106, 9001, 203}.&nbsp; C pop s sends the packet to C with the label stack {106, 9001, 203}.  C pops
the node segment 106 and forwards to F. F pops the adjacency segment the node segment 106 and forwards to F. F pops the adjacency segment
9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's 9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's
next-hop to Z is not SR capable, and thus, E swaps the incoming node next hop to Z is not SR capable, and thus, E swaps the incoming node
segment 203 for the LDP label announced by its next-hop (in this case, segment 203 for the LDP label announced by its next hop (in this case,
implicit null).</t> implicit NULL).</t>
<t pn="section-4.3-8">After IGP convergence, B's MPLS entry to Z will be
<t>After IGP convergence, B's MPLS entry to Z will become:</t> come:</t>
<ul empty="true" bare="false" spacing="normal" pn="section-4.3-9">
<figure> <li pn="section-4.3-9.1">
<artwork><![CDATA[ <t pn="section-4.3-9.1.1">Incoming label: local LDP label bound by B
- Incoming label: local LDP label bound by B for FEC Z for FEC Z</t>
Outgoing label: LDP label bound by C for FEC Z <ul empty="false" bare="false" spacing="normal" pn="section-4.3-9.1.
Outgoing next-hop: C]]></artwork> 2">
</figure> <li pn="section-4.3-9.1.2.1">Outgoing label: LDP label bound by C
for FEC Z </li>
<t/> <li pn="section-4.3-9.1.2.2">Outgoing next hop: C </li>
</ul>
<t>And the traffic XZ travels again over the LDP LSP.</t> </li>
</ul>
<t>Conclusions:</t> <t pn="section-4.3-10">And the traffic XZ travels again over the LDP LSP
.</t>
<t><list style="symbols"> <t pn="section-4.3-11">Conclusions:</t>
<t>the operator has eliminated its second problem: guaranteed FRR <ul spacing="normal" bare="false" empty="false" pn="section-4.3-12">
<li pn="section-4.3-12.1">the operator has eliminated its second probl
em: guaranteed FRR
coverage is provided. The steady-state traffic is still coverage is provided. The steady-state traffic is still
transported over LDP. The SR deployment is confined to the area transported over LDP. The SR deployment is confined to the area
where these benefits are required.</t> where these benefits are required.</li>
<li pn="section-4.3-12.2">FRR coverage has been achieved without any s
<t>FRR coverage has been achieved without any signaling for ignaling for
setting up the repair LSP and without setting up a targeted LDP setting up the repair LSP and without setting up a targeted LDP
session between B and G.</t> session between B and G.</li>
</list></t> </ul>
</section> </section>
<section anchor="sec-5.4" numbered="true" toc="include" removeInRFC="false
<section anchor="section-5.4" " pn="section-4.4">
title="Inter-AS Option C, Carrier's Carrier"> <name slugifiedName="name-inter-as-option-c-carriers-">Inter-AS Option C
<t>In inter-AS Option C <xref target="RFC4364"/>, two interconnected , Carrier's Carrier</name>
<t pn="section-4.4-1">In inter-AS Option C <xref target="RFC4364" format
="default" sectionFormat="of" derivedContent="RFC4364"/>, two interconnected
ASes sets up inter-AS MPLS connectivity. SR may be independently ASes sets up inter-AS MPLS connectivity. SR may be independently
deployed in each AS.</t> deployed in each AS.</t>
<figure anchor="ref-inter-as-option-c" align="left" suppress-title="fals
<figure anchor="ref-inter-as-option-c" title="Inter-AS Option C"> e" pn="figure-4">
<artwork><![CDATA[ <name slugifiedName="name-inter-as-option-c">Inter-AS Option C</name>
<artwork name="" type="" align="left" alt="" pn="section-4.4-2.1">
PE1---R1---B1---B2---R2---PE2 PE1---R1---B1---B2---R2---PE2
<-----------> <-----------&gt; <-----------&gt; &lt;-----------&gt;
AS1 AS2 AS1 AS2
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-4.4-3">In Inter-AS Option C, B2 advertises to B1 a labele
<t>In Inter-AS Option C, B2 advertises to B1 a labeled BGP route <xref d BGP route <xref target="RFC8277" format="default" sectionFormat="of" derivedCo
target="RFC8277"/> for PE2, and B1 reflects it to its internal peers, ntent="RFC8277"/> for PE2, and B1 reflects it to its
e.g., PE1. PE1 learns from a service route reflector a service internal peers, e.g., PE1. PE1 learns from a service route reflector a
route whose next-hop is PE2. PE1 resolves that service route on the service route whose next hop is PE2. PE1 resolves that service route
labeled BGP route to PE2. That labeled BGP route to PE2 is itself on the labeled BGP route to PE2. That labeled BGP route to PE2 is
resolved on the AS1 IGP route to B1.</t> itself resolved on the AS1 IGP route to B1.</t>
<t pn="section-4.4-4">If AS1 operates SR, then the tunnel from PE1 to B1
<t>If AS1 operates SR, then the tunnel from PE1 to B1 is provided by is provided by
the node segment from PE1 to B1.</t> the node segment from PE1 to B1.</t>
<t pn="section-4.4-5">PE1 sends a service packet with three labels: the
<t>PE1 sends a service packet with three labels: the top one is the top one is the
node segment to B1, the next one is the label in the labeled BGP route node segment to B1, the next one is the label in the labeled BGP route
provided by B1 for the route "PE2", and the bottom one is the service provided by B1 for the route "PE2", and the bottom one is the service
label allocated by PE2.</t> label allocated by PE2.</t>
</section> </section>
</section> </section>
<section anchor="sec-6" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="section-6" title="IANA Considerations"> ="section-5">
<t> This document has no IANA actions. </t> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t pn="section-5-1"> This document has no IANA actions. </t>
</section> </section>
<section anchor="sec-7" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="section-7" title="Manageability Considerations"> ="section-6">
<section anchor="section-7.1" title="SR and LDP Coexistence"> <name slugifiedName="name-manageability-consideration">Manageability Consi
<t>When both SR and LDP coexist, the following applies:</t> derations</name>
<section anchor="sec-7.1" numbered="true" toc="include" removeInRFC="false
<t><list style="symbols"> " pn="section-6.1">
<t>If both SR and LDP propose an IP2MPLS entry for the same IP <name slugifiedName="name-sr-and-ldp-coexistence">SR and LDP Coexistence
prefix, then by default the LDP route SHOULD be selected. This is </name>
<t pn="section-6.1-1">When both SR and LDP coexist, the following applie
s:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-6.1-2">
<li pn="section-6.1-2.1">If both SR and LDP propose an IP2MPLS entry f
or the same IP
prefix, then by default the LDP route <bcp14>SHOULD</bcp14> be selec
ted. This is
because it is expected that SR is introduced into networks that because it is expected that SR is introduced into networks that
contain routers that do not support SR. Hence, by having a behavior contain routers that do not support SR. Hence, by having a behavior
that prefers LDP over SR, traffic flow is unlikely to be that prefers LDP over SR, traffic flow is unlikely to be
disrupted</t> disrupted.</li>
<li pn="section-6.1-2.2">A local policy on a router <bcp14>MUST</bcp14
<t>A local policy on a router MUST allow to prefer the SR-provided > allow to prefer the SR-provided
IP2MPLS entry.</t> IP2MPLS entry.</li>
<li pn="section-6.1-2.3">Note that this policy <bcp14>MAY</bcp14> be l
<t>Note that this policy MAY be locally defined. There is no ocally defined. There is no
requirement that all routers use the same policy.</t> requirement that all routers use the same policy.</li>
</list></t> </ul>
</section> </section>
<section anchor="sec-7.3" numbered="true" toc="include" removeInRFC="false
<section anchor="section-7.3" title="Data-Plane Verification"> " pn="section-6.2">
<t>When Label switch paths (LSPs) are defined by stitching LDP LSPs <name slugifiedName="name-data-plane-verification">Data-Plane Verificati
on</name>
<t pn="section-6.2-1">When Label switch paths (LSPs) are defined by stit
ching LDP LSPs
with SR LSPs, it is necessary to have mechanisms allowing the with SR LSPs, it is necessary to have mechanisms allowing the
verification of the LSP connectivity as well as validation of the verification of the LSP connectivity as well as validation of the
path. These mechanisms are described in <xref target="RFC8287"/>.</t> path. These mechanisms are described in <xref target="RFC8287" format="d efault" sectionFormat="of" derivedContent="RFC8287"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec-8" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="section-8" title="Security Considerations"> ="section-7">
<t>This document does not introduce any change to the MPLS data plane <name slugifiedName="name-security-considerations">Security Considerations
<xref target="RFC3031"/> and therefore no additional security of the </name>
<t pn="section-7-1">This document does not introduce any change to the MPL
S data plane
<xref target="RFC3031" format="default" sectionFormat="of" derivedContent=
"RFC3031"/> and therefore no additional security of the
MPLS data plane is required.</t> MPLS data plane is required.</t>
<t pn="section-7-2">
<!-- [rfced] Please clarify this text. Perhaps this is the result
of a copy/paste error. How should it be rewritten?
Original:
Because this document recognizes
that reachability, which presents a different risk profile. This
document miscofiguration and/or programming may result in false or
conflicting also specifies a mechanism by which the ill effects of
advertising label binding advertisements, thereby compromising
traffic conflicting label bindings can be mitigated. In particular,
forwarding, the document recommends strict configuration/
advertisements from the node advertising the IP reachability is more
programmability control as well as montoring the SID advertised and
preferred than the centralized one. log/error messages by the
operator to avoid or at least significantly minimize the possibility
of such risk.
new suggestions from authors:
"This document recognizes that errors in configuration and/or programming may
result in false or conflicting label binding advertisements compromising
traffic forwarding. Therefore, this document recommends the operator the
strict configuration/programmability control, the monitoring of the advertised
SIDs, the preference of an IP reachability SID advertisement over a
centralized SID advertisement and the logging of any error message in order to
avoid, or at least significantly minimize, the possibility of such risk."
<t>
This document introduces another form of label binding advertisements. The This document introduces another form of label binding advertisements. The
security associated with these advertisements is part of the security applied security associated with these advertisements is part of the security applied
to routing protocols such as IS-IS <xref target="RFC5304"/> and OSPF <xref to routing protocols such as IS-IS <xref target="RFC5304" format="default" secti
target="RFC5709"/>, which both optionally make use of cryptographic onFormat="of" derivedContent="RFC5304"/>
authentication mechanisms. This form of advertisement is more centralized, on and OSPF <xref target="RFC5709" format="default" sectionFormat="of" derivedConte
behalf of the node advertising the IP reachability, which presents a different nt="RFC5709"/>, which both optionally make
risk profile. This document also specifies a mechanism by which the ill use of cryptographic authentication mechanisms. This form of advertisement is
effects of advertising conflicting label bindings can be mitigated. In more centralized, on behalf of the node advertising the IP reachability, which
particular, advertisements from the node advertising the IP reachability is presents a different risk profile. This document also specifies a mechanism by
more preferred than the centralized one. Because this document recognizes that which the ill effects of advertising conflicting label bindings can be
reachability, which presents a different risk profile. This document mitigated. In particular, advertisements from the node advertising the IP
misconfiguration and/or programming may result in false or conflicting also reachability is more preferred than the centralized one. This document
specifies a mechanism by which the ill effects of advertising label binding recognizes that errors in configuration and/or programming may result in false
advertisements, thereby compromising traffic conflicting label bindings can be or conflicting label binding advertisements compromising traffic
mitigated. In particular, forwarding, the document recommends strict forwarding. Therefore, this document recommends the operator implement strict
configuration/ advertisements from the node advertising the IP reachability is configuration/programmability control, the monitoring of the advertised SIDs,
more programmability control as well as monitoring the SID advertised and the preference of an IP reachability SID Advertisement over a centralized SID
preferred than the centralized one. log/error messages by the operator to Advertisement, and the logging of any error message in order to avoid, or at
avoid or at least significantly minimize the possibility of such risk.</t> least significantly minimize, the possibility of such risk.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-8">
<name slugifiedName="name-references">References</name>
<?rfc include="reference.RFC.2119" ?> <references pn="section-8.1">
<?rfc include="reference.RFC.8174"?> <name slugifiedName="name-normative-references">Normative References</na
me>
<?rfc include="reference.RFC.5036" ?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<?rfc include="reference.RFC.8402" ?> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<!-- draft-ietf-spring-segment-routing-mpls in C340 --> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660"> le>
<front> <author initials="S." surname="Bradner" fullname="S. Bradner">
<title>Segment Routing with MPLS Data Plane</title> <organization showOnFrontPage="true"/>
<author initials='A' surname='Bashandy' fullname="Ahmed Bashandy" role="editor"> </author>
<organization/> <date year="1997" month="March"/>
</author> <abstract>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils' role="edito <t>In many standards track documents several words are used to sig
r"> nify the requirements in the specification. These words are often capitalized.
<organization/> This document defines these words as they should be interpreted in IETF document
</author> s. This document specifies an Internet Best Current Practices for the Internet
<author initials='S' surname='Previdi' fullname="Stefano Previdi"> Community, and requests discussion and suggestions for improvements.</t>
<organization/> </abstract>
</author> </front>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'> <seriesInfo name="BCP" value="14"/>
<organization/> <seriesInfo name="RFC" value="2119"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'> </reference>
<organization/> <reference anchor="RFC5036" target="https://www.rfc-editor.org/info/rfc5
</author> 036" quoteTitle="true" derivedAnchor="RFC5036">
<author initials='R' surname='Shakir' fullname='Rob Shakir'> <front>
<organization/> <title>LDP Specification</title>
</author> <author initials="L." surname="Andersson" fullname="L. Andersson" ro
<date month='September' year='2019'/> le="editor">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name="RFC" value="8660"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC8660"/> <author initials="I." surname="Minei" fullname="I. Minei" role="edit
</reference> or">
<organization showOnFrontPage="true"/>
</references> </author>
<author initials="B." surname="Thomas" fullname="B. Thomas" role="ed
<references title="Informative References"> itor">
<organization showOnFrontPage="true"/>
<?rfc include="reference.RFC.8355" ?> </author>
<?rfc include="reference.RFC.3031" ?> <date year="2007" month="October"/>
<?rfc include="reference.RFC.8287" ?> <abstract>
<?rfc include="reference.RFC.3209" ?> <t>The architecture for Multiprotocol Label Switching (MPLS) is de
<?rfc include="reference.RFC.4364" ?> scribed in RFC 3031. A fundamental concept in MPLS is that two Label Switching
<?rfc include="reference.RFC.5304" ?> Routers (LSRs) must agree on the meaning of the labels used to forward traffic b
<?rfc include="reference.RFC.5709" ?> etween and through them. This common understanding is achieved by using a set o
<?rfc include="reference.RFC.5960" ?> f procedures, called a label distribution protocol, by which one LSR informs ano
<?rfc include="reference.RFC.7490" ?> ther of label bindings it has made. This document defines a set of such procedu
<?rfc include="reference.RFC.8277" ?> res called LDP (for Label Distribution Protocol) by which LSRs distribute labels
to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]</t>
<!-- I-D.ietf-isis-segment-routing-extensions: I-D exists --> </abstract>
<reference anchor='RFC8667'> </front>
<front> <seriesInfo name="RFC" value="5036"/>
<title>IS-IS Extensions for Segment Routing</title> <seriesInfo name="DOI" value="10.17487/RFC5036"/>
</reference>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<organization /> 174" quoteTitle="true" derivedAnchor="RFC8174">
</author> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<author initials='L' surname='Ginsberg' fullname='Les Ginsberg'> tle>
<organization /> <author initials="B." surname="Leiba" fullname="B. Leiba">
</author> <organization showOnFrontPage="true"/>
</author>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'> <date year="2017" month="May"/>
<organization /> <abstract>
</author> <t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'> t only UPPERCASE usage of the key words have the defined special meanings.</t>
<organization /> </abstract>
</author> </front>
<seriesInfo name="BCP" value="14"/>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'> <seriesInfo name="RFC" value="8174"/>
<organization /> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</author> </reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
<author initials='B' surname='Decraene' fullname='Bruno Decraene'> 402" quoteTitle="true" derivedAnchor="RFC8402">
<organization /> <front>
</author> <title>Segment Routing Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
<date month='September' year='2019' /> ="editor">
<organization showOnFrontPage="true"/>
</front> </author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
<seriesInfo name='RFC' value='8667' /> editor">
<seriesInfo name='DOI' value='10.17487/RFC8667'/> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<!-- &I-D.ietf-ospf-ospfv3-segment-routing-extensions;--> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC8666"> <author initials="B." surname="Decraene" fullname="B. Decraene">
<front> <organization showOnFrontPage="true"/>
<title>OSPFv3 Extensions for Segment Routing</title> </author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<author initials='P' surname='Psenak' fullname='Peter Psenak' role="editor"> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'> </author>
<organization /> <date year="2018" month="July"/>
</author> <abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A
<date month='September' year='2019' /> node steers a packet through an ordered list of instructions, called "segments".
A segment can represent any instruction, topological or service based. A segm
</front> ent can have a semantic local to an SR node or global within an SR domain. SR p
rovides a mechanism that allows a flow to be restricted to a specific topologica
<seriesInfo name='RFC' value='8666' /> l path, while maintaining per-flow state only at the ingress node(s) to the SR d
<seriesInfo name='DOI' value='10.17487/RFC8666'/> omain.</t>
</reference> <t>SR can be directly applied to the MPLS architecture with no cha
nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered
<!-- I-D.ietf-ospf-segment-routing-extensions: I-D exists --> list of segments is encoded as a stack of labels. The segment to process is on
the top of the stack. Upon completion of a segment, the related label is poppe
<reference anchor="RFC8665"> d from the stack.</t>
<front> <t>SR can be applied to the IPv6 architecture, with a new type of
<title>OSPF Extensions for Segment Routing</title> routing header. A segment is encoded as an IPv6 address. An ordered list of se
gments is encoded as an ordered list of IPv6 addresses in the routing header. T
<author initials='P' surname='Psenak' fullname='Peter Psenak' role="editor"> he active segment is indicated by the Destination Address (DA) of the packet. T
<organization /> he next active segment is indicated by a pointer in the new routing header.</t>
</author> </abstract>
</front>
<author initials='S' surname='Previdi' fullname='Stefano Previdi' role="editor"> <seriesInfo name="RFC" value="8402"/>
<organization /> <seriesInfo name="DOI" value="10.17487/RFC8402"/>
</author> </reference>
<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'> 660" quoteTitle="true" derivedAnchor="RFC8660">
<organization /> <front>
</author> <title>Segment Routing with MPLS Data Plane</title>
<seriesInfo name="RFC" value="8660"/>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'> <seriesInfo name="DOI" value="10.17487/RFC8660"/>
<organization /> <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
</author> le="editor">
<organization showOnFrontPage="true"/>
<author initials='R' surname='Shakir' fullname='Rob Shakir'> </author>
<organization /> <author initials="C" surname="Filsfils" fullname="Clarence
</author> Filsfils" role="editor">
<organization showOnFrontPage="true"/>
<author initials='W' surname='Henderickx' fullname='Wim Henderickx'> </author>
<organization /> <author initials="S" surname="Previdi" fullname="Stefano Previdi">
</author> <organization showOnFrontPage="true"/>
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'> <author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization /> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S" surname="Litkowski" fullname="Stephane
<date month='September' year='2019' /> Litkowski">
<organization showOnFrontPage="true"/>
</front> </author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<seriesInfo name='RFC' value='8665' /> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC8665'/> </author>
</reference> <date month="December" year="2019"/>
</front>
</reference>
</references>
<references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3
031" quoteTitle="true" derivedAnchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Viswanathan" fullname="A. Viswanathan
">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="January"/>
<abstract>
<t>This document specifies the architecture for Multiprotocol Labe
l Switching (MPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<seriesInfo name="DOI" value="10.17487/RFC3031"/>
</reference>
<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3
209" quoteTitle="true" derivedAnchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author initials="D." surname="Awduche" fullname="D. Awduche">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Gan" fullname="D. Gan">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="December"/>
<abstract>
<t>This document describes the use of RSVP (Resource Reservation P
rotocol), including all the necessary extensions, to establish label-switched pa
ths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LS
P is completely identified by the label applied at the ingress node of the path,
these paths may be treated as tunnels. A key application of LSP tunnels is tra
ffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3209"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>
<reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4
364" quoteTitle="true" derivedAnchor="RFC4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="February"/>
<abstract>
<t>This document describes a method by which a Service Provider ma
y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
mers. This method uses a "peer model", in which the customers' edge routers (CE
routers) send their routes to the Service Provider's edge routers (PE routers);
there is no "overlay" visible to the customer's routing algorithm, and CE route
rs at different sites do not peer with each other. Data packets are tunneled th
rough the backbone, so that the core routers do not need to know the VPN routes.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4364"/>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
</reference>
<reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5
304" quoteTitle="true" derivedAnchor="RFC5304">
<front>
<title>IS-IS Cryptographic Authentication</title>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="October"/>
<abstract>
<t>This document describes the authentication of Intermediate Syst
em to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Me
ssage Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in R
FC 2104. IS-IS is specified in International Standards Organization (ISO) 10589
, with extensions to support Internet Protocol version 4 (IPv4) described in RFC
1195. The base specification includes an authentication mechanism that allows
for multiple authentication algorithms. The base specification only specifies t
he algorithm for cleartext passwords. This document replaces RFC 3567.</t>
<t>This document proposes an extension to that specification that
allows the use of the HMAC-MD5 authentication algorithm to be used in conjunctio
n with the existing authentication mechanisms. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5304"/>
<seriesInfo name="DOI" value="10.17487/RFC5304"/>
</reference>
<reference anchor="RFC5709" target="https://www.rfc-editor.org/info/rfc5
709" quoteTitle="true" derivedAnchor="RFC5709">
<front>
<title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Fanto" fullname="M. Fanto">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="White" fullname="R. White">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Barnes" fullname="M. Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Atkinson" fullname="R. Atkinson">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="October"/>
<abstract>
<t>This document describes how the National Institute of Standards
and Technology (NIST) Secure Hash Standard family of algorithms can be used wit
h OSPF version 2's built-in, cryptographic authentication mechanism. This updat
es, but does not supercede, the cryptographic authentication mechanism specified
in RFC 2328. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5709"/>
<seriesInfo name="DOI" value="10.17487/RFC5709"/>
</reference>
<reference anchor="RFC5960" target="https://www.rfc-editor.org/info/rfc5
960" quoteTitle="true" derivedAnchor="RFC5960">
<front>
<title>MPLS Transport Profile Data Plane Architecture</title>
<author initials="D." surname="Frost" fullname="D. Frost" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Bryant" fullname="S. Bryant" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bocci" fullname="M. Bocci" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="August"/>
<abstract>
<t>The Multiprotocol Label Switching Transport Profile (MPLS-TP) i
s the set of MPLS protocol functions applicable to the construction and operatio
n of packet-switched transport networks. This document specifies the subset of
these functions that comprises the MPLS-TP data plane: the architectural layer c
oncerned with the encapsulation and forwarding of packets within an MPLS-TP netw
ork.</t>
<t>This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union Telecommunication Standard
ization Sector (ITU-T) effort to include an MPLS Transport Profile within the IE
TF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support th
e capabilities and functionalities of a packet transport network. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5960"/>
<seriesInfo name="DOI" value="10.17487/RFC5960"/>
</reference>
<reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7
490" quoteTitle="true" derivedAnchor="RFC7490">
<front>
<title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
<author initials="S." surname="Bryant" fullname="S. Bryant">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Shand" fullname="M. Shand">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="So" fullname="N. So">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="April"/>
<abstract>
<t>This document describes an extension to the basic IP fast rerou
te mechanism, described in RFC 5286, that provides additional backup connectivit
y for point-to-point link failures when none can be provided by the basic mechan
isms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7490"/>
<seriesInfo name="DOI" value="10.17487/RFC7490"/>
</reference>
<reference anchor="RFC8277" target="https://www.rfc-editor.org/info/rfc8
277" quoteTitle="true" derivedAnchor="RFC8277">
<front>
<title>Using BGP to Bind MPLS Labels to Address Prefixes</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="October"/>
<abstract>
<t>This document specifies a set of procedures for using BGP to ad
vertise that a specified router has bound a specified MPLS label (or a specified
sequence of MPLS labels organized as a contiguous part of a label stack) to a s
pecified address prefix. This can be done by sending a BGP UPDATE message whose
Network Layer Reachability Information field contains both the prefix and the M
PLS label(s) and whose Next Hop field identifies the node at which said prefix i
s bound to said label(s). This document obsoletes RFC 3107.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8277"/>
<seriesInfo name="DOI" value="10.17487/RFC8277"/>
</reference>
<reference anchor="RFC8287" target="https://www.rfc-editor.org/info/rfc8
287" quoteTitle="true" derivedAnchor="RFC8287">
<front>
<title>Label Switched Path (LSP) Ping/Traceroute for Segment Routing
(SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Pla
nes</title>
<author initials="N." surname="Kumar" fullname="N. Kumar" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Akiya" fullname="N. Akiya">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Kini" fullname="S. Kini">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Chen" fullname="M. Chen">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="December"/>
<abstract>
<t>A Segment Routing (SR) architecture leverages source routing an
d tunneling paradigms and can be directly applied to the use of a Multiprotocol
Label Switching (MPLS) data plane. A node steers a packet through a controlled
set of instructions called "segments" by prepending the packet with an SR header
.</t>
<t>The segment assignment and forwarding semantic nature of SR rai
ses additional considerations for connectivity verification and fault isolation
for a Label Switched Path (LSP) within an SR architecture. This document illustr
ates the problem and defines extensions to perform LSP Ping and Traceroute for S
egment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an M
PLS data plane.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8287"/>
<seriesInfo name="DOI" value="10.17487/RFC8287"/>
</reference>
<reference anchor="RFC8355" target="https://www.rfc-editor.org/info/rfc8
355" quoteTitle="true" derivedAnchor="RFC8355">
<front>
<title>Resiliency Use Cases in Source Packet Routing in Networking (
SPRING) Networks</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>This document identifies and describes the requirements for a s
et of use cases related to Segment Routing network resiliency on Source Packet R
outing in Networking (SPRING) networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8355"/>
<seriesInfo name="DOI" value="10.17487/RFC8355"/>
</reference>
<reference anchor="RFC8665" quoteTitle="true" target="https://doi.org/10
.17487/RFC8665" derivedAnchor="RFC8665">
<front>
<title>OSPF Extensions for Segment Routing</title>
<seriesInfo name="RFC" value="8665"/>
<seriesInfo name="DOI" value="10.17487/RFC8665"/>
<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence
Filsfils">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Gredler" fullname="Hannes Gredler">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<organization showOnFrontPage="true"/>
</author>
<author initials="W" surname="Henderickx" fullname="Wim Hend
erickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<reference anchor="RFC8666" quoteTitle="true" target="https://doi.org/10
.17487/RFC8666" derivedAnchor="RFC8666">
<front>
<title>OSPFv3 Extensions for Segment Routing</title>
<seriesInfo name="RFC" value="8666"/>
<seriesInfo name="DOI" value="10.17487/RFC8666"/>
<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<reference anchor="RFC8667" quoteTitle="true" target="https://doi.org/10
.17487/RFC8667" derivedAnchor="RFC8667">
<front>
<title>IS-IS Extensions for Segment Routing</title>
<seriesInfo name="RFC" value="8667"/>
<seriesInfo name="DOI" value="10.17487/RFC8667"/>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Ginsberg" fullname="Les Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence
Filsfils">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Gredler" fullname="Hannes Gredler">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="Appendix-A" numbered="true" toc="include" removeInRFC="fals
<section anchor="Appendix-A" title="Migration from LDP to SR"> e" pn="section-appendix.a">
<figure anchor="ref-migration" title="Migration"> <name slugifiedName="name-migration-from-ldp-to-sr">Migration from LDP to
<artwork><![CDATA[ SR</name>
<figure anchor="ref-migration" align="left" suppress-title="false" pn="fig
ure-5">
<name slugifiedName="name-migration">Migration</name>
<artwork name="" type="" align="left" alt="" pn="section-appendix.a-1.1"
>
PE2 PE4 PE2 PE4
\ / \ /
PE1----P5--P6--P7---PE3 PE1----P5--P6--P7---PE3
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-appendix.a-2">Several migration techniques are possible. Th
<t>Several migration techniques are possible. The technique described e technique described
here is inspired by the commonly used method to migrate from one IGP to here is inspired by the commonly used method to migrate from one IGP to
another.</t> another.</t>
<t pn="section-appendix.a-3">At time T0, all the routers run LDP. Any serv
<t>At time T0, all the routers run LDP. Any service is tunneled from an ice is tunneled from an
ingress PE to an egress PE over a continuous LDP LSP.</t> ingress PE to an egress PE over a continuous LDP LSP.</t>
<t pn="section-appendix.a-4">At time T1, all the routers are upgraded to S
<t>At time T1, all the routers are upgraded to SR. They are configured R. They are configured
with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6, and P7 are with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6, and P7 are
respectively configured with the node segments 101, 102, 103, 104, 105, respectively configured with the node segments 101, 102, 103, 104, 105,
106, and 107 (attached to their service-recursing loopback).</t> 106, and 107 (attached to their service-recursing loopback).
</t>
<t><list hangIndent="3" style="hanging"> <aside pn="section-appendix.a-5">
<t>At this time, the service traffic is still tunneled over LDP LSPs. <t pn="section-appendix.a-5.1">
Note: At this time, the service traffic is still tunneled over LDP LSP
s.
For example, PE1 has an SR node segment to PE3 and an LDP LSP to PE3. For example, PE1 has an SR node segment to PE3 and an LDP LSP to PE3.
As seen earlier, however, the LDP IP2MPLS encapsulation is As seen earlier, however, the LDP IP2MPLS encapsulation is
preferred by default. However, it has to be noted that the SR infrastr ucture is preferred by default. However, it has to be noted that the SR infrastr ucture is
usable, e.g., for Fast Reroute (FRR) or IGP Loop-Free Convergence to usable, e.g., for Fast Reroute (FRR) or IGP Loop-Free Convergence to
protect existing IP and LDP traffic. FRR mechanisms are described in protect existing IP and LDP traffic. FRR mechanisms are described in
<xref target="RFC8355"/>.</t> <xref target="RFC8355" format="default" sectionFormat="of" derivedCont
</list></t> ent="RFC8355"/>.
</t>
<t>At time T2, the operator enables the local policy at PE1 to prefer SR </aside>
<t pn="section-appendix.a-6">At time T2, the operator enables the local po
licy at PE1 to prefer SR
IP2MPLS encapsulation over LDP IP2MPLS.</t> IP2MPLS encapsulation over LDP IP2MPLS.</t>
<ul empty="true" indent="3" bare="false" spacing="normal" pn="section-appe
<t><list hangIndent="3" style="hanging"> ndix.a-7">
<t>The service from PE1 to any other PE is now riding over SR. All <li pn="section-appendix.a-7.1">The service from PE1 to any other PE is
other service traffic is still transported over LDP LSPs.</t> now riding over SR. All
</list></t> other service traffic is still transported over LDP LSPs.</li>
</ul>
<t>At time T3, gradually, the operator enables the preference for SR <t pn="section-appendix.a-8">At time T3, gradually, the operator enables t
he preference for SR
IP2MPLS encapsulation across all the edge routers.</t> IP2MPLS encapsulation across all the edge routers.</t>
<ul empty="true" indent="3" bare="false" spacing="normal" pn="section-appe
<t><list hangIndent="3" style="hanging"> ndix.a-9">
<t>All the service traffic is now transported over SR. LDP is still <li pn="section-appendix.a-9.1">All the service traffic is now transport
operational and services could be reverted to LDP.</t> ed over SR. LDP is still
</list></t> operational and services could be reverted to LDP.</li>
</ul>
<t><list hangIndent="3" style="hanging"> <t pn="section-appendix.a-10">At time T4, LDP is unconfigured from all rou
<t/> ters.</t>
</list></t>
<t>At time T4, LDP is unconfigured from all routers.</t>
</section> </section>
<section anchor="sec-9" numbered="false" toc="include" removeInRFC="false" p
<section anchor="section-9" title="Acknowledgements" numbered= "no"> n="section-appendix.b">
<t>The authors would like to thank Pierre Francois, Ruediger Geib, and <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.b-1">The authors would like to thank Pierre Franco
is, Ruediger Geib, and
Alexander Vainshtein for their contributions to the content of this Alexander Vainshtein for their contributions to the content of this
document.</t> document.</t>
</section> </section>
<section anchor="sec-10" numbered="false" toc="include" removeInRFC="false"
<section anchor="section-10" title="Contributors" numbered="no"> pn="section-appendix.c">
<figure> <name slugifiedName="name-contributors">Contributors</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-appendix.c-1">
Edward Crabbe Edward Crabbe
Individual Individual
Email: edward.crabbe@gmail.com Email: edward.crabbe@gmail.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-2">
Igor Milojevic Igor Milojevic
Email: milojevicigor@gmail.com Email: milojevicigor@gmail.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-3">
Saku Ytti Saku Ytti
TDC TDC
Email: saku@ytti.fi Email: saku@ytti.fi</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-4">
Rob Shakir Rob Shakir
Google Google
Email: robjs@google.com Email: robjs@google.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-5">
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Email: Martin.Horneffer@telekom.de Email: Martin.Horneffer@telekom.de</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-6">
Wim Henderickx Wim Henderickx
Nokia Nokia
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-7">
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-8">
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
Email: ginsberg@cisco.com]]></artwork> Email: ginsberg@cisco.com</artwork>
</figure> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Ahmed Bashandy" initials="A." role="editor" surname="Bas
handy">
<organization showOnFrontPage="true">Individual</organization>
<address>
<postal>
<street>United States of America</street>
</postal>
<email>abashandy.ietf@gmail.com</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." role="editor" surname="
Filsfils">
<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Brussels</street>
<street>Belgium</street>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization showOnFrontPage="true">Huawei Technologies</organization>
<address>
<postal>
<street>Italy</street>
</postal>
<email>stefano@previdi.net</email>
</address>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization showOnFrontPage="true">Orange</organization>
<address>
<postal>
<street>France</street>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization showOnFrontPage="true">Orange</organization>
<address>
<postal>
<street>France</street>
</postal>
<email>slitkows.ietf@gmail.com</email>
</address>
</author>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 163 change blocks. 
899 lines changed or deleted 1672 lines changed or added

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