<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

]> version='1.0' encoding='utf-8'?>
<rfc  number="8661" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="yes" consensus="true" docName="draft-ietf-spring-segment-routing-ldp-interop-15" indexInclude="true" ipr="trust200902" number="8661" prepTime="2019-12-04T20:41:37" scripts="Common,Latin" sortRefs="true" submissionType="IETF" ipr="trust200902">
  <?rfc compact="yes"?>

  <?rfc text-list-symbols="-o*+"?>

  <?rfc subcompact="no"?>

  <?rfc sortrefs="yes"?>

  <?rfc symrefs="yes"?>

  <?rfc strict="yes"?>

  <?rfc toc="yes"?> symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8661" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Segment Routing and LDP">Segment Routing MPLS Interworking with LDP</title>
    <seriesInfo name="RFC" value="8661" stream="IETF"/>
    <author fullname="Ahmed Bashandy" initials="A." role="editor" surname="Bashandy">
      <organization>Individual</organization>
      <organization showOnFrontPage="true">Individual</organization>
      <address>
        <postal>
          <street>United States of America</street>
        </postal>
        <email>abashandy.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." role="editor" surname="Filsfils">
      <organization>Cisco
      <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>Cisco Systems, Inc.</organization>
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>Italy</street>
        </postal>
        <email>stefano@previdi.net</email>
      </address>
    </author>
    <author fullname="Bruno Decraene" initials="B." surname="Decraene">
      <organization>Orange</organization>
      <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>
      <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>
    <date month="September" month="12" year="2019"/>

    <abstract>
      <t>A
    <keyword>SR-MPLS</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">A Segment Routing (SR) node steers a packet through a controlled set
       of instructions, called segments, by prepending the packet with an SR
       header. A segment can represent any instruction, topological or
      service based. SR allows enforcing a flow through any topological path
      while maintaining per-flow state only at the ingress node to the SR
      domain.</t>

      <t>The
      <t pn="section-abstract-2">The Segment Routing architecture can be directly applied to the MPLS
      data plane with no change in the forwarding plane. This document
      describes how Segment Routing MPLS operates in a network where LDP is
      deployed and in the case where SR-capable and non-SR-capable nodes
      coexist.</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/rfc8661" 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-sr-ldp-ships-in-the-night-c">SR-LDP Ships-in-the-Night Coexistence</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="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-mpls2mpls-mpls2ip-and-ip2mp">MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sr-and-ldp-interworking">SR and LDP Interworking</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ldp-to-sr">LDP to SR</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.1.2">
                  <li pn="section-toc.1-1.3.2.1.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ldp-to-sr-behavior">LDP to SR Behavior</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sr-to-ldp">SR to LDP</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-segment-routing-mapping-ser">Segment Routing Mapping Server (SRMS)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sr-to-ldp-behavior">SR to LDP Behavior</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interoperability-of-multipl">Interoperability of Multiple SRMSes and Prefix-SID Advertisements</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sr-ldp-interworking-use-cas">SR-LDP Interworking Use Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sr-protection-of-ldp-based-">SR Protection of LDP-Based Traffic</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eliminating-targeted-ldp-se">Eliminating Targeted LDP Sessions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guaranteed-frr-coverage">Guaranteed FRR Coverage</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-inter-as-option-c-carriers-">Inter-AS Option C, Carrier's Carrier</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</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-sr-and-ldp-coexistence">SR and LDP Coexistence</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-plane-verification">Data-Plane Verification</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref 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.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-migration-from-ldp-to-sr">Migration from LDP to SR</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref 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.11">
            <t keepWithNext="true" pn="section-toc.1-1.11.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.12">
            <t keepWithNext="true" pn="section-toc.1-1.12.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>
    <section anchor="section-1" title="Introduction">
      <t>Segment anchor="sec-1" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">Segment Routing, as described in <xref
      target="RFC8402"/>, target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, can be used on top of the
      MPLS data plane without any modification as described in <xref
      target="RFC8660"/>.</t>

      <t>Segment target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>.</t>
      <t pn="section-1-2">Segment Routing control plane can coexist with current label
      distribution protocols such as LDP <xref target="RFC5036"/>.</t>

      <t>This target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/>.</t>
      <t pn="section-1-3">This document outlines the mechanisms through which SR interworks
      with LDP in cases where a mix of SR-capable and non-SR-capable routers
      coexist within the same network and more precisely in the same routing
      domain.</t>

      <t><xref target="section-2"/>
      <t pn="section-1-4"><xref target="sec-2" format="default" sectionFormat="of" derivedContent="Section 2"/> describes the coexistence of SR with
      other MPLS control-plane protocols. <xref target="section-4"/> target="sec-4" format="default" sectionFormat="of" derivedContent="Section 3"/> documents
      the interworking between SR and LDP in the case of nonhomogeneous
      deployment. <xref target="section-5"/> target="sec-5" format="default" sectionFormat="of" derivedContent="Section 4"/> describes how a partial SR
      deployment can be used to provide SR benefits to LDP-based traffic
      including a possible application of SR in the context of interdomain
      MPLS use cases. <xref target="Appendix-A"/> target="Appendix-A" format="default" sectionFormat="of" derivedContent="Appendix A"/> documents a method to
      migrate from LDP to SR-based MPLS tunneling.</t>

      <t>Typically,
      <t pn="section-1-5">Typically, an implementation will allow an operator to select
      (through configuration) which of the described modes of SR and LDP
      coexistence to use.</t>
      <section title="Requirements Language">

        <t> 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 in BCP&nbsp;14 BCP 14 <xref target="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>
    <section anchor="section-2" title="SR/LDP anchor="sec-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-sr-ldp-ships-in-the-night-c">SR-LDP Ships-in-the-Night Coexistence">
      <t>"MPLS Coexistence</name>
      <t pn="section-2-1">"MPLS Control-Plane Client (MCC)" refers to any control-plane
      protocol installing forwarding entries in the MPLS data plane. SR, LDP
      <xref target="RFC5036"/>, target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/>, RSVP-TE <xref target="RFC3209"/>, target="RFC3209" format="default" sectionFormat="of" derivedContent="RFC3209"/>, BGP <xref
      target="RFC8277"/>, target="RFC8277" format="default" sectionFormat="of" derivedContent="RFC8277"/>, etc., are examples of MCCs.</t>

      <t>An
      <t pn="section-2-2">An MCC, operating at node Node N, must ensure that the incoming label it
      installs in the MPLS data plane of node Node N has been uniquely allocated to
      itself.</t>

      <t>Segment
      <t pn="section-2-3">Segment Routing makes use of the Segment Routing Global Block (SRGB,
      as defined in <xref target="RFC8402"/>) target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>) for the
      label allocation. The use of the SRGB allows SR to coexist with any
      other MCC.</t>

      <t>This
      <t pn="section-2-4">This is clearly the case for the adjacency segment: it is a local
      label allocated by the label manager, as is the case for for any MCC.</t>

      <t>This
      <t pn="section-2-5">This is clearly the case for the prefix segment: the label manager
      allocates the SRGB set of labels to the SR MCC client, and the operator
      ensures the unique allocation of each global prefix segment or label
      within the allocated SRGB set.</t>

      <t>Note
      <t pn="section-2-6">Note that this static label-allocation capability of the label
      manager has existed for many years across several vendors and is
      therefore not new. Furthermore, note that the label manager's ability to
      statically allocate a range of labels to a specific application is not
      new either. This is required for MPLS-TP operation. In this case, the
      range is reserved by the label manager, and it is the MPLS-TP <xref
      target="RFC5960"/> target="RFC5960" format="default" sectionFormat="of" derivedContent="RFC5960"/> Network Management System (acting as an MCC) that ensures the unique
      allocation of any label within the allocated range and the creation of
      the related MPLS forwarding entry.</t>

      <t><list hangIndent="-1" style="hanging">
      <t
          hangText="Let pn="section-2-7">Let us illustrate an example of ship-in-the-night (SIN) coexistence."><vspace
          blankLines="0"/></t>
        </list></t> coexistence.
</t>
      <figure anchor="ref-sin-coexistence" title="SIN Coexistence">
        <artwork><![CDATA[ align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-sin-coexistence">SIN Coexistence</name>
        <artwork name="" type="" align="left" alt="" pn="section-2-8.1">
                           PE2          PE4
                             \          /
                       PE1----A----B---C---PE3
]]></artwork>
</artwork>
      </figure>

      <t>The
      <t pn="section-2-9">The EVEN VPN service is supported by PE2 and PE4 while the ODD VPN
      service is supported by PE1 and PE3. The operator wants to tunnel the
      ODD service via LDP and the EVEN service via SR.</t>

      <t><list hangIndent="3" style="hanging">
      <t hangText="This pn="section-2-10">This can be achieved in the following manner:"><vspace
          blankLines="1"/> The manner:
</t>
      <ul bare="false" empty="false" spacing="normal" pn="section-2-11">
        <li pn="section-2-11.1">The operator configures PE1, PE2, PE3, and PE4 with respective loopbacks
192.0.2.201/32, 192.0.2.202/32, 192.0.2.203/32, and 192.0.2.204/32. These PEs
advertised their VPN routes with next-hop next hop set on their respective loopback
address. <vspace
          blankLines="1"/> The
