<?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 category="std" xmlns:xi="http://www.w3.org/2001/XInclude" number="8666"
     docName="draft-ietf-ospf-ospfv3-segment-routing-extensions-23"
     ipr="trust200902"> category="std" submissionType="IETF" consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="OSPFv3 Extensions for Segment Routing">OSPFv3 Extensions
    for Segment Routing</title>
    <seriesInfo name="RFC" value="8666"/>
    <author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Eurovea Centre, Central 3</street>
          <street>Pribinova Street 10</street>
          <city>Bratislava</city>
          <code>81109</code>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Stefano Previdi" initials="S." role="editor" surname="Previdi">
      <organization>Individual</organization>
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <country></country>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>

        <email>stefano.previdi@net</email>

        <email>stefano@previdi.net</email>
      </address>
    </author>
    <date year=""/> month="December" year="2019"/>
    <area>Routing</area>
    <workgroup>Open Shortest Path First IGP</workgroup>

    <keyword>MPLS</keyword>

    <keyword>SID</keyword>

    <keyword>IGP</keyword>

    <keyword>OSPF</keyword>

    <keyword>Label advertisement</keyword>

    <keyword>Segment
    <keyword>MPLS, SID, IGP, OSPF, Label advertisement, Segment Routing</keyword>

    <abstract>
      <t>Segment Routing (SR) allows a flexible definition of end-to-end
      paths within IGP topologies by encoding paths as sequences of
      topological sub-paths, subpaths called "segments". These segments are advertised
      by the link-state routing protocols (IS-IS and OSPF).</t>
      <t>This draft document describes the OSPFv3 extensions required for Segment Routing
      with the MPLS 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 BCP14 <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 a flexible definition of end-to-end paths
      within IGP topologies by encoding paths as sequences of topological sub-paths,
      subpaths 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), 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 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 it does not require any additional signalling signaling (other than IGP
      extensions). The IPv6 data plane is out of the scope of this specification -
      specification; the OSPFv3 extension for SR with the IPv6 data plane will be
      specified in a separate document.  When used in MPLS networks, SR paths
      do not require any LDP or RSVP-TE signalling. signaling.  However, SR can
      interoperate in the presence of LSPs Label Switched Paths (LSPs) established with RSVP or LDP.</t>
      <t>This draft document describes the OSPFv3 extensions required for Segment
      Routing with the MPLS data plane.</t>
      <t>Segment Routing architecture is described in <xref target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
      <t>Segment Routing use cases are described in <xref target="RFC7855"/>.</t> target="RFC7855" format="default"/>.</t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>This section lists some of the terminology used in this document:

    <list style="hanging">

    <t>ABR - Area

      </t>
      <dl newline="false" spacing="normal" indent="12">
        <dt>ABR:</dt>
        <dd>Area Border Router</t>

    <t>Adj-SID - Adjacency Router</dd>
        <dt>Adj-SID:</dt>
        <dd>Adjacency Segment Identifier</t>

    <t>AS - Autonomous System</t>

    <t>ASBR - Autonomous Identifier</dd>
        <dt>AS:</dt>
        <dd>Autonomous System</dd>
        <dt>ASBR:</dt>
        <dd>Autonomous System Boundary Router</t>

    <t>DR - Designated Router</t>

    <t>IS-IS - Intermediate Router</dd>
        <dt>DR:</dt>
        <dd>Designated Router</dd>
        <dt>IS-IS:</dt>
        <dd>Intermediate System to Intermediate System</t>

    <t>LDP - Label System</dd>
        <dt>LDP:</dt>
        <dd>Label Distribution Protocol</t>

    <t>LSP - Label Protocol</dd>
        <dt>LSP:</dt>
        <dd>Label Switched Path</t>

    <t>MPLS - Multi Protocol Path</dd>
        <dt>MPLS:</dt>
        <dd>Multiprotocol Label Switching</t>

    <t>OSPF - Open Switching</dd>
        <dt>OSPF:</dt>
        <dd>Open Shortest Path First</t>

    <t>SPF - Shortest First</dd>
        <dt>SPF:</dt>
        <dd>Shortest Path First</t>

    <t>RSVP - Resource First</dd>
        <dt>RSVP:</dt>
        <dd>Resource Reservation Protocol</t>

    <t>SID - Segment Identifier</t>

    <t>SR - Segment Routing</t>

    <t>SRGB - Segment Protocol</dd>
        <dt>SID:</dt>
        <dd>Segment Identifier</dd>
        <dt>SR:</dt>
        <dd>Segment Routing</dd>
        <dt>SRGB:</dt>
        <dd>Segment Routing Global Block</t>

    <t>SRLB - Segment Block</dd>
        <dt>SRLB:</dt>
        <dd>Segment Routing Local Block</t>

    <t>SRMS - Segment Block</dd>
        <dt>SRMS:</dt>
        <dd>Segment Routing Mapping Server</t>

    <t>TLV - Type Server</dd>
        <dt>TLV:</dt>
        <dd>Type Length Value</t>

    </list></t> Value</dd>
      </dl>
      <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 title="Segment numbered="true" toc="default">
      <name>Segment Routing Identifiers"> Identifiers</name>
      <t>Segment Routing defines various types of Segment Identifiers (SIDs):
      Prefix-SID, Adjacency-SID, Adjacency SID, and LAN Adjacency SID.</t>
      <section anchor="SIDLABEL" title="SID/Label Sub-TLV"> numbered="true" toc="default">
        <name>SID/Label Sub-TLV</name>
        <t>The SID/Label Sub-TLV sub-TLV appears in multiple TLVs or Sub-TLVs sub-TLVs defined
        later in this document. It is used to advertise the SID or label
        associated with a prefix or adjacency. The SID/Label Sub-TLV sub-TLV has the following
        format:<figure>
            <artwork>
        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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      SID/Label (variable)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

            <t>Length: Either 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork><t>where:</t>
        <ul empty="true"><li><dl newline="false" spacing="normal">
          <dt>Type:</dt>
          <dd>7</dd>
          <dt>Length:</dt>
          <dd>3 or 4 octets</t>

            <t>SID/Label: If octets.</dd>
          <dt>SID/Label:</dt>
          <dd>If the length is set to 3, then the 20 rightmost bits
            represent a label. If the length is set to 4, then the value represents
            a 32-bit SID.</t>

            <t>The receiving router MUST ignore the SID/Label Sub-TLV if the length is
            other than 3 or 4.</t>

          </list></t> SID.</dd>
        </dl></li></ul>
      </section>
    </section>
    <section anchor="SRCAP" title="Segment numbered="true" toc="default">
      <name>Segment Routing Capabilities"> Capabilities</name>
      <t>Segment Routing requires some additional router capabilities to be advertised to
      other routers in the area.</t>
      <t>These SR capabilities are advertised in the OSPFv3 Router Information Opaque LSA
      (defined in <xref target="RFC7770"/>) target="RFC7770" format="default"/>) and specified in
      <xref target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> target="RFC8665" format="default"/>.</t>
    </section>
    <section anchor="PFXRANGE" title="OSPFv3 numbered="true" toc="default">
      <name>OSPFv3 Extended Prefix Range TLV"> TLV</name>
      <t>In some cases cases, it is useful to advertise attributes for a range of
      prefixes in a single advertisement. The Segment Routing SR Mapping Server,
      which is described in <xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>, target="RFC8661" format="default"/>,
      is an example of where SIDs for multiple prefixes can be advertised. To
      optimize such advertisement in case of multiple prefixes from a
      contiguous address range, OSPFv3 Extended Prefix Range TLV is defined."</t> defined.</t>
      <t>The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the following LSAs
      defined in <xref target="RFC8362"/>:
      <list style="hanging">
      		<t>E-Intra-Area-Prefix-LSA</t>

      		<t>E-Inter-Area-Prefix-LSA</t>

      		<t>E-AS-External-LSA</t>

      		<t>E-Type-7-LSA</t>
      	</list></t> target="RFC8362" format="default"/>:
      </t>
      <ul empty="true" spacing="normal">

        <li>E-Intra-Area-Prefix-LSA</li>

        <li>E-Inter-Area-Prefix-LSA</li>

        <li>E-AS-External-LSA</li>

        <li>E-Type-7-LSA</li>
      </ul>
      <t>Multiple OSPFv3 Extended Prefix Range TLVs MAY <bcp14>MAY</bcp14> be advertised in each LSA mentioned
      above. The OSPFv3 Extended Prefix Range TLV has the following
      format: <figure>
            <artwork> </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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |       AF      |         Range Size            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Flags      |                 Reserved                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Address Prefix (variable)                 |
