<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" docName="draft-ietf-isis-segment-routing-extensions-25"
     ipr="trust200902"> consensus="true" number="8667" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" docName="draft-ietf-pce-segment-routing-16">
  <!-- xml2rfc v2v3 conversion 2.27.1 -->
  <front>
    <title abbrev="IS-IS Extensions for Segment Routing">IS-IS Extensions for
    Segment Routing</title>
    <seriesInfo name="RFC" value="8667"/>
    <author fullname="Stefano Previdi" initials="S." role="editor" surname="Previdi">
      <organization>Huawei</organization>
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>

          <country>IT</country>
          <country>Italy</country>
        </postal>
        <email>stefano@previdi.net</email>
      </address>
    </author>
    <author fullname="Les Ginsberg" initials="L." role="editor" surname="Ginsberg">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>ginsberg@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>Brussels</city>
          <region/>
          <code/>

          <country>BE</country>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Ahmed Bashandy" initials="A." surname="Bashandy">
      <organization>Arrcus</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <country/>
        </postal>
        <email>abashandy.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Hannes Gredler" initials="H." surname="Gredler">
      <organization>RtBrick Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>hannes@rtbrick.com</email>
      </address>
    </author>
    <author fullname="Bruno Decraene" initials="B." surname="Decraene">
      <organization>Orange</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>

          <country>FR</country>
          <country>France</country>
        </postal>
        <email>bruno.decraene@orange.com</email>
      </address>
    </author>
    <date day="19" month="May" year="2019"/> year="2019" month="December"/>
    <area>Routing</area>
    <workgroup>IS-IS for IP Internets</workgroup>
    <keyword>MPLS</keyword>
    <keyword>SID</keyword>
    <keyword>IGP</keyword>
    <keyword>IS-IS</keyword>
    <keyword>Label advertisement</keyword>
    <keyword>Segment Routing</keyword>
    <abstract>
      <t>Segment Routing (SR) allows for a flexible definition of end-to-end
      paths within IGP topologies by encoding paths as sequences of
      topological sub-paths, called "segments". These segments are advertised
      by the link-state routing protocols (IS-IS and OSPF).</t>
      <t>This draft document describes the necessary IS-IS extensions that need to be
      introduced for Segment Routing operating on an MPLS data-plane.</t> data plane.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Segment Routing (SR) allows for a flexible definition of end-to-end
      paths within IGP topologies by encoding paths as sequences of
      topological sub-paths, called "segments". These segments are advertised
      by the link-state routing protocols (IS-IS and OSPF). Prefix segments
      represent an ECMP-aware shortest-path shortest path to a prefix (or a node), as per
      the state of the IGP topology. Adjacency segments represent a hop over a
      specific adjacency between two nodes in the IGP. A prefix segment is
      typically a multi-hop path while an adjacency segment, in most of the
      cases, is a one-hop path. SR's control-plane control plane can be applied to both IPv6
      and MPLS data-planes, data planes and does not require any additional signaling
      (other than the regular IGP). For example, when used in MPLS networks,
      SR paths do not require any LDP or RSVP-TE signaling. Still, SR can
      interoperate in the presence of LSPs Label Switched Paths (LSPs) established with RSVP or LDP.</t>
      <t>There are additional segment types, e.g., the Binding SID as defined in
      <xref target="RFC8402"/>. target="RFC8402" format="default"/>. This document also defines an advertisement
      for one type of Binding SID: the Mirror Context segment.</t>
      <t>This draft document describes the necessary IS-IS extensions that need to be
      introduced for Segment Routing operating on an MPLS data-plane.</t> data plane.</t>
      <t>The Segment Routing architecture is described in <xref
      target="RFC8402"/>.</t>

      <t>Segment target="RFC8402" format="default"/>.  Segment Routing use cases are described in <xref
      target="RFC7855"/>.</t> target="RFC7855" format="default"/>.</t>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
    when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section title="Segment numbered="true" toc="default">
      <name>Segment Routing Identifiers"> Identifiers</name>
      <t>The Segment Routing architecture <xref target="RFC8402"/> target="RFC8402" format="default"/> defines
      different types of Segment Identifiers (SID). (SIDs). This document defines the
      IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment,
      the IGP-LAN-Adjacency Segment Segment, and the Binding Segment.</t>
      <section anchor="PREFIXSIDSUBTLV"
               title="Prefix numbered="true" toc="default">
        <name>Prefix Segment Identifier (Prefix-SID Sub-TLV)"> (Prefix-SID) Sub-TLV</name>
        <t>A new IS-IS sub-TLV is defined: the Prefix Segment Identifier
        sub-TLV (Prefix-SID sub-TLV).</t>
        (Prefix-SID) sub-TLV.</t>
        <t>The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID
        as defined in <xref target="RFC8402"/>. target="RFC8402" format="default"/>. The 'Prefix SID' MUST 'Prefix-SID' <bcp14>MUST</bcp14> be
        unique within a given IGP domain (when the L-flag L-Flag is not set).</t>
        <t>A Prefix-SID sub-TLV is associated to a prefix advertised by a node
        and MAY <bcp14>MAY</bcp14> be present in any of the following TLVs: <list style="hanging">
            <t>TLV-135 </t>

        <ul empty="true">
          <li>TLV-135 (Extended IPv4 reachability) defined in <xref
            target="RFC5305"/>.</t>

            <t>TLV-235 (Multitopology target="RFC5305" format="default"/>.</li>

          <li>TLV-235 (Multi-topology IPv4 Reachability) defined in <xref
            target="RFC5120"/>.</t>

            <t>TLV-236 target="RFC5120" format="default"/>.</li>

          <li>TLV-236 (IPv6 IP Reachability) defined in <xref
            target="RFC5308"/>.</t>

            <t>TLV-237 (Multitopology target="RFC5308" format="default"/>.</li>

          <li>TLV-237 (Multi-topology IPv6 IP Reachability) defined in <xref
            target="RFC5120"/>.</t>

            <t>Binding-TLV target="RFC5120" format="default"/>.</li>

          <li>The Binding TLV and Multi-Topology Binding-TLV Binding TLV are defined in Sections <xref
            target="BINDINGTLV"/> target="BINDINGTLV" format="counter"/> and <xref target="MTBINDINGTLV"/>
            respectively.</t>
          </list></t> target="MTBINDINGTLV" format="counter"/>,
            respectively.</li>
        </ul>

        <t>The Prefix-SID sub-TLV has the following format:<figure>
            <artwork><![CDATA[ format:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |     Flags     |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         SID/Index/Label (variable)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:]]></artwork>
          </figure><list style="hanging">
            <t>Type: 3</t>

            <t>Length: 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>where:</t>
<ul empty="true">
<li>
        <dl newline="false" spacing="normal" indent="9">
          <dt>Type:</dt><dd>3</dd>
          <dt>Length:</dt><dd>5 or 6 depending on the size of the SID (described
            below)</t>

            <t>Flags: 1 octet
            below)</dd>
            <dt>
            Flags:</dt><dd><t> 1-octet field of the following flags: <figure>
                <artwork><![CDATA[ flags:</t>

            <artwork name="" type="" align="left" alt=""><![CDATA[
       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |R|N|P|E|V|L|   |
+-+-+-+-+-+-+-+-+
 ]]></artwork>
              </figure>
      +-+-+-+-+-+-+-+-+]]></artwork>
      <t> where: <list style="hanging">
                <t>R-Flag: Re-advertisement flag. </t>
          <dl newline="false" spacing="normal" indent="9">
              <dt>R-Flag:</dt><dd>Re-advertisement Flag. If set, then the prefix to
                which this Prefix-SID is attached, attached has been propagated by the
                router either from either another level (i.e., from level-1 Level-1 to
                level-2
                Level-2 or the opposite) or from redistribution (e.g.: (e.g., from
                another protocol).</t>

                <t>N-Flag: Node-SID flag. protocol).</dd>
              <dt>N-Flag:</dt><dd>Node-SID Flag. If set, then the Prefix-SID refers
                to the router identified by the prefix. Typically, the N-Flag
                is set on Prefix-SIDs that are attached to a router loopback address.
                The N-Flag is set when the Prefix-SID is a Node-SID as
                described in <xref target="RFC8402"/>.</t>

                <t>P-Flag: no-PHP flag. target="RFC8402" format="default"/>.</dd>
              <dt>P-Flag:</dt><dd>No-PHP
(No Penultimate Hop-Popping) Flag. If set, then the penultimate hop MUST
                NOT <bcp14>MUST
                NOT</bcp14> pop the Prefix-SID before delivering the packet to the
                node that advertised the Prefix-SID.</t>

                <t>E-Flag: Explicit-Null Prefix-SID.</dd>
              <dt>E-Flag:</dt><dd>Explicit NULL Flag. If set, any upstream neighbor
                of the Prefix-SID originator MUST <bcp14>MUST</bcp14> replace the Prefix-SID with
              a Prefix-SID having that has an Explicit-NULL Explicit NULL value (0 for IPv4 and 2
                for IPv6) before forwarding the packet.</t>

                <t>V-Flag: Value flag. packet.</dd>
              <dt>V-Flag:</dt><dd>Value Flag. If set, then the Prefix-SID carries a
                value (instead of an index). By default default, the flag is UNSET.</t>

                <t>L-Flag: Local UNSET.</dd>
              <dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index carried by
                the Prefix-SID has local significance. By default default, the flag is
                UNSET.</t>

                <t>Other bits: MUST
                UNSET.</dd>
              <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when originated and ignored when
                received.</t>
              </list></t>

            <t>Algorithm: the
                received.</dd>
          </dl>
        </dd>
       </dl>
      </li>
     </ul>
  	<ul empty="true">
          <li><dl newline="false" spacing="normal">

          <dt>Algorithm:</dt><dd>the router may use various algorithms when
            calculating reachability to other nodes or to prefixes attached to
            these nodes. Algorithm identifiers are defined in <xref
            target="SRALGOSUBTLV"/>. target="SRALGOSUBTLV" format="default"/>. Examples of these algorithms are metric
            based metric-based
            Shortest Path First (SPF), various sorts of Constrained SPF,
            etc. The algorithm Algorithm field of the Prefix-SID contains the identifier
            of the algorithm the router uses to compute the reachability of
            the prefix to which the Prefix-SID is associated.</t>

            <t>At associated.</dd>
           </dl></li></ul>

        <ul empty="true">
        <li>
          At origination, the Prefix-SID algorithm Algorithm field MUST <bcp14>MUST</bcp14> be set to 0
            or to any value advertised in the SR-Algorithm sub-TLV (<xref
            target="SRALGOSUBTLV"/>).</t>

            <t>A (see <xref target="SRALGOSUBTLV" format="default"/>).</li>

          <li>A router receiving a Prefix-SID from a remote node and with an
            algorithm value that such remote node has not advertised in the
            SR-Algorithm sub-TLV (<xref target="SRALGOSUBTLV"/>) MUST (see <xref target="SRALGOSUBTLV" format="default"/>) <bcp14>MUST</bcp14> ignore
            the Prefix-SID sub-TLV.</t>

            <t>SID/Index/Label sub-TLV.</li>

          <li>SID/Index/Label as defined in <xref target="VANDLFLAGS"/>.</t>
          </list></t> target="VANDLFLAGS" format="default"/>.</li>
      </ul>
        <t>When the Prefix SID Prefix-SID is an index (the V-flag (and the V-Flag is not set) set), the value
        is used to determine the actual label value inside the set of all
        advertised label ranges of a given router. This allows a receiving
        router to construct the forwarding state to a particular destination
        router.</t>
        <t>In many use-cases use cases, a 'stable transport' address is overloaded as an
        identifier of a given node. Because Prefixes may be re-advertised into
        other levels levels, there may be some ambiguity (e.g. Originating (e.g., originating router vs. L1L2 router) for which node a particular IP prefix serves as the
        identifier. The Prefix-SID sub-TLV contains the necessary flags to
        disambiguate Prefix to node Prefix-to-node mappings. Furthermore Furthermore, if a given node has
        several 'stable transport' addresses addresses, there are flags to differentiate
        those among other Prefixes advertised from a given node.</t>

        <section anchor="FLAGS" title="Flags"> numbered="true" toc="default">
          <name>Flags</name>
          <section anchor="VANDLFLAGS" title="V numbered="true" toc="default">
            <name>V-Flag and L Flags"> L-Flag</name>
            <t>The V-flag V-Flag indicates whether the SID/Index/Label field is a
            value or an index.</t>

            <t>The L-Flag indicates whether the value/index in the
            SID/Index/Label field has local or global significance.</t>

            <t>The following settings for V V-Flag and L flags L-Flag are valid:</t>

            <t>V-flag is set to 0
        <ul empty="true"><li>
         <dl>
            <dt>The V-Flag and L-flag is L-Flag are set to 0: The 0:</dt><dd>The SID/Index/Label
            field is a 4 octet 4-octet index defining the offset in the SID/Label
            space advertised by this router using the encodings defined in
            <xref target="SRCAPSUBTLV"/>.</t>

            <t>V-flag is set to 1 target="SRCAPSUBTLV" format="default"/>.</dd>

            <dt>The V-Flag and L-flag is L-Flag are set to 1: The 1:</dt><dd>The SID/Index/Label
            field is a 3 octet 3-octet local label where the 20 rightmost bits are
            used for encoding the label value.</t> value.</dd>
         </dl>
        </li>
	</ul>

            <t>All other combinations of V-flag V-Flag and L-flag L-Flag are invalid invalid, and any
            SID advertisement received with an invalid setting for V the V-Flag and L
            flags MUST
            L-Flag <bcp14>MUST</bcp14> be ignored.</t>
          </section>

          <section anchor="RANDNFLAGS" title="R numbered="true" toc="default">
            <name>R-Flag and N Flags"> N-Flag</name>
            <t>The R-Flag MUST <bcp14>MUST</bcp14> be set for prefixes that are not local to the
            router and either:<list style="hanging">
                <t>advertised are advertised because of propagation of:</t>

            <ul empty="true">
              <li>propagation (Level-1 into
                Level-2);</t>

                <t>advertised because of leaking Level-2);</li>
              <li>leaking (Level-2 into Level-1);</t>

                <t>advertised because of redistribution (e.g.: Level-1); or</li>
              <li>redistribution (e.g., from another
                protocol).</t>
              </list></t> protocol).</li>
            </ul>

            <t>In the case where a Level-1-2 router has local interface
            addresses configured in one level, it may also propagate these
            addresses into the other level. In such case, the Level-1-2 router
            MUST NOT
            <bcp14>MUST NOT</bcp14> set the R bit.</t>
            <t>The N-Flag is used in order to define a Node-SID. A router MAY <bcp14>MAY</bcp14>
            set the N-Flag only if all of the following conditions are
            met:<list style="hanging">
                <t>The
            met:</t>

             <ul empty="true">
              <li>The prefix to which the Prefix-SID is attached is local to
                the router (i.e., the prefix is configured on one of the local
                interfaces, e.g., a 'stable transport' loopback).</t>

                <t>The loopback).</li>
              <li>The prefix to which the Prefix-SID is attached has a Prefix
                length of either /32 (IPv4) or /128 (IPv6).</t>
              </list></t> (IPv6).</li>
            </ul>

            <t>The router MUST <bcp14>MUST</bcp14> ignore the N-Flag on a received Prefix-SID if
            the prefix has a Prefix length different than /32 (IPv4) or /128
            (IPv6).</t>
            <t>The Prefix Attributes Attribute Flags sub-TLV <xref target="RFC7794"/> target="RFC7794" format="default"/>
            also defines the N N-Flag and R flags R-Flag and with the same semantics of the
            equivalent flags defined in this document. Whenever the Prefix
            Attributes
            Attribute Flags sub-TLV is present for a given prefix prefix, the values
            of the N N-Flag and R flags R-Flag advertised in that sub-TLV MUST <bcp14>MUST</bcp14> be used used, and
            the values in a corresponding Prefix SID Prefix-SID sub-TLV (if present) MUST <bcp14>MUST</bcp14>
            be ignored.</t>
          </section>
          <section anchor="EANDPFLAGS" title="E numbered="true" toc="default">
            <name>E-Flag and P Flags"> P-Flag</name>
            <t>The following behavior is associated with the settings of the E E-Flag
            and P flags:<list style="symbols">
                <t>If P-Flag:</t>
            <ul spacing="normal">
              <li>If the P-flag P-Flag is not set set, then any upstream neighbor of the
                Prefix-SID originator MUST <bcp14>MUST</bcp14> pop the Prefix-SID. This is
                equivalent to the penultimate hop popping "penultimate hop-popping" mechanism used in
                the MPLS dataplane data plane, which improves performance of the ultimate
                hop. MPLS EXP bits of the Prefix-SID are not preserved to the
                ultimate hop (the Prefix-SID being removed). If the P-flag P-Flag is
                unset
                unset, the received E-flag E-Flag is ignored.</t> ignored.</li>
              <li>
                <t>If the P-flag P-Flag is set then:<list style="symbols">
                    <t>If set, then:</t>
                <ul spacing="normal">
                  <li>If the E-flag E-Flag is not set set, then any upstream neighbor of
                    the Prefix-SID originator MUST <bcp14>MUST</bcp14> keep the Prefix-SID on top
                    of the stack. This is useful when, e.g., the originator of
                    the Prefix-SID must stitch the incoming packet into a
                    continuing MPLS LSP to the final destination. This could
                    occur at an inter-area border router (prefix propagation
                    from one area to another) or at an inter-domain interdomain border
                    router (prefix propagation from one domain to
                    another).</t>

                    <t>If
                    another).</li>
                  <li>If the E-flag E-Flag is set set, then any upstream neighbor of the
                    Prefix-SID originator MUST <bcp14>MUST</bcp14> replace the PrefixSID Prefix-SID with a
                    Prefix-SID having an Explicit-NULL Explicit NULL value. This is useful,
                    e.g., when the originator of the Prefix-SID is the final
                    destination for the related prefix and the originator
                    wishes to receive the packet with the original EXP
                    bits.</t>
                  </list></t>
              </list></t>
                    bits.</li>
                </ul>
              </li>
            </ul>
            <t>When propagating (either from (from either Level-1 to Level-2 or vice versa) Level-2 to Level-1)
            a reachability advertisement originated by another IS-IS speaker,
            the router MUST <bcp14>MUST</bcp14> set the P-flag P-Flag and MUST <bcp14>MUST</bcp14> clear the E-flag E-Flag of the
            related Prefix-SIDs.</t>
          </section>
        </section>

        <section anchor="PROPAGATION" title="Prefix-SID Propagation"> numbered="true" toc="default">
          <name>Prefix-SID Propagation</name>
          <t>The Prefix-SID sub-TLV MUST <bcp14>MUST</bcp14> be included when the associated
          Prefix Reachability TLV is propagated across level boundaries.</t>
          <t>The level-1-2 Level-1-2 router that propagates the Prefix-SID sub-TLV
          between levels maintains the content (flags and SID) SID), except as noted
          in Sections <xref target="RANDNFLAGS"/> target="RANDNFLAGS" format="counter"/> and <xref target="EANDPFLAGS"/>.</t> target="EANDPFLAGS" format="counter"/>.</t>
       </section>
      </section>
      <section title="Adjacency numbered="true" toc="default">
        <name>Adjacency Segment Identifier "> Identifier</name>
        <t>A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier
        sub-TLV (Adj-SID sub-TLV).</t> (Adj-SID)
        sub-TLV.</t>
        <t>The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment
        Routing IGP-Adjacency-SID as defined in <xref target="RFC8402"/> target="RFC8402" format="default"/> with
        flags and fields that may be used, in future extensions of Segment
        Routing, for carrying other types of SIDs.</t>
        <t>IS-IS adjacencies are advertised using one of the IS-Neighbor IS Neighbor TLVs
        below:<list style="hanging">
            <t>TLV-22
        below:</t>
        <ul empty="true">
          <li>TLV-22 (Extended IS reachability)<xref target="RFC5305"/></t>

            <t>TLV-222 (Multitopology IS)<xref target="RFC5120"/></t>

            <t>TLV-23 reachability) <xref target="RFC5305" format="default"/></li>
          <li>TLV-222 (MT-ISN) <xref target="RFC5120" format="default"/></li>
          <li>TLV-23 (IS Neighbor Attribute)<xref target="RFC5311"/></t>

            <t>TLV-223 (Multitopology Attribute) <xref target="RFC5311" format="default"/></li>
          <li>TLV-223 (MT IS Neighbor Attribute)<xref
            target="RFC5311"/></t>

            <t>TLV-141 Attribute) <xref target="RFC5311" format="default"/></li>
          <li>TLV-141 (inter-AS reachability information)<xref
            target="RFC5316"/></t>
          </list></t> information) <xref target="RFC5316" format="default"/></li>
        </ul>
        <t>Multiple Adj-SID sub-TLVs MAY <bcp14>MAY</bcp14> be associated with a single
        IS-neighbor.</t>
        IS Neighbor.</t>

        <section anchor="ADJSIDSUBTLV"
                 title="Adjacency numbered="true" toc="default">
          <name>Adjacency Segment Identifier (Adj-SID) Sub-TLV"> Sub-TLV</name>

          <t>The following format is defined for the Adj-SID sub-TLV:<figure>
              <artwork><![CDATA[ sub-TLV:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |     Flags     |     Weight    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         SID/Label/Index (variable)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:]]></artwork>
            </figure><list style="hanging">
              <t>Type: 31</t>

              <t>Length: 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>where:</t>