</li>
        <li pn="section-2-11.2">The operator configures A, B, C with respective loopbacks 192.0.2.1/32,
192.0.2.2/32, 192.0.2.3/32. <vspace
          blankLines="1"/> The
</li>
        <li pn="section-2-11.3">The operator configures PE2, A, B, C, and PE4 with SRGB [100, 300]. <vspace blankLines="1"/> The
</li>
        <li pn="section-2-11.4">The operator attaches the respective Node Segment Identifiers (Node-SIDs, (Node SIDs,
as defined in <xref
          target="RFC8402"/>), target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>), 202, 101, 102, 103,
and 204, to the loopbacks of nodes PE2, A, B, C, and PE4. The Node-SIDs Node SIDs are
configured to request Penultimate Hop Popping. <vspace
          blankLines="1"/> PE1,
</li>
        <li pn="section-2-11.5">PE1, A, B, C, and PE3 are LDP capable. <vspace
          blankLines="1"/> PE1
</li>
        <li pn="section-2-11.6">PE1 and PE3 are not SR capable.</t>
        </list></t>

      <t>PE3 capable.
</li>
      </ul>
      <t pn="section-2-12">PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN
      label 10001.</t>

      <t>From
      <t pn="section-2-13">From an LDP viewpoint, PE1 received an LDP label binding (1037) for a
      forwarding equivalence class
      Forwarding Equivalence Class (FEC) 192.0.2.203/32 from its next-hop A; A
      received an LDP label binding (2048) for that FEC from its next-hop B; B
      received an LDP label binding (3059) for that FEC from its next-hop C;
      and C received implicit-null implicit NULL LDP binding from its next-hop PE3.</t>

      <t>As
      <t pn="section-2-14">As a result, PE1 sends its traffic to the ODD service route
      advertised by PE3 to next-hop A with two labels: the top label is 1037
      and the bottom label is 10001. Node A swaps 1037 with 2048 and forwards
      to B; B swaps 2048 with 3059 and forwards to C; C pops 3059 and forwards
      to PE3.</t>

      <t>PE4
      <t pn="section-2-15">PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN
      label 10002.</t>

      <t>From
      <t pn="section-2-16">From an SR viewpoint, PE2 maps the IGP route 192.0.2.204/32 onto
      Node-SID
      Node SID 204; node Node A swaps 204 with 204 and forwards to B; B swaps 204
      with 204 and forwards to C; and C pops 204 and forwards to PE4.</t>

      <t>As
      <t pn="section-2-17">As a result, PE2 sends its traffic to the VPN service route
      advertised by PE4 to next-hop A with two labels: the top label is 204
      and the bottom label is 10002. Node A swaps 204 with 204 and forwards to
      B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to
      PE4.</t>

      <t><list hangIndent="3" style="hanging">
      <t hangText="The pn="section-2-18">The two modes of MPLS tunneling coexist."><vspace
          blankLines="1"/> The coexist.
</t>
      <ul empty="false" bare="false" spacing="normal" pn="section-2-19">
        <li pn="section-2-19.1">The ODD service is tunneled from PE1 to PE3 through a continuous LDP LSP
traversing A, B, and C. <vspace blankLines="1"/>
          The
</li>
        <li pn="section-2-19.2">The EVEN service is tunneled from PE2 to PE4 through a continuous SR node
segment traversing A, B, and C.</t>
        </list></t> C.
</li>
      </ul>
      <section anchor="section-2.1"
               title="MPLS2MPLS, anchor="sec-2.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-mpls2mpls-mpls2ip-and-ip2mp">MPLS2MPLS, MPLS2IP, and IP2MPLS Coexistence">
        <t>MPLS2MPLS Coexistence</name>
        <t pn="section-2.1-1">MPLS2MPLS refers to the forwarding behavior where a router receives
        a labeled packet and switches it out as a labeled packet. Several
        MPLS2MPLS entries may be installed in the data plane for the same
        prefix.</t>

        <t><list hangIndent="3" style="hanging">
        <t
            hangText="Let pn="section-2.1-2">Let us examine A's MPLS forwarding table as an example:"><vspace
            blankLines="1"/> Incoming example:</t>
        <ul empty="true" bare="false" spacing="normal" pn="section-2.1-3">
          <li pn="section-2.1-3.1">
            <t pn="section-2.1-3.1.1">Incoming label: 1037</t>
          </list></t>

        <figure>
          <artwork><![CDATA[
       - outgoing
            <ul empty="false" bare="false" spacing="normal" pn="section-2.1-3.1.2">
              <li pn="section-2.1-3.1.2.1">Outgoing label: 2048
       - outgoing next-hop: B
       Note: this 2048</li>
              <li pn="section-2.1-3.1.2.2">Outgoing next hop: B</li>
            </ul>
            <t pn="section-2.1-3.1.3">Note: This entry is programmed by LDP for 192.0.2.203/32

   Incoming 192.0.2.203/32.</t>
          </li>
        </ul>
        <ul empty="true" bare="false" spacing="normal" pn="section-2.1-4">
          <li pn="section-2.1-4.1">
            <t pn="section-2.1-4.1.1">Incoming label: 203

       - outgoing 203</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-2.1-4.1.2">
              <li pn="section-2.1-4.1.2.1">Outgoing label: 203
       - outgoing next-hop: B
       Note: this 203</li>
              <li pn="section-2.1-4.1.2.2">Outgoing next hop: B</li>
            </ul>
            <t pn="section-2.1-4.1.3">Note: This entry is programmed by SR for 192.0.2.203/32
]]></artwork>
        </figure>

        <t>These 192.0.2.203/32.</t>
          </li>
        </ul>
        <t pn="section-2.1-5">These two entries can coexist because their incoming label is
        unique. The uniqueness is guaranteed by the label manager allocation
        rules.</t>

        <t>The
        <t pn="section-2.1-6">The same applies for the MPLS2IP forwarding entries. MPLS2IP is the
        forwarding behavior where a router receives a labeled IPv4/IPv6 packet
        with one label only, pops the label, and switches the packet out as
        IPv4/IPv6. For IP2MPLS coexistence, refer to <xref
        target="section-7.1"/>.</t> target="sec-7.1" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</t>
      </section>
    </section>
    <section anchor="section-4" title="SR anchor="sec-4" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-sr-and-ldp-interworking">SR and LDP Interworking">
      <t>This Interworking</name>
      <t pn="section-3-1">This section analyzes the case where SR is available in one part of
      the network and LDP is available in another part. It describes how a
      continuous MPLS tunnel can be built throughout the network.</t>
      <figure anchor="ref-sr-and-ldp-interworking"
              title="SR align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-sr-and-ldp-interworking-2">SR and LDP Interworking">
        <artwork><![CDATA[ Interworking</name>
        <artwork name="" type="" align="left" alt="" pn="section-3-2.1">
                          PE2            PE4
                            \            /
                     PE1----P5--P6--P7--P8---PE3
]]></artwork>

                     &lt;-----SR----&gt;
                               &lt;------LDP------&gt;
</artwork>
      </figure>

      <t><list hangIndent="3" style="hanging">
      <t hangText="Let pn="section-3-3">Let us analyze the following example:"><vspace
          blankLines="1"/> P6, example:
</t>
      <ul bare="false" empty="false" spacing="normal" pn="section-3-4">
        <li pn="section-3-4.1">P6, P7, P8, PE4, and PE3 are LDP capable. <vspace
          blankLines="1"/> PE1,
</li>
        <li pn="section-3-4.2">PE1, PE2, P5, and P6 are SR capable. PE1, PE2, P5, and P6 are configured
with SRGB (100, 200) and respectively with node segments 101, 102, 105, and 106. <vspace blankLines="1"/> A 106, respectively.
</li>
        <li pn="section-3-4.3">A service flow must be tunneled from PE1 to PE3 over a continuous MPLS
tunnel encapsulation and encapsulation; therefore, SR and LDP need to interwork.</t>
        </list></t>

      <t/> interwork.