|                           ...                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sub-TLVs (variable)                      |
+-                                                             -+
|                                                               |

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

            <t>Length: Variable,                                                               |]]></artwork>
      <t>where:</t><ul empty="true"><li><dl newline="false" spacing="normal">
        <dt>Type:</dt>
        <dd>9</dd>
        <dt>Length:</dt>
        <dd>Variable, in octets, dependent depending on Sub-TLVs.</t>

            <t>Prefix length: Length the sub-TLVs.</dd>
        <dt>Prefix Length:</dt>
        <dd>Length of prefix in bits.</t>

            <t>AF: Address bits.</dd>
        <dt>AF:</dt>
        <dd>
          <t>Address family for the prefix.

            	<list style="hanging">

            		<t>AF: 0

          </t>
          <dl newline="false" spacing="normal">
            <dt>AF:</dt>
            <dd>0 - IPv4 unicast</t>

            		<t>AF: 1 unicast</dd>
            <dt>AF:</dt>
            <dd>1 - IPv6 unicast</t>
           		</list></t>

            <t>Range size: Represents unicast</dd>
          </dl>
        </dd>
        <dt>Range Size:</dt>
        <dd>
          <t>Represents the number of prefixes that are covered by the
            advertisement. The Range Size MUST NOT <bcp14>MUST NOT</bcp14> exceed the number of
			prefixes that could be satisfied by the prefix length Prefix Length without
			including:
			<list style="hanging">

            		<t>Addresses
          </t>
          <ul empty="true" spacing="normal">

            <li>Addresses from the IPv4 multicast address range (224.0.0.0/3), if the
            		AF is IPv4 unicast</t>

            		<t>Addresses unicast.</li>

            <li>Addresses other than the IPv6 unicast addresses, if the
            		AF is IPv6 unicast</t>
           	</list></t>

			<t>Flags: Reserved. MUST unicast.</li>
          </ul>
        </dd>
        <dt>Flags:</dt>
        <dd>Reserved. <bcp14>MUST</bcp14> be zero when sent and are ignored when received.</t>

            <t>Reserved: SHOULD received.</dd>
        <dt>Reserved:</dt>
        <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Address Prefix:
               <list style="hanging">

               <t>For reception.</dd>
        <dt>Address Prefix:</dt>
        <dd>

          <ul empty="true" spacing="normal">

            <li>For the address family IPv4 unicast, the prefix itself is
               encoded as a 32-bit value. The default route is represented by a prefix of
               length 0.</t>

               <t>For 0.</li>

