<?xmlversion="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC8402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"> <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3031 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"> <!ENTITY RFC3032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"> <!ENTITY RFC3443 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3443.xml"> <!ENTITY RFC5462 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"> <!ENTITY RFC7274 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7274.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY I-D.ietf-isis-segment-routing-extensions SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-isis-segment-routing-extensions-13.xml"> <!ENTITY I-D.ietf-ospf-ospfv3-segment-routing-extensions SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-ospfv3-segment-routing-extensions-09.xml"> <!ENTITY I-D.ietf-ospf-segment-routing-extensions SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-segment-routing-extensions-16.xml"> <!ENTITY I-D.ietf-spring-segment-routing-ldp-interop SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-ldp-interop-08.xml"> <!ENTITY I-D.bashandy-rtgwg-segment-routing-ti-lfa SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bashandy-rtgwg-segment-routing-ti-lfa.xml"> <!ENTITY RFC7855 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"> <!ENTITY RFC5036 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"> <!ENTITY RFC5331 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5331.xml"> <!ENTITY RFC7510 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml"> <!ENTITY RFC4817 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4817.xml"> <!ENTITY RFC8287 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8287.xml"> <!ENTITY RFC8403 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8403.xml"> <!ENTITY I-D.ietf-spring-segment-routing-policy SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-policy.xml"> ]>version='1.0' encoding='utf-8'?> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-spring-segment-routing-mpls-22"category="std"> <!-- Generated by id2xml 1.4.4 on 2019-06-12T17:23:43Z --> <?rfc compact="yes"?> <?rfc text-list-symbols="o-*+-"?> <?rfc subcompact="no"?> <?rfc sortrefs="no"?> <?rfc symrefs="yes"?> <?rfc strict="yes"?> <?rfc toc="yes"?>indexInclude="true" ipr="trust200902" number="8660" prepTime="2019-12-04T22:57:35" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls-22" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8660" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title>Segment Routing with the MPLSdata plane</title>Data Plane</title> <seriesInfo name="RFC" value="8660" stream="IETF"/> <author fullname="Ahmed Bashandy" initials="A." role="editor" surname="Bashandy"><organization>Arrcus</organization> <address><email>abashandy.ietf@gmail.com</email><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>Cisco<organization showOnFrontPage="true">Cisco Systems, Inc.</organization><address><postal><street>Brussels</street> <street>BE</street><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>Cisco<organization showOnFrontPage="true">Cisco Systems, Inc.</organization><address><postal><street>Italy</street><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><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>Orange</organization> <address><postal><street>FR</street><organization showOnFrontPage="true">Orange</organization> <address> <postal> <street>France</street> </postal><email>stephane.litkowski@orange.com</email><email>slitkows.ietf@gmail.com</email> </address> </author> <author fullname="Rob Shakir" initials="R." surname="Shakir"><organization>Google</organization> <address><postal><street>US</street><organization showOnFrontPage="true">Google</organization> <address> <postal> <street>United States of America</street> </postal> <email>robjs@google.com</email> </address> </author> <dateday="1" month="May"month="12" year="2019"/><abstract><t><abstract pn="section-abstract"> <t pn="section-abstract-1"> Segment Routing (SR) leverages thesource routingsource-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLSdataplane,data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLSdataplane.</t>data plane (SR-MPLS).</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8660" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.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 derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>. <xref 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 derivedContent="" format="title" sectionFormat="of" target="name-mpls-instantiation-of-segme">MPLS Instantiation of Segment Routing</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-multiple-forwarding-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 derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sid-representation-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 derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-segment-routing-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 derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>. <xref 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 derivedContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-incoming-label-collision">Incoming Label Collision</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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"><xref derivedContent="2.5.1" format="counter" sectionFormat="of" target="section-2.5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-tiebreaking-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"><xref derivedContent="2.5.2" format="counter" sectionFormat="of" target="section-2.5.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-redistribution-between-rout">Redistribution between Routing Protocol Instances</xref></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 derivedContent="2.6" format="counter" sectionFormat="of" target="section-2.6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-effect-of-incoming-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 derivedContent="2.7" format="counter" sectionFormat="of" target="section-2.7"/>. <xref 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="section-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"><xref derivedContent="2.7.1" format="counter" sectionFormat="of" target="section-2.7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-push">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"><xref derivedContent="2.7.2" format="counter" sectionFormat="of" target="section-2.7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-continue">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"><xref derivedContent="2.7.3" format="counter" sectionFormat="of" target="section-2.7.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-next">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 derivedContent="2.8" format="counter" sectionFormat="of" target="section-2.8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-mpls-label-downloaded-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 derivedContent="2.9" format="counter" sectionFormat="of" target="section-2.9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-active-segment">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 derivedContent="2.10" format="counter" sectionFormat="of" target="section-2.10"/>. <xref 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="section-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"><xref derivedContent="2.10.1" format="counter" sectionFormat="of" target="section-2.10.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="2.10.2" format="counter" sectionFormat="of" target="section-2.10.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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 derivedContent="2.11" format="counter" sectionFormat="of" target="section-2.11"/>. <xref 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="section-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"><xref derivedContent="2.11.1" format="counter" sectionFormat="of" target="section-2.11.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="2.11.2" format="counter" sectionFormat="of" target="section-2.11.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-for-the-continue">Forwarding for the CONTINUE Operation for Local SIDs</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"><xref derivedContent="2.11.3" format="counter" sectionFormat="of" target="section-2.11.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-outgoing-label-for-the-next">Outgoing Label for the NEXT Operation for Local SIDs</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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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-examples">Examples</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-igp-segment-examples">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 derivedContent="A.2" format="counter" sectionFormat="of" target="section-a.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-incoming-label-collision-ex">Incoming Label Collision Examples</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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"><xref derivedContent="A.2.1" format="counter" sectionFormat="of" target="section-a.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.2" format="counter" sectionFormat="of" target="section-a.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.3" format="counter" sectionFormat="of" target="section-a.2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.4" format="counter" sectionFormat="of" target="section-a.2.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.5" format="counter" sectionFormat="of" target="section-a.2.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.6" format="counter" sectionFormat="of" target="section-a.2.6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.7" format="counter" sectionFormat="of" target="section-a.2.7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.8" format="counter" sectionFormat="of" target="section-a.2.8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.2.9" format="counter" sectionFormat="of" target="section-a.2.9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref 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"><xref 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"><xref 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"><xref 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"><xref 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 derivedContent="A.3" format="counter" sectionFormat="of" target="section-a.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-examples-for-the-effect-of-">Examples for the Effect of Incoming Label Collision on an Outgoing Label</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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"><xref derivedContent="A.3.1" format="counter" sectionFormat="of" target="section-a.3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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"><xref derivedContent="A.3.2" format="counter" sectionFormat="of" target="section-a.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-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 derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</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 derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t> </li> <li pn="section-toc.1-1.10"> <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <sectiontitle="Introduction" anchor="section-1"><t>anchor="convert-section-1" numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1"> The Segment Routing architectureRFC8402<xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> can be directly applied to the MPLS architecture with no change in the MPLS forwarding plane. This document specifiesthe forwarding planeforwarding-plane behavior to allow Segment Routing to operate on top of the MPLS dataplane.plane (SR-MPLS). This document does not addressthe control planecontrol-plane behavior.Control planeControl-plane behavior is specified in other documents such as <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>, <xref target="I-D.ietf-ospf-segment-routing-extensions"/>, and <xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> <t>target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>.</t> <t pn="section-1-2"> The Segment Routing problem statement is described in <xreftarget="RFC7855"/>.</t> <t> Co-existencetarget="RFC7855" format="default" sectionFormat="of" derivedContent="RFC7855"/>.</t> <t pn="section-1-3"> Coexistence of SR over the MPLS forwarding plane with LDP <xreftarget="RFC5036"/>target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/> is specified in <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t> <t>target="RFC8661" format="default" sectionFormat="of" derivedContent="RFC8661"/>.</t> <t pn="section-1-4"> Policy routing and traffic engineering usingsegment routingSegment Routing can be found in <xreftarget="I-D.ietf-spring-segment-routing-policy"/></t> <section title="Requirements Language" anchor="section-1.1"><t>target="ROUTING-POLICY" format="default" sectionFormat="of" derivedContent="ROUTING-POLICY"/>.</t> <section anchor="convert-section-1.1" numbered="true" toc="include" removeInRFC="false" pn="section-1.1"> <name slugifiedName="name-requirements-language">Requirements Language</name> <t pn="section-1.1-1"> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"/> <xref target="RFC8174"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> </section> <sectiontitle="MPLSanchor="convert-section-2" numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-mpls-instantiation-of-segme">MPLS Instantiation of SegmentRouting" anchor="section-2"><t>Routing</name> <t pn="section-2-1"> MPLS instantiation of Segment Routing fits in the MPLS architecture as defined in <xreftarget="RFC3031"/> bothtarget="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> from both acontrol planecontrol-plane andforwarding planeforwarding-plane perspective:</t><t><list style="symbols"><t>From<ul spacing="normal" bare="false" empty="false" pn="section-2-2"> <li pn="section-2-2.1">From acontrol planecontrol-plane perspective, <xreftarget="RFC3031"/>target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> does not mandate a single signaling protocol. Segment Routing makes use of variouscontrol planecontrol-plane protocols such aslink statelink-state IGPs <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>, <xref target="I-D.ietf-ospf-segment-routing-extensions"/> and <xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/> <xref target="RFC8666" format="default" sectionFormat="of" derivedContent="RFC8666"/> <xref target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>. The flooding mechanisms oflink statelink-state IGPs fit very well with label stacking on the ingress.Future control layerA future control-layer protocol and/or policy/configuration can be used to specify the labelstack.</t> <t>Fromstack.</li> <li pn="section-2-2.2">From aforwarding planeforwarding-plane perspective, Segment Routing does not require any change to the forwarding plane because Segment IDs (SIDs) are instantiated as MPLSlabelslabels, and the SegmentroutingRouting header is instantiated as a stack of MPLSlabels.</t> </list> </t> <t>labels.</li> </ul> <t pn="section-2-3"> We call the "MPLS Control Plane Client (MCC)" anycontrol planecontrol-plane entity installing forwarding entries in the MPLS data plane. Local configuration and policies applied on a router are examples of MCCs.</t><t><t pn="section-2-4"> In order to have a node segment reach the node, a network operatorSHOULD<bcp14>SHOULD</bcp14> configure at least one node segment per routing instance, topology, or algorithm. Otherwise, the node is not reachable within the routing instance,topologywithin the topology, or along the routing algorithm, whichrestrictrestricts its ability to be used byaan SRpolicy, including for TI-LFA.</t> <section title="MultiplePolicy and as a Topology Independent Loop-Free Alternate (TI-LFA).</t> <section anchor="convert-section-2.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.1"> <name slugifiedName="name-multiple-forwarding-behavio">Multiple Forwarding Behaviors for the SamePrefix" anchor="section-2.1"><t>Prefix</name> <t pn="section-2.1-1"> The SR architecture does not prohibit having more than one SID for the same prefix. In fact, by allowing multiple SIDs for the same prefix, it is possible to have different forwarding behaviors (such as different paths, differentECMP/UCMP behaviors,...,etc)ECMP and Unequal-Cost Multipath (UCMP) behaviors, etc.) for the same destination.</t><t><t pn="section-2.1-2"> Instantiating SegmentroutingRouting over the MPLS forwarding plane fits seamlessly with this principle. An operator may assign multiple MPLS labels or indices to the same prefix and assign different forwarding behaviors to each label/SID. The MCC in the network downloads 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 the domain can choose to apply a particular forwarding behavior to a particular packet by applying the PUSH action to that packet using the corresponding SID.</t> </section> <sectiontitle="SIDanchor="convert-section-2.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.2"> <name slugifiedName="name-sid-representation-in-the-m">SID Representation in the MPLS ForwardingPlane" anchor="section-2.2"><t>Plane</name> <t pn="section-2.2-1"> When instantiating SR over the MPLS forwarding plane, a SID is represented by an MPLS label or an index <xreftarget="RFC8402"/>.</t> <t>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t> <t pn="section-2.2-2"> A globalsegmentSID is a label, or an indexwhichthat may be mapped to an MPLS label within the Segment Routing Global Block(SRGB)(SRGB), of the nodeinstalling thethat installs a globalsegmentSID in itsFIB/receivingFIB and receives the labeled packet. <xreftarget="section-2.4"/>target="convert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2.4"/> specifies the procedure to map a global segment represented by an index to an MPLS label within the SRGB.</t><t><t pn="section-2.2-3"> The MCCMUST<bcp14>MUST</bcp14> ensure that any label value corresponding to any SID it installs in the forwarding plane follows thefollowing rules:</t> <t><list style="symbols"><t>Therules below:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.2-4"> <li pn="section-2.2-4.1">The label valueMUST<bcp14>MUST</bcp14> be unique within the router on which the MCC isrunning. i.e.running, i.e., the labelMUST<bcp14>MUST</bcp14> only be used to represent the SID andMUST NOT<bcp14>MUST NOT</bcp14> be used to represent more than one SID or for any other forwarding purpose on therouter.</t> <t>Therouter.</li> <li pn="section-2.2-4.2">The label valueMUST NOT<bcp14>MUST NOT</bcp14> come from the range ofspecial purposespecial-purpose labels <xreftarget="RFC7274"/>.</t> </list> </t> <t>target="RFC7274" format="default" sectionFormat="of" derivedContent="RFC7274"/>.</li> </ul> <t pn="section-2.2-5"> Labels allocated in this document are consideredper platform down- streamper-platform downstream allocated labels <xreftarget="RFC3031"/>.</t>target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>.</t> </section> <sectiontitle="Segmentanchor="convert-section-2.3" numbered="true" toc="include" removeInRFC="false" pn="section-2.3"> <name slugifiedName="name-segment-routing-global-bloc">Segment Routing Global Block and LocalBlock" anchor="section-2.3"><t>Block</name> <t pn="section-2.3-1"> The concepts ofSegment Routing Global Block (SRGB)SRGB and global SID are explained in <xreftarget="RFC8402"/>.target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>. In general, the SRGB need not be a contiguous range of labels.</t><figure><artwork><![CDATA[<t pn="section-2.3-2"> For the rest of this document, the SRGB is specified by the list of MPLSLabellabel ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] where Ll(i)=<=< Lh(i).]]></artwork> </figure> <t></t> <t pn="section-2.3-3"> The following rules apply to the list of MPLS ranges representing theSRGB</t> <t><list style="symbols"><t>TheSRGB:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.3-4"> <li pn="section-2.3-4.1">The list of ranges comprising the SRGBMUST NOT overlap.</t> <t>Every<bcp14>MUST NOT</bcp14> overlap.</li> <li pn="section-2.3-4.2">Every range in the list of ranges specifying the SRGBMUST NOT<bcp14>MUST NOT</bcp14> cover or overlap with a reserved label value or range <xreftarget="RFC7274"/>, respectively.</t> <t>Iftarget="RFC7274" format="default" sectionFormat="of" derivedContent="RFC7274"/>, respectively.</li> <li pn="section-2.3-4.3">If the SRGB of a node does not conform to the structure specified in this section or to the previous two rules,then thisthe SRGBMUST<bcp14>MUST</bcp14> be completely ignored by all routers in the routingdomaindomain, and the nodeMUST<bcp14>MUST</bcp14> be treated as if it does not have anSRGB.</t> <t>TheSRGB.</li> <li pn="section-2.3-4.4">The list of label rangesMUST<bcp14>MUST</bcp14> only be used to instantiate global SIDs into the MPLS forwardingplane</t> </list> </t> <t>plane.</li> </ul> <t pn="section-2.3-5"> ALocallocal segmentMAY<bcp14>MAY</bcp14> be allocated from the Segment Routing Local Block (SRLB) <xreftarget="RFC8402"/>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> or from any unused label as long as it does not use aspecial purposespecial-purpose label. The SRLB consists of the range of local labels reserved by the node for certain local segments. In a controller-driven network, some controllers or applicationsMAY<bcp14>MAY</bcp14> use the control plane to discover the available set oflocalLocal SIDs on a particular router <xreftarget="I-D.ietf-spring-segment-routing-policy"/>.target="ROUTING-POLICY" format="default" sectionFormat="of" derivedContent="ROUTING-POLICY"/>. The rules applicable to the SRGB are also applicable to the SRLB, except therule that says that theSRGBMUST<bcp14>MUST</bcp14> only be used to instantiate global SIDs into the MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB and/or SRLB is a matter of futurestudy</t>study.</t> </section> <sectiontitle="Mappinganchor="convert-section-2.4" numbered="true" toc="include" removeInRFC="false" pn="section-2.4"> <name slugifiedName="name-mapping-a-sid-index-to-an-m">Mapping a SID Index to an MPLSlabel" anchor="section-2.4"><t>Label</name> <t pn="section-2.4-1"> Thissub-sectionsubsection specifies how the MPLS label value is calculated given the index of a SID. The value of the index is determined by an MCC such as IS-IS <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> or OSPF <xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>. This section only 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 both.</t><t><t pn="section-2.4-2"> Consider a SID represented by the index "I". Consider an SRGB as specified in <xreftarget="section-2.3"/>.target="convert-section-2.3" format="default" sectionFormat="of" derivedContent="Section 2.3"/>. The total size of the SRGB, represented by the variable "Size", is calculated according to the formula:</t><figure><artwork><![CDATA[<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> </figure> <t>1</artwork> <t pn="section-2.4-4"> The following rulesMUST<bcp14>MUST</bcp14> be applied by the MCC when calculating the MPLS label value corresponding to the SID index value "I".</t><t> <list style="symbols"> <t>0<ul spacing="normal" empty="true" bare="false" pn="section-2.4-5"> <li pn="section-2.4-5.1">0 =< I < size. Iftheindex "I" does not satisfy the previous inequality, then the label cannot becalculated.</t> <t>Thecalculated.</li> <li pn="section-2.4-5.2"> <t pn="section-2.4-5.2.1">The label value corresponding to the SID index "I" is calculated asfollows <list style="symbols"> <t>jfollows: </t> <ul spacing="normal" empty="true" bare="false" pn="section-2.4-5.2.2"> <li pn="section-2.4-5.2.2.1">j = 1 , temp =0</t> <t>While0</li> <li pn="section-2.4-5.2.2.2"> <t pn="section-2.4-5.2.2.2.1">While temp + Lh(j)- Ll(j) < I<list style="symbols"> <t>temp</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</t> <t>j1</li> <li pn="section-2.4-5.2.2.2.2.2">j =j+1</t> </list></t> <t>labelj+1</li> </ul> </li> <li pn="section-2.4-5.2.2.3">label = I - temp +Ll(j)</t> </list> </t> </list> </t> <t>Ll(j)</li> </ul> </li> </ul> <t pn="section-2.4-6"> An example for how a router calculates labels and forwards traffic based on the procedure described in this section can be found inAppendix A.1.</t><xref target="convert-section-a.1" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>.</t> </section> <sectiontitle="Incominganchor="convert-section-2.5" numbered="true" toc="include" removeInRFC="false" pn="section-2.5"> <name slugifiedName="name-incoming-label-collision">Incoming LabelCollision" anchor="section-2.5"><t>Collision</name> <t pn="section-2.5-1"> The MPLS Architecture <xreftarget="RFC3031"/>target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> defines the term Forwarding Equivalence Class (FEC) as the set of packets with similarand / orand/or identical characteristicswhichthat are forwarded the same way and are bound to the same MPLS incoming (local) label. InSegment-RoutingSegment Routing MPLS, a local label serves as the SID for a given FEC.</t><t><t pn="section-2.5-2"> We defineSegment Routing (SR)SR FEC <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> as one of thefollowing <xref target="RFC8402"/>:</t> <t><list style="symbols"><t>(Prefix,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,AlgorithmAlgorithm) <xreftarget="RFC8402"/>),target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, where a topology identifies a set of links with metrics. For the purpose of incoming label collision resolution, the same Topology numerical valueSHOULD<bcp14>SHOULD</bcp14> be used on all routers to identify the same set of links with metrics. For MCCs where the "Topology" and/or "Algorithm" fields are not defined, the numerical value of zeroMUST<bcp14>MUST</bcp14> be used for these two fields. For the purpose of incoming label collision resolution, a routing instance is identified by a single incoming label downloader to the FIB. Two MCCs running on the same router are considered different routing instances if the only way the two instancescanknow abouttheeach other's incoming labels is through redistribution. The numerical value used to identify a routing instanceMAY<bcp14>MAY</bcp14> be derived from other configuration orMAY<bcp14>MAY</bcp14> be explicitly configured. If it is derived from other configuration, then the same numerical valueSHOULD<bcp14>SHOULD</bcp14> be derived from the same configuration as long as the configuration survives router reload. If the derived numerical value varies for the same configuration, then an implementationSHOULD<bcp14>SHOULD</bcp14> make the numerical value used to identify a routing instanceconfigurable.</t> <t>(next-hop,configurable.</li> <li pn="section-2.5-3.2">(next hop, outgoing interface), where the outgoing interface is physical orvirtual.</t> <t>(numbervirtual.</li> <li pn="section-2.5-3.3">(number of adjacencies, list ofnext-hops,next hops, list of outgoing interfaces IDs in ascending numerical order). This FEC represents parallel adjacencies <xreftarget="RFC8402"/></t> <t>(Endpoint, Color) representingtarget="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</li> <li pn="section-2.5-3.4">(Endpoint, Color). This FEC represents an SRpolicyPolicy <xreftarget="RFC8402"/></t> <t>(Mirrored SID)target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</li> <li pn="section-2.5-3.5">(Mirror SID). TheMirroredMirror SID[RFC8402, Section 5.1](see <xref target="RFC8402" sectionFormat="comma" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-5.1" derivedContent="RFC8402"/>) is the IP address advertised by the advertising node to identify themirror-Mirror SID. The IP address is encoded as specified in <xreftarget="section-2.5.1"/>.</t> </list> </t> <t>target="convert-section-2.5.1" format="default" sectionFormat="of" derivedContent="Section 2.5.1"/>.</li> </ul> <t pn="section-2.5-4"> This section covers theRECOMMENDED<bcp14>RECOMMENDED</bcp14> procedureto handlefor handling the scenario where, because of an error/misconfiguration, more than one SR FEC as defined in thissection, mapsection maps to the same incoming MPLS label. Examples illustrating the behavior specified in this section can be found inAppendix A.2.</t> <t><xref target="convert-section-a.2" format="default" sectionFormat="of" derivedContent="Appendix A.2"/>.</t> <t pn="section-2.5-5"> An incoming label collision occurs if the SIDs of the set of FECs {FEC1,FEC2,...,FEC2, ..., FECk} map to the same incoming SR MPLS label "L1".</t><t><t pn="section-2.5-6"> Suppose an anycast prefix is advertised with aprefix-SIDPrefix-SID by some, but not all, of the nodes that advertise that prefix. If theprefix- SIDPrefix-SID sub-TLVs result in mapping that anycast prefix to the same incoming label, then the advertisement of theprefix-SIDPrefix-SID by some, but not all, of the advertising nodesMUST NOT<bcp14>MUST NOT</bcp14> be treated as a label collision.</t><t><t pn="section-2.5-7"> An implementationMUST NOT<bcp14>MUST NOT</bcp14> allow the MCCs belonging to the same router to assign the same incoming label to more than one SR FEC.</t><t><t pn="section-2.5-8"> The objective of the following steps is to deterministically install in the MPLS Incoming Label Map, also known as label FIB, a single FEC with the incoming label "L1". By "deterministicallyinstall"install", we mean 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 label "L1" irrespective of the order by which the mappings of this set of FECs to the label "L1" are received. For example,afirst-come-first-serve tie-breakingcome, first-served tiebreaking is not allowed. The remaining FECs may be installed in the IP FIB without an incoming label.</t><t><t pn="section-2.5-9"> The procedure in this section relies completely on the local FEC and label database within a given router.</t><t><t pn="section-2.5-10"> The collision resolution procedure is asfollows</t> <t><list style="numbers"><t>Givenfollows:</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 set of FECs, {FEC1, FEC2,..., FECk} map to the same MPLS label"L1".</t> <t>Within"L1".</li> <li pn="section-2.5-11.2" derivedCounter="2."> <t pn="section-2.5-11.2.1">Within an MCC, applytie-breakingtiebreaking rules to select one FEConlyonly, and assign the label to it. The losing FECs are handled as if no labels are attached to them. The losing FECs with algorithms other than the shortest path first <xreftarget="RFC8402"/>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> are not installed in theFIB.<list style="letters"><t>IfFIB. </t> <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 thetie-breakingtiebreaking rulesMUST<bcp14>MUST</bcp14> always select the same FEC irrespective of the order in which the FECs and the label "L1" are received. In other words, thetie-breakingtiebreaking ruleMUST<bcp14>MUST</bcp14> bedeterministic.</t> </list> </t> <t>Ifdeterministic.</li> </ol> </li> <li pn="section-2.5-11.3" derivedCounter="3.">If there is still collision between the FECs belonging to different MCCs, thenre-applyreapply thetie-breakingtiebreaking rules to the remaining FECs to select one FEConlyonly, and assign the label to thatFEC</t> <t>InstallFEC.</li> <li pn="section-2.5-11.4" derivedCounter="4.">Install the selected FEC into the IP FIBthe selected FECand its incoming labelininto the labelFIB.</t> <t>TheFIB.</li> <li pn="section-2.5-11.5" derivedCounter="5.">The remaining FECs with the default algorithm (see thespecification of prefix-SIDPrefix-SID algorithm specification <xreftarget="RFC8402"/>)target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>) may be installed in the FIB natively, such as pure IP entries in case of Prefix FEC, without any incoming labels corresponding to their SIDs. The remaining FECs with algorithms other than the shortest path first <xreftarget="RFC8402"/>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> are not installed in theFIB.</t> </list> </t>FIB.</li> </ol> <sectiontitle="Tie-breaking Rules" anchor="section-2.5.1"> <t>anchor="convert-section-2.5.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.5.1"> <name slugifiedName="name-tiebreaking-rules">Tiebreaking Rules</name> <t pn="section-2.5.1-1"> The defaulttie-breakingtiebreaking rules are specified as follows:</t><t><list style="numbers"><t>if FECi has<ol spacing="normal" type="1" start="1" pn="section-2.5.1-2"> <li pn="section-2.5.1-2.1" derivedCounter="1.">Determine the lowestFECadministrative distance among the competing FECs as defined inthisthe sectionbelow,below. Then filter away all the competing FECs with a higher administrativedistance.</t> <t>ifdistance.</li> <li pn="section-2.5.1-2.2" derivedCounter="2.">If more than one competing FEC remains after step 1, select the smallest numerical FEC value. The numerical value of the FEC is determined according to the FEC encoding described later in thissection.</t> </list> </t> <t>section.</li> </ol> <t pn="section-2.5.1-3"> These rules deterministically selectthewhich FEC to install in the MPLS forwarding plane for the given incoming label.</t><t><t pn="section-2.5.1-4"> This document defines the defaulttie breakingtiebreaking rules thatSHOULD<bcp14>SHOULD</bcp14> be implemented. An implementationMAY<bcp14>MAY</bcp14> choose to support differenttie- breakingtiebreaking rules andMAY<bcp14>MAY</bcp14> use one ofthethese instead of the defaulttie-breakingtiebreaking rules. To maximize MPLS forwarding consistency in case of a SID configuration error, the network operatorMUST<bcp14>MUST</bcp14> deploy, within an IGP flooding area, routers implementing the sametie-breakingtiebreaking rules.</t><t><t pn="section-2.5.1-5"> Each FEC is assigned an administrative distance. The FEC administrative distance is encoded as an 8-bit value. The lower the value, the better the administrative distance.</t><t><t pn="section-2.5.1-6"> The default FEC administrative distance order starting from the lowest valueSHOULD<bcp14>SHOULD</bcp14> be:</t><t><list style="symbols"><t>Explicit<ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-7"> <li pn="section-2.5.1-7.1"> <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 a static assignment of a label to a FEC such that the assignment survives a routerreboot.<list style="symbols"><t>Anreboot.</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-7.1.2"> <li pn="section-2.5.1-7.1.2.1">An example of explicit SID allocation is static assignment of a specific label to anadj-SID.</t> <t>AnAdj-SID.</li> <li pn="section-2.5.1-7.1.2.2">An implementation of explicit SID assignmentMUST<bcp14>MUST</bcp14> guarantee collision freeness on the samerouter</t> </list> </t> <t>Dynamic SID assignment:<list style="symbols"><t>For allrouter.</li> </ul> </li> <li pn="section-2.5.1-7.2"> <t pn="section-2.5.1-7.2.1">Dynamic SID assignment:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-7.2.2"> <li pn="section-2.5.1-7.2.2.1">All FECtypestypes, except forSR policy,theFEC typesSR Policy, are ordered using the default administrative distanceorderingdefined by theimplementation.</t> <t>Bindingimplementation.</li> <li pn="section-2.5.1-7.2.2.2">The Binding SID <xreftarget="RFC8402"/>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> assigned to the SR Policy always has a higher default administrative distance than the default administrative distance of any other FECtype</t> </list> </t> </list> </t> <t>type.</li> </ul> </li> </ul> <t pn="section-2.5.1-8"> To maximize MPLS forwarding consistency,If aif the same FEC is advertised in more than one protocol, a userMUST<bcp14>MUST</bcp14> ensure that the administrative distance preference between protocols is the same on all routers of the IGP flooding domain. Note that this is not really new as this already applies to IP forwarding.</t><t><t pn="section-2.5.1-9"> The numerical sort across FECsSHOULD<bcp14>SHOULD</bcp14> be performed as follows:<list style="symbols"> <t>Each</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-10"> <li pn="section-2.5.1-10.1"> <t pn="section-2.5.1-10.1.1">Each FEC is assigned a FEC type encoded in 8 bits. Thefollowing are thetypecode pointcodepoints for each SR FEC defined at the beginning of thisSection: <list style="empty"> <t>120: (Prefix,section are as follows: </t> <ul empty="true" bare="false" spacing="normal" pn="section-2.5.1-10.1.2"> <li pn="section-2.5.1-10.1.2.1"> <dl newline="false" spacing="normal" pn="section-2.5.1-10.1.2.1.1"> <dt pn="section-2.5.1-10.1.2.1.1.1">120:</dt> <dd pn="section-2.5.1-10.1.2.1.1.2">(Prefix, Routing Instance, Topology,Algorithm)</t> <t>130: (next-hop,Algorithm)</dd> <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, outgoinginterface)</t> <t>140:interface)</dd> <dt pn="section-2.5.1-10.1.2.1.1.5">140:</dt> <dd pn="section-2.5.1-10.1.2.1.1.6"> Parallel Adjacency <xreftarget="RFC8402"/></t> <t>150: an SR policytarget="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 <xreftarget="RFC8402"/>.</t> <t>160: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 <xreftarget="RFC8402"/></t> <t>Thetarget="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 mentioned to guide implementation. If other numerical values are used, then the numerical values must maintain the same greater-than ordering of the numbers mentioned here.</t></list></t> <t>The</li> <li pn="section-2.5.1-10.2"> <t pn="section-2.5.1-10.2.1">The fields of each FEC are encoded asfollows <list style="symbols"> <t>Allfollows: </t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-10.2.2"> <li pn="section-2.5.1-10.2.2.1">All fields in all FECs are encoded in bigendian</t> <t>Routingendian order.</li> <li pn="section-2.5.1-10.2.2.2">The Routing Instance ID is represented by 16 bits. For routing instances that are identified by less than 16 bits, encode the Instance ID in the least significant bits while the most significant bits are set tozero</t> <t>Address Familyzero.</li> <li pn="section-2.5.1-10.2.2.3">The address family is represented by 8 bits, where IPv4 is encoded as100100, and IPv6 is encoded as 110. These numerical values are mentioned to guide implementations. If other numerical values are used, then the numerical value of IPv4MUST<bcp14>MUST</bcp14> be less than the numerical value forIPv6</t> <t>AllIPv6.</li> <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 in 128 bits asfollows <list style="symbols"> <t>IPv6follows: </t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.1-10.2.2.4.2"> <li pn="section-2.5.1-10.2.2.4.2.1">The IPv6 address is encodednatively</t> <t>IPv4natively.</li> <li pn="section-2.5.1-10.2.2.4.2.2">The IPv4 address is encoded in the most significantbitsbits, and the remaining bits are set tozero</t></list> </t> <t>Allzero.</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.<list style="symbols"> <t>A</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 the most significantbitsbits, and the remaining bits are set tozero.</t> <t>Thezero.</li> <li pn="section-2.5.1-10.2.2.5.2.2">The prefix length is encoded before the prefix ina field of size 8 bits.</t></list> </t> <t>Topologyan 8-bit field.</li> </ul> </li> <li pn="section-2.5.1-10.2.2.6">The Topology ID is represented by 16 bits. For routing instances that identify topologies using less than 16 bits, encode the topology ID in the least significant bits while the most significant bits are set tozero</t> <t>Algorithmzero.</li> <li pn="section-2.5.1-10.2.2.7">The Algorithm is encoded in a16 bits field.</t> <t>The16-bit field.</li> <li pn="section-2.5.1-10.2.2.8">The Color ID is encoded using 32bits</t> </list> </t> <t>Choosebits.</li> </ul> </li> <li pn="section-2.5.1-10.3">Choose the set of FECs of the smallest FEC typecode point</t> <t>Outcodepoint.</li> <li pn="section-2.5.1-10.4">Out of these FECs, choose the FECs with the smallest address familycode point</t> <t>Encodecodepoint.</li> <li pn="section-2.5.1-10.5"> <t pn="section-2.5.1-10.5.1">Encode the remaining set of FECs asfollows <list style="symbols"> <t>(Prefix,follows: </t> <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, Topology, Algorithm) is encoded as (Prefix Length, Prefix, routing_instance_id, Topology, SRAlgorithm)</t> <t>(next-hop,Algorithm).</li> <li pn="section-2.5.1-10.5.2.2">(next hop, outgoing interface) is encoded as(next-hop, outgoing_interface_id)</t> <t>(number(next hop, outgoing_interface_id).</li> <li pn="section-2.5.1-10.5.2.3">(number of adjacencies, list ofnext-hopsnext hops in ascending numerical order, list of outgoing interface IDs in ascending numericalorder). This encodingorder) is used to encode a parallel adjacency <xreftarget="RFC8402"/></t> <t>(Endpoint,target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</li> <li pn="section-2.5.1-10.5.2.4">(Endpoint, Color) is encoded as (Endpoint_address,Color_id)</t> <t>(IP address): ThisColor_id).</li> <li pn="section-2.5.1-10.5.2.5">(IP address) is the encoding for amirrorMirror SID FEC. The IP address is encoded as described above in thissection</t> </list> </t> <t>Selectsection.</li> </ul> </li> <li pn="section-2.5.1-10.6">Select the FEC with the smallest numericalvalue</t> </list></t> <t>value.</li> </ul> <t pn="section-2.5.1-11"> The numerical values mentioned in this section are for guidance only. If other numerical values areusedused, then the other numerical valuesMUST<bcp14>MUST</bcp14> maintain the same numerical ordering among different SR FECs.</t> </section> <sectiontitle="Redistributionanchor="convert-section-2.5.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.5.2"> <name slugifiedName="name-redistribution-between-rout">Redistribution between Routing ProtocolInstances" anchor="section-2.5.2"><t>Instances</name> <t pn="section-2.5.2-1"> The following ruleSHOULD<bcp14>SHOULD</bcp14> be applied when redistributing SIDs with prefixes between routing protocol instances:</t><t> <list style="symbols"> <t>If<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 thereceiving instance'sSRGB of the receiving instance is the same as the SRGB of the origin instance,then <list style="symbols"> <t>thethen: </t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.2-2.1.2"> <li pn="section-2.5.2-2.1.2.1">the index is redistributed with theroute</t> </list>route.</li> </ul> </li> <li pn="section-2.5.2-2.2"> <t pn="section-2.5.2-2.2.1">Else, </t><t>Else <list style="symbols"> <t>the<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 and if the receiving instance decides to advertise an index with the redistributed route, it is the duty of the receiving instance to allocate a fresh index relative to its own SRGB. Note that in thiscasecase, the receiving instanceMUST<bcp14>MUST</bcp14> compute the local label itassignesassigns to the route according tosection 2.4<xref target="convert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2.4"/> and install it inFIB.</t> </list> </t> </list> </t> <t>FIB.</li> </ul> </li> </ul> <t pn="section-2.5.2-3"> It is outside the scope of this document to define local node behaviors that would allowto mapthe mapping of the original index into a new index in the receiving instance via the addition of an offset or other policy means.</t> <sectiontitle="Illustration" anchor="section-2.5.2.1"> <figure><artwork><![CDATA[anchor="convert-section-2.5.2.1" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.5.2.1"> <name slugifiedName="name-illustration">Illustration</name> <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) ]]></artwork> </figure> <t>Consider(20001)</artwork> <t pn="section-2.5.2.1-2">Consider the simple topologyabove.</t> <t> <list style="symbols"> <t>Aabove, where:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.5.2.1-3"> <li pn="section-2.5.2.1-3.1">A and B are in the IS-IS domain with SRGB[16000-17000]</t> <t>B= [16000-17000]</li> <li pn="section-2.5.2.1-3.2">B and C are in the OSPF domain with SRGB[20000-21000]</t> <t>B= [20000-21000]</li> <li pn="section-2.5.2.1-3.3">B redistributes 192.0.2.1/32 intoIS-IS domain</t> <!--[rfced] Shouldthetwo points below actually be part ofIS-IS domain</li> </ul> <t pn="section-2.5.2.1-4">In thislist? Seems kind of different from the first 3 points...--> <t>In that casecase, A learns 192.0.2.1/32 as an IP leaf connected toB asB, which is usual for IP prefix redistribution</t><t>However,<t pn="section-2.5.2.1-5">However, according to the redistribution ruleabove rule,above, B decides not to advertise any index with 192.0.2.1/32 into IS-IS because the SRGB is not the same.</t></list> </t></section> <sectiontitle="Illustration 2" anchor="section-2.5.2.2"><t>anchor="convert-section-2.5.2.2" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.5.2.2"> <name slugifiedName="name-illustration-2">Illustration 2</name> <t pn="section-2.5.2.2-1"> Consider the example in the illustration described in <xreftarget="section-2.5.2.1"/>.</t> <t>target="convert-section-2.5.2.1" format="default" sectionFormat="of" derivedContent="Section 2.5.2.1"/>.</t> <t pn="section-2.5.2.2-2"> When router B redistributes the prefix 192.0.2.1/32, router B decides to allocate and advertise the same index 1 with the prefix192.0.2.1/32</t> <t>192.0.2.1/32.</t> <t pn="section-2.5.2.2-3"> Within the SRGB of the IS-IS domain, index 1 corresponds to the local label16001</t> <t><list style="symbols"><t>Hence16001. Hence, according to the redistribution rule above, router B programs the incoming label 16001 in its FIB to match traffic arriving from the IS-IS domain destined to the prefix 192.0.2.1/32.</t></list> </t></section> </section> </section> <sectiontitle="Effectanchor="convert-section-2.6" numbered="true" toc="include" removeInRFC="false" pn="section-2.6"> <name slugifiedName="name-effect-of-incoming-label-co">Effect of Incoming Label Collision on Outgoing LabelProgramming" anchor="section-2.6"><t> For the determination of theProgramming</name> <t pn="section-2.6-1"> When determining what outgoing label to use, the ingress nodepushingthat pushes new segments, and hence a stack of MPLS labels,MUST<bcp14>MUST</bcp14> use, for a given FEC, thesamelabel that has been selected by the node receiving the packet with that label exposed as the top label. So in case of incoming label collision on this receiving node, the ingress nodeMUST<bcp14>MUST</bcp14> resolve this collision by using this same "Incoming Label Collision resolutionprocedure",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 haveexactlythe exact same dataofas the receiving node, so the result may be different. This is under the responsibility of the network operator. But in a typical case,e.g.e.g., where a centralized node or a distributedlink statelink-state IGP is used, all nodes would have the same database.HoweverHowever, to minimize the chance of misforwarding, a FEC that loses its incoming label to thetie-breakingtiebreaking rules specified in <xreftarget="section-2.5"/> MUST NOTtarget="convert-section-2.5" format="default" sectionFormat="of" derivedContent="Section 2.5"/> <bcp14>MUST NOT</bcp14> be installed in FIB with an outgoingsegment routingSegment Routing label based on the SID corresponding to the lost incoming label.</t><t><t pn="section-2.6-3"> Examples for the behavior specified in this section can be found inAppendix A.3.</t><xref target="convert-section-a.3" format="default" sectionFormat="of" derivedContent="Appendix A.3"/>.</t> </section> <sectiontitle="PUSH,anchor="convert-section-2.7" numbered="true" toc="include" removeInRFC="false" pn="section-2.7"> <name slugifiedName="name-push-continue-and-next">PUSH, CONTINUE, andNEXT" anchor="section-2.7"><t>NEXT</name> <t pn="section-2.7-1"> PUSH, NEXT, and CONTINUE are operations applied by the forwarding plane. The specifications of these operations can be found in <xreftarget="RFC8402"/>.target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>. Thissub-sectionsubsection specifies how to implement each of these operations in the MPLS forwarding plane.</t> <sectiontitle="PUSH" anchor="section-2.7.1"><t>anchor="convert-section-2.7.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.7.1"> <name slugifiedName="name-push">PUSH</name> <t pn="section-2.7.1-1"> As described in <xreftarget="RFC8402"/>,target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, PUSH corresponds to pushing one or more labels on top of an incoming packet then sending it out of a particular physical interface or virtual interface, such as a UDP tunnel <xreftarget="RFC7510"/>target="RFC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/> orL2TPv3 tunnelthe Layer 2 Tunneling Protocol version 3 (L2TPv3) <xreftarget="RFC4817"/>,target="RFC4817" format="default" sectionFormat="of" derivedContent="RFC4817"/>, towards a particularnext-hop.next hop. When pushing labels onto a packet's label stack, theTime- to-LiveTime-to-Live (TTL) field(<xref target="RFC3032"/>,<xreftarget="RFC3443"/>)target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> <xref target="RFC3443" format="default" sectionFormat="of" derivedContent="RFC3443"/> and the Traffic Class (TC) field(<xref target="RFC3032"/>,<xreftarget="RFC5462"/>)target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> <xref target="RFC5462" format="default" sectionFormat="of" derivedContent="RFC5462"/> of each label stack entry must, of course, be set. This document does not specify any set of rules for setting these fields; that is a matter of local policy. Sections2.10<xref target="convert-section-2.10" format="counter" sectionFormat="of" derivedContent="2.10"/> and2.11<xref target="convert-section-2.11" format="counter" sectionFormat="of" derivedContent="2.11"/> specify additional details about forwarding behavior.</t> </section> <sectiontitle="CONTINUE" anchor="section-2.7.2"><t>anchor="convert-section-2.7.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.7.2"> <name slugifiedName="name-continue">CONTINUE</name> <t pn="section-2.7.2-1"> As described in <xreftarget="RFC8402"/>,target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, the CONTINUE operation corresponds to swapping the incoming label with an outgoing label. The value of the outgoing label is calculated as specified in Sections2.10 and 2.11.</t> </section> <section title="NEXT" anchor="section-2.7.3"><t><xref target="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"/>.</t> </section> <section anchor="convert-section-2.7.3" numbered="true" toc="include" removeInRFC="false" pn="section-2.7.3"> <name slugifiedName="name-next">NEXT</name> <t pn="section-2.7.3-1"> As described in <xreftarget="RFC8402"/>,target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, NEXT corresponds to popping the topmost label. The action before and/or after the popping depends on the instruction associated with the active SID on the received packet prior to the popping. Forexampleexample, suppose the active SID in the received packet was an Adj-SID <xreftarget="RFC8402"/>, thentarget="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>; on receiving the packet, the node applies the NEXT operation, which corresponds to popping thetop mosttopmost label, and then sends the packet out of the physical or virtual interface(e.g.(e.g., the UDP tunnel <xreftarget="RFC7510"/>target="RFC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/> or L2TPv3 tunnel <xreftarget="RFC4817"/>)target="RFC4817" format="default" sectionFormat="of" derivedContent="RFC4817"/>) towards thenext-hopnext hop corresponding to theadj-SID.</t>Adj-SID.</t> <sectiontitle="Mirror SID" anchor="section-2.7.3.1"><t>anchor="convert-section-2.7.3.1" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.7.3.1"> <name slugifiedName="name-mirror-sid">Mirror SID</name> <t pn="section-2.7.3.1-1"> If the active SID in the received packet was a Mirror SID[RFC8402, Section 5.1](see <xref target="RFC8402" sectionFormat="comma" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-5.1" derivedContent="RFC8402"/>) allocated by the receiving router,thenthe receiving router applies the NEXT operation, which corresponds to popping thetop mosttopmost label, and then performs a lookup using the contents of the packet after popping theouter mostoutermost label in the mirrored forwarding table.<!--[rfced] Should this all be one big paragraph? Occurs at a page break in original, so I can't tell. Diff file gives a hit here. -->The method by which the lookup is made, and/or the actions applied to the packet after the lookup in the mirrortabletable, depends on the contents of the packet and the mirror table. Note that the packet exposed after popping thetop mosttopmost label may or may not be an MPLS packet. AmirrorMirror SID can be viewed as a generalization of the context label in <xreftarget="RFC5331"/>target="RFC5331" format="default" sectionFormat="of" derivedContent="RFC5331"/> because amirrorMirror SID does not make any assumptions about the packet underneath the top label.</t> </section> </section> </section> <sectiontitle="MPLSanchor="convert-section-2.8" numbered="true" toc="include" removeInRFC="false" pn="section-2.8"> <name slugifiedName="name-mpls-label-downloaded-to-th">MPLS Label Downloaded to the FIB for Global and LocalSIDs" anchor="section-2.8"><t>SIDs</name> <t pn="section-2.8-1"> The label corresponding to the global SID"Si""Si", which is represented by the global index "I" and downloaded toFIBthe FIB, is used to match packets whose active segment (and hence topmost label) is "Si". The value of this label is calculated as specified in <xreftarget="section-2.4"/>.</t> <t>target="convert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2.4"/>.</t> <t pn="section-2.8-2"> For Local SIDs, the MCC is responsible for downloading the correct label value to the FIB. For example, an IGP with SR extensions[I-D.ietf-isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-extensions]<xref target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> <xref target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/> downloads the MPLS label corresponding to an Adj-SID <xreftarget="RFC8402"/>.</t> </section> <section title="Active Segment" anchor="section-2.9"><t>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t> </section> <section anchor="convert-section-2.9" numbered="true" toc="include" removeInRFC="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 corresponds to the topmost labelon the packet thatand is calculated according to the procedure specified in Sections2.10<xref target="convert-section-2.10" format="counter" sectionFormat="of" derivedContent="2.10"/> and2.11.<xref target="convert-section-2.11" format="counter" sectionFormat="of" derivedContent="2.11"/>. When arriving at a node, the topmost label corresponding to the active SID matches the MPLS label downloaded to the FIB as specified in <xreftarget="section-2.4"/>.</t>target="convert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2.4"/>.</t> </section> <sectiontitle="Forwarding behavioranchor="convert-section-2.10" numbered="true" toc="include" removeInRFC="false" pn="section-2.10"> <name slugifiedName="name-forwarding-behavior-for-glo">Forwarding Behavior for GlobalSIDs" anchor="section-2.10"><t>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 the PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.</t><t><t pn="section-2.10-2"> This document covers the calculation of the outgoing label for the 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 policy or atraffic engineeringtraffic-engineering tunnel is outside the scope of this document and may be covered in other documents such as <xreftarget="I-D.ietf-spring-segment-routing-policy"/>.</t> <section title="Forwardingtarget="ROUTING-POLICY" format="default" sectionFormat="of" derivedContent="ROUTING-POLICY"/>.</t> <section anchor="convert-section-2.10.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.10.1"> <name slugifiedName="name-forwarding-for-push-and-con">Forwarding for PUSH and CONTINUE of GlobalSIDs" anchor="section-2.10.1"><t>SIDs</name> <t pn="section-2.10.1-1"> Suppose an MCC onarouter "R0" determinesthatthat, before sending the packet towards a neighbor "N", the PUSH or CONTINUE 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 routerRi before sending the packet towards a neighborRi. Neighbor "N" may be directly connected to "R0" through either a physical or a virtual interfacesuch as(e.g., UDP tunnel <xreftarget="RFC7510"/>target="RFC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/> or L2TPv3 tunnel <xreftarget="RFC4817"/>.</t> <t>target="RFC4817" format="default" sectionFormat="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 scope of this document. An example of a method to determine the SID "Si" for the PUSH operation is the case where IS-IS <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> receives theprefix-SIDPrefix-SID "Si" sub-TLV advertised with the prefix "P/m" in TLV135135, and thedestination address of the incoming IPv4 packetprefix "P/m" iscovered bythe longest matching network prefix"P/m".</t> <t>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 <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> receives theprefix-SIDPrefix-SID "Si" sub-TLV advertised with prefix "P" in TLV135135, and the top label of the incoming packet matches the MPLS label in the FIB corresponding to the SID "Si" ontherouter "R0".</t><t><t pn="section-2.10.1-4"> The forwarding behavior for PUSH and CONTINUE corresponding to the SID"Si"</t> <t> <list style="symbols"> <t>If the"Si" is as follows:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.10.1-5"> <li pn="section-2.10.1-5.1"> <t pn="section-2.10.1-5.1.1">If neighbor "N" does not support SR or advertises an invalid SRGB or a SRGB that is too small for the SID"Si" <list style="symbols"> <t>If"Si", then: </t> <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 packet towardstheneighbor "N" using standard MPLS forwarding behavior as specified in <xreftarget="RFC3031"/>target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> and <xreftarget="RFC3032"/>, thentarget="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/>, forward the packet. The method 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 example, the router "R0" can use the downstream label determined by another MCC, such as LDP <xreftarget="RFC5036"/>,target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/>, to send thepacket.</t> <t>Elsepacket.</li> <li pn="section-2.10.1-5.1.2.2">Else, if there are otheruseable next-hops, thenusable next hops, useother next- hopsthem to forward the incoming packet. The method by which the router "R0" decides on the possibility of using othernext-next hops is beyond the scope of this document. For example, the MCC on "R0" may chose the send an IPv4 packet without pushing any label to anothernext-hop.</t> <t>Otherwisenext hop.</li> <li pn="section-2.10.1-5.1.2.3">Otherwise, drop thepacket.</t> </list>packet.</li> </ul> </li> <li pn="section-2.10.1-5.2"> <t pn="section-2.10.1-5.2.1">Else, </t><t>Else <list style="symbols"> <t>Calculate<ul spacing="normal" bare="false" empty="false" pn="section-2.10.1-5.2.2"> <li pn="section-2.10.1-5.2.2.1"> Calculate the outgoing label as specified in <xreftarget="section-2.4"/>target="convert-section-2.4" format="default" sectionFormat="of" derivedContent="Section 2.4"/> using the SRGB oftheneighbor"N" <list style="symbols"> <!--[rfced] id2xml is reading the following bullet as a subpoint of "Calculate"N". </li> <li pn="section-2.10.1-5.2.2.2"> <t pn="section-2.10.1-5.2.2.2.1">Determine the outgoinglabel...". I don't know if this is correct. Please review.--> <t>Iflabel stack</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.10.1-5.2.2.2.2"> <li pn="section-2.10.1-5.2.2.2.2.1"> <t pn="section-2.10.1-5.2.2.2.2.1.1">If the operation isPUSH <list style="symbols"> <t>PushPUSH: </t> <ul spacing="normal" bare="false" empty="false" pn="section-2.10.1-5.2.2.2.2.1.2"> <li pn="section-2.10.1-5.2.2.2.2.1.2.1">Push the calculated label according to the MPLS label pushing rules specified in <xreftarget="RFC3032"/>target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/>. </li> </ul> </li> <li pn="section-2.10.1-5.2.2.2.2.2"> <t pn="section-2.10.1-5.2.2.2.2.2.1">Else, </t></list></t> <t>Else <list style="symbols"> <t>swap<ul spacing="normal" bare="false" empty="false" pn="section-2.10.1-5.2.2.2.2.2.2"> <li pn="section-2.10.1-5.2.2.2.2.2.2.1">swap the incoming label with the calculated label according to thelabel swappinglabel-swapping rules in <xreftarget="RFC3032"/> </t> </list> </t> <t>Sendtarget="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>. </li> </ul> </li> <li pn="section-2.10.1-5.2.2.2.2.3">Send the packet towardstheneighbor"N"</t> </list> </t> </list> </t> </list> </t>"N".</li> </ul> </li> </ul> </li> </ul> </section> <sectiontitle="Forwardinganchor="convert-section-2.10.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.10.2"> <name slugifiedName="name-forwarding-for-the-next-ope">Forwarding for the NEXT Operation for GlobalSIDs" anchor="section-2.10.2"><t>SIDs</name> <t pn="section-2.10.2-1"> As specified in <xreftarget="section-2.7.3"/>target="convert-section-2.7.3" format="default" sectionFormat="of" derivedContent="Section 2.7.3"/>, the NEXT operation corresponds to popping thetop mosttopmost label. The forwarding behavior is asfollows</t> <t><list style="symbols"><t>Popfollows:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2.10.2-2"> <li pn="section-2.10.2-2.1">Pop the topmostlabel</t> <t>Applylabel</li> <li pn="section-2.10.2-2.2">Apply the instruction associated with the incoming label that has beenpopped</t> </list> </t> <t>popped</li> </ul> <t pn="section-2.10.2-3"> The action on the packet after popping the topmost label depends on the instruction associated with the incoming label as well as the contents of the packet right underneath the top label thatgotwas popped. Examples of the NEXT operation are described inAppendix A.1.</t><xref target="convert-section-a.1" format="default" sectionFormat="of" derivedContent="Appendix A.1"/></t> </section> </section> <sectiontitle="Forwardinganchor="convert-section-2.11" numbered="true" toc="include" removeInRFC="false" pn="section-2.11"> <name slugifiedName="name-forwarding-behavior-for-loc">Forwarding Behavior for LocalSIDs" anchor="section-2.11"><t>SIDs</name> <t pn="section-2.11-1"> This section specifies the forwarding behavior forlocalLocal SIDs when SR is instantiated over the MPLS forwarding plane.</t> <sectiontitle="Forwardinganchor="convert-section-2.11.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.11.1"> <name slugifiedName="name-forwarding-for-the-push-ope">Forwarding for the PUSH Operation on LocalSIDs" anchor="section-2.11.1"><t>SIDs</name> <t pn="section-2.11.1-1"> Suppose an MCC onarouter "R0" determines that the PUSH operation is to be applied to an incoming packet using thelocalLocal SID "Si" before sending the packet towardsaneighbor"N""N", which is directly connected to R0 through a physical or virtual interface such as a UDP tunnel <xreftarget="RFC7510"/>target="RFC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/> or L2TPv3 tunnel <xreftarget="RFC4817"/>.</t> <t>target="RFC4817" format="default" sectionFormat="of" derivedContent="RFC4817"/>.</t> <t pn="section-2.11.1-2"> An example of suchlocala Local SID is an Adj-SID allocated and advertised by IS-IS <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.target="RFC8667" format="default" sectionFormat="of" derivedContent="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 example of such a method is the backup path used to protect against a failure using TI-LFA <xreftarget="I-D.bashandy-rtgwg-segment-routing-ti-lfa"/>.</t> <t>target="FAST-REROUTE" format="default" sectionFormat="of" derivedContent="FAST-REROUTE"/>.</t> <t pn="section-2.11.1-3"> As mentioned in <xreftarget="RFC8402"/>,target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, alocalLocal SID is specified by an MPLS label.HenceHence, the PUSH operation for alocalLocal SID is identical to the label push operation<xref target="RFC3032"/>using any MPLSlabel.label <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>. The forwarding action after pushing the MPLS label corresponding to thelocalLocal SID is also 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 forwarding action may be sending the packet to a certain neighbor that will in turn continue to forward the packet along the backuppath</t>path.</t> </section> <sectiontitle="Forwardinganchor="convert-section-2.11.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.11.2"> <name slugifiedName="name-forwarding-for-the-continue">Forwarding for the CONTINUE Operation for LocalSIDs" anchor="section-2.11.2"><t>SIDs</name> <t pn="section-2.11.2-1"> AlocalLocal SID onarouter "R0" corresponds to a local label. In such a scenario, the outgoing label towardsa next-hopnext hop "N" is determined by the MCC running on the router"R0"and"R0", and the forwarding behavior for the CONTINUE operation is identical to the swap operation<xref target="RFC3032"/>on an MPLSlabel.</t>label <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>.</t> </section> <sectiontitle="Outgoing labelanchor="convert-section-2.11.3" numbered="true" toc="include" removeInRFC="false" pn="section-2.11.3"> <name slugifiedName="name-outgoing-label-for-the-next">Outgoing Label for the NEXT Operation for LocalSIDs" anchor="section-2.11.3"><t>SIDs</name> <t pn="section-2.11.3-1"> The NEXT operation for Local SIDs is identical to the NEXT operation for global SIDs as specified in <xreftarget="section-2.10.2"/>.</t>target="convert-section-2.10.2" format="default" sectionFormat="of" derivedContent="Section 2.10.2"/>.</t> </section> </section> </section> <sectiontitle="IANA Considerations" anchor="section-3"><t>anchor="convert-section-3" numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t pn="section-3-1"> This documentdoes not make any request to IANA.</t>has no IANA actions.</t> </section> <sectiontitle="Manageability Considerations" anchor="section-4"><t>anchor="convert-section-4" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-manageability-consideration">Manageability Considerations</name> <t pn="section-4-1"> This document describes the applicability of Segment Routing over the MPLS data plane. Segment Routing does not introduce any change in the MPLS data plane. Manageability considerations described in <xreftarget="RFC8402"/> appliestarget="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> apply to the MPLS data plane when used with Segment Routing. SROAMOperations, Administration, and Maintenance (OAM) use cases for the MPLS data plane are defined in <xreftarget="RFC8403"/>.target="RFC8403" format="default" sectionFormat="of" derivedContent="RFC8403"/>. SR OAM procedures for the MPLS data plane are defined in <xreftarget="RFC8287"/>.</t> </section> <section title="Security Considerations" anchor="section-5"><t>target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/>.</t> </section> <section anchor="convert-section-5" numbered="true" toc="include" removeInRFC="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 mechanisms other than the ones described in <xreftarget="RFC8402"/>.</t>target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t> </section><section title="Contributors" anchor="section-6"><t> The following contributors have substantially helped</middle> <back> <references pn="section-6"> <name slugifiedName="name-references">References</name> <references pn="section-6.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="March"/> <abstract> <t>In many standards track documents several words are used to signify thedefinitionrequirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, andediting ofrequests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" quoteTitle="true" derivedAnchor="RFC3031"> <front> <title>Multiprotocol Label Switching Architecture</title> <author initials="E." surname="Rosen" fullname="E. Rosen"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Viswanathan" fullname="A. Viswanathan"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Callon" fullname="R. Callon"> <organization showOnFrontPage="true"/> </author> <date year="2001" month="January"/> <abstract> <t>This document specifies thecontent of this document:</t> <figure><artwork><![CDATA[ Martin Horneffer Deutsche Telekom Email: Martin.Horneffer@telekom.de Wim Henderickx Nokia Email: wim.henderickx@nokia.com Jeff Tantsura Email: jefftant@gmail.com Edward Crabbe Email: edward.crabbe@gmail.com Igor Milojevic Email: milojevicigor@gmail.com Saku Ytti Email: saku@ytti.fi ]]></artwork> </figure> </section> <section title="Acknowledgements" anchor="section-7"><t> The authors would likearchitecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3031"/> <seriesInfo name="DOI" value="10.17487/RFC3031"/> </reference> <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" quoteTitle="true" derivedAnchor="RFC3032"> <front> <title>MPLS Label Stack Encoding</title> <author initials="E." surname="Rosen" fullname="E. Rosen"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Tappan" fullname="D. Tappan"> <organization showOnFrontPage="true"/> </author> <author initials="G." surname="Fedorkow" fullname="G. Fedorkow"> <organization showOnFrontPage="true"/> </author> <author initials="Y." surname="Rekhter" fullname="Y. Rekhter"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Farinacci" fullname="D. Farinacci"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Li" fullname="T. Li"> <organization showOnFrontPage="true"/> </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 tothank Les Ginsberg, Chris Bowers, Himanshu Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren Dukes, Zafar Ali,be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, andMartin Vigoureuxpossibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack 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/rfc3443" quoteTitle="true" derivedAnchor="RFC3443"> <front> <title>Time To Live (TTL) Processing in Multi-Protocol Label Switching (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 hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of 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/rfc5462" 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 defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, 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 Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today 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 the 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. [STANDARDS-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/rfc7274" 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 is 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 retirement 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-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.</t> <t>This document updates a number of previous RFCs that use the term "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/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that 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/rfc8402" 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 segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t> <t>SR can be directly applied to the MPLS architecture with no change 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 popped 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 segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The 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-REROUTE"> <front> <title>Topology Independent Fast Reroute using Segment Routing</title> <author initials="S" surname="Litkowski" fullname="Stephane Litkowski"> <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-routing-ti-lfa-01"/> <refcontent>Work in Progress</refcontent> </reference> <reference anchor="RFC4817" target="https://www.rfc-editor.org/info/rfc4817" 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 protocol 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 encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [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/rfc5036" quoteTitle="true" derivedAnchor="RFC5036"> <front> <title>LDP Specification</title> <author initials="L." surname="Andersson" fullname="L. Andersson" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="I." surname="Minei" fullname="I. Minei" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="B." surname="Thomas" fullname="B. Thomas" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="October"/> <abstract> <t>The architecture for Multiprotocol Label Switching (MPLS) is described 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 between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures 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/rfc5331" quoteTitle="true" derivedAnchor="RFC5331"> <front> <title>MPLS Upstream Label Assignment and Context-Specific Label Space</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 MPLS 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/rfc7510" 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, called 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 Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed 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 not 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/rfc7855" quoteTitle="true" derivedAnchor="RFC7855"> <front> <title>Source Packet Routing in Networking (SPRING) Problem Statement 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 number 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 imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).</t> <t>This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements 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/rfc8287" 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 Planes</title> <author initials="N." surname="Kumar" fullname="N. Kumar" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="C." surname="Pignataro" fullname="C. Pignataro" role="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 and 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 raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS 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/rfc8403" quoteTitle="true" derivedAnchor="RFC8403"> <front> <title>A Scalable and Topology-Aware MPLS Data-Plane Monitoring System</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" role="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 system 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 to 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. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.</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/rfC8661" 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" role="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 Litkowski"> <organization showOnFrontPage="true"/> </author> <date month="December" year="2019"/> </front> </reference> <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8665" quoteTitle="true" derivedAnchor="RFC8665"> <front> <title>OSPF Extensions fortheir valuable comments on this document.</t> <t> This document was prepared using 2-Word-v2.0.template.dot.</t> </section> </middle> <back> <references title="Normative References"> &RFC8402; &RFC2119; &RFC3031; &RFC3032; &RFC3443; &RFC5462; &RFC7274; &RFC8174;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" role="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/rfc8666" 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" role="editor"> <organization showOnFrontPage="true"/> </author> <date month="December" year="2019"/> </front> </reference> <reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8667" 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" role="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://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-05" derivedAnchor="ROUTING-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-routing-policy-05"/> <refcontent>Work in Progress</refcontent> </reference> </references><references title="Informative References"> &I-D.ietf-isis-segment-routing-extensions; &I-D.ietf-ospf-ospfv3-segment-routing-extensions; &I-D.ietf-ospf-segment-routing-extensions; &I-D.ietf-spring-segment-routing-ldp-interop; &I-D.bashandy-rtgwg-segment-routing-ti-lfa; &RFC7855; &RFC5036; &RFC5331; &RFC7510; &RFC4817; &RFC8287; &RFC8403; &I-D.ietf-spring-segment-routing-policy;</references> <sectiontitle="Examples" anchor="section-a"><section title="IGP Segments Example" anchor="section-a.1"><t>anchor="convert-section-a" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-examples">Examples</name> <section anchor="convert-section-a.1" numbered="true" toc="include" removeInRFC="false" pn="section-a.1"> <name slugifiedName="name-igp-segment-examples">IGP Segment Examples</name> <t pn="section-a.1-1"> Consider the network diagram ofFigure 1<xref target="fig1" format="default" sectionFormat="of" derivedContent="Figure 1"/> and the IPaddressaddresses and IGPSegment allocationsegment allocations ofFigure 2.<xref target="fig2" format="default" sectionFormat="of" derivedContent="Figure 2"/>. Assume that the network is running IS-IS with SR extensions <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>, and all links have the same metric. The following examples can be constructed.</t> <figuretitle="IGPanchor="fig1" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-igp-segments-illustration">IGP Segments- Illustration" anchor="fig1"> <artwork><![CDATA[-- Illustration</name> <artwork name="" type="" align="left" alt="" pn="section-a.1-2.1"> +--------+ / \ R0-----R1-----R2----------R3-----R8 | \ / | | +--R4--+ | | |+-----R5-----+ ]]> </artwork>+-----R5-----+</artwork> </figure> <figuretitle="IGPanchor="fig2" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-igp-address-and-segment-all">IGP Address and Segment Allocation- Illustration" anchor="fig2"> <artwork><![CDATA[-- Illustration</name> <artwork name="" type="" align="left" alt="" pn="section-a.1-3.1"> +-----------------------------------------------------------+ | IPaddressaddresses allocated by the operator: | | 192.0.2.1/32 as a loopback of R1 | | 192.0.2.2/32 as a loopback of R2 | | 192.0.2.3/32 as a loopback of R3 | | 192.0.2.4/32 as a loopback of R4 | | 192.0.2.5/32 as a loopback of R5 | | 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 R5 | | | | SRGB defined by the operator as1000-5000[1000,5000] | | | | Global IGP SID indices allocated by the operator: | | 1 allocated to 192.0.2.1/32 | | 2 allocated to 192.0.2.2/32 | | 3 allocated to 192.0.2.3/32 | | 4 allocated to 192.0.2.4/32 | | 8 allocated to 192.0.2.8/32 | | 1009 allocated to 198.51.100.9/32 | | | | Local IGP SID allocated dynamically by R2 | | for its "north" adjacency to R3: 9001 | | for its "east" adjacency to R3 : 9002 | | for its "south" adjacency to R3: 9003 | | for its only adjacency to R4 : 9004 | | for its only adjacency to R1 : 9005 |+-----------------------------------------------------------+ ]]> </artwork>+-----------------------------------------------------------+</artwork> </figure><t><t pn="section-a.1-4"> Suppose R1 wants to sendanIPv4 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"> 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 domain: any router forwards a packet received with active segment 8 to thenext-hopnext hop along the ECMP-awareshortest-pathshortest path to the related prefix.</t><t><t pn="section-a.1-6"> R2 is thenext-hopnext hop along the shortest path towards R8. By applying the steps in <xreftarget="section-2.8"/>target="convert-section-2.8" format="default" sectionFormat="of" derivedContent="Section 2.8"/>, the outgoing label downloaded to R1's FIB corresponding to the global SID index8"8" is 1008 because the SRGB of R2is= [1000,5000] as shown inFigure 2.</t> <t><xref target="fig2" format="default" sectionFormat="of" derivedContent="Figure 2"/>.</t> <t pn="section-a.1-7"> Because the packet is IPv4, R1 applies the PUSH operation using the label value 1008 as specified in <xreftarget="section-2.10.1"/>.target="convert-section-2.10.1" format="default" sectionFormat="of" derivedContent="Section 2.10.1"/>. The resulting MPLS header will have the "S" bit <xreftarget="RFC3032"/>target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> set because it is followed directly by an IPv4 packet.</t><t><t pn="section-a.1-8"> The packet arrives at router R2. Becausethetop label 1008 corresponds to the IGP SID index "8", which is theprefix-SIDPrefix-SID attached to the prefix 192.0.2.8/32 owned bythe nodeNode R8,thenthe instruction associated with the SID is "forward the packet usingall ECMP/UCMPone of the ECMP interfacesand all ECMP/UCMP next-hop(s)or next hops along theshortest/useableshortest path(s) towards R8". Because R2 is not the penultimate hop, R2 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 in <xreftarget="section-2.10.1"/>.</t> <t>target="convert-section-2.10.1" format="default" sectionFormat="of" derivedContent="Section 2.10.1"/>.</t> <t pn="section-a.1-9"> R3 receives the packet with top label 1008. Becausethetop label 1008 corresponds to the IGP SID index "8", which is theprefix-SIDPrefix-SID attached to the prefix 192.0.2.8/32 owned bythe nodeNode R8,thenthe instruction associated with the SID is "send the packet usingallone of the ECMP interfaces andall next-hop(s)next hops along the shortest path towards R8". Because R3 is the penultimate hop, we assume that R3 performspenumtimatepenultimate hop popping, which corresponds to the NEXToperation, then sendsoperation; the packet is then sent to R8. The NEXT operation results in popping the outer label and sending the packet as a pure IPv4 packet to R8.</t><t><t pn="section-a.1-10"> In conclusion, the path followed by P1 is R1-R2--R3-R8. TheECMP-ECMP awareness ensures that the trafficbeis load-shared between any ECMPpath,path; in thiscasecase, it's the two links between R2 and R3.</t> </section> <sectiontitle="Incominganchor="convert-section-a.2" numbered="true" toc="include" removeInRFC="false" pn="section-a.2"> <name slugifiedName="name-incoming-label-collision-ex">Incoming Label CollisionExamples" anchor="section-a.2"><t>Examples</name> <t pn="section-a.2-1"> This sectiondescribes fewoutlines several examples to illustrate the handling of label collision described in <xreftarget="section-2.5"/>.</t> <t>target="convert-section-2.5" format="default" sectionFormat="of" derivedContent="Section 2.5"/>.</t> <t pn="section-a.2-2"> For the examples in this section, we assume that Node A has the following:</t><t><list style="symbols"><t>OSPF<ul spacing="normal" bare="false" empty="false" pn="section-a.2-3"> <li pn="section-a.2-3.1">OSPF default admin distance forimplementation=50</t> <t>ISISimplementation=50</li> <li pn="section-a.2-3.2">IS-IS default admin distance forimplementation=60</t> </list> </t>implementation=60</li> </ul> <sectiontitle="Example 1" anchor="section-a.2.1"><t> Illustration ofanchor="convert-section-a.2.1" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.1"> <name slugifiedName="name-example-1">Example 1</name> <t pn="section-a.2.1-1"> The following example illustrates incoming label collision resolution for the same FEC type using MCC administrative distance.</t><t><t pn="section-a.2.1-2"> FEC1:</t><figure><artwork><![CDATA[ o<t pn="section-a.2.1-3"> Node A receives an OSPFprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 198.51.100.5/32 withindex=5 oindex=5. Assuming that OSPF SRGB onnodeNode A =[1000,1999] o Incoming label=1005 ]]></artwork> </figure> <t>[1000,1999], the incoming label is 1005. </t> <t pn="section-a.2.1-4"> FEC2:</t><t><list style="symbols"><t>ISIS prefix SID advertisement<t pn="section-a.2.1-5"> IS-IS on Node A receives a Prefix-SID Advertisement fromnodeNode C for 203.0.113.105/32 withindex=5</t> <t>ISISindex=5. Assuming that IS-IS SRGB onnodeNode A =[1000,1999]</t> <t>Incoming label=1005</t> </list>[1000,1999], the incoming label is 1005. </t><t><t pn="section-a.2.1-6"> FEC1 and FEC2 both use dynamic SID assignment. Since neitherofthe FEC types is SR Policy,of the FECs are of type 'SR Policy', we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins.</t> </section> <sectiontitle="Example 2" anchor="section-a.2.2"><t> Illustration ofanchor="convert-section-a.2.2" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.2"> <name slugifiedName="name-example-2">Example 2</name> <t pn="section-a.2.2-1"> The following example Illustrates incoming label collision resolution for different FEC types using the MCC administrative distance.</t><t><t pn="section-a.2.2-2"> FEC1:</t><t><list style="symbols"><t>Node<t pn="section-a.2.2-3"> Node A receives an OSPFprefix sid advertisementPrefix-SID Advertisement fromnodeNode B for 198.51.100.6/32 withindex=6</t> <t>OSPFindex=6. Assuming that OSPF SRGB onnodeNode A =[1000,1999]</t> <t>Hence[1000,1999], the incoming label onnodeNode A corresponding to 198.51.100.6/32 is1006</t> </list>1006. </t><t><t pn="section-a.2.2-4"> FEC2:</t><t> ISIS<t pn="section-a.2.2-5"> IS-IS onnodeNode A assignsthelabel 1006 to the globally significantadj-SID (I.e.Adj-SID (i.e., whenadvertisedadvertised, the"L" flagL-Flag is clear in theadj-SIDAdj-SID sub-TLV as described in<xref target="I-D.ietf-isis-segment-routing-extensions"/>) towards one of its neighbors. Hence<xref target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>). Hence, the incoming label corresponding to thisadj-SIDAdj-SID is 1006. Assume Node A allocates thisadj-SIDAdj-SID dynamically, and it may differ across router reboots.</t><t><t pn="section-a.2.2-6"> FEC1 and FEC2 both use dynamic SID assignment. Since neither of theFEC types is SR Policy,FECs are of type 'SR Policy', we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins.</t> </section> <sectiontitle="Example 3" anchor="section-a.2.3"><t> Illustration ofanchor="convert-section-a.2.3" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.3"> <name slugifiedName="name-example-3">Example 3</name> <t pn="section-a.2.3-1"> The following example illustrates incoming label collision resolution based on preferring static over dynamic SIDassignment</t> <t>assignment.</t> <t pn="section-a.2.3-2"> FEC1:</t><t><t pn="section-a.2.3-3"> OSPF onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 198.51.100.7/32 with index=7. Assuming that the OSPF SRGB onnodeNode Ais= [1000,1999],thenthe incoming label corresponding to 198.51.100.7/32 is1007</t> <t>1007.</t> <t pn="section-a.2.3-4"> FEC2:</t><t><t pn="section-a.2.3-5"> The operator onnodeNode A configuresISISIS-IS onnodeNode A to assignthelabel 1007 to the globally significantadj-SID (I.e.Adj-SID (i.e., whenadvertisedadvertised, the"L" flagL-Flag is clear in theadj-SIDAdj-SID sub-TLV as described in <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>) towards one of its neighbor advertisement from node A with label=1007</t> <t>target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>).</t> <t pn="section-a.2.3-6"> Node A assigns thisadj-SIDAdj-SID explicitly via configuration, so theadj- SIDAdj-SID survives router reboots.</t><t><t pn="section-a.2.3-7"> FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID assignment. So FEC2 wins.</t> </section> <sectiontitle="Example 4" anchor="section-a.2.4"><t> Illustration ofanchor="convert-section-a.2.4" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.4"> <name slugifiedName="name-example-4">Example 4</name> <t pn="section-a.2.4-1"> The following example illustrates incoming label collision resolution using FEC type default administrativedistance</t> <t>distance.</t> <t pn="section-a.2.4-2"> FEC1:</t><t><t pn="section-a.2.4-3"> OSPF onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 198.51.100.8/32 with index=8. Assuming that OSPF SRGB onnodeNode A = [1000,1999], the incoming label corresponding to 198.51.100.8/32 is 1008.</t><t><t pn="section-a.2.4-4"> FEC2:</t><t><t pn="section-a.2.4-5"> Suppose the SR PolicyadvertisementAdvertisement from the controller tonodeNode A for the policy identified by (Endpoint = 192.0.2.208, color = 100)and consistingthat consists ofSID-List = <S1,SID-List=<S1, S2> assigns the globally significant Binding-SID label1008</t> <t>1008.</t> <t pn="section-a.2.4-6"> From the point of view ofnodeNode A, FEC1 and FEC2 both use dynamic SID assignment. Based on the default administrative distance outlined in <xreftarget="section-2.5.1"/>,target="convert-section-2.5.1" format="default" sectionFormat="of" derivedContent="Section 2.5.1"/>, thebindingBinding SID has a higher administrative distance than theprefix-SID and hencePrefix-SID; hence, FEC1 wins.</t> </section> <sectiontitle="Example 5" anchor="section-a.2.5"><t> Illustration ofanchor="convert-section-a.2.5" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.5"> <name slugifiedName="name-example-5">Example 5</name> <t pn="section-a.2.5-1"> The following example illustrates incoming label collision resolution based on FEC typepreference</t> <t>preference.</t> <t pn="section-a.2.5-2"> FEC1:</t><t> ISIS<t pn="section-a.2.5-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.110/32 with index=10. Assuming that theISISIS-IS SRGB onnodeNode Ais= [1000,1999],thenthe incoming label corresponding to 203.0.113.110/32 is 1010.</t><t><t pn="section-a.2.5-4"> FEC2:</t><t> ISIS<t pn="section-a.2.5-5"> IS-IS onnodeNode A assignsthelabel 1010 to the globally significantadj-SID (I.e.Adj-SID (i.e., whenadvertisedadvertised, the"L" flagL-Flag is clear in theadj-SIDAdj-SID sub-TLV as described in <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>) towards one of its neighbors).</t> <t>target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>).</t> <t pn="section-a.2.5-6"> Node A allocates thisadj-SIDAdj-SID dynamically, and it may differ across router reboots.HenceHence, both FEC1 and FEC2 both use dynamic SID assignment.</t><t><t pn="section-a.2.5-7"> Since both FECs are from the same MCC, they have the same default admin distance. So we compare the FEC typecode-point.codepoints. FEC1 has FEC typecode-point=120,codepoint=120, while FEC2 has FEC typecode-point=130.codepoint=130. Therefore, FEC1 wins.</t> </section> <sectiontitle="Example 6" anchor="section-a.2.6"><t> Illustration ofanchor="convert-section-a.2.6" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.6"> <name slugifiedName="name-example-6">Example 6</name> <t pn="section-a.2.6-1"> The following example illustrates incoming label collision resolution based on address family preference.</t><t><t pn="section-a.2.6-2"> FEC1:</t><t> ISIS<t pn="section-a.2.6-3"> IS-IS onnodeNode A receivesprefix SID advertisementa Prefix-SID Advertisement fromnodeNode B for 203.0.113.111/32 withindex 11.index=11. Assuming that theISISIS-IS SRGB onnodeNode Ais= [1000,1999], the incoming label onnodeNode A for 203.0.113.111/32 is 1011.</t><t><t pn="section-a.2.6-4"> FEC2:</t><t> ISIS<t pn="section-a.2.6-5"> IS-IS onnodeNode Aprefix SID advertisementreceives a Prefix-SID Advertisement fromnodeNode C for 2001:DB8:1000::11/128 with index=11. Assuming that theISISIS-IS SRGB onnodeNode Ais= [1000,1999], the incoming label onnodeNode A for 2001:DB8:1000::11/128 is1011</t> <t>1011.</t> <t pn="section-a.2.6-6"> 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 compare the FEC typecode-point.codepoints. Both FECs have FEC typecode-point=120.codepoint=120. So we compare the address family. Since IPv4 is preferred over IPv6, FEC1 wins.</t> </section> <sectiontitle="Example 7" anchor="section-a.2.7"><t> Illustrationanchor="convert-section-a.2.7" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.7"> <name slugifiedName="name-example-7">Example 7</name> <t pn="section-a.2.7-1"> The following example illustrates incoming label collision resolution based on prefix length.</t><t><t pn="section-a.2.7-2"> FEC1:</t><t> ISIS<t pn="section-a.2.7-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.112/32 withindex 12.index=12. Assuming thatISISIS-IS SRGB onnodeNode Ais= [1000,1999], the incoming label for 203.0.113.112/32 onnodeNode A is 1012.</t><t><t pn="section-a.2.7-4"> FEC2:</t><t> ISIS<t pn="section-a.2.7-5"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode C for 203.0.113.128/30 withindex 12.index=12. Assuming that theISISIS-IS SRGB onnodeNode Ais= [1000,1999],thenthe incoming label for 203.0.113.128/30 onnodeNode A is1012</t> <t>1012.</t> <t pn="section-a.2.7-6"> 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 compare the FEC typecode-point.codepoints. Both FECs have FEC typecode-point=120.codepoint=120. So we compare the address family. Both are a part of the IPv4 address family, so we compare the prefix length. FEC1 has prefix length=32, and FEC2 has prefix length=30, so FEC2 wins.</t> </section> <sectiontitle="Example 8" anchor="section-a.2.8"><t> Illustration ofanchor="convert-section-a.2.8" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.8"> <name slugifiedName="name-example-8">Example 8</name> <t pn="section-a.2.8-1"> The following example illustrates incoming label collision resolution based on the numerical value of the FECs.</t><t><t pn="section-a.2.8-2"> FEC1:</t><t> ISIS<t pn="section-a.2.8-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.113/32 withindex 13.index=13. Assuming thatISISIS-IS SRGB onnodeNode Ais= [1000,1999],thenthe incoming label for 203.0.113.113/32 onnodeNode A is1013</t> <t>1013.</t> <t pn="section-a.2.8-4"> FEC2:</t><t> ISIS<t pn="section-a.2.8-5"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode C for 203.0.113.213/32 withindex 13.index=13. Assuming thatISISIS-IS SRGB onnodeNode Ais= [1000,1999],thenthe incoming label for 203.0.113.213/32 onnodeNode A is1013</t> <t>1013.</t> <t pn="section-a.2.8-6"> 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 compare the FEC typecode-point.codepoints. Both FECs have FEC typecode-point=120.codepoint=120. So we compare the address family. Both are a part of the IPv4 address family, so we compare the prefix length. Prefix lengths are the same, so we compare the prefix. FEC1 has the lower prefix, so FEC1 wins.</t> </section> <sectiontitle="Example 9" anchor="section-a.2.9"><t> Illustration ofanchor="convert-section-a.2.9" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.9"> <name slugifiedName="name-example-9">Example 9</name> <t pn="section-a.2.9-1"> The following example illustrates incoming label collision resolution basedon routing instanceon the Routing Instance ID.</t><t><t pn="section-a.2.9-2"> FEC1:</t><t> ISIS<t pn="section-a.2.9-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.114/32 withindex 14.index=14. Assume that thisISISIS-IS instance onnodeNode A hastheRouting Instance ID = 1000 and SRGB = [1000,1999].HenceHence, the incoming label for 203.0.113.114/32 onnodeNode A is1014</t> <t>1014.</t> <t pn="section-a.2.9-4"> FEC2:</t><t> ISIS<t pn="section-a.2.9-5"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode C for 203.0.113.114/32 with index=14. Assume that this is another instance ofISISIS-IS onnodeNode Awith a different routingbut Routing Instance ID = 2000but the sameis different and SRGB[1000,1999]. Hence= [1000,1999] is the same. Hence, the incoming label for 203.0.113.114/32 onnodeNode A1014</t> <t>is 1014.</t> <t pn="section-a.2.9-6"> These two FECs match all the way through the prefix length and prefix. So the Routing Instance ID breaks the tie,withand FEC1winning.</t>wins.</t> </section> <sectiontitle="Example 10" anchor="section-a.2.10"><t> Illustration ofanchor="convert-section-a.2.10" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.10"> <name slugifiedName="name-example-10">Example 10</name> <t pn="section-a.2.10-1"> The following example illustrates incoming label collision resolution based on the topology ID.</t><t><t pn="section-a.2.10-2"> FEC1:</t><t> ISIS<t pn="section-a.2.10-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.115/32 with index=15. Assume that thisISISIS-IS instance onnodeNode A has Routing Instance ID = 1000. Assume that the prefix advertisement of 203.0.113.115/32 was received inISISthe IS-IS Multi-topology advertisement with ID = 50. If theISISIS-IS SRGB for this routing instance onnodeNode Ais= [1000,1999], then the incoming label of 203.0.113.115/32 for topology 50 onnodeNode A is1015</t> <t>1015.</t> <t pn="section-a.2.10-4"> FEC2:</t><t> ISIS<t pn="section-a.2.10-5"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode C for 203.0.113.115/32 withindex 15.index=15. Assume that itishas the sameroutingRouting Instance ID =10001000, but 203.0.113.115/32 was advertised witha different ISISIS-IS Multi-topology ID =40.40, which is different. If theISISIS-IS SRGB onnodeNode Ais= [1000,1999], then the incoming label of 203.0.113.115/32 for topology 40 onnodeNode A is also1015</t> <t> These1015.</t> <t pn="section-a.2.10-6"> Since these two FECs match all the way through the prefix length, prefix, and Routing InstanceID. WeID, we compareISISthe IS-IS Multi-topology ID, so FEC2 wins.</t> </section> <sectiontitle="Example 11" anchor="section-a.2.11"><t> Illustration ofanchor="convert-section-a.2.11" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.11"> <name slugifiedName="name-example-11">Example 11</name> <t pn="section-a.2.11-1"> The following example illustrates incoming label collision for resolution based on the algorithm ID.</t><t><t pn="section-a.2.11-2"> FEC1:</t><t> ISIS<t pn="section-a.2.11-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.116/32 withindex=16index=16. Assume thatISISIS-IS onnodeNode A has Routing Instance ID = 1000. Assume thatnodeNode B advertised 203.0.113.116/32 withISISIS-IS Multi-topology ID = 50 and SR algorithm = 0. Assume that theISISIS-IS SRGB onnodeNode A = [1000,1999].HenceHence, the incoming label corresponding to this advertisement of 203.0.113.116/32 is 1016.</t><t><t pn="section-a.2.11-4"> FEC2:</t><t> ISIS<t pn="section-a.2.11-5"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode C for 203.0.113.116/32 with index=16. Assume that it is the sameISISIS-IS instance onnodeNode A with Routing Instance ID = 1000. Also assume thatnodeNode C advertised 203.0.113.116/32 withISISIS-IS Multi-topology ID = 50 but with SR algorithm = 22. Since it is the same routing instance, the SRGB onnodeNode A = [1000,1999].HenceHence, the incoming label corresponding to this advertisement of 203.0.113.116/32 bynodeNode C is also 1016.</t><t> These<t pn="section-a.2.11-6"> Since these two FECs match all the way through in terms of the prefix length, prefix,andRouting Instance ID, and Multi-topologyID. WeID, we compare the SR algorithmID,IDs, so FEC1 wins.</t> </section> <sectiontitle="Example 12" anchor="section-a.2.12"><t> Illustration ofanchor="convert-section-a.2.12" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.12"> <name slugifiedName="name-example-12">Example 12</name> <t pn="section-a.2.12-1"> The following example illustrates incoming label collision resolution based on the FEC numericalvalue andvalue, independent of how the SID is assigned to the colliding FECs.</t><t><t pn="section-a.2.12-2"> FEC1:</t><t> ISIS<t pn="section-a.2.12-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.117/32 withindex 17.index=17. Assume that theISISIS-IS SRGB onnodeNode Ais [1000,1999], then= [1000,1999]; thus, the incoming label is1017</t> <t>1017.</t> <t pn="section-a.2.12-4"> FEC2:</t><t><t pn="section-a.2.12-5"> Suppose there is anISIS mapping server advertisement (SID/LabelIS-IS Mapping Server Advertisement (SID / Label Binding TLV) fromnodeNode D that hasRangerange = 100 andPrefixprefix = 203.0.113.1/32. Suppose thismapping server advertisementMapping Server Advertisement generates 100 mappings, one of which maps 203.0.113.17/32 toindex 17.index=17. Assuming that it is the sameISISIS-IS instance,thenthe SRGBis= [1000,1999] and hence the incoming label for 1017.</t><t> The fact that<t pn="section-a.2.12-6"> Even though FEC1 comes from a normalprefix SID advertisementPrefix-SID Advertisement and FEC2 is generated from amapping server advertisementMapping Server Advertisement, it is not used as atie-breakingtiebreaking parameter. Both FECs use dynamic SID assignment, are from the same MCC, and have the same FEC typecode-point=120.codepoint=120. Their prefix lengths are the same as well. FEC2 wins based on its lower numerical prefix value, since 203.0.113.17 is less than 203.0.113.117.</t> </section> <sectiontitle="Example 13" anchor="section-a.2.13"><t> Illustration ofanchor="convert-section-a.2.13" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.13"> <name slugifiedName="name-example-13">Example 13</name> <t pn="section-a.2.13-1"> The following example illustrates incoming label collision resolution based on address familypreference</t> <t>preference.</t> <t pn="section-a.2.13-2"> FEC1:</t><t><t pn="section-a.2.13-3"> SR PolicyadvertisementAdvertisement from the controller tonodeNode A. Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1,S2>S2>, and the Binding-SIDlabel=1020</t> <t>label=1020.</t> <t pn="section-a.2.13-4"> FEC2:</t><figure><artwork><![CDATA[<t pn="section-a.2.13-5"> SR PolicyadvertisementAdvertisement from controller tonodeNode A. Endpoint address=192.0.2.60, color=100,SID-List=<S3, S4>SID-List=<S3, S4>, and the Binding-SIDlabel=1020 The FECs match through the tie-breaks up tolabel=1020.</t> <t pn="section-a.2.13-6">The FEC tiebreakers match, andincluding havingthey have the same FEC typecode-point=140.codepoint=140. Thus, FEC2 wins based on the IPv4 address family being preferred overIPv6. ]]></artwork> </figure>IPv6.</t> </section> <sectiontitle="Example 14" anchor="section-a.2.14"><t> Illustration ofanchor="convert-section-a.2.14" numbered="true" toc="include" removeInRFC="false" pn="section-a.2.14"> <name slugifiedName="name-example-14">Example 14</name> <t pn="section-a.2.14-1"> The following example illustrates incoming label resolution based on the numerical value of the policy endpoint.</t><t><t pn="section-a.2.14-2"> FEC1:</t><t><t pn="section-a.2.14-3"> SR PolicyadvertisementAdvertisement from the controller tonodeNode A. Endpoint address=192.0.2.70, color=100, SID-List=<S1,S2>S2>, and Binding-SIDlabel=1021</t> <t>label=1021.</t> <t pn="section-a.2.14-4"> FEC2:</t><t><t pn="section-a.2.14-5"> SR PolicyadvertisementAdvertisement from the controller tonode ANode A. Endpoint address=192.0.2.71, color=100, SID-List=<S3,S4>S4>, and Binding-SIDlabel=1021</t> <t>label=1021.</t> <t pn="section-a.2.14-6"> TheFECs match through the tie-breaks up toFEC tiebreakers match, andincluding havingthey have the same address family. Thus, FEC1 wins by having the lower numerical endpoint address value.</t> </section> </section> <sectiontitle="Examplesanchor="convert-section-a.3" numbered="true" toc="include" removeInRFC="false" pn="section-a.3"> <name slugifiedName="name-examples-for-the-effect-of-">Examples for the Effect of Incoming Label Collision on an OutgoingLabel" anchor="section-a.3"><t>Label</name> <t pn="section-a.3-1"> This section presents examples to illustrate the effect of incoming label collision on the selection of the outgoing label as described in <xreftarget="section-2.6"/>.</t> <section title="Example 1" anchor="section-a.3.1"><t> Illustration oftarget="convert-section-2.6" format="default" sectionFormat="of" derivedContent="Section 2.6"/>.</t> <section anchor="convert-section-a.3.1" numbered="true" toc="include" removeInRFC="false" pn="section-a.3.1"> <name slugifiedName="name-example-1-2">Example 1</name> <t pn="section-a.3.1-1"> The following example illustrates the effect of incoming label resolution on the outgoinglabel</t> <t>label.</t> <t pn="section-a.3.1-2"> FEC1:</t><t> ISIS<t pn="section-a.3.1-3"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode B for 203.0.113.122/32 withindex 22.index=22. Assuming that theISISIS-IS SRGB onnodeNode Ais [1000,1999]= [1000,1999], the corresponding incoming label is 1022.</t><t><t pn="section-a.3.1-4"> FEC2:</t><t> ISIS<t pn="section-a.3.1-5"> IS-IS onnodeNode A receives aprefix SID advertisementPrefix-SID Advertisement fromnodeNode C for 203.0.113.222/32 withindex=22index=22. Assuming that theISISIS-IS SRGB onnodeNode Ais [1000,1999]= [1000,1999], the corresponding incoming label is 1022.</t><t><t pn="section-a.3.1-6"> FEC1 wins based on the lowest numerical prefix value. This means thatnodeNode A installs a transit MPLS forwarding entry toSWAPswap incoming label1022,1022 with outgoing label N and to use outgoing interface I. N is determined by the index associated with FEC1(index 22)(index=22) and the SRGB advertised by the next-hop node on the shortest path to reach 203.0.113.122/32.</t><t><t pn="section-a.3.1-7"> Node A will generally also install an imposition MPLS forwarding entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interface I.</t><t><t pn="section-a.3.1-8"> The rule in <xreftarget="section-2.6"/>target="convert-section-2.6" format="default" sectionFormat="of" derivedContent="Section 2.6"/> meansnodeNode AMUST NOT<bcp14>MUST NOT</bcp14> install an ingress MPLS forwarding entry corresponding to FEC2 (the losing FEC, which would be for prefix 203.0.113.222/32).</t> </section> <sectiontitle="Example 2" anchor="section-a.3.2"><t> Illustration ofanchor="convert-section-a.3.2" numbered="true" toc="include" removeInRFC="false" pn="section-a.3.2"> <name slugifiedName="name-example-2-2">Example 2</name> <t pn="section-a.3.2-1"> The following example illustrates the effect of incoming label collision resolution on outgoing label programming onnode A</t> <t>Node A.</t> <t pn="section-a.3.2-2"> FEC1:</t><t><list style="symbols"><t>SR<t pn="section-a.3.2-3">SR PolicyadvertisementAdvertisement from the controller tonode A</t> <t>EndpointNode A. Endpoint address=192.0.2.80, color=100, SID-List=<S1,S2></t> <t>Binding-SID label=1023</t> </list>S2>, and Binding-SID label=1023. </t><t><t pn="section-a.3.2-4"> FEC2:</t><t><list style="symbols"><t>SR<t pn="section-a.3.2-5"> SR PolicyadvertisementAdvertisement from controller tonode A</t> <t>EndpointNode A. Endpoint address=192.0.2.81, color=100, SID-List=<S3,S4></t> <t>Binding-SID label=1023</t> </list>S4>, and Binding-SID label=1023. </t><t><t pn="section-a.3.2-6"> FEC1 wins by having the lower numerical endpoint address value. This means thatnodeNode A installs a transit MPLS forwarding entry toSWAPswap incominglabel=1023,label=1023 with outgoinglabelslabels, and the outgoing interface is determined by the SID-List for FEC1.</t><t><t pn="section-a.3.2-7"> In this example, we assume thatnodeNode A receives two BGP/VPN routes:</t><t><list style="symbols"><t>R1<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, BGPnext-hopnext hop = 192.0.2.80, andcolor=100,</t> <t>R2color=100</li> <li pn="section-a.3.2-8.2">R2 with VPN label=V2, BGPnext-hopnext hop = 192.0.2.81, andcolor=100,</t> </list> </t> <t>color=100</li> </ul> <t pn="section-a.3.2-9"> We also assume that Node A has a BGP policywhichthat matchesoncolor=100thatand allowsthatits usage asSLAService Level Agreement (SLA) steering information. In this case,nodeNode A will install a VPN route with label stack = <S1,S2,V1> (corresponding to FEC1).</t><t><t pn="section-a.3.2-10"> The rule described insection 2.6<xref target="convert-section-2.6" format="default" sectionFormat="of" derivedContent="Section 2.6"/> means thatnodeNode AMUST NOT<bcp14>MUST NOT</bcp14> install a VPN route with label stack = <S3,S4,V1> (corresponding to FEC2.)</t> </section> </section> </section> <section anchor="convert-section-7" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t pn="section-appendix.b-1"> The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on this document.</t> </section> <section anchor="convert-section-6" numbered="false" toc="include" removeInRFC="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="Bashandy"> <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>