</li>
      </ul>
      <section anchor="section-4.1" title="LDP anchor="sec-4.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-ldp-to-sr">LDP to SR">
        <t>In SR</name>
        <t pn="section-3.1-1">In this section, a right-to-left traffic flow is analyzed.</t>

        <t>PE3
        <t pn="section-3.1-2">PE3 has learned a service route whose next-hop next hop is PE1. PE3 has an
        LDP label binding from the next-hop P8 for the FEC "PE1". Therefore, PE3
        sends its service packet to P8 as per classic LDP behavior.</t>

        <t>P8
        <t pn="section-3.1-3">P8 has an LDP label binding from its next-hop P7 for the FEC "PE1"
        and therefore, P8 forwards to P7 as per classic LDP behavior.</t>

        <t>P7
        <t pn="section-3.1-4">P7 has an LDP label binding from its next-hop P6 for the FEC "PE1"
        and therefore, P7 forwards to P6 as per classic LDP behavior.</t>

        <t>P6
        <t pn="section-3.1-5">P6 does not have an LDP binding from its next-hop P5 for the FEC
        "PE1". However, P6 has an SR node segment to the IGP route "PE1".
        Hence, P6 forwards the packet to P5 and swaps its local LDP label for
        FEC "PE1" by the equivalent node segment (i.e., 101).</t>

        <t>P5
        <t pn="section-3.1-6">P5 pops 101 (assuming PE1 advertised its node segment 101 with the
        penultimate-pop flag set) and forwards to PE1.</t>

        <t>PE1
        <t pn="section-3.1-7">PE1 receives the tunneled packet and processes the service
        label.</t>

        <t>The
        <t pn="section-3.1-8">The end-to-end MPLS tunnel is built from by stitching an LDP LSP from PE3 to P6
        and the related node segment from P6 to PE1.</t>
        <section anchor="section-4.1.1" title="LDP anchor="sec-4.1.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.1.1">
          <name slugifiedName="name-ldp-to-sr-behavior">LDP to SR Behavior">
          <t>It Behavior</name>
          <t pn="section-3.1.1-1">It has to be noted that no additional signaling or state is
          required in order to provide interworking in the direction LDP to
          SR.</t>

          <t>An
          <t pn="section-3.1.1-2">An SR node having LDP neighbors MUST <bcp14>MUST</bcp14> create LDP bindings for each
          Prefix SID
          Prefix-SID learned in the SR domain by treating SR-learned labels as
          if they were learned through an LDP neighbor. In addition, for each
          FEC, the SR node stitches the incoming LDP label to the outgoing SR
          label. This has to be done in both LDP-independent and ordered label
          distribution control modes as defined in <xref
          target="RFC5036"/>.</t> target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/>.</t>
        </section>
      </section>
      <section anchor="section-4.2" title="SR anchor="sec-4.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-sr-to-ldp">SR to LDP">
        <t>In LDP</name>
        <t pn="section-3.2-1">In this section, the left-to-right traffic flow is analyzed.</t>

        <t>This
        <t pn="section-3.2-2">This section defines the Segment Routing Mapping Server (SRMS). The
        SRMS is an IGP node advertising mapping between Segment Identifiers
        (SID) and prefixes advertised by other IGP nodes. The SRMS uses a
        dedicated IGP extension (IS-IS, OSPFv2, and OSPFv3), which is protocol
        specific and defined in <xref
        target="RFC8665"/>, <xref
        target="RFC8666"/>, target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref
        target="RFC8667"/>.</t>

        <t>The target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>.</t>
        <t pn="section-3.2-3">The SRMS function of an SR-capable router allows distribution of
        mappings for prefixes not locally attached to the advertising router
        and therefore allows advertisement of mappings on behalf of
        non-SR-capable routers.</t>

        <t>The
        <t pn="section-3.2-4">The SRMS is a control-plane-only function that may be located
        anywhere in the IGP flooding scope. At least one SRMS server MUST <bcp14>MUST</bcp14>
        exist in a routing domain to advertise Prefix SIDs Prefix-SIDs on behalf of non&nbhy;SR non‑SR
        nodes, thereby allowing non-LDP routers to send and receive labeled
        traffic from LDP-only routers. Multiple SRMSes may be present in the
        same network (for redundancy). This implies that there are multiple
        ways a prefix-to-SID mapping can be advertised. Conflicts resulting
        from inconsistent advertisements are addressed by <xref
        target="RFC8660"/>.</t>

        <t>The target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>.</t>
        <t pn="section-3.2-5">The example depicted in <xref target="ref-sr-and-ldp-interworking"/> target="ref-sr-and-ldp-interworking" format="default" sectionFormat="of" derivedContent="Figure 2"/> assumes that the operator
        configures P5 to act as a Segment Routing Mapping Server (SRMS) and
        advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103),
        and (PE4, 104).</t>

        <t>The
        <t pn="section-3.2-6">The mappings advertised by one or more SRMSes result from local
        policy information configured by the operator.</t>

        <t>If
        <t pn="section-3.2-7">If PE3 had been SR capable, the operator would have configured PE3
        with node segment 103. Instead, as PE3 is not SR capable, the operator
        configures that policy at the SRMS and it is the latter that
        advertises the mapping.</t>

        <t>The mapping server advertisements
        <t pn="section-3.2-8">The Mapping Server Advertisements are only understood by SR-capable
        routers. The SR-capable routers install the related node segments in
        the MPLS data plane exactly like the node segments had been advertised
        by the nodes themselves.</t>

        <t>For
        <t pn="section-3.2-9">For example, PE1 installs the node segment 103 with next-hop P5
        exactly as if PE3 had advertised node segment 103.</t>

        <t>PE1
        <t pn="section-3.2-10">PE1 has a service route whose next-hop next hop is PE3. PE1 has a node
        segment for that IGP route: 103 with next-hop P5. Hence, PE1 sends its
        service packet to P5 with two labels: the bottom label is the service
        label and the top label is 103.</t>

        <t>P5
        <t pn="section-3.2-11">P5 swaps 103 for 103 and forwards to P6.</t>

        <t>P6's next-hop
        <t pn="section-3.2-12">P6's next hop for the IGP route "PE3" is not SR capable (P7 does
        not advertise the SR capability). However, P6 has an LDP label binding
        from that next-hop next hop for the same FEC (e.g., LDP label 1037). Hence, P6
        swaps 103 for 1037 and forwards to P7.</t>

        <t>P7
        <t pn="section-3.2-13">P7 swaps this label with the LDP label received from P8 and
        forwards to P8.</t>

        <t>P8
        <t pn="section-3.2-14">P8 pops the LDP label and forwards to PE3.</t>

        <t>PE3
        <t pn="section-3.2-15">PE3 receives the tunneled packet and processes the service
        label.</t>

        <t>The
        <t pn="section-3.2-16">The end-to-end MPLS tunnel is built from by stitching an SR node segment from
        PE1 to P6 and an LDP LSP from P6 to PE3.</t>

        <t>SR-mapping
        <t pn="section-3.2-17">SR-mapping advertisement for a given prefix provides no information
        about Penultimate Hop Popping. Other mechanisms, such as IGP-specific
        mechanisms (<xref target="RFC8665"/>,
        <xref target="RFC8666"/> and <xref
        target="RFC8667"/>), MAY 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"/>), <bcp14>MAY</bcp14> be
        used to determine the Penultimate Hop Popping in such case.</t>

        <t>Note:
        <aside pn="section-3.2-18">
          <t pn="section-3.2-18.1">Note: In the previous example, Penultimate Hop Popping is not
        performed at the SR/LDP SR-LDP border for segment 103 (PE3), because none of
        the routers in the SR domain are Penultimate Hop for segment 103. In
        this case, P6 requires the presence of the segment 103 such as to map
        it to the LDP label 1037.</t>
        </aside>
        <section anchor="section-4.2.1"
                 title="Segment anchor="sec-4.2.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-segment-routing-mapping-ser">Segment Routing Mapping Server (SRMS)">
          <t>This (SRMS)</name>
          <t pn="section-3.2.1-1">This section specifies the concept and externally visible
          functionality of a segment routing mapping server Segment Routing Mapping Server (SRMS).</t>

          <t>The
          <t pn="section-3.2.1-2">The purpose of SRMS functionality is to support the
          advertisement of Prefix SIDs Prefix-SIDs to a prefix without the need to
          explicitly advertise such assignment within a prefix reachability
          advertisement. Examples of explicit Prefix SID advertisement Prefix-SID Advertisement are the
          Prefix SID
          Prefix-SID sub-TLVs defined in <xref
          target="RFC8665"/>, <xref
          target="RFC8666"/>, target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref
          target="RFC8667"/>.</t>

          <t>The target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>.</t>
          <t pn="section-3.2.1-3">The SRMS functionality allows assigning of Prefix SIDs Prefix-SIDs to
          prefixes owned by non-SR-capable routers as well as to prefixes
          owned by SR-capable nodes. It is the former capability that is
          essential to the SR-LDP interworking described later in this
          section.</t>

          <t>The
          <t pn="section-3.2.1-4">The SRMS functionality consists of two functional blocks: the
          Mapping Server (MS) and Mapping Client (MC).</t>

          <t>An
          <t pn="section-3.2.1-5">An MS is a node that advertises an SR mappings. Advertisements
          sent by an MS define the assignment of a Prefix SID Prefix-SID to a prefix
          independent of the advertisement of reachability to the prefix
          itself. An MS MAY <bcp14>MAY</bcp14> advertise SR mappings for any prefix whether or
          not it advertises reachability for the prefix and irrespective of
          whether that prefix is advertised by or even reachable through any
          router in the network.</t>

          <t>An
          <t pn="section-3.2.1-6">An MC is a node that receives and uses the MS mapping
          advertisements. Note that a node may be both an MS and an MC. An MC
          interprets the SR-mapping advertisement as an assignment of a
          Prefix SID
          Prefix-SID to a prefix. For a given prefix, if an MC receives an
          SR-mapping advertisement from a mapping server Mapping Server and also has received
          a Prefix SID advertisement Prefix-SID Advertisement for that same prefix in a prefix
          reachability advertisement, then the MC MUST <bcp14>MUST</bcp14> prefer the SID
          advertised in the prefix reachability advertisement over the
          mapping server advertisement,
          Mapping Server Advertisement, i.e., the mapping server advertisement
          MUST Mapping Server Advertisement
          <bcp14>MUST</bcp14> be ignored for that prefix. Hence, assigning a Prefix SID Prefix-SID to a
          prefix using the SRMS functionality does not preclude assigning the
          same or different Prefix SID(s) Prefix-SID(s) to the same prefix using explicit
          Prefix SID advertisement
          Prefix-SID Advertisement such as the aforementioned Prefix SID Prefix-SID
          sub-TLVs.</t>

          <t>For
          <t pn="section-3.2.1-7">For example, consider an IPv4 prefix advertisement received by an
          IS&nbhy;IS
          IS‑IS router in the Extended IP reachability TLV (TLV 135). Suppose
          TLV 135 contained the Prefix SID Prefix-SID sub-TLV. If the router that
          receives TLV 135 with the Prefix SID Prefix-SID sub-TLV also received an
          SR-mapping advertisement for the same prefix through the
          SID/Label Binding TLV, then the receiving router must prefer the
          Prefix SID
          Prefix-SID sub-TLV over the SID/Label Binding TLV for that
          prefix. Refer to <xref
          target="RFC8667"/> target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/> for details
          about the Prefix SID Prefix-SID sub-TLV and SID/Label Binding TLV.</t>
        </section>
        <section anchor="section-4.2.2" title="SR anchor="sec-4.2.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-sr-to-ldp-behavior">SR to LDP Behavior">
          <t>SR Behavior</name>
          <t pn="section-3.2.2-1">SR to LDP interworking requires an SRMS as defined above.</t>

          <t>Each
          <t pn="section-3.2.2-2">Each SR-capable router installs in the MPLS data-plane Node-SIDs Node SIDs
          learned from the SRMS exactly like as if these SIDs had been advertised
          by the nodes themselves.</t>

          <t>An
          <t pn="section-3.2.2-3">An SR node having LDP LDP-only neighbors MUST <bcp14>MUST</bcp14> stitch the incoming SR label
          (whose SID is advertised by the SRMS) to the outgoing LDP label.</t>

          <t>It
          <t pn="section-3.2.2-4">It has to be noted that the SR to LDP behavior does not propagate
          the status of the LDP FEC that was signaled if by LDP was when configured
          to use the
          in ordered mode.</t>

          <t>It
          <t pn="section-3.2.2-5">It has to be noted that in the case of SR to LDP, the label
          binding is equivalent to the independent LDP Label Distribution
          Control Mode <xref target="RFC5036"/> target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/> where a label is bound to a
          FEC independently from the received binding for the same FEC.</t>
        </section>
        <section anchor="section-4.2.3"
                 title="Interoperability anchor="sec-4.2.3" numbered="true" toc="include" removeInRFC="false" pn="section-3.2.3">
          <name slugifiedName="name-interoperability-of-multipl">Interoperability of Multiple SRMSes and Prefix SID Advertisements">
          <t>In Prefix-SID Advertisements</name>
          <t pn="section-3.2.3-1">In the case of SR/LDP SR-LDP interoperability through the use of an SRMS,
          mappings are advertised by one or more SRMSes.</t>

          <t>SRMS
          <t pn="section-3.2.3-2">SRMS functionality is implemented in the link-state protocol (such as
          IS-IS and OSPF). Link-state protocols allow propagation of updates
          across area boundaries and, therefore, SRMS advertisements are
          propagated through the usual inter-area advertisement procedures in
          link-state protocols.</t>

          <t>Multiple
          <t pn="section-3.2.3-3">Multiple SRMSes can be provisioned in a network for redundancy.
          Moreover, a preference mechanism may also be used among SRMSes to
          deploy a primary/secondary SRMS scheme allowing controlled
          modification or migration of SIDs.</t>

          <t>The
          <t pn="section-3.2.3-4">The content of SRMS advertisement (i.e., mappings) are a matter
          of local policy determined by the operator. When multiple SRMSes are
          active, it is necessary that the information (mappings) advertised
          by the different SRMSes is aligned and consistent. The following
          mechanism is applied to determine the preference of SRMS
          advertisements:</t>

          <t>If
          <t pn="section-3.2.3-5">If a node acts as an SRMS, it MAY <bcp14>MAY</bcp14> advertise a preference to be
          associated with all SRMS SID advertisements Advertisements sent by that node. The
          means of advertising the preference is defined in the
          protocol-specific documents, e.g., <xref
          target="RFC8665"/>, <xref
          target="RFC8666"/>, target="RFC8665" format="default" sectionFormat="of" derivedContent="RFC8665"/>, <xref target="RFC8666" format="default" sectionFormat="of" derivedContent="RFC8666"/>, and <xref
          target="RFC8667"/>. target="RFC8667" format="default" sectionFormat="of" derivedContent="RFC8667"/>. The
          preference value is an unsigned 8-bit integer with the following
          properties:</t>

          <t><list style="hanging">
              <t>0 - Reserved
          <table anchor="table_1" align="center" pn="table-1">
            <tbody>
              <tr>
                <td align="center" colspan="1" rowspan="1">0</td>
                <td align="left" colspan="1" rowspan="1">Reserved value indicating advertisements from that
      node
              MUST NOT <bcp14>MUST NOT</bcp14> be used.</t>

              <t>1 - 255 Preference used</td>
              </tr>
              <tr>
                <td align="center" colspan="1" rowspan="1">1-255</td>
                <td align="left" colspan="1" rowspan="1">Preference value (255 is most preferred)</t>
            </list>Advertisement preferred)</td>
              </tr>
            </tbody>
          </table>
          <t pn="section-3.2.3-7">Advertisement of a preference value is optional. Nodes
          that do not advertise a preference value are assigned a preference
          value of 128.</t>

          <t>An
          <t pn="section-3.2.3-8">An MCC on a node receiving one or more SRMS mapping advertisements
          applies them as follows:</t>

          <t><list style="symbols">
              <t>For
          <ul spacing="normal" bare="false" empty="false" pn="section-3.2.3-9">
            <li pn="section-3.2.3-9.1">For any prefix for which it did not receive a Prefix SID
              advertisement, Prefix-SID
              Advertisement, the MCC applies the SRMS mapping advertisements
              with the highest preference. The mechanism by which a Prefix SID Prefix-SID
              is advertised for a given prefix is defined in the protocol
              specifications <xref target="RFC8665"/>,
              <xref target="RFC8666"/>, and
              <xref
              target="RFC8667"/>.</t>

              <t>If 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"/>.</li>
            <li pn="section-3.2.3-9.2">If there is an incoming label collision as specified in <xref
              target="RFC8660"/>, target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>, apply the
              steps specified in <xref
              target="RFC8660"/> target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/> to resolve the
              collision.</t>
            </list></t>

          <t>When
              collision.</li>
          </ul>
          <t pn="section-3.2.3-10">When the SRMS advertises mappings, an implementation should
          provide a mechanism through which the operator determines which of
          the IP2MPLS mappings are preferred among the one advertised by the
          SRMS and the ones advertised by LDP.</t>
        </section>
      </section>
    </section>
    <section anchor="section-5" title="SR/LDP anchor="sec-5" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-sr-ldp-interworking-use-cas">SR-LDP Interworking Use Cases">
      <t>SR Cases</name>
      <t pn="section-4-1">SR can be deployed, for example, to enhance LDP transport. The SR
      deployment can be limited to the network region where the SR benefits
      are most desired.</t>
      <section anchor="section-5.1" title="SR anchor="sec-5.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-sr-protection-of-ldp-based-">SR Protection of LDP-Based Traffic">
        <t>In Traffic</name>
        <t pn="section-4.1-1">In <xref target="ref-sr-ldp-interworking-example"/>, target="ref-sr-ldp-interworking-example" format="default" sectionFormat="of" derivedContent="Figure 3"/>, let us assume:
	<list style="empty">
	  <t>
        </t>
        <ul empty="false" spacing="normal" bare="false" pn="section-4.1-2">
          <li pn="section-4.1-2.1">
          All link costs are 10 except FG, which is 30.</t>
	  <t> 30.</li>
          <li pn="section-4.1-2.2"> All routers are LDP capable.</t>
	  <t> capable.</li>
          <li pn="section-4.1-2.3"> X, Y, and Z are PEs participating in an important service S.</t>
	  <t> S.</li>
          <li pn="section-4.1-2.4"> The operator requires 50 msec link-based Fast Reroute (FRR) for service S.</t>
	  <t> S.</li>
          <li pn="section-4.1-2.5"> A, B, C, D, E, F, and G are SR capable.</t>
	  <t> capable.</li>
          <li pn="section-4.1-2.6"> X, Y, and Z are not SR capable, e.g., as part of a
          staged migration from LDP to SR, the operator deploys SR first in
          a subpart of the network and then everywhere.</t>
          </list></t> everywhere.</li>
        </ul>
        <figure anchor="ref-sr-ldp-interworking-example"
                title="SR/LDP align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-sr-ldp-interworking-example">SR-LDP Interworking Example">
          <artwork><![CDATA[ Example</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-3.1">
                                  X
                                  |
                           Y--A---B---E--Z
                              |   |    \
                              D---C--F--G
                                      30
]]></artwork>
</artwork>
        </figure>

        <t><list hangIndent="3" style="hanging">
        <t
            hangText="The pn="section-4.1-4">The operator would like to resolve the following issues:"><vspace
            blankLines="1"/> To issues:
</t>
        <ul empty="false" spacing="normal" bare="false" pn="section-4.1-5">
          <li pn="section-4.1-5.1">To protect the link BA along the shortest-path of the important flow XY,
B requires a Remote Loop-Free Alternate (RLFA; see <xref target="RFC7490"/>) target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/>) repair tunnel to D and, therefore, a targeted LDP session
from B to D. Typically, network operators prefer avoiding these dynamically
established multi-hop LDP sessions in order to reduce the number of protocols
running in the network and, therefore, simplify network operations. <vspace
            blankLines="1"/> There
</li>
          <li pn="section-4.1-5.2">There is no LFA/RLFA solution to protect the link BE along the shortest
path of the important flow XZ. The operator wants a guaranteed link-based FRR solution.</t>
          </list></t>

        <t>The solution.
</li>
        </ul>
        <t pn="section-4.1-6">The operator can meet these objectives by deploying SR only on A,
        B, C, D, E, F, and G:</t>

        <t><list hangIndent="3" style="hanging">
            <t>The
        <ul bare="false" empty="false" spacing="normal" pn="section-4.1-7">
          <li pn="section-4.1-7.1">The operator configures A, B, C, D, E, F, and G with SRGB [100, 200] and respective
with node segments 101, 102, 103, 104, 105, 106, and
            107.</t>
          </list></t>

        <t><list hangIndent="3" style="hanging">
            <t>The 107, respectively.