<li>For the address family IPv6 unicast, the prefix, prefix is encoded as an even
multiple of 32-bit words, words and padded with zeroed bits as necessary. This
encoding consumes ((PrefixLength + 31) / 32) 32-bit words. </t>

               <t>Prefix </li>

            <li>Prefix encoding for other address families is beyond the scope of
               this specification. Prefix encoding for other address families can
               be defined in the future standard-track Standards Track specifications from the IETF specifications.</t>
            </list></t>
          </list></t> stream.</li>
          </ul>
        </dd>
      </dl></li></ul>
      <t>The range represents the contiguous set of prefixes with the same prefix length
     as specified by the Prefix Length field. The set starts with the prefix that is
     specified by the Address Prefix field. The number of prefixes in the range is equal
     to the Range size.</t> Size.</t>
      <t>If the OSPFv3 Extended Prefix Range TLVs advertising the exact same range appears
     in multiple LSAs of the same type, originated by the same OSPFv3 router, the LSA with
     the numerically smallest Instance ID MUST <bcp14>MUST</bcp14> be used used, and subsequent instances of the
     OSPFv3 Extended Prefix Range TLVs MUST <bcp14>MUST</bcp14> be ignored.</t>
    </section>
    <section anchor="PREFIXSID" title="Prefix SID Sub-TLV"> numbered="true" toc="default">
      <name>Prefix-SID Sub-TLV</name>
      <t>The Prefix SID Sub-TLV Prefix-SID sub-TLV is a Sub-TLV sub-TLV of the following OSPFv3 TLVs as
        defined in <xref target="RFC8362"/> target="RFC8362" format="default"/> and in <xref target="PFXRANGE"/>:
        <list style="hanging">
            <t>Intra-Area target="PFXRANGE" format="default"/>:
      </t>
      <ul empty="true" spacing="normal">

        <li>Intra-Area Prefix TLV</t>

            <t>Inter-Area TLV</li>

        <li>Inter-Area Prefix TLV</t>

            <t>External TLV</li>

        <li>External Prefix TLV</t>

            <t>OSPFv3 TLV</li>

        <li>OSPFv3 Extended Prefix Range TLV</t>
          </list></t> TLV</li>
      </ul>
      <t>It MAY <bcp14>MAY</bcp14> appear more than once in the parent TLV and has the following format:
        <figure>
            <artwork>
      </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    |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       SID/Index/Label (variable)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:</artwork>
          </figure><list style="hanging">
            <t>Type: 4</t>

            <t>Length: 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork><t>where:</t>
      <ul empty="true"><li><dl newline="false" spacing="normal">
        <dt>Type:</dt>
        <dd>4</dd>
        <dt>Length:</dt>
        <dd>7 or 8 octets, dependent depending on the V-flag</t>

            <t>Flags: Single octet V-Flag.</dd>
        <dt>Flags:</dt>
        <dd>
          <t>Single-octet field. The following flags are defined: <figure
                align="center">
                <artwork> </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
|  |NP|M |E |V |L |  |  |
+--+--+--+--+--+--+--+--+
where:</artwork>
          </figure><list style="hanging">

                <t>NP-Flag: No-PHP flag.
