<?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"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-idr-rfc7752bis-17" ipr="trust200902" number="9552" obsoletes="7752, 9029"> 9029" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.0 -->
  <front>
    <title abbrev="Link-State Info Information Distribution Using BGP">Distribution of
    Link-State and Traffic Engineering Information Using BGP</title>
    <seriesInfo name="RFC" value="9552"/>
    <author fullname="Ketan Talaulikar" initials="K" role="editor"
            surname="Talaulikar"> surname="Talaulikar" role="editor">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>

    <date/>
    <date month="December" year="2023"/>
    <area>Routing</area>
    <workgroup>Inter-Domain Routing</workgroup>
    <abstract>
      <t>In many environments, a component external to a network is called
      upon to perform computations based on the network topology and the
      current state of the connections within the network, including Traffic
      Engineering (TE) information. This is information typically distributed
      by IGP routing protocols within the network.</t>
      <t>This document describes a mechanism by which link-state and TE
      information can be collected from networks and shared with external
      components using the BGP routing protocol. This is achieved using a BGP
      Network Layer Reachability Information (NLRI) encoding format. The
      mechanism applies to physical and virtual (e.g., tunnel) IGP links. The
      mechanism described is subject to policy control.</t>
      <t>Applications of this technique include Application-Layer Traffic
      Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
      <t>This document obsoletes RFC7752 RFC 7752 by completely replacing that
      document. It makes some small changes and clarifications to the previous
      specification. This document also obsoletes RFC9029 RFC 9029 by incorporating the
      updates that it made to RFC7752.</t> RFC 7752.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The contents of a Link-State Database (LSDB) or of an IGP's Traffic
      Engineering Database (TED) describe only the links and nodes within an
      IGP area. Some applications, such as end-to-end Traffic Engineering
      (TE), would benefit from visibility outside one area or Autonomous
      System (AS) to make better decisions.</t>
      <t>The IETF has defined the Path Computation Element (PCE) <xref
      target="RFC4655"/> target="RFC4655" format="default"/> as a mechanism for achieving the computation of
      end-to-end TE paths that cross crosses the visibility of more than one TED or
      that requires CPU-intensive or coordinated computations. The IETF has
      also defined the ALTO server <xref target="RFC5693"/> target="RFC5693" format="default"/> as an entity that
      generates an abstracted network topology and provides it to
      network-aware applications.</t>
      <t>Both a PCE and an ALTO server need to gather information about the
      topologies and capabilities of the network to be able to fulfill their
      function.</t>
      <t>This document describes a mechanism by which link-state and TE
      information can be collected from networks and shared with external
      components using the BGP routing protocol <xref target="RFC4271"/>. target="RFC4271" format="default"/>. This
      is achieved using a BGP Network Layer Reachability Information (NLRI)
      encoding format. The mechanism applies to physical and virtual (e.g.,
      tunnel) links. The mechanism described is subject to policy control.</t>
      <t>A router maintains one or more databases for storing link-state
      information about nodes and links in any given area. Link attributes
      stored in these databases include: local/remote IP addresses,
      local/remote interface identifiers, link IGP metric, link TE metric,
      link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class
      reservation state, preemption, and Shared Risk Link Groups (SRLGs). The
      router's BGP Link-State - Link State (BGP-LS) process can retrieve topology from
      these LSDBs and distribute it to a consumer, either directly or via a
      peer BGP speaker Speaker (typically a dedicated Route Reflector), route reflector), using the
      encoding specified in this document.</t>
      <t>An illustration of the collection of link-state and TE information
      and its distribution to consumers is shown in <xref
      target="MECHANISM-OVERVIEW"/> target="MECHANISM-OVERVIEW" format="default"/> below.</t>
      <figure anchor="MECHANISM-OVERVIEW"
              title="Collection anchor="MECHANISM-OVERVIEW">
        <name>Collection of Link-State and TE Information">
        <artwork><![CDATA[ Information</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            +-----------+
            | Consumer  |
            +-----------+
                  ^
                  |
            +-----------+             +-----------+
            |    BGP    |             |    BGP    |
            |  Speaker  |<----------->|  Speaker  |  +-----------+
            |    RR1    |             |    RRm    |  | Consumer  |
            +-----------+             +-----------+  +-----------+
                ^   ^                       ^             ^
                |   |                       |             |
          +-----+   +---------+             +---------+   |
          |                   |                       |   |
    +-----------+       +-----------+             +-----------+
    |    BGP    |       |    BGP    |             |    BGP    |
    |  Speaker  |       |  Speaker  |    . . .    |  Speaker  |
    |    R1     |       |     R2    |             |    Rn     |
    +-----------+       +-----------+             +-----------+
          ^                   ^                         ^
          |                   |                         |
         IGP                 IGP                       IGP
        ]]></artwork>
      </figure>
      <t>A BGP speaker Speaker may apply a configurable policy to the information that
      it distributes. Thus, it may distribute the real physical topology from
      the LSDB or the TED. Alternatively, it may create an abstracted
      topology, where virtual, aggregated nodes are connected by virtual
      paths. Aggregated nodes can be created, for example, out of multiple
      routers in a Point of Presence (POP). Abstracted topology can also be a
      mix of physical and virtual nodes and physical and virtual links.
      Furthermore, the BGP speaker Speaker can apply policy to determine when
      information is updated to the consumer so that there is a reduction in
      information flow from the network to the consumers. Mechanisms through
      which topologies can be aggregated or virtualized are outside the scope
      of this document.</t>
      <t>This document focuses on the specifications related to the
      origination of IGP-derived information and their propagation via BGP-LS.
      It also describes the advertisement into BGP-LS of information, either
      configured or derived, that is local to a node. In general, the
      procedures in this document form part of the base BGP-LS protocol
      specification and apply to information from other sources that are
      introduced into BGP-LS.</t>
      <t>This document obsoletes <xref target="RFC7752"/> target="RFC7752" format="default"/> by completely
      replacing that document. It makes some small changes and clarifications
      to the previous specification as documented in <xref
      target="CHANGES"/>.</t> target="CHANGES" format="default"/>.</t>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="APPL" title="Motivation numbered="true" toc="default">
      <name>Motivation and Applicability"> Applicability</name>
      <t>This section describes use cases from which the requirements can be
      derived.</t>
      <section anchor="PCE" title="MPLS-TE numbered="true" toc="default">
        <name>MPLS-TE with PCE"> PCE</name>
        <t>As described in <xref target="RFC4655"/>, target="RFC4655" format="default"/>, a PCE can be used to
        compute MPLS-TE paths within a "domain" (such as an IGP area) or
        across multiple domains (such as a multi-area AS or multiple ASes).
        <list style="symbols">
            <t>Within
        </t>
        <ul spacing="normal">
          <li>Within a single area, the PCE offers enhanced computational
            power that may not be available on individual routers,
            sophisticated policy control and algorithms, and coordination of
            computation across the whole area.</t>

            <t>If area.</li>
          <li>If a router wants to compute an MPLS-TE path across IGP areas,
            then its own TED lacks visibility of the complete topology. That
            means that the router cannot determine the end-to-end path and
            cannot even select the right exit router (Area Border Router
            (ABR)) for an optimal path. This is an issue for large-scale
            networks that need to segment their core networks into distinct
            areas but still want to take advantage of MPLS-TE.</t>
          </list></t> MPLS-TE.</li>
        </ul>
        <t>Previous solutions used per-domain path computation <xref
        target="RFC5152"/>. target="RFC5152" format="default"/>. The source router could only compute the path for
        the first area because the router only has full topological visibility
        for the first area along the path, path but not for subsequent areas.
        Per-domain path computation uses a technique called
        "loose-hop-expansion" <xref target="RFC3209"/> and selects the exit ABR and other ABRs or
        AS Border Routers (ASBRs) as loose-hops <xref target="RFC3209" format="default"/> and using the IGP-computed
        shortest path topology for the remainder of the path. This may lead to
        suboptimal paths, makes alternate/back-up path computation hard, and
        might result in no TE path being found when one does exist.</t>
        <t>The PCE presents a computation server that may have visibility into
        more than one IGP area or AS, AS or may cooperate with other PCEs to
        perform distributed path computation. The PCE needs access to the TED
        for the area(s) it serves, but <xref target="RFC4655"/> target="RFC4655" format="default"/> does not
        describe how this is achieved. Many implementations make the PCE a
        passive participant in the IGP so that it can learn the latest state
        of the network, but this may be sub-optimal suboptimal when the network is
        subject to a high degree of churn or when the PCE is responsible for
        multiple areas.</t>
        <t>The following figure shows how a PCE can get its TED information
        using the mechanism described in this document.</t>
        <figure anchor="PCE-REFERENCE"
                title="External anchor="PCE-REFERENCE">
          <name>External PCE Node Using a TED Synchronization Mechanism">
          <artwork><![CDATA[ Mechanism</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
             +----------+                           +---------+
             |  -----   |                           |   BGP   |
             | | TED |<-+-------------------------->| Speaker |
             |  -----   |   TED synchronization     |         |
             |    |     |        mechanism          +---------+
             |    |     |
             |    v     |
             |  -----   |
             | | PCE |  |
             |  -----   |
             +----------+
                  ^
                  | Request/
                  | Response
                  v
    Service  +----------+   Signaling  +----------+
    Request  | Head-End |   Protocol   | Adjacent |
    -------->|  Node    |<------------>|   Node   |
             +----------+              +----------+
      ]]></artwork>
        </figure>
        <t>The mechanism in this document allows the necessary TED information
        to be collected from the IGP within the network, filtered according to
        configurable policy, and distributed to the PCE as necessary.</t>
      </section>
      <section anchor="ALTO" title="ALTO numbered="true" toc="default">
        <name>ALTO Server Network API"> API</name>
        <t>An ALTO server <xref target="RFC5693"/> target="RFC5693" format="default"/> is an entity that generates
        an abstracted network topology and provides it to network-aware
        applications over a web-service-based API. Example applications are
        peer-to-peer (P2P) clients or trackers, or Content Distribution
        Networks (CDNs). The abstracted network topology comes in the form of
        two maps: a Network Map that specifies the allocation of prefixes to
        Partition Identifiers (PIDs), (PIDs) and a Cost Map that specifies the cost
        between PIDs listed in the Network Map. For more details, see <xref
        target="RFC7285"/>.</t> target="RFC7285" format="default"/>.</t>
        <t>ALTO abstract network topologies can be auto-generated from the
        physical topology of the underlying network. The generation would
        typically be based on policies and rules set by the operator. Both
        prefix and TE data are required: prefix data is required to generate
        ALTO Network Maps and TE (topology) data is required to generate ALTO
        Cost Maps. Prefix data is carried and originated in BGP, and TE data
        is originated and carried in an IGP. The mechanism defined in this
        document provides a single interface through which an ALTO server can
        retrieve all the necessary prefixes and network topology data from the
        underlying network. Note that an ALTO server can use other mechanisms
        to get network data, for example, peering with multiple IGP and BGP
        speakers.</t>
        Speakers.</t>
        <t>The following figure shows how an ALTO server can get network
        topology information from the underlying network using the mechanism
        described in this document.</t>
        <figure anchor="ALTO-REFERENCE"
                title="ALTO anchor="ALTO-REFERENCE">
          <name>ALTO Server Using Network Topology Information">
          <artwork><![CDATA[ Information</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  +--------+
  | Client |<--+
  +--------+   |
               |    ALTO    +--------+     Topology    +---------+
  +--------+   |  Protocol  |  ALTO  | Sync Mechanism  |   BGP   |
  | Client |<--+------------| Server |<----------------| Speaker |
  +--------+   |            |        |                 |         |
               |            +--------+                 +---------+
  +--------+   |
  | Client |<--+
  +--------+
          ]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="ROLES" title="BGP numbered="true" toc="default">
      <name>BGP Speaker Roles for BGP-LS"> BGP-LS</name>
      <t>In the illustration shown in <xref target="MECHANISM-OVERVIEW"/>, target="MECHANISM-OVERVIEW" format="default"/>, the
      BGP Speakers can be seen playing different roles in the distribution of
      information using BGP-LS. This section introduces terms that explain the
      different roles of the BGP Speakers which that are then used through throughout the rest
      of this document.</t>

      <t><list style="symbols">
          <t>BGP-LS Producer: The
      <dl newline="false" spacing="normal">
        <dt>BGP-LS Producer:</dt> <dd>The term BGP-LS Producer refers to a BGP Speaker
          that is originating link-state information into BGP. The  BGP
          Speakers R1, R2, ... Rn, Rn originate link-state information from their
          underlying link-state IGP protocols into BGP-LS. If R1 and R2 are in
          the same IGP flooding domain, then they would ordinarily originate
          the same link-state information into BGP-LS. R1 may also originate
          information from sources other than IGP, e.g. e.g., its local node
          information.</t>

          <t>BGP-LS Consumer: The
          information.</dd>
        <dt>BGP-LS Consumer:</dt> <dd>The term BGP-LS Consumer refers to a consumer
          application/process and not a BGP Speaker. The BGP Speakers RR1 and
          Rn are handing off the BGP-LS information that they have collected
          to a consumer application. The BGP protocol implementation and the
          consumer application may be on the same or different nodes. This
          document only covers the BGP implementation. The consumer
          application and the design of the interface between BGP and the
          consumer application may be implementation specific and are outside
          the scope of this document. The communication of information MUST <bcp14>MUST</bcp14> be
          unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumer
          application)
          application), and a BGP-LS Consumer MUST NOT <bcp14>MUST NOT</bcp14> be able to send
          information to a BGP Speaker for origination into BGP-LS.</t>

          <t>BGP-LS Propagator: The BGP-LS.</dd>
        <dt>BGP-LS Propagator:</dt> <dd>The term BGP-LS Propagator refers to a BGP
          Speaker that is performing BGP protocol processing on the link-state
          information. The BGP Speaker RRm propagates the BGP-LS information
          between the BGP Speaker Rn and the BGP Speaker RR1. The BGP
          implementation on RRm is propagating BGP-LS information. It performs
          handling of BGP-LS UPDATE messages and performs the BGP Decision
          Process as part of deciding what information is to be propagated.
          Similarly, the BGP Speaker RR1 is receiving BGP-LS information from
          R1, R2, and RRm and propagating the information to the BGP-LS
          Consumer after performing BGP Decision Process.</t>
        </list>The Process.</dd>
      </dl>
      <t>The above roles are not mutually exclusive. The same BGP
      Speaker may be the BGP-LS Producer for some link-state information and
      BGP-LS Propagator for some other link-state information while also
      providing this information to a BGP-LS Consumer.</t>
      <t>The rest of this document refers to the role when describing
      procedures that are specific to that role. When the role is not
      specified, then the said procedure applies to all BGP Speakers.</t>
    </section>
    <section anchor="IGPTOBGP" title="Advertising numbered="true" toc="default">
      <name>Advertising IGP Information into BGP-LS"> BGP-LS</name>
      <t>The origination and propagation of IGP link-state information via BGP
      needs to provide a consistent and accurate view of the topology of the
      IGP domain. BGP-LS provides an abstraction of the IGP specifics specifics, and
      BGP-LS Consumers may be varied types of applications.</t>
      <t>The link-state information advertised in BGP-LS from the IGPs is
      derived from the IGP LSDB built using the OSPF Link State Link-State Advertisements
      (LSAs) or the IS-IS Link State Link-State Packets (LSPs). However, it does not
      serve as a verbatim reflection of the originating router's LSDB. It does
      not include the LSA/LSP sequence number information since a single
      link-state object may be put together with information that is coming
      from multiple LSAs/LSPs. Also, not all of the information carried in
      LSAs/LSPs may be required or suitable for advertisement via BGP-LS
      (e.g., ASBR reachability in OSPF, OSPF virtual links, link-local scoped link-local-scoped
      information, etc.). The LSAs/LSPs that are purged or max-aged aged out are not
      included in the BGP-LS advertisement even though they may be present in
      the LSDB (e.g., for the IGP flooding purposes). The information from the
      LSAs/LSPs that is invalid or malformed or that which needs to be ignored
      per the respective IGP protocol specifications are also not included in
      the BGP-LS advertisement.</t>
      <t>The details of the interface between IGPs and BGP for the
      advertisement of link-state information are outside the scope of this
      document. In some cases, the information derived from IGP processing
      (e.g., combination of link-state object from across multiple LSAs/LSPs,
      leveraging reachability and two-way connectivity checks, etc.) is
      required for the advertisement of link-state information into BGP-LS.</t>
    </section>
    <section anchor="BGPLS" title="Carrying numbered="true" toc="default">
      <name>Carrying Link-State Information in BGP"> BGP</name>
      <t>The link-state information is carried in BGP UPDATE messages as: (1)
      BGP NLRI information carried within MP_REACH_NLRI and MP_UNREACH_NLRI
      attributes that describes link, node, or prefix object, objects and (2) a BGP
      path attribute (BGP-LS Attribute) that carries properties of the link,
      node, or prefix objects such as the link and prefix metric or metric, auxiliary
      Router-IDs of nodes, etc.</t>
      <t>It is desirable to keep the dependencies on the protocol source of
      this attribute to a minimum and represent any content in an IGP- neutral IGP-neutral
      way, such that applications that want to learn about a link-state
      topology do not need to know about any OSPF or IS-IS protocol
      specifics.</t>
      <t>This section mainly describes the procedures for a BGP-LS Producer to
      originate link-state information into BGP-LS.</t>
      <section anchor="TLV-section" title="TLV Format"> numbered="true" toc="default">
        <name>TLV Format</name>
        <t>Information in the Link-State NLRIs and the BGP-LS Attribute is
        encoded in Type/Length/Value triplets. The TLV format is shown in
        <xref target="TLV-figure"/> target="TLV-figure" format="default"/> and applies to both the NLRI and the
        BGP-LS Attribute encodings.</t>

        <t><figure anchor="TLV-figure" title="TLV Format">
            <artwork><![CDATA[
        <figure anchor="TLV-figure">
          <name>TLV Format</name>
          <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                        Value (variable)                     //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]></artwork>
          </figure></t>
        </figure>
        <t>The Length field defines the length of the value portion in octets
        (thus, a TLV with no value portion would have a length of zero). The
        TLV is not padded to 4-octet alignment. Unknown and unsupported types
        MUST
        <bcp14>MUST</bcp14> be preserved and propagated within both the NLRI and the BGP-LS
        Attribute. The presence of unknown or unexpected TLVs MUST NOT <bcp14>MUST NOT</bcp14> result
        in the NLRI or the BGP-LS Attribute being considered malformed. An
        example of an unexpected TLV is when a TLV is received along with an
        update for a link state link-state object other than the one that the TLV is
        specified as associated with.</t>
        <t>To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST <bcp14>MUST</bcp14>
        be ordered in ascending order by TLV Type. If there are multiple TLVs
        of the same type within a single NLRI, then the TLVs sharing the same
        type MUST <bcp14>MUST</bcp14> be first in ascending order based on the length Length field
        followed by ascending order based on the value Value field. Comparison of
        the value Value fields is performed by treating the entire field as opaque
        binary data and ordered lexicographically (i.e., treating each byte of
        binary data as a symbol to compare, with the symbols ordered by their
        numerical value). NLRIs having TLVs which that do not follow the above
        ordering rules MUST <bcp14>MUST</bcp14> be considered as malformed by a BGP-LS Propagator.
        This insistence on canonical ordering ensures that multiple variant
        copies of the same NLRI from multiple BGP-LS Producers and the
        ambiguity arising therefrom is prevented.</t>
        <t>For both the NLRI and BGP-LS Attribute parts, all TLVs are
        considered as optional except where explicitly specified as mandatory
        or required in specific conditions.</t>
        <t>The TLVs within the BGP-LS Attribute SHOULD <bcp14>SHOULD</bcp14> be ordered in ascending
        order by TLV type. The BGP-LS Attribute with unordered TLVs MUST NOT <bcp14>MUST NOT</bcp14> be
        considered malformed.</t>
        <t>The origination of the same link-state information by multiple
        BGP-LS Producers may result in differences and inconsistencies due to
        the inclusion or exclusion of optional TLVs. Different optional TLVs
        in the NLRI results in multiple NLRIs being generated for the same
        link-state object. Different optional TLVs in the BGP-LS Attribute may
        result in the propagation of partial information. To address these
        inconsistencies, the BGP-LS Consumer will need to recognize and merge
        the duplicate information, information or to deal with missing information. The
        deployment of BGP-LS Producers that consistently originate the same
        set of optional TLVs is recommended to mitigate such situations.</t>
      </section>
      <section anchor="BGPLSNLRI" title="The numbered="true" toc="default">
        <name>The Link-State NLRI"> NLRI</name>
        <t>The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's
        containers for carrying opaque information. This specification defines
        three Link-State NLRI types that describe either a node, a link, or a
        prefix.</t>
        <t>All non-VPN link, node, and prefix information SHALL <bcp14>SHALL</bcp14> be encoded
        using AFI 16388 / SAFI 71. VPN link, node, and prefix information
        SHALL
        <bcp14>SHALL</bcp14> be encoded using AFI 16388 / SAFI 72.</t>
        <t>For two BGP speakers Speakers to exchange Link-State NLRI, they MUST <bcp14>MUST</bcp14> use BGP
        Capabilities Advertisement to ensure that they are both capable of
        properly processing such NLRI. This is done as specified in <xref
        target="RFC4760"/>, target="RFC4760" format="default"/> by using capability code 1 (multiprotocol BGP),
        with AFI 16388 / SAFI 71 for BGP-LS, BGP-LS and AFI 16388 / SAFI 72 for
        BGP&nbhy;LS&nbhy;VPN.</t>
        BGP-LS-VPN.</t>
        <t>New Link-State NLRI Types types may be introduced in the future. Since
        supported NLRI type values within the address family are not expressed
        in the Multiprotocol BGP (MP-BGP) capability <xref target="RFC4760"/>, target="RFC4760" format="default"/>,
        it is possible that a BGP speaker Speaker has advertised support for BGP-LS
        but does not support a particular Link-State NLRI type. To allow the
        introduction of new Link-State NLRI types seamlessly in the future, future
        without the need for upgrading all BGP speakers Speakers in the propagation
        path (e.g., a route reflector), this document deviates from the
        default handling behavior specified by section 5.4 Section
        <xref target="RFC7606" format="default" sectionFormat="bare" section="5.4"/> (paragraph 2) of <xref target="RFC7606"/> for Link-State address-family. address family. An
        implementation MUST <bcp14>MUST</bcp14> handle unknown Link-State NLRI types as opaque
        objects and MUST <bcp14>MUST</bcp14> preserve and propagate them.</t>
        <t>The format of the Link-State NLRI is shown in the following
        figures.</t>
        <figure anchor="LSSAFI"
                title="Link-State anchor="LSSAFI">
          <name>Link-State AFI 16388 / SAFI 71 NLRI Format">
          <artwork><![CDATA[ Format</name>
          <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            NLRI Type          |     Total NLRI Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //                  Link-State NLRI (variable)                 //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ]]></artwork>
        </figure>
        <figure anchor="LSVPNSAFI"
                title="Link-State anchor="LSVPNSAFI">
          <name>Link-State VPN AFI 16388 / SAFI 72 NLRI Format">
          <artwork><![CDATA[ Format</name>
          <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            NLRI Type          |     Total NLRI Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                Route Distinguisher (8 octets)                 +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //                  Link-State NLRI (variable)                 //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
        </figure>
        <t>The Total NLRI Length field contains the cumulative length, in
        octets, of the rest of the NLRI, not including the NLRI Type field or
        itself. For VPN applications, it also includes the length of the Route
        Distinguisher.</t>

        <texttable
        <table anchor="NLRI-TYPES" title="NLRI Types">
          <ttcol align="center">Type</ttcol>

          <ttcol align="center">
          <name>NLRI Types</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="left">NLRI Type</ttcol>

          <c>1</c>

          <c>Node NLRI</c>

          <c>2</c>

          <c>Link NLRI</c>

          <c>3</c>

          <c>IPv4 Type</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">1</td>
              <td align="left">Node NLRI</td>
            </tr>
            <tr>
              <td align="center">2</td>
              <td align="left">Link NLRI</td>
            </tr>
            <tr>
              <td align="center">3</td>
              <td align="left">IPv4 Topology Prefix NLRI</c>

          <c>4</c>

          <c>IPv6 NLRI</td>
            </tr>
            <tr>
              <td align="center">4</td>
              <td align="left">IPv6 Topology Prefix NLRI</c>
        </texttable> NLRI</td>
            </tr>
          </tbody>
        </table>
        <t>Route Distinguishers are defined and discussed in <xref
        target="RFC4364"/>.</t> target="RFC4364" format="default"/>.</t>
        <t>The Node NLRI (NLRI Type = 1) is shown in the following figure.</t>
        <figure anchor="NODE-NLRI" title="The anchor="NODE-NLRI">
          <name>The Node NLRI Format">
          <artwork><![CDATA[ Format</name>
          <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
  +-+-+-+-+-+-+-+-+
  |  Protocol-ID  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Identifier                          |
  +                           (8 octets)                          +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //             Local Node Descriptors TLV (variable)           //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
        </figure>
        <t>The Link NLRI (NLRI Type = 2) is shown in the following figure.</t>
        <figure anchor="LINK-NLRI" title="The anchor="LINK-NLRI">
          <name>The Link NLRI Format">
          <artwork><![CDATA[ Format</name>
          <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
  +-+-+-+-+-+-+-+-+
  |  Protocol-ID  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Identifier                          |
  +                           (8 octets)                          +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //            Local Node Descriptors TLV (variable)            //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //            Remote Node Descriptors TLV (variable)           //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //               Link Descriptors TLVs (variable)              //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
        </figure>
        <t>The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the
        same format, format as shown in the following figure.</t>
        <figure anchor="PREFIX-NLRI"
                title="The anchor="PREFIX-NLRI">
          <name>The IPv4/IPv6 Topology Prefix NLRI Format">
          <artwork><![CDATA[ Format</name>
          <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
  +-+-+-+-+-+-+-+-+
  |  Protocol-ID  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Identifier                          |
  +                           (8 octets)                          +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //            Local Node Descriptors TLV (variable)            //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //             Prefix Descriptors TLVs (variable)              //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
        </figure>
        <t>The Protocol-ID field can contain one of the following values:</t>

        <texttable
        <table anchor="PROTOCOL-IDS" title="Protocol Identifiers">
          <ttcol align="center">Protocol-ID</ttcol>

          <ttcol align="center">
          <name>Protocol Identifiers</name>
          <thead>
            <tr>
              <th align="center">Protocol-ID</th>
              <th align="left">NLRI information source protocol</ttcol>

          <c>1</c>

          <c>IS-IS protocol</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">1</td>
              <td align="left">IS-IS Level 1</c>

          <c>2</c>

          <c>IS-IS 1</td>
            </tr>
            <tr>
              <td align="center">2</td>
              <td align="left">IS-IS Level 2</c>

          <c>3</c>

          <c>OSPFv2</c>

          <c>4</c>

          <c>Direct</c>

          <c>5</c>

          <c>Static configuration</c>

          <c>6</c>

          <c>OSPFv3</c>
        </texttable> 2</td>
            </tr>
            <tr>
              <td align="center">3</td>
              <td align="left">OSPFv2</td>
            </tr>
            <tr>
              <td align="center">4</td>
              <td align="left">Direct</td>
            </tr>
            <tr>
              <td align="center">5</td>
              <td align="left">Static configuration</td>
            </tr>
            <tr>
              <td align="center">6</td>
              <td align="left">OSPFv3</td>
            </tr>
          </tbody>
        </table>
        <t>The 'Direct' and 'Static configuration' protocol types SHOULD <bcp14>SHOULD</bcp14> be
        used when BGP-LS is sourcing local information. For all information
        derived from other protocols, the corresponding Protocol-ID MUST <bcp14>MUST</bcp14> be
        used. If BGP-LS has direct access to interface information and wants
        to advertise a local link, then the Protocol-ID 'Direct' SHOULD <bcp14>SHOULD</bcp14> be
        used. For modeling virtual links, such as described in <xref
        target="LINKPATHAGGREGATION"/>, target="LINKPATHAGGREGATION" format="default"/>, the Protocol-ID 'Static configuration'
        SHOULD
        <bcp14>SHOULD</bcp14> be used.</t>
        <t>A router may run multiple protocol instances of OSPF or IS-IS
        whereby it becomes a border router between multiple IGP domains. Both
        OSPF and IS-IS may also run multiple routing protocol instances over
        the same link. See <xref target="RFC8202"/> target="RFC8202" format="default"/> and <xref
        target="RFC6549"/>. target="RFC6549" format="default"/>. These instances define independent IGP routing
        domains. The Identifier field carries an 8-octet BGP-LS Instance
        Identifier (Instance-ID) number that is used to identify the IGP
        routing domain where the NLRI belongs. The NLRIs representing
        link-state objects (nodes, links, or prefixes) from the same IGP
        routing instance should have the same BGP-LS Instance-ID. NLRIs with
        different BGP-LS Instance-IDs are considered to be from different IGP
        routing instances.</t>
        <t>To support multiple IGP instances, an implementation needs to
        support the configuration of unique BGP-LS Instance-IDs at the routing
        protocol instance level. The BGP-LS Instance-ID 0 is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to be
        used when there is only a single protocol instance in the network
        where BGP-LS is operational. The network operator MUST <bcp14>MUST</bcp14> assign the same
        BGP-LS Instance-IDs on all BGP-LS Producers within a given IGP domain.
        Unique BGP-LS Instance-ID MUST Instance-IDs <bcp14>MUST</bcp14> be assigned to routing protocol
        instances operating in different IGP domains. This can allow the
        BGP-LS Consumer to build an accurate segregated multi-domain topology
        based on the BGP-LS Instance-ID.</t>
        <t>When the above-described semantics and recommendations are not
        followed, a BGP-LS Consumer may see more than one link-state objects object
        for the same node, link, or prefix (each with a different BGP-LS
        Instance-ID) when there are multiple BGP-LS Producers deployed. This
        may also result in the BGP-LS Consumers getting an inaccurate
        network-wide topology.</t>
        <t>Each Node Descriptor, Link Descriptor, and Prefix Descriptor
        consists of one or more TLVs, as described in the following sections.
        These Descriptor TLVs are applicable for the Node, Link, and Prefix
        NLRI Types for the protocols that are listed in <xref
        target="PROTOCOL-IDS"/>. target="PROTOCOL-IDS" format="default"/>. Documents extending BGP-LS specifications
        with new NLRI Types and/or protocols MUST <bcp14>MUST</bcp14> specify the NLRI Descriptors descriptors
        for them.</t>
        <t>When adding, removing, or modifying a TLV/sub-TLV from a Link-State
        NLRI, the BGP-LS Producer MUST <bcp14>MUST</bcp14> withdraw the old NLRI by including it
        in the MP_UNREACH_NLRI. Not doing so can result in duplicate and
        in-consistent
        inconsistent link-state objects hanging around in the BGP-LS
        table.</t>
        <section anchor="NODEDESC" title="Node Descriptors"> numbered="true" toc="default">
          <name>Node Descriptors</name>
          <t>Each link is anchored by a pair of Router-IDs that are used by
          the underlying IGP, namely, namely a 48-bit ISO System-ID for IS-IS and a
          32-bit Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
          additional auxiliary Router-IDs, mainly for Traffic Engineering
          purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
          Router-IDs <xref target="RFC5305"/> target="RFC5305" format="default"/> <xref target="RFC6119"/>. target="RFC6119" format="default"/>. When
          configured, these auxiliary TE Router-IDs (TLV 1028/1029) MUST <bcp14>MUST</bcp14> be
          included in the node attribute described in <xref
          target="NODEATTR"/> target="NODEATTR" format="default"/> and MAY <bcp14>MAY</bcp14> be included in the link attribute
          described in <xref target="link_attribute"/>. target="link_attribute" format="default"/>. The advertisement of
          the TE Router-IDs can help a BGP-LS Consumer to correlate multiple
          link-state objects (e.g. (e.g., in different IGP instances or areas/levels)
          to the same node in the network.</t>
          <t>It is desirable that the Router-ID assignments inside the Node
          Descriptors are globally unique. However, there may be Router-ID
          spaces (e.g., ISO) where no global registry exists, or worse,
          Router-IDs have been allocated following the private-IP allocation
          described in <xref target="RFC1918"/>. target="RFC1918" format="default"/>. BGP-LS uses the Autonomous
          System (AS) Number to disambiguate the Router-IDs, as described in
          <xref target="gbl_uniqueness"/>.</t> target="gbl_uniqueness" format="default"/>.</t>
          <section anchor="gbl_uniqueness"
                   title="Globally numbered="true" toc="default">
            <name>Globally Unique Node/Link/Prefix Identifiers"> Identifiers</name>
            <t>One problem that needs to be addressed is the ability to
            identify an IGP node globally (by "globally", we mean within the
            BGP-LS database collected by all BGP-LS speakers Speakers that talk to each
            other). This can be expressed through the following two
            requirements: <list hangIndent="6" style="hanging">
                <t hangText="(A)">The </t>
            <ol spacing="normal" type="(%C)" indent="6">
              <li>The same node MUST NOT <bcp14>MUST NOT</bcp14> be represented by two
                keys (otherwise, one node will look like two nodes).</t>

                <t hangText="(B)">Two nodes).</li>
              <li>Two different nodes MUST NOT <bcp14>MUST NOT</bcp14> be represented
                by the same key (otherwise, two nodes will look like one
                node).</t>
              </list></t>
                node).</li>
            </ol>
            <t>We define an "IGP domain" to be the set of nodes (hence, by
            extension
            extension, links and prefixes) within which each node has a unique
            IGP representation by using the combination of OSPF Area-ID,
            Router-ID, Protocol-ID, Multi-Topology ID, Identifier (MT-ID), and BGP-LS Instance-ID.
            The problem is that BGP may receive node/link/prefix information
            from multiple independent "IGP domains", and we need to
            distinguish between them. Moreover, we can't assume there is
            always one and only one IGP domain per AS. During IGP transitions,
            it may happen that two redundant IGPs are in place.</t>
            <t>Furthermore, in deployments where BGP-LS is used to advertise
            topology from multiple-ASes, multiple ASes, the AS Autonomous System Number (ASN) is used to distinguish
            topology information reported from different ASes.</t>
            <t>The BGP-LS Instance-ID carried in the Identifier field field, as
            described earlier along with a set of sub-TLVs described in <xref
            target="node_desc_tlvs"/>, target="node_desc_tlvs" format="default"/>, allows specification of a flexible key
            for any given node/link information such that the global
            uniqueness of the NLRI is ensured. Since the BGP-LS Instance-ID is
            operator assigned, its allocation scheme can ensure that each IGP
            domain is uniquely identified even across a multi-AS network.</t>
          </section>
          <section anchor="LOCALNODEDESC" title="Local numbered="true" toc="default">
            <name>Local Node Descriptors"> Descriptors</name>
            <t>The Local Node Descriptors TLV contains Node Descriptors for
            the node anchoring the local end of the link. This is a mandatory
            TLV in all three types of NLRIs (node, link, and prefix). The Type
            is 256. The length of this TLV is variable. The value contains one
            or more Node Descriptor Sub-TLVs sub-TLVs defined in <xref
            target="node_desc_tlvs"/>.</t> target="node_desc_tlvs" format="default"/>.</t>
            <figure anchor="LOCALNODEDESCTLV"
                    title="Local anchor="LOCALNODEDESCTLV">
              <name>Local Node Descriptors TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //              Node Descriptor Sub-TLVs (variable)            //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>
          </section>
          <section anchor="REMOTENODEDESC" title="Remote numbered="true" toc="default">
            <name>Remote Node Descriptors"> Descriptors</name>
            <t>The Remote Node Descriptors TLV contains Node Descriptors for
            the node anchoring the remote end of the link. This is a mandatory
            TLV for Link NLRIs. The type Type is 257. The length of this TLV is
            variable. The value contains one or more Node Descriptor Sub-TLVs sub-TLVs
            defined in <xref target="node_desc_tlvs"/>.</t> target="node_desc_tlvs" format="default"/>.</t>
            <figure anchor="REMOTENODEDESCTLV"
                    title="Remote anchor="REMOTENODEDESCTLV">
              <name>Remote Node Descriptors TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //              Node Descriptor Sub-TLVs (variable)            //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>
          </section>
          <section anchor="node_desc_tlvs" title="Node numbered="true" toc="default">
            <name>Node Descriptor Sub-TLVs"> Sub-TLVs</name>
            <t>The Node Descriptor Sub-TLV sub-TLV type code points and lengths are
            listed in the following table:</t>

            <texttable
            <table anchor="table_local_anchor_node_tlv"
                       title="Node align="center">
              <name>Node Descriptor Sub-TLVs">
              <ttcol Sub-TLVs</name>
              <thead>
                <tr>
                  <th align="center">Sub-TLV Code Point</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="right">Length</ttcol>

              <c>512</c>

              <c>Autonomous System</c>

              <c>4</c>

              <c>513</c>

              <c>BGP-LS Point</th>
                  <th align="left">Description</th>
                  <th align="right">Length</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">512</td>
                  <td align="left">Autonomous System</td>
                  <td align="right">4</td>
                </tr>
                <tr>
                  <td align="center">513</td>
                  <td align="left">BGP-LS Identifier (deprecated)</c>

              <c>4</c>

              <c>514</c>

              <c>OSPF Area-ID</c>

              <c>4</c>

              <c>515</c>

              <c>IGP Router-ID</c>

              <c>Variable</c>
            </texttable> (deprecated)</td>
                  <td align="right">4</td>
                </tr>
                <tr>
                  <td align="center">514</td>
                  <td align="left">OSPF Area-ID</td>
                  <td align="right">4</td>
                </tr>
                <tr>
                  <td align="center">515</td>
                  <td align="left">IGP Router-ID</td>
                  <td align="right">Variable</td>
                </tr>
              </tbody>
            </table>
            <t>The sub-TLV values in Node Descriptor TLVs are defined as
            follows:</t>

            <t><list style="hanging">
                <t hangText="Autonomous System:">Opaque
            <dl newline="false" spacing="normal">
              <dt>Autonomous System:</dt>
              <dd>Opaque value (32-bit AS
                Number). This is an optional TLV. The value SHOULD <bcp14>SHOULD</bcp14> be set to
                the AS Number associated with the BGP process originating the
                link-state information. An implementation MAY <bcp14>MAY</bcp14> provide a
                configuration option on the BGP-LS Producer to use a different
                value;
                value, e.g., to avoid collisions when using private AS
                numbers.</t>

                <t hangText="BGP-LS Identifier:">Opaque
                Numbers.</dd>
              <dt>BGP-LS Identifier:</dt>
              <dd>Opaque value (32-bit ID).
                This is an optional TLV which that has been deprecated by this
                document (refer to <xref target="CHANGES"/> target="CHANGES" format="default"/> for more details).
                It MAY <bcp14>MAY</bcp14> be advertised for compatibility with <xref
                target="RFC7752"/> target="RFC7752" format="default"/> implementations. See the final paragraph of
                this section for further considerations and a recommended
                default value.</t>

                <t hangText="OSPF Area-ID:">Used value.</dd>
              <dt>OSPF Area-ID:</dt>
              <dd>Used to identify the 32-bit area
                to which the information advertised in the NLRI belongs. This
                is a mandatory TLV when originating information from OSPF that
                is derived from area-scope LSAs. The OSPF Area Identifier
                allows different NLRIs of the same router to be differentiated
                on a per-area basis. It is not used for NLRIs when carrying
                information that is derived from AS-scope LSAs as that
                information is not associated with a specific area.</t>

                <t hangText="IGP Router-ID:">Opaque area.</dd>
		<dt>IGP Router-ID:</dt>
              <dd>Opaque value. This is a mandatory TLV when
	      originating information from IS-IS, OSPF, direct 'Direct', or
                static. 'Static
	      configuration'. For an IS-IS non-pseudonode, this contains a 6-octet
                ISO Node-ID (ISO system-ID). System-ID). For an IS-IS pseudonode
                corresponding to a LAN, this contains the 6-octet ISO Node-ID
                of the Designated Intermediate System (DIS) followed by a
                1-octet, nonzero PSN identifier (7 octets in total). For an
                OSPFv2 or OSPFv3 non-pseudonode, this contains the 4-octet
                Router-ID. For an OSPFv2 pseudonode representing a LAN, this
                contains the 4-octet Router-ID of the Designated Router (DR)
                followed by the 4-octet IPv4 address of the DR's interface to
                the LAN (8 octets in total). Similarly, for an OSPFv3
                pseudonode, this contains the 4-octet Router-ID of the DR
                followed by the 4-octet interface identifier of the DR's
                interface to the LAN (8 octets in total). The TLV size in
                combination with the protocol identifier enables the decoder
                to determine the type of the node. For Direct 'Direct' or Static
                configuration, 'Static
                configuration', the value SHOULD <bcp14>SHOULD</bcp14> be taken from an IPv4 or IPv6
                address (e.g. (e.g., loopback interface) configured on the node.    When the node is running an IGP protocol,
   an implementation MAY <bcp14>MAY</bcp14> choose to use the IGP Router-ID for direct 'Direct'
   or static.</t>
              </list></t>

            <t>There MUST 'Static configuration'.</dd>
            </dl>
            <t>At most, there <bcp14>MUST</bcp14> be at most one instance of each sub-TLV type present
            in any Node Descriptor. The sub-TLVs within a Node Descriptor MUST <bcp14>MUST</bcp14>
            be arranged in ascending order by sub-TLV type. This needs to be
            done to compare NLRIs, even when an implementation encounters an
            unknown sub-TLV. Using stable sorting, an implementation can do a
            binary comparison of NLRIs and hence allow incremental deployment
            of new key sub-TLVs.</t>
            <t>The BGP-LS Identifier was introduced by <xref
            target="RFC7752"/> target="RFC7752" format="default"/>, and its use is being deprecated by this
            document. Implementations SHOULD <bcp14>SHOULD</bcp14> support the advertisement of this
            sub-TLV for backward compatibility in deployments where there are
            BGP-LS Producer implementations that conform to <xref
            target="RFC7752"/> target="RFC7752" format="default"/> to ensure consistency of NLRI encoding for
            link-state objects. The default value of 0 is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to be
            used when a BGP-LS Producer includes this sub-TLV when originating
            information into BGP-LS. Implementations SHOULD <bcp14>SHOULD</bcp14> provide an option
            to configure this value for backward compatibility reasons. As a
            reminder, the use of the BGP-LS Instance-ID that is carried in the
            Identifier field is the way of segregation of link-state objects
            of different IGP domains in BGP-LS.</t>
          </section>
        </section>
        <section anchor="LINKDESC" title="Link Descriptors"> numbered="true" toc="default">
          <name>Link Descriptors</name>
          <t>The Link Descriptor field is a set of Type/Length/Value (TLV)
          triplets. The format of each TLV is shown in <xref
          target="TLV-section"/>. target="TLV-section" format="default"/>. The Link Descriptor TLVs uniquely identify a
          link among multiple parallel links between a pair of anchor routers.
          A link described by the Link Descriptor TLVs actually is a
          "half-link", a unidirectional representation of a logical link. To
          fully describe a single logical link, two anchor routers advertise a
          half-link each, i.e., two Link NLRIs are advertised for a given
          point-to-point link.</t>
          <t>A link between two nodes is not considered as complete (or
          available) unless it is described by the two Link NLRIs
          corresponding to the half-link representation from the pair of
          anchor nodes. This check is similar to the 'two-way connectivity
          check' that is performed by link-state IGPs.</t>
          <t>An implementation MAY <bcp14>MAY</bcp14> suppress the advertisement of a Link NLRI,
          corresponding to a half-link, from a link-state IGP unless the IGP
          has verified that the link is being reported in the IS-IS LSP or
          OSPF Router LSA by both the nodes connected by that link. This
          'two-way connectivity check' is performed by link-state IGPs during
          their computation and can be leveraged before passing information
          for any half-link that is reported from these IGPs into BGP-LS. This
          ensures that only those Link State link-state IGP adjacencies which that are
          established get reported via Link NLRIs. Such a 'two-way
          connectivity check' could be also be required in certain cases (e.g.,
          with OSPF) to obtain the proper link identifiers of the remote
          node.</t>
          <t>The format and semantics of the Value fields in most Link
          Descriptor TLVs correspond to the format and semantics of value Value
          fields in IS-IS Extended IS Reachability sub-TLVs, which are defined in <xref
          target="RFC5305"/>, target="RFC5305" format="default"/>, <xref target="RFC5307"/>, target="RFC5307" format="default"/>, and <xref
          target="RFC6119"/>. target="RFC6119" format="default"/>. Although the encodings for Link Descriptor TLVs
          were originally defined for IS-IS, the TLVs can carry data sourced
          by either IS-IS or OSPF.</t>
          <t>The following TLVs are defined as Link Descriptors in the Link
          NLRI:</t>

          <texttable
          <table anchor="table_link_descriptor_tlv"
                     title="Link align="center">
            <name>Link Descriptor TLVs">
            <ttcol TLVs</name>
            <thead>
              <tr>
                <th align="center">TLV Code Point</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol Point</th>
                <th align="left">Description</th>
                <th align="center">IS-IS TLV/Sub-TLV</ttcol>

            <ttcol align="left">Reference (RFC/Section)</ttcol>

            <c>258</c>

            <c>Link TLV/Sub-TLV</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">258</td>
                <td align="left">Link Local/Remote Identifiers</c>

            <c>22/4</c>

            <c><xref target="RFC5307"/> / 1.1</c>

            <c>259</c>

            <c>IPv4 Identifiers</td>
                <td align="center">22/4</td>
                <td align="left"><xref target="RFC5307" sectionFormat="comma" section="1.1"/></td>
              </tr>
              <tr>
                <td align="center">259</td>
                <td align="left">IPv4 interface address</c>

            <c>22/6</c>

            <c><xref target="RFC5305"/> / 3.2</c>

            <c>260</c>

            <c>IPv4 address</td>
                <td align="center">22/6</td>
                <td align="left"><xref target="RFC5305" sectionFormat="comma" section="3.2"/></td>
              </tr>
              <tr>
                <td align="center">260</td>
                <td align="left">IPv4 neighbor address</c>

            <c>22/8</c>

            <c><xref target="RFC5305"/> / 3.3</c>

            <c>261</c>

            <c>IPv6 address</td>
                <td align="center">22/8</td>
                <td align="left"><xref target="RFC5305" sectionFormat="comma" section="3.3"/></td>
              </tr>
              <tr>
                <td align="center">261</td>
                <td align="left">IPv6 interface address</c>

            <c>22/12</c>

            <c><xref target="RFC6119"/> / 4.2</c>

            <c>262</c>

            <c>IPv6 address</td>
                <td align="center">22/12</td>
                <td align="left"><xref target="RFC6119" sectionFormat="comma" section="4.2"/></td>
              </tr>
              <tr>
                <td align="center">262</td>
                <td align="left">IPv6 neighbor address</c>

            <c>22/13</c>

            <c><xref target="RFC6119"/> / 4.3</c>

            <c>263</c>

            <c>Multi-Topology Identifier</c>

            <c>---</c>

            <c><xref target="MT-ID"/></c>
          </texttable> address</td>
                <td align="center">22/13</td>
                <td align="left"><xref target="RFC6119" sectionFormat="comma" section="4.3"/></td>
              </tr>
              <tr>
                <td align="center">263</td>
                <td align="left">Multi-Topology Identifier</td>
                <td align="center">---</td>
                <td align="left"><xref target="MT-ID" format="default"/></td>
              </tr>
            </tbody>
          </table>
          <t>The information about a link present in the LSA/LSP originated by
          the local node of the link determines the set of TLVs in the Link
          Descriptor of the link. <list style="hanging">
              <t>If </t>
            <t indent="3">If interface and neighbor addresses, either IPv4 or IPv6, are
              present, then the interface/neighbor address TLVs MUST <bcp14>MUST</bcp14> be
              included, and the Link Local/Remote Identifiers TLV MUST NOT <bcp14>MUST NOT</bcp14> be
              included in the Link Descriptor. The Link Local/Remote
              Identifiers TLV MAY <bcp14>MAY</bcp14> be included in the link attribute when
              available. IPv4/IPv6 link-local addresses MUST NOT <bcp14>MUST NOT</bcp14> be carried in
              the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262)
              as descriptors of a link as since they are not considered unique.</t>

              <t>If
            <t indent="3">If interface and neighbor addresses are not present and the
              link local/remote identifiers are present, then the Link
              Local/Remote Identifiers TLV MUST <bcp14>MUST</bcp14> be included in the Link
              Descriptor. The Link Local/Remote Identifiers MUST identifiers <bcp14>MUST</bcp14> be included
              in the Link Descriptor also and in the case of links having only
              IPv6 link-local addressing on them.</t>

              <t>The
            <t indent="3">The Multi-Topology Identifier TLV MUST <bcp14>MUST</bcp14> be included as a Link
              Descriptor if the underlying IGP link object is associated with
              a non-default topology.</t>
            </list></t>
          <t>The TLVs/sub-TLVs corresponding to the interface addresses and/or
          the local/remote identifiers may not always be signaled in the IGPs
          unless their advertisement is enabled specifically. In such cases,
          it is valid to advertise a BGP-LS Link NLRI without any of these
          identifiers.</t>
          <section anchor="MT-ID" title="Multi-Topology ID"> numbered="true" toc="default">
            <name>Multi-Topology Identifier</name>
            <t>The Multi-Topology ID Identifier (MT-ID) TLV carries one or more IS-IS or
            OSPF Multi-Topology IDs Identifiers for a link, node, or prefix.</t>
            <t>The semantics of the IS-IS MT-ID are defined in sections 7.1 Sections <xref target="RFC5120" section="7.1" sectionFormat="bare"/> and 7.2
            <xref target="RFC5120" section="7.2" sectionFormat="bare"/> of <xref target="RFC5120"/>. target="RFC5120" format="default"/>. The semantics of the OSPF
            MT-ID are defined in section 3.7 of <xref target="RFC4915"/>. target="RFC4915" section="3.7" sectionFormat="of" format="default"/>. If
            the value in the MT-ID TLV is derived from OSPF, then the upper R
            bits of the MT-ID field MUST <bcp14>MUST</bcp14> be set to 0 and only the values from
            0 to 127 are valid for the MT-ID.</t>
            <t>The format of the MT-ID TLV is shown in the following
            figure.</t>

            <t><figure anchor="MTIDTLV" title="Multi-Topology ID

            <figure anchor="MTIDTLV">
              <name>Multi-Topology Identifier TLV Format">
                <artwork><![CDATA[ Format</name>
              <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=2*n           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R R R R|  Multi-Topology ID 1  |             ....             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //             ....             |R R R R|  Multi-Topology ID n  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ]]></artwork>
              </figure></t>

            <t>where
            </figure>
            <t>The Type is 263, Length the length is 2*n, and n is the number of MT-IDs
            carried in the TLV.</t>
            <t>The MT-ID TLV MAY <bcp14>MAY</bcp14> be included as a Link Descriptor, as a Prefix
            Descriptor, or in the BGP-LS Attribute of a Node NLRI. When
            included as a Link or Prefix Descriptor, only a single MT-ID TLV
            containing the MT-ID of the topology where the link or the prefix
            is reachable is allowed. In case one wants to advertise multiple
            topologies for a given Link Descriptor or Prefix Descriptor,
            multiple NLRIs MUST <bcp14>MUST</bcp14> be generated where each NLRI contains a single
            unique MT-ID. When used as a Link or Prefix Descriptor for IS-IS,
            the Bits R are reserved and MUST <bcp14>MUST</bcp14> be set to 0 (as per section 7.2
            of <xref target="RFC5120"/>) target="RFC5120" section="7.2" sectionFormat="of" format="default"/>) when originated and ignored on
            receipt.</t>
            <t>In the BGP-LS Attribute of a Node NLRI, one MT-ID TLV
            containing the array of MT-IDs of all topologies where the node is
            reachable is allowed. When used in the Node Attribute TLV for
            IS-IS, the Bits R are set as per section 7.1 of <xref
            target="RFC5120"/>.</t> target="RFC5120" section="7.1" sectionFormat="of" format="default"/>.</t>
          </section>
        </section>
        <section anchor="PREFIXDESC" title="Prefix Descriptors"> numbered="true" toc="default">
          <name>Prefix Descriptors</name>
          <t>The Prefix Descriptor field is a set of Type/Length/Value (TLV)
          triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6
          prefix originated by a node. The following TLVs are defined as
          Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:</t>

          <texttable

          <table anchor="table_prefix_descriptor_tlv"
                     title="Prefix align="center">
            <name>Prefix Descriptor TLVs">
            <ttcol TLVs</name>
            <thead>
              <tr>
                <th align="center">TLV Code Point</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol align="center">Length</ttcol>

            <ttcol align="left">Reference (RFC/Section)</ttcol>

            <c>263</c>

            <c>Multi-Topology Identifier</c>

            <c>variable</c>

            <c><xref target="MT-ID"/></c>

            <c>264</c>

            <c>OSPF Point</th>
                <th align="left">Description</th>
                <th align="center">Length</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">263</td>
                <td align="left">Multi-Topology Identifier</td>
                <td align="center">variable</td>
                <td align="left">
                  <xref target="MT-ID" format="default"/></td>
              </tr>
              <tr>
                <td align="center">264</td>
                <td align="left">OSPF Route Type</c>

            <c>1</c>

            <c><xref target="OSPFRTETYPE"/></c>

            <c>265</c>

            <c>IP Type</td>
                <td align="center">1</td>
                <td align="left">
                  <xref target="OSPFRTETYPE" format="default"/></td>
              </tr>
              <tr>
                <td align="center">265</td>
                <td align="left">IP Reachability Information</c>

            <c>variable</c>

            <c><xref target="IPREACHINFO"/></c>
          </texttable> Information</td>
                <td align="center">variable</td>
                <td align="left">
                  <xref target="IPREACHINFO" format="default"/></td>
              </tr>
            </tbody>
          </table>
          <t>The Multi-Topology Identifier TLV MUST <bcp14>MUST</bcp14> be included in the Prefix
          Descriptor if the underlying IGP prefix object is associated with a
          non-default topology.</t>
          <section anchor="OSPFRTETYPE" title="OSPF numbered="true" toc="default">
            <name>OSPF Route Type"> Type</name>
            <t>The OSPF Route Type TLV is an optional TLV corresponding to
            Prefix NLRIs originated from OSPF. It is used to identify the OSPF
            route type of the prefix. An OSPF prefix MAY <bcp14>MAY</bcp14> be advertised in the
            OSPF domain with multiple route types. The Route Type TLV allows
            the discrimination of these advertisements. The OSPF Route Type
            TLV MUST <bcp14>MUST</bcp14> be included in the advertisement when the type is either
            being signaled explicitly in the underlying LSA or can be
            determined via another LSA for the same prefix when it is not
            signaled explicitly (e.g., in the case of OSPFv2 Extended Prefix
            Opaque LSA <xref target="RFC7684"/>). target="RFC7684" format="default"/>). The route type advertised in
            the OSPFv2 Extended Prefix TLV (section 2.1 of <xref
            target="RFC7684"/>) (<xref target="RFC7684" section="2.1" sectionFormat="of" format="default"/>) does not make a distinction between Type 1 and
            2 for AS external and NSSA Not-So-Stubby Area (NSSA) external routes. In this case, the
            route type to be used in the BGP-LS advertisement can be
            determined by checking the OSPFv2 External or NSSA External LSA
            for the prefix. A similar check for the base OSPFv2 LSAs can be
            done to determine the route type to be used when the route type
            value 0 is carried in the OSPFv2 Extended Prefix TLV.</t>
            <t>The format of the OSPF Route Type TLV is shown in the following
            figure.</t>
            <figure anchor="ROUTETYPETLV" title="OSPF anchor="ROUTETYPETLV">
              <name>OSPF Route Type TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Route Type   |
  +-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>

            <t>where the
            <t>The Type and Length fields of the TLV are defined in
            <xref target="table_prefix_descriptor_tlv"/>. target="table_prefix_descriptor_tlv" format="default"/>. The OSPF Route Type
            field follows the route types defined in the OSPF protocol and can
            be one of the following: <list style="symbols">
                <t>Intra-Area (0x1)</t>

                <t>Inter-Area (0x2)</t>

                <t>External 1 (0x3)</t>

                <t>External </t>
            <ul spacing="normal">
              <li>Intra-Area (0x1)</li>
              <li>Inter-Area (0x2)</li>
              <li>External 1 (0x3)</li>
              <li>External 2 (0x4)</t>

                <t>NSSA (0x4)</li>
              <li>NSSA 1 (0x5)</t>

                <t>NSSA (0x5)</li>
              <li>NSSA 2 (0x6)</t>
              </list></t> (0x6)</li>
            </ul>
          </section>
          <section anchor="IPREACHINFO" title="IP numbered="true" toc="default">
            <name>IP Reachability Information"> Information</name>
            <t>The IP Reachability Information TLV is a mandatory TLV for IPv4
            &amp; IPv6 Prefix NLRI types. The TLV contains one IP address
            prefix (IPv4 or IPv6) originally advertised in the IGP topology. A
            router SHOULD <bcp14>SHOULD</bcp14> advertise an IP Prefix NLRI for each of its BGP
            next-hops.
            next hops. The format of the IP Reachability Information TLV is
            shown in the following figure:</t>

            <t><figure anchor="IPREACHABILITYTLV"
                title="IP
            <figure anchor="IPREACHABILITYTLV">
              <name>IP Reachability Information TLV Format">
                <artwork><![CDATA[ Format</name>
              <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 | IP Prefix (variable)                         //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ]]></artwork>
              </figure></t>
            </figure>
            <t>The Type and Length fields of the TLV are defined in <xref
            target="table_prefix_descriptor_tlv"/>. target="table_prefix_descriptor_tlv" format="default"/>. The following two fields
            determine the reachability information of the address family. The
            Prefix Length field contains the length of the prefix in bits. The
            IP Prefix field contains an IP address prefix, prefix followed by the
            minimum number of trailing bits needed to make the end of the
            field fall on an octet boundary. Any trailing bits MUST <bcp14>MUST</bcp14> be set to
            0. Thus, the IP Prefix field contains the most significant octets
            of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 octets
            for prefix length 9 up to 16, 3 octets for prefix length 17 up to 24,
            4 octets for prefix length 25 up to 32, etc.</t>
          </section>
        </section>
      </section>
      <section anchor="BGPLSATTR" title="The numbered="true" toc="default">
        <name>The BGP-LS Attribute"> Attribute</name>
        <t>The BGP-LS Attribute (assigned value 29 by IANA) is an optional,
        non-transitive BGP attribute Attribute that is used to carry link, node, and
        prefix parameters and attributes. It is defined as a set of
        Type/Length/Value (TLV) triplets, as described in the following section.
        This attribute SHOULD <bcp14>SHOULD</bcp14> only be included with Link-State NLRIs. The use
        of this attribute for other address families is outside the scope of
        this document.</t>
        <t>The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute
        TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute
        associated with a Node NLRI, Link NLRI, and Prefix NLRI
        respectively.</t>
        <t>The size of the BGP-LS Attribute may potentially grow large large,
        depending on the amount of link-state information associated with a
        single Link-State NLRI. The BGP specification <xref target="RFC4271"/> target="RFC4271" format="default"/>
        mandates a maximum BGP message size of 4096 octets. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
        that an implementation supports <xref target="RFC8654"/> target="RFC8654" format="default"/> to
        accommodate a larger size of information within the BGP-LS Attribute.
        BGP-LS Producers MUST <bcp14>MUST</bcp14> ensure that the TLVs included in the BGP-LS
        Attribute does not result in a BGP UPDATE message for a single
        Link-State NLRI that crosses the maximum limit for a BGP message.</t>
        <t>An implementation MAY <bcp14>MAY</bcp14> adopt mechanisms to avoid this problem that
        may be based on the BGP-LS Consumer applications' requirement; these
        mechanisms are beyond the scope of this specification. However, if an
        implementation chooses to mitigate the problem by excluding some TLVs
        from the BGP-LS Attribute, this exclusion SHOULD <bcp14>SHOULD</bcp14> be done consistently
        by all BGP-LS Producers within a given BGP-LS domain. In the event of
        inconsistent exclusion of TLVs from the BGP-LS Attribute, the result
        would be a differing set of attributes of the link-state object being
        propagated to BGP-LS Consumers based on the BGP decision process Decision Process at
        BGP-LS Propagators.</t>
        <t>When a BGP-LS Propagator finds that it is exceeding the maximum BGP
        message size due to the addition or update of some other BGP Attribute
        (e.g.
        (e.g., AS_PATH), it MUST <bcp14>MUST</bcp14> consider the BGP-LS Attribute to be malformed,
        apply the "Attribute Discard" 'Attribute Discard' error-handling approach <xref
        target="RFC7606"/>, target="RFC7606" format="default"/>, and handle the propagation as described in <xref
        target="Fault-Management"/>. target="Fault-Management" format="default"/>. When a BGP-LS Propagator needs to perform
        "Attribute Discard"
        'Attribute Discard' for reducing the BGP UPDATE message size as
        specified in section 4 of <xref target="RFC8654"/>, target="RFC8654" section="4" sectionFormat="of" format="default"/>, it MUST <bcp14>MUST</bcp14> first
        discard the BGP-LS Attribute to enable the detection and diagnosis of
        this error condition as discussed in <xref
        target="Fault-Management"/>. target="Fault-Management" format="default"/>. This brings the deployment consideration
        that the consistent propagation of BGP-LS information with a BGP
        UPDATE message size larger than 4096 octets can only happen along a
        set of BGP Speakers that all support the contents of <xref target="RFC8654"/>.</t> target="RFC8654" format="default"/>.</t>
        <section anchor="NODEATTR" title="Node numbered="true" toc="default">
          <name>Node Attribute TLVs"> TLVs</name>
          <t>The following Node Attribute TLVs are defined for the BGP-LS
          Attribute associated with a Node NLRI:</t>

          <texttable
          <table anchor="node-attribute_tlv" title="Node align="center">
            <name>Node Attribute TLVs">
            <ttcol TLVs</name>
            <thead>
              <tr>
                <th align="center">TLV Code Point</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol align="right">Length</ttcol>

            <ttcol align="left">Reference (RFC/Section)</ttcol>

            <c>263</c>

            <c>Multi-Topology Identifier</c>

            <c>variable</c>

            <c><xref target="MT-ID"/></c>

            <c>1024</c>

            <c>Node Point</th>
                <th align="left">Description</th>
                <th align="right">Length</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">263</td>
                <td align="left">Multi-Topology Identifier</td>
                <td align="right">variable</td>
                <td align="left">
                  <xref target="MT-ID" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1024</td>
                <td align="left">Node Flag Bits</c>

            <c>1</c>

            <c><xref target="NODEFLAGBITS"/></c>

            <c>1025</c>

            <c>Opaque Bits</td>
                <td align="right">1</td>
                <td align="left">
                  <xref target="NODEFLAGBITS" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1025</td>
                <td align="left">Opaque Node Attribute</c>

            <c>variable</c>

            <c><xref target="OPAQUENODE"/></c>

            <c>1026</c>

            <c>Node Name</c>

            <c>variable</c>

            <c><xref target="NODENAME"/></c>

            <c>1027</c>

            <c>IS-IS Attribute</td>
                <td align="right">variable</td>
                <td align="left">
                  <xref target="OPAQUENODE" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1026</td>
                <td align="left">Node Name</td>
                <td align="right">variable</td>
                <td align="left">
                  <xref target="NODENAME" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1027</td>
                <td align="left">IS-IS Area Identifier</c>

            <c>variable</c>

            <c><xref target="ISISAREA"/></c>

            <c>1028</c>

            <c>IPv4 Identifier</td>
                <td align="right">variable</td>
                <td align="left">
                  <xref target="ISISAREA" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1028</td>
                <td align="left">IPv4 Router-ID of Local Node</c>

            <c>4</c>

            <c><xref target="RFC5305"/> / 4.3</c>

            <c>1029</c>

            <c>IPv6 Node</td>
                <td align="right">4</td>
                <td align="left"><xref target="RFC5305" sectionFormat="comma" section="4.3"/></td>
              </tr>
              <tr>
                <td align="center">1029</td>
                <td align="left">IPv6 Router-ID of Local Node</c>

            <c>16</c>

            <c><xref target="RFC6119"/> / 4.1</c>
          </texttable> Node</td>
                <td align="right">16</td>
                <td align="left"><xref target="RFC6119" sectionFormat="comma" section="4.1"/></td>
              </tr>
            </tbody>
          </table>
          <section anchor="NODEFLAGBITS" title="Node numbered="true" toc="default">
            <name>Node Flag Bits TLV"> TLV</name>
            <t>The Node Flag Bits TLV carries a bitmask describing node
            attributes. The value is a 1 octet length 1-octet-length bit array of flags,
            where each bit represents a node operational node-operational state or
            attribute.</t>
            <figure anchor="node_flag_bits" title="Node anchor="node_flag_bits">
              <name>Node Flag Bits TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |O|T|E|B|R|V|   |
  +-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>
            <t>The bits are defined as follows:</t>

            <texttable

            <table anchor="table_node_flag_bits_tlv"
                       title="Node align="center">
              <name>Node Flag Bits Definitions">
              <ttcol align="center">Bit</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="left">Reference</ttcol>

              <c>'O'</c>

              <c>Overload Bit</c>

              <c><xref target="ISO10589"/></c>

              <c>'T'</c>

              <c>Attached Bit</c>

              <c><xref target="ISO10589"/></c>

              <c>'E'</c>

              <c>External Bit</c>

              <c><xref target="RFC2328"/></c>

              <c>'B'</c>

              <c>ABR Bit</c>

              <c><xref target="RFC2328"/></c>

              <c>'R'</c>

              <c>Router Bit</c>

              <c><xref target="RFC5340"/></c>

              <c>'V'</c>

              <c>V6 Bit</c>

              <c><xref target="RFC5340"/></c>
            </texttable> Definitions</name>
              <thead>
                <tr>
                  <th align="center">Bit</th>
                  <th align="left">Description</th>
                  <th align="left">Reference</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">'O'</td>
                  <td align="left">Overload Bit</td>
                  <td align="left">
                    <xref target="ISO10589" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'A'</td>
                  <td align="left">Attached Bit</td>
                  <td align="left">
                    <xref target="ISO10589" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'E'</td>
                  <td align="left">External Bit</td>
                  <td align="left">
                    <xref target="RFC2328" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'B'</td>
                  <td align="left">ABR Bit</td>
                  <td align="left">
                    <xref target="RFC2328" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'R'</td>
                  <td align="left">Router Bit</td>
                  <td align="left">
                    <xref target="RFC5340" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'V'</td>
                  <td align="left">V6 Bit</td>
                  <td align="left">
                    <xref target="RFC5340" format="default"/></td>
                </tr>
              </tbody>
            </table>
            <t>The bits that are not defined MUST <bcp14>MUST</bcp14> be set to 0 by the
            originator and MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>
          </section>
          <section anchor="ISISAREA" title="IS-IS numbered="true" toc="default">
            <name>IS-IS Area Identifier TLV"> TLV</name>
            <t>An IS-IS node can be part of only a single IS-IS area. However,
            a node can have multiple synonymous area addresses. Each of these
            area addresses is carried in the IS-IS Area Identifier TLV. If
            multiple area addresses are present, multiple TLVs are used to
            encode them. The IS-IS Area Identifier TLV may be present in the
            BGP-LS Attribute only when advertised in the Link-State Node
            NLRI.</t>
            <figure anchor="ISISAREAIDTLV"
                    title="IS-IS anchor="ISISAREAIDTLV">
              <name>IS-IS Area Identifier TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //               IS-IS Area Identifier (variable)              //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
          </section>
          <section anchor="NODENAME" title="Node numbered="true" toc="default">
            <name>Node Name TLV"> TLV</name>
            <t>The Node Name TLV is optional. The encoding semantics for the
            node name has been borrowed from <xref target="RFC5301"/>. target="RFC5301" format="default"/>. The
            Value field identifies the symbolic name of the router node. This
            symbolic name can either be the Fully Qualified Domain Name (FQDN)
            for the router, or it can be a substring of the FQDN (e.g., a
            hostname), or it can be any string that an operator wants to use
            for the router. The use of the FQDN or a substring of it is strongly
            RECOMMENDED.
            <bcp14>RECOMMENDED</bcp14>. The maximum length of the Node Name TLV is 255
            octets.</t>
            <t>The Value field is encoded in 7-bit ASCII. If a user interface
            for configuring or displaying this field permits Unicode
            characters, that then the user interface is responsible for applying
            the ToASCII and/or ToUnicode algorithm as described in <xref
            target="RFC5890"/> target="RFC5890" format="default"/> to achieve the correct format for transmission
            or display.</t>
            <t><xref target="RFC5301"/> target="RFC5301" format="default"/> describes an IS-IS-specific extension extension,
            and <xref target="RFC5642"/> target="RFC5642" format="default"/> describes an OSPF extension for the
            advertisement of Node Name the node name, which may be encoded in the Node Name
            TLV.</t>
            <figure anchor="optional-node-name-tlv" title="Node anchor="optional-node-name-tlv">
              <name>Node Name Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                     Node Name (variable)                    //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>
          </section>
          <section anchor="aux_routerid_node"
                   title="Local numbered="true" toc="default">
            <name>Local IPv4/IPv6 Router-ID TLVs"> TLVs</name>
            <t>The local IPv4/IPv6 Router-ID TLVs are used to describe
            auxiliary Router-IDs that the IGP might be using, e.g., for TE and
            migration purposes such as correlating a Node-ID between different
            protocols. If there is more than one auxiliary Router-ID of a
            given type, then each one is encoded as a separate TLV.</t>
          </section>
          <section anchor="OPAQUENODE" title="Opaque numbered="true" toc="default">
            <name>Opaque Node Attribute TLV"> TLV</name>
            <t>The Opaque Node Attribute TLV is an envelope that transparently
            carries optional Node Attribute TLVs advertised by a router. An
            originating router shall use this TLV for encoding information
            specific to the protocol advertised in the NLRI header Protocol-ID
            field or new protocol extensions to the protocol as advertised in
            the NLRI header Protocol-ID field for which there is no
            protocol-neutral representation in the BGP Link-State NLRI. The
            primary use of the Opaque Node Attribute TLV is to bridge the
            document lag between a new IGP link-state attribute and its
            protocol-neutral BGP-LS extension being defined. Once the
            protocol-neutral BGP-LS extensions are defined, the BGP-LS
            implementations may still need to advertise the information both
            within the Opaque Attribute TLV and the new TLV definition for
            incremental deployment and transition.</t>
            <t>In the case of OSPF, this TLV MUST NOT <bcp14>MUST NOT</bcp14> be used to advertise
            TLVs other than those in the OSPF Router Information (RI) LSA
            <xref target="RFC7770"/>.</t> target="RFC7770" format="default"/>.</t>
            <figure anchor="optional_opaque_node-attribute_tlv"
                    title="Opaque anchor="optional_opaque_node-attribute_tlv">
              <name>Opaque Node Attribute Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //               Opaque node attributes Node Attributes (variable)             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ]]></artwork>
            </figure>
            <t>The type Type is as specified in <xref
            target="node-attribute_tlv"/>. Length target="node-attribute_tlv" format="default"/>. The length is variable.</t>
          </section>
        </section>
        <section anchor="link_attribute" title="Link numbered="true" toc="default">
          <name>Link Attribute TLVs"> TLVs</name>
          <t>Link Attribute TLVs are TLVs that may be encoded in the BGP-LS
          Attribute with a Link NLRI. Each 'Link Attribute' is a
          Type/Length/Value (TLV) triplet formatted as defined in <xref
          target="TLV-section"/>. target="TLV-section" format="default"/>. The format and semantics of the Value fields
          in some Link Attribute TLVs correspond to the format and semantics
          of the Value fields in IS-IS Extended IS Reachability sub-TLVs,
          which are defined in <xref target="RFC5305"/> target="RFC5305" format="default"/> and <xref target="RFC5307"/>. target="RFC5307" format="default"/>.
          Other Link Attribute TLVs are defined in this document. Although the
          encodings for Link Attribute TLVs were originally defined for IS-IS,
          the TLVs can carry data sourced by either IS-IS or OSPF.</t>
          <t>The following Link Attribute TLVs are defined for the BGP-LS
          Attribute associated with a Link NLRI:</t>

          <texttable
          <table anchor="table_link_attribute_tlv"
                     title="Link align="center">
            <name>Link Attribute TLVs">
            <ttcol TLVs</name>
            <thead>
              <tr>
                <th align="center">TLV Code Point</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol Point</th>
                <th align="left">Description</th>
                <th align="center">IS-IS TLV/Sub-TLV</ttcol>

            <ttcol align="left">Reference (RFC/Section)</ttcol>

            <c>1028</c>

            <c>IPv4 TLV/Sub-TLV</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">1028</td>
                <td align="left">IPv4 Router-ID of Local Node</c>

            <c>134/---</c>

            <c><xref target="RFC5305"/> / 4.3</c>

            <c>1029</c>

            <c>IPv6 Node</td>
                <td align="center">134/---</td>
                <td align="left">
                  <xref target="RFC5305" sectionFormat="comma" section="4.3"/></td>
              </tr>
              <tr>
                <td align="center">1029</td>
                <td align="left">IPv6 Router-ID of Local Node</c>

            <c>140/---</c>

            <c><xref target="RFC6119"/> / 4.1</c>

            <c>1030</c>

            <c>IPv4 Node</td>
                <td align="center">140/---</td>
                <td align="left">
                  <xref target="RFC6119" sectionFormat="comma" section="4.1"/></td>
              </tr>
              <tr>
                <td align="center">1030</td>
                <td align="left">IPv4 Router-ID of Remote Node</c>

            <c>134/---</c>

            <c><xref target="RFC5305"/> / 4.3</c>

            <c>1031</c>

            <c>IPv6 Node</td>
                <td align="center">134/---</td>
                <td align="left">
                  <xref target="RFC5305" sectionFormat="comma" section="4.3"/></td>
              </tr>
              <tr>
                <td align="center">1031</td>
                <td align="left">IPv6 Router-ID of Remote Node</c>

            <c>140/---</c>

            <c><xref target="RFC6119"/> / 4.1</c>

            <c>1088</c>

            <c>Administrative Node</td>
                <td align="center">140/---</td>
                <td align="left">
                  <xref target="RFC6119" sectionFormat="comma" section="4.1"/></td>
              </tr>
              <tr>
                <td align="center">1088</td>
                <td align="left">Administrative group (color)</c>

            <c>22/3</c>

            <c><xref target="RFC5305"/> / 3.1</c>

            <c>1089</c>

            <c>Maximum (color)</td>
                <td align="center">22/3</td>
                <td align="left">
                  <xref target="RFC5305" sectionFormat="comma" section="3.1"/></td>
              </tr>
              <tr>
                <td align="center">1089</td>
                <td align="left">Maximum link bandwidth</c>

            <c>22/9</c>

            <c><xref target="RFC5305"/> / 3.4</c>

            <c>1090</c>

            <c>Max. bandwidth</td>
                <td align="center">22/9</td>
                <td align="left">
                  <xref target="RFC5305" sectionFormat="comma" section="3.4"/></td>
              </tr>
              <tr>
                <td align="center">1090</td>
                <td align="left">Max. reservable link bandwidth</c>

            <c>22/10</c>

            <c><xref target="RFC5305"/> / 3.5</c>

            <c>1091</c>

            <c>Unreserved bandwidth</c>

            <c>22/11</c>

            <c><xref target="RFC5305"/> / 3.6</c>

            <c>1092</c>

            <c>TE bandwidth</td>
                <td align="center">22/10</td>
                <td align="left">
                  <xref target="RFC5305" sectionFormat="comma" section="3.5"/></td>
              </tr>
              <tr>
                <td align="center">1091</td>
                <td align="left">Unreserved bandwidth</td>
                <td align="center">22/11</td>
                <td align="left">
                  <xref target="RFC5305" sectionFormat="comma" section="3.6"/></td>
              </tr>
              <tr>
                <td align="center">1092</td>
                <td align="left">TE Default Metric</c>

            <c>22/18</c>

            <c><xref target="TEDEFAULTMETTLV"/></c>

            <c>1093</c>

            <c>Link Metric</td>
                <td align="center">22/18</td>
                <td align="left">
                  <xref target="TEDEFAULTMETTLV" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1093</td>
                <td align="left">Link Protection Type</c>

            <c>22/20</c>

            <c><xref target="RFC5307"/> / 1.2</c>

            <c>1094</c>

            <c>MPLS Type</td>
                <td align="center">22/20</td>
                <td align="left">
                  <xref target="RFC5307" sectionFormat="comma" section="1.2"/></td>
              </tr>
              <tr>
                <td align="center">1094</td>
                <td align="left">MPLS Protocol Mask</c>

            <c>---</c>

            <c><xref target="MPLSPROTOTLV"/></c>

            <c>1095</c>

            <c>IGP Metric</c>

            <c>---</c>

            <c><xref target="IGPMETTLV"/></c>

            <c>1096</c>

            <c>Shared Mask</td>
                <td align="center">---</td>
                <td align="left">
                  <xref target="MPLSPROTOTLV" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1095</td>
                <td align="left">IGP Metric</td>
                <td align="center">---</td>
                <td align="left">
                  <xref target="IGPMETTLV" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1096</td>
                <td align="left">Shared Risk Link Group</c>

            <c>---</c>

            <c><xref target="SRLGTLV"/></c>

            <c>1097</c>

            <c>Opaque Link Attribute</c>

            <c>---</c>

            <c><xref target="OPAQUELINK"/></c>

            <c>1098</c>

            <c>Link Name</c>

            <c>---</c>

            <c><xref target="LINKNAME"/></c>
          </texttable> Group</td>
                <td align="center">---</td>
                <td align="left">
                  <xref target="SRLGTLV" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1097</td>
                <td align="left">Opaque Link Attribute</td>
                <td align="center">---</td>
                <td align="left">
                  <xref target="OPAQUELINK" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1098</td>
                <td align="left">Link Name</td>
                <td align="center">---</td>
                <td align="left">
                  <xref target="LINKNAME" format="default"/></td>
              </tr>
            </tbody>
          </table>
          <section anchor="aux_routerid_link" title="IPv4/IPv6 numbered="true" toc="default">
            <name>IPv4/IPv6 Router-ID TLVs"> TLVs</name>
            <t>The local/remote IPv4/IPv6 Router-ID TLVs are used to describe
            auxiliary Router-IDs that the IGP might be using, e.g., for TE
            purposes. All auxiliary Router-IDs of both the local and the
            remote node MUST <bcp14>MUST</bcp14> be included in the link attribute of each Link
            NLRI. If there is more than one auxiliary Router-ID of a given
            type, then multiple TLVs are used to encode them.</t>
          </section>
          <section anchor="MPLSPROTOTLV" title="MPLS numbered="true" toc="default">
            <name>MPLS Protocol Mask TLV"> TLV</name>
            <t>The MPLS Protocol Mask TLV carries a bitmask describing which
            MPLS signaling protocols are enabled. The length of this TLV is 1.
            The value is a bit array of 8 flags, where each bit represents an
            MPLS Protocol capability.</t>
            <t>Generation of the MPLS Protocol Mask TLV is only valid for and
            SHOULD
            <bcp14>SHOULD</bcp14> only be used with originators that have local link insight,
            for example, the Protocol-IDs 'Static configuration' or 'Direct'
            as per <xref target="PROTOCOL-IDS"/>. target="PROTOCOL-IDS" format="default"/>. The MPLS Protocol Mask TLV
            MUST NOT
            <bcp14>MUST NOT</bcp14> be included in NLRIs with the other Protocol-IDs listed
            in <xref target="PROTOCOL-IDS"/>.</t> target="PROTOCOL-IDS" format="default"/>.</t>
            <figure anchor="MPLSPROTO" title="MPLS anchor="MPLSPROTO">
              <name>MPLS Protocol Mask TLV">
              <artwork><![CDATA[ TLV</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |L|R|  Reserved |
  +-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
            <t>The following bits are defined, and the reserved bits MUST <bcp14>MUST</bcp14> be
            set to zero and SHOULD <bcp14>SHOULD</bcp14> be ignored on receipt:</t>

            <texttable
            <table anchor="table_mpls_protocols_tlv"
                       title="MPLS align="center">
              <name>MPLS Protocol Mask TLV Codes">
              <ttcol align="center">Bit</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="left">Reference</ttcol>

              <c>'L'</c>

              <c>Label Codes</name>
              <thead>
                <tr>
                  <th align="center">Bit</th>
                  <th align="left">Description</th>
                  <th align="left">Reference</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">'L'</td>
                  <td align="left">Label Distribution Protocol (LDP)</c>

              <c><xref target="RFC5036"/></c>

              <c>'R'</c>

              <c>Extension (LDP)</td>
                  <td align="left">
                    <xref target="RFC5036" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'R'</td>
                  <td align="left">Extension to RSVP for LSP Tunnels (RSVP&nbhy;TE)</c>

              <c><xref target="RFC3209"/></c>
            </texttable> (RSVP-TE)</td>
                  <td align="left">
                    <xref target="RFC3209" format="default"/></td>
                </tr>
              </tbody>
            </table>
            <t>The bits that are not defined MUST <bcp14>MUST</bcp14> be set to 0 by the
            originator and MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>
          </section>
          <section anchor="TEDEFAULTMETTLV" title="TE numbered="true" toc="default">
            <name>TE Default Metric TLV"> TLV</name>
            <t>The TE Default Metric TLV carries the Traffic Engineering
            metric for this link. The length of this TLV is fixed at 4 octets.
            If a source protocol uses a metric width of fewer than 32 bits,
            then the high-order bits of this field MUST <bcp14>MUST</bcp14> be padded with
            zero.</t>
            <figure anchor="TEDEFAULTMET" title="TE anchor="TEDEFAULTMET">
              <name>TE Default Metric TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    TE Default Link Metric                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
          </section>
          <section anchor="IGPMETTLV" title="IGP numbered="true" toc="default">
            <name>IGP Metric TLV"> TLV</name>
            <t>The IGP Metric TLV carries the metric for this link. The length
            of this TLV is variable, depending on the metric width of the
            underlying protocol. IS-IS small metrics are of 6-bit size, 6 bits in size but
            are encoded in a 1 octet 1-octet field; therefore therefore, the two most significant
            bits of the field MUST <bcp14>MUST</bcp14> be set to 0 by the originator and MUST <bcp14>MUST</bcp14> be
            ignored by the receiver. OSPF link metrics have a length of 2
            octets. IS-IS wide metrics have a length of 3 octets.</t>
            <figure anchor="MET" title="IGP anchor="MET">
              <name>IGP Metric TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //      IGP Link Metric (variable length)      //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
          </section>
          <section anchor="SRLGTLV" title="Shared numbered="true" toc="default">
            <name>Shared Risk Link Group TLV"> TLV</name>
            <t>The Shared Risk Link Group (SRLG) TLV carries the Shared Risk
            Link Group information (see Section 2.3 ("Shared <xref target="RFC4202" section="2.3" sectionFormat="bare">"Shared Risk Link Group
            Information")
            Information"</xref> of <xref target="RFC4202"/>). target="RFC4202" format="default"/>). It contains a data
            structure consisting of a (variable) list of SRLG values, where
            each element in the list has 4 octets, as shown in <xref
            target="SRLG"/>. target="SRLG" format="default"/>. The length of this TLV is 4 * (number of SRLG
            values).</t>
            <figure anchor="SRLG" title="Shared anchor="SRLG">
              <name>Shared Risk Link Group TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Shared Risk Link Group Value                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                         ............                        //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Shared Risk Link Group Value                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>
            <t>The SRLG TLV for OSPF-TE is defined in <xref
            target="RFC4203"/>. target="RFC4203" format="default"/>. In IS-IS, the SRLG information is carried in
            two different TLVs: the IPv4 (SRLG) GMPLS-SRLG TLV (for IPv4) (Type 138) defined in
            <xref target="RFC5307"/> target="RFC5307" format="default"/> and the IPv6 SRLG TLV (Type 139) defined
            in <xref target="RFC6119"/>. target="RFC6119" format="default"/>. Both IPv4 and IPv6 SRLG information
            is carried in a single TLV.</t>
          </section>
          <section anchor="OPAQUELINK" title="Opaque numbered="true" toc="default">
            <name>Opaque Link Attribute TLV"> TLV</name>
            <t>The Opaque Link Attribute TLV is an envelope that transparently
            carries optional Link Attribute TLVs advertised by a router. An
            originating router shall use this TLV for encoding information
            specific to the protocol advertised in the NLRI header Protocol-ID
            field or new protocol extensions to the protocol as advertised in
            the NLRI header Protocol-ID field for which there is no
            protocol-neutral representation in the BGP Link-State NLRI. The
            primary use of the Opaque Link Attribute TLV is to bridge the
            document lag between a new IGP link-state attribute and its
            'protocol-neutral' BGP-LS extension being defined. Once the
            protocol-neutral BGP-LS extensions are defined, the BGP-LS
            implementations may still need to advertise the information both
            within the Opaque Attribute TLV and the new TLV definition for
            incremental deployment and transition.</t>
            <t>In the case of OSPFv2, this TLV MUST NOT <bcp14>MUST NOT</bcp14> be used to advertise
            information carried using TLVs other than those in the OSPFv2
            Extended Link Opaque LSA <xref target="RFC7684"/>. target="RFC7684" format="default"/>. In the case of
            OSPFv3, this TLV MUST NOT <bcp14>MUST NOT</bcp14> be used to advertise TLVs other than
            those in the OSPFv3 E-Router-LSA or E-Link-LSA <xref
            target="RFC8362"/>.</t> target="RFC8362" format="default"/>.</t>
            <figure anchor="OPAQUELINKTLV"
                    title="Opaque anchor="OPAQUELINKTLV">
              <name>Opaque Link Attribute TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                Opaque link attributes Link Attributes (variable)            //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
          </section>
          <section anchor="LINKNAME" title="Link numbered="true" toc="default">
            <name>Link Name TLV"> TLV</name>
            <t>The Link Name TLV is optional. The Value field identifies the
            symbolic name of the router link. This symbolic name can either be
            the FQDN for the link, or it can be a substring of the FQDN, or it
            can be
            any string that an operator wants to use for the link. The
            use of the FQDN or a substring of it is strongly RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. The
            maximum length of the Link Name TLV is 255 octets.</t>
            <t>The Value field is encoded in 7-bit ASCII. If a user interface
            for configuring or displaying this field permits Unicode
            characters, that then the user interface is responsible for applying
            the ToASCII and/or ToUnicode algorithm as described in <xref
            target="RFC5890"/> target="RFC5890" format="default"/> to achieve the correct format for transmission
            or display.</t>
            <t>How a router derives and injects link names is outside of the
            scope of this document.</t>
            <figure anchor="optional-link-name-tlv"
                    title="Link anchor="optional-link-name-tlv">
              <name>Link Name TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                     Link Name (variable)                    //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="PFXATTR" title="Prefix numbered="true" toc="default">
          <name>Prefix Attribute TLVs"> TLVs</name>
          <t>Prefixes are learned from the IGP topology (IS-IS or OSPF) with a
          set of IGP attributes (such as metric, route tags, etc.) that are
          advertised in the BGP-LS Attribute with Prefix NLRI types 3 and
          4.</t>
          <t>The following Prefix Attribute TLVs are defined for the BGP-LS
          Attribute associated with a Prefix NLRI:</t>

          <texttable
          <table anchor="prefix-attribute_tlv"
                     title="Prefix align="center">
            <name>Prefix Attribute TLVs">
            <ttcol TLVs</name>
            <thead>
              <tr>
                <th align="center">TLV Code Point</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol align="right">Length</ttcol>

            <ttcol align="left">Reference</ttcol>

            <c>1152</c>

            <c>IGP Flags</c>

            <c>1</c>

            <c><xref target="IGPFLAGS"/></c>

            <c>1153</c>

            <c>IGP Point</th>
                <th align="left">Description</th>
                <th align="right">Length</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">1152</td>
                <td align="left">IGP Flags</td>
                <td align="right">1</td>
                <td align="left">
                  <xref target="IGPFLAGS" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1153</td>
                <td align="left">IGP Route Tag</c>

            <c>4*n</c>

            <c><xref target="RFC5130"/></c>

            <c>1154</c>

            <c>IGP Tag</td>
                <td align="right">4*n</td>
                <td align="left">
                  <xref target="RFC5130" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1154</td>
                <td align="left">IGP Extended Route Tag</c>

            <c>8*n</c>

            <c><xref target="RFC5130"/></c>

            <c>1155</c>

            <c>Prefix Metric</c>

            <c>4</c>

            <c><xref target="RFC5305"/></c>

            <c>1156</c>

            <c>OSPF Tag</td>
                <td align="right">8*n</td>
                <td align="left">
                  <xref target="RFC5130" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1155</td>
                <td align="left">Prefix Metric</td>
                <td align="right">4</td>
                <td align="left">
                  <xref target="RFC5305" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1156</td>
                <td align="left">OSPF Forwarding Address</c>

            <c>4</c>

            <c><xref target="RFC2328"/></c>

            <c>1157</c>

            <c>Opaque Address</td>
                <td align="right">4</td>
                <td align="left">
                  <xref target="RFC2328" format="default"/></td>
              </tr>
              <tr>
                <td align="center">1157</td>
                <td align="left">Opaque Prefix Attribute</c>

            <c>variable</c>

            <c><xref target="OPAQUEPREFIX"/></c>
          </texttable> Attribute</td>
                <td align="right">variable</td>
                <td align="left">
                  <xref target="OPAQUEPREFIX" format="default"/></td>
              </tr>
            </tbody>
          </table>
          <section anchor="IGPFLAGS" title="IGP numbered="true" toc="default">
            <name>IGP Flags TLV"> TLV</name>
            <t>The IGP Flags TLV contains one octet of IS-IS and OSPF flags
            and bits originally assigned to the prefix. The IGP Flags TLV is
            encoded as follows:</t>
            <figure anchor="IGPFLAGSTLV" title="IGP anchor="IGPFLAGSTLV">
              <name>IGP Flag TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |D|N|L|P|       |
  +-+-+-+-+-+-+-+-+
  ]]></artwork>
            </figure>
            <t>The Value field contains bits defined according to the table
            below:</t>

            <texttable
            <table anchor="table_igp_flag_bits_tlv"
                       title="IGP align="center">
              <name>IGP Flag Bits Definitions">
              <ttcol align="center">Bit</ttcol>

              <ttcol align="left">Description</ttcol>

              <ttcol align="left">Reference</ttcol>

              <c>'D'</c>

              <c>IS-IS Definitions</name>
              <thead>
                <tr>
                  <th align="center">Bit</th>
                  <th align="left">Description</th>
                  <th align="left">Reference</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">'D'</td>
                  <td align="left">IS-IS Up/Down Bit</c>

              <c><xref target="RFC5305"/></c>

              <c>'N'</c>

              <c>OSPF Bit</td>
                  <td align="left">
                    <xref target="RFC5305" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'N'</td>
                  <td align="left">OSPF "no unicast" Bit</c>

              <c><xref target="RFC5340"/></c>

              <c>'L'</c>

              <c>OSPF Bit</td>
                  <td align="left">
                    <xref target="RFC5340" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'L'</td>
                  <td align="left">OSPF "local address" Bit</c>

              <c><xref target="RFC5340"/></c>

              <c>'P'</c>

              <c>OSPF Bit</td>
                  <td align="left">
                    <xref target="RFC5340" format="default"/></td>
                </tr>
                <tr>
                  <td align="center">'P'</td>
                  <td align="left">OSPF "propagate NSSA" Bit</c>

              <c><xref target="RFC5340"/></c>
            </texttable> Bit</td>
                  <td align="left">
                    <xref target="RFC5340" format="default"/></td>
                </tr>
              </tbody>
            </table>
            <t>The bits that are not defined MUST <bcp14>MUST</bcp14> be set to 0 by the
            originator and MUST <bcp14>MUST</bcp14> be ignored by the receiver.</t>
          </section>
          <section anchor="route_tag" title="IGP numbered="true" toc="default">
            <name>IGP Route Tag TLV"> TLV</name>
            <t>The IGP Route Tag TLV carries original IGP Tags (IS-IS <xref
            target="RFC5130"/> target="RFC5130" format="default"/> or OSPF) of the prefix and is encoded as
            follows:</t>
            <figure anchor="IGPROUTETAG" title="IGP anchor="IGPROUTETAG">
              <name>IGP Route Tag TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                    Route Tags (one or more)                 //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>

            <t>Length
            <t>The length is a multiple of 4.</t>
            <t>The Value field contains one or more Route Tags as learned in
            the IGP topology.</t>
          </section>
          <section anchor="ext_route_tag" title="Extended IGP numbered="true" toc="default">
            <name>IGP Extended Route Tag TLV"> TLV</name>
            <t>The Extended IGP Extended Route Tag TLV carries IS-IS Extended Route
            Tags of the prefix <xref target="RFC5130"/> target="RFC5130" format="default"/> and is encoded as
            follows:</t>
            <figure anchor="IGPEXTROUTETAG"
                    title="Extended IGP anchor="IGPEXTROUTETAG">
              <name>IGP Extended Route Tag TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                Extended Route Tag (one or more)             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]></artwork>
            </figure>

            <t>Length
            <t>The length is a multiple of 8.</t>
            <t>The Extended Route Tag field contains one or more Extended
            Route Tags as learned in the IGP topology.</t>
          </section>
          <section anchor="prefix_metric" title="Prefix numbered="true" toc="default">
            <name>Prefix Metric TLV"> TLV</name>
            <t>The Prefix Metric TLV is an optional attribute and may only
            appear once. If present, it carries the metric of the prefix as
            known in the IGP topology topology, as described in Section 4 of <xref
            target="RFC5305"/> target="RFC5305" section="4" sectionFormat="of" format="default"/> (and therefore represents the reachability cost
            to the prefix). If not present, it means that the prefix is
            advertised without any reachability.</t>

            <t><figure anchor="PREFIXMETRIC" title="Prefix
            <figure anchor="PREFIXMETRIC">
              <name>Prefix Metric TLV Format">
                <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Metric                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                ]]></artwork>
              </figure></t>

            <t>Length
            </figure>
            <t>The length is 4.</t>
          </section>
          <section anchor="ospf_fwd_addr" title="OSPF numbered="true" toc="default">
            <name>OSPF Forwarding Address TLV"> TLV</name>
            <t>The OSPF Forwarding Address TLV <xref target="RFC2328"/> target="RFC2328" format="default"/> <xref
            target="RFC5340"/> target="RFC5340" format="default"/> carries the OSPF forwarding address as known in
            the original OSPF advertisement. The forwarding address can be
            either IPv4 or IPv6.</t>
            <figure anchor="OSPFFORWADDR"
                    title="OSPF anchor="OSPFFORWADDR">
              <name>OSPF Forwarding Address TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                Forwarding Address (variable)                //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>

            <t>Length
            <t>The length is 4 for an IPv4 forwarding address, address and 16 for an IPv6
            forwarding address.</t>
          </section>
          <section anchor="OPAQUEPREFIX" title="Opaque numbered="true" toc="default">
            <name>Opaque Prefix Attribute TLV"> TLV</name>
            <t>The Opaque Prefix Attribute TLV is an envelope that
            transparently carries optional Prefix Attribute TLVs advertised by
            a router.
            An originating router shall use this TLV for encoding information
	    specific to the protocol advertised in the NLRI header Protocol-ID
	    field or it shall use new protocol extensions to for the protocol as
	    advertised in the NLRI header Protocol-ID field for which there is no
	    protocol-neutral representation in the BGP Link-State NLRI. The
            primary use of the Opaque Prefix Attribute TLV is to bridge the
            document lag between a new IGP link-state attribute and its
            protocol-neutral BGP-LS extension being defined. Once the
            protocol-neutral BGP-LS extensions are defined, the BGP-LS
            implementations may still need to advertise the information both
            within the Opaque Attribute TLV and the new TLV definition for
            incremental deployment and transition.</t>
            <t>In the case of OSPFv2, this TLV MUST NOT <bcp14>MUST NOT</bcp14> be used to advertise
            information carried using TLVs other than those in the OSPFv2
            Extended Prefix Opaque LSA <xref target="RFC7684"/>. target="RFC7684" format="default"/>.
	    In the case
            of OSPFv3, this TLV MUST NOT <bcp14>MUST NOT</bcp14> be used to advertise TLVs other than
            those in the OSPFv3 E-Inter-Area-Prefix-LSA,
            E-Intra-Area-Prefix-LSA, E-AS-External-Prefix-LSA, E-AS-External-LSA, and E-NSSA-LSA
            <xref target="RFC8362"/>.</t> target="RFC8362" format="default"/>.</t>
            <t>The format of the TLV is as follows:</t>
            <figure anchor="OPAQUEPREFIXTLV"
                    title="Opaque anchor="OPAQUEPREFIXTLV">
              <name>Opaque Prefix Attribute TLV Format">
              <artwork><![CDATA[ Format</name>
              <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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //              Opaque Prefix Attributes  (variable)           //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              ]]></artwork>
            </figure>
            <t>The type Type is as specified in <xref
            target="prefix-attribute_tlv"/>. Length target="prefix-attribute_tlv" format="default"/>. The length is variable.</t>
          </section>
        </section>
      </section>
      <section anchor="PRIVATE" title="Private Use"> numbered="true" toc="default">
        <name>Private Use</name>
        <t>TLVs for Vendor Private use Use are supported using the code point
        range reserved as indicated in <xref target="IANA"/>. target="IANA" format="default"/>. For such TLV use
        in the NLRI or BGP-LS Attribute, the format as described in <xref
        target="TLV-section"/> target="TLV-section" format="default"/> is to be used and a 4-octet field MUST <bcp14>MUST</bcp14> be
        included as the first field in the value to carry the Enterprise Code.
        For a private use NLRI Type, type, a 4 octet 4-octet field MUST <bcp14>MUST</bcp14> be included as the
        first field in the NLRI immediately following the Total NLRI Length
        field of the Link-State NLRI format as described in <xref
        target="BGPLSNLRI"/> target="BGPLSNLRI" format="default"/> to carry the Enterprise Code <xref
        target="ENTNUM"/>. target="ENTNUM" format="default"/>. This enables the use of vendor-specific extensions
        without conflicts.</t>
        <t>Multiple instances of private-use TLVs MAY <bcp14>MAY</bcp14> appear in the BGP-LS
        Attribute.</t>
      </section>
      <section anchor="BGPNH" title="BGP numbered="true" toc="default">
        <name>BGP Next-Hop Information"> Information</name>
        <t>BGP link-state information for both IPv4 and IPv6 networks can be
        carried over either an IPv4 BGP session or an IPv6 BGP session. If an
        IPv4 BGP session is used, then the next-hop next hop in the MP_REACH_NLRI
        SHOULD
        <bcp14>SHOULD</bcp14> be an IPv4 address. Similarly, if an IPv6 BGP session is used,
        then the next-hop next hop in the MP_REACH_NLRI SHOULD <bcp14>SHOULD</bcp14> be an IPv6 address.
        Usually, the next-hop next hop will be set to the local endpoint address of the
        BGP session. The next-hop address MUST <bcp14>MUST</bcp14> be encoded as described in
        <xref target="RFC4760"/>. target="RFC4760" format="default"/>. The Length field of the next-hop address
        will specify the next-hop address family. If the next-hop length is 4,
        then the next-hop next hop is an IPv4 address; if the next-hop length is 16,
        then it is a global IPv6 address; and if the next-hop length is 32,
        then there is one global IPv6 address followed by a link-local an IPv6 link-local
        address. The link-local IPv6 link-local address should be used as described in
        <xref target="RFC2545"/>. target="RFC2545" format="default"/>. For VPN Subsequent Address Family Identifier
        (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero
        is prepended to the next-hop.</t> next hop.</t>
        <t>The BGP Next-Hop is used by each BGP-LS speaker Speaker to validate the
        NLRI it receives. In case identical NLRIs are sourced by multiple
        BGP-LS Producers, the BGP Next-Hop is used to tiebreak as per the
        standard BGP path decision process. This specification doesn't mandate
        any rule regarding the rewrite of the BGP Next-Hop.</t>
      </section>
      <section anchor="INTERAS" title="Inter-AS Links"> numbered="true" toc="default">
        <name>Inter-AS Links</name>
        <t>The main source of TE information is the IGP, which is not active
        on inter-AS links. In some cases, the IGP may have information of
        inter-AS links <xref target="RFC5392"/> target="RFC5392" format="default"/> <xref target="RFC9346"/>. target="RFC9346" format="default"/>. In
        other cases, an implementation SHOULD <bcp14>SHOULD</bcp14> provide a means to inject
        inter-AS links into BGP-LS. The exact mechanism used to advertise the
        inter-AS links is outside the scope of this document.</t>
      </section>
      <section anchor="OSPFVL" title="OSPF numbered="true" toc="default">
        <name>OSPF Virtual Links and Sham Links"> Links</name>
        <t>In an OSPF <xref target="RFC2328"/> target="RFC2328" format="default"/> <xref target="RFC5340"/> target="RFC5340" format="default"/>
        network, OSPF virtual links serve to connect physically separate
        components of the backbone to establish/maintain continuity of the
        backbone area. While OSPF virtual links are modeled as point-to-point point-to-point,
        unnumbered links in the OSPF topology, their characteristics and
        purpose are different from other types of links in the OSPF topology.
        They are advertised using a distinct "virtual link" type in OSPF LSAs.
        The mechanism for the advertisement of OSPF virtual links via BGP-LS
        is outside the scope of this document.</t>
        <t>In an OSPF network, sham links <xref target="RFC4577"/> target="RFC4577" format="default"/> <xref
        target="RFC6565"/> target="RFC6565" format="default"/> are used to provide intra-area connectivity between
        VPN Routing and Forwarding (VRF) instances on PE Provider Edge (PE) routers over the VPN
        provider's network. These links are advertised in OSPF as
        point-to-point
        point-to-point, unnumbered links and represent connectivity over a
        service provider network using encapsulation mechanisms like MPLS. As
        such, the mechanism for the advertisement of OSPF sham links follows
        the same procedures as other point-to-point point-to-point, unnumbered links as
        described previously in this document.</t>
      </section>
      <section anchor="OSPFTYPE4"
               title="OSPFv2 numbered="true" toc="default">
        <name>OSPFv2 Type 4 Summary LSA Summary-LSA &amp; OSPFv3 Inter-Area Router LSA"> Inter-Area-Router-LSA</name>
        <t>OSPFv2 <xref target="RFC2328"/> target="RFC2328" format="default"/> defines the Type type 4 Summary LSA summary-LSA and
        OSPFv3 <xref target="RFC5340"/> target="RFC5340" format="default"/> defines the Inter-area-router-LSA inter-area-router-LSA for an Area
        Border Router (ABR) to advertise reachability to an AS Border Router
        (ASBR) that is external to the area yet internal to the AS. The nature
        of information advertised by OSPF using this type of LSA does not map
        to either a node or node, a link link, or a prefix as discussed in this document.
        Therefore, the mechanism for the advertisement of the information
        carried by these LSAs is outside the scope of this document.</t>
      </section>
      <section anchor="UNREACHNODES" title="Handling numbered="true" toc="default">
        <name>Handling of Unreachable IGP Nodes"> Nodes</name>
        <t>Consider an OSPF network as shown in <xref
        target="INCORRECTTOPORR"/>, target="INCORRECTTOPORR" format="default"/>, where R2 and R3 are the BGP-LS Producers
        and also the OSPF Area Border Routers (ABRs). The link between R2 and
        R3 is in area 0 0, while the other links are in area 1 as indicated by
        the a0 and a1 references respectively against the links.</t>
        <t>A BGP-LS Consumer talks to a BGP route reflector RR0 RR0, which is a
        BGP-LS Propagator that is aggregating the BGP-LS feed from the BGP-LS
        Producers R2 and R3. Here Here, R2 and R3 provide a redundant topology feed
        via BGP-LS to RR0. Normally, RR0 would receive two identical copies of
        all the Link-State NLRIs from both R2 and R3 and it would pick one of
        them (say R2) based on the standard BGP Decision Process.</t>

        <t><figure anchor="INCORRECTTOPORR"
            title="Incorrect
        <figure anchor="INCORRECTTOPORR">
          <name>Incorrect Reporting due Due to BGP Path Selection">
            <artwork><![CDATA[ Selection</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                  BGP-LS Consumer
                         ^
                         |
                        RR0
                 (BGP Route Reflector)
                      /      \
                     /        \
              a1    /   a0     \    a1
         R1 ------ R2 -------- R3 ------ R4
     a1  |                               |  a1
         |                               |
         R5 ---------------------------- R6
                        a1

]]></artwork>
          </figure>Consider
        </figure>
        <t>Consider a scenario where the link between R5 and R6 is
        lost (thereby partitioning the area 1) 1), and consider its impact on the OSPF LSDB
        at R2 and R3.</t>
        <t>Now, R5 will remove the link R5-R6 from its Router LSA, and this
        updated LSA is available at R2. R2 also has a stale copy of R6's
        Router LSA that still has the link R6-R5 in it. Based on this view in
        its LSDB, R2 will advertise only the half-link R6-R5 that it derives
        from R6's stale Router LSA.</t>
        <t>At the same time, R6 has removed the link R6-R5 from its Router
        LSA, and this updated LSA is available at R3. Similarly, R3 also has a
        stale copy of R5's Router LSA having the link R5-R6 in it. Based on
        its LSDB, R3 will advertise only the half-link R5-R6 that it has
        derived
        derives from R5's stale Router LSA.</t>
        <t>Now, the BGP-LS Consumer receives both the Link NLRIs corresponding
        to the half-links from R2 and R3 via RR0. When viewed together, it
        would not detect or realize that area 1 is partitioned. Also, if R2
        continues to report Node and Prefix NLRIs corresponding to the stale
        copy of R4 R4's and R6's Router LSAs LSAs, then RR0 could prefer them over the
        valid Node and Prefix NLRIs for R4 and R6 that it is receiving from R3
        depending on RR0's BGP decision process. Decision Process. This would result in the
        BGP-LS Consumer getting stale and inaccurate topology information.
        This problem scenario is avoided if R2 were to not advertise the
        link-state information corresponding to R4 and R6 and if R3 were to
        not advertise similarly for R1 and R5.</t>
        <t>A BGP-LS Producer SHOULD <bcp14>SHOULD</bcp14> withdraw all link-state objects advertised
        by it in BGP when the node that originated its corresponding LSP/LSAs LSPs/LSAs
        is determined to have become unreachable in the IGP. An implementation
        MAY
        <bcp14>MAY</bcp14> continue to advertise link-state objects corresponding to
        unreachable nodes in a deployment use-case use case where the BGP-LS Consumer
        is interested in receiving a topology feed corresponding to a complete
        IGP LSDB view. In such deployments, it is expected that the problem
        described above is mitigated by the BGP-LS Consumer via appropriate
        handling of such a topology feed in addition to the use of either a
        direct BGP peering with the BGP-LS Producer nodes or mechanisms such
        as those described in <xref target="RFC7911"/> target="RFC7911" format="default"/> when using RRs. Details of these
        mechanisms are outside the scope of this document.</t>
        <t>If the BGP-LS Producer does withdraw link-state objects associated
        with an IGP node based on the failure of reachability check for that
        node, then it MUST <bcp14>MUST</bcp14> re-advertise those link-state objects after that
        node becomes reachable again in the IGP domain.</t>
      </section>
      <section anchor="ISISPN"
               title="Router-ID numbered="true" toc="default">
        <name>Router-ID Anchoring Example: ISO Pseudonode"> Pseudonode</name>
        <t>The encoding of a broadcast LAN in IS-IS provides a good example of
        how Router-IDs are encoded. Consider <xref target="ISISPseudonodes"/>. target="ISISPseudonodes" format="default"/>.
        This represents a Broadcast broadcast LAN between a pair of routers. The "real"
        (non-pseudonode) routers have both an IPv4 Router-ID and an IS-IS
        Node-ID. The pseudonode does not have an IPv4 Router-ID. Node1 is the
        DIS for the LAN. Two unidirectional links links, (Node1, Pseudonode1) and
        (Pseudonode1, Node2) Node2), are being generated.</t>
        <t>The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The
        IGP Router-ID TLV of the local Node Descriptor is 6 octets long and
        contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV of
        the remote Node Descriptor is 7 octets long and contains the ISO-ID of
        Pseudonode1, 1920.0000.2001.02. The BGP-LS Attribute of this link
        contains one local IPv4 Router-ID TLV (TLV type 1028) containing
        192.0.2.1, the IPv4 Router-ID of Node1.</t>
        <t>The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The
        IGP Router-ID TLV of the local Node Descriptor is 7 octets long and
        contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP
        Router-ID TLV of the remote Node Descriptor is 6 octets long and
        contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS Attribute of
        this link contains one remote IPv4 Router-ID TLV (TLV type 1030)
        containing 192.0.2.2, the IPv4 Router-ID of Node2.</t>
        <figure anchor="ISISPseudonodes" title="IS-IS Pseudonodes">
          <artwork><![CDATA[ anchor="ISISPseudonodes">
          <name>IS-IS Pseudonodes</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  +-----------------+    +-----------------+    +-----------------+
  |      Node1      |    |   Pseudonode1   |    |      Node2      |
  |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
  |     192.0.2.1   |    |                 |    |     192.0.2.2   |
  +-----------------+    +-----------------+    +-----------------+
          ]]></artwork>
        </figure>
      </section>
      <section anchor="OSPFPN"
               title="Router-ID numbered="true" toc="default">
        <name>Router-ID Anchoring Example: OSPF Pseudonode"> Pseudonode</name>
        <t>The encoding of a broadcast LAN in OSPF provides a good example of
        how Router-IDs and local Interface IPs are encoded. Consider <xref
        target="OSPFPseudonodes"/>. target="OSPFPseudonodes" format="default"/>. This represents a Broadcast broadcast LAN between a
        pair of routers. The "real" (non-pseudonode) routers have both an IPv4
        Router-ID and an Area Identifier. The pseudonode does have an IPv4
        Router-ID, an IPv4 Interface Address (for disambiguation), and an OSPF
        Area. Node1 is the DR for the LAN; hence, its local IP address
        198.51.100.1 is used as both the Router-ID and Interface IP for the
        pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and
        (Pseudonode1, Node2), are being generated.</t>
        <t>The Link NLRI of (Node1, Pseudonode1) is encoded as follows: <list
            style="symbols"> </t>
        <ul spacing="normal">
          <li>
            <t>Local Node Descriptor <list style="hanging">
                <t>TLV #515: IGP </t>
            <dl newline="false" spacing="normal">
              <dt>TLV #515:</dt>
              <dd>IGP Router-ID: 192.0.2.1</t>

                <t>TLV #514: OSPF 192.0.2.1</dd>
              <dt>TLV #514:</dt>
              <dd>OSPF Area-ID: ID:0.0.0.0</t>
              </list></t> ID:0.0.0.0</dd>
            </dl>
          </li>
          <li>
            <t>Remote Node Descriptor <list style="hanging">
                <t>TLV #515: IGP </t>
            <dl newline="false" spacing="normal">
              <dt>TLV #515:</dt>
              <dd>IGP Router-ID: 192.0.2.1:198.51.100.1</t>

                <t>TLV #514: OSPF 192.0.2.1:198.51.100.1</dd>
              <dt>TLV #514:</dt>
              <dd>OSPF Area-ID: ID:0.0.0.0</t>
              </list></t>
          </list></t> ID:0.0.0.0</dd>
            </dl>
          </li>
        </ul>
        <t>The Link NLRI of (Pseudonode1, Node2) is encoded as follows: <list
            style="symbols"> </t>
        <ul spacing="normal">
          <li>
            <t>Local Node Descriptor <list style="hanging">
                <t>TLV #515: IGP </t>
            <dl newline="false" spacing="normal">
              <dt>TLV #515:</dt>
              <dd>IGP Router-ID: 192.0.2.1:198.51.100.1</t>

                <t>TLV #514: OSPF 192.0.2.1:198.51.100.1</dd>
              <dt>TLV #514:</dt>
              <dd>OSPF Area-ID: ID:0.0.0.0</t>
              </list></t> ID:0.0.0.0</dd>
            </dl>
          </li>
          <li>
            <t>Remote Node Descriptor <list style="hanging">
                <t>TLV #515: IGP </t>
            <dl newline="false" spacing="normal">
              <dt>TLV #515:</dt>
              <dd>IGP Router-ID: 192.0.2.2</t>

                <t>TLV #514: OSPF 192.0.2.2</dd>
              <dt>TLV #514:</dt>
              <dd>OSPF Area-ID: ID:0.0.0.0</t>
              </list></t>
          </list></t> ID:0.0.0.0</dd>
            </dl>
          </li>
        </ul>
        <figure anchor="OSPFPseudonodes" title="OSPF Pseudonodes">
          <artwork><![CDATA[ anchor="OSPFPseudonodes">
          <name>OSPF Pseudonodes</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     198.51.100.1/24             198.51.100.2/24
+-------------+    +-------------+    +-------------+
|   Node1     |    | Pseudonode1 |    |    Node2    |
|  192.0.2.1  |--->|  192.0.2.1  |--->|  192.0.2.2  |
|             |    |198.51.100.1 |    |             |
|   Area 0    |    |   Area 0    |    |    Area 0   |
+-------------+    +-------------+    +-------------+
          ]]></artwork>
        </figure>

        <t/>
        <t>The LAN subnet 198.51.100.0/24 is not included in the Router LSA of
        Node1 or Node2. The Network LSA for this LAN advertised by the DR
        Node1 contains the subnet mask for the LAN along with the DR address.
        A Prefix NLRI corresponding to the LAN subnet is advertised with the
        Pseudonode1 used as the Local local node using the DR address and the subnet
        mask from the Network LSA.</t>
      </section>
      <section anchor="OSPF2ISIS"
               title="Router-ID numbered="true" toc="default">
        <name>Router-ID Anchoring Example: OSPFv2 to IS-IS Migration"> Migration</name>
        <t>Graceful migration from one IGP to another requires coordinated
        operation of both protocols during the migration period. Such
        coordination requires identifying a given physical link in both IGPs.
        The IPv4 Router-ID provides that "glue", which is present in the Node
        Descriptors of the OSPF Link NLRI and in the link attribute of the
        IS-IS Link NLRI.</t>
        <t>Consider a point-to-point link between two routers, A and B, that which
	initially were OSPFv2-only routers and then had IS-IS is enabled on them.
        Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6
        Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the
        link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link NLRI
        for the link is encoded with the IPv4 Router-ID of nodes A and B in
        the local and remote Node Descriptors, respectively. The IS-IS Link
        NLRI for the link is encoded with the ISO-ID of nodes A and B in the
        local and remote Node Descriptors, respectively. In addition, the
        BGP-LS Attribute of the IS-IS Link NLRI contains the TLV type 1028
        containing the IPv4 Router-ID of node A, TLV type 1030 containing the
        IPv4 Router-ID of node B, and TLV type 1031 containing the IPv6
        Router-ID of node B. In this case, by using IPv4 Router-ID, the link
        (A, B) can be identified in both the IS-IS and OSPF protocols.</t>
      </section>
    </section>
    <section anchor="LINKPATHAGGREGATION" title="Link numbered="true" toc="default">
      <name>Link to Path Aggregation"> Aggregation</name>
      <t>Distribution of all links available on the global Internet is
      certainly possible; however, it is not desirable from a scaling and
      privacy point of view. Therefore, an implementation may support a link
      to path aggregation. Rather than advertising all specific links of a
      domain, an ASBR may advertise an "aggregate link" between a non-adjacent
      pair of nodes. The "aggregate link" represents the aggregated set of
      link properties between a pair of non-adjacent nodes. The actual methods
      to compute the path properties (of bandwidth, metric, etc.) are outside
      the scope of this document. The decision of whether to advertise all
      specific links or aggregated links is an operator's policy choice. To
      highlight the varying levels of exposure, the following deployment
      examples are discussed.</t>
      <section title="Example: numbered="true" toc="default">
        <name>Example: No Link Aggregation"> Aggregation</name>
        <t>Consider <xref target="no-link-aggregation"/>. target="no-link-aggregation" format="default"/>. Both AS1 and AS2
        operators want to protect their inter-AS {R1, R3}, {R2, R4} links
        using RSVP-FRR RSVP - Fast Reroute (RSVP-FRR) LSPs. If R1 wants to compute its link-protection LSP to
        R3, it needs to "see" an alternate path to R3. Therefore, the AS2
        operator exposes its topology. All BGP-TE-enabled routers in AS1 "see"
        the full topology of AS2 and therefore can compute a backup path. Note
        that the computing router decides if the direct link between {R3, R4}
        or the {R4, R5, R3} path is used. </t>
        <figure anchor="no-link-aggregation"
            title="No anchor="no-link-aggregation">
          <name>No Link Aggregation">
            <artwork><![CDATA[ Aggregation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       AS1   :   AS2
             :
        R1-------R3
         |   :   | \
         |   :   |  R5
         |   :   | /
        R2-------R4
             :
             :
      ]]></artwork>
          </figure></t>
        </figure>
      </section>
      <section title="Example: numbered="true" toc="default">
        <name>Example: ASBR to ASBR Path Aggregation"> Aggregation</name>
        <t>The brief difference between the "no-link aggregation" example and
        this example is that no specific link gets exposed. Consider <xref
        target="asbr-link-aggregation"/>. target="asbr-link-aggregation" format="default"/>. The only link that gets advertised
        by AS2 is an "aggregate" link between R3 and R4. This is enough to
        tell AS1 that there is a backup path. However, the actual links being
        used are hidden from the topology.</t>
        <figure anchor="asbr-link-aggregation" title="ASBR anchor="asbr-link-aggregation">
          <name>ASBR Link Aggregation">
          <artwork><![CDATA[ Aggregation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       AS1   :   AS2
             :
        R1-------R3
         |   :   |
         |   :   |
         |   :   |
        R2-------R4
             :
             :
      ]]></artwork>
        </figure>
      </section>
      <section title="Example: numbered="true" toc="default">
        <name>Example: Multi-AS Path Aggregation"> Aggregation</name>
        <t>Service providers in control of multiple ASes may even decide to
        not expose their internal inter-AS links. Consider <xref
        target="multi-as-aggregation"/>. target="multi-as-aggregation" format="default"/>. AS3 is modeled as a single node that
        connects to the border routers of the aggregated domain. </t>
        <figure
            anchor="multi-as-aggregation" title="Multi-AS Aggregation">
            <artwork><![CDATA[ anchor="multi-as-aggregation">
          <name>Multi-AS Aggregation</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       AS1   :   AS2   :   AS3
             :         :
        R1-------R3-----
         |   :         : \
         |   :         :   vR0
         |   :         : /
        R2-------R4-----
             :         :
             :         :
          ]]></artwork>
          </figure></t>
        </figure>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>As this document obsoletes <xref target="RFC7752"/> target="RFC7752" format="default"/> and <xref
      target="RFC9029"/>, target="RFC9029" format="default"/>, IANA is requested to change has updated all registration
      information that references those documents to instead reference this
      document.</t>
      <t>IANA has assigned address family number 16388 (BGP-LS) in the
      "Address Family Numbers" registry.</t>
      <t>IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the
      "SAFI Values" registry under the "Subsequent Address Family Identifiers
      (SAFI) Parameters" registry group.</t>
      <t>IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path
      Attributes" registry under the "Border Gateway Protocol (BGP)
      Parameters" registry group.</t>
      <t>IANA has created a "Border Gateway Protocol - Link-State (BGP-LS)
      Parameters" registry group at
      &lt;https://www.iana.org/assignments/bgp-ls-parameters&gt;.</t>
      <eref target="https://www.iana.org/assignments/bgp-ls-parameters" brackets="angle"/>.</t>
      <t>This section also incorporates all the changes to the allocation
      procedures for the BGP-LS IANA registry group as well as the guidelines
      for designated experts introduced by <xref target="RFC9029"/>.</t> target="RFC9029" format="default"/>.</t>
      <section anchor="Registries" title="BGP-LS Registries"> numbered="true" toc="default">
        <name>BGP-LS Registries</name>
        <t>All of the registries listed in the following subsections are
        BGP-LS
        specific to BGP-LS and are accessible under this registry.</t>
        <section anchor="NLRITYPESREG" title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS NLRI Types Registry"> Registry</name>
          <t>The "BGP-LS NLRI Types" registry has been set up for assignment
          for the two-octet sized code-points two-octet-sized code points for BGP-LS NLRI types and
          populated with the values shown below:</t>

          <texttable
          <table anchor="nlri_types_table" title="BGP-LS align="center">
            <name>BGP-LS NLRI Types">
            <ttcol align="center">Type</ttcol>

            <ttcol Types</name>
            <thead>
              <tr>
                <th align="center">Type</th>
                <th align="left">NLRI Type</ttcol>

            <ttcol align="right">Reference</ttcol>

            <c>0</c>

            <c>Reserved</c>

            <c>[This document]</c>

            <c>1</c>

            <c>Node NLRI</c>

            <c>[This document]</c>

            <c>2</c>

            <c>Link NLRI</c>

            <c>[This document]</c>

            <c>3</c>

            <c>IPv4 Type</th>
                <th align="right">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0</td>
                <td align="left">Reserved</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="left">Node NLRI</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="left">Link NLRI</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="left">IPv4 Topology Prefix NLRI</c>

            <c>[This document]</c>

            <c>4</c>

            <c>IPv6 NLRI</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">4</td>
                <td align="left">IPv6 Topology Prefix NLRI</c>

            <c>[This document]</c>

            <c>65000-65535</c>

            <c>Private Use</c>

            <c>[This document]</c>
          </texttable> NLRI</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">65000-65535</td>
                <td align="left">Private Use</td>
                <td align="right">RFC 9552</td>
              </tr>
            </tbody>
          </table>
          <t>A range is reserved for Private Use <xref target="RFC8126"/>. target="RFC8126" format="default"/>. All
          other allocations within the registry are to be made using the
          "Expert Review" policy <xref target="RFC8126"/> that target="RFC8126" format="default"/>, which requires
          documentation of the proposed use of the allocated value and
          approval by the Designated Expert designated expert assigned by the IESG.</t>
        </section>
        <section anchor="PROTOIDREG" title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS Protocol-IDs Registry"> Registry</name>
          <t>The "BGP-LS Protocol-IDs" registry has been set up for assignment
          for the one-octet sized code-points one-octet-sized code points for BGP-LS Protocol-IDs and
          populated with the values shown below:</t>

          <texttable
          <table anchor="protoid_types_table" title="BGP-LS Protocol-IDs">
            <ttcol align="center">Protocol-ID</ttcol>

            <ttcol align="center">
            <name>BGP-LS Protocol-IDs</name>
            <thead>
              <tr>
                <th align="center">Protocol-ID</th>
                <th align="left">NLRI information source protocol</ttcol>

            <ttcol align="right">Reference</ttcol>

            <c>0</c>

            <c>Reserved</c>

            <c>[This document]</c>

            <c>1</c>

            <c>IS-IS protocol</th>
                <th align="right">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0</td>
                <td align="left">Reserved</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="left">IS-IS Level 1</c>

            <c>[This document]</c>

            <c>2</c>

            <c>IS-IS 1</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="left">IS-IS Level 2</c>

            <c>[This document]</c>

            <c>3</c>

            <c>OSPFv2</c>

            <c>[This document]</c>

            <c>4</c>

            <c>Direct</c>

            <c>[This document]</c>

            <c>5</c>

            <c>Static configuration</c>

            <c>[This document]</c>

            <c>6</c>

            <c>OSPFv3</c>

            <c>[This document]</c>

            <c>200-255</c>

            <c>Private Use</c>

            <c>[This document]</c>
          </texttable> 2</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="left">OSPFv2</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">4</td>
                <td align="left">Direct</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">5</td>
                <td align="left">Static configuration</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">6</td>
                <td align="left">OSPFv3</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">200-255</td>
                <td align="left">Private Use</td>
                <td align="right">RFC 9552</td>
              </tr>
            </tbody>
          </table>
          <t>A range is reserved for Private Use <xref target="RFC8126"/>. target="RFC8126" format="default"/>. All
          other allocations within the registry are to be made using the
          "Expert Review" policy <xref target="RFC8126"/> that target="RFC8126" format="default"/>, which requires
          documentation of the proposed use of the allocated value and
          approval by the Designated Expert designated expert assigned by the IESG.</t>
        </section>
        <section anchor="INSTIDREG"
                 title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS Well-Known Instance-IDs Registry"> Registry</name>
          <t>The "BGP-LS Well-Known Instance-IDs" registry that was set up via
          <xref target="RFC7752"/> target="RFC7752" format="default"/> is no longer required. IANA is requested to
          mark has
          marked this registry as obsolete and to change changed its registration
          procedure to "registry closed".</t>
        </section>
        <section anchor="NFLAGSIDREG" title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS Node Flags Registry"> Registry</name>
          <t>The "BGP-LS Node Flags" registry is requested to be has been created for
          the one octet-sized one-octet-sized flags field of the Node Flag Bits TLV (1024) and
          populated with the initial values shown below:</t>

          <texttable
          <table anchor="node_flags_bit_table" title="BGP-LS align="center">
            <name>BGP-LS Node Flags">
            <ttcol align="center">Bit</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol align="right">Reference</ttcol>

            <c>0</c>

            <c>Overload Flags</name>
            <thead>
              <tr>
                <th align="center">Bit</th>
                <th align="left">Description</th>
                <th align="right">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0</td>
                <td align="left">Overload Bit (O-bit)</c>

            <c>[This document]</c>

            <c>1</c>

            <c>Attached (O-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="left">Attached Bit (A-bit)</c>

            <c>[This document]</c>

            <c>2</c>

            <c>External (A-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="left">External Bit (E-bit)</c>

            <c>[This document]</c>

            <c>3</c>

            <c>ABR (E-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="left">ABR Bit (B-bit)</c>

            <c>[This document]</c>

            <c>4</c>

            <c>Router (B-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">4</td>
                <td align="left">Router Bit (R-bit)</c>

            <c>[This document]</c>

            <c>5</c>

            <c>V6 (R-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">5</td>
                <td align="left">V6 Bit (V-bit)</c>

            <c>[This document]</c>

            <c>6-7</c>

            <c>Unassigned</c>

            <c>[This document]</c>
          </texttable> (V-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">6-7</td>
                <td align="left">Unassigned</td>
                <td align="right"></td>
              </tr>
            </tbody>
          </table>
          <t>Allocations within the registry are to be made using the "Expert
          Review" policy <xref target="RFC8126"/> that target="RFC8126" format="default"/>, which requires documentation
          of the proposed use of the allocated value and approval by the
          Designated Expert
          designated expert assigned by the IESG.</t>
        </section>
        <section anchor="MPLSMASKREG"
                 title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS MPLS Protocol Mask Registry"> Registry</name>
          <t>The "BGP-LS MPLS Protocol Mask" registry is requested to be has been
          created for the one octet-sized one-octet-sized flags field of the MPLS Protocol
          Mask TLV (1094) and populated with the initial values shown
          below:</t>

          <texttable
          <table anchor="mpls_proto_mask_table"
                     title="BGP-LS align="center">
            <name>BGP-LS MPLS Protocol Mask">
            <ttcol align="center">Bit</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol align="right">Reference</ttcol>

            <c>0</c>

            <c>Label Mask</name>
            <thead>
              <tr>
                <th align="center">Bit</th>
                <th align="left">Description</th>
                <th align="right">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0</td>
                <td align="left">Label Distribution Protocol (L-bit)</c>

            <c>[This document]</c>

            <c>1</c>

            <c>Extension (L-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="left">Extension to RSVP for LSP Tunnels (R-bit)</c>

            <c>[This document]</c>

            <c>2-7</c>

            <c>Unassigned</c>

            <c>[This document]</c>
          </texttable> (R-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">2-7</td>
                <td align="left">Unassigned</td>
                <td align="right"></td>
              </tr>
            </tbody>
          </table>
          <t>Allocations within the registry are to be made using the "Expert
          Review" policy <xref target="RFC8126"/> that target="RFC8126" format="default"/>, which requires documentation
          of the proposed use of the allocated value and approval by the
          Designated Expert
          designated expert assigned by the IESG.</t>
        </section>
        <section anchor="IGPPFLAGSREG"
                 title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS IGP Prefix Flags Registry"> Registry</name>
          <t>The "BGP-LS IGP Prefix Flags" registry is requested to be has been created
          for the one octet-sized one-octet-sized flags field of the IGP Flags TLV (1152) and
          populated with the initial values shown below:</t>

          <texttable
          <table anchor="prefix_flags_bit_table"
                     title="BGP-LS align="center">
            <name>BGP-LS IGP Prefix Flags">
            <ttcol align="center">Bit</ttcol>

            <ttcol align="left">Description</ttcol>

            <ttcol align="right">Reference</ttcol>

            <c>0</c>

            <c>IS-IS Flags</name>
            <thead>
              <tr>
                <th align="center">Bit</th>
                <th align="left">Description</th>
                <th align="right">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0</td>
                <td align="left">IS-IS Up/Down Bit (D-bit)</c>

            <c>[This document]</c>

            <c>1</c>

            <c>OSPF (D-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">1</td>
                <td align="left">OSPF "no unicast" Bit (N-bit)</c>

            <c>[This document]</c>

            <c>2</c>

            <c>OSPF (N-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="left">OSPF "local address" Bit (L-bit)</c>

            <c>[This document]</c>

            <c>3</c>

            <c>OSPF (L-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="left">OSPF "propagate NSSA" Bit (P-bit)</c>

            <c>[This document]</c>

            <c>4-7</c>

            <c>Unassigned</c>

            <c>[This document]</c>
          </texttable> (P-bit)</td>
                <td align="right">RFC 9552</td>
              </tr>
              <tr>
                <td align="center">4-7</td>
                <td align="left">Unassigned</td>
                <td align="right"></td>
              </tr>
            </tbody>
          </table>
          <t>Allocations within the registry are to be made using the "Expert
          Review" policy <xref target="RFC8126"/> that target="RFC8126" format="default"/>, which requires documentation
          of the proposed use of the allocated value and approval by the
          Designated Expert
          designated expert assigned by the IESG.</t>
        </section>

        <section anchor="TLVREG" title="BGP-LS numbered="true" toc="default">
          <name>BGP-LS TLVs Registry"> Registry</name>
          <t>The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor,
          and Attribute TLVs" registry was created via <xref
          target="RFC7752"/>. This document requests target="RFC7752" format="default"/>. Per this document, IANA to rename has renamed that
          registry to "BGP-LS NLRI and Attribute TLVs" and to remove removed the
          column for "IS-IS TLV/Sub-TLV". The registration procedures are as
          below:</t>

          <texttable
          follows:</t>
          <table anchor="reg_types"
                     title="BGP-LS align="center">
            <name>BGP-LS TLVs Registration Process">
            <ttcol Process</name>
            <thead>
              <tr>
                <th align="center">TLV Code Point</ttcol>

            <ttcol Point</th>
                <th align="left">Registration Process</ttcol>

            <c>0-255</c>

            <c>Reserved Process</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">0-255</td>
                <td align="left">Reserved (not to be allocated)</c>

            <c>256-64999</c>

            <c>Expert Review</c>

            <c>65000-65535</c>

            <c>Private Use</c>
          </texttable> allocated)</td>
              </tr>
              <tr>
                <td align="center">256-64999</td>
                <td align="left">Expert Review</td>
              </tr>
              <tr>
                <td align="center">65000-65535</td>
                <td align="left">Private Use</td>
              </tr>
            </tbody>
          </table>
          <t>A range is reserved for Private Use <xref target="RFC8126"/>. target="RFC8126" format="default"/>. All
          other allocations except for the reserved range within the registry
          are to be made using the "Expert Review" policy <xref
          target="RFC8126"/> that target="RFC8126" format="default"/>, which requires documentation of the proposed use
          of the allocated value and approval by the Designated Expert designated expert
          assigned by the IESG.</t>
          <t>The registry was pre-populated with the values shown in <xref
          target="BGPLSCODEPOINTS"/> target="BGPLSCODEPOINTS" format="default"/>, and the reference for all those
          allocations should be each
          allocation has been changed to this document and the respective
          section where those TLVs are specified.</t>
        </section>
      </section>
      <section anchor="DE-Guidance" title="Guidance numbered="true" toc="default">
        <name>Guidance for Designated Experts"> Experts</name>
        <t>In all cases of review by the designated expert described here, the
        designated expert is expected to check the clarity of purpose and use
        of the requested code points. The following points apply to the
        registries discussed in this document:</t>

        <t><list style="numbers">
            <t>Application
        <ol spacing="normal" type="1"><li>Application for a code point allocation may be made to the
            designated experts at any time and MUST <bcp14>MUST</bcp14> be accompanied by
            technical documentation explaining the use of the code point. Such
            documentation SHOULD <bcp14>SHOULD</bcp14> be presented in the form of an
            Internet-Draft,
            Internet-Draft but MAY <bcp14>MAY</bcp14> arrive in any form that can be reviewed
            and exchanged among reviewers.</t>

            <t>The reviewers.</li>
          <li>The designated experts SHOULD <bcp14>SHOULD</bcp14> only consider requests that arise
            from Internet-Drafts that have already been accepted as working
            group documents or that are planned for progression as
            AD-Sponsored documents in the absence of a suitably chartered
            working group.</t>

            <t>In group.</li>
          <li>In the case of working group documents, the designated experts
            MUST
            <bcp14>MUST</bcp14> check with the working group chairs that there is a consensus
            within the working group to allocate at this time. In the case of
            AD-Sponsored documents, the designated experts MUST <bcp14>MUST</bcp14> check with the
            AD for approval to allocate at this time.</t>

            <t>If time.</li>
          <li>If the document is not adopted by the IDR Working Group (or its
            successor), the designated expert MUST <bcp14>MUST</bcp14> notify the IDR mailing list
            (or its successor) of the request and MUST <bcp14>MUST</bcp14> provide access to the
            document. The designated expert MUST <bcp14>MUST</bcp14> allow two weeks for any
            response. Any comments received MUST <bcp14>MUST</bcp14> be considered by the
            designated expert as part of the subsequent step.</t>

            <t>The step.</li>
          <li>The designated experts MUST <bcp14>MUST</bcp14> then review the assignment requests
            on their technical merit. The designated experts MAY <bcp14>MAY</bcp14> raise issues
            related to the allocation request with the authors and on the IDR
            (or successor) mailing list for further consideration before the
            assignments are made.</t>

            <t>The made.</li>
          <li>The designated expert MUST <bcp14>MUST</bcp14> ensure that any request for a code
            point does not conflict with work that is active or already
            published within the IETF.</t>

            <t>Once IETF.</li>
          <li>Once the designated experts have approved, IANA will update the
            registry by marking the allocated code points with a reference to
            the associated document.</t>

            <t>In document.</li>
          <li>In the event that the document is a working group document or
            is AD-Sponsored, AD-Sponsored and that document fails to progress to
            publication as an RFC, the working group chairs or AD SHOULD <bcp14>SHOULD</bcp14>
            contact IANA to coordinate about marking the code points as
            deprecated. A deprecated code point is not marked as allocated for
            use and is not available for allocation in a future document. The
            WG chairs may inform IANA that a deprecated code point can be
            completely deallocated (i.e., made available for new allocations)
            at any time after it has been deprecated if there is a shortage of
            unallocated code points in the registry.</t>
          </list></t> registry.</li>
        </ol>
      </section>
    </section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>This section is structured as recommended in <xref
      target="RFC5706"/>.</t> target="RFC5706" format="default"/>.</t>
      <section anchor="Operational-Considerations"
               title="Operational Considerations"> numbered="true" toc="default">
        <name>Operational Considerations</name>
        <section anchor="Operations" title="Operations"> numbered="true" toc="default">
          <name>Operations</name>
          <t>Existing BGP operational procedures apply. No new operation
          procedures are defined in this document. It is noted that the NLRI
          information present in this document carries purely
          application-level data that has no immediate impact on the
          corresponding forwarding state computed by BGP. As such, any churn
          in reachability information has a different impact than regular BGP
          updates, which need to change the forwarding state for an entire
          router. Distribution of the BGP-LS NLRIs SHOULD <bcp14>SHOULD</bcp14> be handled by
          dedicated route reflectors in most deployments providing a level of
          isolation and fault containment between different BGP address
          families. In the event of dedicated route reflectors not being
          available, other alternate mechanisms like separation of BGP
          instances or separate BGP sessions (e.g. (e.g., using different addresses
          for peering) for Link-State information distribution SHOULD <bcp14>SHOULD</bcp14> be
          used.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that operators deploying BGP-LS enable two or
          more BGP-LS Producers in each IGP flooding domain to achieve
          redundancy in the origination of link-state information into BGP-LS.
          It is also RECOMMENDED <bcp14>RECOMMENDED</bcp14> that operators ensure BGP peering designs
          that ensure redundancy in the BGP update propagation paths (e.g.,
          using at least a pair of route reflectors) and ensuring ensure that BGP-LS
          Consumers are receiving the topology information from at least two
          BGP-LS Speakers.</t>
          <t>In a multi-domain IGP network, the correct provisioning of the
          BGP-LS Instance-IDs on the BGP-LS Producers is required for
          consistent reporting of the multi-domain link-state topology. Refer
          to <xref target="BGPLSNLRI"/> target="BGPLSNLRI" format="default"/> for more details.</t>
        </section>
        <section anchor="Initial-Setup" title="Installation numbered="true" toc="default">
          <name>Installation and Initial Setup"> Setup</name>
          <t>Configuration parameters defined in <xref
          target="Configuration-Management"/> SHOULD target="Configuration-Management" format="default"/> <bcp14>SHOULD</bcp14> be initialized to the
          following default values: <list style="symbols">
              <t>The </t>
          <ul spacing="normal">
            <li>The Link-State NLRI capability is turned off for all
              neighbors.</t>

              <t>The
              neighbors.</li>
            <li>The maximum rate at which Link-State NLRIs will be
              advertised/withdrawn from neighbors is set to 200 updates per
              second.</t>
            </list></t>
              second.</li>
          </ul>
        </section>
        <section anchor="Migration-Path" title="Migration Path"> numbered="true" toc="default">
          <name>Migration Path</name>
          <t>The proposed extension is only activated between BGP peers after
          capability negotiation. Moreover, the extensions can be turned
          on/off on an individual peer basis (see <xref
          target="Configuration-Management"/>), target="Configuration-Management" format="default"/>), so the extension can be
          gradually rolled out in the network.</t>
        </section>
        <section anchor="Other-Protocols"
                 title="Requirements numbered="true" toc="default">
          <name>Requirements for Other Protocols and Functional Components"> Components</name>
          <t>The protocol extension defined in this document does not put new
          requirements on other protocols or functional components.</t>
        </section>
        <section anchor="Network-Operation"
                 title="Impact numbered="true" toc="default">
          <name>Impact on Network Operation"> Operation</name>
          <t>The frequency of Link-State NLRI updates could interfere with
          regular BGP prefix distribution. A network operator should use a
          dedicated route reflector infrastructure to distribute Link-State
          NLRIs as discussed in <xref target="Operations"/>.</t> target="Operations" format="default"/>.</t>
          <t>Distribution of Link-State NLRIs SHOULD <bcp14>SHOULD</bcp14> be limited to a single
          admin domain, which can consist of multiple areas within an AS or
          multiple ASes.</t>
        </section>
        <section anchor="Verifying-Correct-Operation"
                 title="Verifying numbered="true" toc="default">
          <name>Verifying Correct Operation"> Operation</name>
          <t>Existing BGP procedures apply. In addition, an implementation
          SHOULD
          <bcp14>SHOULD</bcp14> allow an operator to: <list style="symbols">
              <t>List </t>
          <ul spacing="normal">
            <li>List neighbors with whom the speaker is exchanging Link-State
              NLRIs.</t>
            </list></t>
              NLRIs.</li>
          </ul>
        </section>
      </section>
      <section anchor="Management-Considerations"
               title="Management Considerations"> numbered="true" toc="default">
        <name>Management Considerations</name>
        <section anchor="Management-Information"
                 title="Management Information"> numbered="true" toc="default">
          <name>Management Information</name>
          <t>The IDR working group Working Group has documented and continues to document
          parts of the Management Information Base and YANG models for
          managing and monitoring BGP speakers Speakers and the sessions between them.
          It is currently believed that the BGP session running BGP-LS is not
          substantially different from any other BGP session and can be
          managed using the same data models.</t>
        </section>
        <section anchor="Fault-Management" title="Fault Management"> numbered="true" toc="default">
          <name>Fault Management</name>
          <t>This section describes the fault management actions, as described
          in <xref target="RFC7606"/>, target="RFC7606" format="default"/>, that are to be performed for the
          handling of BGP UPDATE messages for BGP-LS.</t>
          <t>A Link-State NLRI MUST NOT <bcp14>MUST NOT</bcp14> be considered malformed or invalid
          based on the inclusion/exclusion of TLVs or contents of the TLV
          fields (i.e. (i.e., semantic errors), as described in Sections <xref
          target="TLV-section"/> target="TLV-section" format="counter"/> and <xref target="BGPLSNLRI"/>.</t> target="BGPLSNLRI" format="counter"/>.</t>
          <t>A BGP-LS Speaker MUST <bcp14>MUST</bcp14> perform the following syntactic validation
          of the Link-State NLRI to determine if it is malformed.<list
              style="symbols">
              <t>The malformed.</t>
          <ul spacing="normal">
            <li>The sum of all TLVs TLV lengths found in the BGP MP_REACH_NLRI
              attribute corresponds to the BGP MP_REACH_NLRI length.</t>

              <t>The length.</li>
            <li>The sum of all TLVs TLV lengths found in the BGP MP_UNREACH_NLRI
              attribute corresponds to the BGP MP_UNREACH_NLRI length.</t>

              <t>The length.</li>
            <li>The sum of all TLVs TLV lengths found in a Link-State NLRI
              corresponds to the Total NLRI Length field of all its
              Descriptors.</t>

              <t>The
              descriptors.</li>
            <li>The length of the TLVs and, when the TLV is recognized then,
              the length of its sub-TLVs in the NLRI is valid.</t>

              <t>The are valid.</li>
            <li>The syntactic correctness of the NLRI fields has been verified as
              per <xref target="RFC7606"/>.</t>

              <t>The target="RFC7606" format="default"/>.</li>
            <li>The rule regarding the ordering of TLVs has been followed as
              described in <xref target="TLV-section"/>.</t>

              <t>For target="TLV-section" format="default"/>.</li>
            <li>For NLRIs carrying either a Local or Remote Node Descriptor
              TLV, there is not more than one instance of a sub-TLV
              present.</t>
            </list></t>
              present.</li>
          </ul>
          <t>When the error that is determined allows for the router to skip
          the malformed NLRI(s) and continue the processing of the rest of the
          BGP UPDATE message (e.g. (e.g., when the TLV ordering rule is violated),
          then it MUST <bcp14>MUST</bcp14> handle such malformed NLRIs as 'NLRI discard' (i.e.,
          processing similar to what is described in section 5.4 of <xref
          target="RFC7606"/>). target="RFC7606" section="5.4" sectionFormat="of" format="default"/>). In other cases, where the error in the NLRI
          encoding results in the inability to process the BGP UPDATE message
          (e.g. length related
          (e.g., length-related encoding errors), then the router SHOULD <bcp14>SHOULD</bcp14> handle
          such malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI
          besides BGP-LS are being advertised over the same session.
          Alternately, the router MUST <bcp14>MUST</bcp14> perform a 'session reset' when the
          session is only being used for BGP-LS or if 'AFI/SAFI disable'
          action is not possible.</t>
          <t>A BGP-LS Attribute MUST NOT <bcp14>MUST NOT</bcp14> be considered malformed or invalid
          based on the inclusion/exclusion of TLVs or contents of the TLV
          fields (i.e. (i.e., semantic errors), as described in Sections <xref
          target="TLV-section"/> target="TLV-section" format="counter"/> and <xref target="BGPLSATTR"/>.</t> target="BGPLSATTR" format="counter"/>.</t>
          <t>A BGP-LS Speaker MUST <bcp14>MUST</bcp14> perform the following syntactic validation
          of the BGP-LS Attribute to determine if it is malformed.<list
              style="symbols">
              <t>The malformed.</t>
          <ul spacing="normal">
            <li>The sum of all TLVs TLV lengths found in the BGP-LS Attribute
              corresponds to the BGP-LS Attribute length.</t>

              <t>The length.</li>
            <li>The syntactic correctness of the Attributes (including the BGP-LS
              Attribute) have been verified as per <xref target="RFC7606"/>.</t>

              <t>The target="RFC7606" format="default"/>.</li>
            <li>The length of each TLV and, when the TLV is recognized then,
              the length of its sub-TLVs in the BGP-LS Attribute is valid.</t>
            </list></t> are valid.</li>
          </ul>
          <t>When the error that is determined allows for the router to skip
          the malformed BGP-LS Attribute and continue the processing of the
          rest of the BGP UPDATE message (e.g. (e.g., when the BGP-LS Attribute
          length and the total Path Attribute Length are correct but some
          TLV/sub-TLV length within the BGP-LS Attribute is invalid), then it
          MUST
          <bcp14>MUST</bcp14> handle such malformed BGP-LS Attribute as 'Attribute Discard'.
          In other cases, where the error in the BGP-LS Attribute encoding
          results in the inability to process the BGP UPDATE message then message, the
          handling is the same as described above for the malformed NLRI.</t>
          <t>Note that the 'Attribute Discard' action results in the loss of
          all TLVs in the BGP-LS Attribute and not the removal of a specific
          malformed TLV. The removal of specific malformed TLVs may give a
          wrong indication to a BGP-LS Consumer of that specific information
          being deleted or not available.</t>
          <t>When a BGP Speaker receives an UPDATE message with Link-State
          NLRI(s) in the MP_REACH_NLRI but without the BGP-LS Attribute, it is
          most likely an indication that a BGP Speaker preceding it has
          performed the 'Attribute Discard' fault handling. An implementation
          SHOULD
          <bcp14>SHOULD</bcp14> preserve and propagate the Link-State NLRIs, unless denied by
          local policy, in such an UPDATE message so that the BGP-LS Consumers
          can detect the loss of link-state information for that object and
          not assume its deletion/withdrawal. This also makes it possible for
          a network operator to trace back to the BGP-LS Propagator that
          detected the fault with the BGP-LS Attribute.</t>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> log a message for any errors found
          during syntax validation for further analysis.</t>
          <t>A BGP-LS Propagator, even when it has a coexisting BGP-LS
          Consumer on the same node, should not perform semantic validation of
          the Link-State NLRI or the BGP-LS Attribute to determine if it is
          malformed or invalid. Some types of semantic validation that are not
          to be performed by a BGP-LS Propagator are as follows (and this is
          not to be considered as an exhaustive list):<list style="symbols">
              <t>presence list):</t>
          <ul spacing="normal">
            <li>presence of a mandatory TLV</t>

              <t>the TLV</li>
            <li>the length of a fixed-length TLV is correct or the length of a
              variable length TLV is valid or permissible</t>

              <t>the permissible</li>
            <li>the values of TLV fields are valid or permissible</t>

              <t>the permissible</li>
            <li>the inclusion and use of TLVs/sub-TLVs with specific
              Link-State NLRI types is valid</t>
            </list></t> valid</li>
          </ul>
          <t>Each TLV may indicate the valid and permissible values and their
          semantics that can be used only by a BGP-LS Consumer for its
          semantic validation. However, the handling of any errors may be
          specific to the particular application and outside the scope of this
          document.</t>
        </section>
        <section anchor="Configuration-Management"
                 title="Configuration Management"> numbered="true" toc="default">
          <name>Configuration Management</name>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to specify neighbors
          to which Link-State NLRIs will be advertised and from which
          Link-State NLRIs will be accepted.</t>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to specify the
          maximum rate at which Link-State NLRIs will be advertised/withdrawn
          from neighbors.</t>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to specify the
          maximum number of Link-State NLRIs stored in a router's Routing
          Information Base (RIB).</t>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to create abstracted
          topologies that are advertised to neighbors and create different
          abstractions for different neighbors.</t>
          <t>An implementation MUST <bcp14>MUST</bcp14> allow the operator to configure an 8-octet
          BGP-LS Instance-ID. Refer to <xref target="BGPLSNLRI"/> target="BGPLSNLRI" format="default"/> for guidance
          to the operator for the configuration of BGP-LS Instance-ID.</t>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to configure ASN Autonomous System Number (ASN) and
          BGP-LS identifiers (refer to <xref target="node_desc_tlvs"/>).</t> target="node_desc_tlvs" format="default"/>).</t>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to configure limiting
          of
          the maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS
          Producer or to allow larger values when they know that <xref
          target="RFC8654"/> target="RFC8654" format="default"/> is supported on all BGP-LS Speakers.</t>
        </section>
        <section anchor="Accounting-Management" title="Accounting Management"> numbered="true" toc="default">
          <name>Accounting Management</name>
          <t>Not Applicable.</t>
        </section>
        <section anchor="Performance-Management"
                 title="Performance Management"> numbered="true" toc="default">
          <name>Performance Management</name>
          <t>An implementation SHOULD <bcp14>SHOULD</bcp14> provide the following statistics: <list
              style="symbols">
              <t>Total </t>
          <ul spacing="normal">
            <li>Total number of Link-State NLRI updates sent/received</t>

              <t>Number sent/received</li>
            <li>Number of Link-State NLRI updates sent/received, per
              neighbor</t>

              <t>Number
              neighbor</li>
            <li>Number of errored received Link-State NLRI updates, per
              neighbor</t>

              <t>Total
              neighbor</li>
            <li>Total number of locally originated Link-State NLRIs</t>
            </list></t> NLRIs</li>
          </ul>
          <t>These statistics should be recorded as absolute counts since the
          system or session start time. An implementation MAY <bcp14>MAY</bcp14> also enhance
          this information by recording peak per-second counts in each
          case.</t>
        </section>
        <section anchor="Security-Management" title="Security Management"> numbered="true" toc="default">
          <name>Security Management</name>
          <t>An operator MUST <bcp14>MUST</bcp14> define an import policy to limit inbound updates
          as follows: <list style="symbols">
              <t>Drop </t>
          <ul spacing="normal">
            <li>Drop all updates from peers that are only serving BGP-LS
              Consumers.</t>
            </list></t>
              Consumers.</li>
          </ul>
          <t>An implementation MUST <bcp14>MUST</bcp14> have the means to limit inbound
          updates.</t>
        </section>
      </section>
    </section>
    <section anchor="TLVSUMMARY" title="TLV/Sub-TLV numbered="true" toc="default">
      <name>TLV/Sub-TLV Code Points Summary"> Summary</name>
      <t>This section contains the global table of all TLVs/sub-TLVs defined
      in this document.</t>

      <texttable
      <table anchor="BGPLSCODEPOINTS"
                 title="Summary align="center">
        <name>Summary Table of TLV/Sub-TLV Code Points">
        <ttcol Points</name>
        <thead>
          <tr>
            <th align="center">TLV Code Point</ttcol>

        <ttcol align="left">Description</ttcol>

        <ttcol Point</th>
            <th align="left">Description</th>
            <th align="left">Reference Section</ttcol>

        <c>256</c>

        <c>Local Section</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">256</td>
            <td align="left">Local Node Descriptors</c>

        <c><xref target="LOCALNODEDESC"/></c>

        <c>257</c>

        <c>Remote Descriptors</td>
            <td align="left">
              <xref target="LOCALNODEDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">257</td>
            <td align="left">Remote Node Descriptors</c>

        <c><xref target="REMOTENODEDESC"/></c>

        <c>258</c>

        <c>Link Descriptors</td>
            <td align="left">
              <xref target="REMOTENODEDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">258</td>
            <td align="left">Link Local/Remote Identifiers</c>

        <c><xref target="LINKDESC"/></c>

        <c>259</c>

        <c>IPv4 Identifiers</td>
            <td align="left">
              <xref target="LINKDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">259</td>
            <td align="left">IPv4 interface address</c>

        <c><xref target="LINKDESC"/></c>

        <c>260</c>

        <c>IPv4 address</td>
            <td align="left">
              <xref target="LINKDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">260</td>
            <td align="left">IPv4 neighbor address</c>

        <c><xref target="LINKDESC"/></c>

        <c>261</c>

        <c>IPv6 address</td>
            <td align="left">
              <xref target="LINKDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">261</td>
            <td align="left">IPv6 interface address</c>

        <c><xref target="LINKDESC"/></c>

        <c>262</c>

        <c>IPv6 address</td>
            <td align="left">
              <xref target="LINKDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">262</td>
            <td align="left">IPv6 neighbor address</c>

        <c><xref target="LINKDESC"/></c>

        <c>263</c>

        <c>Multi-Topology ID</c>

        <c><xref target="MT-ID"/></c>

        <c>264</c>

        <c>OSPF address</td>
            <td align="left">
              <xref target="LINKDESC" format="default"/></td>
          </tr>
          <tr>
            <td align="center">263</td>
            <td align="left">Multi-Topology Identifier</td>
            <td align="left">
              <xref target="MT-ID" format="default"/></td>
          </tr>
          <tr>
            <td align="center">264</td>
            <td align="left">OSPF Route Type</c>

        <c><xref target="PREFIXDESC"/></c>

        <c>265</c>

        <c>IP Type</td>
            <td align="left">
              <xref target="OSPFRTETYPE" format="default"/></td>
          </tr>
          <tr>
            <td align="center">265</td>
            <td align="left">IP Reachability Information</c>

        <c><xref target="PREFIXDESC"/></c>

        <c>512</c>

        <c>Autonomous System</c>

        <c><xref target="node_desc_tlvs"/></c>

        <c>513</c>

        <c>BGP-LS Information</td>
            <td align="left">
              <xref target="IPREACHINFO" format="default"/></td>
          </tr>
          <tr>
            <td align="center">512</td>
            <td align="left">Autonomous System</td>
            <td align="left">
              <xref target="node_desc_tlvs" format="default"/></td>
          </tr>
          <tr>
            <td align="center">513</td>
            <td align="left">BGP-LS Identifier (deprecated)</c>

        <c><xref target="node_desc_tlvs"/></c>

        <c>514</c>

        <c>OSPF Area-ID</c>

        <c><xref target="node_desc_tlvs"/></c>

        <c>515</c>

        <c>IGP Router-ID</c>

        <c><xref target="node_desc_tlvs"/></c>

        <c>1024</c>

        <c>Node (deprecated)</td>
            <td align="left">
              <xref target="node_desc_tlvs" format="default"/></td>
          </tr>
          <tr>
            <td align="center">514</td>
            <td align="left">OSPF Area-ID</td>
            <td align="left">
              <xref target="node_desc_tlvs" format="default"/></td>
          </tr>
          <tr>
            <td align="center">515</td>
            <td align="left">IGP Router-ID</td>
            <td align="left">
              <xref target="node_desc_tlvs" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1024</td>
            <td align="left">Node Flag Bits</c>

        <c><xref target="NODEFLAGBITS"/></c>

        <c>1025</c>

        <c>Opaque Bits</td>
            <td align="left">
              <xref target="NODEFLAGBITS" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1025</td>
            <td align="left">Opaque Node Attribute</c>

        <c><xref target="OPAQUENODE"/></c>

        <c>1026</c>

        <c>Node Name</c>

        <c><xref target="NODENAME"/></c>

        <c>1027</c>

        <c>IS-IS Attribute</td>
            <td align="left">
              <xref target="OPAQUENODE" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1026</td>
            <td align="left">Node Name</td>
            <td align="left">
              <xref target="NODENAME" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1027</td>
            <td align="left">IS-IS Area Identifier</c>

        <c><xref target="ISISAREA"/></c>

        <c>1028</c>

        <c>IPv4 Identifier</td>
            <td align="left">
              <xref target="ISISAREA" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1028</td>
            <td align="left">IPv4 Router-ID of Local Node</c>

        <c><xref target="aux_routerid_node"/> / <xref
        target="aux_routerid_link"/></c>

        <c>1029</c>

        <c>IPv6 Node</td>
            <td align="left">Sections
              <xref target="aux_routerid_node" format="counter"/> and <xref target="aux_routerid_link" format="counter"/></td>
          </tr>
          <tr>
            <td align="center">1029</td>
            <td align="left">IPv6 Router-ID of Local Node</c>

        <c><xref target="aux_routerid_node"/> / <xref
        target="aux_routerid_link"/></c>

        <c>1030</c>

        <c>IPv4 Node</td>
            <td align="left">Sections
              <xref target="aux_routerid_node" format="counter"/> and <xref target="aux_routerid_link" format="counter"/></td>
          </tr>
          <tr>
            <td align="center">1030</td>
            <td align="left">IPv4 Router-ID of Remote Node</c>

        <c><xref target="aux_routerid_link"/></c>

        <c>1031</c>

        <c>IPv6 Node</td>
            <td align="left">
              <xref target="aux_routerid_link" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1031</td>
            <td align="left">IPv6 Router-ID of Remote Node</c>

        <c><xref target="aux_routerid_link"/></c>

        <c>1088</c>

        <c>Administrative Node</td>
            <td align="left">
              <xref target="aux_routerid_link" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1088</td>
            <td align="left">Administrative group (color)</c>

        <c><xref target="link_attribute"/></c>

        <c>1089</c>

        <c>Maximum (color)</td>
            <td align="left">
              <xref target="link_attribute" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1089</td>
            <td align="left">Maximum link bandwidth</c>

        <c><xref target="link_attribute"/></c>

        <c>1090</c>

        <c>Max. bandwidth</td>
            <td align="left">
              <xref target="link_attribute" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1090</td>
            <td align="left">Max. reservable link bandwidth</c>

        <c><xref target="link_attribute"/></c>

        <c>1091</c>

        <c>Unreserved bandwidth</c>

        <c><xref target="link_attribute"/></c>

        <c>1092</c>

        <c>TE bandwidth</td>
            <td align="left">
              <xref target="link_attribute" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1091</td>
            <td align="left">Unreserved bandwidth</td>
            <td align="left">
              <xref target="link_attribute" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1092</td>
            <td align="left">TE Default Metric</c>

        <c><xref target="TEDEFAULTMETTLV"/></c>

        <c>1093</c>

        <c>Link Metric</td>
            <td align="left">
              <xref target="TEDEFAULTMETTLV" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1093</td>
            <td align="left">Link Protection Type</c>

        <c><xref target="link_attribute"/></c>

        <c>1094</c>

        <c>MPLS Type</td>
            <td align="left">
              <xref target="link_attribute" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1094</td>
            <td align="left">MPLS Protocol Mask</c>

        <c><xref target="MPLSPROTOTLV"/></c>

        <c>1095</c>

        <c>IGP Metric</c>

        <c><xref target="IGPMETTLV"/></c>

        <c>1096</c>

        <c>Shared Mask</td>
            <td align="left">
              <xref target="MPLSPROTOTLV" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1095</td>
            <td align="left">IGP Metric</td>
            <td align="left">
              <xref target="IGPMETTLV" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1096</td>
            <td align="left">Shared Risk Link Group</c>

        <c><xref target="SRLGTLV"/></c>

        <c>1097</c>

        <c>Opaque Link Attribute</c>

        <c><xref target="OPAQUELINK"/></c>

        <c>1098</c>

        <c>Link Name</c>

        <c><xref target="LINKNAME"/></c>

        <c>1152</c>

        <c>IGP Flags</c>

        <c><xref target="IGPFLAGS"/></c>

        <c>1153</c>

        <c>IGP Group</td>
            <td align="left">
              <xref target="SRLGTLV" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1097</td>
            <td align="left">Opaque Link Attribute</td>
            <td align="left">
              <xref target="OPAQUELINK" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1098</td>
            <td align="left">Link Name</td>
            <td align="left">
              <xref target="LINKNAME" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1152</td>
            <td align="left">IGP Flags</td>
            <td align="left">
              <xref target="IGPFLAGS" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1153</td>
            <td align="left">IGP Route Tag</c>

        <c><xref target="route_tag"/></c>

        <c>1154</c>

        <c>IGP Tag</td>
            <td align="left">
              <xref target="route_tag" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1154</td>
            <td align="left">IGP Extended Route Tag</c>

        <c><xref target="ext_route_tag"/></c>

        <c>1155</c>

        <c>Prefix Metric</c>

        <c><xref target="prefix_metric"/></c>

        <c>1156</c>

        <c>OSPF Tag</td>
            <td align="left">
              <xref target="ext_route_tag" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1155</td>
            <td align="left">Prefix Metric</td>
            <td align="left">
              <xref target="prefix_metric" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1156</td>
            <td align="left">OSPF Forwarding Address</c>

        <c><xref target="ospf_fwd_addr"/></c>

        <c>1157</c>

        <c>Opaque Address</td>
            <td align="left">
              <xref target="ospf_fwd_addr" format="default"/></td>
          </tr>
          <tr>
            <td align="center">1157</td>
            <td align="left">Opaque Prefix Attribute</c>

        <c><xref target="OPAQUEPREFIX"/></c>
      </texttable> Attribute</td>
            <td align="left">
              <xref target="OPAQUEPREFIX" format="default"/></td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Procedures and protocol extensions defined in this document do not
      affect the BGP security model. See the Security Considerations section
      of <xref target="RFC4271"/> target="RFC4271" format="default"/> for a discussion of BGP security. Also,
      refer to <xref target="RFC4272"/> target="RFC4272" format="default"/> and <xref target="RFC6952"/> target="RFC6952" format="default"/> for
      analysis of security issues for BGP.</t>
      <t>The operator should ensure that a BGP-LS speaker Speaker does not accept
      UPDATE messages from a peer that only provides information to a BGP-LS
      Consumer by using the policy configuration options discussed in Sections <xref
      target="Configuration-Management"/> target="Configuration-Management" format="counter"/> and <xref
      target="Security-Management"/>. target="Security-Management" format="counter"/>. Generally, an operator is aware of the
      BGP-LS speaker's Speaker's role and link-state peerings. Therefore, the operator
      can protect the BGP-LS speaker Speaker from peers sending updates that may
      represent erroneous information, feedback loops, or false input.</t>
      <t>An error or tampering of the link-state information that is
      originated into BGP-LS and propagated through the network for use by
      BGP-LS Consumers applications can result in the malfunction of those
      applications. Some examples of such risks are the origination of
      incorrect information that is not present or consistent with the IGP
      LSDB at the BGP-LS Producer, incorrect ordering of TLVs in the NLRI NLRI, or
      inconsistent origination from multiple BGP-LS Producers and updates to
      either the NLRI or BGP-LS Attribute during propagation (including
      discarding due to errors). These are not new risks from a BGP protocol
      perspective,
      perspective; however, in the case of BGP-LS BGP-LS, impact reflects on the
      consumer applications instead of BGP routing functionalities.</t>
      <t>Additionally, it may be considered that the export of link-state and
      TE information as described in this document constitutes a risk to
      confidentiality of mission-critical or commercially sensitive
      information about the network. BGP peerings are not automatic and
      require configuration; thus, it is the responsibility of the network
      operator to ensure that only trusted BGP Speakers are configured to
      receive such information. Similar security considerations also arise on
      the interface between BGP Speaker Speakers and BGP-LS Consumers, but their
      discussion is outside the scope of this document.</t>
    </section>

    <section anchor="Contributors" title="Contributors">
      <t>The following persons contributed significant text to RFC7752 and
      this document. They should be considered co-authors.</t>

      <t><figure>
          <artwork><![CDATA[Hannes Gredler
Rtbrick
Email: hannes@rtbrick.com]]></artwork>
        </figure></t>

      <t><figure>
          <artwork><![CDATA[Jan Medved
Cisco Systems Inc.
USA
Email: jmedved@cisco.com]]></artwork>
        </figure></t>

      <t><figure>
          <artwork><![CDATA[Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.net]]></artwork>
        </figure></t>

      <t><figure>
          <artwork><![CDATA[Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk]]></artwork>
        </figure></t>

      <t><figure>
          <artwork><![CDATA[Saikat Ray
Individual
USA
Email: raysaikat@gmail.com]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This document update to the BGP-LS specification <xref
      target="RFC7752"/> is a result of feedback and inputs from the
      discussions in the IDR working group. It also incorporates certain
      details and clarifications based on implementation and deployment
      experience with BGP-LS.</t>

      <t>Cengiz Alaettinoglu and Parag Amritkar brought forward the need to
      clarify the advertisement of a LAN subnet for OSPF.</t>

      <t>We would like to thank Balaji Rajagopalan, Srihari Sangli, Shraddha
      Hegde, Andrew Stone, Jeff Tantsura, Acee Lindem, Les Ginsberg, Jie Dong,
      Aijun Wang, Nandan Saha, Joel Halpern, and Gyan Mishra for their review
      and feedback on this document. Thanks to Tom Petch for his review and
      comments on the IANA Considerations section. Would also like to thank
      Jeffrey Haas for his detailed shepherd review and inputs for improving
      the document.</t>

      <t>The detailed AD review by Alvaro Retana and his suggestions have
      helped improve this document significantly.</t>

      <t>We would like to thank Robert Varga for his significant contribution
      to RFC7752.</t>

      <t>We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek
      Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les
      Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, Peter
      Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas
      Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, Balaji Rajagopalan,
      Yakov Rekhter, Alvaro Retana, Barry Leiba, and Ben Campbell for their
      comments on RFC7752.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>

      <?rfc include="reference.RFC.2328.xml"?>

      <?rfc include="reference.RFC.2545.xml"?>

      <?rfc include="reference.RFC.3209.xml"?>

      <?rfc include="reference.RFC.4202.xml"?>

      <?rfc include="reference.RFC.4203.xml"?>

      <?rfc include="reference.RFC.4271.xml"?>

      <?rfc include="reference.RFC.4760.xml"?>

      <?rfc include="reference.RFC.4915.xml"?>

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

      <?rfc include="reference.RFC.5120.xml"?>

      <?rfc include="reference.RFC.5130.xml"?>

      <?rfc include="reference.RFC.5301.xml"?>

      <?rfc include="reference.RFC.5642.xml"?>

      <?rfc include="reference.RFC.8126.xml"?>

      <?rfc include="reference.RFC.5305.xml"?>

      <?rfc include="reference.RFC.5307.xml"?>

      <?rfc include="reference.RFC.5340.xml"?>

      <?rfc include="reference.RFC.5890.xml"?>

      <?rfc include="reference.RFC.6119.xml"?>

      <?rfc include="reference.RFC.7606.xml"?>

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

      <?rfc include='reference.RFC.8654.xml'?>

      <?rfc include='reference.RFC.4577.xml'?>

      <?rfc include='reference.RFC.6565.xml'?>

      <?rfc include='reference.RFC.7684.xml'?>

      <?rfc include='reference.RFC.8362.xml'?>

      <?rfc include="reference.RFC.7770.xml"?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2545.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4915.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5130.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5642.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7606.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8654.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4577.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6565.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"/>
        <reference anchor="ISO10589">
          <front>
          <title>Intermediate
            <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>
            <author>
            <organization>International Organization for
            Standardization</organization>
              <organization>ISO</organization>
            </author>
            <date month="November" year="2002"/>
          </front>
          <seriesInfo name="ISO/IEC" value="10589"/> value="10589:2002"/>
        </reference>
        <reference anchor="ENTNUM" target="https://www.iana.org/assignments/enterprise-numbers/">
          <front>
            <title>Private Enterprise Numbers</title> Numbers (PENs)</title>
            <author>
              <organization>IANA</organization>
            </author>

          <date year=""/>
          </front>
        </reference>
      </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.1918.xml"?>

      <?rfc include="reference.RFC.4272.xml"?>

      <?rfc include="reference.RFC.4364.xml"?>

      <?rfc include="reference.RFC.4655.xml"?>

      <?rfc include="reference.RFC.5152.xml"?>

      <?rfc include="reference.RFC.9346.xml"?>

      <?rfc include="reference.RFC.5392.xml"?>

      <?rfc include="reference.RFC.5693.xml"?>

      <?rfc include="reference.RFC.5706.xml"?>

      <?rfc include="reference.RFC.6549.xml"?>

      <?rfc include="reference.RFC.6952.xml"?>

      <?rfc include="reference.RFC.7285.xml"?>

      <?rfc include="reference.RFC.7752.xml"?>

      <?rfc include="reference.RFC.7911.xml"?>

      <?rfc include="reference.RFC.8202.xml"?>

      <?rfc include='reference.RFC.9029.xml'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5152.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9346.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5392.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5706.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6549.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7911.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8202.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9029.xml"/>
      </references>
    </references>
    <section anchor="CHANGES" title="Changes numbered="true" toc="default">
      <name>Changes from RFC 7752"> 7752</name>
      <t>This section lists the high-level changes from RFC 7752 and provides
      reference to the document sections wherein those have been
      introduced.</t>

      <t><list style="numbers">
          <t>Updated the
      <ol spacing="normal" type="1"><li>Updated <xref target="MECHANISM-OVERVIEW"/> target="MECHANISM-OVERVIEW" format="default"/> in <xref
          target="INTRO"/> target="INTRO" format="default"/> and added <xref target="ROLES"/> target="ROLES" format="default"/> to illustrate the
          different roles of a BGP implementation in conveying link-state
          information.</t>

          <t>Clarified
          information.</li>
        <li>Clarified aspects related to advertisement of link-state
          information from IGPs into BGP-LS in <xref target="IGPTOBGP"/>.</t>

          <t>In target="IGPTOBGP" format="default"/>.</li>
        <li>In <xref target="TLV-section"/>, clarification target="TLV-section" format="default"/>, clarified aspects about the TLV
          handling aspects that apply to both the NLRI and BGP-LS Attribute
          parts and as well as those that are applicable only for the NLRI portion. An
          implementation may have missed the part about the handling of an
          unknown TLV and so, based on <xref target="RFC7606"/> target="RFC7606" format="default"/> guidelines,
          might discard the unknown NLRI types. This aspect is now
          unambiguously clarified in <xref target="BGPLSNLRI"/>. target="BGPLSNLRI" format="default"/>. Also, the
          TLVs in the BGP-LS Attribute that are not ordered are not to be
          considered malformed.</t>

          <t>Clarification malformed.</li>
        <li>Clarified aspects of mandatory and optional TLVs in both NLRI and
          BGP-LS Attribute portions all through the document.</t>

          <t>Handling of large size document.</li>
        <li>In <xref target="BGPLSATTR" format="default"/>, the handling of a large-sized BGP-LS Attribute with growth in BGP-LS
          information is explained in <xref target="BGPLSATTR"/> along with
          mitigation of errors arising out of it.</t>

          <t>Clarified it.</li>
        <li>Clarified that the document describes the NLRI descriptor TLVs
          for the protocols and NLRI types specified in this document and as well as
          future BGP-LS extensions must describe the same for other protocols
          and NLRI types that they introduce.</t>

          <t>Clarification on introduce.</li>
        <li>In <xref target="BGPLSNLRI" format="default"/>, clarified the use of the Identifier field in the
          Link-State NLRI in <xref target="BGPLSNLRI"/> is provided. NLRI. It was
          defined ambiguously to refer to only multi-instance IGP on a single
          link while it can also be used for multiple IGP protocol instances
          on a router. The IANA registry is accordingly being removed.</t>

          <t>The removed.</li>
        <li>The BGP-LS Identifier TLV in the Node Descriptors has been
          deprecated. Its use was not well specified by <xref
          target="RFC7752"/> target="RFC7752" format="default"/>, and there has been some amount of confusion
          between implementators implementors on its usage for identification of IGP
          domains as against the use of the Identifier field carrying the
          BGP-LS Instance-ID when running multiple instances of IGP routing
          protocols. The original purpose of the BGP-LS Identifier was that,
          in conjunction with Autonomous System Number (ASN), the ASN, it would
          uniquely identify the BGP-LS domain and that the combination of ASN
          and BGP-LS ID would be globally unique. However, the BGP-LS
          Instance-ID carried in the Identifier field in the fixed part of the
          NLRI also provides a similar functionality. Hence, the inclusion of
          the BGP-LS Identifier TLV is not necessary. If advertised, all
          BGP-LS speakers Speakers within an IGP flooding-set (set of IGP nodes within
          which an LSP/LSA is flooded) had to use the same (ASN, BGP-LS ID)
          tuple
          tuple, and if an IGP domain consists of multiple flooding-sets, then
          all BGP-LS speakers Speakers within the IGP domain had to use the same (ASN,
          BGP-LS ID) tuple.</t>

          <t>Clarification tuple.</li>
        <li>Clarified that the Area-ID TLV is mandatory in the Node
          Descriptor for the origination of information from OSPF except for
          when sourcing information from AS-scope LSAs where this TLV is not
          applicable. Also clarified on the IS-IS area and area addresses.</t>

          <t>Moved addresses.</li>
        <li>Moved the MT-ID TLV from the Node Descriptor section to under the
          Link Descriptor section since it is not a Node Descriptor sub-TLV.
          Fixed the ambiguity in the encoding of OSPF MT-ID in this TLV.
          Updated the IS-IS specification reference section and describe described the
          differences in the applicability of the R flags when the MT-ID TLV is
          used as link descriptor the Link Descriptor TLV and Prefix Attribute TLV. The MT-ID TLV use
          is now elevated to SHOULD <bcp14>SHOULD</bcp14> when it is enabled in the underlying
          IGP.</t>

          <t>Clarified
          IGP.</li>
        <li>Clarified that IPv6 Link-Local Addresses link-local addresses are not advertised in
          the Link Descriptor TLVs and the local/remote identifiers are to be
          used instead for links with IPv6 link-local addresses only.</t>

          <t>Update only.</li>
        <li>Updated the usage of OSPF Route Type TLV to mandate its use for
          OSPF prefixes in <xref target="OSPFRTETYPE"/> target="OSPFRTETYPE" format="default"/> since this is required
          for segregation of intra-area prefixes that are used to reach a node
          (e.g.
          (e.g., a loopback) from other types of inter-area and external
          prefixes.</t>

          <t>Clarification of
          prefixes.</li>
        <li>Clarified the specific OSPFv2 and OSPFv3 protocol TLV
          space to be used in the node, link, Node, Link, and prefix opaque attribute
          TLVs.</t>

          <t>Clarification on Prefix Opaque Attribute
          TLVs.</li>
        <li>Clarified that the length of the Node Flag Bits and IGP Flags
          TLVs are to be one octet.</t>

          <t>Updated octet.</li>
        <li>Updated the Node Name TLV in <xref target="NODENAME"/> target="NODENAME" format="default"/> with the
          OSPF specification.</t>

          <t>Clarification on specification.</li>
        <li>Clarified the size of the IS-IS Narrow Metric
          advertisement via the IGP Metric TLV and the handling of the unused
          bits.</t>

          <t>Clarified
          bits.</li>
        <li>Clarified the advertisement of the prefix corresponding to the
          LAN segment in an OSPF network in <xref target="OSPFPN"/>.</t>

          <t>Clarified target="OSPFPN" format="default"/>.</li>
        <li>Clarified the advertisement and support for OSPF specific OSPF-specific
          concepts like Virtual virtual links, Sham sham links, and Type 4 LSAs in Sections <xref
          target="OSPFVL"/> target="OSPFVL" format="counter"/> and <xref target="OSPFTYPE4"/>.</t>

          <t>Introduced target="OSPFTYPE4" format="counter"/>.</li>
        <li>Introduced the Private Use TLV code point space and specified their
          encoding in <xref target="PRIVATE"/>.</t>

          <t>Introduced target="PRIVATE" format="default"/>.</li>
        <li>In <xref target="UNREACHNODES"/> target="UNREACHNODES" format="default"/>, introduced where issues related to
          the consistency of reporting IGP link-state along with their
          solutions are covered.</t>

          <t>Added covered.</li>
        <li>Added a recommendation for isolation of BGP-LS sessions from other
          BGP route exchange exchanges to avoid errors and faults in BGP-LS affecting
          the normal BGP routing.</t>

          <t>Updated routing.</li>
        <li>Updated the Fault Management section with detailed rules based on
          the role of the BGP Speaker in the BGP-LS information propagation
          flow.</t>

          <t>Change to
          flow.</li>
        <li>Changed the management of BGP-LS IANA registries from
          "Specification Required" to "Expert Review" along with updated
          guidelines for Designated Experts. More specifically designated experts, more specifically, the inclusion
          of changes introduced via <xref target="RFC9029"/> target="RFC9029" format="default"/> that is are obsoleted
          by this document.</t>

          <t>Added document.</li>
        <li>Added BGP-LS IANA registries with "Expert Review" policy for the
          flag fields of various TLVs that was missed out. Renamed the BGP-LS
          TLV registry and removed the "IS-IS TLV/Sub-TLV" column from it.</t>
        </list></t>

      <t/> it.</li>
      </ol>
    </section>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>This document update to the BGP-LS specification <xref target="RFC7752" format="default"/> is a result of feedback and input from the
      discussions in the IDR Working Group. It also incorporates certain
      details and clarifications based on implementation and deployment
      experience with BGP-LS.</t>
      <t><contact fullname="Cengiz Alaettinoglu"/> and <contact fullname="Parag Amritkar"/> brought forward the need to
      clarify the advertisement of a LAN subnet for OSPF.</t>
      <t>We would like to thank <contact fullname="Balaji Rajagopalan"/>, <contact fullname="Srihari Sangli"/>, <contact fullname="Shraddha Hegde"/>,
      <contact fullname="Andrew Stone"/>, <contact fullname="Jeff Tantsura"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Les Ginsberg"/>, <contact fullname="Jie Dong"/>,
      <contact fullname="Aijun Wang"/>, <contact fullname="Nandan Saha"/>, <contact fullname="Joel Halpern"/>, and <contact fullname="Gyan Mishra"/> for their review
      and feedback on this document. Thanks to <contact fullname="Tom Petch"/> for his review and
      comments on the IANA Considerations section. We would also like to thank
      <contact fullname="Jeffrey Haas"/> for his detailed shepherd review and input for improving
      the document.</t>
      <t>The detailed AD review by <contact fullname="Alvaro Retana"/> and his suggestions have
      helped improve this document significantly.</t>
      <t>We would like to thank Robert Varga for his significant contribution
      to <xref target="RFC7752"/>.</t>
      <t>We would like to thank <contact fullname="Nischal Sheth"/>, <contact fullname="Alia Atlas"/>, <contact fullname="David Ward"/>, <contact fullname="Derek Yeung"/>,
      <contact fullname="Murtuza Lightwala"/>, <contact fullname="John Scudder"/>, <contact fullname="Kaliraj Vairavakkalai"/>, <contact fullname="Les Ginsberg"/>,
      <contact fullname="Liem Nguyen"/>, <contact fullname="Manish Bhardwaj"/>, <contact fullname="Matt Miller"/>, <contact fullname="Mike Shand"/>, <contact fullname="Peter Psenak"/>,
      <contact fullname="Rex Fernando"/>, <contact fullname="Richard Woundy"/>, <contact fullname="Steven Luong"/>, <contact fullname="Tamas Mondal"/>, <contact fullname="Waqas Alam"/>,
      <contact fullname="Vipin Kumar"/>, <contact fullname="Naiming Shen"/>, <contact fullname="Carlos Pignataro"/>, <contact fullname="Balaji Rajagopalan"/>,
      <contact fullname="Yakov Rekhter"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Barry Leiba"/>, and <contact fullname="Ben Campbell"/> for their
      comments on <xref target="RFC7752"/>.</t>
    </section>
    <section anchor="Contributors" numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following persons contributed significant text to <xref target="RFC7752"/> and
      this document. They should be considered coauthors.</t>
      <contact fullname="Hannes Gredler">
	<organization>Rtbrick</organization>
	<address>
	  <email>hannes@rtbrick.com</email>
	</address>
      </contact>
      <contact fullname="Jan Medved">
	<organization>Cisco Systems Inc.</organization>
	<address>
	  <postal>
	    <country>United States of America</country>
	  </postal>
	  <email>jmedved@cisco.com</email>
	</address>
      </contact>
      <contact fullname="Stefano Previdi">
	<organization>Huawei Technologies</organization>
	<address>
	  <postal>
	    <country>Italy</country>
	  </postal>
	  <email>stefano@previdi.net</email>
	</address>
      </contact>
      <contact fullname="Adrian Farrel">
	<organization>Old Dog Consulting</organization>
	<address>
	  <email>adrian@olddog.co.uk</email>
	</address>
      </contact>
      <contact fullname="Saikat Ray">
	<organization>Individual</organization>
	<address>
	  <postal>
	    <country>United States of America</country>
	  </postal>
	  <email>raysaikat@gmail.com</email>
	</address>
      </contact>
    </section>
  </back>
</rfc>