</li>
          <li pn="section-4.1-7.2">The operator configures D as an SR Mapping Server with the following
policy mapping: (X, 201), (Y, 202), and (Z, 203).</t>
          </list></t>

        <t><list hangIndent="3" style="hanging">
            <t>Each 203).
</li>
          <li pn="section-4.1-7.3">Each SR node automatically advertises a local adjacency segment for its
IGP adjacencies. Specifically, F advertises adjacency segment 9001 for its
adjacency FG.</t>
          </list></t>

        <t>A, FG.
</li>
        </ul>
        <t pn="section-4.1-8">A, B, C, D, E, F, and G keep their LDP capability. Therefore, the
        flows XY and XZ are transported over end-to-end LDP LSPs.</t>

        <t>For
        <t pn="section-4.1-9">For example, LDP at B installs the following MPLS data-plane
        entries:</t>

        <t><list hangIndent="3" style="hanging">
        <ul empty="true" bare="false" spacing="normal" pn="section-4.1-10">
          <li pn="section-4.1-10.1">
            <t
            hangText="Incoming pn="section-4.1-10.1.1">Incoming label: local LDP label bound by B for FEC Y"><vspace
            blankLines="0"/> Outgoing Y</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-4.1-10.1.2">
              <li pn="section-4.1-10.1.2.1">Outgoing label: LDP label bound by A for FEC
            Y<vspace blankLines="0"/> Outgoing next-hop: A</t> Y</li>
              <li pn="section-4.1-10.1.2.2">Outgoing next hop: A</li>
            </ul>
          </li>
          <li pn="section-4.1-10.2">
            <t
            hangText="Incoming pn="section-4.1-10.2.1">Incoming label: local LDP label bound by B for FEC Z"><vspace
            blankLines="0"/>Outgoing Z</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-4.1-10.2.2">
              <li pn="section-4.1-10.2.2.1">Outgoing label: LDP label bound by E for FEC
            Z<vspace blankLines="0"/>Outgoing next-hop: E</t>
          </list></t>

        <t>The Z </li>
              <li pn="section-4.1-10.2.2.2">Outgoing next hop: E </li>
            </ul>
          </li>
        </ul>
        <t pn="section-4.1-11">The novelty comes from how the backup chains are computed for these
        LDP-based entries. While LDP labels are used for the primary next- hop
        and outgoing labels, SR information is used for the FRR construction.
        In steady state, the traffic is transported over LDP LSP. In transient
        FRR state, the traffic is backup thanks to the SR-enhanced
        capabilities.</t>

        <t>The
        <t pn="section-4.1-12">The RLFA paths are dynamically precomputed as defined in <xref
        target="RFC7490"/>. target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/>. Typically, implementations allow to enable an RLFA
        mechanism through a simple configuration command that triggers both
        the precomputation and installation of the repair path. The details
        on how RLFA mechanisms are implemented and configured is outside the
        scope of this document and not relevant to the aspects of SR/LDP SR-LDP
        interwork explained in this document.</t>

<!-- hmm how about "maintain guaranteed FRR coverage"?-->
        <t><list hangIndent="3" style="hanging">
        <t
            hangText="This pn="section-4.1-13">This helps meet the requirements of the operator:"><vspace
            blankLines="1"/> Eliminate operator:
</t>
        <ul bare="false" empty="false" spacing="normal" pn="section-4.1-14">
          <li pn="section-4.1-14.1">Eliminate targeted LDP sessions. <vspace
            blankLines="1"/> Guaranteed
</li>
          <li pn="section-4.1-14.2">Provide guaranteed FRR coverage. <vspace blankLines="1"/>
            Keep
</li>
          <li pn="section-4.1-14.3">Keep the traffic over LDP LSP in steady state. <vspace
            blankLines="1"/> Partially
</li>
          <li pn="section-4.1-14.4">Partially deploy SR only where needed.</t>
          </list></t> needed.
</li>
        </ul>
      </section>
      <section anchor="section-5.2" title="Eliminating anchor="sec-5.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-eliminating-targeted-ldp-se">Eliminating Targeted LDP Sessions">
        <t>B's Sessions</name>
        <t pn="section-4.2-1">B's MPLS entry to Y becomes:</t>

        <figure>
          <artwork><![CDATA[
- Incoming
        <ul empty="true" bare="false" spacing="normal" pn="section-4.2-2">
          <li pn="section-4.2-2.1">
            <t pn="section-4.2-2.1.1">Incoming label: local LDP label bound by B for FEC Y
    Outgoing Y</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-4.2-2.1.2">
              <li pn="section-4.2-2.1.2.1">Outgoing label: LDP label bound by A for FEC Y
    Backup Y</li>
              <li pn="section-4.2-2.1.2.2">Backup outgoing label: SR node segment for Y {202}
    Outgoing next-hop: A
    Backup next-hop: {202}</li>
              <li pn="section-4.2-2.1.2.3">Outgoing next hop: A</li>
              <li pn="section-4.2-2.1.2.4">Backup next hop: repair tunnel: node segment to D {104} with outgoing next-hop: C
]]></artwork>
        </figure>

        <t>It
 next hop: C</li>
            </ul>
          </li>
        </ul>
        <t pn="section-4.2-3">It has to be noted that D is selected as a Remote Loop-Free Alternate
        (RLFA) as defined in <xref target="RFC7490"/>.</t>

        <t>In target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/>.</t>
        <t pn="section-4.2-4">In steady state, X sends its Y-destined traffic to B with a top
        label, which is the LDP label bound by B for FEC Y. B swaps that top
        label for the LDP label bound by A for FEC Y and forwards to A. A pops
        the LDP label and forwards to Y.</t>

        <t>Upon
        <t pn="section-4.2-5">Upon failure of the link BA, B swaps the incoming top label with
        the node segment for Y (202) and sends the packet onto a repair tunnel
        to D (node segment 104). Thus, B sends the packet to C with the label
        stack {104, 202}.&nbsp; 202}.  C pops the node segment 104 and forwards to D. D
        swaps 202 for 202 and forwards to A. A's next-hop next hop to Y is not SR
        capable, and therefore, node Node A swaps the incoming node segment 202 to the
        LDP label announced by its next-hop next hop (in this case, implicit null).</t>

        <t>After NULL).</t>
        <t pn="section-4.2-6">After IGP convergence, B's MPLS entry to Y will become:</t>

        <figure>
          <artwork><![CDATA[
- Incoming
        <ul empty="true" bare="false" spacing="normal" pn="section-4.2-7">
          <li pn="section-4.2-7.1">
            <t pn="section-4.2-7.1.1">Incoming label: local LDP label bound by B for FEC Y
    Outgoing Y</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-4.2-7.1.2">
              <li pn="section-4.2-7.1.2.1">Outgoing label: LDP label bound by C for FEC Y
    Outgoing next-hop: C]]></artwork>
        </figure>

        <t/>

        <t>And Y</li>
              <li pn="section-4.2-7.1.2.2">Outgoing next hop: C</li>
            </ul>
          </li>
        </ul>
        <t pn="section-4.2-8">And the traffic XY travels again over the LDP LSP.</t>

        <t>Conclusion:
        <t pn="section-4.2-9">Conclusion: the operator has eliminated the need for targeted LDP
        sessions (no longer required) and the steady-state traffic is still
        transported over LDP. The SR deployment is confined to the area where
        these benefits are required.</t>

        <t>Despite
        <t pn="section-4.2-10">Despite that, in general, an implementation would not require a
        manual configuration of targeted LDP sessions. However, it is always a
        gain if the operator is able to reduce the set of protocol sessions
        running on the network infrastructure.</t>
      </section>
      <section anchor="section-5.3" title="Guaranteed anchor="sec-5.3" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-guaranteed-frr-coverage">Guaranteed FRR Coverage">
        <t>As Coverage</name>
        <t pn="section-4.3-1">As mentioned in <xref target="section-5.1"/>, target="sec-5.1" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, in the example
        topology described in <xref target="ref-sr-ldp-interworking-example"/>, target="ref-sr-ldp-interworking-example" format="default" sectionFormat="of" derivedContent="Figure 3"/>, there is no RLFA-based solution for
        protecting the traffic flow YZ against the failure of link BE because
        there is no intersection between the extended P-space and Q-space (see
        <xref target="RFC7490"/> target="RFC7490" format="default" sectionFormat="of" derivedContent="RFC7490"/> for details). However:</t>

        <t><list style="symbols">
            <t>G
        <ul spacing="normal" bare="false" empty="false" pn="section-4.3-2">
          <li pn="section-4.3-2.1">G belongs to the Q space of Z.</t>

            <t>G Z.</li>
          <li pn="section-4.3-2.2">G can be reached from B via a "repair SR path" {106, 9001} that
            is not affected by failure of link BE. (The method by which G and
            the repair tunnel to it from B are identified are outside the scope of
            this document.)</t>
          </list></t>

        <t>B's document.)</li>
        </ul>
        <t pn="section-4.3-3">B's MPLS entry to Z becomes:</t>

        <figure>
          <artwork><![CDATA[
- Incoming
        <ul empty="true" bare="false" spacing="normal" pn="section-4.3-4">
          <li pn="section-4.3-4.1">
            <t pn="section-4.3-4.1.1">Incoming label: local LDP label bound by B for FEC Z
    Outgoing Z</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-4.3-4.1.2">
              <li pn="section-4.3-4.1.2.1">Outgoing label: LDP label bound by E for FEC Z
    Backup Z</li>
              <li pn="section-4.3-4.1.2.2">Backup outgoing label: SR node segment for Z {203}
    Outgoing next-hop: E
    Backup next-hop: repair {203}</li>
              <li pn="section-4.3-4.1.2.3">Outgoing next hop: E</li>
              <li pn="section-4.3-4.1.2.4">Backup next hop: repair tunnel to G: {106, 9001}
]]></artwork></figure>