+--+--+--+--+--+--+--+--+]]></artwork>
<t>where:</t>
          <dl newline="false" spacing="normal">
            <dt>NP-Flag:</dt>
            <dd>No-PHP (Penultimate Hop Popping) Flag. If set, then the penultimate hop MUST
                NOT <bcp14>MUST
                NOT</bcp14> pop the Prefix-SID before delivering packets to the
                node that advertised the Prefix-SID.</t>

                <t>M-Flag: Mapping Prefix-SID.</dd>
            <dt>M-Flag:</dt>
            <dd>Mapping Server Flag.  If set, the SID was advertised
                by a Segment Routing an SR Mapping Server as described in
                <xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t>

                <t>E-Flag: Explicit-Null target="RFC8661" format="default"/>.</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
                the Explicit-NULL Explicit NULL label (0 for IPv4, 2 for IPv6) before forwarding the packet.</t>

                <t>V-Flag: Value/Index packet.</dd>
            <dt>V-Flag:</dt>
            <dd>Value/Index Flag. If set, then the Prefix-SID
                carries an absolute value. If not set, then the Prefix-SID carries
                an index.</t>

                <t>L-Flag: Local/Global index.</dd>
            <dt>L-Flag:</dt>
            <dd>Local/Global Flag. If set, then the value/index
                carried by the Prefix-SID has local significance. If not set, then
                the value/index carried by this Sub-TLV sub-TLV has global significance.</t>

                <t>Other bits: Reserved. significance.</dd>
            <dt>Other bits:</dt>
            <dd>Reserved. These MUST <bcp14>MUST</bcp14> be zero when sent and are ignored when
                received.</t>
              </list></t>

            <t>Reserved: SHOULD
                received.</dd>
          </dl>
        </dd>
        <dt>Reserved:</dt>
        <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Algorithm: Single reception.</dd>
        <dt>Algorithm:</dt>
        <dd><t>Single octet identifying the algorithm the Prefix-SID
            is associated with as defined in the IGP Algorithm Types registry
            <xref target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> target="ALGOREG" format="default"/>.</t>

        <t>A router receiving a Prefix-SID from a remote node and with an algorithm
            value that such the remote node has not advertised in the SR-Algorithm TLV
            <xref target="I-D.ietf-ospf-segment-routing-extensions"/> MUST target="RFC8665" format="default"/> <bcp14>MUST</bcp14> ignore the
            Prefix-SID Sub-TLV.</t>

            <t>SID/Index/Label: According sub-TLV.</t></dd>
        <dt>SID/Index/Label:</dt>
        <dd>
          <t>According to the V-Flag and L-Flag, it contains:
             <list style="hanging">

            <t>V-flag
          </t>
          <ul empty="true" spacing="normal">

            <li>V-Flag is set to 0 and L-flag L-Flag is set to 0: The SID/Index/Label
            field is a 4 octet 4-octet index defining the offset in the SID/Label
            space advertised by this router</t>

            <t>V-flag router.</li>

            <li>V-Flag is set to 1 and L-flag L-Flag is set to 1: 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>

            <t>All value.</li>

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

          </list></t> ignored.</li>
          </ul>
        </dd>
      </dl></li></ul>
      <t>If an OSPFv3 router advertises multiple Prefix-SIDs for the same prefix,
        topology, and algorithm, all of them MUST <bcp14>MUST</bcp14> be ignored.</t>
      <t>When calculating the outgoing label for the prefix, the router MUST <bcp14>MUST</bcp14>
        take into account, as described below, the E, NP, E-, NP-, and M flags M-Flags advertised by the
        next-hop router if that router advertised the SID for the prefix.  This MUST <bcp14>MUST</bcp14> be done
        regardless of whether the next-hop router contributes to the best path to the
        prefix.</t>
      <t>The NP-Flag (No-PHP) MUST <bcp14>MUST</bcp14> be set and the E-flag MUST E-Flag <bcp14>MUST</bcp14> be clear for Prefix-SIDs
        allocated to prefixes that are propagated between areas by an ABR based on
        intra-area or inter-area reachability, unless the advertised prefix is directly
        attached to such ABR.</t>
      <t>The NP-Flag (No-PHP) MUST <bcp14>MUST</bcp14> be set and the E-flag MUST E-Flag <bcp14>MUST</bcp14> be clear for Prefix-SIDs
        allocated to redistributed prefixes, unless the redistributed prefix is directly
        attached to the advertising ASBR.</t>

      <t>If the NP-Flag is not set, then any then:</t>
      <ul empty="true" spacing="normal">

        <li>Any upstream neighbor of the Prefix-SID
        originator MUST <bcp14>MUST</bcp14> pop the Prefix-SID. This is equivalent to the
	penultimate
        hop popping hop-popping mechanism used in the MPLS dataplane. If the NP-flag is not set,
        then the data plane.</li>

        <li>The received E-flag E-Flag is ignored.</t> ignored.</li>
      </ul>
      <t>If the NP-flag NP-Flag is set then:<list style="hanging">

        <t> If and the E-flag E-Flag is not set, then any then:</t>
      <ul empty="true" spacing="normal">

        <li>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 the originator of
        the Prefix-SID needs to stitch the incoming packet into a continuing
        MPLS LSP to the final destination.  This could occur at an ABR (prefix
        propagation from one area to another) or at an ASBR (prefix
        propagation from one domain to another).</t> another).
        </li>
      </ul>
      <t>If both the E-flag is NP-Flag and E-Flag are set, then any then:</t>
      <ul empty="true" spacing="normal">

        <li>Any upstream neighbor of the Prefix-SID originator
         MUST
         <bcp14>MUST</bcp14> replace the Prefix-SID with an Explicit-NULL Explicit NULL label. 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 Traffic Class field <xref target="RFC5462"/>.</t>
         </list></t> target="RFC5462" format="default"/>.</li>
      </ul>
      <t>When the M-Flag is set, the NP-flag NP-Flag and the E-flag MUST E-Flag <bcp14>MUST</bcp14> be ignored on reception.</t>
      <t>As the Mapping Server does not specify the originator of a prefix advertisement,
        it is not possible to determine PHP behavior solely based on the Mapping Server
        advertisement.
        Advertisement. However, PHP behavior SHOULD <bcp14>SHOULD</bcp14> be done in the following cases:
        <list style="hanging">
        	<t>The
      </t>
      <ul empty="true" spacing="normal">

        <li>The Prefix is intra-area type and the downstream neighbor is the originator
        	of the prefix.</t>

        	<t>The prefix.</li>

        <li>The Prefix is inter-area type and the downstream neighbor is an ABR, which is
        	advertising prefix reachability and is setting the LA-bit in the Prefix
        	Options as described in <xref target="RFC8362"/>.</t>

        	<t>The target="RFC8362" format="default"/>.</li>

        <li>The Prefix is external type and the downstream neighbor is an ASBR, which is
        	advertising prefix reachability and is setting the LA-bit in the Prefix
        	Options as described in <xref target="RFC8362"/>.</t>
        </list></t> target="RFC8362" format="default"/>.</li>
      </ul>
      <t>When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV, then
         the value advertised in the Prefix SID Sub-TLV Prefix-SID sub-TLV is interpreted as a starting
         SID/Label value.</t>
      <t>Example 1: If the following router addresses (loopback addresses)
        need to be mapped into the corresponding Prefix SID Prefix-SID indexes: <figure
            suppress-title="true">
            <artwork> </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
          Router-A: 2001:DB8::1/128, Prefix-SID: Index 1
          Router-B: 2001:DB8::2/128, Prefix-SID: Index 2
          Router-C: 2001:DB8::3/128, Prefix-SID: Index 3
          Router-D: 2001:DB8::4/128, Prefix-SID: Index 4
           </artwork>
          </figure></t> 4]]></artwork>
      <t>then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV would be set
        to 2001:DB8::1, the Prefix Length would be set to 128, the Range Size would be set to 4, and
        the Index value in the Prefix-SID Sub-TLV sub-TLV would be set to 1.</t>
      <t>Example 2: If the following prefixes need to be mapped into the
        corresponding Prefix-SID indexes: <figure suppress-title="true">
            <artwork> </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
          2001:DB8:1::0/120,   Prefix-SID: Index 51
          2001:DB8:1::100/120, Prefix-SID: Index 52
          2001:DB8:1::200/120, Prefix-SID: Index 53
          2001:DB8:1::300/120, Prefix-SID: Index 54
          2001:DB8:1::400/120, Prefix-SID: Index 55
          2001:DB8:1::500/120, Prefix-SID: Index 56
          2001:DB8:1::600/120, Prefix-SID: Index 57
           </artwork>
          </figure></t> 57]]></artwork>
      <t>then the Prefix field in the OSPFv3 Extended Prefix Range TLV would be set
        to 2001:DB8:1::0, the Prefix Length would be set to 120, the Range Size would be set to 7,
        and the Index value in the Prefix-SID Sub-TLV sub-TLV would be set to 51.</t>
    </section>
    <section anchor="ADJSID" title="Adjacency numbered="true" toc="default">
      <name>Adjacency Segment Identifier (Adj-SID)"> (Adj-SID)</name>
      <t>An Adjacency Segment Identifier (Adj-SID) represents a router
      adjacency in Segment Routing.</t>
      <section anchor="ADJSIDSUBTLV" title="Adj-SID Sub-TLV"> numbered="true" toc="default">
        <name>Adj-SID Sub-TLV</name>
        <t>The Adj-SID Sub-TLV sub-TLV is an optional Sub-TLV sub-TLV of the Router-Link TLV as defined in
        <xref target="RFC8362"/>. target="RFC8362" format="default"/>. It MAY <bcp14>MAY</bcp14> appear multiple times
        in the Router-Link TLV.

        The Adj-SID Sub-TLV sub-TLV has the following format:<figure>
            <artwork> 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         |     Weight    |             Reserved          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID/Label/Index (variable)                  |
