rfc8660xml2.original.xml   rfc8660.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF nsus="true" docName="draft-ietf-spring-segment-routing-mpls-22" indexInclude="tr
C.8402.xml"> ue" ipr="trust200902" number="8660" prepTime="2019-12-04T22:57:35" scripts="Comm
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF on,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocI
C.2119.xml"> nclude="true" xml:lang="en">
<!ENTITY RFC3031 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing
C.3031.xml"> -mpls-22" rel="prev"/>
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://dx.doi.org/10.17487/rfc8660" rel="alternate"/>
C.3032.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY RFC3443 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <front>
C.3443.xml"> <title>Segment Routing with the MPLS Data Plane</title>
<!ENTITY RFC5462 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <seriesInfo name="RFC" value="8660" stream="IETF"/>
C.5462.xml"> <author fullname="Ahmed Bashandy" initials="A." role="editor" surname="Basha
<!ENTITY RFC7274 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF ndy">
C.7274.xml"> <organization showOnFrontPage="true">Arrcus</organization>
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <address>
C.8174.xml"> <email>abashandy.ietf@gmail.com</email>
<!ENTITY I-D.ietf-isis-segment-routing-extensions SYSTEM "https://xml2rfc.ietf.o </address>
rg/public/rfc/bibxml3/reference.I-D.draft-ietf-isis-segment-routing-extensions-1 </author>
3.xml"> <author fullname="Clarence Filsfils" initials="C." role="editor" surname="Fi
<!ENTITY I-D.ietf-ospf-ospfv3-segment-routing-extensions SYSTEM "https://xml2rfc lsfils">
.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-ospfv3-segment-routin <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
g-extensions-09.xml"> <address>
<!ENTITY I-D.ietf-ospf-segment-routing-extensions SYSTEM "https://xml2rfc.ietf.o <postal>
rg/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-segment-routing-extensions-1 <street>Brussels</street>
6.xml"> <street>Belgium</street>
<!ENTITY I-D.ietf-spring-segment-routing-ldp-interop SYSTEM "https://xml2rfc.iet </postal>
f.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-ldp-int <email>cfilsfil@cisco.com</email>
erop-08.xml"> </address>
<!ENTITY I-D.bashandy-rtgwg-segment-routing-ti-lfa SYSTEM "https://xml2rfc.ietf. </author>
org/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-ti-lfa.xml"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<!ENTITY RFC7855 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
C.7855.xml"> <address>
<!ENTITY RFC5036 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <postal>
C.5036.xml"> <street>Italy</street>
<!ENTITY RFC5331 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </postal>
C.5331.xml"> <email>stefano@previdi.net</email>
<!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </address>
C.7510.xml"> </author>
<!ENTITY RFC4817 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <author fullname="Bruno Decraene" initials="B." surname="Decraene">
C.4817.xml"> <organization showOnFrontPage="true">Orange</organization>
<!ENTITY RFC8287 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <address>
C.8287.xml"> <postal>
<!ENTITY RFC8403 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <street>France</street>
C.8403.xml"> </postal>
<!ENTITY I-D.ietf-spring-segment-routing-policy SYSTEM "https://xml2rfc.ietf.org <email>bruno.decraene@orange.com</email>
/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-policy.xml"> </address>
]> </author>
<rfc submissionType="IETF" docName="draft-ietf-spring-segment-routing-mpls-22" c <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
ategory="std"> <organization showOnFrontPage="true">Orange</organization>
<!-- Generated by id2xml 1.4.4 on 2019-06-12T17:23:43Z --> <address>
<?rfc compact="yes"?> <postal>
<?rfc text-list-symbols="o-*+-"?> <street>France</street>
<?rfc subcompact="no"?> </postal>
<?rfc sortrefs="no"?> <email>slitkows.ietf@gmail.com</email>
<?rfc symrefs="yes"?> </address>
<?rfc strict="yes"?> </author>
<?rfc toc="yes"?> <author fullname="Rob Shakir" initials="R." surname="Shakir">
<front> <organization showOnFrontPage="true">Google</organization>
<title>Segment Routing with MPLS data plane</title> <address>
<author fullname="Ahmed Bashandy" initials="A." role="editor" surname="Ba <postal>
shandy"> <street>United States of America</street>
<organization>Arrcus</organization> </postal>
<address><email>abashandy.ietf@gmail.com</email> <email>robjs@google.com</email>
</address> </address>
</author> </author>
<date month="12" year="2019"/>
<author fullname="Clarence Filsfils" initials="C." role="editor" surname= <abstract pn="section-abstract">
"Filsfils"> <t pn="section-abstract-1">
<organization>Cisco Systems, Inc.</organization> Segment Routing (SR) leverages the source-routing paradigm. A node
<address><postal><street>Brussels</street>
<street>BE</street>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc.</organization>
<address><postal><street>Italy</street>
</postal>
<email>stefano@previdi.net</email>
</address>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
<address><postal><street>FR</street>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization>Orange</organization>
<address><postal><street>FR</street>
</postal>
<email>stephane.litkowski@orange.com</email>
</address>
</author>
<author fullname="Rob Shakir" initials="R." surname="Shakir">
<organization>Google</organization>
<address><postal><street>US</street>
</postal>
<email>robjs@google.com</email>
</address>
</author>
<date day="1" month="May" year="2019"/>
<abstract><t>
Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through a controlled set of instructions, called steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header. In the MPLS segments, by prepending the packet with an SR header. In the MPLS
dataplane, the SR header is instantiated through a label stack. This data plane, the SR header is instantiated through a label stack. This
document specifies the forwarding behavior to allow instantiating SR document specifies the forwarding behavior to allow instantiating SR
over the MPLS dataplane.</t> over the MPLS data plane (SR-MPLS).</t>
</abstract>
</abstract> <boilerplate>
</front> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<middle> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<section title="Introduction" anchor="section-1"><t> >
The Segment Routing architecture RFC8402 can be directly applied to <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/rfc8660" 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-mpls-instantiation-of-seg
me">MPLS Instantiation of Segment Routing</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-multiple-forw
arding-behavio">Multiple Forwarding Behaviors for the Same Prefix</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derive
dContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sid-represent
ation-in-the-m">SID Representation in the MPLS Forwarding Plane</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t keepWithNext="true" pn="section-toc.1-1.2.2.3.1"><xref derive
dContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-segment-routi
ng-global-bloc">Segment Routing Global Block and Local Block</xref></t>
</li>
<li pn="section-toc.1-1.2.2.4">
<t keepWithNext="true" pn="section-toc.1-1.2.2.4.1"><xref derive
dContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-mapping-a-sid
-index-to-an-m">Mapping a SID Index to an MPLS Label</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5">
<t keepWithNext="true" pn="section-toc.1-1.2.2.5.1"><xref derive
dContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-incoming-labe
l-collision">Incoming Label Collision</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.5.2">
<li pn="section-toc.1-1.2.2.5.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.5.2.1.1"><xre
f derivedContent="2.5.1" format="counter" sectionFormat="of" target="section-2.5
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-t
iebreaking-rules">Tiebreaking Rules</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.5.2.2.1"><xre
f derivedContent="2.5.2" format="counter" sectionFormat="of" target="section-2.5
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-r
edistribution-between-rout">Redistribution between Routing Protocol Instances</x
ref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.6">
<t keepWithNext="true" pn="section-toc.1-1.2.2.6.1"><xref derive
dContent="2.6" format="counter" sectionFormat="of" target="section-2.6"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-effect-of-inc
oming-label-co">Effect of Incoming Label Collision on Outgoing Label Programming
</xref></t>
</li>
<li pn="section-toc.1-1.2.2.7">
<t keepWithNext="true" pn="section-toc.1-1.2.2.7.1"><xref derive
dContent="2.7" format="counter" sectionFormat="of" target="section-2.7"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-push-continue
-and-next">PUSH, CONTINUE, and NEXT</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.7.2">
<li pn="section-toc.1-1.2.2.7.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.7.2.1.1"><xre
f derivedContent="2.7.1" format="counter" sectionFormat="of" target="section-2.7
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-p
ush">PUSH</xref></t>
</li>
<li pn="section-toc.1-1.2.2.7.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.7.2.2.1"><xre
f derivedContent="2.7.2" format="counter" sectionFormat="of" target="section-2.7
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-c
ontinue">CONTINUE</xref></t>
</li>
<li pn="section-toc.1-1.2.2.7.2.3">
<t keepWithNext="true" pn="section-toc.1-1.2.2.7.2.3.1"><xre
f derivedContent="2.7.3" format="counter" sectionFormat="of" target="section-2.7
.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-n
ext">NEXT</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.8">
<t keepWithNext="true" pn="section-toc.1-1.2.2.8.1"><xref derive
dContent="2.8" format="counter" sectionFormat="of" target="section-2.8"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-mpls-label-do
wnloaded-to-th">MPLS Label Downloaded to the FIB for Global and Local SIDs</xref
></t>
</li>
<li pn="section-toc.1-1.2.2.9">
<t keepWithNext="true" pn="section-toc.1-1.2.2.9.1"><xref derive
dContent="2.9" format="counter" sectionFormat="of" target="section-2.9"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-active-segmen
t">Active Segment</xref></t>
</li>
<li pn="section-toc.1-1.2.2.10">
<t keepWithNext="true" pn="section-toc.1-1.2.2.10.1"><xref deriv
edContent="2.10" format="counter" sectionFormat="of" target="section-2.10"/>. <x
ref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-
behavior-for-glo">Forwarding Behavior for Global SIDs</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.10.2">
<li pn="section-toc.1-1.2.2.10.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.10.2.1.1"><xr
ef derivedContent="2.10.1" format="counter" sectionFormat="of" target="section-2
.10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-forwarding-for-push-and-con">Forwarding for PUSH and CONTINUE of Global SIDs</
xref></t>
</li>
<li pn="section-toc.1-1.2.2.10.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.10.2.2.1"><xr
ef derivedContent="2.10.2" format="counter" sectionFormat="of" target="section-2
.10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-forwarding-for-the-next-ope">Forwarding for the NEXT Operation for Global SIDs
</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2.2.11">
<t keepWithNext="true" pn="section-toc.1-1.2.2.11.1"><xref deriv
edContent="2.11" format="counter" sectionFormat="of" target="section-2.11"/>. <x
ref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-
behavior-for-loc">Forwarding Behavior for Local SIDs</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.11.2">
<li pn="section-toc.1-1.2.2.11.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.11.2.1.1"><xr
ef derivedContent="2.11.1" format="counter" sectionFormat="of" target="section-2
.11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-forwarding-for-the-push-ope">Forwarding for the PUSH Operation on Local SIDs</
xref></t>
</li>
<li pn="section-toc.1-1.2.2.11.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.11.2.2.1"><xr
ef derivedContent="2.11.2" format="counter" sectionFormat="of" target="section-2
.11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-forwarding-for-the-continue">Forwarding for the CONTINUE Operation for Local S
IDs</xref></t>
</li>
<li pn="section-toc.1-1.2.2.11.2.3">
<t keepWithNext="true" pn="section-toc.1-1.2.2.11.2.3.1"><xr
ef derivedContent="2.11.3" format="counter" sectionFormat="of" target="section-2
.11.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-outgoing-label-for-the-next">Outgoing Label for the NEXT Operation for Local S
IDs</xref></t>
</li>
</ul>
</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-iana-considerations">IANA
Considerations</xref></t>
</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-manageability-considerati
on">Manageability Considerations</xref></t>
</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-security-considerations">
Security 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-references">References</x
ref></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-normative-ref
erences">Normative References</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-informative-r
eferences">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-example
s">Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derive
dContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-igp-segment-e
xamples">IGP Segment Examples</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derive
dContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-incoming-labe
l-collision-ex">Incoming Label Collision Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.2.2">
<li pn="section-toc.1-1.7.2.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.1.1"><xre
f derivedContent="A.2.1" format="counter" sectionFormat="of" target="section-a.2
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-1">Example 1</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.2.1"><xre
f derivedContent="A.2.2" format="counter" sectionFormat="of" target="section-a.2
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-2">Example 2</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.3">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.3.1"><xre
f derivedContent="A.2.3" format="counter" sectionFormat="of" target="section-a.2
.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-3">Example 3</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.4">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.4.1"><xre
f derivedContent="A.2.4" format="counter" sectionFormat="of" target="section-a.2
.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-4">Example 4</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.5">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.5.1"><xre
f derivedContent="A.2.5" format="counter" sectionFormat="of" target="section-a.2
.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-5">Example 5</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.6">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.6.1"><xre
f derivedContent="A.2.6" format="counter" sectionFormat="of" target="section-a.2
.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-6">Example 6</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.7">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.7.1"><xre
f derivedContent="A.2.7" format="counter" sectionFormat="of" target="section-a.2
.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-7">Example 7</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.8">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.8.1"><xre
f derivedContent="A.2.8" format="counter" sectionFormat="of" target="section-a.2
.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-8">Example 8</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.9">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.9.1"><xre
f derivedContent="A.2.9" format="counter" sectionFormat="of" target="section-a.2
.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-9">Example 9</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.10">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.10.1"><xr
ef derivedContent="A.2.10" format="counter" sectionFormat="of" target="section-a
.2.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name
-example-10">Example 10</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.11">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.11.1"><xr
ef derivedContent="A.2.11" format="counter" sectionFormat="of" target="section-a
.2.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name
-example-11">Example 11</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.12">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.12.1"><xr
ef derivedContent="A.2.12" format="counter" sectionFormat="of" target="section-a
.2.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name
-example-12">Example 12</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.13">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.13.1"><xr
ef derivedContent="A.2.13" format="counter" sectionFormat="of" target="section-a
.2.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name
-example-13">Example 13</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2.2.14">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.14.1"><xr
ef derivedContent="A.2.14" format="counter" sectionFormat="of" target="section-a
.2.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name
-example-14">Example 14</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7.2.3">
<t keepWithNext="true" pn="section-toc.1-1.7.2.3.1"><xref derive
dContent="A.3" format="counter" sectionFormat="of" target="section-a.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-examples-for-
the-effect-of-">Examples for the Effect of Incoming Label Collision on an Outgoi
ng Label</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.3.2">
<li pn="section-toc.1-1.7.2.3.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.3.2.1.1"><xre
f derivedContent="A.3.1" format="counter" sectionFormat="of" target="section-a.3
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-1-2">Example 1</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.3.2.2.1"><xre
f derivedContent="A.3.2" format="counter" sectionFormat="of" target="section-a.3
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-e
xample-2-2">Example 2</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-acknowledgements">Ackno
wledgements</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-contributors">Contribut
ors</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.d"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
hors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="convert-section-1" numbered="true" toc="include" removeInRF
C="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
The Segment Routing architecture <xref target="RFC8402" format="default" sect
ionFormat="of" derivedContent="RFC8402"/> can be directly applied to
the MPLS architecture with no change in the MPLS forwarding plane. the MPLS architecture with no change in the MPLS forwarding plane.
This document specifies the forwarding plane behavior to allow This document specifies forwarding-plane behavior to allow
Segment Routing to operate on top of the MPLS data plane. This Segment Routing to operate on top of the MPLS data plane (SR-MPLS). This
document does not address the control plane behavior. Control plane document does not address control-plane behavior. Control-plane
behavior is specified in other documents such as <xref target="I-D.ietf-isis- behavior is specified in other documents such as <xref target="RFC8665" forma
segment-routing-extensions"/>, <xref target="I-D.ietf-ospf-segment-routing-exten t="default" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666
sions"/>, and <xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.< " format="default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref targ
/t> et="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>.</t>
<t pn="section-1-2">
<t> The Segment Routing problem statement is described in <xref target="RFC7855"
The Segment Routing problem statement is described in <xref target="RFC7855"/ format="default" sectionFormat="of" derivedContent="RFC7855"/>.</t>
>.</t> <t pn="section-1-3">
Coexistence of SR over the MPLS forwarding plane with LDP <xref target="RFC50
<t> 36" format="default" sectionFormat="of" derivedContent="RFC5036"/> is
Co-existence of SR over MPLS forwarding plane with LDP <xref target="RFC5036" specified in <xref target="RFC8661" format="default" sectionFormat="of" deriv
/> is edContent="RFC8661"/>.</t>
specified in <xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t <t pn="section-1-4">
> Policy routing and traffic engineering using Segment Routing can be
found in <xref target="ROUTING-POLICY" format="default" sectionFormat="of" de
<t> rivedContent="ROUTING-POLICY"/>.</t>
Policy routing and traffic engineering using segment routing can be <section anchor="convert-section-1.1" numbered="true" toc="include" remove
found in <xref target="I-D.ietf-spring-segment-routing-policy"/></t> InRFC="false" pn="section-1.1">
<name slugifiedName="name-requirements-language">Requirements Language</
<section title="Requirements Language" anchor="section-1.1"><t> name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t pn="section-1.1-1">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>R
"OPTIONAL" in this document are to be interpreted as described in BCP EQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SH
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the OULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp1
y appear in all 4>NOT RECOMMENDED</bcp14>",
capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
</section> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
</section> mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
<section title="MPLS Instantiation of Segment Routing" anchor="section-2" </section>
><t> </section>
<section anchor="convert-section-2" numbered="true" toc="include" removeInRF
C="false" pn="section-2">
<name slugifiedName="name-mpls-instantiation-of-segme">MPLS Instantiation
of Segment Routing</name>
<t pn="section-2-1">
MPLS instantiation of Segment Routing fits in the MPLS architecture MPLS instantiation of Segment Routing fits in the MPLS architecture
as defined in <xref target="RFC3031"/> both from a control plane and forwardi as defined in <xref target="RFC3031" format="default" sectionFormat="of" deri
ng vedContent="RFC3031"/> from both a control-plane and forwarding-plane
plane perspective:</t> perspective:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2-2">
<t><list style="symbols"><t>From a control plane perspective, <xref targe <li pn="section-2-2.1">From a control-plane perspective, <xref target="R
t="RFC3031"/> does not mandate a FC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> does not
mandate a
single signaling protocol. Segment Routing makes use of various single signaling protocol. Segment Routing makes use of various
control plane protocols such as link state IGPs <xref target="I-D.ietf-isi control-plane protocols such as link-state IGPs <xref target="RFC8665" for
s-segment-routing-extensions"/>, <xref target="I-D.ietf-ospf-segment-routing-ext mat="default" sectionFormat="of" derivedContent="RFC8665"/> <xref target="RFC866
ensions"/> and <xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>. 6" format="default" sectionFormat="of" derivedContent="RFC8666"/> <xref target="
The flooding mechanisms of link state IGPs fit very well with RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>.
label stacking on ingress. Future control layer protocol and/or The flooding mechanisms of link-state IGPs fit very well with
policy/configuration can be used to specify the label stack.</t> label stacking on the ingress. A future control-layer protocol and/or
policy/configuration can be used to specify the label stack.</li>
<t>From a forwarding plane perspective, Segment Routing does not <li pn="section-2-2.2">From a forwarding-plane perspective, Segment Rout
ing does not
require any change to the forwarding plane because Segment IDs require any change to the forwarding plane because Segment IDs
(SIDs) are instantiated as MPLS labels and the Segment routing (SIDs) are instantiated as MPLS labels, and the Segment Routing
header instantiated as a stack of MPLS labels.</t> header is instantiated as a stack of MPLS labels.</li>
</ul>
</list> <t pn="section-2-3">
</t> We call the "MPLS Control Plane Client (MCC)" any control-plane entity
<t>
We call "MPLS Control Plane Client (MCC)" any control plane entity
installing forwarding entries in the MPLS data plane. Local installing forwarding entries in the MPLS data plane. Local
configuration and policies applied on a router are examples of MCCs.</t> configuration and policies applied on a router are examples of MCCs.</t>
<t pn="section-2-4">
<t>
In order to have a node segment reach the node, a network operator In order to have a node segment reach the node, a network operator
SHOULD configure at least one node segment per routing instance, <bcp14>SHOULD</bcp14> configure at least one node segment per routing instanc e,
topology, or algorithm. Otherwise, the node is not reachable within topology, or algorithm. Otherwise, the node is not reachable within
the routing instance, topology or along the routing algorithm, which the routing instance, within the topology,
restrict its ability to be used by a SR policy, including for TI-LFA.</t> or along the routing algorithm, which restricts
its ability to be used by an SR Policy and as a
<section title="Multiple Forwarding Behaviors for the Same Prefix" anchor Topology Independent Loop-Free Alternate (TI-LFA).</t>
="section-2.1"><t> <section anchor="convert-section-2.1" numbered="true" toc="include" remove
InRFC="false" pn="section-2.1">
<name slugifiedName="name-multiple-forwarding-behavio">Multiple Forwardi
ng Behaviors for the Same Prefix</name>
<t pn="section-2.1-1">
The SR architecture does not prohibit having more than one SID for The SR architecture does not prohibit having more than one SID for
the same prefix. In fact, by allowing multiple SIDs for the same the same prefix. In fact, by allowing multiple SIDs for the same
prefix, it is possible to have different forwarding behaviors (such prefix, it is possible to have different forwarding behaviors (such
as different paths, different ECMP/UCMP behaviors,...,etc) for the as different paths, different ECMP and Unequal-Cost Multipath (UCMP) behavior s, etc.) for the
same destination.</t> same destination.</t>
<t pn="section-2.1-2">
<t> Instantiating Segment Routing over the MPLS forwarding plane fits
Instantiating Segment routing over the MPLS forwarding plane fits
seamlessly with this principle. An operator may assign multiple MPLS seamlessly with this principle. An operator may assign multiple MPLS
labels or indices to the same prefix and assign different forwarding labels or indices to the same prefix and assign different forwarding
behaviors to each label/SID. The MCC in the network downloads behaviors to each label/SID. The MCC in the network downloads
different MPLS labels/SIDs to the FIB for different forwarding different MPLS labels/SIDs to the FIB for different forwarding
behaviors. The MCC at the entry of an SR domain or at any point in behaviors. The MCC at the entry of an SR domain or at any point in
the domain can choose to apply a particular forwarding behavior to a the domain can choose to apply a particular forwarding behavior to a
particular packet by applying the PUSH action to that packet using particular packet by applying the PUSH action to that packet using
the corresponding SID.</t> the corresponding SID.</t>
</section>
</section> <section anchor="convert-section-2.2" numbered="true" toc="include" remove
InRFC="false" pn="section-2.2">
<section title="SID Representation in the MPLS Forwarding Plane" anchor=" <name slugifiedName="name-sid-representation-in-the-m">SID Representatio
section-2.2"><t> n in the MPLS Forwarding Plane</name>
<t pn="section-2.2-1">
When instantiating SR over the MPLS forwarding plane, a SID is When instantiating SR over the MPLS forwarding plane, a SID is
represented by an MPLS label or an index <xref target="RFC8402"/>.</t> represented by an MPLS label or an index <xref target="RFC8402" format="defau
lt" sectionFormat="of" derivedContent="RFC8402"/>.</t>
<t> <t pn="section-2.2-2">
A global segment is a label, or an index which may be mapped to an A global SID is a label, or an index that may be mapped to an
MPLS label within the Segment Routing Global Block (SRGB) of the node MPLS label within the Segment Routing Global Block (SRGB), of the node
installing the global segment in its FIB/receiving the labeled that installs a global SID in its FIB and receives the labeled
packet. <xref target="section-2.4"/> specifies the procedure to map a global packet. <xref target="convert-section-2.4" format="default" sectionFormat="of
segment " derivedContent="Section 2.4"/> specifies the procedure to map a global segment
represented by an index to an MPLS label within the SRGB.</t> represented by an index to an MPLS label within the SRGB.</t>
<t pn="section-2.2-3">
<t> The MCC <bcp14>MUST</bcp14> ensure that any label value corresponding to any
The MCC MUST ensure that any label value corresponding to any SID it SID it
installs in the forwarding plane follows the following rules:</t> installs in the forwarding plane follows the rules below:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.2-4">
<t><list style="symbols"><t>The label value MUST be unique within the rou <li pn="section-2.2-4.1">The label value <bcp14>MUST</bcp14> be unique
ter on which the MCC within the router on which the MCC
is running. i.e. the label MUST only be used to represent the SID is running, i.e., the label <bcp14>MUST</bcp14> only be used to represent
and MUST NOT be used to represent more than one SID or for any the SID
other forwarding purpose on the router.</t> and <bcp14>MUST NOT</bcp14> be used to represent more than one SID or for
any
<t>The label value MUST NOT come from the range of special purpose other forwarding purpose on the router.</li>
labels <xref target="RFC7274"/>.</t> <li pn="section-2.2-4.2">The label value <bcp14>MUST NOT</bcp14> come
from the range of special-purpose
</list> labels <xref target="RFC7274" format="default" sectionFormat="of" derivedC
</t> ontent="RFC7274"/>.</li>
</ul>
<t> <t pn="section-2.2-5">
Labels allocated in this document are considered per platform down- Labels allocated in this document are considered per-platform downstream
stream allocated labels <xref target="RFC3031"/>.</t> allocated labels <xref target="RFC3031" format="default" sectionFormat="of" d
erivedContent="RFC3031"/>.</t>
</section> </section>
<section anchor="convert-section-2.3" numbered="true" toc="include" remove
<section title="Segment Routing Global Block and Local Block" anchor="sec InRFC="false" pn="section-2.3">
tion-2.3"><t> <name slugifiedName="name-segment-routing-global-bloc">Segment Routing G
The concepts of Segment Routing Global Block (SRGB) and global SID lobal Block and Local Block</name>
are explained in <xref target="RFC8402"/>. In general, the SRGB need not be a <t pn="section-2.3-1">
The concepts of SRGB and global SID
are explained in <xref target="RFC8402" format="default" sectionFormat="of" d
erivedContent="RFC8402"/>. In general, the SRGB need not be a
contiguous range of labels.</t> contiguous range of labels.</t>
<t pn="section-2.3-2">
<figure><artwork><![CDATA[
For the rest of this document, the SRGB is specified by the list of For the rest of this document, the SRGB is specified by the list of
MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] MPLS label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)]
where Ll(i) =< Lh(i). where Ll(i) =&lt; Lh(i).
]]></artwork> </t>
</figure> <t pn="section-2.3-3">
<t>
The following rules apply to the list of MPLS ranges representing the The following rules apply to the list of MPLS ranges representing the
SRGB</t> SRGB:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.3-4">
<t><list style="symbols"><t>The list of ranges comprising the SRGB MUST N <li pn="section-2.3-4.1">The list of ranges comprising the SRGB <bcp14
OT overlap.</t> >MUST NOT</bcp14> overlap.</li>
<li pn="section-2.3-4.2">Every range in the list of ranges specifying
<t>Every range in the list of ranges specifying the SRGB MUST NOT the SRGB <bcp14>MUST NOT</bcp14>
cover or overlap with a reserved label value or range <xref target="RFC727 cover or overlap with a reserved label value or range <xref target="RFC727
4"/>, 4" format="default" sectionFormat="of" derivedContent="RFC7274"/>,
respectively.</t> respectively.</li>
<li pn="section-2.3-4.3">If the SRGB of a node does not conform to the
<t>If the SRGB of a node does not conform to the structure specified structure specified
in this section or to the previous two rules, then this SRGB MUST in this section or to the previous two rules, the SRGB <bcp14>MUST</bcp14>
be completely ignored by all routers in the routing domain and the be completely ignored by all routers in the routing domain, and the
node MUST be treated as if it does not have an SRGB.</t> node <bcp14>MUST</bcp14> be treated as if it does not have an SRGB.</li>
<li pn="section-2.3-4.4">The list of label ranges <bcp14>MUST</bcp14>
<t>The list of label ranges MUST only be used to instantiate global only be used to instantiate global
SIDs into the MPLS forwarding plane</t> SIDs into the MPLS forwarding plane.</li>
</ul>
</list> <t pn="section-2.3-5">
</t> A local segment <bcp14>MAY</bcp14> be allocated from the Segment Routing Loca
l Block
<t> (SRLB) <xref target="RFC8402" format="default" sectionFormat="of" derivedCont
A Local segment MAY be allocated from the Segment Routing Local Block ent="RFC8402"/> or from any unused label as long as it does not use
(SRLB) <xref target="RFC8402"/> or from any unused label as long as it does n a special-purpose label. The SRLB consists of the range of local
ot use
a special purpose label. The SRLB consists of the range of local
labels reserved by the node for certain local segments. In a labels reserved by the node for certain local segments. In a
controller-driven network, some controllers or applications MAY use controller-driven network, some controllers or applications <bcp14>MAY</bcp14
the control plane to discover the available set of local SIDs on a > use
particular router <xref target="I-D.ietf-spring-segment-routing-policy"/>. Th the control plane to discover the available set of Local SIDs on a
e rules particular router <xref target="ROUTING-POLICY" format="default" sectionForma
t="of" derivedContent="ROUTING-POLICY"/>. The rules
applicable to the SRGB are also applicable to the SRLB, except the applicable to the SRGB are also applicable to the SRLB, except the
rule that says that the SRGB MUST only be used to instantiate global SRGB <bcp14>MUST</bcp14> only be used to instantiate global
SIDs into the MPLS forwarding plane. The recommended, minimum, or SIDs into the MPLS forwarding plane. The recommended, minimum, or
maximum size of the SRGB and/or SRLB is a matter of future study</t> maximum size of the SRGB and/or SRLB is a matter of future study.</t>
</section>
</section> <section anchor="convert-section-2.4" numbered="true" toc="include" remove
InRFC="false" pn="section-2.4">
<section title="Mapping a SID Index to an MPLS label" anchor="section-2.4 <name slugifiedName="name-mapping-a-sid-index-to-an-m">Mapping a SID Ind
"><t> ex to an MPLS Label</name>
This sub-section specifies how the MPLS label value is calculated <t pn="section-2.4-1">
This subsection specifies how the MPLS label value is calculated
given the index of a SID. The value of the index is determined by an given the index of a SID. The value of the index is determined by an
MCC such as IS-IS <xref target="I-D.ietf-isis-segment-routing-extensions"/> o MCC such as IS-IS <xref target="RFC8667" format="default" sectionFormat="of"
r OSPF derivedContent="RFC8667"/> or OSPF
<xref target="I-D.ietf-ospf-segment-routing-extensions"/>. This section only <xref target="RFC8665" format="default" sectionFormat="of" derivedContent="RF
C8665"/>. This section only
specifies how to map the index to an MPLS label. The calculated MPLS specifies how to map the index to an MPLS label. The calculated MPLS
label is downloaded to the FIB, sent out with a forwarded packet, or label is downloaded to the FIB, sent out with a forwarded packet, or
both.</t> both.</t>
<t pn="section-2.4-2">
<t>
Consider a SID represented by the index "I". Consider an SRGB as Consider a SID represented by the index "I". Consider an SRGB as
specified in <xref target="section-2.3"/>. The total size of the SRGB, repres ented by specified in <xref target="convert-section-2.3" format="default" sectionForma t="of" derivedContent="Section 2.3"/>. The total size of the SRGB, represented b y
the variable "Size", is calculated according to the formula:</t> the variable "Size", is calculated according to the formula:</t>
<artwork name="" type="" align="left" alt="" pn="section-2.4-3">
size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1</artwork>
<t pn="section-2.4-4"> The following rules <bcp14>MUST</bcp14> be applie
d by the MCC when calculating the
MPLS label value corresponding to the SID index value "I".</t>
<ul spacing="normal" empty="true" bare="false" pn="section-2.4-5">
<li pn="section-2.4-5.1">0 =&lt; I &lt; size. If index "I" does not sa
tisfy the previous inequality, then the label cannot be calculated.</li>
<li pn="section-2.4-5.2">
<t pn="section-2.4-5.2.1">The label value corresponding to the SID i
ndex "I" is calculated
as follows:
<figure><artwork><![CDATA[ </t>
size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 <ul spacing="normal" empty="true" bare="false" pn="section-2.4-5.2.2
]]></artwork> ">
</figure> <li pn="section-2.4-5.2.2.1">j = 1 , temp = 0</li>
<t> <li pn="section-2.4-5.2.2.2">
The following rules MUST be applied by the MCC when calculating the <t pn="section-2.4-5.2.2.2.1">While temp + Lh(j)- Ll(j) &lt; I
MPLS label value corresponding the SID index value "I".</t>
<t>
<list style="symbols">
<t>0 =&lt; I &lt; size. If the index "I" does not satisfy the previous ineq
uality, then the label cannot be calculated.</t>
<t>The label value corresponding to the SID index "I" is calculated
as follows
<list style="symbols">
<t>j = 1 , temp = 0</t>
<t>While temp + Lh(j)- Ll(j) &lt; I
<list style="symbols">
<t>temp = temp + Lh(j)- Ll(j) + 1</t>
<t>j = j+1</t>
</list></t>
<t>label = I - temp + Ll(j)</t>
</list>
</t>
</list>
</t>
<t> </t>
<ul spacing="normal" empty="true" bare="false" pn="section-2.4-5
.2.2.2.2">
<li pn="section-2.4-5.2.2.2.2.1">temp = temp + Lh(j)- Ll(j) +
1</li>
<li pn="section-2.4-5.2.2.2.2.2">j = j+1</li>
</ul>
</li>
<li pn="section-2.4-5.2.2.3">label = I - temp + Ll(j)</li>
</ul>
</li>
</ul>
<t pn="section-2.4-6">
An example for how a router calculates labels and forwards traffic An example for how a router calculates labels and forwards traffic
based on the procedure described in this section can be found in based on the procedure described in this section can be found in
Appendix A.1.</t> <xref target="convert-section-a.1" format="default" sectionFormat="of" derive
dContent="Appendix A.1"/>.</t>
</section> </section>
<section anchor="convert-section-2.5" numbered="true" toc="include" remove
<section title="Incoming Label Collision" anchor="section-2.5"><t> InRFC="false" pn="section-2.5">
The MPLS Architecture <xref target="RFC3031"/> defines the term Forwarding <name slugifiedName="name-incoming-label-collision">Incoming Label Colli
Equivalence Class (FEC) as the set of packets with similar and / or sion</name>
identical characteristics which are forwarded the same way and are <t pn="section-2.5-1">
bound to the same MPLS incoming (local) label. In Segment-Routing The MPLS Architecture <xref target="RFC3031" format="default" sectionFormat="
MPLS, a local label serves as the SID for given FEC.</t> of" derivedContent="RFC3031"/> defines the term Forwarding
Equivalence Class (FEC) as the set of packets with similar and/or
<t> identical characteristics that are forwarded the same way and are
We define Segment Routing (SR) FEC as one of the following <xref target="RFC8 bound to the same MPLS incoming (local) label. In Segment Routing
402"/>:</t> MPLS, a local label serves as the SID for a given FEC.</t>
<t pn="section-2.5-2">
<t><list style="symbols"><t>(Prefix, Routing Instance, Topology, Algorith We define SR FEC <xref target="RFC8402" format="default" sectionFormat="of" d
m <xref target="RFC8402"/>), where a erivedContent="RFC8402"/> as one of the following:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.5-3">
<li pn="section-2.5-3.1">(Prefix, Routing Instance, Topology, Algorith
m) <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RF
C8402"/>, where a
topology identifies a set of links with metrics. For the purpose topology identifies a set of links with metrics. For the purpose
of incoming label collision resolution, the same Topology of incoming label collision resolution, the same Topology
numerical value SHOULD be used on all routers to identify the same numerical value <bcp14>SHOULD</bcp14> be used on all routers to identify t he same
set of links with metrics. For MCCs where the "Topology" and/or set of links with metrics. For MCCs where the "Topology" and/or
"Algorithm" fields are not defined, the numerical value of zero "Algorithm" fields are not defined, the numerical value of zero
MUST be used for these two fields. For the purpose of incoming <bcp14>MUST</bcp14> be used for these two fields. For the purpose of incom ing
label collision resolution, a routing instance is identified by a label collision resolution, a routing instance is identified by a
single incoming label downloader to FIB. Two MCCs running on the single incoming label downloader to the FIB. Two MCCs running on the
same router are considered different routing instances if the only same router are considered different routing instances if the only
way the two instances can know about the other's incoming labels way the two instances know about each other's incoming labels
is through redistribution. The numerical value used to identify a is through redistribution. The numerical value used to identify a
routing instance MAY be derived from other configuration or MAY be routing instance <bcp14>MAY</bcp14> be derived from other configuration or <bcp14>MAY</bcp14> be
explicitly configured. If it is derived from other configuration, explicitly configured. If it is derived from other configuration,
then the same numerical value SHOULD be derived from the same then the same numerical value <bcp14>SHOULD</bcp14> be derived from the sa me
configuration as long as the configuration survives router reload. configuration as long as the configuration survives router reload.
If the derived numerical value varies for the same configuration, If the derived numerical value varies for the same configuration,
then an implementation SHOULD make numerical value used to then an implementation <bcp14>SHOULD</bcp14> make the numerical value used
identify a routing instance configurable.</t> to
identify a routing instance configurable.</li>
<t>(next-hop, outgoing interface), where the outgoing interface is <li pn="section-2.5-3.2">(next hop, outgoing interface), where the out
physical or virtual.</t> going interface is
physical or virtual.</li>
<t>(number of adjacencies, list of next-hops, list of outgoing <li pn="section-2.5-3.3">(number of adjacencies, list of next hops, li
st of outgoing
interfaces IDs in ascending numerical order). This FEC represents interfaces IDs in ascending numerical order). This FEC represents
parallel adjacencies <xref target="RFC8402"/></t> parallel adjacencies <xref target="RFC8402" format="default" sectionFormat
="of" derivedContent="RFC8402"/>.</li>
<t>(Endpoint, Color) representing an SR policy <xref target="RFC8402"/></ <li pn="section-2.5-3.4">(Endpoint, Color). This FEC represents an SR
t> Policy <xref target="RFC8402" format="default" sectionFormat="of" derivedContent
="RFC8402"/>.</li>
<t>(Mirrored SID) The Mirrored SID [RFC8402, Section 5.1] is the IP <li pn="section-2.5-3.5">(Mirror SID). The Mirror SID (see <xref targe
address advertised by the advertising node to identify the mirror- t="RFC8402" sectionFormat="comma" section="5.1" format="default" derivedLink="ht
SID. The IP address is encoded as specified in <xref target="section-2.5.1 tps://rfc-editor.org/rfc/rfc8402#section-5.1" derivedContent="RFC8402"/>) is the
"/>.</t> IP
address advertised by the advertising node to identify the Mirror SID.
</list> The IP address is encoded as specified in <xref target="convert-section-2.
</t> 5.1" format="default" sectionFormat="of" derivedContent="Section 2.5.1"/>.</li>
</ul>
<t> <t pn="section-2.5-4">
This section covers the RECOMMENDED procedure to handle the scenario This section covers the <bcp14>RECOMMENDED</bcp14> procedure for handling the
scenario
where, because of an error/misconfiguration, more than one SR FEC as where, because of an error/misconfiguration, more than one SR FEC as
defined in this section, map to the same incoming MPLS label. defined in this section maps to the same incoming MPLS label.
Examples illustrating the behavior specified in this section can be Examples illustrating the behavior specified in this section can be
found in Appendix A.2.</t> found in <xref target="convert-section-a.2" format="default" sectionFormat="o
f" derivedContent="Appendix A.2"/>.</t>
<t pn="section-2.5-5">
<t>
An incoming label collision occurs if the SIDs of the set of FECs An incoming label collision occurs if the SIDs of the set of FECs
{FEC1, FEC2,..., FECk} map to the same incoming SR MPLS label "L1".</t> {FEC1, FEC2, ..., FECk} map to the same incoming SR MPLS label "L1".</t>
<t pn="section-2.5-6">
<t> Suppose an anycast prefix is advertised with a Prefix-SID by some,
Suppose an anycast prefix is advertised with a prefix-SID by some, but not all, of the nodes that advertise that prefix. If the Prefix-SID
but not all, of the nodes that advertise that prefix. If the prefix- sub-TLVs result in mapping that anycast prefix to the same
SID sub-TLVs result in mapping that anycast prefix to the same incoming label, then the advertisement of the Prefix-SID by some, but
incoming label, then the advertisement of the prefix-SID by some, but not all, of the advertising nodes <bcp14>MUST NOT</bcp14> be treated as a lab
not all, of advertising nodes MUST NOT be treated as a label el
collision.</t> collision.</t>
<t pn="section-2.5-7">
<t> An implementation <bcp14>MUST NOT</bcp14> allow the MCCs belonging to the sam
An implementation MUST NOT allow the MCCs belonging to the same e
router to assign the same incoming label to more than one SR FEC.</t> router to assign the same incoming label to more than one SR FEC.</t>
<t pn="section-2.5-8">
<t>
The objective of the following steps is to deterministically install The objective of the following steps is to deterministically install
in the MPLS Incoming Label Map, also known as label FIB, a single FEC in the MPLS Incoming Label Map, also known as label FIB, a single FEC
with the incoming label "L1". By "deterministically install" we mean with the incoming label "L1". By "deterministically install", we mean
if the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR if the set of FECs {FEC1, FEC2,..., FECk} map to the same incoming SR
MPLS label "L1", then the steps below assign the same FEC to the MPLS label "L1", then the steps below assign the same FEC to the
label "L1" irrespective of the order by which the mappings of this label "L1" irrespective of the order by which the mappings of this
set of FECs to the label "L1" are received. For example, a first- set of FECs to the label "L1" are received. For example, first-
come-first-serve tie-breaking is not allowed. The remaining FECs may come, first-served tiebreaking is not allowed. The remaining FECs may
be installed in the IP FIB without incoming label.</t> be installed in the IP FIB without an incoming label.</t>
<t pn="section-2.5-9">
<t>
The procedure in this section relies completely on the local FEC and The procedure in this section relies completely on the local FEC and
label database within a given router.</t> label database within a given router.</t>
<t pn="section-2.5-10">
<t> The collision resolution procedure is as follows:</t>
The collision resolution procedure is as follows</t> <ol spacing="normal" type="1" start="1" pn="section-2.5-11">
<li pn="section-2.5-11.1" derivedCounter="1.">Given the SIDs of the se
<t><list style="numbers"><t>Given the SIDs of the set of FECs, {FEC1, FEC t of FECs, {FEC1, FEC2,..., FECk} map to
2,..., FECk} map to the same MPLS label "L1".</li>
the same MPLS label "L1".</t> <li pn="section-2.5-11.2" derivedCounter="2.">
<t pn="section-2.5-11.2.1">Within an MCC, apply tiebreaking rules to
<t>Within an MCC, apply tie-breaking rules to select one FEC only and select one FEC only, and
assign the label to it. The losing FECs are handled as if no assign the label to it. The losing FECs are handled as if no
labels are attached to them. The losing FECs with algorithms other labels are attached to them. The losing FECs with algorithms other
than the shortest path first <xref target="RFC8402"/> are not installed in than the shortest path first <xref target="RFC8402" format="default" secti
the onFormat="of" derivedContent="RFC8402"/> are not installed in the
FIB.<list style="letters"><t>If the same set of FECs are attached to the s FIB.
ame label "L1", </t>
then the tie-breaking rules MUST always select the same FEC <ol spacing="normal" type="a" start="1" pn="section-2.5-11.2.2">
<li pn="section-2.5-11.2.2.1" derivedCounter="a."> If the same set
of FECs are attached to the same label "L1",
then the tiebreaking rules <bcp14>MUST</bcp14> always select the same
FEC
irrespective of the order in which the FECs and the label "L1" irrespective of the order in which the FECs and the label "L1"
are received. In other words, the tie-breaking rule MUST be are received. In other words, the tiebreaking rule <bcp14>MUST</bcp14>
deterministic.</t> be
deterministic.</li>
</list> </ol>
</t> </li>
<li pn="section-2.5-11.3" derivedCounter="3.">If there is still collis
<t>If there is still collision between the FECs belonging to ion between the FECs belonging to
different MCCs, then re-apply the tie-breaking rules to the different MCCs, then reapply the tiebreaking rules to the
remaining FECs to select one FEC only and assign the label to that remaining FECs to select one FEC only, and assign the label to that
FEC</t> FEC.</li>
<li pn="section-2.5-11.4" derivedCounter="4.">Install the selected FEC
<t>Install into the IP FIB the selected FEC and its incoming label in into the IP FIB and its incoming label into
the label FIB.</t> the label FIB.</li>
<li pn="section-2.5-11.5" derivedCounter="5.">The remaining FECs with
<t>The remaining FECs with the default algorithm (see the the default algorithm (see the
specification of prefix-SID algorithm <xref target="RFC8402"/>) may be ins Prefix-SID algorithm specification <xref target="RFC8402" format="default"
talled sectionFormat="of" derivedContent="RFC8402"/>) may be installed
in the FIB natively, such as pure IP entries in case of Prefix in the FIB natively, such as pure IP entries in case of Prefix
FEC, without any incoming labels corresponding to their SIDs. The FEC, without any incoming labels corresponding to their SIDs. The
remaining FECs with algorithms other than the shortest path first remaining FECs with algorithms other than the shortest path first
<xref target="RFC8402"/> are not installed in the FIB.</t> <xref target="RFC8402" format="default" sectionFormat="of" derivedContent=
"RFC8402"/> are not installed in the FIB.</li>
</list> </ol>
</t> <section anchor="convert-section-2.5.1" numbered="true" toc="include" re
moveInRFC="false" pn="section-2.5.1">
<section title="Tie-breaking Rules" anchor="section-2.5.1"> <name slugifiedName="name-tiebreaking-rules">Tiebreaking Rules</name>
<t> <t pn="section-2.5.1-1">
The default tie-breaking rules are specified as follows:</t> The default tiebreaking rules are specified as follows:</t>
<ol spacing="normal" type="1" start="1" pn="section-2.5.1-2">
<t><list style="numbers"><t>if FECi has the lowest FEC administrative dis <li pn="section-2.5.1-2.1" derivedCounter="1.">Determine the lowest
tance among the administrative distance among the competing FECs as defined in the section below
competing FECs as defined in this section below, filter away all . Then filter away all the competing FECs with a higher administrative distance.
the competing FECs with higher administrative distance.</t> </li>
<li pn="section-2.5.1-2.2" derivedCounter="2.">If more than one comp
<t>if more than one competing FEC remains after step 1, select the eting FEC remains after step 1, select the
smallest numerical FEC value. The numerical value of the FEC is smallest numerical FEC value. The numerical value of the FEC is
determined according to the FEC encoding described later in this determined according to the FEC encoding described later in this
section.</t> section.</li>
</ol>
</list> <t pn="section-2.5.1-3">
</t> These rules deterministically select which FEC to install in the MPLS
<t>
These rules deterministically select the FEC to install in the MPLS
forwarding plane for the given incoming label.</t> forwarding plane for the given incoming label.</t>
<t pn="section-2.5.1-4">
<t> This document defines the default tiebreaking rules that <bcp14>SHOULD</bcp14
This document defines the default tie breaking rules that SHOULD be > be
implemented. An implementation MAY choose to support different tie- implemented. An implementation <bcp14>MAY</bcp14> choose to support different
breaking rules and MAY use one of the these instead of the default tiebreaking
tie-breaking rules. To maximize MPLS forwarding consistency in case rules and <bcp14>MAY</bcp14> use one of these instead of the default
of SID configuration error, the network operator MUST deploy, within tiebreaking rules. To maximize MPLS forwarding consistency in case
an IGP flooding area, routers implementing the same tie-breaking of a SID configuration error, the network operator <bcp14>MUST</bcp14> deploy
, within
an IGP flooding area, routers implementing the same tiebreaking
rules.</t> rules.</t>
<t pn="section-2.5.1-5">
<t>
Each FEC is assigned an administrative distance. The FEC Each FEC is assigned an administrative distance. The FEC
administrative distance is encoded as an 8-bit value. The lower the administrative distance is encoded as an 8-bit value. The lower the
value, the better the administrative distance.</t> value, the better the administrative distance.</t>
<t pn="section-2.5.1-6">
<t>
The default FEC administrative distance order starting from the The default FEC administrative distance order starting from the
lowest value SHOULD be:</t> lowest value <bcp14>SHOULD</bcp14> be:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-7">
<t><list style="symbols"><t>Explicit SID assignment to a FEC that maps to <li pn="section-2.5.1-7.1">
a label outside the <t pn="section-2.5.1-7.1.1">Explicit SID assignment to a FEC that
maps to a label outside the
SRGB irrespective of the owner MCC. An explicit SID assignment is SRGB irrespective of the owner MCC. An explicit SID assignment is
a static assignment of a label to a FEC such that the assignment a static assignment of a label to a FEC such that the assignment
survives router reboot.<list style="symbols"><t>An example of explicit SID survives a router reboot.</t>
allocation is static assignment of <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-
a specific label to an adj-SID.</t> 7.1.2">
<li pn="section-2.5.1-7.1.2.1">An example of explicit SID alloca
<t>An implementation of explicit SID assignment MUST guarantee tion is static assignment of
collision freeness on the same router</t> a specific label to an Adj-SID.</li>
<li pn="section-2.5.1-7.1.2.2">An implementation of explicit SID
</list> assignment <bcp14>MUST</bcp14> guarantee
</t> collision freeness on the same router.</li>
</ul>
<t>Dynamic SID assignment:<list style="symbols"><t>For all FEC types exce </li>
pt for SR policy, the FEC types are <li pn="section-2.5.1-7.2">
ordered using the default administrative distance ordering <t pn="section-2.5.1-7.2.1">Dynamic SID assignment:</t>
defined by the implementation.</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-
7.2.2">
<t>Binding SID <xref target="RFC8402"/> assigned to SR Policy always has <li pn="section-2.5.1-7.2.2.1">All FEC types, except for the SR
a Policy, are
ordered using the default administrative distance
defined by the implementation.</li>
<li pn="section-2.5.1-7.2.2.2">The Binding SID <xref target="RFC
8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> assigned to
the SR Policy always has a
higher default administrative distance than the default higher default administrative distance than the default
administrative distance of any other FEC type</t> administrative distance of any other FEC type.</li>
</ul>
</list> </li>
</t> </ul>
<t pn="section-2.5.1-8">
</list> To maximize MPLS forwarding consistency, if the same FEC is advertised
</t> in more than one protocol, a user <bcp14>MUST</bcp14> ensure that the adminis
trative
<t>
To maximize MPLS forwarding consistency, If a same FEC is advertised
in more than one protocol, a user MUST ensure that the administrative
distance preference between protocols is the same on all routers of distance preference between protocols is the same on all routers of
the IGP flooding domain. Note that this is not really new as this the IGP flooding domain. Note that this is not really new as this
already applies to IP forwarding.</t> already applies to IP forwarding.</t>
<t pn="section-2.5.1-9">
The numerical sort across FECs <bcp14>SHOULD</bcp14> be performed as follows:
<t> </t>
The numerical sort across FECs SHOULD be performed as follows: <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-10">
<li pn="section-2.5.1-10.1">
<list style="symbols"> <t pn="section-2.5.1-10.1.1">Each FEC is assigned a FEC type encod
ed in 8 bits. The type codepoints
<t>Each FEC is assigned a FEC type encoded in 8 bits. The following for each SR FEC defined at the beginning
are the type code point for each SR FEC defined at the beginning of this section are as follows:
of this Section: </t>
<list style="empty"> <ul empty="true" bare="false" spacing="normal" pn="section-2.5.1-1
0.1.2">
<t>120: (Prefix, Routing Instance, Topology, Algorithm)</t> <li pn="section-2.5.1-10.1.2.1">
<dl newline="false" spacing="normal" pn="section-2.5.1-10.1.2.
<t>130: (next-hop, outgoing interface)</t> 1.1">
<dt pn="section-2.5.1-10.1.2.1.1.1">120:</dt>
<t>140: Parallel Adjacency <xref target="RFC8402"/></t> <dd pn="section-2.5.1-10.1.2.1.1.2">(Prefix, Routing Instanc
e, Topology, Algorithm)</dd>
<t>150: an SR policy <xref target="RFC8402"/>.</t> <dt pn="section-2.5.1-10.1.2.1.1.3">130:</dt>
<dd pn="section-2.5.1-10.1.2.1.1.4"> (next hop, outgoing int
<t>160: Mirror SID <xref target="RFC8402"/></t> erface)</dd>
<dt pn="section-2.5.1-10.1.2.1.1.5">140:</dt>
<t>The numerical values above are mentioned to guide <dd pn="section-2.5.1-10.1.2.1.1.6"> Parallel Adjacency <xre
f target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/
></dd>
<dt pn="section-2.5.1-10.1.2.1.1.7">150:</dt>
<dd pn="section-2.5.1-10.1.2.1.1.8">SR Policy <xref target="
RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/></dd>
<dt pn="section-2.5.1-10.1.2.1.1.9">160:</dt>
<dd pn="section-2.5.1-10.1.2.1.1.10"> Mirror SID <xref targe
t="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/></dd>
</dl>
</li>
</ul>
<t pn="section-2.5.1-10.1.3">The numerical values above are mentio
ned to guide
implementation. If other numerical values are used, then the implementation. If other numerical values are used, then the
numerical values must maintain the same greater-than ordering numerical values must maintain the same greater-than ordering
of the numbers mentioned here.</t> of the numbers mentioned here.</t>
</li>
</list></t> <li pn="section-2.5.1-10.2">
<t pn="section-2.5.1-10.2.1">The fields of each FEC are encoded as
<t>The fields of each FEC are encoded as follows follows:
<list style="symbols"> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-
<t>All fields in all FECs are encoded in big endian</t> 10.2.2">
<li pn="section-2.5.1-10.2.2.1">All fields in all FECs are encod
<t>Routing Instance ID represented by 16 bits. For routing ed in big endian order.</li>
<li pn="section-2.5.1-10.2.2.2">The Routing Instance ID is repre
sented by 16 bits. For routing
instances that are identified by less than 16 bits, encode the instances that are identified by less than 16 bits, encode the
Instance ID in the least significant bits while the most Instance ID in the least significant bits while the most
significant bits are set to zero</t> significant bits are set to zero.</li>
<li pn="section-2.5.1-10.2.2.3">The address family is represente
<t>Address Family represented by 8 bits, where IPv4 encoded as d by 8 bits, where IPv4 is encoded as
100 and IPv6 is encoded as 110. These numerical values are 100, and IPv6 is encoded as 110. These numerical values are
mentioned to guide implementations. If other numerical values mentioned to guide implementations. If other numerical values
are used, then the numerical value of IPv4 MUST be less than are used, then the numerical value of IPv4 <bcp14>MUST</bcp14> be less
the numerical value for IPv6</t> than
the numerical value for IPv6.</li>
<t>All addresses are represented in 128 bits as follows <li pn="section-2.5.1-10.2.2.4">
<t pn="section-2.5.1-10.2.2.4.1">All addresses are represented
<list style="symbols"> in 128 bits as follows:
<t>IPv6 address is encoded natively</t>
<t>IPv4 address is encoded in the most significant bits and
the remaining bits are set to zero</t></list>
</t>
<t>All prefixes are represented by (8 + 128) bits.
<list style="symbols">
<t>A prefix is encoded in the most significant bits and the
remaining bits are set to zero.</t>
<t>The prefix length is encoded before the prefix in a field </t>
of size 8 bits.</t></list> <ul spacing="normal" bare="false" empty="false" pn="section-2.
</t> 5.1-10.2.2.4.2">
<li pn="section-2.5.1-10.2.2.4.2.1">The IPv6 address is enco
ded natively.</li>
<li pn="section-2.5.1-10.2.2.4.2.2">The IPv4 address is enco
ded in the most significant bits, and
the remaining bits are set to zero.</li>
</ul>
</li>
<li pn="section-2.5.1-10.2.2.5">
<t pn="section-2.5.1-10.2.2.5.1">All prefixes are represented
by (8 + 128) bits.
<t>Topology ID is represented by 16 bits. For routing instances </t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.
5.1-10.2.2.5.2">
<li pn="section-2.5.1-10.2.2.5.2.1">A prefix is encoded in t
he most significant bits, and the
remaining bits are set to zero.</li>
<li pn="section-2.5.1-10.2.2.5.2.2">The prefix length is enc
oded before the prefix in an 8-bit field.</li>
</ul>
</li>
<li pn="section-2.5.1-10.2.2.6">The Topology ID is represented b
y 16 bits. For routing instances
that identify topologies using less than 16 bits, encode the that identify topologies using less than 16 bits, encode the
topology ID in the least significant bits while the most topology ID in the least significant bits while the most
significant bits are set to zero</t> significant bits are set to zero.</li>
<li pn="section-2.5.1-10.2.2.7">The Algorithm is encoded in a 16
<t>Algorithm is encoded in a 16 bits field.</t> -bit field.</li>
<li pn="section-2.5.1-10.2.2.8">The Color ID is encoded using 32
<t>The Color ID is encoded using 32 bits</t> bits.</li>
</ul>
</list> </li>
</t> <li pn="section-2.5.1-10.3">Choose the set of FECs of the smallest F
EC type codepoint.</li>
<t>Choose the set of FECs of the smallest FEC type code point</t> <li pn="section-2.5.1-10.4">Out of these FECs, choose the FECs with
the smallest address
<t>Out of these FECs, choose the FECs with the smallest address family codepoint.</li>
family code point</t> <li pn="section-2.5.1-10.5">
<t pn="section-2.5.1-10.5.1">Encode the remaining set of FECs as f
<t>Encode the remaining set of FECs as follows ollows:
<list style="symbols"> </t>
<t>(Prefix, Routing Instance, Topology, Algorithm) is encoded as <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-
10.5.2">
<li pn="section-2.5.1-10.5.2.1">(Prefix, Routing Instance, Topol
ogy, Algorithm) is encoded as
(Prefix Length, Prefix, routing_instance_id, Topology, SR (Prefix Length, Prefix, routing_instance_id, Topology, SR
Algorithm)</t> Algorithm).</li>
<li pn="section-2.5.1-10.5.2.2">(next hop, outgoing interface) i
<t>(next-hop, outgoing interface) is encoded as (next-hop, s encoded as (next hop,
outgoing_interface_id)</t> outgoing_interface_id).</li>
<li pn="section-2.5.1-10.5.2.3">(number of adjacencies, list of
<t>(number of adjacencies, list of next-hops in ascending next hops in ascending
numerical order, list of outgoing interface IDs in ascending numerical order, list of outgoing interface IDs in ascending
numerical order). This encoding is used to encode a parallel numerical order) is used to encode a parallel
adjacency <xref target="RFC8402"/></t> adjacency <xref target="RFC8402" format="default" sectionFormat="of" de
rivedContent="RFC8402"/>.</li>
<t>(Endpoint, Color) is encoded as (Endpoint_address, Color_id)</t> <li pn="section-2.5.1-10.5.2.4">(Endpoint, Color) is encoded as
(Endpoint_address, Color_id).</li>
<t>(IP address): This is the encoding for a mirror SID FEC. The IP <li pn="section-2.5.1-10.5.2.5">(IP address) is the encoding for
address is encoded as described above in this section</t> a Mirror SID FEC. The IP
address is encoded as described above in this section.</li>
</list> </ul>
</t> </li>
<li pn="section-2.5.1-10.6">Select the FEC with the smallest numeric
<t>Select the FEC with the smallest numerical value</t> al value.</li>
</ul>
</list></t> <t pn="section-2.5.1-11">
<t>
The numerical values mentioned in this section are for guidance only. The numerical values mentioned in this section are for guidance only.
If other numerical values are used then the other numerical values If other numerical values are used, then the other numerical values
MUST maintain the same numerical ordering among different SR FECs.</t> <bcp14>MUST</bcp14> maintain the same numerical ordering among different SR F
ECs.</t>
</section> </section>
<section anchor="convert-section-2.5.2" numbered="true" toc="include" re
<section title="Redistribution between Routing Protocol Instances" anchor moveInRFC="false" pn="section-2.5.2">
="section-2.5.2"><t> <name slugifiedName="name-redistribution-between-rout">Redistribution
The following rule SHOULD be applied when redistributing SIDs with between Routing Protocol Instances</name>
<t pn="section-2.5.2-1">
The following rule <bcp14>SHOULD</bcp14> be applied when redistributing SIDs
with
prefixes between routing protocol instances:</t> prefixes between routing protocol instances:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.5.2-2">
<li pn="section-2.5.2-2.1">
<t pn="section-2.5.2-2.1.1">If the SRGB of the receiving instance
is the same as the SRGB of the origin
instance, then:
<t> </t>
<list style="symbols"> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.2-
<t>If the receiving instance's SRGB is the same as the SRGB of origin 2.1.2">
instance, then <li pn="section-2.5.2-2.1.2.1">the index is redistributed with t
he route.</li>
<list style="symbols"> </ul>
</li>
<t>the index is redistributed with the route</t> <li pn="section-2.5.2-2.2">
<t pn="section-2.5.2-2.2.1">Else,
</list>
</t>
<t>Else
<list style="symbols">
<t>the index is not redistributed and if the receiving instance </t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.5.2-
2.2.2">
<li pn="section-2.5.2-2.2.2.1">the index is not redistributed an
d if the receiving instance
decides to advertise an index with the redistributed route, it decides to advertise an index with the redistributed route, it
is the duty of the receiving instance to allocate a fresh is the duty of the receiving instance to allocate a fresh
index relative to its own SRGB. Note that in this case the index relative to its own SRGB. Note that in this case, the
receiving instance MUST compute the local label it assignes to receiving instance <bcp14>MUST</bcp14> compute the local label it assig
the route according to section 2.4 and install it in FIB.</t> ns to
the route according to <xref target="convert-section-2.4" format="defau
</list> lt" sectionFormat="of" derivedContent="Section 2.4"/> and install it in FIB.</li
</t> >
</ul>
</list> </li>
</t> </ul>
<t pn="section-2.5.2-3">
<t>
It is outside the scope of this document to define local node It is outside the scope of this document to define local node
behaviors that would allow to map the original index into a new index behaviors that would allow the mapping of the original index into a new index
in the receiving instance via the addition of an offset or other in the receiving instance via the addition of an offset or other
policy means.</t> policy means.</t>
<section anchor="convert-section-2.5.2.1" numbered="true" toc="exclude
<section title="Illustration" anchor="section-2.5.2.1"> " removeInRFC="false" pn="section-2.5.2.1">
<name slugifiedName="name-illustration">Illustration</name>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-2.5.2.1-1">
A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001) A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001)</artwork>
<t pn="section-2.5.2.1-2">Consider the simple topology above, where:
]]></artwork> </t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.5.2.1-
</figure> 3">
<li pn="section-2.5.2.1-3.1">A and B are in the IS-IS domain with
<t>Consider the simple topology above.</t> SRGB = [16000-17000]</li>
<li pn="section-2.5.2.1-3.2">B and C are in the OSPF domain with S
<t> RGB = [20000-21000]</li>
<list style="symbols"> <li pn="section-2.5.2.1-3.3">B redistributes 192.0.2.1/32 into the
<t>A and B are in the IS-IS domain with SRGB [16000-17000]</t> IS-IS domain</li>
</ul>
<t>B and C are in OSPF domain with SRGB [20000-21000]</t> <t pn="section-2.5.2.1-4">In this case, A learns 192.0.2.1/32 as an
IP leaf connected to B, which is
<t>B redistributes 192.0.2.1/32 into IS-IS domain</t>
<!--[rfced] Should the two points below actually be part of this list? S
eems kind of different from the first 3 points...-->
<t>In that case A learns 192.0.2.1/32 as an IP leaf connected to B as
usual for IP prefix redistribution</t> usual for IP prefix redistribution</t>
<t pn="section-2.5.2.1-5">However, according to the redistribution r
<t>However, according to the redistribution rule above rule, B ule above, B
decides not to advertise any index with 192.0.2.1/32 into IS-IS decides not to advertise any index with 192.0.2.1/32 into IS-IS
because the SRGB is not the same.</t> because the SRGB is not the same.</t>
</section>
</list> <section anchor="convert-section-2.5.2.2" numbered="true" toc="exclude
</t> " removeInRFC="false" pn="section-2.5.2.2">
<name slugifiedName="name-illustration-2">Illustration 2</name>
</section> <t pn="section-2.5.2.2-1">
Consider the example in the illustration described in <xref target="convert-s
<section title="Illustration 2" anchor="section-2.5.2.2"><t> ection-2.5.2.1" format="default" sectionFormat="of" derivedContent="Section 2.5.
Consider the example in the illustration described in <xref target="section-2 2.1"/>.</t>
.5.2.1"/>.</t> <t pn="section-2.5.2.2-2">
<t>
When router B redistributes the prefix 192.0.2.1/32, router B decides When router B redistributes the prefix 192.0.2.1/32, router B decides
to allocate and advertise the same index 1 with the prefix to allocate and advertise the same index 1 with the prefix
192.0.2.1/32</t> 192.0.2.1/32.</t>
<t pn="section-2.5.2.2-3">
<t>
Within the SRGB of the IS-IS domain, index 1 corresponds to the local Within the SRGB of the IS-IS domain, index 1 corresponds to the local
label 16001</t> label 16001. Hence, according to the redistribution rule above, router B
<t><list style="symbols"><t>Hence according to the redistribution rule ab
ove, router B
programs the incoming label 16001 in its FIB to match traffic programs the incoming label 16001 in its FIB to match traffic
arriving from the IS-IS domain destined to the prefix arriving from the IS-IS domain destined to the prefix
192.0.2.1/32.</t> 192.0.2.1/32.</t>
</section>
</section>
</section>
<section anchor="convert-section-2.6" numbered="true" toc="include" remove
InRFC="false" pn="section-2.6">
<name slugifiedName="name-effect-of-incoming-label-co">Effect of Incomin
g Label Collision on Outgoing Label Programming</name>
<t pn="section-2.6-1">
</list> When determining what outgoing label to use, the ingress node
</t> that pushes new segments, and hence a stack of MPLS labels, <bcp14>MUST</bcp1
4> use, for
</section> a given FEC, the label that has been selected by the node
receiving the packet with that label exposed as the top label. So in case
</section>
</section>
<section title="Effect of Incoming Label Collision on Outgoing Label Prog
ramming" anchor="section-2.6"><t>
For the determination of the outgoing label to use, the ingress node
pushing new segments, and hence a stack of MPLS labels, MUST use, for
a given FEC, the same label that has been selected by the node
receiving the packet with that label exposed as top label. So in case
of incoming label collision on this receiving node, the ingress node of incoming label collision on this receiving node, the ingress node
MUST resolve this collision using this same "Incoming Label Collision resolut <bcp14>MUST</bcp14> resolve this collision by using this same "Incoming Label
ion procedure", using the data of the receiving node.</t> Collision resolution procedure" and by using the data of the receiving node.</t
>
<t> <t pn="section-2.6-2">
In the general case, the ingress node may not have exactly the same In the general case, the ingress node may not have the exact same
data of the receiving node, so the result may be different. This is data as the receiving node, so the result may be different. This is
under the responsibility of the network operator. But in typical under the responsibility of the network operator. But in a typical
case, e.g. where a centralized node or a distributed link state IGP case, e.g., where a centralized node or a distributed link-state IGP
is used, all nodes would have the same database. However to minimize is used, all nodes would have the same database. However, to minimize
the chance of misforwarding, a FEC that loses its incoming label to the chance of misforwarding, a FEC that loses its incoming label to
the tie-breaking rules specified in <xref target="section-2.5"/> MUST NOT be the tiebreaking rules specified in <xref target="convert-section-2.5" format=
installed in FIB with an outgoing segment routing label based on the "default" sectionFormat="of" derivedContent="Section 2.5"/> <bcp14>MUST NOT</bcp
14> be
installed in FIB with an outgoing Segment Routing label based on the
SID corresponding to the lost incoming label.</t> SID corresponding to the lost incoming label.</t>
<t pn="section-2.6-3">
<t>
Examples for the behavior specified in this section can be found in Examples for the behavior specified in this section can be found in
Appendix A.3.</t> <xref target="convert-section-a.3" format="default" sectionFormat="of" derive
dContent="Appendix A.3"/>.</t>
</section> </section>
<section anchor="convert-section-2.7" numbered="true" toc="include" remove
<section title="PUSH, CONTINUE, and NEXT" anchor="section-2.7"><t> InRFC="false" pn="section-2.7">
<name slugifiedName="name-push-continue-and-next">PUSH, CONTINUE, and NE
XT</name>
<t pn="section-2.7-1">
PUSH, NEXT, and CONTINUE are operations applied by the forwarding PUSH, NEXT, and CONTINUE are operations applied by the forwarding
plane. The specifications of these operations can be found in plane. The specifications of these operations can be found in
<xref target="RFC8402"/>. This sub-section specifies how to implement each of these <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RF C8402"/>. This subsection specifies how to implement each of these
operations in the MPLS forwarding plane.</t> operations in the MPLS forwarding plane.</t>
<section anchor="convert-section-2.7.1" numbered="true" toc="include" re
<section title="PUSH" anchor="section-2.7.1"><t> moveInRFC="false" pn="section-2.7.1">
As described in <xref target="RFC8402"/>, PUSH corresponds to pushing one or <name slugifiedName="name-push">PUSH</name>
more <t pn="section-2.7.1-1">
As described in <xref target="RFC8402" format="default" sectionFormat="of" de
rivedContent="RFC8402"/>, PUSH corresponds to pushing one or more
labels on top of an incoming packet then sending it out of a labels on top of an incoming packet then sending it out of a
particular physical interface or virtual interface, such as UDP particular physical interface or virtual interface, such as a UDP
tunnel <xref target="RFC7510"/> or L2TPv3 tunnel <xref target="RFC4817"/>, to tunnel <xref target="RFC7510" format="default" sectionFormat="of" derivedCont
wards a particular ent="RFC7510"/> or the Layer 2 Tunneling Protocol version 3 (L2TPv3) <xref targe
next-hop. When pushing labels onto a packet's label stack, the Time- t="RFC4817" format="default" sectionFormat="of" derivedContent="RFC4817"/>, towa
to-Live (TTL) field (<xref target="RFC3032"/>, <xref target="RFC3443"/>) and rds a particular
the Traffic Class (TC) next hop.
field (<xref target="RFC3032"/>, <xref target="RFC5462"/>) of each label stac
k entry must, of When pushing labels onto a packet's label stack, the Time-to-Live
(TTL) field <xref target="RFC3032" format="default" sectionFormat="of" derive
dContent="RFC3032"/> <xref target="RFC3443" format="default" sectionFormat="of"
derivedContent="RFC3443"/> and the Traffic Class (TC)
field <xref target="RFC3032" format="default" sectionFormat="of" derivedConte
nt="RFC3032"/> <xref target="RFC5462" format="default" sectionFormat="of" derive
dContent="RFC5462"/> of each label stack entry must, of
course, be set. This document does not specify any set of rules for course, be set. This document does not specify any set of rules for
setting these fields; that is a matter of local policy. Sections setting these fields; that is a matter of local policy. Sections <xref target
2.10 and 2.11 specify additional details about forwarding ="convert-section-2.10" format="counter" sectionFormat="of" derivedContent="2.10
"/> and <xref target="convert-section-2.11" format="counter" sectionFormat="of"
derivedContent="2.11"/> specify additional details about forwarding
behavior.</t> behavior.</t>
</section>
</section> <section anchor="convert-section-2.7.2" numbered="true" toc="include" re
moveInRFC="false" pn="section-2.7.2">
<section title="CONTINUE" anchor="section-2.7.2"><t> <name slugifiedName="name-continue">CONTINUE</name>
As described in <xref target="RFC8402"/>, the CONTINUE operation corresponds <t pn="section-2.7.2-1">
to As described in <xref target="RFC8402" format="default" sectionFormat="of" de
rivedContent="RFC8402"/>, the CONTINUE operation corresponds to
swapping the incoming label with an outgoing label. The value of the swapping the incoming label with an outgoing label. The value of the
outgoing label is calculated as specified in Sections 2.10 and 2.11.</t> outgoing label is calculated as specified in Sections <xref target="convert-s
ection-2.10" format="counter" sectionFormat="of" derivedContent="2.10"/> and <xr
</section> ef target="convert-section-2.11" format="counter" sectionFormat="of" derivedCont
ent="2.11"/>.</t>
<section title="NEXT" anchor="section-2.7.3"><t> </section>
As described in <xref target="RFC8402"/>, NEXT corresponds to popping the top <section anchor="convert-section-2.7.3" numbered="true" toc="include" re
most moveInRFC="false" pn="section-2.7.3">
<name slugifiedName="name-next">NEXT</name>
<t pn="section-2.7.3-1">
As described in <xref target="RFC8402" format="default" sectionFormat="of" de
rivedContent="RFC8402"/>, NEXT corresponds to popping the topmost
label. The action before and/or after the popping depends on the label. The action before and/or after the popping depends on the
instruction associated with the active SID on the received packet instruction associated with the active SID on the received packet
prior to the popping. For example suppose the active SID in the prior to the popping. For example, suppose the active SID in the
received packet was an Adj-SID <xref target="RFC8402"/>, then on receiving th received packet was an Adj-SID <xref target="RFC8402" format="default" sectio
e nFormat="of" derivedContent="RFC8402"/>; on receiving the
packet, the node applies NEXT operation, which corresponds to popping packet, the node applies the NEXT operation, which corresponds to popping
the top most label, and then sends the packet out of the physical or the topmost label, and then sends the packet out of the physical or
virtual interface (e.g. UDP tunnel <xref target="RFC7510"/> or L2TPv3 tunnel virtual interface (e.g., the UDP tunnel <xref target="RFC7510" format="defaul
<xref target="RFC4817"/>) towards the next-hop corresponding to the adj-SID.< t" sectionFormat="of" derivedContent="RFC7510"/> or L2TPv3 tunnel
/t> <xref target="RFC4817" format="default" sectionFormat="of" derivedContent="RF
C4817"/>) towards the next hop corresponding to the Adj-SID.</t>
<section title="Mirror SID" anchor="section-2.7.3.1"><t> <section anchor="convert-section-2.7.3.1" numbered="true" toc="exclude
If the active SID in the received packet was a Mirror SID [RFC8402, Section 5 " removeInRFC="false" pn="section-2.7.3.1">
.1] allocated by the receiving router, then the receiving <name slugifiedName="name-mirror-sid">Mirror SID</name>
router applies NEXT operation, which corresponds to popping the top <t pn="section-2.7.3.1-1">
most label, then performs a lookup using the contents of the packet If the active SID in the received packet was a Mirror SID (see <xref target="
after popping the outer most label in the mirrored forwarding table. RFC8402" sectionFormat="comma" section="5.1" format="default" derivedLink="https
://rfc-editor.org/rfc/rfc8402#section-5.1" derivedContent="RFC8402"/>) allocated
<!--[rfced] Should this all be one big paragraph? Occurs at a page break in by the receiving router, the receiving
original, so I can't tell. Diff file gives a hit here. --> router applies the NEXT operation, which corresponds to popping the topmost
label, and then performs a lookup using the contents of the packet
after popping the outermost label in the mirrored forwarding table.
The method by which the lookup is made, and/or the actions applied to The method by which the lookup is made, and/or the actions applied to
the packet after the lookup in the mirror table depends on the the packet after the lookup in the mirror table, depends on the
contents of the packet and the mirror table. Note that the packet contents of the packet and the mirror table. Note that the packet
exposed after popping the top most label may or may not be an MPLS exposed after popping the topmost label may or may not be an MPLS
packet. A mirror SID can be viewed as a generalization of the context packet. A Mirror SID can be viewed as a generalization of the context
label in <xref target="RFC5331"/> because a mirror SID does not make any label in <xref target="RFC5331" format="default" sectionFormat="of" derivedCo
ntent="RFC5331"/> because a Mirror SID does not make any
assumptions about the packet underneath the top label.</t> assumptions about the packet underneath the top label.</t>
</section>
</section> </section>
</section>
</section> <section anchor="convert-section-2.8" numbered="true" toc="include" remove
InRFC="false" pn="section-2.8">
</section> <name slugifiedName="name-mpls-label-downloaded-to-th">MPLS Label Downlo
aded to the FIB for Global and Local SIDs</name>
<section title="MPLS Label Downloaded to FIB for Global and Local SIDs" a <t pn="section-2.8-1">
nchor="section-2.8"><t> The label corresponding to the global SID "Si", which is represented by the
The label corresponding to the global SID "Si" represented by the global index "I" and downloaded to the FIB, is used to match packets whose
global index "I" downloaded to FIB is used to match packets whose
active segment (and hence topmost label) is "Si". The value of this active segment (and hence topmost label) is "Si". The value of this
label is calculated as specified in <xref target="section-2.4"/>.</t> label is calculated as specified in <xref target="convert-section-2.4" format
="default" sectionFormat="of" derivedContent="Section 2.4"/>.</t>
<t> <t pn="section-2.8-2">
For Local SIDs, the MCC is responsible for downloading the correct For Local SIDs, the MCC is responsible for downloading the correct
label value to FIB. For example, an IGP with SR extensions [I-D.ietf-isis-seg label value to the FIB. For example, an IGP with SR extensions <xref target="
ment-routing-extensions, I-D.ietf-ospf-segment-routing-extensions] downloads the RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> <xref ta
MPLS label corresponding to an Adj-SID rget="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/> do
<xref target="RFC8402"/>.</t> wnloads the MPLS label corresponding to an Adj-SID <xref target="RFC8402" format
="default" sectionFormat="of" derivedContent="RFC8402"/>.</t>
</section> </section>
<section anchor="convert-section-2.9" numbered="true" toc="include" remove
<section title="Active Segment" anchor="section-2.9"><t> InRFC="false" pn="section-2.9">
<name slugifiedName="name-active-segment">Active Segment</name>
<t pn="section-2.9-1">
When instantiated in the MPLS domain, the active segment on a packet When instantiated in the MPLS domain, the active segment on a packet
corresponds to the topmost label on the packet that is calculated corresponds to the topmost label and is calculated
according to the procedure specified in Sections 2.10 and 2.11. When according to the procedure specified in Sections <xref target="convert-sectio
n-2.10" format="counter" sectionFormat="of" derivedContent="2.10"/> and <xref ta
rget="convert-section-2.11" format="counter" sectionFormat="of" derivedContent="
2.11"/>. When
arriving at a node, the topmost label corresponding to the active SID arriving at a node, the topmost label corresponding to the active SID
matches the MPLS label downloaded to FIB as specified in <xref target="sectio matches the MPLS label downloaded to the FIB as specified in <xref target="co
n-2.4"/>.</t> nvert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2
.4"/>.</t>
</section> </section>
<section anchor="convert-section-2.10" numbered="true" toc="include" remov
<section title="Forwarding behavior for Global SIDs" anchor="section-2.10 eInRFC="false" pn="section-2.10">
"><t> <name slugifiedName="name-forwarding-behavior-for-glo">Forwarding Behavi
This section specifies forwarding behavior, including the calculation or for Global SIDs</name>
<t pn="section-2.10-1">
This section specifies the forwarding behavior, including the calculation
of outgoing labels, that corresponds to a global SID when applying of outgoing labels, that corresponds to a global SID when applying
PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.</t> the PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.</t>
<t pn="section-2.10-2">
<t>
This document covers the calculation of the outgoing label for the This document covers the calculation of the outgoing label for the
top label only. The case where the outgoing label is not the top top label only. The case where the outgoing label is not the top
label and is part of a stack of labels that instantiates a routing label and is part of a stack of labels that instantiates a routing
policy or a traffic engineering tunnel is outside the scope of this policy or a traffic-engineering tunnel is outside the scope of this
document and may be covered in other documents such as <xref target="I-D.ietf document and may be covered in other documents such as <xref target="ROUTING-
-spring-segment-routing-policy"/>.</t> POLICY" format="default" sectionFormat="of" derivedContent="ROUTING-POLICY"/>.</
t>
<section title="Forwarding for PUSH and CONTINUE of Global SIDs" anchor=" <section anchor="convert-section-2.10.1" numbered="true" toc="include" r
section-2.10.1"><t> emoveInRFC="false" pn="section-2.10.1">
Suppose an MCC on a router "R0" determines that PUSH or CONTINUE <name slugifiedName="name-forwarding-for-push-and-con">Forwarding for
operation is to be applied to an incoming packet related to the PUSH and CONTINUE of Global SIDs</name>
global SID "Si" represented by the global index "I" and owned by the <t pn="section-2.10.1-1">
router Ri before sending the packet towards a neighbor "N" directly Suppose an MCC on router "R0" determines that, before sending the packet towar
connected to "R0" through a physical or virtual interface such as UDP ds a neighbor "N", the PUSH or CONTINUE
tunnel <xref target="RFC7510"/> or L2TPv3 tunnel <xref target="RFC4817"/>.</t operation is to be applied to an incoming packet related to the global SID "Si
> ".
SID "Si" is represented by the global index "I" and owned by the router Ri.
<t> Neighbor "N" may be directly
The method by which the MCC on router "R0" determines that PUSH or connected to "R0" through either a physical or a virtual interface (e.g.,
UDP tunnel <xref target="RFC7510" format="default" sectionFormat="of" derivedC
ontent="RFC7510"/> or L2TPv3 tunnel <xref target="RFC4817" format="default" sect
ionFormat="of" derivedContent="RFC4817"/>).
</t>
<t pn="section-2.10.1-2">
The method by which the MCC on router "R0" determines that the PUSH or
CONTINUE operation must be applied using the SID "Si" is beyond the CONTINUE operation must be applied using the SID "Si" is beyond the
scope of this document. An example of a method to determine the SID scope of this document.
"Si" for PUSH operation is the case where IS-IS <xref target="I-D.ietf-isis-s
egment-routing-extensions"/> receives the prefix-SID "Si" sub-TLV
advertised with prefix "P/m" in TLV 135 and the destination address
of the incoming IPv4 packet is covered by the prefix "P/m".</t>
<t> An example of a method to determine the SID
For CONTINUE operation, an example of a method to determine the SID "Si" for the PUSH operation is the case where IS-IS <xref target="RFC8667" fo
"Si" is the case where IS-IS <xref target="I-D.ietf-isis-segment-routing-exte rmat="default" sectionFormat="of" derivedContent="RFC8667"/>
nsions"/> receives the prefix-SID "Si" sub-TLV advertised with receives the Prefix-SID "Si" sub-TLV
prefix "P" in TLV 135 and the top label of the incoming packet advertised with the prefix "P/m" in TLV 135, and the prefix "P/m" is the long
matches the MPLS label in FIB corresponding to the SID "Si" on the est matching
network prefix for the incoming IPv4 packet.</t>
<t pn="section-2.10.1-3">
For the CONTINUE operation, an example of a method used to determine the SID
"Si" is the case where IS-IS <xref target="RFC8667" format="default" sectionF
ormat="of" derivedContent="RFC8667"/> receives the Prefix-SID "Si" sub-TLV adver
tised with
prefix "P" in TLV 135, and the top label of the incoming packet
matches the MPLS label in the FIB corresponding to the SID "Si" on
router "R0".</t> router "R0".</t>
<t pn="section-2.10.1-4">
<t>
The forwarding behavior for PUSH and CONTINUE corresponding to the The forwarding behavior for PUSH and CONTINUE corresponding to the
SID "Si"</t> SID "Si" is as follows:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.10.1-5">
<t> <li pn="section-2.10.1-5.1">
<list style="symbols"> <t pn="section-2.10.1-5.1.1">If neighbor "N" does not support SR o
<t>If the neighbor "N" does not support SR or advertises an invalid r advertises an invalid
SRGB or a SRGB that is too small for the SID "Si" SRGB or a SRGB that is too small for the SID "Si", then:
<list style="symbols"> </t>
<t>If it is possible to send the packet towards the neighbor "N" <ul spacing="normal" bare="false" empty="false" pn="section-2.10.1
-5.1.2">
<li pn="section-2.10.1-5.1.2.1">If it is possible to send the pa
cket towards neighbor "N"
using standard MPLS forwarding behavior as specified in using standard MPLS forwarding behavior as specified in
<xref target="RFC3031"/> and <xref target="RFC3032"/>, then forward the packet. The method <xref target="RFC3031" format="default" sectionFormat="of" derivedConte nt="RFC3031"/> and <xref target="RFC3032" format="default" sectionFormat="of" de rivedContent="RFC3032"/>, forward the packet. The method
by which a router decides whether it is possible to send the by which a router decides whether it is possible to send the
packet to "N" or not is beyond the scope of this document. For packet to "N" or not is beyond the scope of this document. For
example, the router "R0" can use the downstream label example, the router "R0" can use the downstream label
determined by another MCC, such as LDP <xref target="RFC5036"/>, to sen determined by another MCC, such as LDP <xref target="RFC5036" format="d
d the efault" sectionFormat="of" derivedContent="RFC5036"/>, to send the
packet.</t> packet.</li>
<li pn="section-2.10.1-5.1.2.2">Else, if there are other usable
<t>Else if there are other useable next-hops, then use other next- next hops, use them to forward the incoming packet.
hops to forward the incoming packet. The method by which the The method by which the
router "R0" decides on the possibility of using other next- router "R0" decides on the possibility of using other next hops
hops is beyond the scope of this document. For example, the is beyond the scope of this document. For example, the
MCC on "R0" may chose the send an IPv4 packet without pushing MCC on "R0" may chose the send an IPv4 packet without pushing
any label to another next-hop.</t> any label to another next hop.</li>
<li pn="section-2.10.1-5.1.2.3">Otherwise, drop the packet.</li>
<t>Otherwise drop the packet.</t> </ul>
</li>
</list> <li pn="section-2.10.1-5.2">
</t> <t pn="section-2.10.1-5.2.1">Else,
</t>
<t>Else <ul spacing="normal" bare="false" empty="false" pn="section-2.10.1
-5.2.2">
<list style="symbols"> <li pn="section-2.10.1-5.2.2.1">
Calculate the outgoing label as specified in <xref target="con
<t>Calculate the outgoing label as specified in <xref target="section-2 vert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2.
.4"/> using 4"/> using
the SRGB of the neighbor "N" the SRGB of neighbor "N".
</li>
<list style="symbols"> <li pn="section-2.10.1-5.2.2.2">
<!--[rfced] id2xml is reading the following bullet as a subpoint of " <t pn="section-2.10.1-5.2.2.2.1">Determine the outgoing label
Calculate the outgoing label...". I don't know if this is correct. Please revi stack</t>
ew.--> <ul spacing="normal" bare="false" empty="false" pn="section-2.
10.1-5.2.2.2.2">
<t>If the operation is PUSH <li pn="section-2.10.1-5.2.2.2.2.1">
<list style="symbols"> <t pn="section-2.10.1-5.2.2.2.2.1.1">If the operation is P
<t>Push the calculated label according to the MPLS label USH:
pushing rules specified in <xref target="RFC3032"/> </t>
</t> <ul spacing="normal" bare="false" empty="false" pn="sectio
</list></t> n-2.10.1-5.2.2.2.2.1.2">
<t>Else <li pn="section-2.10.1-5.2.2.2.2.1.2.1">Push the calcula
ted label according to the MPLS label
<list style="symbols"> pushing rules specified in <xref target="RFC3032" format="default"
sectionFormat="of" derivedContent="RFC3032"/>.
<t>swap the incoming label with the calculated label </li>
according to the label swapping rules in <xref target="RFC3032"/> </ul>
</t> </li>
</list> <li pn="section-2.10.1-5.2.2.2.2.2">
</t> <t pn="section-2.10.1-5.2.2.2.2.2.1">Else,
</t>
<t>Send the packet towards the neighbor "N"</t> <ul spacing="normal" bare="false" empty="false" pn="sectio
n-2.10.1-5.2.2.2.2.2.2">
</list> <li pn="section-2.10.1-5.2.2.2.2.2.2.1">swap the incomin
</t> g label with the calculated label
according to the label-swapping rules in <xref target="RFC3031" forma
</list> t="default" sectionFormat="of" derivedContent="RFC3031"/>.
</t> </li>
</ul>
</list> </li>
</t> <li pn="section-2.10.1-5.2.2.2.2.3">Send the packet towards
neighbor "N".</li>
</section> </ul>
</li>
<section title="Forwarding for NEXT Operation for Global SIDs" anchor="se </ul>
ction-2.10.2"><t> </li>
As specified in <xref target="section-2.7.3"/> NEXT operation corresponds to </ul>
popping </section>
the top most label. The forwarding behavior is as follows</t> <section anchor="convert-section-2.10.2" numbered="true" toc="include" r
emoveInRFC="false" pn="section-2.10.2">
<t><list style="symbols"><t>Pop the topmost label</t> <name slugifiedName="name-forwarding-for-the-next-ope">Forwarding for
the NEXT Operation for Global SIDs</name>
<t>Apply the instruction associated with the incoming label that has <t pn="section-2.10.2-1">
been popped</t> As specified in <xref target="convert-section-2.7.3" format="default" section
Format="of" derivedContent="Section 2.7.3"/>, the NEXT operation corresponds to
</list> popping
</t> the topmost label. The forwarding behavior is as follows:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2.10.2-2">
<t> <li pn="section-2.10.2-2.1">Pop the topmost label</li>
<li pn="section-2.10.2-2.2">Apply the instruction associated with th
e incoming label that has
been popped</li>
</ul>
<t pn="section-2.10.2-3">
The action on the packet after popping the topmost label depends on The action on the packet after popping the topmost label depends on
the instruction associated with the incoming label as well as the the instruction associated with the incoming label as well as the
contents of the packet right underneath the top label that got contents of the packet right underneath the top label that was
popped. Examples of NEXT operation are described in Appendix A.1.</t> popped. Examples of the NEXT operation are described in <xref target="convert
-section-a.1" format="default" sectionFormat="of" derivedContent="Appendix A.1"/
</section> ></t>
</section>
</section> </section>
<section anchor="convert-section-2.11" numbered="true" toc="include" remov
<section title="Forwarding Behavior for Local SIDs" anchor="section-2.11" eInRFC="false" pn="section-2.11">
><t> <name slugifiedName="name-forwarding-behavior-for-loc">Forwarding Behavi
This section specifies the forwarding behavior for local SIDs when SR or for Local SIDs</name>
<t pn="section-2.11-1">
This section specifies the forwarding behavior for Local SIDs when SR
is instantiated over the MPLS forwarding plane.</t> is instantiated over the MPLS forwarding plane.</t>
<section anchor="convert-section-2.11.1" numbered="true" toc="include" r
<section title="Forwarding for PUSH Operation on Local SIDs" anchor="sect emoveInRFC="false" pn="section-2.11.1">
ion-2.11.1"><t> <name slugifiedName="name-forwarding-for-the-push-ope">Forwarding for
Suppose an MCC on a router "R0" determines that PUSH operation is to the PUSH Operation on Local SIDs</name>
be applied to an incoming packet using the local SID "Si" before <t pn="section-2.11.1-1">
sending the packet towards a neighbor "N" directly connected to R0 Suppose an MCC on router "R0" determines that the PUSH operation is to
through a physical or virtual interface such as UDP tunnel <xref target="RFC7 be applied to an incoming packet using the Local SID "Si" before
510"/> sending the packet towards neighbor "N", which is directly connected to R0
or L2TPv3 tunnel <xref target="RFC4817"/>.</t> through a physical or virtual interface such as a UDP tunnel <xref target="RF
C7510" format="default" sectionFormat="of" derivedContent="RFC7510"/>
<t> or L2TPv3 tunnel <xref target="RFC4817" format="default" sectionFormat="of" d
An example of such local SID is an Adj-SID allocated and advertised erivedContent="RFC4817"/>.</t>
by IS-IS <xref target="I-D.ietf-isis-segment-routing-extensions"/>. The metho <t pn="section-2.11.1-2">
d by An example of such a Local SID is an Adj-SID allocated and advertised
which the MCC on "R0" determines that PUSH operation is to be applied by IS-IS <xref target="RFC8667" format="default" sectionFormat="of" derivedCo
ntent="RFC8667"/>. The method by
which the MCC on "R0" determines that the PUSH operation is to be applied
to the incoming packet is beyond the scope of this document. An to the incoming packet is beyond the scope of this document. An
example of such method is backup path used to protect against a example of such a method is the backup path used to protect against a
failure using TI-LFA <xref target="I-D.bashandy-rtgwg-segment-routing-ti-lfa" failure using TI-LFA <xref target="FAST-REROUTE" format="default" sectionForm
/>.</t> at="of" derivedContent="FAST-REROUTE"/>.</t>
<t pn="section-2.11.1-3">
<t> As mentioned in <xref target="RFC8402" format="default" sectionFormat="of" de
As mentioned in <xref target="RFC8402"/>, a local SID is specified by an MPLS rivedContent="RFC8402"/>, a Local SID is specified by an MPLS label.
label. Hence, the PUSH operation for a Local SID is identical to the label push
Hence the PUSH operation for a local SID is identical to label push operation using any MPLS label <xref target="RFC3031" format="default" sectio
operation <xref target="RFC3032"/> using any MPLS label. The forwarding actio nFormat="of" derivedContent="RFC3031"/>. The forwarding action after
n after pushing the MPLS label corresponding to the Local SID is also
pushing the MPLS label corresponding to the local SID is also
determined by the MCC. For example, if the PUSH operation was done to determined by the MCC. For example, if the PUSH operation was done to
forward a packet over a backup path calculated using TI-LFA, then the forward a packet over a backup path calculated using TI-LFA, then the
forwarding action may be sending the packet to a certain neighbor forwarding action may be sending the packet to a certain neighbor
that will in turn continue to forward the packet along the backup that will in turn continue to forward the packet along the backup
path</t> path.</t>
</section>
</section> <section anchor="convert-section-2.11.2" numbered="true" toc="include" r
emoveInRFC="false" pn="section-2.11.2">
<section title="Forwarding for CONTINUE Operation for Local SIDs" anchor= <name slugifiedName="name-forwarding-for-the-continue">Forwarding for
"section-2.11.2"><t> the CONTINUE Operation for Local SIDs</name>
A local SID on a router "R0" corresponds to a local label. In such <t pn="section-2.11.2-1">
scenario, the outgoing label towards a next-hop "N" is determined by A Local SID on router "R0" corresponds to a local label.
the MCC running on the router "R0"and the forwarding behavior for In such a
CONTINUE operation is identical to swap operation <xref target="RFC3032"/> on scenario, the outgoing label towards next hop "N" is determined by
an the MCC running on the router "R0", and the forwarding behavior for the
MPLS label.</t> CONTINUE operation is identical to the swap operation on an
MPLS label <xref target="RFC3031" format="default" sectionFormat="of" derived
</section> Content="RFC3031"/>.</t>
</section>
<section title="Outgoing label for NEXT Operation for Local SIDs" anchor= <section anchor="convert-section-2.11.3" numbered="true" toc="include" r
"section-2.11.3"><t> emoveInRFC="false" pn="section-2.11.3">
NEXT operation for Local SIDs is identical to NEXT operation for <name slugifiedName="name-outgoing-label-for-the-next">Outgoing Label
global SIDs specified in <xref target="section-2.10.2"/>.</t> for the NEXT Operation for Local SIDs</name>
<t pn="section-2.11.3-1">
</section> The NEXT operation for Local SIDs is identical to the NEXT operation for
global SIDs as specified in <xref target="convert-section-2.10.2" format="def
</section> ault" sectionFormat="of" derivedContent="Section 2.10.2"/>.</t>
</section>
</section> </section>
</section>
<section title="IANA Considerations" anchor="section-3"><t> <section anchor="convert-section-3" numbered="true" toc="include" removeInRF
This document does not make any request to IANA.</t> C="false" pn="section-3">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
</section> <t pn="section-3-1">
This document has no IANA actions.</t>
<section title="Manageability Considerations" anchor="section-4"><t> </section>
<section anchor="convert-section-4" numbered="true" toc="include" removeInRF
C="false" pn="section-4">
<name slugifiedName="name-manageability-consideration">Manageability Consi
derations</name>
<t pn="section-4-1">
This document describes the applicability of Segment Routing over the This document describes the applicability of Segment Routing over the
MPLS data plane. Segment Routing does not introduce any change in MPLS data plane. Segment Routing does not introduce any change in
the MPLS data plane. Manageability considerations described in the MPLS data plane. Manageability considerations described in
<xref target="RFC8402"/> applies to the MPLS data plane when used with Segmen <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RF
t C8402"/> apply to the MPLS data plane when used with Segment
Routing. SR OAM use cases for the MPLS data plane are defined in Routing. SR Operations, Administration, and Maintenance (OAM) use cases for t
<xref target="RFC8403"/>. SR OAM procedures for the MPLS data plane are defi he MPLS data plane are defined in
ned in <xref target="RFC8403" format="default" sectionFormat="of" derivedContent="RF
<xref target="RFC8287"/>.</t> C8403"/>. SR OAM procedures for the MPLS data plane are defined in
<xref target="RFC8287" format="default" sectionFormat="of" derivedContent="RF
</section> C8287"/>.</t>
</section>
<section title="Security Considerations" anchor="section-5"><t> <section anchor="convert-section-5" numbered="true" toc="include" removeInRF
C="false" pn="section-5">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t pn="section-5-1">
This document does not introduce additional security requirements and This document does not introduce additional security requirements and
mechanisms other than the ones described in <xref target="RFC8402"/>.</t> mechanisms other than the ones described in <xref target="RFC8402" format="de
fault" sectionFormat="of" derivedContent="RFC8402"/>.</t>
</section> </section>
</middle>
<section title="Contributors" anchor="section-6"><t> <back>
The following contributors have substantially helped the definition <references pn="section-6">
and editing of the content of this document:</t> <name slugifiedName="name-references">References</name>
<references pn="section-6.1">
<figure><artwork><![CDATA[ <name slugifiedName="name-normative-references">Normative References</na
Martin Horneffer me>
Deutsche Telekom <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
Email: Martin.Horneffer@telekom.de 119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
Wim Henderickx <title>Key words for use in RFCs to Indicate Requirement Levels</tit
Nokia le>
Email: wim.henderickx@nokia.com <author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
Jeff Tantsura </author>
Email: jefftant@gmail.com <date year="1997" month="March"/>
Edward Crabbe <abstract>
Email: edward.crabbe@gmail.com <t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
Igor Milojevic This document defines these words as they should be interpreted in IETF document
Email: milojevicigor@gmail.com s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
Saku Ytti </abstract>
Email: saku@ytti.fi </front>
]]></artwork> <seriesInfo name="BCP" value="14"/>
</figure> <seriesInfo name="RFC" value="2119"/>
</section> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<section title="Acknowledgements" anchor="section-7"><t> <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3
The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu 031" quoteTitle="true" derivedAnchor="RFC3031">
Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren <front>
Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on <title>Multiprotocol Label Switching Architecture</title>
this document.</t> <author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
<t> </author>
This document was prepared using 2-Word-v2.0.template.dot.</t> <author initials="A." surname="Viswanathan" fullname="A. Viswanathan
">
</section> <organization showOnFrontPage="true"/>
</author>
</middle> <author initials="R." surname="Callon" fullname="R. Callon">
<organization showOnFrontPage="true"/>
<back> </author>
<references title="Normative References"> <date year="2001" month="January"/>
&RFC8402; <abstract>
&RFC2119; <t>This document specifies the architecture for Multiprotocol Labe
&RFC3031; l Switching (MPLS). [STANDARDS-TRACK]</t>
&RFC3032; </abstract>
&RFC3443; </front>
&RFC5462; <seriesInfo name="RFC" value="3031"/>
&RFC7274; <seriesInfo name="DOI" value="10.17487/RFC3031"/>
&RFC8174; </reference>
</references> <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3
<references title="Informative References"> 032" quoteTitle="true" derivedAnchor="RFC3032">
&I-D.ietf-isis-segment-routing-extensions; <front>
&I-D.ietf-ospf-ospfv3-segment-routing-extensions; <title>MPLS Label Stack Encoding</title>
&I-D.ietf-ospf-segment-routing-extensions; <author initials="E." surname="Rosen" fullname="E. Rosen">
&I-D.ietf-spring-segment-routing-ldp-interop; <organization showOnFrontPage="true"/>
&I-D.bashandy-rtgwg-segment-routing-ti-lfa; </author>
&RFC7855; <author initials="D." surname="Tappan" fullname="D. Tappan">
&RFC5036; <organization showOnFrontPage="true"/>
&RFC5331; </author>
&RFC7510; <author initials="G." surname="Fedorkow" fullname="G. Fedorkow">
&RFC4817; <organization showOnFrontPage="true"/>
&RFC8287; </author>
&RFC8403; <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
&I-D.ietf-spring-segment-routing-policy; <organization showOnFrontPage="true"/>
</references> </author>
<section title="Examples" anchor="section-a"><section title="IGP Segments <author initials="D." surname="Farinacci" fullname="D. Farinacci">
Example" anchor="section-a.1"><t> <organization showOnFrontPage="true"/>
Consider the network diagram of Figure 1 and the IP address and IGP </author>
Segment allocation of Figure 2. Assume that the network is running <author initials="T." surname="Li" fullname="T. Li">
IS-IS with SR extensions <xref target="I-D.ietf-isis-segment-routing-extensio <organization showOnFrontPage="true"/>
ns"/> </author>
<author initials="A." surname="Conta" fullname="A. Conta">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="January"/>
<abstract>
<t>This document specifies the encoding to be used by an LSR in or
der to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on
LAN data links, and possibly on other data links as well. This document also sp
ecifies rules and procedures for processing the various fields of the label stac
k encoding. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3032"/>
<seriesInfo name="DOI" value="10.17487/RFC3032"/>
</reference>
<reference anchor="RFC3443" target="https://www.rfc-editor.org/info/rfc3
443" quoteTitle="true" derivedAnchor="RFC3443">
<front>
<title>Time To Live (TTL) Processing in Multi-Protocol Label Switchi
ng (MPLS) Networks</title>
<author initials="P." surname="Agarwal" fullname="P. Agarwal">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Akyol" fullname="B. Akyol">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="January"/>
<abstract>
<t>This document describes Time To Live (TTL) processing in hierar
chical Multi-Protocol Label Switching (MPLS) networks and is motivated by the ne
ed to formalize a TTL-transparent mode of operation for an MPLS label-switched p
ath. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both P
ipe and Uniform Model hierarchical tunnels are specified with examples for both
"push" and "pop" cases. The document also complements RFC 3270, "MPLS Support o
f Differentiated Services" and ties together the terminology introduced in that
document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="3443"/>
<seriesInfo name="DOI" value="10.17487/RFC3443"/>
</reference>
<reference anchor="RFC5462" target="https://www.rfc-editor.org/info/rfc5
462" quoteTitle="true" derivedAnchor="RFC5462">
<front>
<title>Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP"
Field Renamed to "Traffic Class" Field</title>
<author initials="L." surname="Andersson" fullname="L. Andersson">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Asati" fullname="R. Asati">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="February"/>
<abstract>
<t>The early Multiprotocol Label Switching (MPLS) documents define
d the form of the MPLS label stack entry. This includes a three-bit field calle
d the "EXP field". The exact use of this field was not defined by these documen
ts, except to state that it was to be "reserved for experimental use".</t>
<t>Although the intended use of the EXP field was as a "Class of S
ervice" (CoS) field, it was not named a CoS field by these early documents becau
se the use of such a CoS field was not considered to be sufficiently defined. T
oday a number of standards documents define its usage as a CoS field.</t>
<t>To avoid misunderstanding about how this field may be used, it
has become increasingly necessary to rename this field. This document changes t
he name of the field to the "Traffic Class field" ("TC field"). In doing so, it
also updates documents that define the current use of the EXP field. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5462"/>
<seriesInfo name="DOI" value="10.17487/RFC5462"/>
</reference>
<reference anchor="RFC7274" target="https://www.rfc-editor.org/info/rfc7
274" quoteTitle="true" derivedAnchor="RFC7274">
<front>
<title>Allocating and Retiring Special-Purpose MPLS Labels</title>
<author initials="K." surname="Kompella" fullname="K. Kompella">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Andersson" fullname="L. Andersson">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Farrel" fullname="A. Farrel">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="June"/>
<abstract>
<t>Some MPLS labels have been allocated for specific purposes. A
block of labels (0-15) has been set aside to this end; these labels are commonly
called "reserved labels". They will be called "special-purpose
labels" in this document.</t>
<t>As there are only 16 of these special-purpose labels, caution i
s needed in the allocation of new special-purpose labels; yet, at the same time,
forward progress should be allowed when one is called for.</t>
<t>This memo defines new procedures for the allocation and retirem
ent of special-purpose labels, as well as a method to extend the special-purpose
label space and a description of how to handle extended special-purpose labels
in the data plane. Finally, this memo renames the IANA registry for special-purp
ose labels to "Special-Purpose MPLS Label Values" and creates a new registry cal
led the "Extended Special-Purpose MPLS Label Values" registry.</t
>
<t>This document updates a number of previous RFCs that use the te
rm "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209,
3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7274"/>
<seriesInfo name="DOI" value="10.17487/RFC7274"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<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
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
402" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<title>Segment Routing Architecture</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="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A
node steers a packet through an ordered list of instructions, called "segments".
A segment can represent any instruction, topological or service based. A segm
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
l path, while maintaining per-flow state only at the ingress node(s) to the SR d
omain.</t>
<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
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
d from the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of
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
he active segment is indicated by the Destination Address (DA) of the packet. T
he next active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
</references>
<references pn="section-6.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="FAST-REROUTE" quoteTitle="true" target="https://tools
.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-01" derivedAnchor="FAST-R
EROUTE">
<front>
<title>Topology Independent Fast Reroute using Segment Routing</titl
e>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
i">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Francois" fullname="Pierre Francois">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Voyer" fullname="Daniel Voyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="F" surname="Clad" fullname="Francois Clad">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Camarillo" fullname="Pablo Camarillo">
<organization showOnFrontPage="true"/>
</author>
<date month="March" day="5" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-segment-rout
ing-ti-lfa-01"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC4817" target="https://www.rfc-editor.org/info/rfc4
817" quoteTitle="true" derivedAnchor="RFC4817">
<front>
<title>Encapsulation of MPLS over Layer 2 Tunneling Protocol Version
3</title>
<author initials="M." surname="Townsley" fullname="M. Townsley">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Wainner" fullname="S. Wainner">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Seely" fullname="T. Seely">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Young" fullname="J. Young">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="March"/>
<abstract>
<t>The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a pr
otocol for tunneling a variety of payload types over IP networks. This document
defines how to carry an MPLS label stack and its payload over the L2TPv3 data en
capsulation. This enables an application that traditionally requires an MPLS-en
abled core network, to utilize an L2TPv3 encapsulation over an IP network instea
d. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4817"/>
<seriesInfo name="DOI" value="10.17487/RFC4817"/>
</reference>
<reference anchor="RFC5036" target="https://www.rfc-editor.org/info/rfc5
036" quoteTitle="true" derivedAnchor="RFC5036">
<front>
<title>LDP Specification</title>
<author initials="L." surname="Andersson" fullname="L. Andersson" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Minei" fullname="I. Minei" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Thomas" fullname="B. Thomas" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="October"/>
<abstract>
<t>The architecture for Multiprotocol Label Switching (MPLS) is de
scribed in RFC 3031. A fundamental concept in MPLS is that two Label Switching
Routers (LSRs) must agree on the meaning of the labels used to forward traffic b
etween and through them. This common understanding is achieved by using a set o
f procedures, called a label distribution protocol, by which one LSR informs ano
ther of label bindings it has made. This document defines a set of such procedu
res called LDP (for Label Distribution Protocol) by which LSRs distribute labels
to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5036"/>
<seriesInfo name="DOI" value="10.17487/RFC5036"/>
</reference>
<reference anchor="RFC5331" target="https://www.rfc-editor.org/info/rfc5
331" quoteTitle="true" derivedAnchor="RFC5331">
<front>
<title>MPLS Upstream Label Assignment and Context-Specific Label Spa
ce</title>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="August"/>
<abstract>
<t>RFC 3031 limits the MPLS architecture to downstream-assigned MP
LS labels. This document introduces the notion of upstream-assigned MPLS labels
. It describes the procedures for upstream MPLS label assignment and introduces
the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5331"/>
<seriesInfo name="DOI" value="10.17487/RFC5331"/>
</reference>
<reference anchor="RFC7510" target="https://www.rfc-editor.org/info/rfc7
510" quoteTitle="true" derivedAnchor="RFC7510">
<front>
<title>Encapsulating MPLS in UDP</title>
<author initials="X." surname="Xu" fullname="X. Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Sheth" fullname="N. Sheth">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Yong" fullname="L. Yong">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="April"/>
<abstract>
<t>This document specifies an IP-based encapsulation for MPLS, cal
led MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation
is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost M
ultipath) or link aggregation. The MPLS- in-UDP encapsulation technology must o
nly be deployed within a single network (with a single network operator) or netw
orks of an adjacent set of cooperating network operators where traffic is manage
d to avoid congestion, rather than over the Internet where congestion control is
required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is no
t congestion controlled and to UDP zero checksum usage with IPv6.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7510"/>
<seriesInfo name="DOI" value="10.17487/RFC7510"/>
</reference>
<reference anchor="RFC7855" target="https://www.rfc-editor.org/info/rfc7
855" quoteTitle="true" derivedAnchor="RFC7855">
<front>
<title>Source Packet Routing in Networking (SPRING) Problem Statemen
t and Requirements</title>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Horneffer" fullname="M. Horneffer">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="May"/>
<abstract>
<t>The ability for a node to specify a forwarding path, other than
the normal shortest path, that a particular packet will traverse, benefits a nu
mber of network functions. Source-based routing mechanisms have previously been
specified for network protocols but have not seen widespread adoption. In this
context, the term "source" means "the point at which the explicit route is impo
sed"; therefore, it is not limited to the originator of the packet (i.e., the no
de imposing the explicit route may be the ingress node of an operator's network)
.</t>
<t>This document outlines various use cases, with their requiremen
ts, that need to be taken into account by the Source Packet Routing in Networkin
g (SPRING) architecture for unicast traffic. Multicast use cases and requiremen
ts are out of scope for this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7855"/>
<seriesInfo name="DOI" value="10.17487/RFC7855"/>
</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="RFC8403" target="https://www.rfc-editor.org/info/rfc8
403" quoteTitle="true" derivedAnchor="RFC8403">
<front>
<title>A Scalable and Topology-Aware MPLS Data-Plane Monitoring Syst
em</title>
<author initials="R." surname="Geib" fullname="R. Geib" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Pignataro" fullname="C. Pignataro" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Kumar" fullname="N. Kumar">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t>This document describes features of an MPLS path monitoring sys
tem and related use cases. Segment-based routing enables a scalable and simple
method to monitor data-plane liveliness of the complete set of paths belonging t
o a single domain. The MPLS monitoring system adds features to the traditional
MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPL
S topology awareness reduces management and control-plane involvement of Operati
ons, Administration, and Maintenance (OAM) measurements while enabling new OAM f
eatures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8403"/>
<seriesInfo name="DOI" value="10.17487/RFC8403"/>
</reference>
<reference anchor="RFC8661" target="https://www.rfc-editor.org/info/rfC8
661" quoteTitle="true" derivedAnchor="RFC8661">
<front>
<title>Segment Routing MPLS Interworking with LDP</title>
<seriesInfo name="RFC" value="8661"/>
<seriesInfo name="DOI" value="10.17487/RFC8661"/>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
i">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8
665" quoteTitle="true" 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 Henderickx">
<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" target="https://www.rfc-editor.org/info/rfc8
666" quoteTitle="true" 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" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8
667" quoteTitle="true" 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" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Ginsberg" fullname="Les Ginsberg" role
="editor">
<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>
<reference anchor="ROUTING-POLICY" quoteTitle="true" target="https://too
ls.ietf.org/html/draft-ietf-spring-segment-routing-policy-05" derivedAnchor="ROU
TING-POLICY">
<front>
<title>Segment Routing Policy Architecture</title>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Voyer" fullname="Daniel Voyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Bogdanov" fullname="Alex Bogdanov">
<organization showOnFrontPage="true"/>
</author>
<author initials="P" surname="Mattes" fullname="Paul Mattes">
<organization showOnFrontPage="true"/>
</author>
<date month="November" day="17" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-segment-rou
ting-policy-05"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references>
</references>
<section anchor="convert-section-a" numbered="true" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-examples">Examples</name>
<section anchor="convert-section-a.1" numbered="true" toc="include" remove
InRFC="false" pn="section-a.1">
<name slugifiedName="name-igp-segment-examples">IGP Segment Examples</na
me>
<t pn="section-a.1-1">
Consider the network diagram of <xref target="fig1" format="default" sectionF
ormat="of" derivedContent="Figure 1"/> and the IP addresses and IGP
segment allocations of <xref target="fig2" format="default" sectionFormat="of
" derivedContent="Figure 2"/>. Assume that the network is running
IS-IS with SR extensions <xref target="RFC8667" format="default" sectionForma
t="of" derivedContent="RFC8667"/>,
and all links have the same metric. The following examples can be and all links have the same metric. The following examples can be
constructed.</t> constructed.</t>
<figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
<figure title="IGP Segments - Illustration" anchor="fig1"> <name slugifiedName="name-igp-segments-illustration">IGP Segments -- I
<artwork><![CDATA[ llustration</name>
<artwork name="" type="" align="left" alt="" pn="section-a.1-2.1">
+--------+ +--------+
/ \ / \
R0-----R1-----R2----------R3-----R8 R0-----R1-----R2----------R3-----R8
| \ / | | \ / |
| +--R4--+ | | +--R4--+ |
| | | |
+-----R5-----+ +-----R5-----+</artwork>
]]> </figure>
</artwork> <figure anchor="fig2" align="left" suppress-title="false" pn="figure-2">
</figure> <name slugifiedName="name-igp-address-and-segment-all">IGP Address and
Segment Allocation -- Illustration</name>
<figure title="IGP Address and Segment Allocation - Illustration" anchor=" <artwork name="" type="" align="left" alt="" pn="section-a.1-3.1">
fig2">
<artwork><![CDATA[
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| IP address allocated by the operator: | | IP addresses allocated by the operator: |
| 192.0.2.1/32 as a loopback of R1 | | 192.0.2.1/32 as a loopback of R1 |
| 192.0.2.2/32 as a loopback of R2 | | 192.0.2.2/32 as a loopback of R2 |
| 192.0.2.3/32 as a loopback of R3 | | 192.0.2.3/32 as a loopback of R3 |
| 192.0.2.4/32 as a loopback of R4 | | 192.0.2.4/32 as a loopback of R4 |
| 192.0.2.5/32 as a loopback of R5 | | 192.0.2.5/32 as a loopback of R5 |
| 192.0.2.8/32 as a loopback of R8 | | 192.0.2.8/32 as a loopback of R8 |
| 198.51.100.9/32 as an anycast loopback of R4 | | 198.51.100.9/32 as an anycast loopback of R4 |
| 198.51.100.9/32 as an anycast loopback of R5 | | 198.51.100.9/32 as an anycast loopback of R5 |
| | | |
| SRGB defined by the operator as 1000-5000 | | SRGB defined by the operator as [1000,5000] |
| | | |
| Global IGP SID indices allocated by the operator: | | Global IGP SID indices allocated by the operator: |
| 1 allocated to 192.0.2.1/32 | | 1 allocated to 192.0.2.1/32 |
| 2 allocated to 192.0.2.2/32 | | 2 allocated to 192.0.2.2/32 |
| 3 allocated to 192.0.2.3/32 | | 3 allocated to 192.0.2.3/32 |
| 4 allocated to 192.0.2.4/32 | | 4 allocated to 192.0.2.4/32 |
| 8 allocated to 192.0.2.8/32 | | 8 allocated to 192.0.2.8/32 |
| 1009 allocated to 198.51.100.9/32 | | 1009 allocated to 198.51.100.9/32 |
| | | |
| Local IGP SID allocated dynamically by R2 | | Local IGP SID allocated dynamically by R2 |
| for its "north" adjacency to R3: 9001 | | for its "north" adjacency to R3: 9001 |
| for its "east" adjacency to R3 : 9002 | | for its "east" adjacency to R3 : 9002 |
| for its "south" adjacency to R3: 9003 | | for its "south" adjacency to R3: 9003 |
| for its only adjacency to R4 : 9004 | | for its only adjacency to R4 : 9004 |
| for its only adjacency to R1 : 9005 | | for its only adjacency to R1 : 9005 |
+-----------------------------------------------------------+ +-----------------------------------------------------------+</artwork>
]]> </figure>
</artwork> <t pn="section-a.1-4">
</figure> Suppose R1 wants to send IPv4 packet P1 to R8. In this case, R1
needs to apply the PUSH operation to the IPv4 packet.</t>
<t> <t pn="section-a.1-5">
Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1
needs to apply PUSH operation to the IPv4 packet.</t>
<t>
Remember that the SID index "8" is a global IGP segment attached to Remember that the SID index "8" is a global IGP segment attached to
the IP prefix 192.0.2.8/32. Its semantic is global within the IGP the IP prefix 192.0.2.8/32. Its semantic is global within the IGP
domain: any router forwards a packet received with active segment 8 domain: any router forwards a packet received with active segment 8
to the next-hop along the ECMP-aware shortest-path to the related to the next hop along the ECMP-aware shortest path to the related
prefix.</t> prefix.</t>
<t pn="section-a.1-6">
<t> R2 is the next hop along the shortest path towards R8. By applying
R2 is the next-hop along the shortest path towards R8. By applying the steps in <xref target="convert-section-2.8" format="default" sectionForma
the steps in <xref target="section-2.8"/> the outgoing label downloaded to R1 t="of" derivedContent="Section 2.8"/>, the outgoing label downloaded to R1's FIB
's FIB corresponding to the global SID index "8" is 1008 because the SRGB of
corresponding to the global SID index 8 is 1008 because the SRGB of R2 = [1000,5000] as shown in <xref target="fig2" format="default" sectionForm
R2 is [1000,5000] as shown in Figure 2.</t> at="of" derivedContent="Figure 2"/>.</t>
<t pn="section-a.1-7">
<t>
Because the packet is IPv4, R1 applies the PUSH operation using the Because the packet is IPv4, R1 applies the PUSH operation using the
label value 1008 as specified in <xref target="section-2.10.1"/>. The resulti label value 1008 as specified in <xref target="convert-section-2.10.1" format
ng MPLS ="default" sectionFormat="of" derivedContent="Section 2.10.1"/>. The resulting M
header will have the "S" bit <xref target="RFC3032"/> set because it is follo PLS
wed header will have the "S" bit <xref target="RFC3032" format="default" sectionF
ormat="of" derivedContent="RFC3032"/> set because it is followed
directly by an IPv4 packet.</t> directly by an IPv4 packet.</t>
<t pn="section-a.1-8">
The packet arrives at router R2.
<t> Because top label 1008
The packet arrives at router R2. Because the top label 1008 corresponds to the IGP SID index "8", which is the Prefix-SID attached to
corresponds to the IGP SID "8", which is the prefix-SID attached to the prefix 192.0.2.8/32 owned by Node R8, the instruction
the prefix 192.0.2.8/32 owned by the node R8, then the instruction associated with the SID is "forward the packet using one of the ECMP interfac
associated with the SID is "forward the packet using all ECMP/UCMP interfaces es or next hops along the shortest path(s) towards R8". Because R2 is not the pe
and all ECMP/UCMP next-hop(s) along the shortest/useable path(s) towards R8". B nultimate hop, R2
ecause R2 is not the penultimate hop, R2
applies the CONTINUE operation to the packet and sends it to R3 using applies the CONTINUE operation to the packet and sends it to R3 using
one of the two links connected to R3 with top label 1008 as specified one of the two links connected to R3 with top label 1008 as specified
in <xref target="section-2.10.1"/>.</t> in <xref target="convert-section-2.10.1" format="default" sectionFormat="of"
derivedContent="Section 2.10.1"/>.</t>
<t> <t pn="section-a.1-9">
R3 receives the packet with top label 1008. Because the top label R3 receives the packet with top label 1008. Because top label
1008 corresponds to the IGP SID "8", which is the prefix-SID attached 1008 corresponds to the IGP SID index "8", which is the Prefix-SID attached
to the prefix 192.0.2.8/32 owned by the node R8, then the instruction to the prefix 192.0.2.8/32 owned by Node R8, the instruction
associated with the SID is "send the packet using all ECMP interfaces and all associated with the SID is "send the packet using one of the ECMP interfaces
next-hop(s) along the shortest path towards R8". Because R3 and next hops along the shortest path towards R8". Because R3
is the penultimate hop, we assume that R3 performs penumtimate hop is the penultimate hop, we assume that R3 performs penultimate hop
popping, which corresponds to the NEXT operation, then sends the popping, which corresponds to the NEXT operation; the packet is then sent to
packet to R8. The NEXT operation results in popping the outer label R8. The NEXT operation results in popping the outer label
and sending the packet as a pure IPv4 packet to R8.</t> and sending the packet as a pure IPv4 packet to R8.</t>
<t pn="section-a.1-10">
<t> In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP
In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- awareness ensures that the traffic is load-shared between any ECMP
awareness ensures that the traffic be load-shared between any ECMP path; in this case, it's the two links between R2 and R3.</t>
path, in this case the two links between R2 and R3.</t> </section>
<section anchor="convert-section-a.2" numbered="true" toc="include" remove
</section> InRFC="false" pn="section-a.2">
<name slugifiedName="name-incoming-label-collision-ex">Incoming Label Co
<section title="Incoming Label Collision Examples" anchor="section-a.2">< llision Examples</name>
t> <t pn="section-a.2-1">
This section describes few examples to illustrate the handling of This section outlines several examples to illustrate the handling of
label collision described in <xref target="section-2.5"/>.</t> label collision described in <xref target="convert-section-2.5" format="defau
lt" sectionFormat="of" derivedContent="Section 2.5"/>.</t>
<t> <t pn="section-a.2-2">
For the examples in this section, we assume that Node A has the For the examples in this section, we assume that Node A has the
following:</t> following:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-a.2-3">
<t><list style="symbols"><t>OSPF default admin distance for implementatio <li pn="section-a.2-3.1">OSPF default admin distance for implementatio
n=50</t> n=50</li>
<li pn="section-a.2-3.2">IS-IS default admin distance for implementati
<t>ISIS default admin distance for implementation=60</t> on=60</li>
</ul>
</list> <section anchor="convert-section-a.2.1" numbered="true" toc="include" re
</t> moveInRFC="false" pn="section-a.2.1">
<name slugifiedName="name-example-1">Example 1</name>
<section title="Example 1" anchor="section-a.2.1"><t> <t pn="section-a.2.1-1">
Illustration of incoming label collision resolution for the same FEC The following example illustrates incoming label collision resolution for the
same FEC
type using MCC administrative distance.</t> type using MCC administrative distance.</t>
<t pn="section-a.2.1-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.1-3">
<figure><artwork><![CDATA[ Node A receives an OSPF Prefix-SID Advertisement from Node B for 198
o OSPF prefix SID advertisement from node B for 198.51.100.5/32 with .51.100.5/32 with index=5.
index=5 Assuming that OSPF SRGB on Node A = [1000,1999], the incoming label
is 1005.
o OSPF SRGB on node A = [1000,1999] </t>
<t pn="section-a.2.1-4">
o Incoming label=1005
]]></artwork>
</figure>
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.1-5">
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.105/32
with index=5. Assuming that IS-IS SRGB on Node A = [1000,1999], the incomi
ng label is 1005.
</t>
<t pn="section-a.2.1-6">
FEC1 and FEC2 both use dynamic SID assignment.
<t><list style="symbols"><t>ISIS prefix SID advertisement from node C for Since neither of the
203.0.113.105/32 FECs are of type 'SR Policy', we use the default admin distances of 50 and
with index=5</t>
<t>ISIS SRGB on node A = [1000,1999]</t>
<t>Incoming label=1005</t>
</list>
</t>
<t>
FEC1 and FEC2 both use dynamic SID assignment. Since neither ofthe
FEC types is SR Policy, we use the default admin distances of 50 and
60 to break the tie. So FEC1 wins.</t> 60 to break the tie. So FEC1 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.2" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.2.2">
<section title="Example 2" anchor="section-a.2.2"><t> <name slugifiedName="name-example-2">Example 2</name>
Illustration of incoming label collision resolution for different FEC <t pn="section-a.2.2-1">
The following example Illustrates incoming label collision resolution for dif
ferent FEC
types using the MCC administrative distance.</t> types using the MCC administrative distance.</t>
<t pn="section-a.2.2-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.2-3">
<t><list style="symbols"><t>Node A receives an OSPF prefix sid advertisem Node A receives an OSPF Prefix-SID Advertisement from Node B for
ent from node B for 198.51.100.6/32 with index=6.
198.51.100.6/32 with index=6</t> Assuming that OSPF SRGB on Node A = [1000,1999],
the incoming label on Node A corresponding to
<t>OSPF SRGB on node A = [1000,1999]</t> 198.51.100.6/32 is 1006.
</t>
<t>Hence the incoming label on node A corresponding to <t pn="section-a.2.2-4">
198.51.100.6/32 is 1006</t>
</list>
</t>
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.2-5">
<t> IS-IS on Node A assigns label 1006 to the globally significant
ISIS on node A assigns the label 1006 to the globally significant Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID
adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID sub-TLV as described in <xref target="RFC8667" format="default" sectionFormat
sub-TLV as described in <xref target="I-D.ietf-isis-segment-routing-extension ="of" derivedContent="RFC8667"/>). Hence, the incoming label corresponding
s"/>) to this Adj-SID is 1006. Assume Node A allocates this Adj-SID
towards one of its neighbors. Hence the incoming label corresponding
to this adj-SID 1006. Assume Node A allocates this adj-SID
dynamically, and it may differ across router reboots.</t> dynamically, and it may differ across router reboots.</t>
<t pn="section-a.2.2-6">
<t>
FEC1 and FEC2 both use dynamic SID assignment. Since neither of the FEC1 and FEC2 both use dynamic SID assignment. Since neither of the
FEC types is SR Policy, we use the default admin distances of 50 and FECs are of type 'SR Policy', we use the default admin distances of 50 and
60 to break the tie. So FEC1 wins.</t> 60 to break the tie. So FEC1 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.3" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.2.3">
<section title="Example 3" anchor="section-a.2.3"><t> <name slugifiedName="name-example-3">Example 3</name>
Illustration of incoming label collision resolution based on <t pn="section-a.2.3-1">
preferring static over dynamic SID assignment</t> The following example illustrates incoming label collision resolution based o
n
<t> preferring static over dynamic SID assignment.</t>
<t pn="section-a.2.3-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.2.3-3">
<t> OSPF on Node A receives a Prefix-SID Advertisement from Node B for
OSPF on node A receives a prefix SID advertisement from node B for 198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on Node A
198.51.100.7/32 with index=7. Assuming that the OSPF SRGB on node A = [1000,1999], the incoming label corresponding to 198.51.100.7/32
is [1000,1999], then incoming label corresponding to 198.51.100.7/32 is 1007.</t>
is 1007</t> <t pn="section-a.2.3-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.3-5">
<t> The operator on Node A configures IS-IS on Node A to assign label
The operator on node A configures ISIS on node A to assign the label 1007 to the globally significant Adj-SID (i.e., when advertised, the
1007 to the globally significant adj-SID (I.e. when advertised the L-Flag is clear in the Adj-SID sub-TLV as described in <xref target="RFC8667"
"L" flag is clear in the adj-SID sub-TLV as described in <xref target="I-D.ie format="default" sectionFormat="of" derivedContent="RFC8667"/>).</t>
tf-isis-segment-routing-extensions"/>) towards one of its neighbor <t pn="section-a.2.3-6">
advertisement from node A with label=1007</t> Node A assigns this Adj-SID explicitly via configuration, so the Adj-SID
survives router reboots.</t>
<t> <t pn="section-a.2.3-7">
Node A assigns this adj-SID explicitly via configuration, so the adj-
SID survives router reboots.</t>
<t>
FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
assignment. So FEC2 wins.</t> assignment. So FEC2 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.4" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.2.4">
<section title="Example 4" anchor="section-a.2.4"><t> <name slugifiedName="name-example-4">Example 4</name>
Illustration of incoming label collision resolution using FEC type <t pn="section-a.2.4-1">
default administrative distance</t> The following example illustrates incoming label collision resolution using F
EC type
<t> default administrative distance.</t>
<t pn="section-a.2.4-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.2.4-3">
<t> OSPF on Node A receives a Prefix-SID Advertisement from Node B for
OSPF on node A receives a prefix SID advertisement from node B for 198.51.100.8/32 with index=8. Assuming that OSPF SRGB on Node A =
198.51.100.8/32 with index=8. Assuming that OSPF SRGB on node A =
[1000,1999], the incoming label corresponding to 198.51.100.8/32 is [1000,1999], the incoming label corresponding to 198.51.100.8/32 is
1008.</t> 1008.</t>
<t pn="section-a.2.4-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.4-5">
<t> Suppose the SR Policy Advertisement from the controller to Node A for the
Suppose the SR Policy advertisement from controller to node A for the policy identified by (Endpoint = 192.0.2.208, color = 100) that
policy identified by (Endpoint = 192.0.2.208, color = 100) and consists of SID-List=&lt;S1, S2&gt; assigns the globally significant
consisting of SID-List = &lt;S1, S2&gt; assigns the globally significant Binding-SID label 1008.</t>
Binding-SID label 1008</t> <t pn="section-a.2.4-6">
From the point of view of Node A, FEC1 and FEC2 both use dynamic SID
<t>
From the point of view of node A, FEC1 and FEC2 both use dynamic SID
assignment. Based on the default administrative distance outlined in assignment. Based on the default administrative distance outlined in
<xref target="section-2.5.1"/>, the binding SID has a higher administrative d <xref target="convert-section-2.5.1" format="default" sectionFormat="of" deri
istance vedContent="Section 2.5.1"/>, the Binding SID has a higher administrative distan
than the prefix-SID and hence FEC1 wins.</t> ce
than the Prefix-SID; hence, FEC1 wins.</t>
</section> </section>
<section anchor="convert-section-a.2.5" numbered="true" toc="include" re
<section title="Example 5" anchor="section-a.2.5"><t> moveInRFC="false" pn="section-a.2.5">
Illustration of incoming label collision resolution based on FEC type <name slugifiedName="name-example-5">Example 5</name>
preference</t> <t pn="section-a.2.5-1">
The following example illustrates incoming label collision resolution based o
<t> n FEC type
preference.</t>
<t pn="section-a.2.5-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.2.5-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.110/32 with index=10. Assuming that the IS-IS SRGB on Node A
203.0.113.110/32 with index=10. Assuming that the ISIS SRGB on node A = [1000,1999], the incoming label corresponding to 203.0.113.110/32
is [1000,1999], then incoming label corresponding to 203.0.113.110/32
is 1010.</t> is 1010.</t>
<t pn="section-a.2.5-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.5-5">
<t> IS-IS on Node A assigns label 1010 to the globally significant
ISIS on node A assigns the label 1010 to the globally significant Adj-SID (i.e., when advertised, the L-Flag is clear in the Adj-SID
adj-SID (I.e. when advertised the "L" flag is clear in the adj-SID sub-TLV as described in <xref target="RFC8667" format="default" sectionFormat
sub-TLV as described in <xref target="I-D.ietf-isis-segment-routing-extension ="of" derivedContent="RFC8667"/>).</t>
s"/>) <t pn="section-a.2.5-6">
towards one of its neighbors).</t> Node A allocates this Adj-SID dynamically, and it may differ across
router reboots. Hence, both FEC1 and FEC2 both use dynamic SID
<t>
Node A allocates this adj-SID dynamically, and it may differ across
router reboots. Hence both FEC1 and FEC2 both use dynamic SID
assignment.</t> assignment.</t>
<t pn="section-a.2.5-7">
<t>
Since both FECs are from the same MCC, they have the same default Since both FECs are from the same MCC, they have the same default
admin distance. So we compare FEC type code-point. FEC1 has FEC type admin distance. So we compare the FEC type codepoints. FEC1 has FEC type
code-point=120, while FEC2 has FEC type code-point=130. Therefore, codepoint=120, while FEC2 has FEC type codepoint=130. Therefore,
FEC1 wins.</t> FEC1 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.6" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.2.6">
<section title="Example 6" anchor="section-a.2.6"><t> <name slugifiedName="name-example-6">Example 6</name>
Illustration of incoming label collision resolution based on address <t pn="section-a.2.6-1">
The following example illustrates incoming label collision resolution based o
n address
family preference.</t> family preference.</t>
<t pn="section-a.2.6-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.6-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives prefix SID advertisement from node B for 203.0.113.111/32 with index=11. Assuming that the IS-IS SRGB on Node A
203.0.113.111/32 with index 11. Assuming that the ISIS SRGB on node A = [1000,1999], the incoming label on Node A for 203.0.113.111/32 is
is [1000,1999], the incoming label on node A for 203.0.113.111/32 is
1011.</t> 1011.</t>
<t pn="section-a.2.6-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.6-5">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
ISIS on node A prefix SID advertisement from node C for 2001:DB8:1000::11/128 with index=11. Assuming that the IS-IS SRGB on
2001:DB8:1000::11/128 with index=11. Assuming that the ISIS SRGB on Node A = [1000,1999], the incoming label on Node A for
node A is [1000,1999], the incoming label on node A for 2001:DB8:1000::11/128 is 1011.</t>
2001:DB8:1000::11/128 is 1011</t> <t pn="section-a.2.6-6">
<t>
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
from the same MCC, they have the same default admin distance. So we from the same MCC, they have the same default admin distance. So we
compare FEC type code-point. Both FECs have FEC type code-point=120. compare the FEC type codepoints. Both FECs have FEC type codepoint=120.
So we compare address family. Since IPv4 is preferred over IPv6, FEC1 So we compare the address family. Since IPv4 is preferred over IPv6, FEC1
wins.</t> wins.</t>
</section>
</section> <section anchor="convert-section-a.2.7" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.2.7">
<section title="Example 7" anchor="section-a.2.7"><t> <name slugifiedName="name-example-7">Example 7</name>
Illustration incoming label collision resolution based on prefix <t pn="section-a.2.7-1">
The following example illustrates incoming label collision resolution based o
n prefix
length.</t> length.</t>
<t pn="section-a.2.7-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.7-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.112/32 with index=12. Assuming that IS-IS SRGB on Node A =
203.0.113.112/32 with index 12. Assuming that ISIS SRGB on node A is [1000,1999], the incoming label for 203.0.113.112/32 on Node A is
[1000,1999], the incoming label for 203.0.113.112/32 on node A is
1012.</t> 1012.</t>
<t pn="section-a.2.7-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.7-5">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.128/30 with index=12. Assuming that the IS-IS SRGB on Node A
203.0.113.128/30 with index 12. Assuming that the ISIS SRGB on node A = [1000,1999], the incoming label for 203.0.113.128/30 on Node A is
is [1000,1999], then incoming label for 203.0.113.128/30 on node A is 1012.</t>
1012</t> <t pn="section-a.2.7-6">
<t>
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
from the same MCC, they have the same default admin distance. So we from the same MCC, they have the same default admin distance. So we
compare FEC type code-point. Both FECs have FEC type code-point=120. compare the FEC type codepoints. Both FECs have FEC type codepoint=120.
So we compare address family. Both are IPv4 address family, so we So we compare the address family. Both are a part of the IPv4 address family
compare prefix length. FEC1 has prefix length=32, and FEC2 has , so we
compare the prefix length. FEC1 has prefix length=32, and FEC2 has
prefix length=30, so FEC2 wins.</t> prefix length=30, so FEC2 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.8" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.2.8">
<section title="Example 8" anchor="section-a.2.8"><t> <name slugifiedName="name-example-8">Example 8</name>
Illustration of incoming label collision resolution based on the <t pn="section-a.2.8-1">
The following example illustrates incoming label collision resolution based o
n the
numerical value of the FECs.</t> numerical value of the FECs.</t>
<t pn="section-a.2.8-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.8-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.113/32 with index=13. Assuming that IS-IS SRGB on Node A =
203.0.113.113/32 with index 13. Assuming that ISIS SRGB on node A is [1000,1999], the incoming label for 203.0.113.113/32 on Node A
[1000,1999], then the incoming label for 203.0.113.113/32 on node A is 1013.</t>
is 1013</t> <t pn="section-a.2.8-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.8-5">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.213/32 with index=13. Assuming that IS-IS SRGB on Node A =
203.0.113.213/32 with index 13. Assuming that ISIS SRGB on node A is [1000,1999], the incoming label for 203.0.113.213/32 on Node A
[1000,1999], then the incoming label for 203.0.113.213/32 on node A is 1013.</t>
is 1013</t> <t pn="section-a.2.8-6">
<t>
FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
from the same MCC, they have the same default admin distance. So we from the same MCC, they have the same default admin distance. So we
compare FEC type code-point. Both FECs have FEC type code-point=120. compare the FEC type codepoints. Both FECs have FEC type codepoint=120.
So we compare address family. Both are IPv4 address family, so we So we compare the address family. Both are a part of the IPv4 address family
compare prefix length. Prefix lengths are the same, so we compare , so we
prefix. FEC1 has the lower prefix, so FEC1 wins.</t> compare the prefix length. Prefix lengths are the same, so we compare
the prefix. FEC1 has the lower prefix, so FEC1 wins.</t>
</section> </section>
<section anchor="convert-section-a.2.9" numbered="true" toc="include" re
<section title="Example 9" anchor="section-a.2.9"><t> moveInRFC="false" pn="section-a.2.9">
Illustration of incoming label collision resolution based on routing <name slugifiedName="name-example-9">Example 9</name>
instance ID.</t> <t pn="section-a.2.9-1">
The following example illustrates incoming label collision resolution based o
<t> n the Routing
Instance ID.</t>
<t pn="section-a.2.9-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.2.9-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.114/32 with index=14. Assume that this IS-IS instance on
203.0.113.114/32 with index 14. Assume that this ISIS instance on Node A has Routing Instance ID = 1000 and SRGB = [1000,1999]. Hence,
node A has the Routing Instance ID 1000 and SRGB [1000,1999]. Hence the incoming label for 203.0.113.114/32 on Node A is 1014.</t>
the incoming label for 203.0.113.114/32 on node A is 1014</t> <t pn="section-a.2.9-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.9-5">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
ISIS on node A receives a prefix SID advertisement from node C for
203.0.113.114/32 with index=14. Assume that this is another instance 203.0.113.114/32 with index=14. Assume that this is another instance
of ISIS on node A with a different routing Instance ID 2000 but the of IS-IS on Node A but Routing Instance ID = 2000 is different and
same SRGB [1000,1999]. Hence incoming label for 203.0.113.114/32 on SRGB = [1000,1999] is the same. Hence, the incoming label for 203.0.113.114/3
node A 1014</t> 2 on
Node A is 1014.</t>
<t> <t pn="section-a.2.9-6">
These two FECs match all the way through the prefix length and These two FECs match all the way through the prefix length and
prefix. So Routing Instance ID breaks the tie, with FEC1 winning.</t> prefix. So the Routing Instance ID breaks the tie, and FEC1 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.10" numbered="true" toc="include" r
emoveInRFC="false" pn="section-a.2.10">
<section title="Example 10" anchor="section-a.2.10"><t> <name slugifiedName="name-example-10">Example 10</name>
Illustration of incoming label collision resolution based on topology <t pn="section-a.2.10-1">
The following example illustrates incoming label collision resolution based o
n the topology
ID.</t> ID.</t>
<t pn="section-a.2.10-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.10-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.115/32 with index=15. Assume that this IS-IS instance on
203.0.113.115/32 with index=15. Assume that this ISIS instance on Node A has Routing Instance ID = 1000. Assume that the prefix
node A has Routing Instance ID 1000. Assume that the prefix advertisement of 203.0.113.115/32 was received in the IS-IS Multi-topology
advertisement of 203.0.113.115/32 was received in ISIS Multi-topology advertisement with ID = 50. If the IS-IS SRGB for this routing
advertisement with ID = 50. If the ISIS SRGB for this routing instance on Node A = [1000,1999], then the incoming label of
instance on node A is [1000,1999], then incoming label of 203.0.113.115/32 for topology 50 on Node A is 1015.</t>
203.0.113.115/32 for topology 50 on node A is 1015</t> <t pn="section-a.2.10-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.10-5">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.115/32 with index=15. Assume that it has the same Routing
203.0.113.115/32 with index 15. Assume that it is the same routing Instance ID = 1000, but 203.0.113.115/32 was advertised with
Instance ID = 1000 but 203.0.113.115/32 was advertised with a IS-IS Multi-topology ID = 40, which is different. If the IS-IS SRGB on Node A
different ISIS Multi-topology ID = 40. If the ISIS SRGB on node A is =
[1000,1999], then incoming label of 203.0.113.115/32 for topology 40 [1000,1999], then the incoming label of 203.0.113.115/32 for topology 40
on node A is also 1015</t> on Node A is also 1015.</t>
<t pn="section-a.2.10-6">
<t> Since these two FECs match all the way through the prefix length, prefix,
These two FECs match all the way through the prefix length, prefix, and Routing Instance ID, we compare the IS-IS Multi-topology ID, so FEC2
and Routing Instance ID. We compare ISIS Multi-topology ID, so FEC2
wins.</t> wins.</t>
</section>
</section> <section anchor="convert-section-a.2.11" numbered="true" toc="include" r
emoveInRFC="false" pn="section-a.2.11">
<section title="Example 11" anchor="section-a.2.11"><t> <name slugifiedName="name-example-11">Example 11</name>
Illustration of incoming label collision for resolution based on <t pn="section-a.2.11-1">
algorithm ID.</t> The following example illustrates incoming label collision for resolution bas
ed on
<t> the algorithm ID.</t>
<t pn="section-a.2.11-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.2.11-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.116/32 with index=16. Assume that IS-IS on Node A has Routing
203.0.113.116/32 with index=16 Assume that ISIS on node A has Routing Instance ID = 1000. Assume that Node B advertised 203.0.113.116/32
Instance ID = 1000. Assume that node B advertised 203.0.113.116/32 with IS-IS Multi-topology ID = 50 and SR algorithm = 0. Assume that
with ISIS Multi-topology ID = 50 and SR algorithm = 0. Assume that the IS-IS SRGB on Node A = [1000,1999]. Hence, the incoming label
the ISIS SRGB on node A = [1000,1999]. Hence the incoming label
corresponding to this advertisement of 203.0.113.116/32 is 1016.</t> corresponding to this advertisement of 203.0.113.116/32 is 1016.</t>
<t pn="section-a.2.11-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.11-5">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
ISIS on node A receives a prefix SID advertisement from node C for 203.0.113.116/32 with index=16. Assume that it is the same IS-IS
203.0.113.116/32 with index=16. Assume that it is the same ISIS instance on Node A with Routing Instance ID = 1000. Also assume that
instance on node A with Routing Instance ID = 1000. Also assume that Node C advertised 203.0.113.116/32 with IS-IS Multi-topology ID = 50
node C advertised 203.0.113.116/32 with ISIS Multi-topology ID = 50
but with SR algorithm = 22. Since it is the same routing instance, but with SR algorithm = 22. Since it is the same routing instance,
the SRGB on node A = [1000,1999]. Hence the incoming label the SRGB on Node A = [1000,1999]. Hence, the incoming label
corresponding to this advertisement of 203.0.113.116/32 by node C is corresponding to this advertisement of 203.0.113.116/32 by Node C is
also 1016.</t> also 1016.</t>
<t pn="section-a.2.11-6">
<t> Since these two FECs match all the way through in terms of the prefix length,
These two FECs match all the way through the prefix length, prefix, prefix,
and Routing Instance ID, and Multi-topology ID. We compare SR Routing Instance ID, and Multi-topology ID, we compare the SR
algorithm ID, so FEC1 wins.</t> algorithm IDs, so FEC1 wins.</t>
</section>
</section> <section anchor="convert-section-a.2.12" numbered="true" toc="include" r
emoveInRFC="false" pn="section-a.2.12">
<section title="Example 12" anchor="section-a.2.12"><t> <name slugifiedName="name-example-12">Example 12</name>
Illustration of incoming label collision resolution based on FEC <t pn="section-a.2.12-1">
numerical value and independent of how the SID assigned to the The following example illustrates incoming label collision resolution based o
n the FEC
numerical value, independent of how the SID is assigned to the
colliding FECs.</t> colliding FECs.</t>
<t pn="section-a.2.12-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.12-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.117/32 with index=17. Assume that the IS-IS SRGB on Node A
203.0.113.117/32 with index 17. Assume that the ISIS SRGB on node A = [1000,1999]; thus, the incoming label is 1017.</t>
is [1000,1999], then the incoming label is 1017</t> <t pn="section-a.2.12-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.12-5">
<t> Suppose there is an IS-IS Mapping Server Advertisement (SID / Label
Suppose there is an ISIS mapping server advertisement (SID/Label Binding TLV) from Node D that has range = 100 and prefix = 203.0.113.1/32.
Binding TLV) from node D has Range 100 and Prefix = 203.0.113.1/32. Suppose this Mapping Server Advertisement generates 100 mappings, one
Suppose this mapping server advertisement generates 100 mappings, one of which maps 203.0.113.17/32 to index=17.
of which maps 203.0.113.17/32 to index 17. Assuming that it is the Assuming that it is the
same ISIS instance, then the SRGB is [1000,1999] and hence the same IS-IS instance, the SRGB = [1000,1999] and hence the
incoming label for 1017.</t> incoming label for 1017.</t>
<t pn="section-a.2.12-6">
<t> Even though FEC1 comes from a normal Prefix-SID Advertisement and
The fact that FEC1 comes from a normal prefix SID advertisement and FEC2 is generated from a Mapping Server Advertisement, it is not used as
FEC2 is generated from a mapping server advertisement is not used as a tiebreaking parameter. Both FECs use dynamic SID assignment, are
a tie-breaking parameter. Both FECs use dynamic SID assignment, are from the same MCC, and have the same FEC type codepoint=120. Their
from the same MCC, have the same FEC type code-point=120. Their prefix lengths are the same as well. FEC2 wins based on its lower
prefix lengths are the same as well. FEC2 wins based on lower
numerical prefix value, since 203.0.113.17 is less than numerical prefix value, since 203.0.113.17 is less than
203.0.113.117.</t> 203.0.113.117.</t>
</section>
</section> <section anchor="convert-section-a.2.13" numbered="true" toc="include" r
emoveInRFC="false" pn="section-a.2.13">
<section title="Example 13" anchor="section-a.2.13"><t> <name slugifiedName="name-example-13">Example 13</name>
Illustration of incoming label collision resolution based on address <t pn="section-a.2.13-1">
family preference</t> The following example illustrates incoming label collision resolution based o
n address
<t> family preference.</t>
<t pn="section-a.2.13-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.2.13-3">
<t> SR Policy Advertisement from the controller to Node A. Endpoint
SR Policy advertisement from controller to node A. Endpoint address=2001:DB8:3000::100, color=100, SID-List=&lt;S1, S2&gt;, and the
address=2001:DB8:3000::100, color=100, SID-List=&lt;S1, S2&gt; and the Binding-SID label=1020.</t>
Binding-SID label=1020</t> <t pn="section-a.2.13-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.13-5">
<figure><artwork><![CDATA[ SR Policy Advertisement from controller to Node A. Endpoint
SR Policy advertisement from controller to node A. Endpoint address=192.0.2.60, color=100, SID-List=&lt;S3, S4&gt;, and the Binding-SID
address=192.0.2.60, color=100, SID-List=<S3, S4> and the Binding-SID label=1020.</t>
label=1020 <t pn="section-a.2.13-6">The FEC tiebreakers match, and they have the
The FECs match through the tie-breaks up to and including having the same FEC type codepoint=140. Thus, FEC2 wins based on the IPv4 address family
same FEC type code-point=140. FEC2 wins based on IPv4 address family being preferred over IPv6.</t>
being preferred over IPv6. </section>
]]></artwork> <section anchor="convert-section-a.2.14" numbered="true" toc="include" r
</figure> emoveInRFC="false" pn="section-a.2.14">
</section> <name slugifiedName="name-example-14">Example 14</name>
<t pn="section-a.2.14-1">
<section title="Example 14" anchor="section-a.2.14"><t> The following example illustrates incoming label resolution based on the nume
Illustration of incoming label resolution based on numerical value of rical value of
the policy endpoint.</t> the policy endpoint.</t>
<t pn="section-a.2.14-2">
<t>
FEC1:</t> FEC1:</t>
<t pn="section-a.2.14-3">
<t> SR Policy Advertisement from the controller to Node A. Endpoint
SR Policy advertisement from controller to node A. Endpoint address=192.0.2.70, color=100, SID-List=&lt;S1, S2&gt;, and Binding-SID
address=192.0.2.70, color=100, SID-List=&lt;S1, S2&gt; and Binding-SID label=1021.</t>
label=1021</t> <t pn="section-a.2.14-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.2.14-5">
<t> SR Policy Advertisement from the controller to Node A. Endpoint
SR Policy advertisement from controller to node A Endpoint address=192.0.2.71, color=100, SID-List=&lt;S3, S4&gt;, and Binding-SID
address=192.0.2.71, color=100, SID-List=&lt;S3, S4&gt; and Binding-SID label=1021.</t>
label=1021</t> <t pn="section-a.2.14-6">
The FEC tiebreakers match, and they have the
<t> same address family. Thus, FEC1 wins by having the lower numerical endpoint
The FECs match through the tie-breaks up to and including having the
same address family. FEC1 wins by having the lower numerical endpoint
address value.</t> address value.</t>
</section>
</section> </section>
<section anchor="convert-section-a.3" numbered="true" toc="include" remove
</section> InRFC="false" pn="section-a.3">
<name slugifiedName="name-examples-for-the-effect-of-">Examples for the
<section title="Examples for the Effect of Incoming Label Collision on Ou Effect of Incoming Label Collision on an Outgoing Label</name>
tgoing Label" anchor="section-a.3"><t> <t pn="section-a.3-1">
This section presents examples to illustrate the effect of incoming This section presents examples to illustrate the effect of incoming
label collision on the selection of the outgoing label described in label collision on the selection of the outgoing label as described in
<xref target="section-2.6"/>.</t> <xref target="convert-section-2.6" format="default" sectionFormat="of" derive
dContent="Section 2.6"/>.</t>
<section title="Example 1" anchor="section-a.3.1"><t> <section anchor="convert-section-a.3.1" numbered="true" toc="include" re
Illustration of the effect of incoming label resolution on the moveInRFC="false" pn="section-a.3.1">
outgoing label</t> <name slugifiedName="name-example-1-2">Example 1</name>
<t pn="section-a.3.1-1">
<t> The following example illustrates the effect of incoming label resolution on
the
outgoing label.</t>
<t pn="section-a.3.1-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.3.1-3">
<t> IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
ISIS on node A receives a prefix SID advertisement from node B for 203.0.113.122/32 with index=22. Assuming that the IS-IS SRGB on Node A
203.0.113.122/32 with index 22. Assuming that the ISIS SRGB on node A = [1000,1999], the corresponding incoming label is 1022.</t>
is [1000,1999] the corresponding incoming label is 1022.</t> <t pn="section-a.3.1-4">
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.3.1-5">
IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
203.0.113.222/32 with index=22. Assuming that the IS-IS SRGB on Node A
= [1000,1999], the corresponding incoming label is 1022.</t>
<t pn="section-a.3.1-6">
<t> FEC1 wins based on the lowest numerical prefix value. This means that
ISIS on node A receives a prefix SID advertisement from node C for Node A installs a transit MPLS forwarding entry to swap incoming
203.0.113.222/32 with index=22 Assuming that the ISIS SRGB on node A label 1022 with outgoing label N and to use outgoing interface I. N is
is [1000,1999] the corresponding incoming label is 1022.</t> determined by the index associated with FEC1 (index=22) and the SRGB
<t>
FEC1 wins based on lowest numerical prefix value. This means that
node A installs a transit MPLS forwarding entry to SWAP incoming
label 1022, with outgoing label N and use outgoing interface I. N is
determined by the index associated with FEC1 (index 22) and the SRGB
advertised by the next-hop node on the shortest path to reach advertised by the next-hop node on the shortest path to reach
203.0.113.122/32.</t> 203.0.113.122/32.</t>
<t pn="section-a.3.1-7">
<t>
Node A will generally also install an imposition MPLS forwarding Node A will generally also install an imposition MPLS forwarding
entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 entry corresponding to FEC1 for incoming prefix=203.0.113.122/32
pushing outgoing label N, and using outgoing interface I.</t> pushing outgoing label N, and using outgoing interface I.</t>
<t pn="section-a.3.1-8">
<t> The rule in <xref target="convert-section-2.6" format="default" sectionFormat
The rule in <xref target="section-2.6"/> means node A MUST NOT install an ing ="of" derivedContent="Section 2.6"/> means Node A <bcp14>MUST NOT</bcp14> instal
ress l an ingress
MPLS forwarding entry corresponding to FEC2 (the losing FEC, which MPLS forwarding entry corresponding to FEC2 (the losing FEC, which
would be for prefix 203.0.113.222/32).</t> would be for prefix 203.0.113.222/32).</t>
</section>
</section> <section anchor="convert-section-a.3.2" numbered="true" toc="include" re
moveInRFC="false" pn="section-a.3.2">
<section title="Example 2" anchor="section-a.3.2"><t> <name slugifiedName="name-example-2-2">Example 2</name>
Illustration of the effect of incoming label collision resolution on <t pn="section-a.3.2-1">
outgoing label programming on node A</t> The following example illustrates the effect of incoming label collision reso
lution on
<t> outgoing label programming on Node A.</t>
<t pn="section-a.3.2-2">
FEC1:</t> FEC1:</t>
<t pn="section-a.3.2-3">SR Policy Advertisement from the controller to
<t><list style="symbols"><t>SR Policy advertisement from controller to no Node A.
de A</t> Endpoint address=192.0.2.80, color=100, SID-List=&lt;S1, S2&gt;, and
Binding-SID label=1023.
<t>Endpoint address=192.0.2.80, color=100, SID-List=&lt;S1, S2&gt;</t> </t>
<t pn="section-a.3.2-4">
<t>Binding-SID label=1023</t>
</list>
</t>
<t>
FEC2:</t> FEC2:</t>
<t pn="section-a.3.2-5">
<t><list style="symbols"><t>SR Policy advertisement from controller to no SR Policy Advertisement from controller to Node A.
de A</t> Endpoint address=192.0.2.81, color=100, SID-List=&lt;S3, S4&gt;, and
Binding-SID label=1023.
<t>Endpoint address=192.0.2.81, color=100, SID-List=&lt;S3, S4&gt;</t> </t>
<t pn="section-a.3.2-6">
<t>Binding-SID label=1023</t>
</list>
</t>
<t>
FEC1 wins by having the lower numerical endpoint address value. This FEC1 wins by having the lower numerical endpoint address value. This
means that node A installs a transit MPLS forwarding entry to SWAP means that Node A installs a transit MPLS forwarding entry to swap
incoming label=1023, with outgoing labels and outgoing interface incoming label=1023 with outgoing labels, and the outgoing interface
determined by the SID-List for FEC1.</t> is determined by the SID-List for FEC1.</t>
<t pn="section-a.3.2-7">
<t> In this example, we assume that Node A receives two BGP/VPN routes:</t>
In this example, we assume that node A receives two BGP/VPN routes:</t> <ul spacing="normal" bare="false" empty="false" pn="section-a.3.2-8">
<li pn="section-a.3.2-8.1">R1 with VPN label=V1, BGP next hop = 192.
<t><list style="symbols"><t>R1 with VPN label=V1, BGP next-hop = 192.0.2. 0.2.80, and color=100</li>
80, and color=100,</t> <li pn="section-a.3.2-8.2">R2 with VPN label=V2, BGP next hop = 192.
0.2.81, and color=100</li>
<t>R2 with VPN label=V2, BGP next-hop = 192.0.2.81, and color=100,</t> </ul>
<t pn="section-a.3.2-9">
</list> We also assume that Node A has a BGP policy that matches color=100
</t> and allows its usage as Service Level Agreement (SLA) steering information. I
n this case,
<t> Node A will install a VPN route with label stack = &lt;S1,S2,V1&gt;
We also assume that A has a BGP policy which matches on color=100
that allows that its usage as SLA steering information. In this case,
node A will install a VPN route with label stack = &lt;S1,S2,V1&gt;
(corresponding to FEC1).</t> (corresponding to FEC1).</t>
<t pn="section-a.3.2-10">
<t> The rule described in <xref target="convert-section-2.6" format="default" sec
The rule described in section 2.6 means that node A MUST NOT install tionFormat="of" derivedContent="Section 2.6"/> means that Node A <bcp14>MUST NOT
</bcp14> install
a VPN route with label stack = &lt;S3,S4,V1&gt; (corresponding to FEC2.)</t> a VPN route with label stack = &lt;S3,S4,V1&gt; (corresponding to FEC2.)</t>
</section>
</section> </section>
</section>
</section> <section anchor="convert-section-7" numbered="false" toc="include" removeInR
FC="false" pn="section-appendix.b">
</section> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.b-1">
</back> The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu
Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren
</rfc> Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on
this document.</t>
</section>
<section anchor="convert-section-6" numbered="false" toc="include" removeInR
FC="false" pn="section-appendix.c">
<name slugifiedName="name-contributors">Contributors</name>
<t pn="section-appendix.c-1">
The following contributors have substantially helped the definition
and editing of the content of this document:</t>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-2">
Martin Horneffer
Deutsche Telekom
Email: Martin.Horneffer@telekom.de</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-3">
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-4">
Jeff Tantsura
Email: jefftant@gmail.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-5">
Edward Crabbe
Email: edward.crabbe@gmail.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-6">
Igor Milojevic
Email: milojevicigor@gmail.com</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-7">
Saku Ytti
Email: saku@ytti.fi</artwork>
</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">Arrcus</organization>
<address>
<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">Cisco Systems, Inc.</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>
<author fullname="Rob Shakir" initials="R." surname="Shakir">
<organization showOnFrontPage="true">Google</organization>
<address>
<postal>
<street>United States of America</street>
</postal>
<email>robjs@google.com</email>
</address>
</author>
</section>
</back>
</rfc>
 End of changes. 202 change blocks. 
1593 lines changed or deleted 2597 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/