<t>
<list style="empty"><t><list style="empty"><t> 9001}</li>
            </ul>
          </li>
        </ul>
        <ul empty="true" spacing="normal" bare="false" pn="section-4.3-5">
          <li pn="section-4.3-5.1">
        G is reachable from B via the combination of a
        node segment to F {106} and an adjacency segment
        FG {9001}
      </t>
<t> {9001}.
      </li>
          <li pn="section-4.3-5.2">
        Note that {106, 107} would have equally work. worked.
        Indeed, in many cases, P's shortest path to Q is
        over the link PQ.  The adjacency segment from P to
        Q is required only in very rare topologies where
        the shortest-path from P to Q is not via the link
        PQ.
</t>
      </list></t></list>
</li>
        </ul>
        <t pn="section-4.3-6">

        In steady state, X sends its Z-destined traffic to B with a top
        label, which is the LDP label bound by B for FEC Z. B swaps that top
        label for the LDP label bound by E for FEC Z and forwards to E. E pops
        the LDP label and forwards to Z.</t>

        <t>Upon
        <t pn="section-4.3-7">Upon failure of the link BE, B swaps the incoming top label with
        the node segment for Z (203) and sends the packet onto a repair tunnel
        to G (node segment 106 followed by adjacency segment 9001). Thus, B
        sends the packet to C with the label stack {106, 9001, 203}.&nbsp; 203}.  C pops
        the node segment 106 and forwards to F. F pops the adjacency segment
        9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's
        next-hop
        next hop to Z is not SR capable, and thus, E swaps the incoming node
        segment 203 for the LDP label announced by its next-hop next hop (in this case,
        implicit null).</t>

        <t>After NULL).</t>
        <t pn="section-4.3-8">After IGP convergence, B's MPLS entry to Z will become:</t>

        <figure>
          <artwork><![CDATA[
- Incoming
        <ul empty="true" bare="false" spacing="normal" pn="section-4.3-9">
          <li pn="section-4.3-9.1">
            <t pn="section-4.3-9.1.1">Incoming label: local LDP label bound by B for FEC Z
    Outgoing Z</t>
            <ul empty="false" bare="false" spacing="normal" pn="section-4.3-9.1.2">
              <li pn="section-4.3-9.1.2.1">Outgoing label: LDP label bound by C for FEC Z
    Outgoing next-hop: C]]></artwork>
        </figure>

        <t/>

        <t>And </li>
              <li pn="section-4.3-9.1.2.2">Outgoing next hop: C </li>
            </ul>
          </li>
        </ul>
        <t pn="section-4.3-10">And the traffic XZ travels again over the LDP LSP.</t>

        <t>Conclusions:</t>

        <t><list style="symbols">
            <t>the
        <t pn="section-4.3-11">Conclusions:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-4.3-12">
          <li pn="section-4.3-12.1">the operator has eliminated its second problem: guaranteed FRR
            coverage is provided. The steady-state traffic is still
            transported over LDP. The SR deployment is confined to the area
            where these benefits are required.</t>

            <t>FRR required.</li>
          <li pn="section-4.3-12.2">FRR coverage has been achieved without any signaling for
            setting up the repair LSP and without setting up a targeted LDP
            session between B and G.</t>
          </list></t> G.</li>
        </ul>
      </section>
      <section anchor="section-5.4"
               title="Inter-AS anchor="sec-5.4" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-inter-as-option-c-carriers-">Inter-AS Option C, Carrier's Carrier">
        <t>In Carrier</name>
        <t pn="section-4.4-1">In inter-AS Option C <xref target="RFC4364"/>, target="RFC4364" format="default" sectionFormat="of" derivedContent="RFC4364"/>, two interconnected
        ASes sets up inter-AS MPLS connectivity. SR may be independently
        deployed in each AS.</t>
        <figure anchor="ref-inter-as-option-c" title="Inter-AS align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-inter-as-option-c">Inter-AS Option C">
          <artwork><![CDATA[ C</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.4-2.1">
                    PE1---R1---B1---B2---R2---PE2
                    <----------->   <----------->
                    &lt;-----------&gt;   &lt;-----------&gt;
                         AS1            AS2
]]></artwork>
</artwork>
        </figure>

        <t>In
        <t pn="section-4.4-3">In Inter-AS Option C, B2 advertises to B1 a labeled BGP route <xref
        target="RFC8277"/> target="RFC8277" format="default" sectionFormat="of" derivedContent="RFC8277"/> for PE2, and B1 reflects it to its
        internal peers, e.g., PE1. PE1 learns from a service route reflector a
        service route whose next-hop next hop is PE2. PE1 resolves that service route
        on the labeled BGP route to PE2. That labeled BGP route to PE2 is
        itself resolved on the AS1 IGP route to B1.</t>

        <t>If
        <t pn="section-4.4-4">If AS1 operates SR, then the tunnel from PE1 to B1 is provided by
        the node segment from PE1 to B1.</t>

        <t>PE1
        <t pn="section-4.4-5">PE1 sends a service packet with three labels: the top one is the
        node segment to B1, the next one is the label in the labeled BGP route
        provided by B1 for the route "PE2", and the bottom one is the service
        label allocated by PE2.</t>
      </section>
    </section>
    <section anchor="section-6" title="IANA Considerations">
      <t> anchor="sec-6" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-5-1"> This document has no IANA actions. </t>
    </section>
    <section anchor="section-7" title="Manageability Considerations"> anchor="sec-7" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <section anchor="section-7.1" title="SR anchor="sec-7.1" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-sr-and-ldp-coexistence">SR and LDP Coexistence">
        <t>When Coexistence</name>
        <t pn="section-6.1-1">When both SR and LDP coexist, the following applies:</t>

        <t><list style="symbols">
            <t>If
        <ul spacing="normal" bare="false" empty="false" pn="section-6.1-2">
          <li pn="section-6.1-2.1">If both SR and LDP propose an IP2MPLS entry for the same IP
            prefix, then by default the LDP route SHOULD <bcp14>SHOULD</bcp14> be selected. This is
            because it is expected that SR is introduced into networks that
            contain routers that do not support SR. Hence, by having a behavior
            that prefers LDP over SR, traffic flow is unlikely to be
            disrupted</t>

            <t>A
            disrupted.</li>
          <li pn="section-6.1-2.2">A local policy on a router MUST <bcp14>MUST</bcp14> allow to prefer the SR-provided
            IP2MPLS entry.</t>

            <t>Note entry.</li>
          <li pn="section-6.1-2.3">Note that this policy MAY <bcp14>MAY</bcp14> be locally defined. There is no
            requirement that all routers use the same policy.</t>
          </list></t> policy.</li>
        </ul>
      </section>
      <section anchor="section-7.3" title="Data-Plane Verification">
        <t>When anchor="sec-7.3" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-data-plane-verification">Data-Plane Verification</name>
        <t pn="section-6.2-1">When Label switch paths (LSPs) are defined by stitching LDP LSPs
        with SR LSPs, it is necessary to have mechanisms allowing the
        verification of the LSP connectivity as well as validation of the
        path. These mechanisms are described in <xref target="RFC8287"/>.</t> target="RFC8287" format="default" sectionFormat="of" derivedContent="RFC8287"/>.</t>
      </section>
    </section>
    <section anchor="section-8" title="Security Considerations">
      <t>This anchor="sec-8" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-7-1">This document does not introduce any change to the MPLS data plane
      <xref target="RFC3031"/> target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> and therefore no additional security of the
      MPLS data plane is required.</t>