+---------------------------------------------------------------+

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

            <t>Length: 7
+---------------------------------------------------------------+]]></artwork><t>where:</t>
        <ul empty="true"><li><dl newline="false" spacing="normal">
          <dt>Type:</dt>
          <dd>5</dd>
          <dt>Length:</dt>
          <dd>7 or 8 octets, dependent depending on the V flag.</t>

            <t>Flags: Single octet V-Flag.</dd>
          <dt>Flags:</dt>
          <dd>
            <t>Single-octet field containing the following flags:<figure align="center">
                <artwork> flags:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |B|V|L|G|P|     |
+-+-+-+-+-+-+-+-+

where:</artwork>
              </figure><list style="hanging">
                <t>B-Flag: Backup
   +-+-+-+-+-+-+-+-+]]></artwork><t>where:</t>
            <dl newline="false" spacing="normal">
              <dt>B-Flag:</dt>
              <dd>Backup Flag. If set, the Adj-SID refers to an
                adjacency that is eligible for protection (e.g., using IPFRR IP Fast
		Reroute (IPFRR) or MPLS-FRR) MPLS-FRR (MPLS Fast Reroute)) as
                described in section 3.5 of <xref target="RFC8402"/>.</t>

                <t>The V-Flag: Value/Index target="RFC8402"
		sectionFormat="of" section="3.4"/>.</dd>
              <dt>V-Flag:</dt>
              <dd>Value/Index Flag. If set, then the Adj-SID
                carries an absolute value. If not set, then the Adj-SID carries
                an index.</t>

                <t>The L-Flag: Local/Global index.</dd>
              <dt>L-Flag:</dt>
              <dd>Local/Global Flag. If set, then the value/index
                carried by the Adj-SID has local significance. If not set, then
                the value/index carried by this Sub-TLV sub-TLV has global significance.</t>

                <t>The G-Flag: Group significance.</dd>
              <dt>G-Flag:</dt>
              <dd>Group Flag. When set, the G-Flag indicates that the
                Adj-SID refers to a group 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 the same across router restart and/or interface flap.</t>

                <t>Other bits: Reserved. flap.</dd>
              <dt>Other bits:</dt>
              <dd>Reserved. These MUST <bcp14>MUST</bcp14> be zero when sent and are
                ignored when received.</t>
              </list></t>

           <t>Reserved: SHOULD received.</dd>
            </dl>
          </dd>
          <dt>Reserved:</dt>
          <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Weight: Weight reception.</dd>
          <dt>Weight:</dt>
          <dd>Weight used for load-balancing purposes. The use of the
            weight is defined in <xref target="RFC8402"/>.</t>

            <t>SID/Index/Label: as target="RFC8402" format="default"/>.</dd>
          <dt>SID/Index/Label:</dt>
          <dd>As described in <xref target="PREFIXSID"/>.</t>

          </list></t> target="PREFIXSID" format="default"/>.</dd>
        </dl></li></ul>
        <t>An SR-capable router MAY <bcp14>MAY</bcp14> allocate an Adj-SID for each of its
        adjacencies and set the B-Flag when the adjacency is eligible for protection by an
        FRR mechanism (IP or MPLS) as described in <xref target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
        <t>An SR-capable router MAY <bcp14>MAY</bcp14> allocate more than one Adj-SID to an adjacency.</t>
        <t>An SR-capable router MAY <bcp14>MAY</bcp14> allocate the same Adj-SID to different adjacencies.</t>
        <t>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>
      </section>
      <section anchor="LANADJSIDSUBTLV" title="LAN numbered="true" toc="default">
        <name>LAN Adj-SID Sub-TLV"> Sub-TLV</name>
        <t>The LAN Adj-SID Sub-TLV Adjacency SID is an optional Sub-TLV sub-TLV of the Router-Link
        TLV. It MAY <bcp14>MAY</bcp14> appear multiple times in the Router-Link TLV. It is used
        to advertise a SID/Label for an adjacency to a non-DR router on a
        broadcast, NBMA, Non-Broadcast Multi-Access (NBMA), or hybrid <xref target="RFC6845"/> target="RFC6845" format="default"/> network.
        <figure>
            <artwork>
        </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    |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Neighbor ID                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    SID/Label/Index (variable)                 |
+---------------------------------------------------------------+

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

            <t>Length: 11
