<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfcSYSTEM "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 " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <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-StateInfoInformation 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 obsoletesRFC7752RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletesRFC9029RFC 9029 by incorporating the updates that it made toRFC7752.</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) <xreftarget="RFC4655"/>target="RFC4655" format="default"/> as a mechanism for achieving the computation of end-to-end TE paths thatcrosscrosses the visibility of more than one TED or that requires CPU-intensive or coordinated computations. The IETF has also defined the ALTO server <xreftarget="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 <xreftarget="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 BGPLink-State- Link State (BGP-LS) process can retrieve topology from these LSDBs and distribute it to a consumer, either directly or via a peer BGPspeakerSpeaker (typically a dedicatedRoute 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 <xreftarget="MECHANISM-OVERVIEW"/>target="MECHANISM-OVERVIEW" format="default"/> below.</t> <figureanchor="MECHANISM-OVERVIEW" title="Collectionanchor="MECHANISM-OVERVIEW"> <name>Collection of Link-State and TEInformation"> <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 BGPspeakerSpeaker 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 BGPspeakerSpeaker 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 <xreftarget="RFC7752"/>target="RFC7752" format="default"/> by completely replacing that document. It makes some small changes and clarifications to the previous specification as documented in <xreftarget="CHANGES"/>.</t>target="CHANGES" format="default"/>.</t> <sectiontitle="Requirements Language"> <t>Thenumbered="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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section anchor="APPL"title="Motivationnumbered="true" toc="default"> <name>Motivation andApplicability">Applicability</name> <t>This section describes use cases from which the requirements can be derived.</t> <section anchor="PCE"title="MPLS-TEnumbered="true" toc="default"> <name>MPLS-TE withPCE">PCE</name> <t>As described in <xreftarget="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 wholearea.</t> <t>Ifarea.</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 ofMPLS-TE.</t> </list></t>MPLS-TE.</li> </ul> <t>Previous solutions used per-domain path computation <xreftarget="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 thepath,path but not for subsequent areas. Per-domain path computationuses a technique called "loose-hop-expansion" <xref target="RFC3209"/> andselects 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 orAS,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 <xreftarget="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 besub-optimalsuboptimal 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> <figureanchor="PCE-REFERENCE" title="Externalanchor="PCE-REFERENCE"> <name>External PCE Node Using a TED SynchronizationMechanism"> <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="ALTOnumbered="true" toc="default"> <name>ALTO Server NetworkAPI">API</name> <t>An ALTO server <xreftarget="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 <xreftarget="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 BGPspeakers.</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> <figureanchor="ALTO-REFERENCE" title="ALTOanchor="ALTO-REFERENCE"> <name>ALTO Server Using Network TopologyInformation"> <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="BGPnumbered="true" toc="default"> <name>BGP Speaker Roles forBGP-LS">BGP-LS</name> <t>Inthe illustration shown in<xreftarget="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 Speakerswhichthat are then usedthroughthroughout 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.TheBGP 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 nodeinformation.</t> <t>BGP-LS Consumer: Theinformation.</dd> <dt>BGP-LS Consumer:</dt> <dd>The term BGP-LS Consumer refers to a consumer application/process and not a BGP Speaker.TheBGP 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 informationMUST<bcp14>MUST</bcp14> be unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumerapplication)application), and a BGP-LS ConsumerMUST NOT<bcp14>MUST NOT</bcp14> be able to send information to a BGP Speaker for origination intoBGP-LS.</t> <t>BGP-LS Propagator: TheBGP-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.TheBGP Speaker RRm propagates the BGP-LS information betweentheBGP Speaker Rn andtheBGP 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,theBGP Speaker RR1 is receiving BGP-LS information from R1, R2, and RRm and propagating the information to the BGP-LS Consumer after performing BGP DecisionProcess.</t> </list>TheProcess.</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="Advertisingnumbered="true" toc="default"> <name>Advertising IGP Information intoBGP-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 IGPspecificsspecifics, 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 OSPFLink StateLink-State Advertisements (LSAs) or the IS-ISLink StateLink-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 scopedlink-local-scoped information, etc.). The LSAs/LSPs that are purged ormax-agedaged 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="Carryingnumbered="true" toc="default"> <name>Carrying Link-State Information inBGP">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 prefixobject,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 prefixmetric ormetric, 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 anIGP- neutralIGP-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 <xreftarget="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 typesMUST<bcp14>MUST</bcp14> be preserved and propagated within both the NLRI and the BGP-LS Attribute. The presence of unknown or unexpected TLVsMUST 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 alink statelink-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 NLRIMUST<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 typeMUST<bcp14>MUST</bcp14> be first in ascending order based on thelengthLength field followed by ascending order based on thevalueValue field. Comparison of thevalueValue 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 TLVswhichthat do not follow the above ordering rulesMUST<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 AttributeSHOULD<bcp14>SHOULD</bcp14> be ordered in ascending order by TLV type. The BGP-LS Attribute with unordered TLVsMUST 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 duplicateinformation,information ortodeal 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="Thenumbered="true" toc="default"> <name>The Link-StateNLRI">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 informationSHALL<bcp14>SHALL</bcp14> be encoded using AFI 16388 / SAFI 71. VPN link, node, and prefix informationSHALL<bcp14>SHALL</bcp14> be encoded using AFI 16388 / SAFI 72.</t> <t>For two BGPspeakersSpeakers to exchange Link-State NLRI, theyMUST<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 <xreftarget="RFC4760"/>,target="RFC4760" format="default"/> by using capability code 1 (multiprotocol BGP), with AFI 16388 / SAFI 71 forBGP-LS,BGP-LS and AFI 16388 / SAFI 72 forBGP&nbhy;LS&nbhy;VPN.</t>BGP-LS-VPN.</t> <t>New Link-State NLRITypestypes 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 <xreftarget="RFC4760"/>,target="RFC4760" format="default"/>, it is possible that a BGPspeakerSpeaker 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 thefuture,future without the need for upgrading all BGPspeakersSpeakers in the propagation path (e.g., a route reflector), this document deviates from the default handling behavior specified bysection 5.4Section <xref target="RFC7606" format="default" sectionFormat="bare" section="5.4"/> (paragraph 2) of <xref target="RFC7606"/> for Link-Stateaddress-family.address family. An implementationMUST<bcp14>MUST</bcp14> handle unknown Link-State NLRI types as opaque objects andMUST<bcp14>MUST</bcp14> preserve and propagate them.</t> <t>The format of the Link-State NLRI is shown in the following figures.</t> <figureanchor="LSSAFI" title="Link-Stateanchor="LSSAFI"> <name>Link-State AFI 16388 / SAFI 71 NLRIFormat"> <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> <figureanchor="LSVPNSAFI" title="Link-Stateanchor="LSVPNSAFI"> <name>Link-State VPN AFI 16388 / SAFI 72 NLRIFormat"> <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> <ttcolalign="center"> <name>NLRI Types</name> <thead> <tr> <th align="center">Type</th> <th align="left">NLRIType</ttcol> <c>1</c> <c>Node NLRI</c> <c>2</c> <c>Link NLRI</c> <c>3</c> <c>IPv4Type</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 PrefixNLRI</c> <c>4</c> <c>IPv6NLRI</td> </tr> <tr> <td align="center">4</td> <td align="left">IPv6 Topology PrefixNLRI</c> </texttable>NLRI</td> </tr> </tbody> </table> <t>Route Distinguishers are defined and discussed in <xreftarget="RFC4364"/>.</t>target="RFC4364" format="default"/>.</t> <t>The Node NLRI (NLRI Type = 1) is shown in the following figure.</t> <figureanchor="NODE-NLRI" title="Theanchor="NODE-NLRI"> <name>The Node NLRIFormat"> <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> <figureanchor="LINK-NLRI" title="Theanchor="LINK-NLRI"> <name>The Link NLRIFormat"> <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 sameformat,format as shown in the following figure.</t> <figureanchor="PREFIX-NLRI" title="Theanchor="PREFIX-NLRI"> <name>The IPv4/IPv6 Topology Prefix NLRIFormat"> <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> <ttcolalign="center"> <name>Protocol Identifiers</name> <thead> <tr> <th align="center">Protocol-ID</th> <th align="left">NLRI information sourceprotocol</ttcol> <c>1</c> <c>IS-ISprotocol</th> </tr> </thead> <tbody> <tr> <td align="center">1</td> <td align="left">IS-IS Level1</c> <c>2</c> <c>IS-IS1</td> </tr> <tr> <td align="center">2</td> <td align="left">IS-IS Level2</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 typesSHOULD<bcp14>SHOULD</bcp14> be used when BGP-LS is sourcing local information. For all information derived from other protocols, the corresponding Protocol-IDMUST<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 <xreftarget="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 <xreftarget="RFC8202"/>target="RFC8202" format="default"/> and <xreftarget="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 isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to be used when there is only a single protocol instance in the network where BGP-LS is operational. The network operatorMUST<bcp14>MUST</bcp14> assign the same BGP-LS Instance-IDs on all BGP-LS Producers within a given IGP domain. Unique BGP-LSInstance-ID MUSTInstance-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-stateobjectsobject 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 <xreftarget="PROTOCOL-IDS"/>.target="PROTOCOL-IDS" format="default"/>. Documents extending BGP-LS specifications with new NLRI Types and/or protocolsMUST<bcp14>MUST</bcp14> specify the NLRIDescriptorsdescriptors for them.</t> <t>When adding, removing, or modifying a TLV/sub-TLV from a Link-State NLRI, the BGP-LS ProducerMUST<bcp14>MUST</bcp14> withdraw the old NLRI by including it in the MP_UNREACH_NLRI. Not doing so can result in duplicate andin-consistentinconsistent 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 <xreftarget="RFC5305"/>target="RFC5305" format="default"/> <xreftarget="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 <xreftarget="NODEATTR"/>target="NODEATTR" format="default"/> andMAY<bcp14>MAY</bcp14> be included in the link attribute described in <xreftarget="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 <xreftarget="RFC1918"/>.target="RFC1918" format="default"/>. BGP-LS uses the Autonomous System(AS)Number to disambiguate the Router-IDs, as described in <xreftarget="gbl_uniqueness"/>.</t>target="gbl_uniqueness" format="default"/>.</t> <section anchor="gbl_uniqueness"title="Globallynumbered="true" toc="default"> <name>Globally Unique Node/Link/PrefixIdentifiers">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-LSspeakersSpeakers 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 nodeMUST NOT<bcp14>MUST NOT</bcp14> be represented by two keys (otherwise, one node will look like twonodes).</t> <t hangText="(B)">Twonodes).</li> <li>Two different nodesMUST NOT<bcp14>MUST NOT</bcp14> be represented by the same key (otherwise, two nodes will look like onenode).</t> </list></t>node).</li> </ol> <t>We define an "IGP domain" to be the set of nodes (hence, byextensionextension, 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-TopologyID,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 frommultiple-ASes,multiple ASes, theASAutonomous System Number (ASN) is used to distinguish topology information reported from different ASes.</t> <t>The BGP-LS Instance-ID carried in the Identifierfieldfield, as described earlier along with a set of sub-TLVs described in <xreftarget="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="Localnumbered="true" toc="default"> <name>Local NodeDescriptors">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 DescriptorSub-TLVssub-TLVs defined in <xreftarget="node_desc_tlvs"/>.</t>target="node_desc_tlvs" format="default"/>.</t> <figureanchor="LOCALNODEDESCTLV" title="Localanchor="LOCALNODEDESCTLV"> <name>Local Node Descriptors TLVFormat"> <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="Remotenumbered="true" toc="default"> <name>Remote NodeDescriptors">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. ThetypeType is 257. The length of this TLV is variable. The value contains one or more Node DescriptorSub-TLVssub-TLVs defined in <xreftarget="node_desc_tlvs"/>.</t>target="node_desc_tlvs" format="default"/>.</t> <figureanchor="REMOTENODEDESCTLV" title="Remoteanchor="REMOTENODEDESCTLV"> <name>Remote Node Descriptors TLVFormat"> <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="Nodenumbered="true" toc="default"> <name>Node DescriptorSub-TLVs">Sub-TLVs</name> <t>The Node DescriptorSub-TLVsub-TLV type code points and lengths are listed in the following table:</t><texttable<table anchor="table_local_anchor_node_tlv"title="Nodealign="center"> <name>Node DescriptorSub-TLVs"> <ttcolSub-TLVs</name> <thead> <tr> <th align="center">Sub-TLV CodePoint</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-LSPoint</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 valueSHOULD<bcp14>SHOULD</bcp14> be set to the AS Number associated with the BGP process originating the link-state information. An implementationMAY<bcp14>MAY</bcp14> provide a configuration option on the BGP-LS Producer to use a differentvalue;value, e.g., to avoid collisions when using private ASnumbers.</t> <t hangText="BGP-LS Identifier:">OpaqueNumbers.</dd> <dt>BGP-LS Identifier:</dt> <dd>Opaque value (32-bit ID). This is an optional TLVwhichthat has been deprecated by this document (refer to <xreftarget="CHANGES"/>target="CHANGES" format="default"/> for more details). ItMAY<bcp14>MAY</bcp14> be advertised for compatibility with <xreftarget="RFC7752"/>target="RFC7752" format="default"/> implementations. See the final paragraph of this section for further considerations and a recommended defaultvalue.</t> <t hangText="OSPF Area-ID:">Usedvalue.</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 specificarea.</t> <t hangText="IGP Router-ID:">Opaquearea.</dd> <dt>IGP Router-ID:</dt> <dd>Opaque value. This is a mandatory TLV when originating information from IS-IS, OSPF,direct'Direct', orstatic.'Static configuration'. For an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISOsystem-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. ForDirect'Direct' orStatic configuration,'Static configuration', the valueSHOULD<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 implementationMAY<bcp14>MAY</bcp14> choose to use the IGP Router-ID fordirect'Direct' orstatic.</t> </list></t> <t>There MUST'Static configuration'.</dd> </dl> <t>At most, there <bcp14>MUST</bcp14> beat mostone instance of each sub-TLV type present in any Node Descriptor. The sub-TLVs within a Node DescriptorMUST<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 <xreftarget="RFC7752"/>target="RFC7752" format="default"/>, and its use is being deprecated by this document. ImplementationsSHOULD<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 <xreftarget="RFC7752"/>target="RFC7752" format="default"/> to ensure consistency of NLRI encoding for link-state objects. The default value of 0 isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to be used when a BGP-LS Producer includes this sub-TLV when originating information into BGP-LS. ImplementationsSHOULD<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 <xreftarget="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 implementationMAY<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 thoseLink Statelink-state IGP adjacencieswhichthat are established get reported via Link NLRIs. Such a 'two-way connectivity check' couldbealso 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 ofvalueValue fields in IS-IS Extended IS Reachability sub-TLVs, which are defined in <xreftarget="RFC5305"/>,target="RFC5305" format="default"/>, <xreftarget="RFC5307"/>,target="RFC5307" format="default"/>, and <xreftarget="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="Linkalign="center"> <name>Link DescriptorTLVs"> <ttcolTLVs</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcol align="left">Description</ttcol> <ttcolPoint</th> <th align="left">Description</th> <th align="center">IS-ISTLV/Sub-TLV</ttcol> <ttcol align="left">Reference (RFC/Section)</ttcol> <c>258</c> <c>LinkTLV/Sub-TLV</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">258</td> <td align="left">Link Local/RemoteIdentifiers</c> <c>22/4</c> <c><xref target="RFC5307"/> / 1.1</c> <c>259</c> <c>IPv4Identifiers</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 interfaceaddress</c> <c>22/6</c> <c><xref target="RFC5305"/> / 3.2</c> <c>260</c> <c>IPv4address</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 neighboraddress</c> <c>22/8</c> <c><xref target="RFC5305"/> / 3.3</c> <c>261</c> <c>IPv6address</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 interfaceaddress</c> <c>22/12</c> <c><xref target="RFC6119"/> / 4.2</c> <c>262</c> <c>IPv6address</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 neighboraddress</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 TLVsMUST<bcp14>MUST</bcp14> be included, and the Link Local/Remote Identifiers TLVMUST NOT<bcp14>MUST NOT</bcp14> be included in the Link Descriptor. The Link Local/Remote Identifiers TLVMAY<bcp14>MAY</bcp14> be included in the link attribute when available. IPv4/IPv6 link-local addressesMUST NOT<bcp14>MUST NOT</bcp14> be carried in the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262) as descriptors of a linkassince 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 TLVMUST<bcp14>MUST</bcp14> be included in the Link Descriptor. The Link Local/RemoteIdentifiers MUSTidentifiers <bcp14>MUST</bcp14> be included in the Link Descriptoralsoand in the case of links having only IPv6 link-local addressing on them.</t><t>The<t indent="3">The Multi-Topology Identifier TLVMUST<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-TopologyIDIdentifier (MT-ID) TLV carries one or more IS-IS or OSPF Multi-TopologyIDsIdentifiers for a link, node, or prefix.</t> <t>The semantics of the IS-IS MT-ID are defined insections 7.1Sections <xref target="RFC5120" section="7.1" sectionFormat="bare"/> and7.2<xref target="RFC5120" section="7.2" sectionFormat="bare"/> of <xreftarget="RFC5120"/>.target="RFC5120" format="default"/>. The semantics of the OSPF MT-ID are defined insection 3.7 of<xreftarget="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 fieldMUST<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 TLVFormat"> <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,Lengththe length is 2*n, and n is the number of MT-IDs carried in the TLV.</t> <t>The MT-ID TLVMAY<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 LinkDescriptoror Prefix Descriptor, multiple NLRIsMUST<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 andMUST<bcp14>MUST</bcp14> be set to 0 (as persection 7.2 of<xreftarget="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 persection 7.1 of<xreftarget="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="Prefixalign="center"> <name>Prefix DescriptorTLVs"> <ttcolTLVs</name> <thead> <tr> <th align="center">TLV CodePoint</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>OSPFPoint</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 RouteType</c> <c>1</c> <c><xref target="OSPFRTETYPE"/></c> <c>265</c> <c>IPType</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 ReachabilityInformation</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 TLVMUST<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="OSPFnumbered="true" toc="default"> <name>OSPF RouteType">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 prefixMAY<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 TLVMUST<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 <xreftarget="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 andNSSANot-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> <figureanchor="ROUTETYPETLV" title="OSPFanchor="ROUTETYPETLV"> <name>OSPF Route Type TLVFormat"> <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 <xreftarget="table_prefix_descriptor_tlv"/>.target="table_prefix_descriptor_tlv" format="default"/>. TheOSPFRoute 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="IPnumbered="true" toc="default"> <name>IP ReachabilityInformation">Information</name> <t>The IP Reachability Information TLV is a mandatory TLV for IPv4 & IPv6 Prefix NLRI types. The TLV contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP topology. A routerSHOULD<bcp14>SHOULD</bcp14> advertise an IP Prefix NLRI for each of its BGPnext-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 TLVFormat"> <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 <xreftarget="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 addressprefix,prefix followed by the minimum number of trailing bits needed to make the end of the field fall on an octet boundary. Any trailing bitsMUST<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="Thenumbered="true" toc="default"> <name>The BGP-LSAttribute">Attribute</name> <t>The BGP-LS Attribute (assigned value 29 by IANA) is an optional, non-transitive BGPattributeAttribute 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 attributeSHOULD<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 growlargelarge, depending on the amount of link-state information associated with a single Link-State NLRI. The BGP specification <xreftarget="RFC4271"/>target="RFC4271" format="default"/> mandates a maximum BGP message size of 4096 octets. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that an implementation supports <xreftarget="RFC8654"/>target="RFC8654" format="default"/> to accommodate a larger size of information within the BGP-LS Attribute. BGP-LS ProducersMUST<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 implementationMAY<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 exclusionSHOULD<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 BGPdecision processDecision 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), itMUST<bcp14>MUST</bcp14> consider the BGP-LS Attribute to be malformed, apply the"Attribute Discard"'Attribute Discard' error-handling approach <xreftarget="RFC7606"/>,target="RFC7606" format="default"/>, and handle the propagation as described in <xreftarget="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 insection 4 of<xreftarget="RFC8654"/>,target="RFC8654" section="4" sectionFormat="of" format="default"/>, itMUST<bcp14>MUST</bcp14> first discard the BGP-LS Attribute to enable the detection and diagnosis of this error condition as discussed in <xreftarget="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 <xreftarget="RFC8654"/>.</t>target="RFC8654" format="default"/>.</t> <section anchor="NODEATTR"title="Nodenumbered="true" toc="default"> <name>Node AttributeTLVs">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="Nodealign="center"> <name>Node AttributeTLVs"> <ttcolTLVs</name> <thead> <tr> <th align="center">TLV CodePoint</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>NodePoint</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 FlagBits</c> <c>1</c> <c><xref target="NODEFLAGBITS"/></c> <c>1025</c> <c>OpaqueBits</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 NodeAttribute</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-ISAttribute</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 AreaIdentifier</c> <c>variable</c> <c><xref target="ISISAREA"/></c> <c>1028</c> <c>IPv4Identifier</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 LocalNode</c> <c>4</c> <c><xref target="RFC5305"/> / 4.3</c> <c>1029</c> <c>IPv6Node</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 LocalNode</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="Nodenumbered="true" toc="default"> <name>Node Flag BitsTLV">TLV</name> <t>The Node Flag Bits TLV carries a bitmask describing node attributes. The value is a1 octet length1-octet-length bit array of flags, where each bit represents anode operationalnode-operational state or attribute.</t> <figureanchor="node_flag_bits" title="Nodeanchor="node_flag_bits"> <name>Node Flag Bits TLVFormat"> <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="Nodealign="center"> <name>Node Flag BitsDefinitions"> <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 definedMUST<bcp14>MUST</bcp14> be set to 0 by the originator andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </section> <section anchor="ISISAREA"title="IS-ISnumbered="true" toc="default"> <name>IS-IS Area IdentifierTLV">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> <figureanchor="ISISAREAIDTLV" title="IS-ISanchor="ISISAREAIDTLV"> <name>IS-IS Area Identifier TLVFormat"> <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="Nodenumbered="true" toc="default"> <name>Node NameTLV">TLV</name> <t>The Node Name TLV is optional. The encoding semantics for the node name has been borrowed from <xreftarget="RFC5301"/>.target="RFC5301" format="default"/>. The Value field identifies the symbolic name of the router node. This symbolic name caneitherbe the Fully Qualified Domain Name (FQDN) for the router,or it can bea substring of the FQDN (e.g., a hostname), orit can beany string that an operator wants to use for the router. The use of the FQDN or a substring of it is stronglyRECOMMENDED.<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,thatthen the user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in <xreftarget="RFC5890"/>target="RFC5890" format="default"/> to achieve the correct format for transmission or display.</t> <t><xreftarget="RFC5301"/>target="RFC5301" format="default"/> describes an IS-IS-specificextensionextension, and <xreftarget="RFC5642"/>target="RFC5642" format="default"/> describes an OSPF extension for the advertisement ofNode Namethe node name, which may be encoded in the Node Name TLV.</t> <figureanchor="optional-node-name-tlv" title="Nodeanchor="optional-node-name-tlv"> <name>Node NameFormat"> <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="Localnumbered="true" toc="default"> <name>Local IPv4/IPv6 Router-IDTLVs">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="Opaquenumbered="true" toc="default"> <name>Opaque Node AttributeTLV">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 TLVMUST NOT<bcp14>MUST NOT</bcp14> be used to advertise TLVs other than those in the OSPF Router Information (RI) LSA <xreftarget="RFC7770"/>.</t>target="RFC7770" format="default"/>.</t> <figureanchor="optional_opaque_node-attribute_tlv" title="Opaqueanchor="optional_opaque_node-attribute_tlv"> <name>Opaque Node AttributeFormat"> <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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Opaquenode attributesNode Attributes (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t>ThetypeType is as specified in <xreftarget="node-attribute_tlv"/>. Lengthtarget="node-attribute_tlv" format="default"/>. The length is variable.</t> </section> </section> <section anchor="link_attribute"title="Linknumbered="true" toc="default"> <name>Link AttributeTLVs">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 <xreftarget="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 <xreftarget="RFC5305"/>target="RFC5305" format="default"/> and <xreftarget="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="Linkalign="center"> <name>Link AttributeTLVs"> <ttcolTLVs</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcol align="left">Description</ttcol> <ttcolPoint</th> <th align="left">Description</th> <th align="center">IS-ISTLV/Sub-TLV</ttcol> <ttcol align="left">Reference (RFC/Section)</ttcol> <c>1028</c> <c>IPv4TLV/Sub-TLV</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">1028</td> <td align="left">IPv4 Router-ID of LocalNode</c> <c>134/---</c> <c><xref target="RFC5305"/> / 4.3</c> <c>1029</c> <c>IPv6Node</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 LocalNode</c> <c>140/---</c> <c><xref target="RFC6119"/> / 4.1</c> <c>1030</c> <c>IPv4Node</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 RemoteNode</c> <c>134/---</c> <c><xref target="RFC5305"/> / 4.3</c> <c>1031</c> <c>IPv6Node</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 RemoteNode</c> <c>140/---</c> <c><xref target="RFC6119"/> / 4.1</c> <c>1088</c> <c>AdministrativeNode</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 linkbandwidth</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 linkbandwidth</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>TEbandwidth</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 DefaultMetric</c> <c>22/18</c> <c><xref target="TEDEFAULTMETTLV"/></c> <c>1093</c> <c>LinkMetric</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 ProtectionType</c> <c>22/20</c> <c><xref target="RFC5307"/> / 1.2</c> <c>1094</c> <c>MPLSType</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 ProtocolMask</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>SharedMask</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 LinkGroup</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/IPv6numbered="true" toc="default"> <name>IPv4/IPv6 Router-IDTLVs">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 nodeMUST<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="MPLSnumbered="true" toc="default"> <name>MPLS Protocol MaskTLV">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 andSHOULD<bcp14>SHOULD</bcp14> only be used with originators that have local link insight, for example, the Protocol-IDs 'Static configuration' or 'Direct' as per <xreftarget="PROTOCOL-IDS"/>.target="PROTOCOL-IDS" format="default"/>. The MPLS Protocol Mask TLVMUST NOT<bcp14>MUST NOT</bcp14> be included in NLRIs with the other Protocol-IDs listed in <xreftarget="PROTOCOL-IDS"/>.</t>target="PROTOCOL-IDS" format="default"/>.</t> <figureanchor="MPLSPROTO" title="MPLSanchor="MPLSPROTO"> <name>MPLS Protocol MaskTLV"> <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 bitsMUST<bcp14>MUST</bcp14> be set to zero andSHOULD<bcp14>SHOULD</bcp14> be ignored on receipt:</t><texttable<table anchor="table_mpls_protocols_tlv"title="MPLSalign="center"> <name>MPLS Protocol Mask TLVCodes"> <ttcol align="center">Bit</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="left">Reference</ttcol> <c>'L'</c> <c>LabelCodes</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 definedMUST<bcp14>MUST</bcp14> be set to 0 by the originator andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </section> <section anchor="TEDEFAULTMETTLV"title="TEnumbered="true" toc="default"> <name>TE Default MetricTLV">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 fieldMUST<bcp14>MUST</bcp14> be padded with zero.</t> <figureanchor="TEDEFAULTMET" title="TEanchor="TEDEFAULTMET"> <name>TE Default Metric TLVFormat"> <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="IGPnumbered="true" toc="default"> <name>IGP MetricTLV">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 areof 6-bit size,6 bits in size but are encoded in a1 octet1-octet field;thereforetherefore, the two most significant bits of the fieldMUST<bcp14>MUST</bcp14> be set to 0 by the originator andMUST<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> <figureanchor="MET" title="IGPanchor="MET"> <name>IGP Metric TLVFormat"> <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="Sharednumbered="true" toc="default"> <name>Shared Risk Link GroupTLV">TLV</name> <t>The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link Group information (see Section2.3 ("Shared<xref target="RFC4202" section="2.3" sectionFormat="bare">"Shared Risk Link GroupInformation")Information"</xref> of <xreftarget="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 <xreftarget="SRLG"/>.target="SRLG" format="default"/>. The length of this TLV is 4 * (number of SRLG values).</t> <figureanchor="SRLG" title="Sharedanchor="SRLG"> <name>Shared Risk Link Group TLVFormat"> <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 <xreftarget="RFC4203"/>.target="RFC4203" format="default"/>. In IS-IS, the SRLG information is carried in two different TLVs: theIPv4 (SRLG)GMPLS-SRLG TLV (for IPv4) (Type 138) defined in <xreftarget="RFC5307"/>target="RFC5307" format="default"/> and the IPv6 SRLG TLV (Type 139) defined in <xreftarget="RFC6119"/>.target="RFC6119" format="default"/>. Both IPv4 and IPv6 SRLG information is carried in a single TLV.</t> </section> <section anchor="OPAQUELINK"title="Opaquenumbered="true" toc="default"> <name>Opaque Link AttributeTLV">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 TLVMUST NOT<bcp14>MUST NOT</bcp14> be used to advertise information carried using TLVs other than those in the OSPFv2 Extended Link Opaque LSA <xreftarget="RFC7684"/>.target="RFC7684" format="default"/>. In the case of OSPFv3, this TLVMUST NOT<bcp14>MUST NOT</bcp14> be used to advertise TLVs other than those in the OSPFv3 E-Router-LSA or E-Link-LSA <xreftarget="RFC8362"/>.</t>target="RFC8362" format="default"/>.</t> <figureanchor="OPAQUELINKTLV" title="Opaqueanchor="OPAQUELINKTLV"> <name>Opaque Link Attribute TLVFormat"> <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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Opaquelink attributesLink Attributes (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </section> <section anchor="LINKNAME"title="Linknumbered="true" toc="default"> <name>Link NameTLV">TLV</name> <t>The Link Name TLV is optional. The Value field identifies the symbolic name of the router link. This symbolic name caneitherbe the FQDN for the link,or it can bea substring of the FQDN, orit can beany string that an operator wants to use for the link. The use of the FQDN or a substring of it is stronglyRECOMMENDED.<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,thatthen the user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in <xreftarget="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> <figureanchor="optional-link-name-tlv" title="Linkanchor="optional-link-name-tlv"> <name>Link Name TLVFormat"> <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="Prefixnumbered="true" toc="default"> <name>Prefix AttributeTLVs">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="Prefixalign="center"> <name>Prefix AttributeTLVs"> <ttcolTLVs</name> <thead> <tr> <th align="center">TLV CodePoint</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>IGPPoint</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 RouteTag</c> <c>4*n</c> <c><xref target="RFC5130"/></c> <c>1154</c> <c>IGPTag</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 RouteTag</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>OSPFTag</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 ForwardingAddress</c> <c>4</c> <c><xref target="RFC2328"/></c> <c>1157</c> <c>OpaqueAddress</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 PrefixAttribute</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="IGPnumbered="true" toc="default"> <name>IGP FlagsTLV">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> <figureanchor="IGPFLAGSTLV" title="IGPanchor="IGPFLAGSTLV"> <name>IGP Flag TLVFormat"> <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="IGPalign="center"> <name>IGP Flag BitsDefinitions"> <ttcol align="center">Bit</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="left">Reference</ttcol> <c>'D'</c> <c>IS-ISDefinitions</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/DownBit</c> <c><xref target="RFC5305"/></c> <c>'N'</c> <c>OSPFBit</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>OSPFBit</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>OSPFBit</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 definedMUST<bcp14>MUST</bcp14> be set to 0 by the originator andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </section> <section anchor="route_tag"title="IGPnumbered="true" toc="default"> <name>IGP Route TagTLV">TLV</name> <t>The IGP Route Tag TLV carries original IGP Tags (IS-IS <xreftarget="RFC5130"/>target="RFC5130" format="default"/> or OSPF) of the prefix and is encoded as follows:</t> <figureanchor="IGPROUTETAG" title="IGPanchor="IGPROUTETAG"> <name>IGP Route Tag TLVFormat"> <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 IGPnumbered="true" toc="default"> <name>IGP Extended Route TagTLV">TLV</name> <t>TheExtendedIGP Extended Route Tag TLV carries IS-IS Extended Route Tags of the prefix <xreftarget="RFC5130"/>target="RFC5130" format="default"/> and is encoded as follows:</t> <figureanchor="IGPEXTROUTETAG" title="Extended IGPanchor="IGPEXTROUTETAG"> <name>IGP Extended Route Tag TLVFormat"> <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="Prefixnumbered="true" toc="default"> <name>Prefix MetricTLV">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 IGPtopologytopology, as described inSection 4 of<xreftarget="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 TLVFormat"> <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="OSPFnumbered="true" toc="default"> <name>OSPF Forwarding AddressTLV">TLV</name> <t>The OSPF Forwarding Address TLV <xreftarget="RFC2328"/>target="RFC2328" format="default"/> <xreftarget="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> <figureanchor="OSPFFORWADDR" title="OSPFanchor="OSPFFORWADDR"> <name>OSPF Forwarding Address TLVFormat"> <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 forwardingaddress,address and 16 for an IPv6 forwarding address.</t> </section> <section anchor="OPAQUEPREFIX"title="Opaquenumbered="true" toc="default"> <name>Opaque Prefix AttributeTLV">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 extensionstofor 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 TLVMUST NOT<bcp14>MUST NOT</bcp14> be used to advertise information carried using TLVs other than those in the OSPFv2 Extended Prefix Opaque LSA <xreftarget="RFC7684"/>.target="RFC7684" format="default"/>. In the case of OSPFv3, this TLVMUST 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 <xreftarget="RFC8362"/>.</t>target="RFC8362" format="default"/>.</t> <t>The format of the TLV is as follows:</t> <figureanchor="OPAQUEPREFIXTLV" title="Opaqueanchor="OPAQUEPREFIXTLV"> <name>Opaque Prefix Attribute TLVFormat"> <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>ThetypeType is as specified in <xreftarget="prefix-attribute_tlv"/>. Lengthtarget="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 PrivateuseUse are supported using the code point range reserved as indicated in <xreftarget="IANA"/>.target="IANA" format="default"/>. For such TLV use in the NLRI or BGP-LS Attribute, the formatasdescribed in <xreftarget="TLV-section"/>target="TLV-section" format="default"/> is to be used and a 4-octet fieldMUST<bcp14>MUST</bcp14> be included as the first field in the value to carry the Enterprise Code. For a private use NLRIType,type, a4 octet4-octet fieldMUST<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 <xreftarget="BGPLSNLRI"/>target="BGPLSNLRI" format="default"/> to carry the Enterprise Code <xreftarget="ENTNUM"/>.target="ENTNUM" format="default"/>. This enables the use of vendor-specific extensions without conflicts.</t> <t>Multiple instances of private-use TLVsMAY<bcp14>MAY</bcp14> appear in the BGP-LS Attribute.</t> </section> <section anchor="BGPNH"title="BGPnumbered="true" toc="default"> <name>BGP Next-HopInformation">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 thenext-hopnext hop in the MP_REACH_NLRISHOULD<bcp14>SHOULD</bcp14> be an IPv4 address. Similarly, if an IPv6 BGP session is used, then thenext-hopnext hop in the MP_REACH_NLRISHOULD<bcp14>SHOULD</bcp14> be an IPv6 address. Usually, thenext-hopnext hop will be set to the local endpoint address of the BGP session. The next-hop addressMUST<bcp14>MUST</bcp14> be encoded as described in <xreftarget="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 thenext-hopnext 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 bya link-localan IPv6 link-local address. Thelink-localIPv6 link-local address should be used as described in <xreftarget="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 thenext-hop.</t>next hop.</t> <t>The BGP Next-Hop is used by each BGP-LSspeakerSpeaker 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 <xreftarget="RFC5392"/>target="RFC5392" format="default"/> <xreftarget="RFC9346"/>.target="RFC9346" format="default"/>. In other cases, an implementationSHOULD<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="OSPFnumbered="true" toc="default"> <name>OSPF Virtual Links and ShamLinks">Links</name> <t>In an OSPF <xreftarget="RFC2328"/>target="RFC2328" format="default"/> <xreftarget="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 aspoint-to-pointpoint-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 <xreftarget="RFC4577"/>target="RFC4577" format="default"/> <xreftarget="RFC6565"/>target="RFC6565" format="default"/> are used to provide intra-area connectivity between VPN Routing and Forwarding (VRF) instances onPEProvider Edge (PE) routers over the VPN provider's network. These links are advertised in OSPF aspoint-to-pointpoint-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 otherpoint-to-pointpoint-to-point, unnumbered links as described previously in this document.</t> </section> <section anchor="OSPFTYPE4"title="OSPFv2numbered="true" toc="default"> <name>OSPFv2 Type 4Summary LSASummary-LSA & OSPFv3Inter-Area Router LSA">Inter-Area-Router-LSA</name> <t>OSPFv2 <xreftarget="RFC2328"/>target="RFC2328" format="default"/> defines theTypetype 4Summary LSAsummary-LSA and OSPFv3 <xreftarget="RFC5340"/>target="RFC5340" format="default"/> defines theInter-area-router-LSAinter-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 anode ornode, alinklink, 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="Handlingnumbered="true" toc="default"> <name>Handling of Unreachable IGPNodes">Nodes</name> <t>Consider an OSPF network as shown in <xreftarget="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 area00, 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 toaBGP route reflectorRR0RR0, which is a BGP-LS Propagator that is aggregating the BGP-LS feed fromtheBGP-LS Producers R2 and R3.HereHere, 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 ReportingdueDue to BGP PathSelection"> <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 area1)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 ithas derivedderives 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 ofR4R4's and R6's RouterLSAsLSAs, 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 BGPdecision 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 ProducerSHOULD<bcp14>SHOULD</bcp14> withdraw all link-state objects advertised by it in BGP when the node that originated its correspondingLSP/LSAsLSPs/LSAs is determined to have become unreachable in the IGP. An implementationMAY<bcp14>MAY</bcp14> continue to advertise link-state objects corresponding to unreachable nodes in a deploymentuse-caseuse 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 <xreftarget="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 itMUST<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-IDnumbered="true" toc="default"> <name>Router-ID Anchoring Example: ISOPseudonode">Pseudonode</name> <t>The encoding of a broadcast LAN in IS-IS provides a good example of how Router-IDs are encoded. Consider <xreftarget="ISISPseudonodes"/>.target="ISISPseudonodes" format="default"/>. This represents aBroadcastbroadcast 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 unidirectionallinkslinks, (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> <figureanchor="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-IDnumbered="true" toc="default"> <name>Router-ID Anchoring Example: OSPFPseudonode">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 <xreftarget="OSPFPseudonodes"/>.target="OSPFPseudonodes" format="default"/>. This represents aBroadcastbroadcast 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: OSPF192.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: OSPF192.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: OSPF192.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: OSPF192.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> <figureanchor="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 theLocallocal node using the DR address and the subnet mask from the Network LSA.</t> </section> <section anchor="OSPF2ISIS"title="Router-IDnumbered="true" toc="default"> <name>Router-ID Anchoring Example: OSPFv2 to IS-ISMigration">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,thatwhich initially were OSPFv2-only routers and then had IS-ISisenabled 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="Linknumbered="true" toc="default"> <name>Link to PathAggregation">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> <sectiontitle="Example:numbered="true" toc="default"> <name>Example: No LinkAggregation">Aggregation</name> <t>Consider <xreftarget="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 usingRSVP-FRRRSVP - 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> <figureanchor="no-link-aggregation" title="Noanchor="no-link-aggregation"> <name>No LinkAggregation"> <artwork><![CDATA[Aggregation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ AS1 : AS2 : R1-------R3 | : | \ | : | R5 | : | / R2-------R4 : : ]]></artwork></figure></t></figure> </section> <sectiontitle="Example:numbered="true" toc="default"> <name>Example: ASBR to ASBR PathAggregation">Aggregation</name> <t>The brief difference between the "no-link aggregation" example and this example is that no specific link gets exposed. Consider <xreftarget="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> <figureanchor="asbr-link-aggregation" title="ASBRanchor="asbr-link-aggregation"> <name>ASBR LinkAggregation"> <artwork><![CDATA[Aggregation</name> <artwork name="" type="" align="left" alt=""><![CDATA[ AS1 : AS2 : R1-------R3 | : | | : | | : | R2-------R4 : : ]]></artwork> </figure> </section> <sectiontitle="Example:numbered="true" toc="default"> <name>Example: Multi-AS PathAggregation">Aggregation</name> <t>Service providers in control of multiple ASes may even decide to not expose their internal inter-AS links. Consider <xreftarget="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> <figureanchor="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 <xreftarget="RFC7752"/>target="RFC7752" format="default"/> and <xreftarget="RFC9029"/>,target="RFC9029" format="default"/>, IANAis requested to changehas 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<https://www.iana.org/assignments/bgp-ls-parameters>.</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 <xreftarget="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 areBGP-LSspecific to BGP-LS and are accessible under this registry.</t> <section anchor="NLRITYPESREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS NLRI TypesRegistry">Registry</name> <t>The "BGP-LS NLRI Types" registry has been set up for assignment for thetwo-octet sized code-pointstwo-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-LSalign="center"> <name>BGP-LS NLRITypes"> <ttcol align="center">Type</ttcol> <ttcolTypes</name> <thead> <tr> <th align="center">Type</th> <th align="left">NLRIType</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>IPv4Type</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 PrefixNLRI</c> <c>[This document]</c> <c>4</c> <c>IPv6NLRI</td> <td align="right">RFC 9552</td> </tr> <tr> <td align="center">4</td> <td align="left">IPv6 Topology PrefixNLRI</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 <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. All other allocations within the registry are to be made using the "Expert Review" policy <xreftarget="RFC8126"/> thattarget="RFC8126" format="default"/>, which requires documentation of the proposed use of the allocated value and approval by theDesignated Expertdesignated expert assigned by the IESG.</t> </section> <section anchor="PROTOIDREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS Protocol-IDsRegistry">Registry</name> <t>The "BGP-LS Protocol-IDs" registry has been set up for assignment for theone-octet sized code-pointsone-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> <ttcolalign="center"> <name>BGP-LS Protocol-IDs</name> <thead> <tr> <th align="center">Protocol-ID</th> <th align="left">NLRI information sourceprotocol</ttcol> <ttcol align="right">Reference</ttcol> <c>0</c> <c>Reserved</c> <c>[This document]</c> <c>1</c> <c>IS-ISprotocol</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 Level1</c> <c>[This document]</c> <c>2</c> <c>IS-IS1</td> <td align="right">RFC 9552</td> </tr> <tr> <td align="center">2</td> <td align="left">IS-IS Level2</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 <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. All other allocations within the registry are to be made using the "Expert Review" policy <xreftarget="RFC8126"/> thattarget="RFC8126" format="default"/>, which requires documentation of the proposed use of the allocated value and approval by theDesignated Expertdesignated expert assigned by the IESG.</t> </section> <section anchor="INSTIDREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS Well-Known Instance-IDsRegistry">Registry</name> <t>The "BGP-LS Well-Known Instance-IDs" registry that was set up via <xreftarget="RFC7752"/>target="RFC7752" format="default"/> is no longer required. IANAis requested to markhas marked this registryasobsolete andto changechanged its registration procedure to "registry closed".</t> </section> <section anchor="NFLAGSIDREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS Node FlagsRegistry">Registry</name> <t>The "BGP-LS Node Flags" registryis requested to behas been created for theone octet-sizedone-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-LSalign="center"> <name>BGP-LS NodeFlags"> <ttcol align="center">Bit</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="right">Reference</ttcol> <c>0</c> <c>OverloadFlags</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 <xreftarget="RFC8126"/> thattarget="RFC8126" format="default"/>, which requires documentation of the proposed use of the allocated value and approval by theDesignated Expertdesignated expert assigned by the IESG.</t> </section> <section anchor="MPLSMASKREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS MPLS Protocol MaskRegistry">Registry</name> <t>The "BGP-LS MPLS Protocol Mask" registryis requested to behas been created for theone octet-sizedone-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-LSalign="center"> <name>BGP-LS MPLS ProtocolMask"> <ttcol align="center">Bit</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="right">Reference</ttcol> <c>0</c> <c>LabelMask</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 <xreftarget="RFC8126"/> thattarget="RFC8126" format="default"/>, which requires documentation of the proposed use of the allocated value and approval by theDesignated Expertdesignated expert assigned by the IESG.</t> </section> <section anchor="IGPPFLAGSREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS IGP Prefix FlagsRegistry">Registry</name> <t>The "BGP-LS IGP Prefix Flags" registryis requested to behas been created for theone octet-sizedone-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-LSalign="center"> <name>BGP-LS IGP PrefixFlags"> <ttcol align="center">Bit</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="right">Reference</ttcol> <c>0</c> <c>IS-ISFlags</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 <xreftarget="RFC8126"/> thattarget="RFC8126" format="default"/>, which requires documentation of the proposed use of the allocated value and approval by theDesignated Expertdesignated expert assigned by the IESG.</t> </section> <section anchor="TLVREG"title="BGP-LSnumbered="true" toc="default"> <name>BGP-LS TLVsRegistry">Registry</name> <t>The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry was created via <xreftarget="RFC7752"/>. This document requeststarget="RFC7752" format="default"/>. Per this document, IANAto renamehas renamed that registry to "BGP-LS NLRI and Attribute TLVs" andto removeremoved the column for "IS-IS TLV/Sub-TLV". The registration procedures are asbelow:</t> <texttablefollows:</t> <table anchor="reg_types"title="BGP-LSalign="center"> <name>BGP-LS TLVs RegistrationProcess"> <ttcolProcess</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcolPoint</th> <th align="left">RegistrationProcess</ttcol> <c>0-255</c> <c>ReservedProcess</th> </tr> </thead> <tbody> <tr> <td align="center">0-255</td> <td align="left">Reserved (not to beallocated)</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 <xreftarget="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 <xreftarget="RFC8126"/> thattarget="RFC8126" format="default"/>, which requires documentation of the proposed use of the allocated value and approval by theDesignated Expertdesignated expert assigned by the IESG.</t> <t>The registry was pre-populated with the values shown in <xreftarget="BGPLSCODEPOINTS"/>target="BGPLSCODEPOINTS" format="default"/>, and the reference forall those allocations should beeach allocation has been changed to this document and the respective section where those TLVs are specified.</t> </section> </section> <section anchor="DE-Guidance"title="Guidancenumbered="true" toc="default"> <name>Guidance for DesignatedExperts">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 andMUST<bcp14>MUST</bcp14> be accompanied by technical documentation explaining the use of the code point. Such documentationSHOULD<bcp14>SHOULD</bcp14> be presented in the form of anInternet-Draft,Internet-Draft butMAY<bcp14>MAY</bcp14> arrive in any form that can be reviewed and exchanged amongreviewers.</t> <t>Thereviewers.</li> <li>The designated expertsSHOULD<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 workinggroup.</t> <t>Ingroup.</li> <li>In the case of working group documents, the designated expertsMUST<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 expertsMUST<bcp14>MUST</bcp14> check with the AD for approval to allocate at thistime.</t> <t>Iftime.</li> <li>If the document is not adopted by the IDR Working Group (or its successor), the designated expertMUST<bcp14>MUST</bcp14> notify the IDR mailing list (or its successor) of the request andMUST<bcp14>MUST</bcp14> provide access to the document. The designated expertMUST<bcp14>MUST</bcp14> allow two weeks for any response. Any comments receivedMUST<bcp14>MUST</bcp14> be considered by the designated expert as part of the subsequentstep.</t> <t>Thestep.</li> <li>The designated expertsMUST<bcp14>MUST</bcp14> then review the assignment requests on their technical merit. The designated expertsMAY<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 aremade.</t> <t>Themade.</li> <li>The designated expertMUST<bcp14>MUST</bcp14> ensure that any request for a code point does not conflict with work that is active or already published within theIETF.</t> <t>OnceIETF.</li> <li>Once the designated experts have approved, IANA will update the registry by marking the allocated code points with a reference to the associateddocument.</t> <t>Indocument.</li> <li>In the event that the document is a working group document or isAD-Sponsored,AD-Sponsored andthat documentfails to progress to publication as an RFC, the working group chairs or ADSHOULD<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 theregistry.</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 <xreftarget="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 NLRIsSHOULD<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 distributionSHOULD<bcp14>SHOULD</bcp14> be used.</t> <t>It isRECOMMENDED<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 alsoRECOMMENDED<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) andensuringensure 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 <xreftarget="BGPLSNLRI"/>target="BGPLSNLRI" format="default"/> for more details.</t> </section> <section anchor="Initial-Setup"title="Installationnumbered="true" toc="default"> <name>Installation and InitialSetup">Setup</name> <t>Configuration parameters defined in <xreftarget="Configuration-Management"/> SHOULDtarget="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 allneighbors.</t> <t>Theneighbors.</li> <li>The maximum rate at which Link-State NLRIs will be advertised/withdrawn from neighbors is set to 200 updates persecond.</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 <xreftarget="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="Requirementsnumbered="true" toc="default"> <name>Requirements for Other Protocols and FunctionalComponents">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="Impactnumbered="true" toc="default"> <name>Impact on NetworkOperation">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 <xreftarget="Operations"/>.</t>target="Operations" format="default"/>.</t> <t>Distribution of Link-State NLRIsSHOULD<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="Verifyingnumbered="true" toc="default"> <name>Verifying CorrectOperation">Operation</name> <t>Existing BGP procedures apply. In addition, an implementationSHOULD<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-StateNLRIs.</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 IDRworking groupWorking Group has documented and continues to document parts of the Management Information Base and YANG models for managing and monitoring BGPspeakersSpeakers 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 <xreftarget="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 NLRIMUST 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 <xreftarget="TLV-section"/>target="TLV-section" format="counter"/> and <xreftarget="BGPLSNLRI"/>.</t>target="BGPLSNLRI" format="counter"/>.</t> <t>A BGP-LS SpeakerMUST<bcp14>MUST</bcp14> perform the following syntactic validation of the Link-State NLRI to determine if it ismalformed.<list style="symbols"> <t>Themalformed.</t> <ul spacing="normal"> <li>The sum of allTLVsTLV lengths found in the BGP MP_REACH_NLRI attribute corresponds to the BGP MP_REACH_NLRIlength.</t> <t>Thelength.</li> <li>The sum of allTLVsTLV lengths found in the BGP MP_UNREACH_NLRI attribute corresponds to the BGP MP_UNREACH_NLRIlength.</t> <t>Thelength.</li> <li>The sum of allTLVsTLV lengths found in a Link-State NLRI corresponds to the Total NLRI Length field of all itsDescriptors.</t> <t>Thedescriptors.</li> <li>The length of the TLVs and, when the TLV is recognized then, the length of its sub-TLVs in the NLRIis valid.</t> <t>Theare valid.</li> <li>The syntactic correctness of the NLRI fields has been verified as per <xreftarget="RFC7606"/>.</t> <t>Thetarget="RFC7606" format="default"/>.</li> <li>The rule regarding the ordering of TLVs has been followed as described in <xreftarget="TLV-section"/>.</t> <t>Fortarget="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-TLVpresent.</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 itMUST<bcp14>MUST</bcp14> handle such malformed NLRIs as 'NLRI discard' (i.e., processing similar to what is described insection 5.4 of<xreftarget="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 routerSHOULD<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 routerMUST<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 AttributeMUST 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 <xreftarget="TLV-section"/>target="TLV-section" format="counter"/> and <xreftarget="BGPLSATTR"/>.</t>target="BGPLSATTR" format="counter"/>.</t> <t>A BGP-LS SpeakerMUST<bcp14>MUST</bcp14> perform the following syntactic validation of the BGP-LS Attribute to determine if it ismalformed.<list style="symbols"> <t>Themalformed.</t> <ul spacing="normal"> <li>The sum of allTLVsTLV lengths found in the BGP-LS Attribute corresponds to the BGP-LS Attributelength.</t> <t>Thelength.</li> <li>The syntactic correctness of the Attributes (including the BGP-LS Attribute) have been verified as per <xreftarget="RFC7606"/>.</t> <t>Thetarget="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 Attributeis 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 itMUST<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 UPDATEmessage thenmessage, 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 implementationSHOULD<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 implementationSHOULD<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 exhaustivelist):<list style="symbols"> <t>presencelist):</t> <ul spacing="normal"> <li>presence of a mandatoryTLV</t> <t>theTLV</li> <li>the length of a fixed-length TLV is correct or the length of a variable length TLV is valid orpermissible</t> <t>thepermissible</li> <li>the values of TLV fields are valid orpermissible</t> <t>thepermissible</li> <li>the inclusion and use of TLVs/sub-TLVs with specific Link-State NLRI types isvalid</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 implementationSHOULD<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 implementationSHOULD<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 implementationSHOULD<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 implementationSHOULD<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 implementationMUST<bcp14>MUST</bcp14> allow the operator to configure an 8-octet BGP-LS Instance-ID. Refer to <xreftarget="BGPLSNLRI"/>target="BGPLSNLRI" format="default"/> for guidance to the operator for the configuration of BGP-LS Instance-ID.</t> <t>An implementationSHOULD<bcp14>SHOULD</bcp14> allow the operator to configureASNAutonomous System Number (ASN) and BGP-LS identifiers (refer to <xreftarget="node_desc_tlvs"/>).</t>target="node_desc_tlvs" format="default"/>).</t> <t>An implementationSHOULD<bcp14>SHOULD</bcp14> allow the operator to configure limitingofthe 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 <xreftarget="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 implementationSHOULD<bcp14>SHOULD</bcp14> provide the following statistics:<list style="symbols"> <t>Total</t> <ul spacing="normal"> <li>Total number of Link-State NLRI updatessent/received</t> <t>Numbersent/received</li> <li>Number of Link-State NLRI updates sent/received, perneighbor</t> <t>Numberneighbor</li> <li>Number of errored received Link-State NLRI updates, perneighbor</t> <t>Totalneighbor</li> <li>Total number of locally originated Link-StateNLRIs</t> </list></t>NLRIs</li> </ul> <t>These statistics should be recorded as absolute counts since the system or session start time. An implementationMAY<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 operatorMUST<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-LSConsumers.</t> </list></t>Consumers.</li> </ul> <t>An implementationMUST<bcp14>MUST</bcp14> have the means to limit inbound updates.</t> </section> </section> </section> <section anchor="TLVSUMMARY"title="TLV/Sub-TLVnumbered="true" toc="default"> <name>TLV/Sub-TLV Code PointsSummary">Summary</name> <t>This section contains the global table of all TLVs/sub-TLVs defined in this document.</t><texttable<table anchor="BGPLSCODEPOINTS"title="Summaryalign="center"> <name>Summary Table of TLV/Sub-TLV CodePoints"> <ttcolPoints</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcol align="left">Description</ttcol> <ttcolPoint</th> <th align="left">Description</th> <th align="left">ReferenceSection</ttcol> <c>256</c> <c>LocalSection</th> </tr> </thead> <tbody> <tr> <td align="center">256</td> <td align="left">Local NodeDescriptors</c> <c><xref target="LOCALNODEDESC"/></c> <c>257</c> <c>RemoteDescriptors</td> <td align="left"> <xref target="LOCALNODEDESC" format="default"/></td> </tr> <tr> <td align="center">257</td> <td align="left">Remote NodeDescriptors</c> <c><xref target="REMOTENODEDESC"/></c> <c>258</c> <c>LinkDescriptors</td> <td align="left"> <xref target="REMOTENODEDESC" format="default"/></td> </tr> <tr> <td align="center">258</td> <td align="left">Link Local/RemoteIdentifiers</c> <c><xref target="LINKDESC"/></c> <c>259</c> <c>IPv4Identifiers</td> <td align="left"> <xref target="LINKDESC" format="default"/></td> </tr> <tr> <td align="center">259</td> <td align="left">IPv4 interfaceaddress</c> <c><xref target="LINKDESC"/></c> <c>260</c> <c>IPv4address</td> <td align="left"> <xref target="LINKDESC" format="default"/></td> </tr> <tr> <td align="center">260</td> <td align="left">IPv4 neighboraddress</c> <c><xref target="LINKDESC"/></c> <c>261</c> <c>IPv6address</td> <td align="left"> <xref target="LINKDESC" format="default"/></td> </tr> <tr> <td align="center">261</td> <td align="left">IPv6 interfaceaddress</c> <c><xref target="LINKDESC"/></c> <c>262</c> <c>IPv6address</td> <td align="left"> <xref target="LINKDESC" format="default"/></td> </tr> <tr> <td align="center">262</td> <td align="left">IPv6 neighboraddress</c> <c><xref target="LINKDESC"/></c> <c>263</c> <c>Multi-Topology ID</c> <c><xref target="MT-ID"/></c> <c>264</c> <c>OSPFaddress</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 RouteType</c> <c><xref target="PREFIXDESC"/></c> <c>265</c> <c>IPType</td> <td align="left"> <xref target="OSPFRTETYPE" format="default"/></td> </tr> <tr> <td align="center">265</td> <td align="left">IP ReachabilityInformation</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-LSInformation</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 FlagBits</c> <c><xref target="NODEFLAGBITS"/></c> <c>1025</c> <c>OpaqueBits</td> <td align="left"> <xref target="NODEFLAGBITS" format="default"/></td> </tr> <tr> <td align="center">1025</td> <td align="left">Opaque NodeAttribute</c> <c><xref target="OPAQUENODE"/></c> <c>1026</c> <c>Node Name</c> <c><xref target="NODENAME"/></c> <c>1027</c> <c>IS-ISAttribute</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 AreaIdentifier</c> <c><xref target="ISISAREA"/></c> <c>1028</c> <c>IPv4Identifier</td> <td align="left"> <xref target="ISISAREA" format="default"/></td> </tr> <tr> <td align="center">1028</td> <td align="left">IPv4 Router-ID of LocalNode</c> <c><xref target="aux_routerid_node"/> / <xref target="aux_routerid_link"/></c> <c>1029</c> <c>IPv6Node</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 LocalNode</c> <c><xref target="aux_routerid_node"/> / <xref target="aux_routerid_link"/></c> <c>1030</c> <c>IPv4Node</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 RemoteNode</c> <c><xref target="aux_routerid_link"/></c> <c>1031</c> <c>IPv6Node</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 RemoteNode</c> <c><xref target="aux_routerid_link"/></c> <c>1088</c> <c>AdministrativeNode</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 linkbandwidth</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 linkbandwidth</c> <c><xref target="link_attribute"/></c> <c>1091</c> <c>Unreserved bandwidth</c> <c><xref target="link_attribute"/></c> <c>1092</c> <c>TEbandwidth</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 DefaultMetric</c> <c><xref target="TEDEFAULTMETTLV"/></c> <c>1093</c> <c>LinkMetric</td> <td align="left"> <xref target="TEDEFAULTMETTLV" format="default"/></td> </tr> <tr> <td align="center">1093</td> <td align="left">Link ProtectionType</c> <c><xref target="link_attribute"/></c> <c>1094</c> <c>MPLSType</td> <td align="left"> <xref target="link_attribute" format="default"/></td> </tr> <tr> <td align="center">1094</td> <td align="left">MPLS ProtocolMask</c> <c><xref target="MPLSPROTOTLV"/></c> <c>1095</c> <c>IGP Metric</c> <c><xref target="IGPMETTLV"/></c> <c>1096</c> <c>SharedMask</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 LinkGroup</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>IGPGroup</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 RouteTag</c> <c><xref target="route_tag"/></c> <c>1154</c> <c>IGPTag</td> <td align="left"> <xref target="route_tag" format="default"/></td> </tr> <tr> <td align="center">1154</td> <td align="left">IGP Extended RouteTag</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>OSPFTag</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 ForwardingAddress</c> <c><xref target="ospf_fwd_addr"/></c> <c>1157</c> <c>OpaqueAddress</td> <td align="left"> <xref target="ospf_fwd_addr" format="default"/></td> </tr> <tr> <td align="center">1157</td> <td align="left">Opaque PrefixAttribute</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 <xreftarget="RFC4271"/>target="RFC4271" format="default"/> for a discussion of BGP security. Also, refer to <xreftarget="RFC4272"/>target="RFC4272" format="default"/> and <xreftarget="RFC6952"/>target="RFC6952" format="default"/> for analysis of security issues for BGP.</t> <t>The operator should ensure that a BGP-LSspeakerSpeaker 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 <xreftarget="Configuration-Management"/>target="Configuration-Management" format="counter"/> and <xreftarget="Security-Management"/>.target="Security-Management" format="counter"/>. Generally, an operator is aware of the BGP-LSspeaker'sSpeaker's role and link-state peerings. Therefore, the operator can protect the BGP-LSspeakerSpeaker 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 theNLRINLRI, 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 protocolperspective,perspective; however, in the case ofBGP-LSBGP-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 BGPSpeakerSpeakers 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 EnterpriseNumbers</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="Changesnumbered="true" toc="default"> <name>Changes from RFC7752">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 <xreftarget="MECHANISM-OVERVIEW"/>target="MECHANISM-OVERVIEW" format="default"/> in <xreftarget="INTRO"/>target="INTRO" format="default"/> and added <xreftarget="ROLES"/>target="ROLES" format="default"/> to illustrate the different roles of a BGP implementation in conveying link-stateinformation.</t> <t>Clarifiedinformation.</li> <li>Clarified aspects related to advertisement of link-state information from IGPs into BGP-LS in <xreftarget="IGPTOBGP"/>.</t> <t>Intarget="IGPTOBGP" format="default"/>.</li> <li>In <xreftarget="TLV-section"/>, clarificationtarget="TLV-section" format="default"/>, clarified aspects abouttheTLV handlingaspectsthat apply to both the NLRI and BGP-LS Attribute partsandas 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 <xreftarget="RFC7606"/>target="RFC7606" format="default"/> guidelines, might discard the unknown NLRI types. This aspect is now unambiguously clarified in <xreftarget="BGPLSNLRI"/>.target="BGPLSNLRI" format="default"/>. Also, the TLVs in the BGP-LS Attribute that are not ordered are not to be consideredmalformed.</t> <t>Clarificationmalformed.</li> <li>Clarified aspects of mandatory and optional TLVs in both NLRI and BGP-LS Attribute portions all through thedocument.</t> <t>Handling of large sizedocument.</li> <li>In <xref target="BGPLSATTR" format="default"/>, the handling of a large-sized BGP-LS Attribute with growth in BGP-LS information is explainedin <xref target="BGPLSATTR"/>along with mitigation of errors arising out ofit.</t> <t>Clarifiedit.</li> <li>Clarified that the document describes the NLRI descriptor TLVs for the protocols and NLRI types specified in this documentandas well as future BGP-LS extensions must describe the same for other protocols and NLRI types that theyintroduce.</t> <t>Clarification onintroduce.</li> <li>In <xref target="BGPLSNLRI" format="default"/>, clarified the use of the Identifier field in the Link-StateNLRI 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 beingremoved.</t> <t>Theremoved.</li> <li>The BGP-LS Identifier TLV in the Node Descriptors has been deprecated. Its use was not well specified by <xreftarget="RFC7752"/>target="RFC7752" format="default"/>, and there has been some amount of confusion betweenimplementatorsimplementors 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 withAutonomous 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-LSspeakersSpeakers 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)tupletuple, and if an IGP domain consists of multiple flooding-sets, then all BGP-LSspeakersSpeakers within the IGP domain had to use the same (ASN, BGP-LS ID)tuple.</t> <t>Clarificationtuple.</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 clarifiedonthe IS-IS area and areaaddresses.</t> <t>Movedaddresses.</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 anddescribedescribed the differences in the applicability of the R flags when the MT-ID TLV is used aslink descriptorthe Link Descriptor TLV and Prefix Attribute TLV. The MT-ID TLV use is now elevated toSHOULD<bcp14>SHOULD</bcp14> when it is enabled in the underlyingIGP.</t> <t>ClarifiedIGP.</li> <li>Clarified that IPv6Link-Local Addresseslink-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 addressesonly.</t> <t>Updateonly.</li> <li>Updated the usage of OSPF Route Type TLV to mandate its use for OSPF prefixes in <xreftarget="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 externalprefixes.</t> <t>Clarification ofprefixes.</li> <li>Clarified the specific OSPFv2 and OSPFv3 protocol TLV space to be used in thenode, link,Node, Link, andprefix opaque attribute TLVs.</t> <t>Clarification onPrefix Opaque Attribute TLVs.</li> <li>Clarified that the length of the Node Flag Bits and IGP Flags TLVs are to be oneoctet.</t> <t>Updatedoctet.</li> <li>Updated the Node Name TLV in <xreftarget="NODENAME"/>target="NODENAME" format="default"/> with the OSPFspecification.</t> <t>Clarification onspecification.</li> <li>Clarified the size of the IS-IS Narrow Metric advertisement via the IGP Metric TLV and the handling of the unusedbits.</t> <t>Clarifiedbits.</li> <li>Clarified the advertisement of the prefix corresponding to the LAN segment in an OSPF network in <xreftarget="OSPFPN"/>.</t> <t>Clarifiedtarget="OSPFPN" format="default"/>.</li> <li>Clarified the advertisement and support forOSPF specificOSPF-specific concepts likeVirtualvirtual links,Shamsham links, and Type 4 LSAs in Sections <xreftarget="OSPFVL"/>target="OSPFVL" format="counter"/> and <xreftarget="OSPFTYPE4"/>.</t> <t>Introducedtarget="OSPFTYPE4" format="counter"/>.</li> <li>Introduced the Private Use TLV code point space and specified their encoding in <xreftarget="PRIVATE"/>.</t> <t>Introducedtarget="PRIVATE" format="default"/>.</li> <li>In <xreftarget="UNREACHNODES"/>target="UNREACHNODES" format="default"/>, introduced where issues related to the consistency of reporting IGP link-state along with their solutions arecovered.</t> <t>Addedcovered.</li> <li>Added a recommendation for isolation of BGP-LS sessions from other BGP routeexchangeexchanges to avoid errors and faults in BGP-LS affecting the normal BGProuting.</t> <t>Updatedrouting.</li> <li>Updated the Fault Management section with detailed rules based on the role of the BGP Speaker in the BGP-LS information propagationflow.</t> <t>Change toflow.</li> <li>Changed the management of BGP-LS IANA registries from "Specification Required" to "Expert Review" along with updated guidelines forDesignated Experts. More specificallydesignated experts, more specifically, the inclusion of changes introduced via <xreftarget="RFC9029"/>target="RFC9029" format="default"/> thatisare obsoleted by thisdocument.</t> <t>Addeddocument.</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 fromit.</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>