<!-- [rfced] Please clarify this text. Perhaps this
      <t pn="section-7-2">
This document introduces another form of label binding advertisements. The
security associated with these advertisements is part of the result security applied
to routing protocols such as IS-IS <xref target="RFC5304" format="default" sectionFormat="of" derivedContent="RFC5304"/>
and OSPF <xref target="RFC5709" format="default" sectionFormat="of" derivedContent="RFC5709"/>, which both optionally make
use of a copy/paste error. How should it be rewritten?

Original:
   Because this document recognizes
   that cryptographic authentication mechanisms. This form of advertisement is
more centralized, on behalf of the node advertising the IP reachability, which
presents a different risk profile. This document miscofiguration and/or programming may result in false or
   conflicting also specifies a mechanism by
which the ill effects of advertising label binding advertisements, thereby compromising
   traffic conflicting label bindings can be
mitigated. In particular,
   forwarding, the document recommends strict configuration/ advertisements from the node advertising the IP
reachability is more
   programmability control as well as montoring the SID advertised and preferred than the centralized one. log/error messages by the
   operator to avoid or at least significantly minimize the possibility
   of such risk.

new suggestions from authors:

"This This document
recognizes that errors in configuration and/or programming may result in false
or conflicting label binding advertisements compromising traffic
forwarding. Therefore, this document recommends the operator the implement strict
configuration/programmability control, the monitoring of the advertised SIDs,
the preference of an IP reachability SID advertisement Advertisement over a centralized SID advertisement
Advertisement, and the logging of any error message in order to avoid, or at
least significantly minimize, the possibility of such risk."

-->

      <t> risk.
</t>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.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 the requirements in the specification.  These words are often capitalized. This document introduces another form of label binding advertisements. The
security associated with defines these advertisements is part of the security applied
to routing protocols such words as IS-IS <xref target="RFC5304"/> and OSPF <xref
target="RFC5709"/>, which both optionally make use of cryptographic
authentication mechanisms. This form of advertisement is more centralized, on
behalf of the node advertising the IP reachability, which presents a different
risk profile. they should be interpreted in IETF documents.  This document also specifies a mechanism by which the ill
effects an Internet Best Current Practices for the Internet Community, and requests 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="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 advertising conflicting label bindings can 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="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 mitigated. In
particular, advertisements from 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 advertising 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>
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" quoteTitle="true" derivedAnchor="RFC8660">
          <front>
            <title>Segment Routing with MPLS Data Plane</title>
            <seriesInfo name="RFC" value="8660"/>
            <seriesInfo name="DOI" value="10.17487/RFC8660"/>
            <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>
            <author initials="R" surname="Shakir" fullname="Rob Shakir">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="2019"/>
          </front>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/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 the architecture 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="RFC3209" target="https://www.rfc-editor.org/info/rfc3209" quoteTitle="true" derivedAnchor="RFC3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <author initials="D." surname="Awduche" fullname="D. Awduche">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Gan" fullname="D. Gan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2001" month="December"/>
            <abstract>
              <t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3209"/>
          <seriesInfo name="DOI" value="10.17487/RFC3209"/>
        </reference>
        <reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4364" quoteTitle="true" derivedAnchor="RFC4364">
          <front>
            <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author initials="E." surname="Rosen" fullname="E. Rosen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="February"/>
            <abstract>
              <t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers.  This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other.  Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4364"/>
          <seriesInfo name="DOI" value="10.17487/RFC4364"/>
        </reference>
        <reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5304" quoteTitle="true" derivedAnchor="RFC5304">
          <front>
            <title>IS-IS Cryptographic Authentication</title>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Atkinson" fullname="R. Atkinson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="October"/>
            <abstract>
              <t>This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.  The base specification includes an authentication mechanism that allows for multiple authentication algorithms.  The base specification only specifies the algorithm for cleartext passwords.  This document replaces RFC 3567.</t>
              <t>This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5304"/>
          <seriesInfo name="DOI" value="10.17487/RFC5304"/>
        </reference>
        <reference anchor="RFC5709" target="https://www.rfc-editor.org/info/rfc5709" quoteTitle="true" derivedAnchor="RFC5709">
          <front>
            <title>OSPFv2 HMAC-SHA Cryptographic Authentication</title>
            <author initials="M." surname="Bhatia" fullname="M. Bhatia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Manral" fullname="V. Manral">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Fanto" fullname="M. Fanto">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="White" fullname="R. White">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Barnes" fullname="M. Barnes">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Atkinson" fullname="R. Atkinson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="October"/>
            <abstract>
              <t>This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism.  This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5709"/>
          <seriesInfo name="DOI" value="10.17487/RFC5709"/>
        </reference>
        <reference anchor="RFC5960" target="https://www.rfc-editor.org/info/rfc5960" quoteTitle="true" derivedAnchor="RFC5960">
          <front>
            <title>MPLS Transport Profile Data Plane Architecture</title>
            <author initials="D." surname="Frost" fullname="D. Frost" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Bryant" fullname="S. Bryant" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bocci" fullname="M. Bocci" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t>The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks.  This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.</t>
              <t>This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5960"/>
          <seriesInfo name="DOI" value="10.17487/RFC5960"/>
        </reference>
        <reference anchor="RFC7490" target="https://www.rfc-editor.org/info/rfc7490" quoteTitle="true" derivedAnchor="RFC7490">
          <front>
            <title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
            <author initials="S." surname="Bryant" fullname="S. Bryant">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Filsfils" fullname="C. Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Shand" fullname="M. Shand">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="So" fullname="N. So">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="April"/>
            <abstract>
              <t>This document describes an extension to the basic IP reachability is
more preferred than the centralized one. Because this document recognizes fast reroute mechanism, described in RFC 5286, that
reachability, which presents a different risk profile.  This provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7490"/>
          <seriesInfo name="DOI" value="10.17487/RFC7490"/>
        </reference>
        <reference anchor="RFC8277" target="https://www.rfc-editor.org/info/rfc8277" quoteTitle="true" derivedAnchor="RFC8277">
          <front>
            <title>Using BGP to Bind MPLS Labels to Address Prefixes</title>
            <author initials="E." surname="Rosen" fullname="E. Rosen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t>This document
misconfiguration and/or programming may result in false or conflicting also specifies a mechanism by which the ill effects set of advertising procedures for using BGP to advertise that a specified router has bound a specified MPLS label binding
advertisements, thereby compromising traffic conflicting (or a specified sequence of MPLS labels organized as a contiguous part of a label bindings stack) to a specified address prefix.  This can be
mitigated. In particular, forwarding, done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the document recommends strict
configuration/ advertisements from prefix and the node advertising MPLS label(s) and whose Next Hop field identifies the IP reachability node at which said prefix is
more programmability control as well as monitoring bound to said label(s).  This document obsoletes RFC 3107.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8277"/>
          <seriesInfo name="DOI" value="10.17487/RFC8277"/>
        </reference>
        <reference anchor="RFC8287" target="https://www.rfc-editor.org/info/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 SID advertised packet with an SR header.</t>
              <t>The segment assignment and
preferred than the centralized one. log/error messages by 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 operator problem and defines extensions to
avoid or at least significantly minimize the possibility of such risk.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">

<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.8174"?>

<?rfc include="reference.RFC.5036" ?>
<?rfc include="reference.RFC.8402" ?>

<!-- draft-ietf-spring-segment-routing-mpls in C340 -->
<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660">
<front>
<title>Segment perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS Data Plane</title> data plane.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8287"/>
          <seriesInfo name="DOI" value="10.17487/RFC8287"/>
        </reference>
        <reference anchor="RFC8355" target="https://www.rfc-editor.org/info/rfc8355" quoteTitle="true" derivedAnchor="RFC8355">
          <front>
            <title>Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks</title>
            <author initials='A' surname='Bashandy' fullname="Ahmed Bashandy" initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
  <organization/>
              <organization showOnFrontPage="true"/>
            </author>
            <author initials='C' surname='Filsfils' fullname='Clarence Filsfils' initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
  <organization/>
</author>
<author initials='S' surname='Previdi' fullname="Stefano Previdi">
  <organization/>
</author>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'>
  <organization/>
              <organization showOnFrontPage="true"/>
            </author>
            <author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
  <organization/> initials="B." surname="Decraene" fullname="B. Decraene">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials='R' surname='Shakir' fullname='Rob Shakir'>
  <organization/> initials="R." surname="Shakir" fullname="R. Shakir">
              <organization showOnFrontPage="true"/>
            </author>
            <date month='September' year='2019'/> year="2018" month="March"/>
            <abstract>
              <t>This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8660"/> value="8355"/>
          <seriesInfo name="DOI" value="10.17487/RFC8660"/> value="10.17487/RFC8355"/>
        </reference>

    </references>

    <references title="Informative References">

<?rfc include="reference.RFC.8355" ?>
<?rfc include="reference.RFC.3031" ?>
<?rfc include="reference.RFC.8287" ?>
<?rfc include="reference.RFC.3209" ?>
<?rfc include="reference.RFC.4364" ?>
<?rfc include="reference.RFC.5304" ?>
<?rfc include="reference.RFC.5709" ?>
<?rfc include="reference.RFC.5960" ?>
<?rfc include="reference.RFC.7490" ?>
<?rfc include="reference.RFC.8277" ?>