+---------------------------------------------------------------+]]></artwork><t>where:</t>
        <ul empty="true"><li><dl newline="false" spacing="normal">
          <dt>Type:</dt>
          <dd>6</dd>
          <dt>Length:</dt>
          <dd>11 or 12 octets, dependent depending on V-flag.</t>

            <t>Flags: same the V-Flag.</dd>
          <dt>Flags:</dt>
          <dd>Same as in <xref target="ADJSIDSUBTLV"/></t>

            <t>Weight: Weight target="ADJSIDSUBTLV" format="default"/>.</dd>
          <dt>Weight:</dt>
          <dd>Weight used for load-balancing purposes. The use of the
            weight is defined in <xref target="RFC8402"/>.</t>

            <t>Reserved: SHOULD target="RFC8402" format="default"/>.</dd>
          <dt>Reserved:</dt>
          <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored on reception.</t>

            <t>Neighbor ID: The reception.</dd>
          <dt>Neighbor ID:</dt>
          <dd>The Router ID of the neighbor for which the LAN-Adj-SID LAN Adjacency SID is
            advertised.</t>

            <t>SID/Index/Label: as
            advertised.</dd>
          <dt>SID/Index/Label:</dt>
          <dd><t>As described in <xref target="PREFIXSID"/>.</t> target="PREFIXSID" format="default"/>.</t>

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

          </list></t> persistent.</t></dd>
        </dl></li></ul>
      </section>
    </section>
    <section title="Elements numbered="true" toc="default">
      <name>Elements of Procedure"> Procedure</name>
      <section title="Intra-area numbered="true" toc="default">
        <name>Intra-area Segment routing Routing in OSPFv3 "> OSPFv3</name>
        <t>An OSPFv3 router that supports segment routing MAY Segment Routing <bcp14>MAY</bcp14> advertise Prefix-
        SIDs for any prefix to which it is advertising reachability (e.g.,
        a loopback IP address as described in <xref target="PREFIXSID"/>).</t> target="PREFIXSID" format="default"/>).</t>
        <t>A Prefix-SID can also be advertised by SR Mapping Servers (as
        described in <xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>). target="RFC8661" format="default"/>). A Mapping
        Server advertises Prefix-SIDs for remote prefixes that exist in the
        OSPFv3 routing domain. Multiple Mapping Servers can advertise Prefix-SIDs
        for the same prefix, in which case the same Prefix-SID MUST <bcp14>MUST</bcp14> be advertised by
        all of them. The SR Mapping Server could use either area flooding scope or
        autonomous system flooding scope when advertising Prefix SIDs Prefix-SIDs for
        prefixes, based on the configuration of the SR Mapping Server.
        Depending on the flooding scope used, the SR Mapping Server chooses the
        OSPFv3 LSA type that will be used. If the area flooding scope is needed,
        an E-Intra-Area-Prefix-LSA <xref target="RFC8362"/> target="RFC8362" format="default"/>
        is used. If autonomous system flooding scope is needed,
        an E-AS-External-LSA <xref target="RFC8362"/> target="RFC8362" format="default"/> is used.</t>
        <t>When a Prefix-SID is advertised by the Mapping Server, which is
        indicated by the M-flag M-Flag in the Prefix-SID Sub-TLV sub-TLV (<xref
        target="PREFIXSID"/>),
        target="PREFIXSID" format="default"/>), the route type as implied by
        the LSA type is ignored and the Prefix-SID is bound to the
        corresponding prefix independent of the route type.</t>
        <t>Advertisement of the Prefix-SID by the Mapping Server using an
        Inter-Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV
        <xref target="RFC8362"/> target="RFC8362" format="default"/> does not itself
        contribute to the prefix reachability. The NU-bit <xref target="RFC5340"/> MUST target="RFC5340" format="default"/> <bcp14>MUST</bcp14> be set in the
        PrefixOptions field of the LSA LSA, which is used by the Mapping Server to
        advertise SID or SID Range, which prevents the advertisement from contributing to
        prefix reachability.</t>
        <t>An SR Mapping Server MUST <bcp14>MUST</bcp14> use the OSPFv3 Extended Prefix Range TLVs when advertising SIDs
        for prefixes. Prefixes of different route-types route types can be combined in a single OSPFv3
        Extended Prefix Range TLV advertised by an SR Mapping Server.</t>
        <t>Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas, similar
        to propagation of prefixes between areas. Same rules that are used for propagating
        prefixes between areas <xref target="RFC5340"/> target="RFC5340" format="default"/> are used for the propagation of
        the prefix ranges.</t>
      </section>
      <section title="Inter-area numbered="true" toc="default">
        <name>Inter-area Segment routing Routing in OSPFv3"> OSPFv3</name>
        <t>In order to support SR in a multi-area multiarea environment, OSPFv3 MUST <bcp14>MUST</bcp14>
        propagate Prefix-SID information between areas. The following
        procedure is used to propagate Prefix SIDs Prefix-SIDs between areas.</t>
        <t>When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an
        intra-area prefix to all its connected areas, it will also include the
        Prefix-SID Sub-TLV, sub-TLV as described in <xref target="PREFIXSID"/>. target="PREFIXSID" format="default"/>. The
        Prefix-SID value will be set as follows: <list style="hanging">
            <t>The </t>
        <ul empty="true" spacing="normal">

          <li>The ABR will look at its best path to the prefix in the source area
            and find the advertising router associated with the best
            path to that prefix.</t>

            <t>The prefix.</li>

          <li>The ABR will then determine if such this router advertised a Prefix-SID
			for the prefix and use it when advertising the Prefix-SID to other
			connected areas.</t>

            <t>If areas.</li>

          <li>If no Prefix-SID was advertised for the prefix in the source
            area by the router that contributes to the best path to the
            prefix, the originating ABR will use the Prefix-SID advertised by any
            other router when propagating the Prefix-SID for the prefix to other areas.</t>
          </list></t> areas.</li>
        </ul>

        <t>When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA LSAs from an
        inter-area route to all its connected areas, it will also include the
        Prefix-SID Sub-TLV, sub-TLV as described in <xref target="PREFIXSID"/>. target="PREFIXSID" format="default"/>. The
        Prefix-SID value will be set as follows: <list style="hanging">
            <t>The </t>
        <ul empty="true" spacing="normal">

          <li>The ABR will look at its best path to the prefix in the backbone
            area and find the advertising router associated with the best
            path to that prefix.</t>

            <t>The prefix.</li>

          <li>The ABR will then determine if such this router advertised a Prefix-SID
            for the prefix and use it when advertising the Prefix-SID to other
            connected areas.</t>

            <t>If areas.</li>

          <li>If no Prefix-SID was advertised for the prefix in the backbone
            area by the ABR that contributes to the best path to the prefix,
            the originating ABR will use the Prefix-SID advertised by any
            other router when propagating the Prefix-SID for the prefix to other areas.</t>
          </list></t> areas.</li>
        </ul>
      </section>
      <section title="Segment numbered="true" toc="default">
        <name>Segment Routing for External Prefixes"> Prefixes</name>
        <t>AS-External-LSAs are flooded domain wide. When an ASBR, which
        supports SR, originates an E-AS-External-LSA, it SHOULD <bcp14>SHOULD</bcp14> also include
        a Prefix-SID Sub-TLV, sub-TLV as described in <xref target="PREFIXSID"/>. target="PREFIXSID" format="default"/>.
        The Prefix-SID value will be set to the SID that has been reserved for
        that prefix.</t>
        <t>When an NSSA a Not-So-Stubby Area (NSSA) <xref target="RFC3101"/> target="RFC3101" format="default"/> ABR
        translates an E-NSSA-LSA into an E-AS-External-LSA, it
        SHOULD <bcp14>SHOULD</bcp14> also
        advertise the Prefix-SID for the prefix. The NSSA ABR determines its
        best path to the prefix advertised in the translated E-NSSA-LSA and
        finds the advertising router associated with that path.  If the
        advertising router has advertised a Prefix-SID for the prefix, then
        the NSSA ABR uses it when advertising the Prefix-SID for the
        E-AS-External-LSA. Otherwise, the Prefix-SID advertised by any other
        router will be used.</t>
      </section>
      <section title="Advertisement numbered="true" toc="default">
        <name>Advertisement of Adj-SID"> Adj-SID</name>
        <t>The Adjacency Segment Routing Identifier (Adj-SID) is advertised
        using the Adj-SID Sub-TLV sub-TLV as described in <xref target="ADJSID"/>.</t> target="ADJSID" format="default"/>.</t>
        <section title="Advertisement numbered="true" toc="default">
          <name>Advertisement of Adj-SID on Point-to-Point Links"> Links</name>
          <t>An Adj-SID MAY <bcp14>MAY</bcp14> be advertised for any adjacency on a P2P
          point-to-point (P2P) link that is in neighbor state 2-Way or
          higher. If the adjacency on a P2P link transitions from the FULL
          state, then the Adj-SID for that adjacency
          MAY <bcp14>MAY</bcp14> be removed from the
          area. If the adjacency transitions to a state lower than 2-Way, then
          the Adj-SID advertisement MUST Advertisement <bcp14>MUST</bcp14> be withdrawn from the area.</t>
        </section>
        <section title="Adjacency numbered="true" toc="default">
          <name>Adjacency SID on Broadcast or NBMA Interfaces"> Interfaces</name>
          <t>Broadcast, NBMA, or hybrid <xref target="RFC6845"/> target="RFC6845" format="default"/> networks in OSPFv3 are
          represented by a star topology where the DR is the central
          point to which all other routers on the broadcast, NBMA, or hybrid network connect.
          As a result, routers on the broadcast, NBMA, or hybrid network advertise only
          their adjacency to the DR. Routers that do not act as DR do not form or advertise
          adjacencies with each other. They do, however, maintain 2-Way adjacency state
          with each other and are directly reachable.</t>
          <t>When Segment Routing is used, each router on the broadcast, NBMA, or hybrid
          network MAY <bcp14>MAY</bcp14> advertise the Adj-SID for its adjacency to the DR using the
          Adj-SID Sub-TLV sub-TLV as described in <xref target="ADJSIDSUBTLV"/>.</t> target="ADJSIDSUBTLV" format="default"/>.</t>
          <t>SR-capable routers MAY <bcp14>MAY</bcp14> also advertise a LAN-Adj-SID LAN
          Adjacency SID for other neighbors (e.g., BDR, DR-OTHER) Backup Designated Router
          (BDR), DR-OTHER, etc.) on the broadcast, NBMA, or hybrid network
          using the
          LAN-Adj-SID Sub-TLV LAN Adj-SID sub-TLV as described in <xref target="LANADJSIDSUBTLV"/>.</t>
          target="LANADJSIDSUBTLV" format="default"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This specification updates several two existing OSPFv3 registries.</t>
      <section anchor="EPLTLVREG" title="OSPFv3 numbered="true" toc="default">
        <name>"OSPFv3 Extended-LSA TLV Registry">

	  <t>Following TLVs" Registry</name>
        <t>The following values are have been allocated:</t>

        <t>o 9 - OSPFv3