<ul empty="true"><li>
          <dl newline="false" spacing="normal" indent="9">
            <dt>Type:</dt><dd>31</dd>
            <dt>Length:</dt><dd>5 or 6 depending on size of the SID</t>

              <t>Flags: 1 octet SID</dd>
            <dt>Flags:</dt><dd><t>1-octet field of the following flags: <figure>
                  <artwork><![CDATA[ flags:</t>
              <artwork name="" type="" align="left" alt=""><![CDATA[       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |F|B|V|L|S|P|   |
      +-+-+-+-+-+-+-+-+
]]></artwork>
                </figure>
      +-+-+-+-+-+-+-+-+]]></artwork>
              <t> where: <list style="hanging">
                  <t>F-Flag: Address-Family flag. </t>
              <dl newline="false" spacing="normal" indent="9">

                <dt>F-Flag:</dt><dd>Address-Family Flag. If unset, then the Adj-SID
                  is used when forwarding IPv4 encapsulated IPv4-encapsulated traffic to the
                  neighbor. If set set, then the Adj-SID is used when forwarding
                  IPv6 encapsulated
                  IPv6-encapsulated traffic to the neighbor.</t>

                  <t>B-Flag: Backup flag. neighbor.</dd>

                <dt>B-Flag:</dt><dd>Backup Flag. If set, the Adj-SID is eligible for
                  protection (e.g.: (e.g., using IPFRR IP Fast Reroute (IPFRR) or MPLS-FRR) MPLS Fast Reroute (MPLS-FRR)) as described in
                  <xref target="RFC8402"/>.</t>

                  <t>V-Flag: Value flag. target="RFC8402" format="default"/>.</dd>

                <dt>V-Flag:</dt><dd>Value Flag. If set, then the Adj-SID carries a
                  value. By default default, the flag is SET.</t>

                  <t>L-Flag: Local SET.</dd>

                <dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index carried
                  by the Adj-SID has local significance. By default default, the flag
                  is SET.</t>

                  <t>S-Flag. Set flag. SET.</dd>

                <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that the
                  Adj-SID refers to a set of adjacencies (and therefore MAY <bcp14>MAY</bcp14> be
                  assigned to other adjacencies as well).</t>

                  <t>P-Flag. Persistent flag. well).</dd>

                <dt>P-Flag:</dt><dd>Persistent Flag. When set, the P-Flag indicates
                  that the Adj-SID is persistently allocated, i.e., the
                  Adj-SID value remains consistent across router restart
                  and/or interface flap.</t>

                  <t>Other bits: MUST flap.</dd>

                <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when originated and ignored when
                  received.</t>
                </list></t>

              <t>Weight: 1
                  received.</dd>
              </dl>
            </dd>
	  </dl>
         </li>
	</ul>
          <ul empty="true">
          <li><dl newline="false" spacing="normal" indent="9">

            <dt>Weight:</dt><dd>1 octet. The value represents the weight of the
              Adj-SID for the purpose of load balancing. The use of the weight
              is defined in <xref target="RFC8402"/>.</t>

              <t>SID/Index/Label target="RFC8402" format="default"/>.</dd>
           </dl>
          </li>
         </ul>

        <ul empty="true">
        <li>SID/Index/Label as defined in <xref
              target="VANDLFLAGS"/>.</t>

              <t>An SR capable target="VANDLFLAGS" format="default"/>.</li>

            <li>An SR-capable router MAY <bcp14>MAY</bcp14> allocate an Adj-SID for each of its
              adjacencies</t>

              <t>An SR capable
              adjacencies.</li>

            <li>An SR-capable router MAY <bcp14>MAY</bcp14> allocate more than one Adj-SID to an
              adjacency.</t>

              <t>An SR capable
              adjacency.</li>

            <li>An SR-capable router MAY <bcp14>MAY</bcp14> allocate the same Adj-SID to
              different adjacencies.</t>

              <t>When adjacencies.</li>

            <li>When the P-flag P-Flag is not set, the Adj-SID MAY <bcp14>MAY</bcp14> be persistent.
              When the P-flag P-Flag is set, the Adj-SID MUST <bcp14>MUST</bcp14> be persistent.</t>

              <t>Examples of use persistent.</li>

            <li>Examples of the Adj-SID sub-TLV use are described in <xref
              target="RFC8402"/>.</t>

              <t>The F-flag target="RFC8402" format="default"/>.</li>

            <li>The F-Flag is used in order for the router to advertise the
              outgoing encapsulation of the adjacency the Adj-SID is attached
              to.</t>
            </list></t>
              to.</li>
          </ul>
        </section>

        <section anchor="LANADJSIDSUBTLV"
                 title="Adjacency numbered="true" toc="default">
          <name>Adjacency Segment Identifiers in LANs"> Identifier (LAN-Adj-SID) Sub-TLV</name>
          <t>In LAN subnetworks, the Designated Intermediate System (DIS) is
          elected and originates the Pseudonode-LSP (PN-LSP) Pseudonode LSP (PN LSP) including all
          neighbors of the DIS.</t>
          <t>When Segment Routing is used, each router in the LAN MAY <bcp14>MAY</bcp14>
          advertise the Adj-SID of each of its neighbors. Since, on LANs, each
          router only advertises one adjacency to the DIS (and doesn't
          advertise any other adjacency), each router advertises the set of
          Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV
          that is a part of the TLV advertising the adjacency to the DIS (e.g.: (e.g.,
          TLV-22).</t>
          <t>The following new sub-TLV is defined: LAN-Adj-SID LAN Adjacency Segment Identifier (LAN-Adj-SID) containing the
          set of Adj-SIDs the router assigned to each of its LAN
          neighbors.</t>
          <t>The format of the LAN-Adj-SID sub-TLV is as follows:<figure>
              <artwork><![CDATA[ follows:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |      Flags    |    Weight     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Neighbor System-ID (ID length octets)        |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID/Label/Index (variable)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where: ]]></artwork>
            </figure><list style="hanging">
              <t>Type: 32</t>

              <t>Length: variable.</t>

              <t>Flags: 1 octet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
  <t>where:</t>
  <ul empty="true"><li>
          <dl newline="false" spacing="normal" indent="9">

            <dt>Type:</dt><dd>32</dd>

            <dt>Length:</dt><dd>Variable</dd>

            <dt>Flags:</dt><dd><t> 1-octet field of the following flags: <figure>
                  <artwork><![CDATA[ flags:</t>

              <artwork name="" type="" align="left" alt=""><![CDATA[       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |F|B|V|L|S|P|   |
      +-+-+-+-+-+-+-+-+
]]></artwork>
                </figure>
      +-+-+-+-+-+-+-+-+]]></artwork>
              <t> where F, B, V, L, S the F-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and P flags P-Flag are defined in <xref
              target="ADJSIDSUBTLV"/>. Other bits: MUST target="ADJSIDSUBTLV" format="default"/>. </t>
	    </dd>
           </dl>
          </li>
         </ul>
          <ul empty="true"><li>
              <dl newline="false" spacing="normal" indent="13">
              <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when
              originated and ignored when received.</t>

              <t>Weight: 1 received.</dd>

            <dt>Weight:</dt><dd>1 octet. The value represents the weight of the
              Adj-SID for the purpose of load balancing. The use of the weight
              is defined in <xref target="RFC8402"/>.</t>

              <t>Neighbor System-ID: IS-IS target="RFC8402" format="default"/>.</dd>

            <dt>Neighbor System-ID:</dt><dd>IS-IS System-ID of length "ID Length" as
              defined in <xref target="ISO10589"/>.</t>

              <t>SID/Index/Label as target="ISO10589" format="default"/>.</dd>

            <dt>SID/Index/Label:</dt><dd>As defined in <xref
              target="VANDLFLAGS"/>.</t>
            </list></t> target="VANDLFLAGS" format="default"/>.</dd>
          </dl>
      </li>
     </ul>

          <t>Multiple LAN-Adj-SID sub-TLVs MAY <bcp14>MAY</bcp14> be encoded.</t>
          <t>Note that this sub-TLV MUST NOT <bcp14>MUST NOT</bcp14> appear in TLV 141.</t>
          <t>In case one TLV-22/23/222/223 TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency to the
          DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple
          advertisements of the adjacency to the DIS MUST <bcp14>MUST</bcp14> be used used, and all
          advertisements MUST <bcp14>MUST</bcp14> have the same metric.</t>
          <t>Each router within the level, by receiving the DIS PN LSP as well
          as the non-PN LSP of each router in the LAN, is capable of
          reconstructing the LAN topology as well as the set of Adj-SIDs each
          router uses for each of its neighbors.</t>
        </section>
      </section>

      <section anchor="SIDLABELSUBTLV" title="SID/Label Sub-TLV"> numbered="true" toc="default">
        <name>SID/Label Sub-TLV</name>
        <t>The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs
        defined in this document:</t>

        <t>SR-Capabilities Sub-TLV
        <ul empty="true">
        <li>SR-Capabilities sub-TLV (<xref target="SRCAPSUBTLV"/>)</t>

        <t>SR target="SRCAPSUBTLV" format="default"/>)</li>
        <li>SR Local Block Sub-TLV sub-TLV (<xref target="SRLBSUBTLV"/>)</t>

        <t>SID/Label target="SRLBSUBTLV" format="default"/>)</li>
        <li>SID/Label Binding TLV (<xref target="BINDINGTLV"/>)</t>

        <t>Multi-Topology target="BINDINGTLV" format="default"/>)</li>
        <li>Multi-Topology SID/Label Binding TLV (<xref
        target="MTBINDINGTLV"/>)</t> target="MTBINDINGTLV" format="default"/>)</li>
        </ul>

        <t>Note that the code point codepoint used in all of the above cases is the
        SID/Label Sub-TLV code point sub-TLV codepoint specified in the new &ldquo;sub-TLVs "sub-TLVs for
        TLV 149 and 150&rdquo; 150" registry created by this document.</t>
        <t>The SID/Label sub-TLV contains a SID or a an MPLS Label. label. The SID/Label
        sub-TLV has the following format: <figure>
            <artwork><![CDATA[ </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SID/Label (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:]]></artwork>
          </figure><list>
            <t>Type: 1</t>

            <t>Length: 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
<t>where:</t>
          <ul empty="true"><li>
          <dl newline="false" spacing="normal" indent="12">

          <dt>Type:</dt><dd>1</dd>

          <dt>Length:</dt><dd>3 or 4</t>

            <t>SID/Label: if 4</dd>

          <dt>SID/Label:</dt><dd>If the length is set to 3 3, then the 20 rightmost bits
            represent a an MPLS label. If the length is set to 4 4, then the value is a
            32 bit index</t>
          </list></t>
            32-bit index.</dd>
        </dl>
      </li>
     </ul>
      </section>

      <section anchor="BINDINGTLV" title="SID/Label numbered="true" toc="default">
        <name>SID/Label Binding TLV"> TLV</name>
        <t>The SID/Label Binding TLV MAY <bcp14>MAY</bcp14> be originated by any router in an
        IS-IS domain. There are multiple uses of the SID/Label Binding
        TLV.</t>
        <t>The SID/Label Binding TLV may be used to advertise prefixes to
        SID/Label mappings. This functionality is called the Segment Routing
        Mapping Server (SRMS). The behavior of the SRMS is defined in <xref
        target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t> target="RFC8661" format="default"/>.</t>
        <t>The SID/Label Binding TLV may also be used to advertise a Mirror
        SID to advertise indicating the ability of a node to process traffic originally destined to
        another IGP node. This behavior is defined in <xref
        target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
        <t>The SID/Label Binding TLV has the following format:</t>

        <figure anchor="SID-MPLS-Binding-TLV-figure"
                title="SID/Label Binding TLV format">
          <artwork><![CDATA[

          <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |     Flags     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range              | Prefix Length |     Prefix    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //               Prefix (continued, variable)                  //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Sub-TLVs (variable)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="symbols">
            <t>Type: 149</t>

            <t>Length: variable.</t>

            <t>1 octet of flags</t>

            <t>1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
     <t>where:</t>
       <ul empty="true"><li>
          <dl newline="false" spacing="normal" indent="12">
          <dt>Type:</dt><dd>149</dd>
          <dt>Length:</dt><dd>Variable</dd>
          <dt>Flags:</dt><dd>1 octet</dd>
          <dt>RESERVED:</dt><dd>1 octet of RESERVED (SHOULD (<bcp14>SHOULD</bcp14> be transmitted as 0 and MUST <bcp14>MUST</bcp14> be
            ignored on receipt)</t>

            <t>2 octets of Range</t>

            <t>1 octet of Prefix Length</t>

            <t>0-16 octets of Prefix</t> receipt)</dd>
          <dt>Range:</dt><dd>2 octets</dd>
          <dt>Prefix Length:</dt><dd>1 octet</dd>
          <dt>Prefix:</dt><dd>0-16 octets</dd></dl>
          <t>sub-TLVs, where each sub-TLV consists of a sequence of: <list
                style="symbols">
                <t>1 of:</t>
            <ul spacing="normal">
              <li>1 octet of sub-TLV type</t>

                <t>1 type</li>
              <li>1 octet of length of the value field of the sub-TLV</t>

                <t>0-243 sub-TLV</li>
              <li>0-243 octets of value</t>
              </list></t>
          </list></t> value</li>
            </ul>
            </li>
            </ul>

        <section title="Flags"> numbered="true" toc="default">
          <name>Flags</name>
          <t>Flags: 1 octet 1-octet field of the following flags:<figure>
              <artwork><![CDATA[ flags:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A|     |
+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure>
+-+-+-+-+-+-+-+-+]]></artwork>
          <t> where: <list style="hanging">
              <t>F-Flag: Address Family flag. </t>
          <ul empty="true"><li>
          <dl newline="false" spacing="normal" indent="9">

            <dt>F-Flag:</dt><dd>Address-Family Flag. If unset, then the Prefix prefix
              carries an IPv4 Prefix. prefix. If set set, then the Prefix prefix carries an IPv6
              Prefix.</t>

              <t>M-Flag: Mirror
              prefix.</dd>

            <dt>M-Flag:</dt><dd>Mirror Context flag. Flag. Set if the advertised SID
              corresponds to a mirrored context. The use of a mirrored context
              is described in <xref target="RFC8402"/>.</t>

              <t>S-Flag: If target="RFC8402" format="default"/>.</dd>

            <dt>S-Flag:</dt><dd>If set, the SID/Label Binding TLV SHOULD <bcp14>SHOULD</bcp14> be flooded
              across the entire routing domain. If the S flag S-Flag is not set, the
              SID/Label Binding TLV MUST NOT <bcp14>MUST NOT</bcp14> be leaked between levels. This
              bit MUST NOT <bcp14>MUST NOT</bcp14> be altered during the TLV leaking.</t>

              <t>D-Flag: when leaking.</dd>

            <dt>D-Flag:</dt><dd>When the SID/Label Binding TLV is leaked from level-2 Level-2
              to level-1, Level-1, the D-Flag MUST <bcp14>MUST</bcp14> be set. Otherwise, this flag MUST <bcp14>MUST</bcp14> be
              clear. SID/Label Binding TLVs with the D-Flag set MUST NOT <bcp14>MUST NOT</bcp14> be
              leaked from level-1 Level-1 to level-2. Level-2. This is to prevent TLV looping
              across levels.</t>

              <t>A-Flag: Attached flag. levels.</dd>

            <dt>A-Flag:</dt><dd>Attached Flag. The originator of the SID/Label
              Binding TLV MAY <bcp14>MAY</bcp14> set the A bit in order to signal that the
              prefixes and SIDs advertised in the SID/Label Binding TLV are
              directly connected to their originators. The mechanisms through
              which the originator of the SID/Label Binding TLV can figure out
              if a prefix is attached or not are outside the scope of this
              document (e.g.: (e.g., through explicit configuration). If the Binding
              TLV is leaked to other areas/levels areas/levels, the A-flag MUST A-Flag <bcp14>MUST</bcp14> be
              cleared.</t>

              <t>An
              cleared.</dd>
	  </dl>
	</li>
       </ul>

          <ul empty="true">
            <li>An implementation may decide not to honor the S-flag S-Flag in order
              not
              to not leak Binding TLV's TLVs between levels (for policy
              reasons).</t>

              <t>Other bits: MUST
              reasons).</li></ul>

         <ul empty="true"><li>
            <dl>
            <dt>Other bits:</dt><dd><bcp14>MUST</bcp14> be zero when originated and ignored when
              received.</t>
            </list></t>
              received.</dd>
	    </dl>
           </li>
          </ul>

        </section>
        <section title="Range"> numbered="true" toc="default">
          <name>Range</name>
          <t>The 'Range' field provides the ability to specify a range of
          addresses and their associated Prefix SIDs. Prefix-SIDs. This advertisement
          supports the SRMS functionality. It is essentially a compression
          scheme to distribute a continuous Prefix prefix and their continuous,
          corresponding SID/Label Block. If a single SID is advertised advertised, then
          the range Range field MUST <bcp14>MUST</bcp14> be set to one. For range advertisements &gt; 1,
          the range Range field MUST <bcp14>MUST</bcp14> be set to the number of addresses that need to
          be mapped into a Prefix-SID. In either case case, the prefix is the first
          address to which a SID is to be assigned.</t>
        </section>
        <section title="Prefix numbered="true" toc="default">
          <name>Prefix Length, Prefix"> Prefix</name>
          <t>The 'Prefix' represents the Forwarding equivalence class Equivalence Class at the
          tail-end
          tail end of the advertised path. The 'Prefix' does not need to
          correspond to a routable prefix of the originating node.</t>
          <t>The 'Prefix Length' field contains the length of the prefix in
          bits. Only the most significant octets of the Prefix prefix are encoded
          (i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix
          length 9 to up 16, 3 octets for prefix length 17 up to 24 and 24, 4 octets
          for prefix length 25 up to 32, ...., and 16 octets for prefix length 113
          up to 128).</t>
        </section>
        <section title="Mapping numbered="true" toc="default">
          <name>Mapping Server Prefix-SID"> Prefix-SID</name>
          <t>The Prefix-SID sub-TLV is defined in <xref
          target="PREFIXSIDSUBTLV"/> target="PREFIXSIDSUBTLV" format="default"/> and contains the SID/index/label SID/Index/Label value
          associated with the prefix and range. The Prefix-SID Sub-TLV MUST sub-TLV <bcp14>MUST</bcp14> be
          present in the SID/Label Binding TLV when the M-flag M-Flag is clear. The
          Prefix-SID Sub-TLV MUST NOT sub-TLV <bcp14>MUST NOT</bcp14> be present when the M-flag M-Flag is set.</t>
          <section title="Prefix-SID Flags"> numbered="true" toc="default">
            <name>Prefix-SID Flags</name>
            <t>The Prefix-SID flags Flags are defined in <xref
            target="PREFIXSIDSUBTLV"/>. target="PREFIXSIDSUBTLV" format="default"/>. The Mapping Server MAY <bcp14>MAY</bcp14> advertise a
            mapping with the N flag N-Flag set when the prefix being mapped is known
            in the link-state topology with a mask length of 32 (IPv4) or 128
            (IPv6) and when the prefix represents a node. The mechanisms
            through which the operator defines that a prefix represents a node
            are outside the scope of this document (typically it will be
            through configuration).</t>
            <t>The other flags defined in <xref target="PREFIXSIDSUBTLV"/> target="PREFIXSIDSUBTLV" format="default"/> are
            not used by the Mapping Server and MUST <bcp14>MUST</bcp14> be ignored at
            reception.</t>
          </section>
          <section anchor="MSPHP"
                   title=" PHP numbered="true" toc="default">
            <name>PHP Behavior when using Using Mapping Server Advertisements"> Advertisements</name>
            <t>As the mapping server Mapping Server does not specify the originator of a
            prefix advertisement advertisement, it is not possible to determine PHP behavior
            solely based on the Mapping Server Advertisement. However, if
            additional information is available available, PHP behavior may safely be
            done. The required information consists of:<list style="symbols">
                <t>A of:</t>
            <ul spacing="normal">
              <li>A prefix reachability advertisement for the prefix has been
                received
                received, which includes the Prefix Attribute Flags sub-TLV
                <xref target="RFC7794"/>.</t>

                <t>X target="RFC7794" format="default"/>.</li>
              <li>X-Flag and R flags R-Flag are both set to 0 in the Prefix Attribute
                Flags sub-TLV.</t>
              </list></t> sub-TLV.</li>
            </ul>
            <t>In the absence of an a Prefix Attribute Flags sub-TLV <xref
            target="RFC7794"/> target="RFC7794" format="default"/>, the A flag A-Flag in the binding Binding TLV indicates that
            the originator of a prefix reachability advertisement is directly
            connected to the prefix and thus prefix; thus, PHP MUST <bcp14>MUST</bcp14> be done by the neighbors
            of the router originating the prefix reachability advertisement.
            Note that A-flag the A-Flag is only valid in the original area in which the
            Binding TLV is advertised.</t>
          </section>
          <section title="Prefix-SID Algorithm"> numbered="true" toc="default">
            <name>Prefix-SID Algorithm</name>
            <t>The algorithm Algorithm field contains the identifier of the algorithm
            associated with the SIDs for the prefix(es) in the range. Use of
            the algorithm Algorithm field is described in <xref
            target="PREFIXSIDSUBTLV"/>.</t> target="PREFIXSIDSUBTLV" format="default"/>.</t>
          </section>
        </section>
        <section anchor="BSIDSUBTLV" title="SID/Label Sub-TLV"> numbered="true" toc="default">
          <name>SID/Label Sub-TLV</name>
          <t>The SID/Label sub-TLV (Type: 1) contains the SID/Label value as
          defined in <xref target="SIDLABELSUBTLV"/>. target="SIDLABELSUBTLV" format="default"/>. It MUST <bcp14>MUST</bcp14> be present in
          the SID/Label Binding TLV when the M-flag M-Flag is set in the Flags field
          of the parent TLV.</t>
        </section>
        <section anchor="BSIDEXAMPLE" title="Example Encodings"> numbered="true" toc="default">
          <name>Example Encodings</name>
          <t>Example 1: if If the following IPv4 router addresses (loopback
          addresses) need to be mapped into the corresponding Prefix SID
          indexes. <figure suppress-title="true">
              <artwork><![CDATA[
Router-A: Prefix-SID
          indexes, then: </t>

<ul empty="true">
<li>Router-A: 192.0.2.1/32, Prefix-SID: Index 1
Router-B: 1</li>
<li>Router-B: 192.0.2.2/32, Prefix-SID: Index 2
Router-C: 2</li>
<li>Router-C: 192.0.2.3/32, Prefix-SID: Index 3
Router-D: 3</li>
<li>Router-D: 192.0.2.4/32, Prefix-SID: Index 4
     ]]></artwork>
            </figure> <figure suppress-title="true">
              <artwork><![CDATA[ 4</li>
</ul>

          <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |0|0|0|0|0|     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range = 4          |        32     |      192      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        0      |         2     |        1      |Prefix-SID Type|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | sub-TLV Sub-TLV Length|     Flags     |   Algorithm   |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                             1 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
            </figure></t>

          <t>Example-2:
          <t>Example 2: If the following IPv4 prefixes need to be mapped into
          the corresponding Prefix-SID indexes: <figure suppress-title="true">
              <artwork><![CDATA[
10.1.1/24, indexes, then: </t>

<ul empty="true">
<li>10.1.1/24, Prefix-SID: Index 51
10.1.2/24, 51</li>
<li>10.1.2/24, Prefix-SID: Index 52
10.1.3/24, 52</li>
<li>10.1.3/24, Prefix-SID: Index 53
10.1.4/24, 53</li>
<li>10.1.4/24, Prefix-SID: Index 54
10.1.5/24, 54</li>
<li>10.1.5/24, Prefix-SID: Index 55
10.1.6/24, 55</li>
<li>10.1.6/24, Prefix-SID: Index 56
10.1.7/24, 56</li>
<li>10.1.7/24, Prefix-SID: Index 57
 ]]></artwork>
            </figure> <figure suppress-title="true">
              <artwork><![CDATA[ 57</li>
</ul>

          <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |0|0|0|0|0|     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range = 7          |        24     |      10       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        1      |         1     |Prefix-SID Type| sub-TLV Sub-TLV Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Flags      | Algorithm     |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           51  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure></t>

          <t>Example-3:
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          <t>Example 3: If the following IPv6 prefixes need to be mapped into
          the corresponding Prefix-SID indexes: <figure suppress-title="true">
              <artwork><![CDATA[
2001:db8:1/48, indexes, then: </t>

<ul empty="true">
<li>2001:db8:1/48, Prefix-SID: Index 151
2001:db8:2/48, 151</li>
<li>2001:db8:2/48, Prefix-SID: Index 152
2001:db8:3/48, 152</li>
<li>2001:db8:3/48, Prefix-SID: Index 153
2001:db8:4/48, 153</li>
<li>2001:db8:4/48, Prefix-SID: Index 154
 ]]></artwork>
            </figure> <figure suppress-title="true">
              <artwork><![CDATA[ 154</li>
</ul>

          <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |1|0|0|0|0|     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range = 4          |        48     |     0x20      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       0x01    |       0x0d    |       0xb8    |     0x00      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    0x01       |Prefix-SID Type| sub-TLV Sub-TLV Length|  Flags        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Algorithm     |                 0                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       151     |
  +-+-+-+-+-+-+-+-+]]></artwork>
            </figure></t>
          <t>It is not expected that a network operator will be able to keep
          fully continuous Prefix / SID/Index Prefix/SID/Index mappings. In order to support
          noncontinuous mapping ranges ranges, an implementation MAY <bcp14>MAY</bcp14> generate several
          instances of Binding TLVs.</t>
          <t>For example example, if a router wants to advertise the following ranges:
          <list style="hanging">
              <t>Range 16: {
          </t>
     <ul empty="true"><li>
          <dl newline="false" spacing="normal" indent="12">

            <dt>Range 16:</dt><dd>{ 192.0.2.1-15, Index 1-15 }</t>

              <t>Range 6: { }</dd>

            <dt>Range 6:</dt><dd>{ 192.0.2.22-27, Index 22-27 }</t>

              <t>Range 41: { }</dd>

            <dt>Range 41:</dt><dd>{ 192.0.2.44-84, Index 80-120 }</t>
            </list> A }</dd>
          </dl>
	</li>
      </ul>
          <t> a router would need to advertise three instances of the
          Binding TLV.</t>
        </section>
      </section>
      <section anchor="MTBINDINGTLV"
               title="Multi-Topology numbered="true" toc="default">
        <name>Multi-Topology SID/Label Binding TLV"> TLV</name>
        <t>The Multi-Topology SID/Label Binding TLV allows the support of
        M-ISIS
        Multi-Topology IS-IS (M-ISIS) as defined in <xref target="RFC5120"/>. target="RFC5120" format="default"/>. The Multi-Topology
        SID/Label Binding TLV has the same format as the SID/Label Binding TLV
        defined in <xref target="BINDINGTLV"/> target="BINDINGTLV" format="default"/> with the difference consisting
        of a Multitopology Multi-topology Identifier (MTID) (MT ID) as defined here below:</t>

        <figure anchor="MTBINDINGTLVFIG"
                title="Multi-Topology SID/Label Binding TLV format">
          <artwork><![CDATA[

          <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |             MTID             MT ID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Flags     |     RESERVED  |            Range              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Prefix Length |            Prefix (variable)                 //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Sub-TLVs (variable)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      <t>where: <list style="hanging">
            <t>Type: 150</t>

            <t>Length: variable</t>

            <t>MTID </t>
      <ul empty="true"><li>
        <dl newline="false" spacing="normal" indent="9">

          <dt>Type:</dt><dd>150</dd>

          <dt>Length:</dt><dd>Variable</dd>
	</dl>

           <t>MT ID is the multitopology identifier Multi-topology Identifier defined as: <figure
                anchor="MTIDFIG" suppress-title="true">
                <artwork><![CDATA[ as:</t>

            <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | RESVD |         MTID         MT ID         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure><list style="hanging">
                <t>RESVD: reserved
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
              <ul empty="true"><li>
              <dl newline="false" spacing="normal" indent="9">

              <dt>RESVD:</dt><dd>Reserved bits. MUST <bcp14>MUST</bcp14> be reset on transmission and
                ignored on receive.</t>

                <t>MTID: a receive.</dd>

              <dt>MT ID:</dt><dd>A 12-bit field containing the non-zero ID of the
                topology being announced. The TLV MUST <bcp14>MUST</bcp14> be ignored if the ID is
                zero. This is to ensure the consistent view of the standard
                unicast topology.</t>
              </list></t> topology.</dd>

             </dl>
           </li>
         </ul>
       </li>
      </ul>

        <ul empty="true"><li>
          <t>The other fields and Sub-TLVs sub-TLVs are defined in <xref
            target="BINDINGTLV"/>.</t>
          </list></t> target="BINDINGTLV" format="default"/>.</t>
	</li></ul>

      </section>
    </section>
    <section title="Router Capabilities"> numbered="true" toc="default">
      <name>Router Capabilities</name>
      <t>This section defines sub-TLVs which that are inserted into the IS-IS
      Router Capability TLV-242 that is defined in <xref
      target="RFC7981"/>.</t> target="RFC7981" format="default"/>.</t>
      <section anchor="SRCAPSUBTLV" title="SR-Capabilities Sub-TLV"> numbered="true" toc="default">
        <name>SR-Capabilities Sub-TLV</name>
        <t>Segment Routing requires each router to advertise its SR data-plane data plane
        capability and the range of MPLS label values it uses for Segment
        Routing in the case where global SIDs are allocated (i.e., global
        indexes). Data-plane Data plane capabilities and label ranges are advertised
        using the newly defined SR-Capabilities sub-TLV.</t>
        <t>The Router Capability TLV specifies flags that control its
        advertisement. The SR Capabilities SR-Capabilities sub-TLV MUST <bcp14>MUST</bcp14> be propagated
        throughout the level and MUST NOT <bcp14>MUST NOT</bcp14> be advertised across level
        boundaries. Therefore Therefore, Router Capability TLV distribution flags are set
        accordingly, i.e., the S flag S-Flag in the Router Capability TLV <xref
        target="RFC7981"/> MUST target="RFC7981" format="default"/> <bcp14>MUST</bcp14> be unset.</t>
        <t>The SR Capabilities SR-Capabilities sub-TLV has the following format:<figure>
            <artwork><![CDATA[ format:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Range                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                SID/Label Sub-TLV (variable)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure><list style="hanging">
            <t>Type: 2</t>

            <t>Length: variable.</t>

            <t>Flags: 1
         <ul empty="true"><li>
         <dl newline="false" spacing="normal" indent="9">
         <dt>Type:</dt><dd>2</dd>

          <dt>Length:</dt><dd>Variable</dd>

          <dt>Flags:</dt><dd><t>1 octet of flags. The following are defined: <figure>
                <artwork><![CDATA[ </t>

            <artwork name="" type="" align="left" alt=""><![CDATA[    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |I|V|           |
   +-+-+-+-+-+-+-+-+
]]></artwork>
              </figure>where: <list style="hanging">
                <t>I-Flag: MPLS
   +-+-+-+-+-+-+-+-+]]></artwork>

          </dd></dl>
         </li>
        </ul>
             <ul empty="true"><li>
             <t>where: </t>
             <ul empty="true"><li>
             <dl newline="false" spacing="normal" indent="9">
              <dt>I-Flag:</dt><dd>MPLS IPv4 flag. Flag. If set, then the router is capable
                of processing SR MPLS encapsulated SR-MPLS-encapsulated IPv4 packets on all
                interfaces.</t>

                <t>V-Flag: MPLS
                interfaces.</dd>

              <dt>V-Flag:</dt><dd>MPLS IPv6 flag. Flag. If set, then the router is capable
                of processing SR MPLS encapsulated SR-MPLS-encapsulated IPv6 packets on all
                interfaces.</t>
              </list></t>
                interfaces.</dd>
            </dl>
	  </li></ul></li></ul>

            <ul empty="true"><li>
            <t>One or more SRGB Segment Routing Global Block (SRGB) Descriptor entries, each of which have the
            following format:<list style="hanging">
                <t>Range: 3 octets.</t>

                <t>SID/Label sub-TLV (as format:</t>

             <ul empty="true"><li>
             <dl newline="false" spacing="normal" indent="9">
              <dt>Range:</dt><dd>3 octets</dd>
              <dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xref
                target="SIDLABELSUBTLV"/>).</t>
              </list></t>
          </list></t>

        <t>SID/Label target="SIDLABELSUBTLV" format="default"/></dd>
            </dl>
         </li>
       </ul>
     </li>
   </ul>

        <t>The SID/Label sub-TLV contains the first value of the SRGB while the
        range contains the number of SRGB elements. The range value MUST <bcp14>MUST</bcp14> be
        higher than 0.</t>
        <t>The SR-Capabilities sub-TLV MAY <bcp14>MAY</bcp14> be advertised in an LSP of any
        number
        number, but a router MUST NOT <bcp14>MUST NOT</bcp14> advertise more than one SR-Capabilities
        sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from the
        same originator SHOULD <bcp14>SHOULD</bcp14> select the first advertisement in the lowest
        numbered lowest-numbered
        LSP.</t>
        <t>When multiple SRGB Descriptors are advertised advertised, the entries define an
        ordered set of ranges on which a SID index is to be applied. For this
        reason
        reason, changing the order in which the descriptors are advertised will
        have a disruptive effect on forwarding.</t>
        <t>When a router adds a new SRGB Descriptor to an existing
        SR-Capabilities sub-TLV sub-TLV, the new Descriptor SHOULD descriptor <bcp14>SHOULD</bcp14> add the newly
        configured block at the end of the sub-TLV and SHOULD NOT <bcp14>SHOULD NOT</bcp14> change the
        order of previously advertised blocks. Changing the order of the
        advertised descriptors will create label churn in the FIB and
        blackhole
        black hole / misdirect some traffic during the IGP convergence. In
        particular, if a range which that is not the last is extended extended, it's
        preferable to add a new range rather than extending the previously
        advertised range.</t>
        <t>The originating router MUST <bcp14>MUST</bcp14> ensure the order is unchanged after a
        graceful restart (using checkpointing, non-volatile storage storage, or any
        other mechanism).</t>
        <t>The originating router MUST NOT <bcp14>MUST NOT</bcp14> advertise overlapping ranges.</t>
        <t>When a router receives multiple overlapping ranges, it MUST <bcp14>MUST</bcp14> conform
        to the procedures defined in <xref
        target="I-D.ietf-spring-segment-routing-mpls"/>.</t> target="RFC8660" format="default"/>.</t>

        <t>Here follows an example of the advertisement of multiple ranges:<figure
            anchor="SRGBEXAMPLE" suppress-title="true">
            <artwork><![CDATA[
   The ranges:</t>

  <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
             <li>The originating router advertises the following ranges:
      SR-Cap: ranges:</li>
             <li>SR-Cap: range: 100, SID value: 100
      SR-Cap: </li>
             <li>SR-Cap: range: 100, SID value: 1000
      SR-Cap: 1000</li>
             <li>SR-Cap: range: 100, SID value: 500 500</li>
       	</ul>
     </li>
  </ul>

  <ul empty="true" spacing="normal">
          <li>
   The receiving routers concatenate the ranges in the received
   order and build the SRGB as follows: follows:</li>
  </ul>

  <artwork name="" type="" align="left" alt=""><![CDATA[
   SRGB = [100, 199]
          [1000, 1099]
          [500, 599]

   The 599]]]></artwork>

 <ul empty="true" spacing="normal">
 <li>The indexes span multiple ranges:

      index=0 ranges:</li>
 </ul>

  <artwork name="" type="" align="left" alt=""><![CDATA[
      index 0   means label 100
      ...
      index 99  means label 199
      index 100 means label 1000
      index 199 means label 1099
      ...
      index 200 means label 500
      ...
]]></artwork>
          </figure></t>
      ...]]></artwork>

      </section>
      <section anchor="SRALGOSUBTLV" title="SR-Algorithm Sub-TLV"> numbered="true" toc="default">
        <name>SR-Algorithm Sub-TLV</name>
        <t>The router may use various algorithms when calculating reachability
        to other nodes or to prefixes attached to these nodes. Examples of
        these algorithms are metric based Shortest Path First (SPF), metric-based SPF, various
        sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the
        router to advertise the algorithms that the router is currently using.
        Algorithm values are defined in the "IGP Algorithm Type" registry
        defined in <xref target="I-D.ietf-ospf-segment-routing-extensions"/>. target="RFC8665" format="default"/>.
        The following values have been defined:<list>
            <t>0: Shortest Path First (SPF) defined:</t>

        <ul empty="true" spacing="normal"><li>
          <dl newline="false" spacing="normal">
          <dt>0:</dt><dd>SPF algorithm based on link metric.
            This is the well-known shortest path algorithm as computed by the
            IS-IS Decision process. Process. Consistent with the deployed practice for
            link-state protocols, algorithm 0 permits any node to overwrite
            the SPF path with a different path based on local policy.</t>

            <t>1: Strict Shortest Path First (SPF) policy.</dd>
          <dt>1:</dt><dd>Strict SPF algorithm based on link
            metric. The algorithm is identical to algorithm 0 0, but algorithm 1
            requires that all nodes along the path will honor the SPF routing
            decision. Local policy MUST NOT <bcp14>MUST NOT</bcp14> alter the forwarding decision
            computed by algorithm 1 at the node claiming to support algorithm
            1.</t>
          </list></t>
            1.</dd>
	  </dl>
	</li>
        </ul>
        <t>The Router Capability TLV specifies flags that control its
        advertisement. The SR-Algorithm MUST <bcp14>MUST</bcp14> be propagated throughout the
        level and MUST NOT <bcp14>MUST NOT</bcp14> be advertised across level boundaries. Therefore Therefore,
        Router Capability TLV distribution flags are set accordingly, i.e.,
        the S flag MUST S-Flag <bcp14>MUST</bcp14> be unset.</t>
        <t>The SR-Algorithm sub-TLV is optional. It MUST NOT <bcp14>MUST NOT</bcp14> be advertsied advertised
        more than once at a given level. A router receiving multiple
        SR-Algorithm sub-TLVs from the same originator SHOULD <bcp14>SHOULD</bcp14> select the first
        advertisement in the lowest numbered lowest-numbered LSP.</t>
        <t>When the originating router does not advertise the SR-Algorithm
        sub-TLV, this it implies that algorithm 0 is the only algorithm supported by the routers
        supporting
        that support the extensions defined in this document is Algorithm 0.</t> document.</t>
        <t>When the originating router does advertise the SR-Algorithm
        sub-TLV, then algorithm 0 MUST <bcp14>MUST</bcp14> be present while non-zero algorithms
        MAY
        <bcp14>MAY</bcp14> be present.</t>
        <t>The SR-Algorithm sub-TLV has the following format: <figure>
            <artwork><![CDATA[ </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type        |     Length    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        <t> where: <list style="hanging">
            <t>Type: 19</t>

            <t>Length: variable.</t>

            <t>Algorithm: 1 </t>
        <ul empty="true"><li>
        <dl newline="false" spacing="normal" indent="12">

          <dt>Type:</dt><dd>19</dd>

          <dt>Length:</dt><dd>Variable</dd>

          <dt>Algorithm:</dt><dd>1 octet of algorithm</t>
          </list></t> algorithm</dd>
        </dl></li></ul>
      </section>
      <section anchor="SRLBSUBTLV" title="SR numbered="true" toc="default">
        <name>SR Local Block Sub-TLV"> Sub-TLV</name>
        <t>The SR Local Block (SRLB) Sub-TLV sub-TLV contains the range of labels the
        node has reserved for local Local SIDs. Local SIDs are used, e.g., for
        Adjacency-SIDs,
        Adj-SIDs, and may also be allocated by components other than the
        IS-IS protocol. As an example, an application or a controller may
        instruct the router to allocate a specific local Local SID. Therefore, in
        order for such applications or controllers to know what are the local Local
        SIDs are available in the router, it is required that the router
        advertises its SRLB.</t>
        <t>The SRLB Sub-TLV sub-TLV is used for this purpose and has following
        format:<figure>
            <artwork><![CDATA[
        format:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Range                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                SID/Label Sub-TLV (variable)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure><list style="hanging">
            <t>Type: 22</t>

            <t>Length: variable.</t>

            <t>Flags: 1
      <ul empty="true"><li>
       <dl newline="false" spacing="normal" indent="9">
          <dt>Type:</dt><dd>22</dd>

          <dt>Length:</dt><dd>Variable</dd>

          <dt>Flags:</dt><dd>1 octet of flags. None are defined at this stage.</t> stage.</dd>
          </dl>
	</li>
      </ul>
           <ul empty="true"><li>
            <t>One or more SRLB Descriptor entries, each of which have the
            following format:<list style="hanging">
                <t>Range: 3 octets.</t>

                <t>SID/Label sub-TLV (as format:</t>

            <ul empty="true"><li>
            <dl newline="false" spacing="normal" indent="9">

              <dt>Range:</dt><dd>3 octets</dd>

              <dt>SID/Label sub-TLV:</dt><dd>MPLS label as defined in <xref
                target="SIDLABELSUBTLV"/>).</t>
              </list></t>
          </list></t>

        <t>SID/Label target="SIDLABELSUBTLV" format="default"/></dd>
            </dl>
      </li>
    </ul>
  </li>
</ul>
        <t>The SID/Label sub-TLV contains the first value of the SRLB while the
        range contains the number of SRLB elements. The range value MUST <bcp14>MUST</bcp14> be
        higher than 0.</t>
        <t>The SRLB sub-TLV MAY <bcp14>MAY</bcp14> be advertised in an LSP of any number number, but a
        router MUST NOT <bcp14>MUST NOT</bcp14> advertise more than one SRLB sub-TLV. A router
        receiving multiple SRLB sub-TLVs, from the same originator, SHOULD <bcp14>SHOULD</bcp14>
        select the first advertisement in the lowest numbered lowest-numbered LSP.</t>
        <t>The originating router MUST NOT <bcp14>MUST NOT</bcp14> advertise overlapping ranges.</t>
        <t>When a router receives multiple overlapping ranges, it MUST <bcp14>MUST</bcp14> conform
        to the procedures defined in <xref
        target="I-D.ietf-spring-segment-routing-mpls"/>.</t> target="RFC8660" format="default"/>.</t>
        <t>It is important to note that each time a SID from the SRLB is
        allocated, it should also be reported to all components (e.g.: (e.g.,
        controller or applications) in order for these components to have an
        up-to-date view of the current SRLB allocation and in order to avoid
        collision between allocation instructions.</t>
        <t>Within the context of IS-IS, the reporting of local Local SIDs is done
        through IS-IS Sub-TLVs sub-TLVs such as the Adjacency-SID. Adj-SID. However, the
        reporting of allocated local Local SIDs may also be done through other means
        and protocols which that are outside the scope of this document.</t>
        <t>A router advertising the SRLB sub-TLV may also have other label
        ranges, outside the SRLB, for its local allocation purposes which that are
        NOT advertised in the SRLB. For example, it is possible that an
        Adjacency-SID
        Adj-SID is allocated using a local label not part of the
        SRLB.</t>
      </section>
      <section anchor="SRMSPREFSUBTLV" title="SRMS numbered="true" toc="default">
        <name>SRMS Preference Sub-TLV"> Sub-TLV</name>
        <t>The Segment Routing Mapping Server (SRMS) SRMS Preference sub-TLV is
        used in order to associate a preference with SRMS advertisements from
        a particular source.</t>
        <t>The SRMS Preference sub-TLV has the following format:<figure>
            <artwork><![CDATA[ format:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |    Length     | Preference    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure><list style="hanging">
            <t>Type: 24</t>

            <t>Length: 1.</t>

            <t>Preference: 1 octet. Unsigned 8 bit
     <ul empty="true"><li>
     <dl newline="false" spacing="normal" indent="13">
          <dt>Type:</dt><dd>24</dd>

          <dt>Length:</dt><dd>1</dd>

          <dt>Preference:</dt><dd>1 octet and unsigned 8-bit SRMS preference.</t>
          </list></t> preference.</dd>
        </dl>
      </li>
     </ul>
        <t>The SRMS Preference sub-TLV MAY <bcp14>MAY</bcp14> be advertised in an LSP of any
        number
        number, but a router MUST NOT <bcp14>MUST NOT</bcp14> advertise more than one SRMS Preference
        sub-TLV. A router receiving multiple SRMS Preference sub-TLVs, from
        the same originator, SHOULD <bcp14>SHOULD</bcp14> select the first advertisement in the
        lowest numbered
        lowest-numbered LSP.</t>
        <t>The use of the SRMS Preference preference during the SID selection process is
        described in <xref
        target="I-D.ietf-spring-segment-routing-ldp-interop"/></t> target="RFC8661" format="default"/>.</t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests allocation for numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Per this document, IANA has allocated the following TLVs and
      Sub-TLVs.</t>
      sub-TLVs.</t>
      <section title="Sub TLVs numbered="true" toc="default">
        <name>Sub-TLVs for Type 22,23,25,141,222, Types 22, 23, 25, 141, 222, and 223"> 223</name>
        <t>This document makes the following registrations in the "sub-TLVs "Sub-TLVs
        for TLV 22, 23, 25, 141, 222 222, and 223" registry.</t>

        <t><figure>
            <artwork><![CDATA[Type  Description                       22  23  25  141 222 223
----  --------------------------------  --- --- --- --- --- ---
 31   Adjacency

<table anchor="IANA_table_1" align="left">
  <thead>
    <tr>
      <th align='center'>Type</th>
      <th align='left'>Description</th>
      <th align='center'>22</th>
      <th align='center'>23</th>
      <th align='center'>25</th>
      <th align='center'>141</th>
      <th align='center'>222</th>
      <th align='center'>223</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">31</td>
      <td align="left">Adjacency Segment Identifier       y   y   n   y   y   y
 32   LAN Identifier</td>
      <td align="center">y</td>
      <td align="center">y</td>
      <td align="center">n</td>
      <td align="center">y</td>
      <td align="center">y</td>
      <td align="center">y</td>
    </tr>
    <tr>
      <td align="center">32</td>
      <td align="left">LAN Adjacency Segment Identifier   y   y   n   y   y   y

]]></artwork>
          </figure></t> Identifier</td>
      <td align="center">y</td>
      <td align="center">y</td>
      <td align="center">n</td>
      <td align="center">y</td>
      <td align="center">y</td>
      <td align="center">y</td>
    </tr>
  </tbody>
</table>

      </section>

      <section title="Sub TLVs for Type 135,235,236 numbered="true" toc="default">
        <name>Sub-TLVs for Types 135, 235, 236, and 237"> 237</name>
        <t>This document makes the following registrations in the "sub-TLVs "Sub-TLVs
        for TLV 135,235,236 135, 235, 236, and 237" registry.</t>

        <figure>
          <artwork><![CDATA[Type  Description                       135 235 236 237
----  -------------------------         --- --- --- ---
  3   Prefix

<table anchor="IANA_table_2" align="left">
  <thead>
    <tr>
      <th align='center'>Type</th>
      <th align='left'>Description</th>
      <th align='center'>135</th>
      <th align='center'>235</th>
      <th align='center'>236</th>
      <th align='center'>237</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">3</td>
      <td align="left">Prefix Segment Identifier          y   y   y   y

]]></artwork>
        </figure> Identifier</td>
      <td align="center">y</td>
      <td align="center">y</td>
      <td align="center">y</td>
      <td align="center">y</td>
  </tr>
  </tbody>
</table>

      </section>
      <section title="Sub TLVs numbered="true" toc="default">
        <name>Sub-TLVs for Type 242"> 242</name>
        <t>This document makes the following registrations in the "sub-TLVs "Sub-TLVs
        for TLV 242" registry.</t>

        <figure>
          <artwork><![CDATA[Type  Description
----  -----------
  2   Segment

<table anchor="IANA_table_3" align="left">
  <thead>
    <tr>
      <th align='center'>Type</th>
      <th align='left'>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">2</td>
      <td align="left">Segment Routing Capability
 19   Segment Capability</td>
  </tr>
  <tr>
      <td align="center">19</td>
      <td align="left">Segment Routing Algorithm
 22   Segment Algorithm</td>
  </tr>
  <tr>
      <td align="center">22</td>
      <td align="left">Segment Routing Local Block (SRLB)
 24   Segment (SRLB)</td>
  </tr>
 <tr>
      <td align="center">24</td>
      <td align="left">Segment Routing Mapping Server Preference (SRMS Preference)

]]></artwork>
        </figure>

        <t/> Preference)</td>
  </tr>
  </tbody>
</table>

      </section>
      <section title="New numbered="true" toc="default">
        <name>New TLV Codepoint and Sub-TLV registry"> Registry</name>
        <t>This document registers the following TLV:</t>

        <t><figure>
            <artwork><![CDATA[Value Name                              IIH LSP SNP Purge
----- --------------------------------- --- --- --- -----
149   Segment Identifier/Label Binding   n   y   n   n
150   Multi-Topology

<table anchor="IANA_table_4" align="left">
  <thead>
    <tr>
      <th align='center'>Value</th>
      <th align='left'>Name</th>
      <th align='center'>IIH</th>
      <th align='center'>LSP</th>
      <th align='center'>SNP</th>
      <th align='center'>Purge</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">149</td>
      <td align="left">Segment Identifier / Label Binding</td>
      <td align="center">n</td>
      <td align="center">y</td>
      <td align="center">n</td>
      <td align="center">n</td>
  </tr>
 <tr>
      <td align="center">150</td>
      <td align="left">Multi-Topology Segment Identifier  n   y   n   n
          /Label Binding

]]></artwork>
          </figure></t> / Label Binding</td>
      <td align="center">n</td>
      <td align="center">y</td>
      <td align="center">n</td>
      <td align="center">n</td>
  </tr>
  </tbody>
</table>
        <t>This document creates the following sub-TLV Registry:</t>

        <t><figure>
            <artwork><![CDATA[Name: sub-TLVs

<dl>
  <dt>Name:</dt>
  <dd>Sub-TLVs for TLVs 149 and 150
Registration Procedure: Expert 150</dd>
  <dt>Registration Procedure:</dt>
  <dd>Expert Review

Type     Description
----     -----------
  0      Reserved
  1      SID/Label
  2      Unassigned
  3      Prefix SID
  4-255  Unassigned

]]></artwork>
          </figure></t> <xref target="RFC8126" format="default"/></dd>
</dl>

<table anchor="IANA_table_5" align="left">
  <thead>
    <tr>
      <th align='center'>Type</th>
      <th align='center'>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">0</td>
      <td align="left">Reserved</td>
  </tr>
 <tr>
      <td align="center">1</td>
      <td align="left">SID/Label</td>
  </tr>
 <tr>
      <td align="center">2</td>
      <td align="left">Unassigned</td>
  </tr>
 <tr>
      <td align="center">3</td>
      <td align="left">Prefix Segment Identifier</td>
  </tr>
 <tr>
      <td align="center">4-255</td>
      <td align="left">Unassigned</td>
  </tr>
  </tbody>
</table>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>With the use of the extensions defined in this document, IS-IS
      carries information which that will be used to program the MPLS data plane
      [RFC3031].
      <xref target="RFC3031" format="default"/>. In general, the same types type of attacks that can be carried out
      on the IP/IPv6 control plane can be carried out on the MPLS control
      plane
      plane, resulting in traffic being misrouted in the respective data
      planes. However, the latter may be more difficult to detect and
      isolate.</t>
      <t>Existing security extensions as described in [RFC5304] <xref target="RFC5304" format="default"/>
         and [RFC5310] <xref target="RFC5310" format="default"/> apply to these segment routing Segment Routing extensions.</t>
    </section>
  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7981.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7794.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>

        <reference anchor="ISO10589">
          <front>
            <title>Information technology -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system intra-domain
          routeing information exchange protocol for use in conjunction with
          the protocol for providing the connectionless-mode network service
          (ISO 8473)</title>
            <seriesInfo name="ISO/IEC 10589:2002," value="Second Edition"/>
            <author>
              <organization abbrev="ISO">International Organization for Standardization</organization>
            </author>
            <date month="November" year="2002"/>
          </front>
        </reference>

        <!--draft-ietf-ospf-segment-routing-extensions">; companion document RFC 8665 -->
        <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8665">
          <front>
            <title>OSPF Extensions for Segment Routing</title>
            <seriesInfo name="DOI" value="10.17487/RFC8665"/>
            <seriesInfo name="RFC" value="8665"/>
            <author initials="P" surname="Psenak" fullname="Peter Psenak" role="editor">
              <organization/>
            </author>
            <author initials="S" surname="Previdi" fullname="Stefano Previdi" role="editor">
              <organization/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
              <organization/>
            </author>
            <author initials="H" surname="Gredler" fullname="Hannes Gredler">
              <organization/>
            </author>
            <author initials="R" surname="Shakir" fullname="Rob Shakir">
              <organization/>
            </author>
            <author initials="W" surname="Henderickx" fullname="Wim Henderickx">
              <organization/>
            </author>
            <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
              <organization/>
            </author>
            <date month="December" year="2019"/>
          </front>
        </reference>

        <!--draft-ietf-spring-segment-routing-mpls">; companion document RFC 8660-->
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660">
          <front>
            <title>Segment Routing with the MPLS Data Plane</title>
            <seriesInfo name="DOI" value="10.17487/RFC8660"/>
            <seriesInfo name="RFC" value="8660"/>
            <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" role="editor">
              <organization/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils" role="editor">
              <organization/>
            </author>
            <author initials="S" surname="Previdi" fullname="Stefano Previdi">
              <organization/>
            </author>
            <author initials="B" surname="Decraene" fullname="Bruno Decraene">
              <organization/>
            </author>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization/>
            </author>
            <author initials="R" surname="Shakir" fullname="Rob Shakir">
              <organization/>
            </author>
            <date month="December" year="2019"/>
          </front>
        </reference>

        <!--draft-ietf-spring-segment-routing-ldp-interop">; companion document RFC 8661-->
        <reference anchor="RFC8661" target="https://www.rfc-editor.org/info/rfc8661">
          <front>
            <title>Segment Routing MPLS Interworking with LDP</title>
            <seriesInfo name="DOI" value="10.17487/RFC8661"/>
            <seriesInfo name="RFC" value="8661"/>
            <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" role="editor">
              <organization/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils" role="editor">
              <organization/>
            </author>
            <author initials="S" surname="Previdi" fullname="Stefano Previdi">
              <organization/>
            </author>
            <author initials="B" surname="Decraene" fullname="Bruno Decraene">
              <organization/>
            </author>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization/>
            </author>
            <date month="December" year="2019"/>
          </front>
        </reference>
      </references>

      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5311.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5316.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
      Francois
      Francois, and Jesper Skrivers for their contribution to the content of
      this document.</t>
    </section>
    <section anchor="Contributors" title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people gave a substantial contribution to the content
      of this document and should be considered as co-authors:</t>

      <figure>
        <artwork><![CDATA[Stephane coauthors:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[Stephane Litkowski
Orange
FR
France
Email: stephane.litkowski@orange.com stephane.litkowski@orange.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Jeff Tantsura
Apstra, Inc.
Email: jefftant@gmail.com jefftant@gmail.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Peter Psenak
Cisco Systems Inc.
US
United States of America
Email: ppsenak@cisco.com ppsenak@cisco.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Martin Horneffer
Deutsche Telekom
DE
Germany
Email: Martin.Horneffer@telekom.de Martin.Horneffer@telekom.de]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Wim Henderickx
Nokia
BE
Belgium
Email: wim.henderickx@nokia.com wim.henderickx@nokia.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Edward Crabbe
Oracle
US
United States of America
Email: edward.crabbe@oracle.com edward.crabbe@oracle.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Rob Shakir
Google
UK
United Kingdom
Email: robjs@google.com robjs@google.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Igor Milojevic
Individual
RS
Serbia
Email: milojevicigor@gmail.com milojevicigor@gmail.com]]></artwork>

<artwork name="" type="" align="left" alt=""><![CDATA[
Saku Ytti
TDC
FI
Finland
Email: saku@ytti.fi

Steven Luong
Cisco Systems Inc.
US

Email: sluong@cisco.com]]></artwork>
      </figure> saku@ytti.fi]]></artwork>

    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <reference anchor="ISO10589">
        <front>
          <title>Intermediate system to Intermediate system intra-domain
          routeing information exchange protocol for use in conjunction with
          the protocol for providing the connectionless-mode Network Service
          (ISO 8473)</title>

          <author>
            <organization abbrev="ISO">International Organization for
            Standardization</organization>
          </author>

          <date month="Nov" year="2002"/>
        </front>

        <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
      </reference>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5304.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5310.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5120.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7981.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7794.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml"?>

      <?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions.xml"?>

      <?rfc include="reference.I-D.ietf-spring-segment-routing-mpls.xml"?>

      <?rfc include="reference.I-D.ietf-spring-segment-routing-ldp-interop.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5311.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5316.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7855.xml"?>
    </references>
  </back>
</rfc>