<!--  I-D.ietf-isis-segment-routing-extensions: I-D exists -->
        <reference anchor='RFC8667'> anchor="RFC8665" quoteTitle="true" target="https://doi.org/10.17487/RFC8665" derivedAnchor="RFC8665">
          <front>
<title>IS-IS
            <title>OSPF Extensions for Segment Routing</title>
            <seriesInfo name="RFC" value="8665"/>
            <seriesInfo name="DOI" value="10.17487/RFC8665"/>
            <author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials='S' surname='Previdi' fullname='Stefano Previdi'> initials="S" surname="Previdi" fullname="Stefano Previdi" role="editor">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='L' surname='Ginsberg' fullname='Les Ginsberg'> initials="C" surname="Filsfils" fullname="Clarence              Filsfils">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'> initials="H" surname="Gredler" fullname="Hannes Gredler">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'> initials="R" surname="Shakir" fullname="Rob Shakir">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='H' surname='Gredler' fullname='Hannes Gredler'> initials="W" surname="Henderickx" fullname="Wim         Henderickx">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='B' surname='Decraene' fullname='Bruno Decraene'> initials="J" surname="Tantsura" fullname="Jeff Tantsura">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='September' year='2019' /> month="December" year="2019"/>
          </front>

<seriesInfo name='RFC' value='8667' />
<seriesInfo name='DOI' value='10.17487/RFC8667'/>
        </reference>

   <!--   &I-D.ietf-ospf-ospfv3-segment-routing-extensions;-->
        <reference anchor="RFC8666"> anchor="RFC8666" quoteTitle="true" target="https://doi.org/10.17487/RFC8666" derivedAnchor="RFC8666">
          <front>
            <title>OSPFv3 Extensions for Segment Routing</title>
            <seriesInfo name="RFC" value="8666"/>
            <seriesInfo name="DOI" value="10.17487/RFC8666"/>
            <author initials='P' surname='Psenak' fullname='Peter Psenak' initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='S' surname='Previdi' fullname='Stefano Previdi'> initials="S" surname="Previdi" fullname="Stefano Previdi">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='September' year='2019' /> month="December" year="2019"/>
          </front>

<seriesInfo name='RFC' value='8666' />
<seriesInfo name='DOI' value='10.17487/RFC8666'/>
        </reference>

<!--  I-D.ietf-ospf-segment-routing-extensions: I-D exists -->
        <reference anchor="RFC8665"> anchor="RFC8667" quoteTitle="true" target="https://doi.org/10.17487/RFC8667" derivedAnchor="RFC8667">
          <front>
<title>OSPF
            <title>IS-IS Extensions for Segment Routing</title>
            <seriesInfo name="RFC" value="8667"/>
            <seriesInfo name="DOI" value="10.17487/RFC8667"/>
            <author initials='P' surname='Psenak' fullname='Peter Psenak' role="editor">
    <organization />
</author>

<author initials='S' surname='Previdi' fullname='Stefano Previdi' role="editor"> initials="S" surname="Previdi" fullname="Stefano Previdi">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'> initials="L" surname="Ginsberg" fullname="Les Ginsberg">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='H' surname='Gredler' fullname='Hannes Gredler'> initials="C" surname="Filsfils" fullname="Clarence              Filsfils">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='R' surname='Shakir' fullname='Rob Shakir'> initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='W' surname='Henderickx' fullname='Wim Henderickx'> initials="H" surname="Gredler" fullname="Hannes Gredler">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='J' surname='Tantsura' fullname='Jeff Tantsura'> initials="B" surname="Decraene" fullname="Bruno Decraene">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='September' year='2019' /> month="December" year="2019"/>
          </front>

<seriesInfo name='RFC' value='8665' />
<seriesInfo name='DOI' value='10.17487/RFC8665'/>
        </reference>
      </references>
    </references>
    <section anchor="Appendix-A" title="Migration numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-migration-from-ldp-to-sr">Migration from LDP to SR"> SR</name>
      <figure anchor="ref-migration" title="Migration">
        <artwork><![CDATA[ align="left" suppress-title="false" pn="figure-5">
        <name slugifiedName="name-migration">Migration</name>
        <artwork name="" type="" align="left" alt="" pn="section-appendix.a-1.1">
                            PE2        PE4
                              \        /
                       PE1----P5--P6--P7---PE3
]]></artwork>
</artwork>
      </figure>

      <t>Several
      <t pn="section-appendix.a-2">Several migration techniques are possible. The technique described
      here is inspired by the commonly used method to migrate from one IGP to
      another.</t>

      <t>At
      <t pn="section-appendix.a-3">At time T0, all the routers run LDP. Any service is tunneled from an
      ingress PE to an egress PE over a continuous LDP LSP.</t>

      <t>At
      <t pn="section-appendix.a-4">At time T1, all the routers are upgraded to SR. They are configured
      with the SRGB range [100, 300]. PE1, PE2, PE3, PE4, P5, P6, and P7 are
      respectively configured with the node segments 101, 102, 103, 104, 105,
      106, and 107 (attached to their service-recursing loopback).</t>

      <t><list hangIndent="3" style="hanging">
          <t>At loopback).
</t>
      <aside pn="section-appendix.a-5">
        <t pn="section-appendix.a-5.1">
          Note: At this time, the service traffic is still tunneled over LDP LSPs.
          For example, PE1 has an SR node segment to PE3 and an LDP LSP to PE3.
          As seen earlier, however, the LDP IP2MPLS encapsulation is
          preferred by default. However, it has to be noted that the SR infrastructure is
          usable, e.g., for Fast Reroute (FRR) or IGP Loop-Free Convergence to
          protect existing IP and LDP traffic. FRR mechanisms are described in
          <xref target="RFC8355"/>.</t>
        </list></t>

      <t>At target="RFC8355" format="default" sectionFormat="of" derivedContent="RFC8355"/>.
</t>
      </aside>
      <t pn="section-appendix.a-6">At time T2, the operator enables the local policy at PE1 to prefer SR
      IP2MPLS encapsulation over LDP IP2MPLS.</t>

      <t><list hangIndent="3" style="hanging">
          <t>The
      <ul empty="true" indent="3" bare="false" spacing="normal" pn="section-appendix.a-7">
        <li pn="section-appendix.a-7.1">The service from PE1 to any other PE is now riding over SR. All
          other service traffic is still transported over LDP LSPs.</t>
        </list></t>

      <t>At LSPs.</li>
      </ul>
      <t pn="section-appendix.a-8">At time T3, gradually, the operator enables the preference for SR
      IP2MPLS encapsulation across all the edge routers.</t>

      <t><list hangIndent="3" style="hanging">
          <t>All
      <ul empty="true" indent="3" bare="false" spacing="normal" pn="section-appendix.a-9">
        <li pn="section-appendix.a-9.1">All the service traffic is now transported over SR. LDP is still
          operational and services could be reverted to LDP.</t>
        </list></t>

      <t><list hangIndent="3" style="hanging">
          <t/>
        </list></t>

      <t>At LDP.</li>
      </ul>
      <t pn="section-appendix.a-10">At time T4, LDP is unconfigured from all routers.</t>
    </section>
    <section anchor="section-9" title="Acknowledgements" numbered= "no">
      <t>The anchor="sec-9" 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 Pierre Francois, Ruediger Geib, and
      Alexander Vainshtein for their contributions to the content of this
      document.</t>
    </section>
    <section anchor="section-10" title="Contributors" numbered="no">
      <figure>
        <artwork><![CDATA[ anchor="sec-10" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-1">
Edward Crabbe
Individual
Email: edward.crabbe@gmail.com edward.crabbe@gmail.com</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-2">
Igor Milojevic
Email: milojevicigor@gmail.com milojevicigor@gmail.com</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-3">
Saku Ytti
TDC
Email: saku@ytti.fi saku@ytti.fi</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-4">
Rob Shakir
Google
Email: robjs@google.com robjs@google.com</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-5">
Martin Horneffer
Deutsche Telekom
Email: Martin.Horneffer@telekom.de Martin.Horneffer@telekom.de</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-6">
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com wim.henderickx@nokia.com</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-7">
Jeff Tantsura
Apstra, Inc.
Email: jefftant.ietf@gmail.com jefftant.ietf@gmail.com</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.c-8">
Les Ginsberg
Cisco Systems
Email: ginsberg@cisco.com]]></artwork>
      </figure> ginsberg@cisco.com</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">Individual</organization>
        <address>
          <postal>
            <street>United States of America</street>
          </postal>
          <email>abashandy.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Clarence Filsfils" initials="C." role="editor" surname="Filsfils">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street>Brussels</street>
            <street>Belgium</street>
          </postal>
          <email>cfilsfil@cisco.com</email>
        </address>
      </author>
      <author fullname="Stefano Previdi" initials="S." surname="Previdi">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>Italy</street>
          </postal>
          <email>stefano@previdi.net</email>
        </address>
      </author>
      <author fullname="Bruno Decraene" initials="B." surname="Decraene">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street>France</street>
          </postal>
          <email>bruno.decraene@orange.com</email>
        </address>
      </author>
      <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street>France</street>
          </postal>
          <email>slitkows.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>