<table anchor="IANA1" align="left">
  <name>OSPFv3 Extended-LSA TLVs</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>9</td>
      <td>OSPFv3 Extended Prefix Range TLV</t> TLV</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="EXTLSAREG" title="OSPFv3 numbered="true" toc="default">
        <name>"OSPFv3 Extended-LSA Sub-TLV registry">

      <t>o 4 - Prefix SID Sub-TLV</t>

      <t>o 5 - Adj-SID Sub-TLV</t>

      <t>o 6 - LAN Sub-TLVs" Registry</name>
        <t>The following values have been allocated:</t>

<table anchor="IANA2" align="left">
  <name>OSPFv3 Extended-LSA Sub-TLVs</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>

    </tr>
  </thead>
  <tbody>
    <tr>
      <td>4</td>
      <td>Prefix-SID sub-TLV</td>
      <td>This document</td>

    </tr>
    <tr>
      <td>5</td>
      <td>Adj-SID sub-TLV</td>
      <td>This document</td>

    </tr>
    <tr>
      <td>6</td>
      <td>LAN Adj-SID Sub-TLV</t>

      <t>o 7 - SID/Label Sub-TLV</t> sub-TLV</td>
      <td>This document</td>
    </tr>
    <tr>
      <td>7</td>
      <td>SID/Label sub-TLV</td>
      <td>This document</td>

    </tr>
  </tbody>
</table>

      </section>
    </section>

  <section anchor="Error-handling" numbered="true" toc="default">
<name>TLV/Sub-TLV Error Handling
</name>
<t>For any new TLVs/sub-TLVs defined in this document, if the length is
invalid, the LSA in which it is advertised is considered malformed and
<bcp14>MUST</bcp14> be ignored. Errors <bcp14>SHOULD</bcp14> be logged subject
to rate limiting.
</t>
  </section>

    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>With the OSPFv3 segment routing Segment Routing extensions defined herein,
      OSPFv3 will now program the MPLS data plane <xref target="RFC3031"></xref>. target="RFC3031" format="default"/>.
      Previously, LDP <xref target="RFC5036"></xref> target="RFC5036" format="default"/> or
      another label distribution mechanism was required to advertise MPLS labels and
      program the MPLS data plane.</t>
      <t>In general, the same types of attacks that can be carried out on the IP
      control plane can be carried out on the MPLS control plane resulting in traffic
      being misrouted in the respective data planes. However, the latter can be more
      difficult to detect and isolate.</t>
      <t>Existing security extensions extensions, as described in <xref target="RFC5340"></xref> target="RFC5340" format="default"/> and
       <xref target="RFC8362"/> target="RFC8362" format="default"/>, apply to these segment routing Segment Routing
       extensions. While OSPFv3 is under a single administrative domain, there can be
       deployments where potential attackers have access to one or more networks in the
       OSPFv3 routing domain. In these deployments, stronger authentication mechanisms mechanisms,
       such as those specified in <xref target="RFC4552"></xref> target="RFC4552" format="default"/> or
       <xref target="RFC7166"></xref>
       SHOULD target="RFC7166" format="default"/>,
       <bcp14>SHOULD</bcp14> be used.</t>
      <t>Implementations MUST assure <bcp14>MUST</bcp14> ensure that malformed TLV TLVs and Sub-TLV sub-TLVs defined in this document
       are detected and that they do not provide a vulnerability for attackers to crash the OSPFv3
       router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD sub-TLV <bcp14>SHOULD</bcp14> be counted
       and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD sub-TLVs <bcp14>SHOULD</bcp14>
       be rate-limited rate limited to prevent a Denial of Service Denial-of-Service (DoS) attack (distributed or otherwise)
       from overloading the OSPFv3 control plane.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6845.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3101.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <!-- I-D.ietf-spring-segment-routing-ldp-interop: Companion document -->
<reference anchor='RFC8661' target="https://www.rfc-editor.org/info/rfc8661">
<front>
<title>Segment Routing MPLS Interworking with LDP</title>

<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>
<seriesInfo name="RFC" value="8661"/>
<seriesInfo name="DOI" value="10.17487/RFC8661"/>
</reference>

 <reference anchor="ALGOREG"
	    target="https://www.iana.org/assignments/igp-parameters">
       <front>
       <title>Interior Gateway Protocol (IGP) Parameters</title>

        <author><organization>IANA</organization>
	</author>
       </front>
 </reference>

        <!--  I-D.ietf-ospf-segment-routing-extensions: I-D exists-->

      <reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8665">
<front>
<title>OSPF Extensions for Segment Routing</title>
<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='Filfils' 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>
<seriesInfo name="RFC" value="8665"/>
<seriesInfo name="DOI" value="10.17487/RFC8665"/>
</reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" 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>

      <t><figure>
          <artwork><![CDATA[ coauthors:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   Belgium

   Email: cfilsfil@cisco.com cfilsfil@cisco.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
   Hannes Gredler
   RtBrick Inc.
   Austria

   Email: hannes@rtbrick.com hannes@rtbrick.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
   Rob Shakir
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US
   United States of America

   Email: robjs@google.com robjs@google.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
   Wim Henderickx
   Nokia
   Copernicuslaan 50
   Antwerp  2018
   BE
   Belgium

   Email: wim.henderickx@nokia.com wim.henderickx@nokia.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
   Jeff Tantsura
   Nuage Networks
   US
   Apstra, Inc.
   United States of America

   Email: jefftant.ietf@gmail.com

]]></artwork>
        </figure></t> jefftant.ietf@gmail.com]]></artwork>
      <t>Thanks to Acee Lindem for his substantial contribution to the content of
      this document.</t>
      <t>We would like to thank Anton Smirnov for his contribution as well.</t>
    </section>
  </middle>

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

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

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

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"?>

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6845.xml"?>

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3101.xml"?>

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"?>

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

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"?>

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

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

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"?>

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-ldp-interop.xml"?>

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-mpls.xml"?>

       <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-segment-routing-extensions.xml"?>

       <reference anchor="ALGOREG" target="https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types">
       <front>
       <title>IGP Algorithm Types</title>

        <author>
        </author>
	     <date/>
       </front>

       </reference>

    </references>

    <references title="Informative References">

      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"?>

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

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

      </references>
  </back>
</rfc>