rfc9552xml2.original.xml   rfc9552.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="3"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc inline="yes"?> tf-idr-rfc7752bis-17" ipr="trust200902" number="9552" obsoletes="7752, 9029" upd
<?rfc compact="yes"?> ates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" t
<?rfc subcompact="no"?> ocDepth="3" symRefs="true" sortRefs="true" version="3">
<rfc category="std" docName="draft-ietf-idr-rfc7752bis-17" ipr="trust200902" <!-- xml2rfc v2v3 conversion 3.18.0 -->
obsoletes="7752, 9029">
<front> <front>
<title abbrev="Link-State Info Distribution Using BGP">Distribution of <title abbrev="Link-State Information Distribution Using BGP">Distribution o f
Link-State and Traffic Engineering Information Using BGP</title> Link-State and Traffic Engineering Information Using BGP</title>
<seriesInfo name="RFC" value="9552"/>
<author fullname="Ketan Talaulikar" initials="K" role="editor" <author fullname="Ketan Talaulikar" initials="K" surname="Talaulikar" role="
surname="Talaulikar"> editor">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="December" year="2023"/>
<date/>
<area>Routing</area> <area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup> <workgroup>Inter-Domain Routing</workgroup>
<abstract> <abstract>
<t>In many environments, a component external to a network is called <t>In many environments, a component external to a network is called
upon to perform computations based on the network topology and the upon to perform computations based on the network topology and the
current state of the connections within the network, including Traffic current state of the connections within the network, including Traffic
Engineering (TE) information. This is information typically distributed Engineering (TE) information. This is information typically distributed
by IGP routing protocols within the network.</t> by IGP routing protocols within the network.</t>
<t>This document describes a mechanism by which link-state and TE <t>This document describes a mechanism by which link-state and TE
information can be collected from networks and shared with external information can be collected from networks and shared with external
components using the BGP routing protocol. This is achieved using a BGP components using the BGP routing protocol. This is achieved using a BGP
Network Layer Reachability Information (NLRI) encoding format. The Network Layer Reachability Information (NLRI) encoding format. The
mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The
mechanism described is subject to policy control.</t> mechanism described is subject to policy control.</t>
<t>Applications of this technique include Application-Layer Traffic <t>Applications of this technique include Application-Layer Traffic
Optimization (ALTO) servers and Path Computation Elements (PCEs).</t> Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
<t>This document obsoletes RFC 7752 by completely replacing that
<t>This document obsoletes RFC7752 by completely replacing that
document. It makes some small changes and clarifications to the previous document. It makes some small changes and clarifications to the previous
specification. This document also obsoletes RFC9029 by incorporating the specification. This document also obsoletes RFC 9029 by incorporating the
updates that it made to RFC7752.</t> updates that it made to RFC 7752.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<name>Introduction</name>
<t>The contents of a Link-State Database (LSDB) or of an IGP's Traffic <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 Engineering Database (TED) describe only the links and nodes within an
IGP area. Some applications, such as end-to-end Traffic Engineering IGP area. Some applications, such as end-to-end Traffic Engineering
(TE), would benefit from visibility outside one area or Autonomous (TE), would benefit from visibility outside one area or Autonomous
System (AS) to make better decisions.</t> System (AS) to make better decisions.</t>
<t>The IETF has defined the Path Computation Element (PCE) <xref target="R
<t>The IETF has defined the Path Computation Element (PCE) <xref FC4655" format="default"/> as a mechanism for achieving the computation of
target="RFC4655"/> as a mechanism for achieving the computation of end-to-end TE paths that crosses the visibility of more than one TED or
end-to-end TE paths that cross the visibility of more than one TED or
that requires CPU-intensive or coordinated computations. The IETF has that requires CPU-intensive or coordinated computations. The IETF has
also defined the ALTO server <xref target="RFC5693"/> as an entity that also defined the ALTO server <xref target="RFC5693" format="default"/> as an entity that
generates an abstracted network topology and provides it to generates an abstracted network topology and provides it to
network-aware applications.</t> network-aware applications.</t>
<t>Both a PCE and an ALTO server need to gather information about the <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 topologies and capabilities of the network to be able to fulfill their
function.</t> function.</t>
<t>This document describes a mechanism by which link-state and TE <t>This document describes a mechanism by which link-state and TE
information can be collected from networks and shared with external information can be collected from networks and shared with external
components using the BGP routing protocol <xref target="RFC4271"/>. This components using the BGP routing protocol <xref target="RFC4271" format="d efault"/>. This
is achieved using a BGP Network Layer Reachability Information (NLRI) is achieved using a BGP Network Layer Reachability Information (NLRI)
encoding format. The mechanism applies to physical and virtual (e.g., encoding format. The mechanism applies to physical and virtual (e.g.,
tunnel) links. The mechanism described is subject to policy control.</t> tunnel) links. The mechanism described is subject to policy control.</t>
<t>A router maintains one or more databases for storing link-state <t>A router maintains one or more databases for storing link-state
information about nodes and links in any given area. Link attributes information about nodes and links in any given area. Link attributes
stored in these databases include: local/remote IP addresses, stored in these databases include: local/remote IP addresses,
local/remote interface identifiers, link IGP metric, link TE metric, local/remote interface identifiers, link IGP metric, link TE metric,
link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class
reservation state, preemption, and Shared Risk Link Groups (SRLGs). The reservation state, preemption, and Shared Risk Link Groups (SRLGs). The
router's BGP Link-State (BGP-LS) process can retrieve topology from router's BGP - Link State (BGP-LS) process can retrieve topology from
these LSDBs and distribute it to a consumer, either directly or via a these LSDBs and distribute it to a consumer, either directly or via a
peer BGP speaker (typically a dedicated Route Reflector), using the peer BGP Speaker (typically a dedicated route reflector), using the
encoding specified in this document.</t> encoding specified in this document.</t>
<t>An illustration of the collection of link-state and TE information <t>An illustration of the collection of link-state and TE information
and its distribution to consumers is shown in <xref and its distribution to consumers is shown in <xref target="MECHANISM-OVER
target="MECHANISM-OVERVIEW"/> below.</t> VIEW" format="default"/> below.</t>
<figure anchor="MECHANISM-OVERVIEW">
<figure anchor="MECHANISM-OVERVIEW" <name>Collection of Link-State and TE Information</name>
title="Collection of Link-State and TE Information"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+-----------+ +-----------+
| Consumer | | Consumer |
+-----------+ +-----------+
^ ^
| |
+-----------+ +-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP | | BGP |
| Speaker |<----------->| Speaker | +-----------+ | Speaker |<----------->| Speaker | +-----------+
| RR1 | | RRm | | Consumer | | RR1 | | RRm | | Consumer |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
skipping to change at line 133 skipping to change at line 110
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP | | BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker | | Speaker | | Speaker | . . . | Speaker |
| R1 | | R2 | | Rn | | R1 | | R2 | | Rn |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
^ ^ ^ ^ ^ ^
| | | | | |
IGP IGP IGP IGP IGP IGP
]]></artwork> ]]></artwork>
</figure> </figure>
<t>A BGP Speaker may apply a configurable policy to the information that
<t>A BGP speaker may apply a configurable policy to the information that
it distributes. Thus, it may distribute the real physical topology from it distributes. Thus, it may distribute the real physical topology from
the LSDB or the TED. Alternatively, it may create an abstracted the LSDB or the TED. Alternatively, it may create an abstracted
topology, where virtual, aggregated nodes are connected by virtual topology, where virtual, aggregated nodes are connected by virtual
paths. Aggregated nodes can be created, for example, out of multiple paths. Aggregated nodes can be created, for example, out of multiple
routers in a Point of Presence (POP). Abstracted topology can also be a routers in a Point of Presence (POP). Abstracted topology can also be a
mix of physical and virtual nodes and physical and virtual links. mix of physical and virtual nodes and physical and virtual links.
Furthermore, the BGP speaker can apply policy to determine when Furthermore, the BGP Speaker can apply policy to determine when
information is updated to the consumer so that there is a reduction in information is updated to the consumer so that there is a reduction in
information flow from the network to the consumers. Mechanisms through information flow from the network to the consumers. Mechanisms through
which topologies can be aggregated or virtualized are outside the scope which topologies can be aggregated or virtualized are outside the scope
of this document.</t> of this document.</t>
<t>This document focuses on the specifications related to the <t>This document focuses on the specifications related to the
origination of IGP-derived information and their propagation via BGP-LS. origination of IGP-derived information and their propagation via BGP-LS.
It also describes the advertisement into BGP-LS of information, either It also describes the advertisement into BGP-LS of information, either
configured or derived, that is local to a node. In general, the configured or derived, that is local to a node. In general, the
procedures in this document form part of the base BGP-LS protocol procedures in this document form part of the base BGP-LS protocol
specification and apply to information from other sources that are specification and apply to information from other sources that are
introduced into BGP-LS.</t> introduced into BGP-LS.</t>
<t>This document obsoletes <xref target="RFC7752" format="default"/> by co
<t>This document obsoletes <xref target="RFC7752"/> by completely mpletely
replacing that document. It makes some small changes and clarifications replacing that document. It makes some small changes and clarifications
to the previous specification as documented in <xref to the previous specification as documented in <xref target="CHANGES" form
target="CHANGES"/>.</t> at="default"/>.</t>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="APPL" numbered="true" toc="default">
<section anchor="APPL" title="Motivation and Applicability"> <name>Motivation and Applicability</name>
<t>This section describes use cases from which the requirements can be <t>This section describes use cases from which the requirements can be
derived.</t> derived.</t>
<section anchor="PCE" numbered="true" toc="default">
<section anchor="PCE" title="MPLS-TE with PCE"> <name>MPLS-TE with PCE</name>
<t>As described in <xref target="RFC4655"/>, a PCE can be used to <t>As described in <xref target="RFC4655" format="default"/>, a PCE can
be used to
compute MPLS-TE paths within a "domain" (such as an IGP area) or 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). across multiple domains (such as a multi-area AS or multiple ASes).
<list style="symbols"> </t>
<t>Within a single area, the PCE offers enhanced computational <ul spacing="normal">
<li>Within a single area, the PCE offers enhanced computational
power that may not be available on individual routers, power that may not be available on individual routers,
sophisticated policy control and algorithms, and coordination of sophisticated policy control and algorithms, and coordination of
computation across the whole area.</t> computation across the whole area.</li>
<li>If a router wants to compute an MPLS-TE path across IGP areas,
<t>If a router wants to compute an MPLS-TE path across IGP areas,
then its own TED lacks visibility of the complete topology. That then its own TED lacks visibility of the complete topology. That
means that the router cannot determine the end-to-end path and means that the router cannot determine the end-to-end path and
cannot even select the right exit router (Area Border Router cannot even select the right exit router (Area Border Router
(ABR)) for an optimal path. This is an issue for large-scale (ABR)) for an optimal path. This is an issue for large-scale
networks that need to segment their core networks into distinct networks that need to segment their core networks into distinct
areas but still want to take advantage of MPLS-TE.</t> areas but still want to take advantage of MPLS-TE.</li>
</list></t> </ul>
<t>Previous solutions used per-domain path computation <xref target="RFC
<t>Previous solutions used per-domain path computation <xref 5152" format="default"/>. The source router could only compute the path for
target="RFC5152"/>. The source router could only compute the path for
the first area because the router only has full topological visibility the first area because the router only has full topological visibility
for the first area along the path, but not for subsequent areas. for the first area along the path but not for subsequent areas.
Per-domain path computation uses a technique called Per-domain path computation selects the exit ABR and other ABRs or
"loose-hop-expansion" <xref target="RFC3209"/> and selects the exit AS Border Routers (ASBRs) as loose-hops <xref target="RFC3209" format="d
ABR and other ABRs or AS Border Routers (ASBRs) using the IGP-computed efault"/> and using the IGP-computed
shortest path topology for the remainder of the path. This may lead to shortest path topology for the remainder of the path. This may lead to
suboptimal paths, makes alternate/back-up path computation hard, and suboptimal paths, makes alternate/back-up path computation hard, and
might result in no TE path being found when one does exist.</t> 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 <t>The PCE presents a computation server that may have visibility into
more than one IGP area or AS, or may cooperate with other PCEs to more than one IGP area or AS or may cooperate with other PCEs to
perform distributed path computation. The PCE needs access to the TED perform distributed path computation. The PCE needs access to the TED
for the area(s) it serves, but <xref target="RFC4655"/> does not for the area(s) it serves, but <xref target="RFC4655" format="default"/> does not
describe how this is achieved. Many implementations make the PCE a describe how this is achieved. Many implementations make the PCE a
passive participant in the IGP so that it can learn the latest state passive participant in the IGP so that it can learn the latest state
of the network, but this may be sub-optimal when the network is of the network, but this may be suboptimal when the network is
subject to a high degree of churn or when the PCE is responsible for subject to a high degree of churn or when the PCE is responsible for
multiple areas.</t> multiple areas.</t>
<t>The following figure shows how a PCE can get its TED information <t>The following figure shows how a PCE can get its TED information
using the mechanism described in this document.</t> using the mechanism described in this document.</t>
<figure anchor="PCE-REFERENCE">
<figure anchor="PCE-REFERENCE" <name>External PCE Node Using a TED Synchronization Mechanism</name>
title="External PCE Node Using a TED Synchronization Mechanism"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+----------+ +---------+ +----------+ +---------+
| ----- | | BGP | | ----- | | BGP |
| | TED |<-+-------------------------->| Speaker | | | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | | | ----- | TED synchronization | |
| | | mechanism +---------+ | | | mechanism +---------+
| | | | | |
| v | | v |
| ----- | | ----- |
| | PCE | | | | PCE | |
| ----- | | ----- |
skipping to change at line 240 skipping to change at line 209
^ ^
| Request/ | Request/
| Response | Response
v v
Service +----------+ Signaling +----------+ Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent | Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node | -------->| Node |<------------>| Node |
+----------+ +----------+ +----------+ +----------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The mechanism in this document allows the necessary TED information <t>The mechanism in this document allows the necessary TED information
to be collected from the IGP within the network, filtered according to to be collected from the IGP within the network, filtered according to
configurable policy, and distributed to the PCE as necessary.</t> configurable policy, and distributed to the PCE as necessary.</t>
</section> </section>
<section anchor="ALTO" numbered="true" toc="default">
<section anchor="ALTO" title="ALTO Server Network API"> <name>ALTO Server Network API</name>
<t>An ALTO server <xref target="RFC5693"/> is an entity that generates <t>An ALTO server <xref target="RFC5693" format="default"/> is an entity
that generates
an abstracted network topology and provides it to network-aware an abstracted network topology and provides it to network-aware
applications over a web-service-based API. Example applications are applications over a web-service-based API. Example applications are
peer-to-peer (P2P) clients or trackers, or Content Distribution peer-to-peer (P2P) clients or trackers, or Content Distribution
Networks (CDNs). The abstracted network topology comes in the form of Networks (CDNs). The abstracted network topology comes in the form of
two maps: a Network Map that specifies the allocation of prefixes to two maps: a Network Map that specifies the allocation of prefixes to
Partition Identifiers (PIDs), and a Cost Map that specifies the cost Partition Identifiers (PIDs) and a Cost Map that specifies the cost
between PIDs listed in the Network Map. For more details, see <xref between PIDs listed in the Network Map. For more details, see <xref targ
target="RFC7285"/>.</t> et="RFC7285" format="default"/>.</t>
<t>ALTO abstract network topologies can be auto-generated from the <t>ALTO abstract network topologies can be auto-generated from the
physical topology of the underlying network. The generation would physical topology of the underlying network. The generation would
typically be based on policies and rules set by the operator. Both typically be based on policies and rules set by the operator. Both
prefix and TE data are required: prefix data is required to generate prefix and TE data are required: prefix data is required to generate
ALTO Network Maps and TE (topology) data is required to generate ALTO 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 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 is originated and carried in an IGP. The mechanism defined in this
document provides a single interface through which an ALTO server can document provides a single interface through which an ALTO server can
retrieve all the necessary prefixes and network topology data from the retrieve all the necessary prefixes and network topology data from the
underlying network. Note that an ALTO server can use other mechanisms underlying network. Note that an ALTO server can use other mechanisms
to get network data, for example, peering with multiple IGP and BGP to get network data, for example, peering with multiple IGP and BGP
speakers.</t> Speakers.</t>
<t>The following figure shows how an ALTO server can get network <t>The following figure shows how an ALTO server can get network
topology information from the underlying network using the mechanism topology information from the underlying network using the mechanism
described in this document.</t> described in this document.</t>
<figure anchor="ALTO-REFERENCE">
<figure anchor="ALTO-REFERENCE" <name>ALTO Server Using Network Topology Information</name>
title="ALTO Server Using Network Topology Information"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
+--------+ +--------+
| Client |<--+ | Client |<--+
+--------+ | +--------+ |
| ALTO +--------+ Topology +---------+ | ALTO +--------+ Topology +---------+
+--------+ | Protocol | ALTO | Sync Mechanism | BGP | +--------+ | Protocol | ALTO | Sync Mechanism | BGP |
| Client |<--+------------| Server |<----------------| Speaker | | Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | | | +--------+ | | | | |
| +--------+ +---------+ | +--------+ +---------+
+--------+ | +--------+ |
| Client |<--+ | Client |<--+
+--------+ +--------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="ROLES" numbered="true" toc="default">
<section anchor="ROLES" title="BGP Speaker Roles for BGP-LS"> <name>BGP Speaker Roles for BGP-LS</name>
<t>In the illustration shown in <xref target="MECHANISM-OVERVIEW"/>, the <t>In <xref target="MECHANISM-OVERVIEW" format="default"/>, the
BGP Speakers can be seen playing different roles in the distribution of BGP Speakers can be seen playing different roles in the distribution of
information using BGP-LS. This section introduces terms that explain the information using BGP-LS. This section introduces terms that explain the
different roles of the BGP Speakers which are then used through the rest different roles of the BGP Speakers that are then used throughout the rest
of this document.</t> of this document.</t>
<dl newline="false" spacing="normal">
<t><list style="symbols"> <dt>BGP-LS Producer:</dt> <dd>The term BGP-LS Producer refers to a BGP S
<t>BGP-LS Producer: The term BGP-LS Producer refers to a BGP Speaker peaker
that is originating link-state information into BGP. The BGP that is originating link-state information into BGP. BGP
Speakers R1, R2, ... Rn, originate link-state information from their Speakers R1, R2, ... Rn originate link-state information from their
underlying link-state IGP protocols into BGP-LS. If R1 and R2 are in 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 IGP flooding domain, then they would ordinarily originate
the same link-state information into BGP-LS. R1 may also originate the same link-state information into BGP-LS. R1 may also originate
information from sources other than IGP, e.g. its local node information from sources other than IGP, e.g., its local node
information.</t> information.</dd>
<dt>BGP-LS Consumer:</dt> <dd>The term BGP-LS Consumer refers to a consu
<t>BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer mer
application/process and not a BGP Speaker. The BGP Speakers RR1 and application/process and not a BGP Speaker. BGP Speakers RR1 and
Rn are handing off the BGP-LS information that they have collected Rn are handing off the BGP-LS information that they have collected
to a consumer application. The BGP protocol implementation and the to a consumer application. The BGP protocol implementation and the
consumer application may be on the same or different nodes. This consumer application may be on the same or different nodes. This
document only covers the BGP implementation. The consumer document only covers the BGP implementation. The consumer
application and the design of the interface between BGP and the application and the design of the interface between BGP and the
consumer application may be implementation specific and are outside consumer application may be implementation specific and are outside
the scope of this document. The communication of information MUST be the scope of this document. The communication of information <bcp14>MU ST</bcp14> be
unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumer unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumer
application) and a BGP-LS Consumer MUST NOT be able to send application), and a BGP-LS Consumer <bcp14>MUST NOT</bcp14> be able to
information to a BGP Speaker for origination into BGP-LS.</t> send
information to a BGP Speaker for origination into BGP-LS.</dd>
<t>BGP-LS Propagator: The term BGP-LS Propagator refers to a BGP <dt>BGP-LS Propagator:</dt> <dd>The term BGP-LS Propagator refers to a B
GP
Speaker that is performing BGP protocol processing on the link-state Speaker that is performing BGP protocol processing on the link-state
information. The BGP Speaker RRm propagates the BGP-LS information information. BGP Speaker RRm propagates the BGP-LS information
between the BGP Speaker Rn and the BGP Speaker RR1. The BGP between BGP Speaker Rn and BGP Speaker RR1. The BGP
implementation on RRm is propagating BGP-LS information. It performs implementation on RRm is propagating BGP-LS information. It performs
handling of BGP-LS UPDATE messages and performs the BGP Decision handling of BGP-LS UPDATE messages and performs the BGP Decision
Process as part of deciding what information is to be propagated. Process as part of deciding what information is to be propagated.
Similarly, the BGP Speaker RR1 is receiving BGP-LS information from Similarly, BGP Speaker RR1 is receiving BGP-LS information from
R1, R2, and RRm and propagating the information to the BGP-LS R1, R2, and RRm and propagating the information to the BGP-LS
Consumer after performing BGP Decision Process.</t> Consumer after performing BGP Decision Process.</dd>
</list>The above roles are not mutually exclusive. The same BGP </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 Speaker may be the BGP-LS Producer for some link-state information and
BGP-LS Propagator for some other link-state information while also BGP-LS Propagator for some other link-state information while also
providing this information to a BGP-LS Consumer.</t> providing this information to a BGP-LS Consumer.</t>
<t>The rest of this document refers to the role when describing <t>The rest of this document refers to the role when describing
procedures that are specific to that role. When the role is not procedures that are specific to that role. When the role is not
specified, then the said procedure applies to all BGP Speakers.</t> specified, then the said procedure applies to all BGP Speakers.</t>
</section> </section>
<section anchor="IGPTOBGP" numbered="true" toc="default">
<section anchor="IGPTOBGP" title="Advertising IGP Information into BGP-LS"> <name>Advertising IGP Information into BGP-LS</name>
<t>The origination and propagation of IGP link-state information via BGP <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 needs to provide a consistent and accurate view of the topology of the
IGP domain. BGP-LS provides an abstraction of the IGP specifics and IGP domain. BGP-LS provides an abstraction of the IGP specifics, and
BGP-LS Consumers may be varied types of applications.</t> BGP-LS Consumers may be varied types of applications.</t>
<t>The link-state information advertised in BGP-LS from the IGPs is <t>The link-state information advertised in BGP-LS from the IGPs is
derived from the IGP LSDB built using the OSPF Link State Advertisements derived from the IGP LSDB built using the OSPF Link-State Advertisements
(LSAs) or the IS-IS Link State Packets (LSPs). However, it does not (LSAs) or the IS-IS Link-State Packets (LSPs). However, it does not
serve as a verbatim reflection of the originating router's LSDB. It does serve as a verbatim reflection of the originating router's LSDB. It does
not include the LSA/LSP sequence number information since a single not include the LSA/LSP sequence number information since a single
link-state object may be put together with information that is coming link-state object may be put together with information that is coming
from multiple LSAs/LSPs. Also, not all of the information carried in from multiple LSAs/LSPs. Also, not all of the information carried in
LSAs/LSPs may be required or suitable for advertisement via BGP-LS LSAs/LSPs may be required or suitable for advertisement via BGP-LS
(e.g., ASBR reachability in OSPF, OSPF virtual links, link-local scoped (e.g., ASBR reachability in OSPF, OSPF virtual links, link-local-scoped
information, etc.). The LSAs/LSPs that are purged or max-aged are not information, etc.). The LSAs/LSPs that are purged or aged out are not
included in the BGP-LS advertisement even though they may be present in 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 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 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 per the respective IGP protocol specifications are also not included in
the BGP-LS advertisement.</t> the BGP-LS advertisement.</t>
<t>The details of the interface between IGPs and BGP for the <t>The details of the interface between IGPs and BGP for the
advertisement of link-state information are outside the scope of this advertisement of link-state information are outside the scope of this
document. In some cases, the information derived from IGP processing document. In some cases, the information derived from IGP processing
(e.g., combination of link-state object from across multiple LSAs/LSPs, (e.g., combination of link-state object from across multiple LSAs/LSPs,
leveraging reachability and two-way connectivity checks, etc.) is leveraging reachability and two-way connectivity checks, etc.) is
required for advertisement of link-state information into BGP-LS.</t> required for the advertisement of link-state information into BGP-LS.</t>
</section> </section>
<section anchor="BGPLS" numbered="true" toc="default">
<section anchor="BGPLS" title="Carrying Link-State Information in BGP"> <name>Carrying Link-State Information in BGP</name>
<t>The link-state information is carried in BGP UPDATE messages as: (1) <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 BGP NLRI information carried within MP_REACH_NLRI and MP_UNREACH_NLRI
attributes that describes link, node, or prefix object, and (2) a BGP attributes that describes link, node, or prefix objects and (2) a BGP
path attribute (BGP-LS Attribute) that carries properties of the link, path attribute (BGP-LS Attribute) that carries properties of the link,
node, or prefix objects such as the link and prefix metric or auxiliary node, or prefix objects such as the link and prefix metric, auxiliary
Router-IDs of nodes, etc.</t> Router-IDs of nodes, etc.</t>
<t>It is desirable to keep the dependencies on the protocol source of <t>It is desirable to keep the dependencies on the protocol source of
this attribute to a minimum and represent any content in an IGP- neutral this attribute to a minimum and represent any content in an IGP-neutral
way, such that applications that want to learn about a link-state 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 topology do not need to know about any OSPF or IS-IS protocol
specifics.</t> specifics.</t>
<t>This section mainly describes the procedures for a BGP-LS Producer to <t>This section mainly describes the procedures for a BGP-LS Producer to
originate link-state information into BGP-LS.</t> originate link-state information into BGP-LS.</t>
<section anchor="TLV-section" numbered="true" toc="default">
<section anchor="TLV-section" title="TLV Format"> <name>TLV Format</name>
<t>Information in the Link-State NLRIs and the BGP-LS Attribute is <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 encoded in Type/Length/Value triplets. The TLV format is shown in
<xref target="TLV-figure"/> and applies to both the NLRI and the <xref target="TLV-figure" format="default"/> and applies to both the NLR I and the
BGP-LS Attribute encodings.</t> BGP-LS Attribute encodings.</t>
<figure anchor="TLV-figure">
<t><figure anchor="TLV-figure" title="TLV Format"> <name>TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (variable) // // Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The Length field defines the length of the value portion in octets <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 (thus, a TLV with no value portion would have a length of zero). The
TLV is not padded to 4-octet alignment. Unknown and unsupported types TLV is not padded to 4-octet alignment. Unknown and unsupported types
MUST be preserved and propagated within both the NLRI and the BGP-LS <bcp14>MUST</bcp14> be preserved and propagated within both the NLRI and
Attribute. The presence of unknown or unexpected TLVs MUST NOT result the BGP-LS
Attribute. The presence of unknown or unexpected TLVs <bcp14>MUST NOT</b
cp14> result
in the NLRI or the BGP-LS Attribute being considered malformed. An 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 example of an unexpected TLV is when a TLV is received along with an
update for a link state object other than the one that the TLV is update for a link-state object other than the one that the TLV is
specified as associated with.</t> specified as associated with.</t>
<t>To compare NLRIs with unknown TLVs, all TLVs within the NLRI <bcp14>M
<t>To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST UST</bcp14>
be ordered in ascending order by TLV Type. If there are multiple TLVs 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 of the same type within a single NLRI, then the TLVs sharing the same
type MUST be first in ascending order based on the length field type <bcp14>MUST</bcp14> be first in ascending order based on the Length
followed by ascending order based on the value field. Comparison of field
the value fields is performed by treating the entire field as opaque followed by ascending order based on the Value field. Comparison of
the Value fields is performed by treating the entire field as opaque
binary data and ordered lexicographically (i.e., treating each byte of binary data and ordered lexicographically (i.e., treating each byte of
binary data as a symbol to compare, with the symbols ordered by their binary data as a symbol to compare, with the symbols ordered by their
numerical value). NLRIs having TLVs which do not follow the above numerical value). NLRIs having TLVs that do not follow the above
ordering rules MUST be considered as malformed by a BGP-LS Propagator. ordering rules <bcp14>MUST</bcp14> be considered as malformed by a BGP-L
S Propagator.
This insistence on canonical ordering ensures that multiple variant This insistence on canonical ordering ensures that multiple variant
copies of the same NLRI from multiple BGP-LS Producers and the copies of the same NLRI from multiple BGP-LS Producers and the
ambiguity arising therefrom is prevented.</t> ambiguity arising therefrom is prevented.</t>
<t>For both the NLRI and BGP-LS Attribute parts, all TLVs are <t>For both the NLRI and BGP-LS Attribute parts, all TLVs are
considered as optional except where explicitly specified as mandatory considered as optional except where explicitly specified as mandatory
or required in specific conditions.</t> or required in specific conditions.</t>
<t>The TLVs within the BGP-LS Attribute <bcp14>SHOULD</bcp14> be ordered
<t>The TLVs within the BGP-LS Attribute SHOULD be ordered in ascending in ascending
order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be order by TLV type. The BGP-LS Attribute with unordered TLVs <bcp14>MUST
NOT</bcp14> be
considered malformed.</t> considered malformed.</t>
<t>The origination of the same link-state information by multiple <t>The origination of the same link-state information by multiple
BGP-LS Producers may result in differences and inconsistencies due to BGP-LS Producers may result in differences and inconsistencies due to
the inclusion or exclusion of optional TLVs. Different optional TLVs the inclusion or exclusion of optional TLVs. Different optional TLVs
in the NLRI results in multiple NLRIs being generated for the same in the NLRI results in multiple NLRIs being generated for the same
link-state object. Different optional TLVs in the BGP-LS Attribute may link-state object. Different optional TLVs in the BGP-LS Attribute may
result in the propagation of partial information. To address these result in the propagation of partial information. To address these
inconsistencies, the BGP-LS Consumer will need to recognize and merge inconsistencies, the BGP-LS Consumer will need to recognize and merge
the duplicate information, or to deal with missing information. The the duplicate information or deal with missing information. The
deployment of BGP-LS Producers that consistently originate the same deployment of BGP-LS Producers that consistently originate the same
set of optional TLVs is recommended to mitigate such situations.</t> set of optional TLVs is recommended to mitigate such situations.</t>
</section> </section>
<section anchor="BGPLSNLRI" numbered="true" toc="default">
<section anchor="BGPLSNLRI" title="The Link-State NLRI"> <name>The Link-State NLRI</name>
<t>The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's <t>The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's
containers for carrying opaque information. This specification defines containers for carrying opaque information. This specification defines
three Link-State NLRI types that describe either a node, a link, or a three Link-State NLRI types that describe either a node, a link, or a
prefix.</t> prefix.</t>
<t>All non-VPN link, node, and prefix information <bcp14>SHALL</bcp14> b
<t>All non-VPN link, node, and prefix information SHALL be encoded e encoded
using AFI 16388 / SAFI 71. VPN link, node, and prefix information using AFI 16388 / SAFI 71. VPN link, node, and prefix information
SHALL be encoded using AFI 16388 / SAFI 72.</t> <bcp14>SHALL</bcp14> be encoded using AFI 16388 / SAFI 72.</t>
<t>For two BGP Speakers to exchange Link-State NLRI, they <bcp14>MUST</b
<t>For two BGP speakers to exchange Link-State NLRI, they MUST use BGP cp14> use BGP
Capabilities Advertisement to ensure that they are both capable of Capabilities Advertisement to ensure that they are both capable of
properly processing such NLRI. This is done as specified in <xref properly processing such NLRI. This is done as specified in <xref target
target="RFC4760"/>, by using capability code 1 (multiprotocol BGP), ="RFC4760" format="default"/> by using capability code 1 (multiprotocol BGP),
with AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for with AFI 16388 / SAFI 71 for BGP-LS and AFI 16388 / SAFI 72 for
BGP&nbhy;LS&nbhy;VPN.</t> BGP-LS-VPN.</t>
<t>New Link-State NLRI types may be introduced in the future. Since
<t>New Link-State NLRI Types may be introduced in the future. Since
supported NLRI type values within the address family are not expressed supported NLRI type values within the address family are not expressed
in the Multiprotocol BGP (MP-BGP) capability <xref target="RFC4760"/>, in the Multiprotocol BGP (MP-BGP) capability <xref target="RFC4760" form
it is possible that a BGP speaker has advertised support for BGP-LS at="default"/>,
it is possible that a BGP Speaker has advertised support for BGP-LS
but does not support a particular Link-State NLRI type. To allow the but does not support a particular Link-State NLRI type. To allow the
introduction of new Link-State NLRI types seamlessly in the future, introduction of new Link-State NLRI types seamlessly in the future
without the need for upgrading all BGP speakers in the propagation without the need for upgrading all BGP Speakers in the propagation
path (e.g., a route reflector), this document deviates from the path (e.g., a route reflector), this document deviates from the
default handling behavior specified by section 5.4 (paragraph 2) of default handling behavior specified by Section
<xref target="RFC7606"/> for Link-State address-family. An <xref target="RFC7606" format="default" sectionFormat="bare" section="5.
implementation MUST handle unknown Link-State NLRI types as opaque 4"/> (paragraph 2) of <xref target="RFC7606"/> for Link-State address family. An
objects and MUST preserve and propagate them.</t> implementation <bcp14>MUST</bcp14> handle unknown Link-State NLRI types
as opaque
objects and <bcp14>MUST</bcp14> preserve and propagate them.</t>
<t>The format of the Link-State NLRI is shown in the following <t>The format of the Link-State NLRI is shown in the following
figures.</t> figures.</t>
<figure anchor="LSSAFI">
<figure anchor="LSSAFI" <name>Link-State AFI 16388 / SAFI 71 NLRI Format</name>
title="Link-State AFI 16388 / SAFI 71 NLRI Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Link-State NLRI (variable) // // Link-State NLRI (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="LSVPNSAFI">
<figure anchor="LSVPNSAFI" <name>Link-State VPN AFI 16388 / SAFI 72 NLRI Format</name>
title="Link-State VPN AFI 16388 / SAFI 72 NLRI Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Route Distinguisher (8 octets) + + Route Distinguisher (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at line 518 skipping to change at line 463
| | | |
+ Route Distinguisher (8 octets) + + Route Distinguisher (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Link-State NLRI (variable) // // Link-State NLRI (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Total NLRI Length field contains the cumulative length, in <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 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 itself. For VPN applications, it also includes the length of the Route
Distinguisher.</t> Distinguisher.</t>
<table anchor="NLRI-TYPES" align="center">
<texttable anchor="NLRI-TYPES" title="NLRI Types"> <name>NLRI Types</name>
<ttcol align="center">Type</ttcol> <thead>
<tr>
<ttcol align="left">NLRI Type</ttcol> <th align="center">Type</th>
<th align="left">NLRI Type</th>
<c>1</c> </tr>
</thead>
<c>Node NLRI</c> <tbody>
<tr>
<c>2</c> <td align="center">1</td>
<td align="left">Node NLRI</td>
<c>Link NLRI</c> </tr>
<tr>
<c>3</c> <td align="center">2</td>
<td align="left">Link NLRI</td>
<c>IPv4 Topology Prefix NLRI</c> </tr>
<tr>
<c>4</c> <td align="center">3</td>
<td align="left">IPv4 Topology Prefix NLRI</td>
<c>IPv6 Topology Prefix NLRI</c> </tr>
</texttable> <tr>
<td align="center">4</td>
<t>Route Distinguishers are defined and discussed in <xref <td align="left">IPv6 Topology Prefix NLRI</td>
target="RFC4364"/>.</t> </tr>
</tbody>
</table>
<t>Route Distinguishers are defined and discussed in <xref target="RFC43
64" format="default"/>.</t>
<t>The Node NLRI (NLRI Type = 1) is shown in the following figure.</t> <t>The Node NLRI (NLRI Type = 1) is shown in the following figure.</t>
<figure anchor="NODE-NLRI">
<figure anchor="NODE-NLRI" title="The Node NLRI Format"> <name>The Node NLRI Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+ (8 octets) + + (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors TLV (variable) // // Local Node Descriptors TLV (variable) //
skipping to change at line 566 skipping to change at line 512
| Protocol-ID | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+ (8 octets) + + (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors TLV (variable) // // Local Node Descriptors TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Link NLRI (NLRI Type = 2) is shown in the following figure.</t> <t>The Link NLRI (NLRI Type = 2) is shown in the following figure.</t>
<figure anchor="LINK-NLRI">
<figure anchor="LINK-NLRI" title="The Link NLRI Format"> <name>The Link NLRI Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+ (8 octets) + + (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors TLV (variable) // // Local Node Descriptors TLV (variable) //
skipping to change at line 588 skipping to change at line 533
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors TLV (variable) // // Local Node Descriptors TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors TLV (variable) // // Remote Node Descriptors TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors TLVs (variable) // // Link Descriptors TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the <t>The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the
same format, as shown in the following figure.</t> same format as shown in the following figure.</t>
<figure anchor="PREFIX-NLRI">
<figure anchor="PREFIX-NLRI" <name>The IPv4/IPv6 Topology Prefix NLRI Format</name>
title="The IPv4/IPv6 Topology Prefix NLRI Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+ (8 octets) + + (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors TLV (variable) // // Local Node Descriptors TLV (variable) //
skipping to change at line 610 skipping to change at line 553
| Identifier | | Identifier |
+ (8 octets) + + (8 octets) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors TLV (variable) // // Local Node Descriptors TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors TLVs (variable) // // Prefix Descriptors TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Protocol-ID field can contain one of the following values:</t> <t>The Protocol-ID field can contain one of the following values:</t>
<table anchor="PROTOCOL-IDS" align="center">
<texttable anchor="PROTOCOL-IDS" title="Protocol Identifiers"> <name>Protocol Identifiers</name>
<ttcol align="center">Protocol-ID</ttcol> <thead>
<tr>
<ttcol align="left">NLRI information source protocol</ttcol> <th align="center">Protocol-ID</th>
<th align="left">NLRI information source protocol</th>
<c>1</c> </tr>
</thead>
<c>IS-IS Level 1</c> <tbody>
<tr>
<c>2</c> <td align="center">1</td>
<td align="left">IS-IS Level 1</td>
<c>IS-IS Level 2</c> </tr>
<tr>
<c>3</c> <td align="center">2</td>
<td align="left">IS-IS Level 2</td>
<c>OSPFv2</c> </tr>
<tr>
<c>4</c> <td align="center">3</td>
<td align="left">OSPFv2</td>
<c>Direct</c> </tr>
<tr>
<c>5</c> <td align="center">4</td>
<td align="left">Direct</td>
<c>Static configuration</c> </tr>
<tr>
<c>6</c> <td align="center">5</td>
<td align="left">Static configuration</td>
<c>OSPFv3</c> </tr>
</texttable> <tr>
<td align="center">6</td>
<t>The 'Direct' and 'Static configuration' protocol types SHOULD be <td align="left">OSPFv3</td>
</tr>
</tbody>
</table>
<t>The 'Direct' and 'Static configuration' protocol types <bcp14>SHOULD<
/bcp14> be
used when BGP-LS is sourcing local information. For all information used when BGP-LS is sourcing local information. For all information
derived from other protocols, the corresponding Protocol-ID MUST be derived from other protocols, the corresponding Protocol-ID <bcp14>MUST< /bcp14> be
used. If BGP-LS has direct access to interface information and wants used. If BGP-LS has direct access to interface information and wants
to advertise a local link, then the Protocol-ID 'Direct' SHOULD be to advertise a local link, then the Protocol-ID 'Direct' <bcp14>SHOULD</
used. For modeling virtual links, such as described in <xref bcp14> be
target="LINKPATHAGGREGATION"/>, the Protocol-ID 'Static configuration' used. For modeling virtual links, such as described in <xref target="LIN
SHOULD be used.</t> KPATHAGGREGATION" format="default"/>, the Protocol-ID 'Static configuration'
<bcp14>SHOULD</bcp14> be used.</t>
<t>A router may run multiple protocol instances of OSPF or IS-IS <t>A router may run multiple protocol instances of OSPF or IS-IS
whereby it becomes a border router between multiple IGP domains. Both whereby it becomes a border router between multiple IGP domains. Both
OSPF and IS-IS may also run multiple routing protocol instances over OSPF and IS-IS may also run multiple routing protocol instances over
the same link. See <xref target="RFC8202"/> and <xref the same link. See <xref target="RFC8202" format="default"/> and <xref t
target="RFC6549"/>. These instances define independent IGP routing arget="RFC6549" format="default"/>. These instances define independent IGP routi
ng
domains. The Identifier field carries an 8-octet BGP-LS Instance domains. The Identifier field carries an 8-octet BGP-LS Instance
Identifier (Instance-ID) number that is used to identify the IGP Identifier (Instance-ID) number that is used to identify the IGP
routing domain where the NLRI belongs. The NLRIs representing routing domain where the NLRI belongs. The NLRIs representing
link-state objects (nodes, links, or prefixes) from the same IGP link-state objects (nodes, links, or prefixes) from the same IGP
routing instance should have the same BGP-LS Instance-ID. NLRIs with routing instance should have the same BGP-LS Instance-ID. NLRIs with
different BGP-LS Instance-IDs are considered to be from different IGP different BGP-LS Instance-IDs are considered to be from different IGP
routing instances.</t> routing instances.</t>
<t>To support multiple IGP instances, an implementation needs to <t>To support multiple IGP instances, an implementation needs to
support the configuration of unique BGP-LS Instance-IDs at the routing support the configuration of unique BGP-LS Instance-IDs at the routing
protocol instance level. The BGP-LS Instance-ID 0 is RECOMMENDED to be protocol instance level. The BGP-LS Instance-ID 0 is <bcp14>RECOMMENDED< /bcp14> to be
used when there is only a single protocol instance in the network used when there is only a single protocol instance in the network
where BGP-LS is operational. The network operator MUST assign the same where BGP-LS is operational. The network operator <bcp14>MUST</bcp14> as sign the same
BGP-LS Instance-IDs on all BGP-LS Producers within a given IGP domain. BGP-LS Instance-IDs on all BGP-LS Producers within a given IGP domain.
Unique BGP-LS Instance-ID MUST be assigned to routing protocol Unique BGP-LS Instance-IDs <bcp14>MUST</bcp14> be assigned to routing pr otocol
instances operating in different IGP domains. This can allow the instances operating in different IGP domains. This can allow the
BGP-LS Consumer to build an accurate segregated multi-domain topology BGP-LS Consumer to build an accurate segregated multi-domain topology
based on the BGP-LS Instance-ID.</t> based on the BGP-LS Instance-ID.</t>
<t>When the above-described semantics and recommendations are not <t>When the above-described semantics and recommendations are not
followed, a BGP-LS Consumer may see more than one link-state objects followed, a BGP-LS Consumer may see more than one link-state object
for the same node, link, or prefix (each with a different BGP-LS for the same node, link, or prefix (each with a different BGP-LS
Instance-ID) when there are multiple BGP-LS Producers deployed. This Instance-ID) when there are multiple BGP-LS Producers deployed. This
may also result in the BGP-LS Consumers getting an inaccurate may also result in the BGP-LS Consumers getting an inaccurate
network-wide topology.</t> network-wide topology.</t>
<t>Each Node Descriptor, Link Descriptor, and Prefix Descriptor <t>Each Node Descriptor, Link Descriptor, and Prefix Descriptor
consists of one or more TLVs, as described in the following sections. consists of one or more TLVs, as described in the following sections.
These Descriptor TLVs are applicable for the Node, Link, and Prefix These Descriptor TLVs are applicable for the Node, Link, and Prefix
NLRI Types for the protocols that are listed in <xref NLRI Types for the protocols that are listed in <xref target="PROTOCOL-I
target="PROTOCOL-IDS"/>. Documents extending BGP-LS specifications DS" format="default"/>. Documents extending BGP-LS specifications
with new NLRI Types and/or protocols MUST specify the NLRI Descriptors with new NLRI Types and/or protocols <bcp14>MUST</bcp14> specify the NLR
I descriptors
for them.</t> for them.</t>
<t>When adding, removing, or modifying a TLV/sub-TLV from a Link-State <t>When adding, removing, or modifying a TLV/sub-TLV from a Link-State
NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it NLRI, the BGP-LS Producer <bcp14>MUST</bcp14> withdraw the old NLRI by i ncluding it
in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in the MP_UNREACH_NLRI. Not doing so can result in duplicate and
in-consistent link-state objects hanging around in the BGP-LS inconsistent link-state objects hanging around in the BGP-LS
table.</t> table.</t>
<section anchor="NODEDESC" numbered="true" toc="default">
<section anchor="NODEDESC" title="Node Descriptors"> <name>Node Descriptors</name>
<t>Each link is anchored by a pair of Router-IDs that are used by <t>Each link is anchored by a pair of Router-IDs that are used by
the underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a the underlying IGP, 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 32-bit Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
additional auxiliary Router-IDs, mainly for Traffic Engineering additional auxiliary Router-IDs, mainly for Traffic Engineering
purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
Router-IDs <xref target="RFC5305"/> <xref target="RFC6119"/>. When Router-IDs <xref target="RFC5305" format="default"/> <xref target="RFC
configured, these auxiliary TE Router-IDs (TLV 1028/1029) MUST be 6119" format="default"/>. When
included in the node attribute described in <xref configured, these auxiliary TE Router-IDs (TLV 1028/1029) <bcp14>MUST<
target="NODEATTR"/> and MAY be included in the link attribute /bcp14> be
described in <xref target="link_attribute"/>. The advertisement of included in the node attribute described in <xref target="NODEATTR" fo
rmat="default"/> and <bcp14>MAY</bcp14> be included in the link attribute
described in <xref target="link_attribute" format="default"/>. The adv
ertisement of
the TE Router-IDs can help a BGP-LS Consumer to correlate multiple the TE Router-IDs can help a BGP-LS Consumer to correlate multiple
link-state objects (e.g. in different IGP instances or areas/levels) link-state objects (e.g., in different IGP instances or areas/levels)
to the same node in the network.</t> to the same node in the network.</t>
<t>It is desirable that the Router-ID assignments inside the Node <t>It is desirable that the Router-ID assignments inside the Node
Descriptors are globally unique. However, there may be Router-ID Descriptors are globally unique. However, there may be Router-ID
spaces (e.g., ISO) where no global registry exists, or worse, spaces (e.g., ISO) where no global registry exists, or worse,
Router-IDs have been allocated following the private-IP allocation Router-IDs have been allocated following the private-IP allocation
described in <xref target="RFC1918"/>. BGP-LS uses the Autonomous described in <xref target="RFC1918" format="default"/>. BGP-LS uses th
System (AS) Number to disambiguate the Router-IDs, as described in e Autonomous
<xref target="gbl_uniqueness"/>.</t> System Number to disambiguate the Router-IDs, as described in
<xref target="gbl_uniqueness" format="default"/>.</t>
<section anchor="gbl_uniqueness" <section anchor="gbl_uniqueness" numbered="true" toc="default">
title="Globally Unique Node/Link/Prefix Identifiers"> <name>Globally Unique Node/Link/Prefix Identifiers</name>
<t>One problem that needs to be addressed is the ability to <t>One problem that needs to be addressed is the ability to
identify an IGP node globally (by "globally", we mean within the identify an IGP node globally (by "globally", we mean within the
BGP-LS database collected by all BGP-LS speakers that talk to each BGP-LS database collected by all BGP-LS Speakers that talk to each
other). This can be expressed through the following two other). This can be expressed through the following two
requirements: <list hangIndent="6" style="hanging"> requirements: </t>
<t hangText="(A)">The same node MUST NOT be represented by two <ol spacing="normal" type="(%C)" indent="6">
keys (otherwise, one node will look like two nodes).</t> <li>The same node <bcp14>MUST NOT</bcp14> be represented by two
keys (otherwise, one node will look like two nodes).</li>
<t hangText="(B)">Two different nodes MUST NOT be represented <li>Two different nodes <bcp14>MUST NOT</bcp14> be represented
by the same key (otherwise, two nodes will look like one by the same key (otherwise, two nodes will look like one
node).</t> node).</li>
</list></t> </ol>
<t>We define an "IGP domain" to be the set of nodes (hence, by <t>We define an "IGP domain" to be the set of nodes (hence, by
extension links and prefixes) within which each node has a unique extension, links and prefixes) within which each node has a unique
IGP representation by using the combination of OSPF Area-ID, IGP representation by using the combination of OSPF Area-ID,
Router-ID, Protocol-ID, Multi-Topology ID, and BGP-LS Instance-ID. Router-ID, Protocol-ID, Multi-Topology Identifier (MT-ID), and BGP-L S Instance-ID.
The problem is that BGP may receive node/link/prefix information The problem is that BGP may receive node/link/prefix information
from multiple independent "IGP domains", and we need to from multiple independent "IGP domains", and we need to
distinguish between them. Moreover, we can't assume there is distinguish between them. Moreover, we can't assume there is
always one and only one IGP domain per AS. During IGP transitions, always one and only one IGP domain per AS. During IGP transitions,
it may happen that two redundant IGPs are in place.</t> it may happen that two redundant IGPs are in place.</t>
<t>Furthermore, in deployments where BGP-LS is used to advertise <t>Furthermore, in deployments where BGP-LS is used to advertise
topology from multiple-ASes, the AS Number is used to distinguish topology from multiple ASes, the Autonomous System Number (ASN) is u sed to distinguish
topology information reported from different ASes.</t> topology information reported from different ASes.</t>
<t>The BGP-LS Instance-ID carried in the Identifier field, as
<t>The BGP-LS Instance-ID carried in the Identifier field as described earlier along with a set of sub-TLVs described in <xref ta
described earlier along with a set of sub-TLVs described in <xref rget="node_desc_tlvs" format="default"/>, allows specification of a flexible key
target="node_desc_tlvs"/>, allows specification of a flexible key
for any given node/link information such that the global for any given node/link information such that the global
uniqueness of the NLRI is ensured. Since the BGP-LS Instance-ID is uniqueness of the NLRI is ensured. Since the BGP-LS Instance-ID is
operator assigned, its allocation scheme can ensure that each IGP operator assigned, its allocation scheme can ensure that each IGP
domain is uniquely identified even across a multi-AS network.</t> domain is uniquely identified even across a multi-AS network.</t>
</section> </section>
<section anchor="LOCALNODEDESC" numbered="true" toc="default">
<section anchor="LOCALNODEDESC" title="Local Node Descriptors"> <name>Local Node Descriptors</name>
<t>The Local Node Descriptors TLV contains Node Descriptors for <t>The Local Node Descriptors TLV contains Node Descriptors for
the node anchoring the local end of the link. This is a mandatory 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 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 is 256. The length of this TLV is variable. The value contains one
or more Node Descriptor Sub-TLVs defined in <xref or more Node Descriptor sub-TLVs defined in <xref target="node_desc_
target="node_desc_tlvs"/>.</t> tlvs" format="default"/>.</t>
<figure anchor="LOCALNODEDESCTLV">
<figure anchor="LOCALNODEDESCTLV" <name>Local Node Descriptors TLV Format</name>
title="Local Node Descriptors TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Node Descriptor Sub-TLVs (variable) // // Node Descriptor Sub-TLVs (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="REMOTENODEDESC" numbered="true" toc="default">
<section anchor="REMOTENODEDESC" title="Remote Node Descriptors"> <name>Remote Node Descriptors</name>
<t>The Remote Node Descriptors TLV contains Node Descriptors for <t>The Remote Node Descriptors TLV contains Node Descriptors for
the node anchoring the remote end of the link. This is a mandatory the node anchoring the remote end of the link. This is a mandatory
TLV for Link NLRIs. The type is 257. The length of this TLV is TLV for Link NLRIs. The Type is 257. The length of this TLV is
variable. The value contains one or more Node Descriptor Sub-TLVs variable. The value contains one or more Node Descriptor sub-TLVs
defined in <xref target="node_desc_tlvs"/>.</t> defined in <xref target="node_desc_tlvs" format="default"/>.</t>
<figure anchor="REMOTENODEDESCTLV">
<figure anchor="REMOTENODEDESCTLV" <name>Remote Node Descriptors TLV Format</name>
title="Remote Node Descriptors TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Node Descriptor Sub-TLVs (variable) // // Node Descriptor Sub-TLVs (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="node_desc_tlvs" numbered="true" toc="default">
<section anchor="node_desc_tlvs" title="Node Descriptor Sub-TLVs"> <name>Node Descriptor Sub-TLVs</name>
<t>The Node Descriptor Sub-TLV type code points and lengths are <t>The Node Descriptor sub-TLV type code points and lengths are
listed in the following table:</t> listed in the following table:</t>
<table anchor="table_local_anchor_node_tlv" align="center">
<texttable anchor="table_local_anchor_node_tlv" <name>Node Descriptor Sub-TLVs</name>
title="Node Descriptor Sub-TLVs"> <thead>
<ttcol align="center">Sub-TLV Code Point</ttcol> <tr>
<th align="center">Sub-TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="right">Length</th>
<ttcol align="right">Length</ttcol> </tr>
</thead>
<c>512</c> <tbody>
<tr>
<c>Autonomous System</c> <td align="center">512</td>
<td align="left">Autonomous System</td>
<c>4</c> <td align="right">4</td>
</tr>
<c>513</c> <tr>
<td align="center">513</td>
<c>BGP-LS Identifier (deprecated)</c> <td align="left">BGP-LS Identifier (deprecated)</td>
<td align="right">4</td>
<c>4</c> </tr>
<tr>
<c>514</c> <td align="center">514</td>
<td align="left">OSPF Area-ID</td>
<c>OSPF Area-ID</c> <td align="right">4</td>
</tr>
<c>4</c> <tr>
<td align="center">515</td>
<c>515</c> <td align="left">IGP Router-ID</td>
<td align="right">Variable</td>
<c>IGP Router-ID</c> </tr>
</tbody>
<c>Variable</c> </table>
</texttable>
<t>The sub-TLV values in Node Descriptor TLVs are defined as <t>The sub-TLV values in Node Descriptor TLVs are defined as
follows:</t> follows:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Autonomous System:</dt>
<t hangText="Autonomous System:">Opaque value (32-bit AS <dd>Opaque value (32-bit AS
Number). This is an optional TLV. The value SHOULD be set to Number). This is an optional TLV. The value <bcp14>SHOULD</bcp14
> be set to
the AS Number associated with the BGP process originating the the AS Number associated with the BGP process originating the
link-state information. An implementation MAY provide a link-state information. An implementation <bcp14>MAY</bcp14> pro vide a
configuration option on the BGP-LS Producer to use a different configuration option on the BGP-LS Producer to use a different
value; e.g., to avoid collisions when using private AS value, e.g., to avoid collisions when using private AS
numbers.</t> Numbers.</dd>
<dt>BGP-LS Identifier:</dt>
<t hangText="BGP-LS Identifier:">Opaque value (32-bit ID). <dd>Opaque value (32-bit ID).
This is an optional TLV which has been deprecated by this This is an optional TLV that has been deprecated by this
document (refer to <xref target="CHANGES"/> for more details). document (refer to <xref target="CHANGES" format="default"/> for
It MAY be advertised for compatibility with <xref more details).
target="RFC7752"/> implementations. See the final paragraph of It <bcp14>MAY</bcp14> be advertised for compatibility with <xref
this section for further considerations and recommended target="RFC7752" format="default"/> implementations. See the final paragraph of
default value.</t> this section for further considerations and a recommended
default value.</dd>
<t hangText="OSPF Area-ID:">Used to identify the 32-bit area <dt>OSPF Area-ID:</dt>
<dd>Used to identify the 32-bit area
to which the information advertised in the NLRI belongs. This to which the information advertised in the NLRI belongs. This
is a mandatory TLV when originating information from OSPF that is a mandatory TLV when originating information from OSPF that
is derived from area-scope LSAs. The OSPF Area Identifier is derived from area-scope LSAs. The OSPF Area Identifier
allows different NLRIs of the same router to be differentiated allows different NLRIs of the same router to be differentiated
on a per-area basis. It is not used for NLRIs when carrying on a per-area basis. It is not used for NLRIs when carrying
information that is derived from AS-scope LSAs as that information that is derived from AS-scope LSAs as that
information is not associated with a specific area.</t> information is not associated with a specific area.</dd>
<dt>IGP Router-ID:</dt>
<t hangText="IGP Router-ID:">Opaque value. This is a mandatory <dd>Opaque value. This is a mandatory TLV when
TLV when originating information from IS-IS, OSPF, direct or originating information from IS-IS, OSPF, 'Direct', or 'Static
static. For an IS-IS non-pseudonode, this contains a 6-octet configuration'. For an IS-IS non-pseudonode, this contains a 6-octe
ISO Node-ID (ISO system-ID). For an IS-IS pseudonode t
ISO Node-ID (ISO System-ID). For an IS-IS pseudonode
corresponding to a LAN, this contains the 6-octet ISO Node-ID corresponding to a LAN, this contains the 6-octet ISO Node-ID
of the Designated Intermediate System (DIS) followed by a of the Designated Intermediate System (DIS) followed by a
1-octet, nonzero PSN identifier (7 octets in total). For an 1-octet, nonzero PSN identifier (7 octets in total). For an
OSPFv2 or OSPFv3 non-pseudonode, this contains the 4-octet OSPFv2 or OSPFv3 non-pseudonode, this contains the 4-octet
Router-ID. For an OSPFv2 pseudonode representing a LAN, this Router-ID. For an OSPFv2 pseudonode representing a LAN, this
contains the 4-octet Router-ID of the Designated Router (DR) contains the 4-octet Router-ID of the Designated Router (DR)
followed by the 4-octet IPv4 address of the DR's interface to followed by the 4-octet IPv4 address of the DR's interface to
the LAN (8 octets in total). Similarly, for an OSPFv3 the LAN (8 octets in total). Similarly, for an OSPFv3
pseudonode, this contains the 4-octet Router-ID of the DR pseudonode, this contains the 4-octet Router-ID of the DR
followed by the 4-octet interface identifier of the DR's followed by the 4-octet interface identifier of the DR's
interface to the LAN (8 octets in total). The TLV size in interface to the LAN (8 octets in total). The TLV size in
combination with the protocol identifier enables the decoder combination with the protocol identifier enables the decoder
to determine the type of the node. For Direct or Static to determine the type of the node. For 'Direct' or 'Static
configuration, the value SHOULD be taken from an IPv4 or IPv6 configuration', the value <bcp14>SHOULD</bcp14> be taken from an
address (e.g. loopback interface) configured on the node. When IPv4 or IPv6
the node is running an IGP protocol, an implementation MAY address (e.g., loopback interface) configured on the node. Wh
choose to use the IGP Router-ID for direct or static.</t> en the node is running an IGP protocol,
</list></t> an implementation <bcp14>MAY</bcp14> choose to use the IGP Router-ID for 'Dir
ect'
<t>There MUST be at most one instance of each sub-TLV type present or 'Static configuration'.</dd>
in any Node Descriptor. The sub-TLVs within a Node Descriptor MUST </dl>
<t>At most, there <bcp14>MUST</bcp14> be one instance of each sub-TL
V type present
in any Node Descriptor. The sub-TLVs within a Node Descriptor <bcp14
>MUST</bcp14>
be arranged in ascending order by sub-TLV type. This needs to be be arranged in ascending order by sub-TLV type. This needs to be
done to compare NLRIs, even when an implementation encounters an done to compare NLRIs, even when an implementation encounters an
unknown sub-TLV. Using stable sorting, an implementation can do a unknown sub-TLV. Using stable sorting, an implementation can do a
binary comparison of NLRIs and hence allow incremental deployment binary comparison of NLRIs and hence allow incremental deployment
of new key sub-TLVs.</t> of new key sub-TLVs.</t>
<t>The BGP-LS Identifier was introduced by <xref target="RFC7752" fo
<t>The BGP-LS Identifier was introduced by <xref rmat="default"/>, and its use is being deprecated by this
target="RFC7752"/> and its use is being deprecated by this document. Implementations <bcp14>SHOULD</bcp14> support the advertis
document. Implementations SHOULD support the advertisement of this ement of this
sub-TLV for backward compatibility in deployments where there are sub-TLV for backward compatibility in deployments where there are
BGP-LS Producer implementations that conform to <xref BGP-LS Producer implementations that conform to <xref target="RFC775
target="RFC7752"/> to ensure consistency of NLRI encoding for 2" format="default"/> to ensure consistency of NLRI encoding for
link-state objects. The default value of 0 is RECOMMENDED to be link-state objects. The default value of 0 is <bcp14>RECOMMENDED</bc
p14> to be
used when a BGP-LS Producer includes this sub-TLV when originating used when a BGP-LS Producer includes this sub-TLV when originating
information into BGP-LS. Implementations SHOULD provide an option information into BGP-LS. Implementations <bcp14>SHOULD</bcp14> provi de an option
to configure this value for backward compatibility reasons. As a to configure this value for backward compatibility reasons. As a
reminder, the use of the BGP-LS Instance-ID that is carried in the 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 Identifier field is the way of segregation of link-state objects
of different IGP domains in BGP-LS.</t> of different IGP domains in BGP-LS.</t>
</section> </section>
</section> </section>
<section anchor="LINKDESC" numbered="true" toc="default">
<section anchor="LINKDESC" title="Link Descriptors"> <name>Link Descriptors</name>
<t>The Link Descriptor field is a set of Type/Length/Value (TLV) <t>The Link Descriptor field is a set of Type/Length/Value (TLV)
triplets. The format of each TLV is shown in <xref triplets. The format of each TLV is shown in <xref target="TLV-section
target="TLV-section"/>. The Link Descriptor TLVs uniquely identify a " format="default"/>. The Link Descriptor TLVs uniquely identify a
link among multiple parallel links between a pair of anchor routers. link among multiple parallel links between a pair of anchor routers.
A link described by the Link Descriptor TLVs actually is a A link described by the Link Descriptor TLVs actually is a
"half-link", a unidirectional representation of a logical link. To "half-link", a unidirectional representation of a logical link. To
fully describe a single logical link, two anchor routers advertise a fully describe a single logical link, two anchor routers advertise a
half-link each, i.e., two Link NLRIs are advertised for a given half-link each, i.e., two Link NLRIs are advertised for a given
point-to-point link.</t> point-to-point link.</t>
<t>A link between two nodes is not considered as complete (or <t>A link between two nodes is not considered as complete (or
available) unless it is described by the two Link NLRIs available) unless it is described by the two Link NLRIs
corresponding to the half-link representation from the pair of corresponding to the half-link representation from the pair of
anchor nodes. This check is similar to the 'two-way connectivity anchor nodes. This check is similar to the 'two-way connectivity
check' that is performed by link-state IGPs.</t> check' that is performed by link-state IGPs.</t>
<t>An implementation <bcp14>MAY</bcp14> suppress the advertisement of
<t>An implementation MAY suppress the advertisement of a Link NLRI, a Link NLRI,
corresponding to a half-link, from a link-state IGP unless the IGP 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 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 OSPF Router LSA by both the nodes connected by that link. This
'two-way connectivity check' is performed by link-state IGPs during 'two-way connectivity check' is performed by link-state IGPs during
their computation and can be leveraged before passing information their computation and can be leveraged before passing information
for any half-link that is reported from these IGPs into BGP-LS. This for any half-link that is reported from these IGPs into BGP-LS. This
ensures that only those Link State IGP adjacencies which are ensures that only those link-state IGP adjacencies that are
established get reported via Link NLRIs. Such a 'two-way established get reported via Link NLRIs. Such a 'two-way
connectivity check' could be also required in certain cases (e.g., connectivity check' could also be required in certain cases (e.g.,
with OSPF) to obtain the proper link identifiers of the remote with OSPF) to obtain the proper link identifiers of the remote
node.</t> node.</t>
<t>The format and semantics of the Value fields in most Link <t>The format and semantics of the Value fields in most Link
Descriptor TLVs correspond to the format and semantics of value Descriptor TLVs correspond to the format and semantics of Value
fields in IS-IS Extended IS Reachability sub-TLVs, defined in <xref fields in IS-IS Extended IS Reachability sub-TLVs, which are defined i
target="RFC5305"/>, <xref target="RFC5307"/>, and <xref n <xref target="RFC5305" format="default"/>, <xref target="RFC5307" format="defa
target="RFC6119"/>. Although the encodings for Link Descriptor TLVs ult"/>, and <xref target="RFC6119" format="default"/>. Although the encodings fo
r Link Descriptor TLVs
were originally defined for IS-IS, the TLVs can carry data sourced were originally defined for IS-IS, the TLVs can carry data sourced
by either IS-IS or OSPF.</t> by either IS-IS or OSPF.</t>
<t>The following TLVs are defined as Link Descriptors in the Link <t>The following TLVs are defined as Link Descriptors in the Link
NLRI:</t> NLRI:</t>
<table anchor="table_link_descriptor_tlv" align="center">
<texttable anchor="table_link_descriptor_tlv" <name>Link Descriptor TLVs</name>
title="Link Descriptor TLVs"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="center">IS-IS TLV/Sub-TLV</th>
<ttcol align="center">IS-IS TLV/Sub-TLV</ttcol> <th align="left">Reference</th>
</tr>
<ttcol align="left">Reference (RFC/Section)</ttcol> </thead>
<tbody>
<c>258</c> <tr>
<td align="center">258</td>
<c>Link Local/Remote Identifiers</c> <td align="left">Link Local/Remote Identifiers</td>
<td align="center">22/4</td>
<c>22/4</c> <td align="left"><xref target="RFC5307" sectionFormat="comma" se
ction="1.1"/></td>
<c><xref target="RFC5307"/> / 1.1</c> </tr>
<tr>
<c>259</c> <td align="center">259</td>
<td align="left">IPv4 interface address</td>
<c>IPv4 interface address</c> <td align="center">22/6</td>
<td align="left"><xref target="RFC5305" sectionFormat="comma" se
<c>22/6</c> ction="3.2"/></td>
</tr>
<c><xref target="RFC5305"/> / 3.2</c> <tr>
<td align="center">260</td>
<c>260</c> <td align="left">IPv4 neighbor address</td>
<td align="center">22/8</td>
<c>IPv4 neighbor address</c> <td align="left"><xref target="RFC5305" sectionFormat="comma" se
ction="3.3"/></td>
<c>22/8</c> </tr>
<tr>
<c><xref target="RFC5305"/> / 3.3</c> <td align="center">261</td>
<td align="left">IPv6 interface address</td>
<c>261</c> <td align="center">22/12</td>
<td align="left"><xref target="RFC6119" sectionFormat="comma" se
<c>IPv6 interface address</c> ction="4.2"/></td>
</tr>
<c>22/12</c> <tr>
<td align="center">262</td>
<c><xref target="RFC6119"/> / 4.2</c> <td align="left">IPv6 neighbor address</td>
<td align="center">22/13</td>
<c>262</c> <td align="left"><xref target="RFC6119" sectionFormat="comma" se
ction="4.3"/></td>
<c>IPv6 neighbor address</c> </tr>
<tr>
<c>22/13</c> <td align="center">263</td>
<td align="left">Multi-Topology Identifier</td>
<c><xref target="RFC6119"/> / 4.3</c> <td align="center">---</td>
<td align="left"><xref target="MT-ID" format="default"/></td>
<c>263</c> </tr>
</tbody>
<c>Multi-Topology Identifier</c> </table>
<c>---</c>
<c><xref target="MT-ID"/></c>
</texttable>
<t>The information about a link present in the LSA/LSP originated by <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 the local node of the link determines the set of TLVs in the Link
Descriptor of the link. <list style="hanging"> Descriptor of the link. </t>
<t>If interface and neighbor addresses, either IPv4 or IPv6, are <t indent="3">If interface and neighbor addresses, either IPv4 or IP
present, then the interface/neighbor address TLVs MUST be v6, are
included, and the Link Local/Remote Identifiers TLV MUST NOT be present, then the interface/neighbor address TLVs <bcp14>MUST</bcp
14> be
included, and the Link Local/Remote Identifiers TLV <bcp14>MUST NO
T</bcp14> be
included in the Link Descriptor. The Link Local/Remote included in the Link Descriptor. The Link Local/Remote
Identifiers TLV MAY be included in the link attribute when Identifiers TLV <bcp14>MAY</bcp14> be included in the link attribu
available. IPv4/IPv6 link-local addresses MUST NOT be carried in te when
available. IPv4/IPv6 link-local addresses <bcp14>MUST NOT</bcp14>
be carried in
the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262) the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262)
as descriptors of a link as they are not considered unique.</t> as descriptors of a link since they are not considered unique.</t>
<t indent="3">If interface and neighbor addresses are not present an
<t>If interface and neighbor addresses are not present and the d the
link local/remote identifiers are present, then the Link link local/remote identifiers are present, then the Link
Local/Remote Identifiers TLV MUST be included in the Link Local/Remote Identifiers TLV <bcp14>MUST</bcp14> be included in th
Descriptor. The Link Local/Remote Identifiers MUST be included e Link
in the Link Descriptor also in the case of links having only Descriptor. The Link Local/Remote identifiers <bcp14>MUST</bcp14>
be included
in the Link Descriptor and in the case of links having only
IPv6 link-local addressing on them.</t> IPv6 link-local addressing on them.</t>
<t indent="3">The Multi-Topology Identifier TLV <bcp14>MUST</bcp14>
<t>The Multi-Topology Identifier TLV MUST be included as a Link be included as a Link
Descriptor if the underlying IGP link object is associated with Descriptor if the underlying IGP link object is associated with
a non-default topology.</t> a non-default topology.</t>
</list></t>
<t>The TLVs/sub-TLVs corresponding to the interface addresses and/or <t>The TLVs/sub-TLVs corresponding to the interface addresses and/or
the local/remote identifiers may not always be signaled in the IGPs the local/remote identifiers may not always be signaled in the IGPs
unless their advertisement is enabled specifically. In such cases, unless their advertisement is enabled specifically. In such cases,
it is valid to advertise a BGP-LS Link NLRI without any of these it is valid to advertise a BGP-LS Link NLRI without any of these
identifiers.</t> identifiers.</t>
<section anchor="MT-ID" numbered="true" toc="default">
<section anchor="MT-ID" title="Multi-Topology ID"> <name>Multi-Topology Identifier</name>
<t>The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or <t>The Multi-Topology Identifier (MT-ID) TLV carries one or more IS-
OSPF Multi-Topology IDs for a link, node, or prefix.</t> IS or
OSPF Multi-Topology Identifiers for a link, node, or prefix.</t>
<t>The semantics of the IS-IS MT-ID are defined in sections 7.1 <t>The semantics of the IS-IS MT-ID are defined in Sections <xref ta
and 7.2 of <xref target="RFC5120"/>. The semantics of the OSPF rget="RFC5120" section="7.1" sectionFormat="bare"/> and
MT-ID are defined in section 3.7 of <xref target="RFC4915"/>. If <xref target="RFC5120" section="7.2" sectionFormat="bare"/> of <xref
target="RFC5120" format="default"/>. The semantics of the OSPF
MT-ID are defined in <xref target="RFC4915" section="3.7" sectionFor
mat="of" format="default"/>. If
the value in the MT-ID TLV is derived from OSPF, then the upper R the value in the MT-ID TLV is derived from OSPF, then the upper R
bits of the MT-ID field MUST be set to 0 and only the values from bits of the MT-ID field <bcp14>MUST</bcp14> be set to 0 and only the values from
0 to 127 are valid for the MT-ID.</t> 0 to 127 are valid for the MT-ID.</t>
<t>The format of the MT-ID TLV is shown in the following <t>The format of the MT-ID TLV is shown in the following
figure.</t> figure.</t>
<t><figure anchor="MTIDTLV" title="Multi-Topology ID TLV Format"> <figure anchor="MTIDTLV">
<artwork><![CDATA[ <name>Multi-Topology Identifier TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... // |R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n | // .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The Type is 263, the length is 2*n, and n is the number of MT-IDs
<t>where Type is 263, Length is 2*n, and n is the number of MT-IDs
carried in the TLV.</t> carried in the TLV.</t>
<t>The MT-ID TLV <bcp14>MAY</bcp14> be included as a Link Descriptor
<t>The MT-ID TLV MAY be included as a Link Descriptor, a Prefix , as a Prefix
Descriptor, or in the BGP-LS Attribute of a Node NLRI. When 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 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 containing the MT-ID of the topology where the link or the prefix
is reachable is allowed. In case one wants to advertise multiple is reachable is allowed. In case one wants to advertise multiple
topologies for a given Link Descriptor or Prefix Descriptor, topologies for a given Link or Prefix Descriptor,
multiple NLRIs MUST be generated where each NLRI contains a single multiple NLRIs <bcp14>MUST</bcp14> be generated where each NLRI cont
ains a single
unique MT-ID. When used as a Link or Prefix Descriptor for IS-IS, unique MT-ID. When used as a Link or Prefix Descriptor for IS-IS,
the Bits R are reserved and MUST be set to 0 (as per section 7.2 the Bits R are reserved and <bcp14>MUST</bcp14> be set to 0 (as per
of <xref target="RFC5120"/>) when originated and ignored on <xref target="RFC5120" section="7.2" sectionFormat="of" format="default"/>) when
originated and ignored on
receipt.</t> receipt.</t>
<t>In the BGP-LS Attribute of a Node NLRI, one MT-ID TLV <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 containing the array of MT-IDs of all topologies where the node is
reachable is allowed. When used in the Node Attribute TLV for reachable is allowed. When used in the Node Attribute TLV for
IS-IS, the Bits R are set as per section 7.1 of <xref IS-IS, the Bits R are set as per <xref target="RFC5120" section="7.1
target="RFC5120"/>.</t> " sectionFormat="of" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="PREFIXDESC" numbered="true" toc="default">
<section anchor="PREFIXDESC" title="Prefix Descriptors"> <name>Prefix Descriptors</name>
<t>The Prefix Descriptor field is a set of Type/Length/Value (TLV) <t>The Prefix Descriptor field is a set of Type/Length/Value (TLV)
triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6
prefix originated by a node. The following TLVs are defined as prefix originated by a node. The following TLVs are defined as
Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:</t> Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:</t>
<texttable anchor="table_prefix_descriptor_tlv" <table anchor="table_prefix_descriptor_tlv" align="center">
title="Prefix Descriptor TLVs"> <name>Prefix Descriptor TLVs</name>
<ttcol align="center">TLV Code Point</ttcol> <thead>
<tr>
<ttcol align="left">Description</ttcol> <th align="center">TLV Code Point</th>
<th align="left">Description</th>
<ttcol align="center">Length</ttcol> <th align="center">Length</th>
<th align="left">Reference</th>
<ttcol align="left">Reference (RFC/Section)</ttcol> </tr>
</thead>
<c>263</c> <tbody>
<tr>
<c>Multi-Topology Identifier</c> <td align="center">263</td>
<td align="left">Multi-Topology Identifier</td>
<c>variable</c> <td align="center">variable</td>
<td align="left">
<c><xref target="MT-ID"/></c> <xref target="MT-ID" format="default"/></td>
</tr>
<c>264</c> <tr>
<td align="center">264</td>
<c>OSPF Route Type</c> <td align="left">OSPF Route Type</td>
<td align="center">1</td>
<c>1</c> <td align="left">
<xref target="OSPFRTETYPE" format="default"/></td>
<c><xref target="OSPFRTETYPE"/></c> </tr>
<tr>
<c>265</c> <td align="center">265</td>
<td align="left">IP Reachability Information</td>
<c>IP Reachability Information</c> <td align="center">variable</td>
<td align="left">
<c>variable</c> <xref target="IPREACHINFO" format="default"/></td>
</tr>
<c><xref target="IPREACHINFO"/></c> </tbody>
</texttable> </table>
<t>The Multi-Topology Identifier TLV <bcp14>MUST</bcp14> be included i
<t>The Multi-Topology Identifier TLV MUST be included in the Prefix n the Prefix
Descriptor if the underlying IGP prefix object is associated with a Descriptor if the underlying IGP prefix object is associated with a
non-default topology.</t> non-default topology.</t>
<section anchor="OSPFRTETYPE" numbered="true" toc="default">
<section anchor="OSPFRTETYPE" title="OSPF Route Type"> <name>OSPF Route Type</name>
<t>The OSPF Route Type TLV is an optional TLV corresponding to <t>The OSPF Route Type TLV is an optional TLV corresponding to
Prefix NLRIs originated from OSPF. It is used to identify the OSPF Prefix NLRIs originated from OSPF. It is used to identify the OSPF
route type of the prefix. An OSPF prefix MAY be advertised in the route type of the prefix. An OSPF prefix <bcp14>MAY</bcp14> be adver tised in the
OSPF domain with multiple route types. The Route Type TLV allows OSPF domain with multiple route types. The Route Type TLV allows
the discrimination of these advertisements. The OSPF Route Type the discrimination of these advertisements. The OSPF Route Type
TLV MUST be included in the advertisement when the type is either TLV <bcp14>MUST</bcp14> be included in the advertisement when the ty pe is either
being signaled explicitly in the underlying LSA or can be being signaled explicitly in the underlying LSA or can be
determined via another LSA for the same prefix when it is not determined via another LSA for the same prefix when it is not
signaled explicitly (e.g., in the case of OSPFv2 Extended Prefix signaled explicitly (e.g., in the case of OSPFv2 Extended Prefix
Opaque LSA <xref target="RFC7684"/>). The route type advertised in Opaque LSA <xref target="RFC7684" format="default"/>). The route typ
the OSPFv2 Extended Prefix TLV (section 2.1 of <xref e advertised in
target="RFC7684"/>) does not make a distinction between Type 1 and the OSPFv2 Extended Prefix TLV (<xref target="RFC7684" section="2.1"
2 for AS external and NSSA external routes. In this case, the sectionFormat="of" format="default"/>) does not make a distinction between Type
1 and
2 for AS external and Not-So-Stubby Area (NSSA) external routes. In
this case, the
route type to be used in the BGP-LS advertisement can be route type to be used in the BGP-LS advertisement can be
determined by checking the OSPFv2 External or NSSA External LSA determined by checking the OSPFv2 External or NSSA External LSA
for the prefix. A similar check for the base OSPFv2 LSAs can be 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 done to determine the route type to be used when the route type
value 0 is carried in the OSPFv2 Extended Prefix TLV.</t> 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 <t>The format of the OSPF Route Type TLV is shown in the following
figure.</t> figure.</t>
<figure anchor="ROUTETYPETLV">
<figure anchor="ROUTETYPETLV" title="OSPF Route Type TLV Format"> <name>OSPF Route Type TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | | Route Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Type and Length fields of the TLV are defined in
<t>where the Type and Length fields of the TLV are defined in <xref target="table_prefix_descriptor_tlv" format="default"/>. The R
<xref target="table_prefix_descriptor_tlv"/>. The OSPF Route Type oute Type
field follows the route types defined in the OSPF protocol and can field follows the route types defined in the OSPF protocol and can
be one of the following: <list style="symbols"> be one of the following: </t>
<t>Intra-Area (0x1)</t> <ul spacing="normal">
<li>Intra-Area (0x1)</li>
<t>Inter-Area (0x2)</t> <li>Inter-Area (0x2)</li>
<li>External 1 (0x3)</li>
<t>External 1 (0x3)</t> <li>External 2 (0x4)</li>
<li>NSSA 1 (0x5)</li>
<t>External 2 (0x4)</t> <li>NSSA 2 (0x6)</li>
</ul>
<t>NSSA 1 (0x5)</t>
<t>NSSA 2 (0x6)</t>
</list></t>
</section> </section>
<section anchor="IPREACHINFO" numbered="true" toc="default">
<section anchor="IPREACHINFO" title="IP Reachability Information"> <name>IP Reachability Information</name>
<t>The IP Reachability Information TLV is a mandatory TLV for IPv4 <t>The IP Reachability Information TLV is a mandatory TLV for IPv4
&amp; IPv6 Prefix NLRI types. The TLV contains one IP address &amp; IPv6 Prefix NLRI types. The TLV contains one IP address
prefix (IPv4 or IPv6) originally advertised in the IGP topology. A prefix (IPv4 or IPv6) originally advertised in the IGP topology. A
router SHOULD advertise an IP Prefix NLRI for each of its BGP router <bcp14>SHOULD</bcp14> advertise an IP Prefix NLRI for each of
next-hops. The format of the IP Reachability Information TLV is its BGP
next hops. The format of the IP Reachability Information TLV is
shown in the following figure:</t> shown in the following figure:</t>
<figure anchor="IPREACHABILITYTLV">
<t><figure anchor="IPREACHABILITYTLV" <name>IP Reachability Information TLV Format</name>
title="IP Reachability Information TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (variable) // | Prefix Length | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The Type and Length fields of the TLV are defined in <xref target
<t>The Type and Length fields of the TLV are defined in <xref ="table_prefix_descriptor_tlv" format="default"/>. The following two fields
target="table_prefix_descriptor_tlv"/>. The following two fields
determine the reachability information of the address family. The determine the reachability information of the address family. The
Prefix Length field contains the length of the prefix in bits. The Prefix Length field contains the length of the prefix in bits. The
IP Prefix field contains an IP address prefix, followed by the IP Prefix field contains an IP address prefix followed by the
minimum number of trailing bits needed to make the end of the minimum number of trailing bits needed to make the end of the
field fall on an octet boundary. Any trailing bits MUST be set to field fall on an octet boundary. Any trailing bits <bcp14>MUST</bcp1 4> be set to
0. Thus, the IP Prefix field contains the most significant octets 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 of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 octets
for prefix length 9 to 16, 3 octets for prefix length 17 up to 24, 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> 4 octets for prefix length 25 up to 32, etc.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="BGPLSATTR" numbered="true" toc="default">
<section anchor="BGPLSATTR" title="The BGP-LS Attribute"> <name>The BGP-LS Attribute</name>
<t>The BGP-LS Attribute (assigned value 29 by IANA) is an optional, <t>The BGP-LS Attribute (assigned value 29 by IANA) is an optional,
non-transitive BGP attribute that is used to carry link, node, and non-transitive BGP Attribute that is used to carry link, node, and
prefix parameters and attributes. It is defined as a set of prefix parameters and attributes. It is defined as a set of
Type/Length/Value (TLV) triplets, described in the following section. Type/Length/Value (TLV) triplets, as described in the following section.
This attribute SHOULD only be included with Link-State NLRIs. The use This attribute <bcp14>SHOULD</bcp14> only be included with Link-State NL
RIs. The use
of this attribute for other address families is outside the scope of of this attribute for other address families is outside the scope of
this document.</t> this document.</t>
<t>The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute <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 TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute
associated with a Node NLRI, Link NLRI, and Prefix NLRI associated with a Node NLRI, Link NLRI, and Prefix NLRI
respectively.</t> respectively.</t>
<t>The size of the BGP-LS Attribute may potentially grow large,
<t>The size of the BGP-LS Attribute may potentially grow large
depending on the amount of link-state information associated with a depending on the amount of link-state information associated with a
single Link-State NLRI. The BGP specification <xref target="RFC4271"/> single Link-State NLRI. The BGP specification <xref target="RFC4271" for
mandates a maximum BGP message size of 4096 octets. It is RECOMMENDED mat="default"/>
that an implementation supports <xref target="RFC8654"/> to mandates a maximum BGP message size of 4096 octets. It is <bcp14>RECOMME
NDED</bcp14>
that an implementation supports <xref target="RFC8654" format="default"/
> to
accommodate a larger size of information within the BGP-LS Attribute. accommodate a larger size of information within the BGP-LS Attribute.
BGP-LS Producers MUST ensure that the TLVs included in the BGP-LS BGP-LS Producers <bcp14>MUST</bcp14> ensure that the TLVs included in th e BGP-LS
Attribute does not result in a BGP UPDATE message for a single 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> Link-State NLRI that crosses the maximum limit for a BGP message.</t>
<t>An implementation <bcp14>MAY</bcp14> adopt mechanisms to avoid this p
<t>An implementation MAY adopt mechanisms to avoid this problem that roblem that
may be based the BGP-LS Consumer applications' requirement; these may be based on the BGP-LS Consumer applications' requirement; these
mechanisms are beyond the scope of this specification. However, if an mechanisms are beyond the scope of this specification. However, if an
implementation chooses to mitigate the problem by excluding some TLVs implementation chooses to mitigate the problem by excluding some TLVs
from the BGP-LS Attribute, this exclusion SHOULD be done consistently from the BGP-LS Attribute, this exclusion <bcp14>SHOULD</bcp14> be done consistently
by all BGP-LS Producers within a given BGP-LS domain. In the event of 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 inconsistent exclusion of TLVs from the BGP-LS Attribute, the result
would be a differing set of attributes of the link-state object being would be a differing set of attributes of the link-state object being
propagated to BGP-LS Consumers based on the BGP decision process at propagated to BGP-LS Consumers based on the BGP Decision Process at
BGP-LS Propagators.</t> BGP-LS Propagators.</t>
<t>When a BGP-LS Propagator finds that it is exceeding the maximum BGP <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 message size due to the addition or update of some other BGP Attribute
(e.g. AS_PATH), it MUST consider the BGP-LS Attribute to be malformed, (e.g., AS_PATH), it <bcp14>MUST</bcp14> consider the BGP-LS Attribute to
apply the "Attribute Discard" error-handling approach <xref be malformed,
target="RFC7606"/>, and handle the propagation as described in <xref apply the 'Attribute Discard' error-handling approach <xref target="RFC7
target="Fault-Management"/>. When a BGP-LS Propagator needs to perform 606" format="default"/>, and handle the propagation as described in <xref target
"Attribute Discard" for reducing the BGP UPDATE message size as ="Fault-Management" format="default"/>. When a BGP-LS Propagator needs to perfor
specified in section 4 of <xref target="RFC8654"/>, it MUST first m
'Attribute Discard' for reducing the BGP UPDATE message size as
specified in <xref target="RFC8654" section="4" sectionFormat="of" forma
t="default"/>, it <bcp14>MUST</bcp14> first
discard the BGP-LS Attribute to enable the detection and diagnosis of discard the BGP-LS Attribute to enable the detection and diagnosis of
this error condition as discussed in <xref this error condition as discussed in <xref target="Fault-Management" for
target="Fault-Management"/>. This brings the deployment consideration mat="default"/>. This brings the deployment consideration
that the consistent propagation of BGP-LS information with a BGP that the consistent propagation of BGP-LS information with a BGP
UPDATE message size larger than 4096 octets can only happen along a UPDATE message size larger than 4096 octets can only happen along a
set of BGP Speakers that all support <xref target="RFC8654"/>.</t> set of BGP Speakers that all support the contents of <xref target="RFC86
54" format="default"/>.</t>
<section anchor="NODEATTR" title="Node Attribute TLVs"> <section anchor="NODEATTR" numbered="true" toc="default">
<name>Node Attribute TLVs</name>
<t>The following Node Attribute TLVs are defined for the BGP-LS <t>The following Node Attribute TLVs are defined for the BGP-LS
Attribute associated with a Node NLRI:</t> Attribute associated with a Node NLRI:</t>
<table anchor="node-attribute_tlv" align="center">
<texttable anchor="node-attribute_tlv" title="Node Attribute TLVs"> <name>Node Attribute TLVs</name>
<ttcol align="center">TLV Code Point</ttcol> <thead>
<tr>
<ttcol align="left">Description</ttcol> <th align="center">TLV Code Point</th>
<th align="left">Description</th>
<ttcol align="right">Length</ttcol> <th align="right">Length</th>
<th align="left">Reference</th>
<ttcol align="left">Reference (RFC/Section)</ttcol> </tr>
</thead>
<c>263</c> <tbody>
<tr>
<c>Multi-Topology Identifier</c> <td align="center">263</td>
<td align="left">Multi-Topology Identifier</td>
<c>variable</c> <td align="right">variable</td>
<td align="left">
<c><xref target="MT-ID"/></c> <xref target="MT-ID" format="default"/></td>
</tr>
<c>1024</c> <tr>
<td align="center">1024</td>
<c>Node Flag Bits</c> <td align="left">Node Flag Bits</td>
<td align="right">1</td>
<c>1</c> <td align="left">
<xref target="NODEFLAGBITS" format="default"/></td>
<c><xref target="NODEFLAGBITS"/></c> </tr>
<tr>
<c>1025</c> <td align="center">1025</td>
<td align="left">Opaque Node Attribute</td>
<c>Opaque Node Attribute</c> <td align="right">variable</td>
<td align="left">
<c>variable</c> <xref target="OPAQUENODE" format="default"/></td>
</tr>
<c><xref target="OPAQUENODE"/></c> <tr>
<td align="center">1026</td>
<c>1026</c> <td align="left">Node Name</td>
<td align="right">variable</td>
<c>Node Name</c> <td align="left">
<xref target="NODENAME" format="default"/></td>
<c>variable</c> </tr>
<tr>
<c><xref target="NODENAME"/></c> <td align="center">1027</td>
<td align="left">IS-IS Area Identifier</td>
<c>1027</c> <td align="right">variable</td>
<td align="left">
<c>IS-IS Area Identifier</c> <xref target="ISISAREA" format="default"/></td>
</tr>
<c>variable</c> <tr>
<td align="center">1028</td>
<c><xref target="ISISAREA"/></c> <td align="left">IPv4 Router-ID of Local Node</td>
<td align="right">4</td>
<c>1028</c> <td align="left"><xref target="RFC5305" sectionFormat="comma" se
ction="4.3"/></td>
<c>IPv4 Router-ID of Local Node</c> </tr>
<tr>
<c>4</c> <td align="center">1029</td>
<td align="left">IPv6 Router-ID of Local Node</td>
<c><xref target="RFC5305"/> / 4.3</c> <td align="right">16</td>
<td align="left"><xref target="RFC6119" sectionFormat="comma" se
<c>1029</c> ction="4.1"/></td>
</tr>
<c>IPv6 Router-ID of Local Node</c> </tbody>
</table>
<c>16</c> <section anchor="NODEFLAGBITS" numbered="true" toc="default">
<name>Node Flag Bits TLV</name>
<c><xref target="RFC6119"/> / 4.1</c>
</texttable>
<section anchor="NODEFLAGBITS" title="Node Flag Bits TLV">
<t>The Node Flag Bits TLV carries a bitmask describing node <t>The Node Flag Bits TLV carries a bitmask describing node
attributes. The value is a 1 octet length bit array of flags, attributes. The value is a 1-octet-length bit array of flags,
where each bit represents a node operational state or where each bit represents a node-operational state or
attribute.</t> attribute.</t>
<figure anchor="node_flag_bits">
<figure anchor="node_flag_bits" title="Node Flag Bits TLV Format"> <name>Node Flag Bits TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| | |O|T|E|B|R|V| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The bits are defined as follows:</t> <t>The bits are defined as follows:</t>
<texttable anchor="table_node_flag_bits_tlv" <table anchor="table_node_flag_bits_tlv" align="center">
title="Node Flag Bits Definitions"> <name>Node Flag Bits Definitions</name>
<ttcol align="center">Bit</ttcol> <thead>
<tr>
<ttcol align="left">Description</ttcol> <th align="center">Bit</th>
<th align="left">Description</th>
<ttcol align="left">Reference</ttcol> <th align="left">Reference</th>
</tr>
<c>'O'</c> </thead>
<tbody>
<c>Overload Bit</c> <tr>
<td align="center">'O'</td>
<c><xref target="ISO10589"/></c> <td align="left">Overload Bit</td>
<td align="left">
<c>'T'</c> <xref target="ISO10589" format="default"/></td>
</tr>
<c>Attached Bit</c> <tr>
<td align="center">'A'</td>
<c><xref target="ISO10589"/></c> <td align="left">Attached Bit</td>
<td align="left">
<c>'E'</c> <xref target="ISO10589" format="default"/></td>
</tr>
<c>External Bit</c> <tr>
<td align="center">'E'</td>
<c><xref target="RFC2328"/></c> <td align="left">External Bit</td>
<td align="left">
<c>'B'</c> <xref target="RFC2328" format="default"/></td>
</tr>
<c>ABR Bit</c> <tr>
<td align="center">'B'</td>
<c><xref target="RFC2328"/></c> <td align="left">ABR Bit</td>
<td align="left">
<c>'R'</c> <xref target="RFC2328" format="default"/></td>
</tr>
<c>Router Bit</c> <tr>
<td align="center">'R'</td>
<c><xref target="RFC5340"/></c> <td align="left">Router Bit</td>
<td align="left">
<c>'V'</c> <xref target="RFC5340" format="default"/></td>
</tr>
<c>V6 Bit</c> <tr>
<td align="center">'V'</td>
<c><xref target="RFC5340"/></c> <td align="left">V6 Bit</td>
</texttable> <td align="left">
<xref target="RFC5340" format="default"/></td>
<t>The bits that are not defined MUST be set to 0 by the </tr>
originator and MUST be ignored by the receiver.</t> </tbody>
</table>
<t>The bits that are not defined <bcp14>MUST</bcp14> be set to 0 by
the
originator and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
</section> </section>
<section anchor="ISISAREA" numbered="true" toc="default">
<section anchor="ISISAREA" title="IS-IS Area Identifier TLV"> <name>IS-IS Area Identifier TLV</name>
<t>An IS-IS node can be part of only a single IS-IS area. However, <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 a node can have multiple synonymous area addresses. Each of these
area addresses is carried in the IS-IS Area Identifier TLV. If area addresses is carried in the IS-IS Area Identifier TLV. If
multiple area addresses are present, multiple TLVs are used to multiple area addresses are present, multiple TLVs are used to
encode them. The IS-IS Area Identifier TLV may be present in the encode them. The IS-IS Area Identifier TLV may be present in the
BGP-LS Attribute only when advertised in the Link-State Node BGP-LS Attribute only when advertised in the Link-State Node
NLRI.</t> NLRI.</t>
<figure anchor="ISISAREAIDTLV">
<figure anchor="ISISAREAIDTLV" <name>IS-IS Area Identifier TLV Format</name>
title="IS-IS Area Identifier TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IS-IS Area Identifier (variable) // // IS-IS Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="NODENAME" numbered="true" toc="default">
<section anchor="NODENAME" title="Node Name TLV"> <name>Node Name TLV</name>
<t>The Node Name TLV is optional. The encoding semantics for the <t>The Node Name TLV is optional. The encoding semantics for the
node name has been borrowed from <xref target="RFC5301"/>. The node name has been borrowed from <xref target="RFC5301" format="defa ult"/>. The
Value field identifies the symbolic name of the router node. This Value field identifies the symbolic name of the router node. This
symbolic name can either be the Fully Qualified Domain Name (FQDN) symbolic name can be the Fully Qualified Domain Name (FQDN)
for the router, or it can be a substring of the FQDN (e.g., a for the router, a substring of the FQDN (e.g., a
hostname), or it can be any string that an operator wants to use hostname), or any string that an operator wants to use
for the router. The use of FQDN or a substring of it is strongly for the router. The use of the FQDN or a substring of it is strongly
RECOMMENDED. The maximum length of the Node Name TLV is 255 <bcp14>RECOMMENDED</bcp14>. The maximum length of the Node Name TLV
is 255
octets.</t> octets.</t>
<t>The Value field is encoded in 7-bit ASCII. If a user interface <t>The Value field is encoded in 7-bit ASCII. If a user interface
for configuring or displaying this field permits Unicode for configuring or displaying this field permits Unicode
characters, that the user interface is responsible for applying characters, then the user interface is responsible for applying
the ToASCII and/or ToUnicode algorithm as described in <xref the ToASCII and/or ToUnicode algorithm as described in <xref target=
target="RFC5890"/> to achieve the correct format for transmission "RFC5890" format="default"/> to achieve the correct format for transmission
or display.</t> or display.</t>
<t><xref target="RFC5301" format="default"/> describes an IS-IS-spec
<t><xref target="RFC5301"/> describes an IS-IS-specific extension ific extension,
and <xref target="RFC5642"/> describes an OSPF extension for the and <xref target="RFC5642" format="default"/> describes an OSPF exte
advertisement of Node Name which may be encoded in the Node Name nsion for the
advertisement of the node name, which may be encoded in the Node Nam
e
TLV.</t> TLV.</t>
<figure anchor="optional-node-name-tlv">
<figure anchor="optional-node-name-tlv" title="Node Name Format"> <name>Node Name Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (variable) // // Node Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="aux_routerid_node" numbered="true" toc="default">
<section anchor="aux_routerid_node" <name>Local IPv4/IPv6 Router-ID TLVs</name>
title="Local IPv4/IPv6 Router-ID TLVs">
<t>The local IPv4/IPv6 Router-ID TLVs are used to describe <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 auxiliary Router-IDs that the IGP might be using, e.g., for TE and
migration purposes such as correlating a Node-ID between different migration purposes such as correlating a Node-ID between different
protocols. If there is more than one auxiliary Router-ID of a protocols. If there is more than one auxiliary Router-ID of a
given type, then each one is encoded as a separate TLV.</t> given type, then each one is encoded as a separate TLV.</t>
</section> </section>
<section anchor="OPAQUENODE" numbered="true" toc="default">
<section anchor="OPAQUENODE" title="Opaque Node Attribute TLV"> <name>Opaque Node Attribute TLV</name>
<t>The Opaque Node Attribute TLV is an envelope that transparently <t>The Opaque Node Attribute TLV is an envelope that transparently
carries optional Node Attribute TLVs advertised by a router. An carries optional Node Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID specific to the protocol advertised in the NLRI header Protocol-ID
field or new protocol extensions to the protocol as advertised in field or new protocol extensions to the protocol as advertised in
the NLRI header Protocol-ID field for which there is no the NLRI header Protocol-ID field for which there is no
protocol-neutral representation in the BGP Link-State NLRI. The protocol-neutral representation in the BGP Link-State NLRI. The
primary use of the Opaque Node Attribute TLV is to bridge the primary use of the Opaque Node Attribute TLV is to bridge the
document lag between a new IGP link-state attribute and its document lag between a new IGP link-state attribute and its
protocol-neutral BGP-LS extension being defined. Once the protocol-neutral BGP-LS extension being defined. Once the
protocol-neutral BGP-LS extensions are defined, the BGP-LS protocol-neutral BGP-LS extensions are defined, the BGP-LS
implementations may still need to advertise the information both implementations may still need to advertise the information both
within the Opaque Attribute TLV and the new TLV definition for within the Opaque Attribute TLV and the new TLV definition for
incremental deployment and transition.</t> incremental deployment and transition.</t>
<t>In the case of OSPF, this TLV <bcp14>MUST NOT</bcp14> be used to
<t>In the case of OSPF, this TLV MUST NOT be used to advertise advertise
TLVs other than those in the OSPF Router Information (RI) LSA TLVs other than those in the OSPF Router Information (RI) LSA
<xref target="RFC7770"/>.</t> <xref target="RFC7770" format="default"/>.</t>
<figure anchor="optional_opaque_node-attribute_tlv">
<figure anchor="optional_opaque_node-attribute_tlv" <name>Opaque Node Attribute Format</name>
title="Opaque Node Attribute Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (variable) // // Opaque Node Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Type is as specified in <xref target="node-attribute_tlv" for
<t>The type is as specified in <xref mat="default"/>. The length is variable.</t>
target="node-attribute_tlv"/>. Length is variable.</t>
</section> </section>
</section> </section>
<section anchor="link_attribute" numbered="true" toc="default">
<section anchor="link_attribute" title="Link Attribute TLVs"> <name>Link Attribute TLVs</name>
<t>Link Attribute TLVs are TLVs that may be encoded in the BGP-LS <t>Link Attribute TLVs are TLVs that may be encoded in the BGP-LS
Attribute with a Link NLRI. Each 'Link Attribute' is a Attribute with a Link NLRI. Each 'Link Attribute' is a
Type/Length/Value (TLV) triplet formatted as defined in <xref Type/Length/Value (TLV) triplet formatted as defined in <xref target="
target="TLV-section"/>. The format and semantics of the Value fields TLV-section" format="default"/>. The format and semantics of the Value fields
in some Link Attribute TLVs correspond to the format and semantics in some Link Attribute TLVs correspond to the format and semantics
of the Value fields in IS-IS Extended IS Reachability sub-TLVs, of the Value fields in IS-IS Extended IS Reachability sub-TLVs,
defined in <xref target="RFC5305"/> and <xref target="RFC5307"/>. which are defined in <xref target="RFC5305" format="default"/> and <xr ef target="RFC5307" format="default"/>.
Other Link Attribute TLVs are defined in this document. Although the Other Link Attribute TLVs are defined in this document. Although the
encodings for Link Attribute TLVs were originally defined for IS-IS, encodings for Link Attribute TLVs were originally defined for IS-IS,
the TLVs can carry data sourced by either IS-IS or OSPF.</t> 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 <t>The following Link Attribute TLVs are defined for the BGP-LS
Attribute associated with a Link NLRI:</t> Attribute associated with a Link NLRI:</t>
<table anchor="table_link_attribute_tlv" align="center">
<texttable anchor="table_link_attribute_tlv" <name>Link Attribute TLVs</name>
title="Link Attribute TLVs"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="center">IS-IS TLV/Sub-TLV</th>
<ttcol align="center">IS-IS TLV/Sub-TLV</ttcol> <th align="left">Reference</th>
</tr>
<ttcol align="left">Reference (RFC/Section)</ttcol> </thead>
<tbody>
<c>1028</c> <tr>
<td align="center">1028</td>
<c>IPv4 Router-ID of Local Node</c> <td align="left">IPv4 Router-ID of Local Node</td>
<td align="center">134/---</td>
<c>134/---</c> <td align="left">
<xref target="RFC5305" sectionFormat="comma" section="4.3"/></
<c><xref target="RFC5305"/> / 4.3</c> td>
</tr>
<c>1029</c> <tr>
<td align="center">1029</td>
<c>IPv6 Router-ID of Local Node</c> <td align="left">IPv6 Router-ID of Local Node</td>
<td align="center">140/---</td>
<c>140/---</c> <td align="left">
<xref target="RFC6119" sectionFormat="comma" section="4.1"/></
<c><xref target="RFC6119"/> / 4.1</c> td>
</tr>
<c>1030</c> <tr>
<td align="center">1030</td>
<c>IPv4 Router-ID of Remote Node</c> <td align="left">IPv4 Router-ID of Remote Node</td>
<td align="center">134/---</td>
<c>134/---</c> <td align="left">
<xref target="RFC5305" sectionFormat="comma" section="4.3"/></
<c><xref target="RFC5305"/> / 4.3</c> td>
</tr>
<c>1031</c> <tr>
<td align="center">1031</td>
<c>IPv6 Router-ID of Remote Node</c> <td align="left">IPv6 Router-ID of Remote Node</td>
<td align="center">140/---</td>
<c>140/---</c> <td align="left">
<xref target="RFC6119" sectionFormat="comma" section="4.1"/></
<c><xref target="RFC6119"/> / 4.1</c> td>
</tr>
<c>1088</c> <tr>
<td align="center">1088</td>
<c>Administrative group (color)</c> <td align="left">Administrative group (color)</td>
<td align="center">22/3</td>
<c>22/3</c> <td align="left">
<xref target="RFC5305" sectionFormat="comma" section="3.1"/></
<c><xref target="RFC5305"/> / 3.1</c> td>
</tr>
<c>1089</c> <tr>
<td align="center">1089</td>
<c>Maximum link bandwidth</c> <td align="left">Maximum link bandwidth</td>
<td align="center">22/9</td>
<c>22/9</c> <td align="left">
<xref target="RFC5305" sectionFormat="comma" section="3.4"/></
<c><xref target="RFC5305"/> / 3.4</c> td>
</tr>
<c>1090</c> <tr>
<td align="center">1090</td>
<c>Max. reservable link bandwidth</c> <td align="left">Max. reservable link bandwidth</td>
<td align="center">22/10</td>
<c>22/10</c> <td align="left">
<xref target="RFC5305" sectionFormat="comma" section="3.5"/></
<c><xref target="RFC5305"/> / 3.5</c> td>
</tr>
<c>1091</c> <tr>
<td align="center">1091</td>
<c>Unreserved bandwidth</c> <td align="left">Unreserved bandwidth</td>
<td align="center">22/11</td>
<c>22/11</c> <td align="left">
<xref target="RFC5305" sectionFormat="comma" section="3.6"/></
<c><xref target="RFC5305"/> / 3.6</c> td>
</tr>
<c>1092</c> <tr>
<td align="center">1092</td>
<c>TE Default Metric</c> <td align="left">TE Default Metric</td>
<td align="center">22/18</td>
<c>22/18</c> <td align="left">
<xref target="TEDEFAULTMETTLV" format="default"/></td>
<c><xref target="TEDEFAULTMETTLV"/></c> </tr>
<tr>
<c>1093</c> <td align="center">1093</td>
<td align="left">Link Protection Type</td>
<c>Link Protection Type</c> <td align="center">22/20</td>
<td align="left">
<c>22/20</c> <xref target="RFC5307" sectionFormat="comma" section="1.2"/></
td>
<c><xref target="RFC5307"/> / 1.2</c> </tr>
<tr>
<c>1094</c> <td align="center">1094</td>
<td align="left">MPLS Protocol Mask</td>
<c>MPLS Protocol Mask</c> <td align="center">---</td>
<td align="left">
<c>---</c> <xref target="MPLSPROTOTLV" format="default"/></td>
</tr>
<c><xref target="MPLSPROTOTLV"/></c> <tr>
<td align="center">1095</td>
<c>1095</c> <td align="left">IGP Metric</td>
<td align="center">---</td>
<c>IGP Metric</c> <td align="left">
<xref target="IGPMETTLV" format="default"/></td>
<c>---</c> </tr>
<tr>
<c><xref target="IGPMETTLV"/></c> <td align="center">1096</td>
<td align="left">Shared Risk Link Group</td>
<c>1096</c> <td align="center">---</td>
<td align="left">
<c>Shared Risk Link Group</c> <xref target="SRLGTLV" format="default"/></td>
</tr>
<c>---</c> <tr>
<td align="center">1097</td>
<c><xref target="SRLGTLV"/></c> <td align="left">Opaque Link Attribute</td>
<td align="center">---</td>
<c>1097</c> <td align="left">
<xref target="OPAQUELINK" format="default"/></td>
<c>Opaque Link Attribute</c> </tr>
<tr>
<c>---</c> <td align="center">1098</td>
<td align="left">Link Name</td>
<c><xref target="OPAQUELINK"/></c> <td align="center">---</td>
<td align="left">
<c>1098</c> <xref target="LINKNAME" format="default"/></td>
</tr>
<c>Link Name</c> </tbody>
</table>
<c>---</c> <section anchor="aux_routerid_link" numbered="true" toc="default">
<name>IPv4/IPv6 Router-ID TLVs</name>
<c><xref target="LINKNAME"/></c>
</texttable>
<section anchor="aux_routerid_link" title="IPv4/IPv6 Router-ID TLVs">
<t>The local/remote IPv4/IPv6 Router-ID TLVs are used to describe <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 auxiliary Router-IDs that the IGP might be using, e.g., for TE
purposes. All auxiliary Router-IDs of both the local and the purposes. All auxiliary Router-IDs of both the local and the
remote node MUST be included in the link attribute of each Link remote node <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 NLRI. If there is more than one auxiliary Router-ID of a given
type, then multiple TLVs are used to encode them.</t> type, then multiple TLVs are used to encode them.</t>
</section> </section>
<section anchor="MPLSPROTOTLV" numbered="true" toc="default">
<section anchor="MPLSPROTOTLV" title="MPLS Protocol Mask TLV"> <name>MPLS Protocol Mask TLV</name>
<t>The MPLS Protocol Mask TLV carries a bitmask describing which <t>The MPLS Protocol Mask TLV carries a bitmask describing which
MPLS signaling protocols are enabled. The length of this TLV is 1. 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 The value is a bit array of 8 flags, where each bit represents an
MPLS Protocol capability.</t> MPLS Protocol capability.</t>
<t>Generation of the MPLS Protocol Mask TLV is only valid for and <t>Generation of the MPLS Protocol Mask TLV is only valid for and
SHOULD only be used with originators that have local link insight, <bcp14>SHOULD</bcp14> only be used with originators that have local link insight,
for example, the Protocol-IDs 'Static configuration' or 'Direct' for example, the Protocol-IDs 'Static configuration' or 'Direct'
as per <xref target="PROTOCOL-IDS"/>. The MPLS Protocol Mask TLV as per <xref target="PROTOCOL-IDS" format="default"/>. The MPLS Prot
MUST NOT be included in NLRIs with the other Protocol-IDs listed ocol Mask TLV
in <xref target="PROTOCOL-IDS"/>.</t> <bcp14>MUST NOT</bcp14> be included in NLRIs with the other Protocol
-IDs listed
<figure anchor="MPLSPROTO" title="MPLS Protocol Mask TLV"> in <xref target="PROTOCOL-IDS" format="default"/>.</t>
<artwork><![CDATA[ <figure anchor="MPLSPROTO">
<name>MPLS Protocol Mask TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved | |L|R| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The following bits are defined, and the reserved bits <bcp14>MUST
<t>The following bits are defined, and the reserved bits MUST be </bcp14> be
set to zero and SHOULD be ignored on receipt:</t> set to zero and <bcp14>SHOULD</bcp14> be ignored on receipt:</t>
<table anchor="table_mpls_protocols_tlv" align="center">
<texttable anchor="table_mpls_protocols_tlv" <name>MPLS Protocol Mask TLV Codes</name>
title="MPLS Protocol Mask TLV Codes"> <thead>
<ttcol align="center">Bit</ttcol> <tr>
<th align="center">Bit</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol align="left">Reference</ttcol> </tr>
</thead>
<c>'L'</c> <tbody>
<tr>
<c>Label Distribution Protocol (LDP)</c> <td align="center">'L'</td>
<td align="left">Label Distribution Protocol (LDP)</td>
<c><xref target="RFC5036"/></c> <td align="left">
<xref target="RFC5036" format="default"/></td>
<c>'R'</c> </tr>
<tr>
<c>Extension to RSVP for LSP Tunnels (RSVP&nbhy;TE)</c> <td align="center">'R'</td>
<td align="left">Extension to RSVP for LSP Tunnels (RSVP-TE)</
<c><xref target="RFC3209"/></c> td>
</texttable> <td align="left">
<xref target="RFC3209" format="default"/></td>
<t>The bits that are not defined MUST be set to 0 by the </tr>
originator and MUST be ignored by the receiver.</t> </tbody>
</table>
<t>The bits that are not defined <bcp14>MUST</bcp14> be set to 0 by
the
originator and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
</section> </section>
<section anchor="TEDEFAULTMETTLV" numbered="true" toc="default">
<section anchor="TEDEFAULTMETTLV" title="TE Default Metric TLV"> <name>TE Default Metric TLV</name>
<t>The TE Default Metric TLV carries the Traffic Engineering <t>The TE Default Metric TLV carries the Traffic Engineering
metric for this link. The length of this TLV is fixed at 4 octets. 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, If a source protocol uses a metric width of fewer than 32 bits,
then the high-order bits of this field MUST be padded with then the high-order bits of this field <bcp14>MUST</bcp14> be padded with
zero.</t> zero.</t>
<figure anchor="TEDEFAULTMET">
<figure anchor="TEDEFAULTMET" title="TE Default Metric TLV Format"> <name>TE Default Metric TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric | | TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="IGPMETTLV" numbered="true" toc="default">
<section anchor="IGPMETTLV" title="IGP Metric TLV"> <name>IGP Metric TLV</name>
<t>The IGP Metric TLV carries the metric for this link. The length <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 of this TLV is variable, depending on the metric width of the
underlying protocol. IS-IS small metrics are of 6-bit size, but underlying protocol. IS-IS small metrics are 6 bits in size but
are encoded in a 1 octet field; therefore the two most significant are encoded in a 1-octet field; therefore, the two most significant
bits of the field MUST be set to 0 by the originator and MUST be bits of the field <bcp14>MUST</bcp14> be set to 0 by the originator
and <bcp14>MUST</bcp14> be
ignored by the receiver. OSPF link metrics have a length of 2 ignored by the receiver. OSPF link metrics have a length of 2
octets. IS-IS wide metrics have a length of 3 octets.</t> octets. IS-IS wide metrics have a length of 3 octets.</t>
<figure anchor="MET">
<figure anchor="MET" title="IGP Metric TLV Format"> <name>IGP Metric TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable length) // // IGP Link Metric (variable length) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="SRLGTLV" numbered="true" toc="default">
<section anchor="SRLGTLV" title="Shared Risk Link Group TLV"> <name>Shared Risk Link Group TLV</name>
<t>The Shared Risk Link Group (SRLG) TLV carries the Shared Risk <t>The Shared Risk Link Group (SRLG) TLV carries the Shared Risk
Link Group information (see Section 2.3 ("Shared Risk Link Group Link Group information (see Section <xref target="RFC4202" section="
Information") of <xref target="RFC4202"/>). It contains a data 2.3" sectionFormat="bare">"Shared Risk Link Group
Information"</xref> of <xref target="RFC4202" format="default"/>). I
t contains a data
structure consisting of a (variable) list of SRLG values, where structure consisting of a (variable) list of SRLG values, where
each element in the list has 4 octets, as shown in <xref each element in the list has 4 octets, as shown in <xref target="SRL
target="SRLG"/>. The length of this TLV is 4 * (number of SRLG G" format="default"/>. The length of this TLV is 4 * (number of SRLG
values).</t> values).</t>
<figure anchor="SRLG">
<figure anchor="SRLG" title="Shared Risk Link Group TLV Format"> <name>Shared Risk Link Group TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value | | Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ // // ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value | | Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The SRLG TLV for OSPF-TE is defined in <xref target="RFC4203" for
<t>The SRLG TLV for OSPF-TE is defined in <xref mat="default"/>. In IS-IS, the SRLG information is carried in
target="RFC4203"/>. In IS-IS, the SRLG information is carried in two different TLVs: the GMPLS-SRLG TLV (for IPv4) (Type 138) defined
two different TLVs: the IPv4 (SRLG) TLV (Type 138) defined in in
<xref target="RFC5307"/> and the IPv6 SRLG TLV (Type 139) defined <xref target="RFC5307" format="default"/> and the IPv6 SRLG TLV (Typ
in <xref target="RFC6119"/>. Both IPv4 and IPv6 SRLG information e 139) defined
in <xref target="RFC6119" format="default"/>. Both IPv4 and IPv6 SRL
G information
is carried in a single TLV.</t> is carried in a single TLV.</t>
</section> </section>
<section anchor="OPAQUELINK" numbered="true" toc="default">
<section anchor="OPAQUELINK" title="Opaque Link Attribute TLV"> <name>Opaque Link Attribute TLV</name>
<t>The Opaque Link Attribute TLV is an envelope that transparently <t>The Opaque Link Attribute TLV is an envelope that transparently
carries optional Link Attribute TLVs advertised by a router. An carries optional Link Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID specific to the protocol advertised in the NLRI header Protocol-ID
field or new protocol extensions to the protocol as advertised in field or new protocol extensions to the protocol as advertised in
the NLRI header Protocol-ID field for which there is no the NLRI header Protocol-ID field for which there is no
protocol-neutral representation in the BGP Link-State NLRI. The protocol-neutral representation in the BGP Link-State NLRI. The
primary use of the Opaque Link Attribute TLV is to bridge the primary use of the Opaque Link Attribute TLV is to bridge the
document lag between a new IGP link-state attribute and its document lag between a new IGP link-state attribute and its
'protocol-neutral' BGP-LS extension being defined. Once the 'protocol-neutral' BGP-LS extension being defined. Once the
protocol-neutral BGP-LS extensions are defined, the BGP-LS protocol-neutral BGP-LS extensions are defined, the BGP-LS
implementations may still need to advertise the information both implementations may still need to advertise the information both
within the Opaque Attribute TLV and the new TLV definition for within the Opaque Attribute TLV and the new TLV definition for
incremental deployment and transition.</t> incremental deployment and transition.</t>
<t>In the case of OSPFv2, this TLV <bcp14>MUST NOT</bcp14> be used t
<t>In the case of OSPFv2, this TLV MUST NOT be used to advertise o advertise
information carried using TLVs other than those in the OSPFv2 information carried using TLVs other than those in the OSPFv2
Extended Link Opaque LSA <xref target="RFC7684"/>. In the case of Extended Link Opaque LSA <xref target="RFC7684" format="default"/>.
OSPFv3, this TLV MUST NOT be used to advertise TLVs other than In the case of
those in the OSPFv3 E-Router-LSA or E-Link-LSA <xref OSPFv3, this TLV <bcp14>MUST NOT</bcp14> be used to advertise TLVs o
target="RFC8362"/>.</t> ther than
those in the OSPFv3 E-Router-LSA or E-Link-LSA <xref target="RFC8362
<figure anchor="OPAQUELINKTLV" " format="default"/>.</t>
title="Opaque Link Attribute TLV Format"> <figure anchor="OPAQUELINKTLV">
<artwork><![CDATA[ <name>Opaque Link Attribute TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (variable) // // Opaque Link Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="LINKNAME" numbered="true" toc="default">
<section anchor="LINKNAME" title="Link Name TLV"> <name>Link Name TLV</name>
<t>The Link Name TLV is optional. The Value field identifies the <t>The Link Name TLV is optional. The Value field identifies the
symbolic name of the router link. This symbolic name can either be symbolic name of the router link. This symbolic name can be
the FQDN for the link, or it can be a substring of the FQDN, or it the FQDN for the link, a substring of the FQDN, or
can be any string that an operator wants to use for the link. The any string that an operator wants to use for the link. The
use of FQDN or a substring of it is strongly RECOMMENDED. The use of the FQDN or a substring of it is strongly <bcp14>RECOMMENDED<
/bcp14>. The
maximum length of the Link Name TLV is 255 octets.</t> 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 <t>The Value field is encoded in 7-bit ASCII. If a user interface
for configuring or displaying this field permits Unicode for configuring or displaying this field permits Unicode
characters, that the user interface is responsible for applying characters, then the user interface is responsible for applying
the ToASCII and/or ToUnicode algorithm as described in <xref the ToASCII and/or ToUnicode algorithm as described in <xref target=
target="RFC5890"/> to achieve the correct format for transmission "RFC5890" format="default"/> to achieve the correct format for transmission
or display.</t> or display.</t>
<t>How a router derives and injects link names is outside of the <t>How a router derives and injects link names is outside of the
scope of this document.</t> scope of this document.</t>
<figure anchor="optional-link-name-tlv">
<figure anchor="optional-link-name-tlv" <name>Link Name TLV Format</name>
title="Link Name TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (variable) // // Link Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="PFXATTR" numbered="true" toc="default">
<section anchor="PFXATTR" title="Prefix Attribute TLVs"> <name>Prefix Attribute TLVs</name>
<t>Prefixes are learned from the IGP topology (IS-IS or OSPF) with a <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 set of IGP attributes (such as metric, route tags, etc.) that are
advertised in the BGP-LS Attribute with Prefix NLRI types 3 and advertised in the BGP-LS Attribute with Prefix NLRI types 3 and
4.</t> 4.</t>
<t>The following Prefix Attribute TLVs are defined for the BGP-LS <t>The following Prefix Attribute TLVs are defined for the BGP-LS
Attribute associated with a Prefix NLRI:</t> Attribute associated with a Prefix NLRI:</t>
<table anchor="prefix-attribute_tlv" align="center">
<texttable anchor="prefix-attribute_tlv" <name>Prefix Attribute TLVs</name>
title="Prefix Attribute TLVs"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="right">Length</th>
<ttcol align="right">Length</ttcol> <th align="left">Reference</th>
</tr>
<ttcol align="left">Reference</ttcol> </thead>
<tbody>
<c>1152</c> <tr>
<td align="center">1152</td>
<c>IGP Flags</c> <td align="left">IGP Flags</td>
<td align="right">1</td>
<c>1</c> <td align="left">
<xref target="IGPFLAGS" format="default"/></td>
<c><xref target="IGPFLAGS"/></c> </tr>
<tr>
<c>1153</c> <td align="center">1153</td>
<td align="left">IGP Route Tag</td>
<c>IGP Route Tag</c> <td align="right">4*n</td>
<td align="left">
<c>4*n</c> <xref target="RFC5130" format="default"/></td>
</tr>
<c><xref target="RFC5130"/></c> <tr>
<td align="center">1154</td>
<c>1154</c> <td align="left">IGP Extended Route Tag</td>
<td align="right">8*n</td>
<c>IGP Extended Route Tag</c> <td align="left">
<xref target="RFC5130" format="default"/></td>
<c>8*n</c> </tr>
<tr>
<c><xref target="RFC5130"/></c> <td align="center">1155</td>
<td align="left">Prefix Metric</td>
<c>1155</c> <td align="right">4</td>
<td align="left">
<c>Prefix Metric</c> <xref target="RFC5305" format="default"/></td>
</tr>
<c>4</c> <tr>
<td align="center">1156</td>
<c><xref target="RFC5305"/></c> <td align="left">OSPF Forwarding Address</td>
<td align="right">4</td>
<c>1156</c> <td align="left">
<xref target="RFC2328" format="default"/></td>
<c>OSPF Forwarding Address</c> </tr>
<tr>
<c>4</c> <td align="center">1157</td>
<td align="left">Opaque Prefix Attribute</td>
<c><xref target="RFC2328"/></c> <td align="right">variable</td>
<td align="left">
<c>1157</c> <xref target="OPAQUEPREFIX" format="default"/></td>
</tr>
<c>Opaque Prefix Attribute</c> </tbody>
</table>
<c>variable</c> <section anchor="IGPFLAGS" numbered="true" toc="default">
<name>IGP Flags TLV</name>
<c><xref target="OPAQUEPREFIX"/></c>
</texttable>
<section anchor="IGPFLAGS" title="IGP Flags TLV">
<t>The IGP Flags TLV contains one octet of IS-IS and OSPF flags <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 and bits originally assigned to the prefix. The IGP Flags TLV is
encoded as follows:</t> encoded as follows:</t>
<figure anchor="IGPFLAGSTLV">
<figure anchor="IGPFLAGSTLV" title="IGP Flag TLV Format"> <name>IGP Flag TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| | |D|N|L|P| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Value field contains bits defined according to the table <t>The Value field contains bits defined according to the table
below:</t> below:</t>
<table anchor="table_igp_flag_bits_tlv" align="center">
<texttable anchor="table_igp_flag_bits_tlv" <name>IGP Flag Bits Definitions</name>
title="IGP Flag Bits Definitions"> <thead>
<ttcol align="center">Bit</ttcol> <tr>
<th align="center">Bit</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol align="left">Reference</ttcol> </tr>
</thead>
<c>'D'</c> <tbody>
<tr>
<c>IS-IS Up/Down Bit</c> <td align="center">'D'</td>
<td align="left">IS-IS Up/Down Bit</td>
<c><xref target="RFC5305"/></c> <td align="left">
<xref target="RFC5305" format="default"/></td>
<c>'N'</c> </tr>
<tr>
<c>OSPF "no unicast" Bit</c> <td align="center">'N'</td>
<td align="left">OSPF "no unicast" Bit</td>
<c><xref target="RFC5340"/></c> <td align="left">
<xref target="RFC5340" format="default"/></td>
<c>'L'</c> </tr>
<tr>
<c>OSPF "local address" Bit</c> <td align="center">'L'</td>
<td align="left">OSPF "local address" Bit</td>
<c><xref target="RFC5340"/></c> <td align="left">
<xref target="RFC5340" format="default"/></td>
<c>'P'</c> </tr>
<tr>
<c>OSPF "propagate NSSA" Bit</c> <td align="center">'P'</td>
<td align="left">OSPF "propagate NSSA" Bit</td>
<c><xref target="RFC5340"/></c> <td align="left">
</texttable> <xref target="RFC5340" format="default"/></td>
</tr>
<t>The bits that are not defined MUST be set to 0 by the </tbody>
originator and MUST be ignored by the receiver.</t> </table>
<t>The bits that are not defined <bcp14>MUST</bcp14> be set to 0 by
the
originator and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
</section> </section>
<section anchor="route_tag" numbered="true" toc="default">
<section anchor="route_tag" title="IGP Route Tag TLV"> <name>IGP Route Tag TLV</name>
<t>The IGP Route Tag TLV carries original IGP Tags (IS-IS <xref <t>The IGP Route Tag TLV carries original IGP Tags (IS-IS <xref targ
target="RFC5130"/> or OSPF) of the prefix and is encoded as et="RFC5130" format="default"/> or OSPF) of the prefix and is encoded as
follows:</t> follows:</t>
<figure anchor="IGPROUTETAG">
<figure anchor="IGPROUTETAG" title="IGP Route Tag TLV Format"> <name>IGP Route Tag TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (one or more) // // Route Tags (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The length is a multiple of 4.</t>
<t>Length is a multiple of 4.</t>
<t>The Value field contains one or more Route Tags as learned in <t>The Value field contains one or more Route Tags as learned in
the IGP topology.</t> the IGP topology.</t>
</section> </section>
<section anchor="ext_route_tag" numbered="true" toc="default">
<section anchor="ext_route_tag" title="Extended IGP Route Tag TLV"> <name>IGP Extended Route Tag TLV</name>
<t>The Extended IGP Route Tag TLV carries IS-IS Extended Route <t>The IGP Extended Route Tag TLV carries IS-IS Extended Route
Tags of the prefix <xref target="RFC5130"/> and is encoded as Tags of the prefix <xref target="RFC5130" format="default"/> and is
encoded as
follows:</t> follows:</t>
<figure anchor="IGPEXTROUTETAG">
<figure anchor="IGPEXTROUTETAG" <name>IGP Extended Route Tag TLV Format</name>
title="Extended IGP Route Tag TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Route Tag (one or more) // // Extended Route Tag (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The length is a multiple of 8.</t>
<t>Length is a multiple of 8.</t>
<t>The Extended Route Tag field contains one or more Extended <t>The Extended Route Tag field contains one or more Extended
Route Tags as learned in the IGP topology.</t> Route Tags as learned in the IGP topology.</t>
</section> </section>
<section anchor="prefix_metric" numbered="true" toc="default">
<section anchor="prefix_metric" title="Prefix Metric TLV"> <name>Prefix Metric TLV</name>
<t>The Prefix Metric TLV is an optional attribute and may only <t>The Prefix Metric TLV is an optional attribute and may only
appear once. If present, it carries the metric of the prefix as appear once. If present, it carries the metric of the prefix as
known in the IGP topology as described in Section 4 of <xref known in the IGP topology, as described in <xref target="RFC5305" se
target="RFC5305"/> (and therefore represents the reachability cost ction="4" sectionFormat="of" format="default"/> (and therefore represents the re
achability cost
to the prefix). If not present, it means that the prefix is to the prefix). If not present, it means that the prefix is
advertised without any reachability.</t> advertised without any reachability.</t>
<figure anchor="PREFIXMETRIC">
<t><figure anchor="PREFIXMETRIC" title="Prefix Metric TLV Format"> <name>Prefix Metric TLV Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The length is 4.</t>
<t>Length is 4.</t>
</section> </section>
<section anchor="ospf_fwd_addr" numbered="true" toc="default">
<section anchor="ospf_fwd_addr" title="OSPF Forwarding Address TLV"> <name>OSPF Forwarding Address TLV</name>
<t>The OSPF Forwarding Address TLV <xref target="RFC2328"/> <xref <t>The OSPF Forwarding Address TLV <xref target="RFC2328" format="de
target="RFC5340"/> carries the OSPF forwarding address as known in fault"/> <xref target="RFC5340" format="default"/> carries the OSPF forwarding a
ddress as known in
the original OSPF advertisement. The forwarding address can be the original OSPF advertisement. The forwarding address can be
either IPv4 or IPv6.</t> either IPv4 or IPv6.</t>
<figure anchor="OSPFFORWADDR">
<figure anchor="OSPFFORWADDR" <name>OSPF Forwarding Address TLV Format</name>
title="OSPF Forwarding Address TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (variable) // // Forwarding Address (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The length is 4 for an IPv4 forwarding address and 16 for an IPv6
<t>Length is 4 for an IPv4 forwarding address, and 16 for an IPv6
forwarding address.</t> forwarding address.</t>
</section> </section>
<section anchor="OPAQUEPREFIX" numbered="true" toc="default">
<section anchor="OPAQUEPREFIX" title="Opaque Prefix Attribute TLV"> <name>Opaque Prefix Attribute TLV</name>
<t>The Opaque Prefix Attribute TLV is an envelope that <t>The Opaque Prefix Attribute TLV is an envelope that
transparently carries optional Prefix Attribute TLVs advertised by transparently carries optional Prefix Attribute TLVs advertised by
a router. An originating router shall use this TLV for encoding a router.
information specific to the protocol advertised in the NLRI header An originating router shall use this TLV for encoding information
Protocol-ID field or new protocol extensions to the protocol as specific to the protocol advertised in the NLRI header Protocol-ID
advertised in the NLRI header Protocol-ID field for which there is field or it shall use new protocol extensions for the protocol as
no protocol-neutral representation in the BGP Link-State NLRI. The 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 primary use of the Opaque Prefix Attribute TLV is to bridge the
document lag between a new IGP link-state attribute and its document lag between a new IGP link-state attribute and its
protocol-neutral BGP-LS extension being defined. Once the protocol-neutral BGP-LS extension being defined. Once the
protocol-neutral BGP-LS extensions are defined, the BGP-LS protocol-neutral BGP-LS extensions are defined, the BGP-LS
implementations may still need to advertise the information both implementations may still need to advertise the information both
within the Opaque Attribute TLV and the new TLV definition for within the Opaque Attribute TLV and the new TLV definition for
incremental deployment and transition.</t> incremental deployment and transition.</t>
<t>In the case of OSPFv2, this TLV <bcp14>MUST NOT</bcp14> be used t
<t>In the case of OSPFv2, this TLV MUST NOT be used to advertise o advertise
information carried using TLVs other than those in the OSPFv2 information carried using TLVs other than those in the OSPFv2
Extended Prefix Opaque LSA <xref target="RFC7684"/>. In the case Extended Prefix Opaque LSA <xref target="RFC7684" format="default"/>
of OSPFv3, this TLV MUST NOT be used to advertise TLVs other than .
In the case
of OSPFv3, this TLV <bcp14>MUST NOT</bcp14> be used to advertise TLV
s other than
those in the OSPFv3 E-Inter-Area-Prefix-LSA, those in the OSPFv3 E-Inter-Area-Prefix-LSA,
E-Intra-Area-Prefix-LSA, E-AS-External-Prefix-LSA, and E-NSSA-LSA E-Intra-Area-Prefix-LSA, E-AS-External-LSA, and E-NSSA-LSA
<xref target="RFC8362"/>.</t> <xref target="RFC8362" format="default"/>.</t>
<t>The format of the TLV is as follows:</t> <t>The format of the TLV is as follows:</t>
<figure anchor="OPAQUEPREFIXTLV">
<figure anchor="OPAQUEPREFIXTLV" <name>Opaque Prefix Attribute TLV Format</name>
title="Opaque Prefix Attribute TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (variable) // // Opaque Prefix Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Type is as specified in <xref target="prefix-attribute_tlv" f
<t>The type is as specified in <xref ormat="default"/>. The length is variable.</t>
target="prefix-attribute_tlv"/>. Length is variable.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="PRIVATE" numbered="true" toc="default">
<section anchor="PRIVATE" title="Private Use"> <name>Private Use</name>
<t>TLVs for Vendor Private use are supported using the code point <t>TLVs for Vendor Private Use are supported using the code point
range reserved as indicated in <xref target="IANA"/>. For such TLV use range reserved as indicated in <xref target="IANA" format="default"/>. F
in the NLRI or BGP-LS Attribute, the format as described in <xref or such TLV use
target="TLV-section"/> is to be used and a 4-octet field MUST be in the NLRI or BGP-LS Attribute, the format described in <xref target="T
LV-section" format="default"/> is to be used and a 4-octet field <bcp14>MUST</bc
p14> be
included as the first field in the value to carry the Enterprise Code. included as the first field in the value to carry the Enterprise Code.
For a private use NLRI Type, a 4 octet field MUST be included as the For a private use NLRI type, a 4-octet field <bcp14>MUST</bcp14> be incl uded as the
first field in the NLRI immediately following the Total NLRI Length first field in the NLRI immediately following the Total NLRI Length
field of the Link-State NLRI format as described in <xref field of the Link-State NLRI format as described in <xref target="BGPLSN
target="BGPLSNLRI"/> to carry the Enterprise Code <xref LRI" format="default"/> to carry the Enterprise Code <xref target="ENTNUM" forma
target="ENTNUM"/>. This enables the use of vendor-specific extensions t="default"/>. This enables the use of vendor-specific extensions
without conflicts.</t> without conflicts.</t>
<t>Multiple instances of private-use TLVs <bcp14>MAY</bcp14> appear in t
<t>Multiple instances of private-use TLVs MAY appear in the BGP-LS he BGP-LS
Attribute.</t> Attribute.</t>
</section> </section>
<section anchor="BGPNH" numbered="true" toc="default">
<section anchor="BGPNH" title="BGP Next-Hop Information"> <name>BGP Next-Hop Information</name>
<t>BGP link-state information for both IPv4 and IPv6 networks can be <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 carried over either an IPv4 BGP session or an IPv6 BGP session. If an
IPv4 BGP session is used, then the next-hop in the MP_REACH_NLRI IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI
SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used, <bcp14>SHOULD</bcp14> be an IPv4 address. Similarly, if an IPv6 BGP sess
then the next-hop in the MP_REACH_NLRI SHOULD be an IPv6 address. ion is used,
Usually, the next-hop will be set to the local endpoint address of the then the next hop in the MP_REACH_NLRI <bcp14>SHOULD</bcp14> be an IPv6
BGP session. The next-hop address MUST be encoded as described in address.
<xref target="RFC4760"/>. The Length field of the next-hop address Usually, the next hop will be set to the local endpoint address of the
BGP session. The next-hop address <bcp14>MUST</bcp14> be encoded as desc
ribed in
<xref 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, will specify the next-hop address family. If the next-hop length is 4,
then the next-hop is an IPv4 address; if the next-hop length is 16, then the next hop is an IPv4 address; if the next-hop length is 16,
then it is a global IPv6 address; and if the next-hop length is 32, then it is a global IPv6 address; and if the next-hop length is 32,
then there is one global IPv6 address followed by a link-local IPv6 then there is one global IPv6 address followed by an IPv6 link-local
address. The link-local IPv6 address should be used as described in address. The IPv6 link-local address should be used as described in
<xref target="RFC2545"/>. For VPN Subsequent Address Family Identifier <xref target="RFC2545" format="default"/>. For VPN Subsequent Address Fa
mily Identifier
(SAFI), as per custom, an 8-byte Route Distinguisher set to all zero (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero
is prepended to the next-hop.</t> is prepended to the next hop.</t>
<t>The BGP Next-Hop is used by each BGP-LS Speaker to validate the
<t>The BGP Next-Hop is used by each BGP-LS speaker to validate the
NLRI it receives. In case identical NLRIs are sourced by multiple 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 BGP-LS Producers, the BGP Next-Hop is used to tiebreak as per the
standard BGP path decision process. This specification doesn't mandate standard BGP path decision process. This specification doesn't mandate
any rule regarding the rewrite of the BGP Next-Hop.</t> any rule regarding the rewrite of the BGP Next-Hop.</t>
</section> </section>
<section anchor="INTERAS" numbered="true" toc="default">
<section anchor="INTERAS" title="Inter-AS Links"> <name>Inter-AS Links</name>
<t>The main source of TE information is the IGP, which is not active <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 on inter-AS links. In some cases, the IGP may have information of
inter-AS links <xref target="RFC5392"/> <xref target="RFC9346"/>. In inter-AS links <xref target="RFC5392" format="default"/> <xref target="R
other cases, an implementation SHOULD provide a means to inject FC9346" format="default"/>. In
other cases, an implementation <bcp14>SHOULD</bcp14> provide a means to
inject
inter-AS links into BGP-LS. The exact mechanism used to advertise the inter-AS links into BGP-LS. The exact mechanism used to advertise the
inter-AS links is outside the scope of this document.</t> inter-AS links is outside the scope of this document.</t>
</section> </section>
<section anchor="OSPFVL" numbered="true" toc="default">
<section anchor="OSPFVL" title="OSPF Virtual Links and Sham Links"> <name>OSPF Virtual Links and Sham Links</name>
<t>In an OSPF <xref target="RFC2328"/> <xref target="RFC5340"/> <t>In an OSPF <xref target="RFC2328" format="default"/> <xref target="RF
C5340" format="default"/>
network, OSPF virtual links serve to connect physically separate network, OSPF virtual links serve to connect physically separate
components of the backbone to establish/maintain continuity of the components of the backbone to establish/maintain continuity of the
backbone area. While OSPF virtual links are modeled as point-to-point backbone area. While OSPF virtual links are modeled as point-to-point,
unnumbered links in the OSPF topology, their characteristics and unnumbered links in the OSPF topology, their characteristics and
purpose are different from other types of links in the OSPF topology. purpose are different from other types of links in the OSPF topology.
They are advertised using a distinct "virtual link" type in OSPF LSAs. They are advertised using a distinct "virtual link" type in OSPF LSAs.
The mechanism for the advertisement of OSPF virtual links via BGP-LS The mechanism for the advertisement of OSPF virtual links via BGP-LS
is outside the scope of this document.</t> is outside the scope of this document.</t>
<t>In an OSPF network, sham links <xref target="RFC4577" format="default
<t>In an OSPF network, sham links <xref target="RFC4577"/> <xref "/> <xref target="RFC6565" format="default"/> are used to provide intra-area con
target="RFC6565"/> are used to provide intra-area connectivity between nectivity between
VPN Routing and Forwarding (VRF) instances on PE routers over the VPN VPN Routing and Forwarding (VRF) instances on Provider Edge (PE) routers
over the VPN
provider's network. These links are advertised in OSPF as provider's network. These links are advertised in OSPF as
point-to-point unnumbered links and represent connectivity over a point-to-point, unnumbered links and represent connectivity over a
service provider network using encapsulation mechanisms like MPLS. As service provider network using encapsulation mechanisms like MPLS. As
such, the mechanism for the advertisement of OSPF sham links follows such, the mechanism for the advertisement of OSPF sham links follows
the same procedures as other point-to-point unnumbered links as the same procedures as other point-to-point, unnumbered links as
described previously in this document.</t> described previously in this document.</t>
</section> </section>
<section anchor="OSPFTYPE4" numbered="true" toc="default">
<section anchor="OSPFTYPE4" <name>OSPFv2 Type 4 Summary-LSA &amp; OSPFv3 Inter-Area-Router-LSA</name
title="OSPFv2 Type 4 Summary LSA &amp; OSPFv3 Inter-Area Router L >
SA"> <t>OSPFv2 <xref target="RFC2328" format="default"/> defines the type 4 s
<t>OSPFv2 <xref target="RFC2328"/> defines the Type 4 Summary LSA and ummary-LSA and
OSPFv3 <xref target="RFC5340"/> the Inter-area-router-LSA for an Area OSPFv3 <xref target="RFC5340" format="default"/> defines the inter-area-
router-LSA for an Area
Border Router (ABR) to advertise reachability to an AS Border Router 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 (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 of information advertised by OSPF using this type of LSA does not map
to either a node or a link or a prefix as discussed in this document. to either a node, a link, or a prefix as discussed in this document.
Therefore, the mechanism for the advertisement of the information Therefore, the mechanism for the advertisement of the information
carried by these LSAs is outside the scope of this document.</t> carried by these LSAs is outside the scope of this document.</t>
</section> </section>
<section anchor="UNREACHNODES" numbered="true" toc="default">
<section anchor="UNREACHNODES" title="Handling of Unreachable IGP Nodes"> <name>Handling of Unreachable IGP Nodes</name>
<t>Consider an OSPF network as shown in <xref <t>Consider an OSPF network as shown in <xref target="INCORRECTTOPORR" f
target="INCORRECTTOPORR"/>, where R2 and R3 are the BGP-LS Producers ormat="default"/>, where R2 and R3 are the BGP-LS Producers
and also the OSPF Area Border Routers (ABRs). The link between R2 and and also the OSPF Area Border Routers (ABRs). The link between R2 and
R3 is in area 0 while the other links are in area 1 as indicated by R3 is in area 0, while the other links are in area 1 as indicated by
the a0 and a1 references respectively against the links.</t> the a0 and a1 references respectively against the links.</t>
<t>A BGP-LS Consumer talks to BGP route reflector RR0, which is a
<t>A BGP-LS Consumer talks to a BGP route reflector RR0 which is a BGP-LS Propagator that is aggregating the BGP-LS feed from BGP-LS
BGP-LS Propagator that is aggregating the BGP-LS feed from the BGP-LS Producers R2 and R3. Here, R2 and R3 provide a redundant topology feed
Producers R2 and R3. Here R2 and R3 provide a redundant topology feed
via BGP-LS to RR0. Normally, RR0 would receive two identical copies of 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 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> them (say R2) based on the standard BGP Decision Process.</t>
<figure anchor="INCORRECTTOPORR">
<t><figure anchor="INCORRECTTOPORR" <name>Incorrect Reporting Due to BGP Path Selection</name>
title="Incorrect Reporting due to BGP Path Selection"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
BGP-LS Consumer BGP-LS Consumer
^ ^
| |
RR0 RR0
(BGP Route Reflector) (BGP Route Reflector)
/ \ / \
/ \ / \
a1 / a0 \ a1 a1 / a0 \ a1
R1 ------ R2 -------- R3 ------ R4 R1 ------ R2 -------- R3 ------ R4
a1 | | a1 a1 | | a1
| | | |
R5 ---------------------------- R6 R5 ---------------------------- R6
a1 a1
]]></artwork> ]]></artwork>
</figure>Consider a scenario where the link between R5 and R6 is </figure>
lost (thereby partitioning the area 1) and its impact on the OSPF LSDB <t>Consider a scenario where the link between R5 and R6 is
lost (thereby partitioning the area 1), and consider its impact on the O
SPF LSDB
at R2 and R3.</t> at R2 and R3.</t>
<t>Now, R5 will remove the link R5-R6 from its Router LSA, and this <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 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 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 its LSDB, R2 will advertise only the half-link R6-R5 that it derives
from R6's stale Router LSA.</t> from R6's stale Router LSA.</t>
<t>At the same time, R6 has removed the link R6-R5 from its Router <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 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 stale copy of R5's Router LSA having the link R5-R6 in it. Based on
its LSDB, R3 will advertise only the half-link R5-R6 that it has its LSDB, R3 will advertise only the half-link R5-R6 that it
derived from R5's stale Router LSA.</t> derives from R5's stale Router LSA.</t>
<t>Now, the BGP-LS Consumer receives both the Link NLRIs corresponding <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 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 would not detect or realize that area 1 is partitioned. Also, if R2
continues to report Node and Prefix NLRIs corresponding to the stale continues to report Node and Prefix NLRIs corresponding to the stale
copy of R4 and R6's Router LSAs then RR0 could prefer them over the copy of R4's and R6's Router LSAs, then RR0 could prefer them over the
valid Node and Prefix NLRIs for R4 and R6 that it is receiving from R3 valid Node and Prefix NLRIs for R4 and R6 that it is receiving from R3
depending on RR0's BGP decision process. This would result in the depending on RR0's BGP Decision Process. This would result in the
BGP-LS Consumer getting stale and inaccurate topology information. BGP-LS Consumer getting stale and inaccurate topology information.
This problem scenario is avoided if R2 were to not advertise the 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 link-state information corresponding to R4 and R6 and if R3 were to
not advertise similarly for R1 and R5.</t> not advertise similarly for R1 and R5.</t>
<t>A BGP-LS Producer <bcp14>SHOULD</bcp14> withdraw all link-state objec
<t>A BGP-LS Producer SHOULD withdraw all link-state objects advertised ts advertised
by it in BGP when the node that originated its corresponding LSP/LSAs by it in BGP when the node that originated its corresponding LSPs/LSAs
is determined to have become unreachable in the IGP. An implementation is determined to have become unreachable in the IGP. An implementation
MAY continue to advertise link-state objects corresponding to <bcp14>MAY</bcp14> continue to advertise link-state objects correspondin
unreachable nodes in a deployment use-case where the BGP-LS Consumer g to
unreachable nodes in a deployment use case where the BGP-LS Consumer
is interested in receiving a topology feed corresponding to a complete is interested in receiving a topology feed corresponding to a complete
IGP LSDB view. In such deployments, it is expected that the problem IGP LSDB view. In such deployments, it is expected that the problem
described above is mitigated by the BGP-LS Consumer via appropriate 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 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 direct BGP peering with the BGP-LS Producer nodes or mechanisms such
as <xref target="RFC7911"/> when using RRs. Details of these as those described in <xref target="RFC7911" format="default"/> when usi ng RRs. Details of these
mechanisms are outside the scope of this document.</t> mechanisms are outside the scope of this document.</t>
<t>If the BGP-LS Producer does withdraw link-state objects associated <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 with an IGP node based on the failure of reachability check for that
node, then it MUST re-advertise those link-state objects after that node, then it <bcp14>MUST</bcp14> re-advertise those link-state objects after that
node becomes reachable again in the IGP domain.</t> node becomes reachable again in the IGP domain.</t>
</section> </section>
<section anchor="ISISPN" numbered="true" toc="default">
<section anchor="ISISPN" <name>Router-ID Anchoring Example: ISO Pseudonode</name>
title="Router-ID Anchoring Example: ISO Pseudonode">
<t>The encoding of a broadcast LAN in IS-IS provides a good example of <t>The encoding of a broadcast LAN in IS-IS provides a good example of
how Router-IDs are encoded. Consider <xref target="ISISPseudonodes"/>. how Router-IDs are encoded. Consider <xref target="ISISPseudonodes" form
This represents a Broadcast LAN between a pair of routers. The "real" at="default"/>.
(non-pseudonode) routers have both an IPv4 Router-ID and IS-IS This represents a broadcast LAN between a pair of routers. The "real"
(non-pseudonode) routers have both an IPv4 Router-ID and an IS-IS
Node-ID. The pseudonode does not have an IPv4 Router-ID. Node1 is the Node-ID. The pseudonode does not have an IPv4 Router-ID. Node1 is the
DIS for the LAN. Two unidirectional links (Node1, Pseudonode1) and DIS for the LAN. Two unidirectional links, (Node1, Pseudonode1) and
(Pseudonode1, Node2) are being generated.</t> (Pseudonode1, Node2), are being generated.</t>
<t>The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The <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 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 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 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 Pseudonode1, 1920.0000.2001.02. The BGP-LS Attribute of this link
contains one local IPv4 Router-ID TLV (TLV type 1028) containing contains one local IPv4 Router-ID TLV (TLV type 1028) containing
192.0.2.1, the IPv4 Router-ID of Node1.</t> 192.0.2.1, the IPv4 Router-ID of Node1.</t>
<t>The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The <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 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 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 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 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) this link contains one remote IPv4 Router-ID TLV (TLV type 1030)
containing 192.0.2.2, the IPv4 Router-ID of Node2.</t> containing 192.0.2.2, the IPv4 Router-ID of Node2.</t>
<figure anchor="ISISPseudonodes">
<figure anchor="ISISPseudonodes" title="IS-IS Pseudonodes"> <name>IS-IS Pseudonodes</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 | | Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 | | 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="OSPFPN" numbered="true" toc="default">
<section anchor="OSPFPN" <name>Router-ID Anchoring Example: OSPF Pseudonode</name>
title="Router-ID Anchoring Example: OSPF Pseudonode">
<t>The encoding of a broadcast LAN in OSPF provides a good example of <t>The encoding of a broadcast LAN in OSPF provides a good example of
how Router-IDs and local Interface IPs are encoded. Consider <xref how Router-IDs and local Interface IPs are encoded. Consider <xref targe
target="OSPFPseudonodes"/>. This represents a Broadcast LAN between a t="OSPFPseudonodes" format="default"/>. This represents a broadcast LAN between
a
pair of routers. The "real" (non-pseudonode) routers have both an IPv4 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 and an Area Identifier. The pseudonode does have an IPv4
Router-ID, an IPv4 Interface Address (for disambiguation), and an OSPF Router-ID, an IPv4 Interface Address (for disambiguation), and an OSPF
Area. Node1 is the DR for the LAN; hence, its local IP address 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 198.51.100.1 is used as both the Router-ID and Interface IP for the
pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and
(Pseudonode1, Node2), are being generated.</t> (Pseudonode1, Node2), are being generated.</t>
<t>The Link NLRI of (Node1, Pseudonode1) is encoded as follows: </t>
<t>The Link NLRI of (Node1, Pseudonode1) is encoded as follows: <list <ul spacing="normal">
style="symbols"> <li>
<t>Local Node Descriptor <list style="hanging"> <t>Local Node Descriptor </t>
<t>TLV #515: IGP Router-ID: 192.0.2.1</t> <dl newline="false" spacing="normal">
<dt>TLV #515:</dt>
<t>TLV #514: OSPF Area-ID: ID:0.0.0.0</t> <dd>IGP Router-ID: 192.0.2.1</dd>
</list></t> <dt>TLV #514:</dt>
<dd>OSPF Area-ID: ID:0.0.0.0</dd>
<t>Remote Node Descriptor <list style="hanging"> </dl>
<t>TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1</t> </li>
<li>
<t>TLV #514: OSPF Area-ID: ID:0.0.0.0</t> <t>Remote Node Descriptor </t>
</list></t> <dl newline="false" spacing="normal">
</list></t> <dt>TLV #515:</dt>
<dd>IGP Router-ID: 192.0.2.1:198.51.100.1</dd>
<t>The Link NLRI of (Pseudonode1, Node2) is encoded as follows: <list <dt>TLV #514:</dt>
style="symbols"> <dd>OSPF Area-ID: ID:0.0.0.0</dd>
<t>Local Node Descriptor <list style="hanging"> </dl>
<t>TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1</t> </li>
</ul>
<t>TLV #514: OSPF Area-ID: ID:0.0.0.0</t> <t>The Link NLRI of (Pseudonode1, Node2) is encoded as follows: </t>
</list></t> <ul spacing="normal">
<li>
<t>Remote Node Descriptor <list style="hanging"> <t>Local Node Descriptor </t>
<t>TLV #515: IGP Router-ID: 192.0.2.2</t> <dl newline="false" spacing="normal">
<dt>TLV #515:</dt>
<t>TLV #514: OSPF Area-ID: ID:0.0.0.0</t> <dd>IGP Router-ID: 192.0.2.1:198.51.100.1</dd>
</list></t> <dt>TLV #514:</dt>
</list></t> <dd>OSPF Area-ID: ID:0.0.0.0</dd>
</dl>
<figure anchor="OSPFPseudonodes" title="OSPF Pseudonodes"> </li>
<artwork><![CDATA[ <li>
<t>Remote Node Descriptor </t>
<dl newline="false" spacing="normal">
<dt>TLV #515:</dt>
<dd>IGP Router-ID: 192.0.2.2</dd>
<dt>TLV #514:</dt>
<dd>OSPF Area-ID: ID:0.0.0.0</dd>
</dl>
</li>
</ul>
<figure anchor="OSPFPseudonodes">
<name>OSPF Pseudonodes</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
198.51.100.1/24 198.51.100.2/24 198.51.100.1/24 198.51.100.2/24
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Node1 | | Pseudonode1 | | Node2 | | Node1 | | Pseudonode1 | | Node2 |
| 192.0.2.1 |--->| 192.0.2.1 |--->| 192.0.2.2 | | 192.0.2.1 |--->| 192.0.2.1 |--->| 192.0.2.2 |
| | |198.51.100.1 | | | | | |198.51.100.1 | | |
| Area 0 | | Area 0 | | Area 0 | | Area 0 | | Area 0 | | Area 0 |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t/>
<t>The LAN subnet 198.51.100.0/24 is not included in the Router LSA of <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 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. 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 A Prefix NLRI corresponding to the LAN subnet is advertised with the
Pseudonode1 used as the Local node using the DR address and the subnet Pseudonode1 used as the local node using the DR address and the subnet
mask from the Network LSA.</t> mask from the Network LSA.</t>
</section> </section>
<section anchor="OSPF2ISIS" numbered="true" toc="default">
<section anchor="OSPF2ISIS" <name>Router-ID Anchoring Example: OSPFv2 to IS-IS Migration</name>
title="Router-ID Anchoring Example: OSPFv2 to IS-IS Migration">
<t>Graceful migration from one IGP to another requires coordinated <t>Graceful migration from one IGP to another requires coordinated
operation of both protocols during the migration period. Such operation of both protocols during the migration period. Such
coordination requires identifying a given physical link in both IGPs. coordination requires identifying a given physical link in both IGPs.
The IPv4 Router-ID provides that "glue", which is present in the Node 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 Descriptors of the OSPF Link NLRI and in the link attribute of the
IS-IS Link NLRI.</t> IS-IS Link NLRI.</t>
<t>Consider a point-to-point link between two routers, A and B, which
<t>Consider a point-to-point link between two routers, A and B, that initially were OSPFv2-only routers and then had IS-IS enabled on them.
initially were OSPFv2-only routers and then IS-IS is enabled on them.
Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 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 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 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 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 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 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 local and remote Node Descriptors, respectively. In addition, the
BGP-LS Attribute of the IS-IS Link NLRI contains the TLV type 1028 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 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 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 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> (A, B) can be identified in both the IS-IS and OSPF protocols.</t>
</section> </section>
</section> </section>
<section anchor="LINKPATHAGGREGATION" numbered="true" toc="default">
<section anchor="LINKPATHAGGREGATION" title="Link to Path Aggregation"> <name>Link to Path Aggregation</name>
<t>Distribution of all links available on the global Internet is <t>Distribution of all links available on the global Internet is
certainly possible; however, it is not desirable from a scaling and certainly possible; however, it is not desirable from a scaling and
privacy point of view. Therefore, an implementation may support a link privacy point of view. Therefore, an implementation may support a link
to path aggregation. Rather than advertising all specific links of a to path aggregation. Rather than advertising all specific links of a
domain, an ASBR may advertise an "aggregate link" between a non-adjacent domain, an ASBR may advertise an "aggregate link" between a non-adjacent
pair of nodes. The "aggregate link" represents the aggregated set of pair of nodes. The "aggregate link" represents the aggregated set of
link properties between a pair of non-adjacent nodes. The actual methods link properties between a pair of non-adjacent nodes. The actual methods
to compute the path properties (of bandwidth, metric, etc.) are outside to compute the path properties (of bandwidth, metric, etc.) are outside
the scope of this document. The decision of whether to advertise all the scope of this document. The decision of whether to advertise all
specific links or aggregated links is an operator's policy choice. To specific links or aggregated links is an operator's policy choice. To
highlight the varying levels of exposure, the following deployment highlight the varying levels of exposure, the following deployment
examples are discussed.</t> examples are discussed.</t>
<section numbered="true" toc="default">
<section title="Example: No Link Aggregation"> <name>Example: No Link Aggregation</name>
<t>Consider <xref target="no-link-aggregation"/>. Both AS1 and AS2 <t>Consider <xref target="no-link-aggregation" format="default"/>. Both
AS1 and AS2
operators want to protect their inter-AS {R1, R3}, {R2, R4} links operators want to protect their inter-AS {R1, R3}, {R2, R4} links
using RSVP-FRR LSPs. If R1 wants to compute its link-protection LSP to using RSVP - Fast Reroute (RSVP-FRR) LSPs. If R1 wants to compute its li nk-protection LSP to
R3, it needs to "see" an alternate path to R3. Therefore, the AS2 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" 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 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} that the computing router decides if the direct link between {R3, R4}
or the {R4, R5, R3} path is used. <figure anchor="no-link-aggregation" or the {R4, R5, R3} path is used. </t>
title="No Link Aggregation"> <figure anchor="no-link-aggregation">
<artwork><![CDATA[ <name>No Link Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
AS1 : AS2 AS1 : AS2
: :
R1-------R3 R1-------R3
| : | \ | : | \
| : | R5 | : | R5
| : | / | : | /
R2-------R4 R2-------R4
: :
: :
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Example: ASBR to ASBR Path Aggregation"> <name>Example: ASBR to ASBR Path Aggregation</name>
<t>The brief difference between the "no-link aggregation" example and <t>The brief difference between the "no-link aggregation" example and
this example is that no specific link gets exposed. Consider <xref this example is that no specific link gets exposed. Consider <xref targe
target="asbr-link-aggregation"/>. The only link that gets advertised t="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 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 tell AS1 that there is a backup path. However, the actual links being
used are hidden from the topology.</t> used are hidden from the topology.</t>
<figure anchor="asbr-link-aggregation">
<figure anchor="asbr-link-aggregation" title="ASBR Link Aggregation"> <name>ASBR Link Aggregation</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
AS1 : AS2 AS1 : AS2
: :
R1-------R3 R1-------R3
| : | | : |
| : | | : |
| : | | : |
R2-------R4 R2-------R4
: :
: :
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Example: Multi-AS Path Aggregation"> <name>Example: Multi-AS Path Aggregation</name>
<t>Service providers in control of multiple ASes may even decide to <t>Service providers in control of multiple ASes may even decide to
not expose their internal inter-AS links. Consider <xref not expose their internal inter-AS links. Consider <xref target="multi-a
target="multi-as-aggregation"/>. AS3 is modeled as a single node that s-aggregation" format="default"/>. AS3 is modeled as a single node that
connects to the border routers of the aggregated domain. <figure connects to the border routers of the aggregated domain. </t>
anchor="multi-as-aggregation" title="Multi-AS Aggregation"> <figure anchor="multi-as-aggregation">
<artwork><![CDATA[ <name>Multi-AS Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
AS1 : AS2 : AS3 AS1 : AS2 : AS3
: : : :
R1-------R3----- R1-------R3-----
| : : \ | : : \
| : : vR0 | : : vR0
| : : / | : : /
R2-------R4----- R2-------R4-----
: : : :
: : : :
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>As this document obsoletes <xref target="RFC7752"/> and <xref <t>As this document obsoletes <xref target="RFC7752" format="default"/> an
target="RFC9029"/>, IANA is requested to change all registration d <xref target="RFC9029" format="default"/>, IANA has updated all registration
information that references those documents to instead reference this information that references those documents to instead reference this
document.</t> document.</t>
<t>IANA has assigned address family number 16388 (BGP-LS) in the <t>IANA has assigned address family number 16388 (BGP-LS) in the
"Address Family Numbers" registry.</t> "Address Family Numbers" registry.</t>
<t>IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the <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 Values" registry under the "Subsequent Address Family Identifiers
(SAFI) Parameters" registry group.</t> (SAFI) Parameters" registry group.</t>
<t>IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path <t>IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path
Attributes" registry under the "Border Gateway Protocol (BGP) Attributes" registry under the "Border Gateway Protocol (BGP)
Parameters" registry group.</t> Parameters" registry group.</t>
<t>IANA has created a "Border Gateway Protocol - Link-State (BGP-LS) <t>IANA has created a "Border Gateway Protocol - Link-State (BGP-LS)
Parameters" registry group at Parameters" registry group at
&lt;https://www.iana.org/assignments/bgp-ls-parameters&gt;.</t> <eref target="https://www.iana.org/assignments/bgp-ls-parameters" brackets
="angle"/>.</t>
<t>This section also incorporates all the changes to the allocation <t>This section also incorporates all the changes to the allocation
procedures for the BGP-LS IANA registry group as well as the guidelines procedures for the BGP-LS IANA registry group as well as the guidelines
for designated experts introduced by <xref target="RFC9029"/>.</t> for designated experts introduced by <xref target="RFC9029" format="defaul
t"/>.</t>
<section anchor="Registries" title="BGP-LS Registries"> <section anchor="Registries" numbered="true" toc="default">
<name>BGP-LS Registries</name>
<t>All of the registries listed in the following subsections are <t>All of the registries listed in the following subsections are
BGP-LS specific and are accessible under this registry.</t> specific to BGP-LS and are accessible under this registry.</t>
<section anchor="NLRITYPESREG" numbered="true" toc="default">
<section anchor="NLRITYPESREG" title="BGP-LS NLRI Types Registry"> <name>BGP-LS NLRI Types Registry</name>
<t>The "BGP-LS NLRI Types" registry has been set up for assignment <t>The "BGP-LS NLRI Types" registry has been set up for assignment
for the two-octet sized code-points for BGP-LS NLRI types and for the two-octet-sized code points for BGP-LS NLRI types and
populated with the values shown below:</t> populated with the values shown below:</t>
<table anchor="nlri_types_table" align="center">
<texttable anchor="nlri_types_table" title="BGP-LS NLRI Types"> <name>BGP-LS NLRI Types</name>
<ttcol align="center">Type</ttcol> <thead>
<tr>
<ttcol align="left">NLRI Type</ttcol> <th align="center">Type</th>
<th align="left">NLRI Type</th>
<ttcol align="right">Reference</ttcol> <th align="right">Reference</th>
</tr>
<c>0</c> </thead>
<tbody>
<c>Reserved</c> <tr>
<td align="center">0</td>
<c>[This document]</c> <td align="left">Reserved</td>
<td align="right">RFC 9552</td>
<c>1</c> </tr>
<tr>
<c>Node NLRI</c> <td align="center">1</td>
<td align="left">Node NLRI</td>
<c>[This document]</c> <td align="right">RFC 9552</td>
</tr>
<c>2</c> <tr>
<td align="center">2</td>
<c>Link NLRI</c> <td align="left">Link NLRI</td>
<td align="right">RFC 9552</td>
<c>[This document]</c> </tr>
<tr>
<c>3</c> <td align="center">3</td>
<td align="left">IPv4 Topology Prefix NLRI</td>
<c>IPv4 Topology Prefix NLRI</c> <td align="right">RFC 9552</td>
</tr>
<c>[This document]</c> <tr>
<td align="center">4</td>
<c>4</c> <td align="left">IPv6 Topology Prefix NLRI</td>
<td align="right">RFC 9552</td>
<c>IPv6 Topology Prefix NLRI</c> </tr>
<tr>
<c>[This document]</c> <td align="center">65000-65535</td>
<td align="left">Private Use</td>
<c>65000-65535</c> <td align="right">RFC 9552</td>
</tr>
<c>Private Use</c> </tbody>
</table>
<c>[This document]</c> <t>A range is reserved for Private Use <xref target="RFC8126" format="
</texttable> default"/>. All
<t>A range is reserved for Private Use <xref target="RFC8126"/>. All
other allocations within the registry are to be made using the other allocations within the registry are to be made using the
"Expert Review" policy <xref target="RFC8126"/> that requires "Expert Review" policy <xref target="RFC8126" format="default"/>, whic h requires
documentation of the proposed use of the allocated value and documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG.</t> approval by the designated expert assigned by the IESG.</t>
</section> </section>
<section anchor="PROTOIDREG" numbered="true" toc="default">
<section anchor="PROTOIDREG" title="BGP-LS Protocol-IDs Registry"> <name>BGP-LS Protocol-IDs Registry</name>
<t>The "BGP-LS Protocol-IDs" registry has been set up for assignment <t>The "BGP-LS Protocol-IDs" registry has been set up for assignment
for the one-octet sized code-points for BGP-LS Protocol-IDs and for the one-octet-sized code points for BGP-LS Protocol-IDs and
populated with the values shown below:</t> populated with the values shown below:</t>
<table anchor="protoid_types_table" align="center">
<texttable anchor="protoid_types_table" title="BGP-LS Protocol-IDs"> <name>BGP-LS Protocol-IDs</name>
<ttcol align="center">Protocol-ID</ttcol> <thead>
<tr>
<ttcol align="left">NLRI information source protocol</ttcol> <th align="center">Protocol-ID</th>
<th align="left">NLRI information source protocol</th>
<ttcol align="right">Reference</ttcol> <th align="right">Reference</th>
</tr>
<c>0</c> </thead>
<tbody>
<c>Reserved</c> <tr>
<td align="center">0</td>
<c>[This document]</c> <td align="left">Reserved</td>
<td align="right">RFC 9552</td>
<c>1</c> </tr>
<tr>
<c>IS-IS Level 1</c> <td align="center">1</td>
<td align="left">IS-IS Level 1</td>
<c>[This document]</c> <td align="right">RFC 9552</td>
</tr>
<c>2</c> <tr>
<td align="center">2</td>
<c>IS-IS Level 2</c> <td align="left">IS-IS Level 2</td>
<td align="right">RFC 9552</td>
<c>[This document]</c> </tr>
<tr>
<c>3</c> <td align="center">3</td>
<td align="left">OSPFv2</td>
<c>OSPFv2</c> <td align="right">RFC 9552</td>
</tr>
<c>[This document]</c> <tr>
<td align="center">4</td>
<c>4</c> <td align="left">Direct</td>
<td align="right">RFC 9552</td>
<c>Direct</c> </tr>
<tr>
<c>[This document]</c> <td align="center">5</td>
<td align="left">Static configuration</td>
<c>5</c> <td align="right">RFC 9552</td>
</tr>
<c>Static configuration</c> <tr>
<td align="center">6</td>
<c>[This document]</c> <td align="left">OSPFv3</td>
<td align="right">RFC 9552</td>
<c>6</c> </tr>
<tr>
<c>OSPFv3</c> <td align="center">200-255</td>
<td align="left">Private Use</td>
<c>[This document]</c> <td align="right">RFC 9552</td>
</tr>
<c>200-255</c> </tbody>
</table>
<c>Private Use</c> <t>A range is reserved for Private Use <xref target="RFC8126" format="
default"/>. All
<c>[This document]</c>
</texttable>
<t>A range is reserved for Private Use <xref target="RFC8126"/>. All
other allocations within the registry are to be made using the other allocations within the registry are to be made using the
"Expert Review" policy <xref target="RFC8126"/> that requires "Expert Review" policy <xref target="RFC8126" format="default"/>, whic h requires
documentation of the proposed use of the allocated value and documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG.</t> approval by the designated expert assigned by the IESG.</t>
</section> </section>
<section anchor="INSTIDREG" numbered="true" toc="default">
<section anchor="INSTIDREG" <name>BGP-LS Well-Known Instance-IDs Registry</name>
title="BGP-LS Well-Known Instance-IDs Registry">
<t>The "BGP-LS Well-Known Instance-IDs" registry that was set up via <t>The "BGP-LS Well-Known Instance-IDs" registry that was set up via
<xref target="RFC7752"/> is no longer required. IANA is requested to <xref target="RFC7752" format="default"/> is no longer required. IANA
mark this registry as obsolete and to change its registration has
marked this registry obsolete and changed its registration
procedure to "registry closed".</t> procedure to "registry closed".</t>
</section> </section>
<section anchor="NFLAGSIDREG" numbered="true" toc="default">
<section anchor="NFLAGSIDREG" title="BGP-LS Node Flags Registry"> <name>BGP-LS Node Flags Registry</name>
<t>The "BGP-LS Node Flags" registry is requested to be created for <t>The "BGP-LS Node Flags" registry has been created for
the one octet-sized flags field of the Node Flag Bits TLV (1024) and the one-octet-sized flags field of the Node Flag Bits TLV (1024) and
populated with the initial values shown below:</t> populated with the initial values shown below:</t>
<table anchor="node_flags_bit_table" align="center">
<texttable anchor="node_flags_bit_table" title="BGP-LS Node Flags"> <name>BGP-LS Node Flags</name>
<ttcol align="center">Bit</ttcol> <thead>
<tr>
<ttcol align="left">Description</ttcol> <th align="center">Bit</th>
<th align="left">Description</th>
<ttcol align="right">Reference</ttcol> <th align="right">Reference</th>
</tr>
<c>0</c> </thead>
<tbody>
<c>Overload Bit (O-bit)</c> <tr>
<td align="center">0</td>
<c>[This document]</c> <td align="left">Overload Bit (O-bit)</td>
<td align="right">RFC 9552</td>
<c>1</c> </tr>
<tr>
<c>Attached Bit (A-bit)</c> <td align="center">1</td>
<td align="left">Attached Bit (A-bit)</td>
<c>[This document]</c> <td align="right">RFC 9552</td>
</tr>
<c>2</c> <tr>
<td align="center">2</td>
<c>External Bit (E-bit)</c> <td align="left">External Bit (E-bit)</td>
<td align="right">RFC 9552</td>
<c>[This document]</c> </tr>
<tr>
<c>3</c> <td align="center">3</td>
<td align="left">ABR Bit (B-bit)</td>
<c>ABR Bit (B-bit)</c> <td align="right">RFC 9552</td>
</tr>
<c>[This document]</c> <tr>
<td align="center">4</td>
<c>4</c> <td align="left">Router Bit (R-bit)</td>
<td align="right">RFC 9552</td>
<c>Router Bit (R-bit)</c> </tr>
<tr>
<c>[This document]</c> <td align="center">5</td>
<td align="left">V6 Bit (V-bit)</td>
<c>5</c> <td align="right">RFC 9552</td>
</tr>
<c>V6 Bit (V-bit)</c> <tr>
<td align="center">6-7</td>
<c>[This document]</c> <td align="left">Unassigned</td>
<td align="right"></td>
<c>6-7</c> </tr>
</tbody>
<c>Unassigned</c> </table>
<c>[This document]</c>
</texttable>
<t>Allocations within the registry are to be made using the "Expert <t>Allocations within the registry are to be made using the "Expert
Review" policy <xref target="RFC8126"/> that requires documentation Review" policy <xref target="RFC8126" format="default"/>, which requir es documentation
of the proposed use of the allocated value and approval by the of the proposed use of the allocated value and approval by the
Designated Expert assigned by the IESG.</t> designated expert assigned by the IESG.</t>
</section> </section>
<section anchor="MPLSMASKREG" numbered="true" toc="default">
<section anchor="MPLSMASKREG" <name>BGP-LS MPLS Protocol Mask Registry</name>
title="BGP-LS MPLS Protocol Mask Registry"> <t>The "BGP-LS MPLS Protocol Mask" registry has been
<t>The "BGP-LS MPLS Protocol Mask" registry is requested to be created for the one-octet-sized flags field of the MPLS Protocol
created for the one octet-sized flags field of the MPLS Protocol
Mask TLV (1094) and populated with the initial values shown Mask TLV (1094) and populated with the initial values shown
below:</t> below:</t>
<table anchor="mpls_proto_mask_table" align="center">
<texttable anchor="mpls_proto_mask_table" <name>BGP-LS MPLS Protocol Mask</name>
title="BGP-LS MPLS Protocol Mask"> <thead>
<ttcol align="center">Bit</ttcol> <tr>
<th align="center">Bit</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="right">Reference</th>
<ttcol align="right">Reference</ttcol> </tr>
</thead>
<c>0</c> <tbody>
<tr>
<c>Label Distribution Protocol (L-bit)</c> <td align="center">0</td>
<td align="left">Label Distribution Protocol (L-bit)</td>
<c>[This document]</c> <td align="right">RFC 9552</td>
</tr>
<c>1</c> <tr>
<td align="center">1</td>
<c>Extension to RSVP for LSP Tunnels (R-bit)</c> <td align="left">Extension to RSVP for LSP Tunnels (R-bit)</td>
<td align="right">RFC 9552</td>
<c>[This document]</c> </tr>
<tr>
<c>2-7</c> <td align="center">2-7</td>
<td align="left">Unassigned</td>
<c>Unassigned</c> <td align="right"></td>
</tr>
<c>[This document]</c> </tbody>
</texttable> </table>
<t>Allocations within the registry are to be made using the "Expert <t>Allocations within the registry are to be made using the "Expert
Review" policy <xref target="RFC8126"/> that requires documentation Review" policy <xref target="RFC8126" format="default"/>, which requir es documentation
of the proposed use of the allocated value and approval by the of the proposed use of the allocated value and approval by the
Designated Expert assigned by the IESG.</t> designated expert assigned by the IESG.</t>
</section> </section>
<section anchor="IGPPFLAGSREG" numbered="true" toc="default">
<section anchor="IGPPFLAGSREG" <name>BGP-LS IGP Prefix Flags Registry</name>
title="BGP-LS IGP Prefix Flags Registry"> <t>The "BGP-LS IGP Prefix Flags" registry has been created
<t>The "BGP-LS IGP Prefix Flags" registry is requested to be created for the one-octet-sized flags field of the IGP Flags TLV (1152) and
for the one octet-sized flags field of the IGP Flags TLV (1152) and
populated with the initial values shown below:</t> populated with the initial values shown below:</t>
<table anchor="prefix_flags_bit_table" align="center">
<texttable anchor="prefix_flags_bit_table" <name>BGP-LS IGP Prefix Flags</name>
title="BGP-LS IGP Prefix Flags"> <thead>
<ttcol align="center">Bit</ttcol> <tr>
<th align="center">Bit</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="right">Reference</th>
<ttcol align="right">Reference</ttcol> </tr>
</thead>
<c>0</c> <tbody>
<tr>
<c>IS-IS Up/Down Bit (D-bit)</c> <td align="center">0</td>
<td align="left">IS-IS Up/Down Bit (D-bit)</td>
<c>[This document]</c> <td align="right">RFC 9552</td>
</tr>
<c>1</c> <tr>
<td align="center">1</td>
<c>OSPF "no unicast" Bit (N-bit)</c> <td align="left">OSPF "no unicast" Bit (N-bit)</td>
<td align="right">RFC 9552</td>
<c>[This document]</c> </tr>
<tr>
<c>2</c> <td align="center">2</td>
<td align="left">OSPF "local address" Bit (L-bit)</td>
<c>OSPF "local address" Bit (L-bit)</c> <td align="right">RFC 9552</td>
</tr>
<c>[This document]</c> <tr>
<td align="center">3</td>
<c>3</c> <td align="left">OSPF "propagate NSSA" Bit (P-bit)</td>
<td align="right">RFC 9552</td>
<c>OSPF "propagate NSSA" Bit (P-bit)</c> </tr>
<tr>
<c>[This document]</c> <td align="center">4-7</td>
<td align="left">Unassigned</td>
<c>4-7</c> <td align="right"></td>
</tr>
<c>Unassigned</c> </tbody>
</table>
<c>[This document]</c>
</texttable>
<t>Allocations within the registry are to be made using the "Expert <t>Allocations within the registry are to be made using the "Expert
Review" policy <xref target="RFC8126"/> that requires documentation Review" policy <xref target="RFC8126" format="default"/>, which requir es documentation
of the proposed use of the allocated value and approval by the of the proposed use of the allocated value and approval by the
Designated Expert assigned by the IESG.</t> designated expert assigned by the IESG.</t>
</section> </section>
<section anchor="TLVREG" title="BGP-LS TLVs Registry"> <section anchor="TLVREG" numbered="true" toc="default">
<name>BGP-LS TLVs Registry</name>
<t>The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, <t>The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor,
and Attribute TLVs" registry was created via <xref and Attribute TLVs" registry was created via <xref target="RFC7752" fo
target="RFC7752"/>. This document requests IANA to rename that rmat="default"/>. Per this document, IANA has renamed that
registry to "BGP-LS NLRI and Attribute TLVs" and to remove the registry to "BGP-LS NLRI and Attribute TLVs" and removed the
column for "IS-IS TLV/Sub-TLV". The registration procedures are as column for "IS-IS TLV/Sub-TLV". The registration procedures are as
below:</t> follows:</t>
<table anchor="reg_types" align="center">
<texttable anchor="reg_types" <name>BGP-LS TLVs Registration Process</name>
title="BGP-LS TLVs Registration Process"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Registration Process</ttcol> <th align="left">Registration Process</th>
</tr>
<c>0-255</c> </thead>
<tbody>
<c>Reserved (not to be allocated)</c> <tr>
<td align="center">0-255</td>
<c>256-64999</c> <td align="left">Reserved (not to be allocated)</td>
</tr>
<c>Expert Review</c> <tr>
<td align="center">256-64999</td>
<c>65000-65535</c> <td align="left">Expert Review</td>
</tr>
<c>Private Use</c> <tr>
</texttable> <td align="center">65000-65535</td>
<td align="left">Private Use</td>
<t>A range is reserved for Private Use <xref target="RFC8126"/>. All </tr>
</tbody>
</table>
<t>A range is reserved for Private Use <xref target="RFC8126" format="
default"/>. All
other allocations except for the reserved range within the registry other allocations except for the reserved range within the registry
are to be made using the "Expert Review" policy <xref are to be made using the "Expert Review" policy <xref target="RFC8126"
target="RFC8126"/> that requires documentation of the proposed use format="default"/>, which requires documentation of the proposed use
of the allocated value and approval by the Designated Expert of the allocated value and approval by the designated expert
assigned by the IESG.</t> assigned by the IESG.</t>
<t>The registry was pre-populated with the values shown in <xref targe
<t>The registry was pre-populated with the values shown in <xref t="BGPLSCODEPOINTS" format="default"/>, and the reference for each
target="BGPLSCODEPOINTS"/> and the reference for all those allocation has been changed to this document and the respective
allocations should be changed to this document and the respective
section where those TLVs are specified.</t> section where those TLVs are specified.</t>
</section> </section>
</section> </section>
<section anchor="DE-Guidance" numbered="true" toc="default">
<section anchor="DE-Guidance" title="Guidance for Designated Experts"> <name>Guidance for Designated Experts</name>
<t>In all cases of review by the designated expert described here, the <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 designated expert is expected to check the clarity of purpose and use
of the requested code points. The following points apply to the of the requested code points. The following points apply to the
registries discussed in this document:</t> registries discussed in this document:</t>
<ol spacing="normal" type="1"><li>Application for a code point allocatio
<t><list style="numbers"> n may be made to the
<t>Application for a code point allocation may be made to the designated experts at any time and <bcp14>MUST</bcp14> be accompanie
designated experts at any time and MUST be accompanied by d by
technical documentation explaining the use of the code point. Such technical documentation explaining the use of the code point. Such
documentation SHOULD be presented in the form of an documentation <bcp14>SHOULD</bcp14> be presented in the form of an
Internet-Draft, but MAY arrive in any form that can be reviewed Internet-Draft but <bcp14>MAY</bcp14> arrive in any form that can be
and exchanged among reviewers.</t> reviewed
and exchanged among reviewers.</li>
<t>The designated experts SHOULD only consider requests that arise <li>The designated experts <bcp14>SHOULD</bcp14> only consider request
s that arise
from Internet-Drafts that have already been accepted as working from Internet-Drafts that have already been accepted as working
group documents or that are planned for progression as group documents or that are planned for progression as
AD-Sponsored documents in the absence of a suitably chartered AD-Sponsored documents in the absence of a suitably chartered
working group.</t> working group.</li>
<li>In the case of working group documents, the designated experts
<t>In the case of working group documents, the designated experts <bcp14>MUST</bcp14> check with the working group chairs that there i
MUST check with the working group chairs that there is a consensus s a consensus
within the working group to allocate at this time. In the case of within the working group to allocate at this time. In the case of
AD-Sponsored documents, the designated experts MUST check with the AD-Sponsored documents, the designated experts <bcp14>MUST</bcp14> c
AD for approval to allocate at this time.</t> heck with the
AD for approval to allocate at this time.</li>
<t>If the document is not adopted by the IDR Working Group (or its <li>If the document is not adopted by the IDR Working Group (or its
successor), the designated expert MUST notify the IDR mailing list successor), the designated expert <bcp14>MUST</bcp14> notify the IDR
(or its successor) of the request and MUST provide access to the mailing list
document. The designated expert MUST allow two weeks for any (or its successor) of the request and <bcp14>MUST</bcp14> provide ac
response. Any comments received MUST be considered by the cess to the
designated expert as part of the subsequent step.</t> document. The designated expert <bcp14>MUST</bcp14> allow two weeks
for any
<t>The designated experts MUST then review the assignment requests response. Any comments received <bcp14>MUST</bcp14> be considered by
on their technical merit. The designated experts MAY raise issues the
designated expert as part of the subsequent step.</li>
<li>The designated experts <bcp14>MUST</bcp14> then review the assignm
ent requests
on their technical merit. The designated experts <bcp14>MAY</bcp14>
raise issues
related to the allocation request with the authors and on the IDR related to the allocation request with the authors and on the IDR
(or successor) mailing list for further consideration before the (or successor) mailing list for further consideration before the
assignments are made.</t> assignments are made.</li>
<li>The designated expert <bcp14>MUST</bcp14> ensure that any request
<t>The designated expert MUST ensure that any request for a code for a code
point does not conflict with work that is active or already point does not conflict with work that is active or already
published within the IETF.</t> published within the IETF.</li>
<li>Once the designated experts have approved, IANA will update the
<t>Once the designated experts have approved, IANA will update the
registry by marking the allocated code points with a reference to registry by marking the allocated code points with a reference to
the associated document.</t> the associated document.</li>
<li>In the event that the document is a working group document or
<t>In the event that the document is a working group document or is AD-Sponsored and fails to progress to
is AD-Sponsored, and that document fails to progress to publication as an RFC, the working group chairs or AD <bcp14>SHOULD<
publication as an RFC, the working group chairs or AD SHOULD /bcp14>
contact IANA to coordinate about marking the code points as contact IANA to coordinate about marking the code points as
deprecated. A deprecated code point is not marked as allocated for deprecated. A deprecated code point is not marked as allocated for
use and is not available for allocation in a future document. The use and is not available for allocation in a future document. The
WG chairs may inform IANA that a deprecated code point can be WG chairs may inform IANA that a deprecated code point can be
completely deallocated (i.e., made available for new allocations) completely deallocated (i.e., made available for new allocations)
at any time after it has been deprecated if there is a shortage of at any time after it has been deprecated if there is a shortage of
unallocated code points in the registry.</t> unallocated code points in the registry.</li>
</list></t> </ol>
</section> </section>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>This section is structured as recommended in <xref <t>This section is structured as recommended in <xref target="RFC5706" for
target="RFC5706"/>.</t> mat="default"/>.</t>
<section anchor="Operational-Considerations" numbered="true" toc="default"
<section anchor="Operational-Considerations" >
title="Operational Considerations"> <name>Operational Considerations</name>
<section anchor="Operations" title="Operations"> <section anchor="Operations" numbered="true" toc="default">
<name>Operations</name>
<t>Existing BGP operational procedures apply. No new operation <t>Existing BGP operational procedures apply. No new operation
procedures are defined in this document. It is noted that the NLRI procedures are defined in this document. It is noted that the NLRI
information present in this document carries purely information present in this document carries purely
application-level data that has no immediate impact on the application-level data that has no immediate impact on the
corresponding forwarding state computed by BGP. As such, any churn corresponding forwarding state computed by BGP. As such, any churn
in reachability information has a different impact than regular BGP in reachability information has a different impact than regular BGP
updates, which need to change the forwarding state for an entire updates, which need to change the forwarding state for an entire
router. Distribution of the BGP-LS NLRIs SHOULD be handled by router. Distribution of the BGP-LS NLRIs <bcp14>SHOULD</bcp14> be hand led by
dedicated route reflectors in most deployments providing a level of dedicated route reflectors in most deployments providing a level of
isolation and fault containment between different BGP address isolation and fault containment between different BGP address
families. In the event of dedicated route reflectors not being families. In the event of dedicated route reflectors not being
available, other alternate mechanisms like separation of BGP available, other alternate mechanisms like separation of BGP
instances or separate BGP sessions (e.g. using different addresses instances or separate BGP sessions (e.g., using different addresses
for peering) for Link-State information distribution SHOULD be for peering) for Link-State information distribution <bcp14>SHOULD</bc
p14> be
used.</t> used.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that operators deploying BGP-LS en
<t>It is RECOMMENDED that operators deploying BGP-LS enable two or able two or
more BGP-LS Producers in each IGP flooding domain to achieve more BGP-LS Producers in each IGP flooding domain to achieve
redundancy in the origination of link-state information into BGP-LS. redundancy in the origination of link-state information into BGP-LS.
It is also RECOMMENDED that operators ensure BGP peering designs It is also <bcp14>RECOMMENDED</bcp14> that operators ensure BGP peerin g designs
that ensure redundancy in the BGP update propagation paths (e.g., that ensure redundancy in the BGP update propagation paths (e.g.,
using at least a pair of route reflectors) and ensuring that BGP-LS using at least a pair of route reflectors) and ensure that BGP-LS
Consumers are receiving the topology information from at least two Consumers are receiving the topology information from at least two
BGP-LS Speakers.</t> BGP-LS Speakers.</t>
<t>In a multi-domain IGP network, the correct provisioning of the <t>In a multi-domain IGP network, the correct provisioning of the
BGP-LS Instance-IDs on the BGP-LS Producers is required for BGP-LS Instance-IDs on the BGP-LS Producers is required for
consistent reporting of the multi-domain link-state topology. Refer consistent reporting of the multi-domain link-state topology. Refer
to <xref target="BGPLSNLRI"/> for more details.</t> to <xref target="BGPLSNLRI" format="default"/> for more details.</t>
</section> </section>
<section anchor="Initial-Setup" numbered="true" toc="default">
<section anchor="Initial-Setup" title="Installation and Initial Setup"> <name>Installation and Initial Setup</name>
<t>Configuration parameters defined in <xref <t>Configuration parameters defined in <xref target="Configuration-Man
target="Configuration-Management"/> SHOULD be initialized to the agement" format="default"/> <bcp14>SHOULD</bcp14> be initialized to the
following default values: <list style="symbols"> following default values: </t>
<t>The Link-State NLRI capability is turned off for all <ul spacing="normal">
neighbors.</t> <li>The Link-State NLRI capability is turned off for all
neighbors.</li>
<t>The maximum rate at which Link-State NLRIs will be <li>The maximum rate at which Link-State NLRIs will be
advertised/withdrawn from neighbors is set to 200 updates per advertised/withdrawn from neighbors is set to 200 updates per
second.</t> second.</li>
</list></t> </ul>
</section> </section>
<section anchor="Migration-Path" numbered="true" toc="default">
<section anchor="Migration-Path" title="Migration Path"> <name>Migration Path</name>
<t>The proposed extension is only activated between BGP peers after <t>The proposed extension is only activated between BGP peers after
capability negotiation. Moreover, the extensions can be turned capability negotiation. Moreover, the extensions can be turned
on/off on an individual peer basis (see <xref on/off on an individual peer basis (see <xref target="Configuration-Ma
target="Configuration-Management"/>), so the extension can be nagement" format="default"/>), so the extension can be
gradually rolled out in the network.</t> gradually rolled out in the network.</t>
</section> </section>
<section anchor="Other-Protocols" numbered="true" toc="default">
<section anchor="Other-Protocols" <name>Requirements for Other Protocols and Functional Components</name
title="Requirements for Other Protocols and Functional Componen >
ts">
<t>The protocol extension defined in this document does not put new <t>The protocol extension defined in this document does not put new
requirements on other protocols or functional components.</t> requirements on other protocols or functional components.</t>
</section> </section>
<section anchor="Network-Operation" numbered="true" toc="default">
<section anchor="Network-Operation" <name>Impact on Network Operation</name>
title="Impact on Network Operation">
<t>The frequency of Link-State NLRI updates could interfere with <t>The frequency of Link-State NLRI updates could interfere with
regular BGP prefix distribution. A network operator should use a regular BGP prefix distribution. A network operator should use a
dedicated route reflector infrastructure to distribute Link-State dedicated route reflector infrastructure to distribute Link-State
NLRIs as discussed in <xref target="Operations"/>.</t> NLRIs as discussed in <xref target="Operations" format="default"/>.</t
>
<t>Distribution of Link-State NLRIs SHOULD be limited to a single <t>Distribution of Link-State NLRIs <bcp14>SHOULD</bcp14> be limited t
o a single
admin domain, which can consist of multiple areas within an AS or admin domain, which can consist of multiple areas within an AS or
multiple ASes.</t> multiple ASes.</t>
</section> </section>
<section anchor="Verifying-Correct-Operation" numbered="true" toc="defau
<section anchor="Verifying-Correct-Operation" lt">
title="Verifying Correct Operation"> <name>Verifying Correct Operation</name>
<t>Existing BGP procedures apply. In addition, an implementation <t>Existing BGP procedures apply. In addition, an implementation
SHOULD allow an operator to: <list style="symbols"> <bcp14>SHOULD</bcp14> allow an operator to: </t>
<t>List neighbors with whom the speaker is exchanging Link-State <ul spacing="normal">
NLRIs.</t> <li>List neighbors with whom the speaker is exchanging Link-State
</list></t> NLRIs.</li>
</ul>
</section> </section>
</section> </section>
<section anchor="Management-Considerations" numbered="true" toc="default">
<section anchor="Management-Considerations" <name>Management Considerations</name>
title="Management Considerations"> <section anchor="Management-Information" numbered="true" toc="default">
<section anchor="Management-Information" <name>Management Information</name>
title="Management Information"> <t>The IDR Working Group has documented and continues to document
<t>The IDR working group has documented and continues to document
parts of the Management Information Base and YANG models for parts of the Management Information Base and YANG models for
managing and monitoring BGP speakers and the sessions between them. managing and monitoring BGP Speakers and the sessions between them.
It is currently believed that the BGP session running BGP-LS is not It is currently believed that the BGP session running BGP-LS is not
substantially different from any other BGP session and can be substantially different from any other BGP session and can be
managed using the same data models.</t> managed using the same data models.</t>
</section> </section>
<section anchor="Fault-Management" numbered="true" toc="default">
<section anchor="Fault-Management" title="Fault Management"> <name>Fault Management</name>
<t>This section describes the fault management actions, as described <t>This section describes the fault management actions, as described
in <xref target="RFC7606"/>, that are to be performed for the in <xref target="RFC7606" format="default"/>, that are to be performed for the
handling of BGP UPDATE messages for BGP-LS.</t> handling of BGP UPDATE messages for BGP-LS.</t>
<t>A Link-State NLRI <bcp14>MUST NOT</bcp14> be considered malformed o
<t>A Link-State NLRI MUST NOT be considered malformed or invalid r invalid
based on the inclusion/exclusion of TLVs or contents of the TLV based on the inclusion/exclusion of TLVs or contents of the TLV
fields (i.e. semantic errors), as described in <xref fields (i.e., semantic errors), as described in Sections <xref target=
target="TLV-section"/> and <xref target="BGPLSNLRI"/>.</t> "TLV-section" format="counter"/> and <xref target="BGPLSNLRI" format="counter"/>
.</t>
<t>A BGP-LS Speaker MUST perform the following syntactic validation <t>A BGP-LS Speaker <bcp14>MUST</bcp14> perform the following syntacti
of the Link-State NLRI to determine if it is malformed.<list c validation
style="symbols"> of the Link-State NLRI to determine if it is malformed.</t>
<t>The sum of all TLVs lengths found in the BGP MP_REACH_NLRI <ul spacing="normal">
attribute corresponds to the BGP MP_REACH_NLRI length.</t> <li>The sum of all TLV lengths found in the BGP MP_REACH_NLRI
attribute corresponds to the BGP MP_REACH_NLRI length.</li>
<t>The sum of all TLVs lengths found in the BGP MP_UNREACH_NLRI <li>The sum of all TLV lengths found in the BGP MP_UNREACH_NLRI
attribute corresponds to the BGP MP_UNREACH_NLRI length.</t> attribute corresponds to the BGP MP_UNREACH_NLRI length.</li>
<li>The sum of all TLV lengths found in a Link-State NLRI
<t>The sum of all TLVs lengths found in a Link-State NLRI
corresponds to the Total NLRI Length field of all its corresponds to the Total NLRI Length field of all its
Descriptors.</t> descriptors.</li>
<li>The length of the TLVs and, when the TLV is recognized then,
<t>The length of the TLVs and, when the TLV is recognized then, the length of its sub-TLVs in the NLRI are valid.</li>
the length of its sub-TLVs in the NLRI is valid.</t> <li>The syntactic correctness of the NLRI fields has been verified a
s
<t>The syntactic correctness of the NLRI fields been verified as per <xref target="RFC7606" format="default"/>.</li>
per <xref target="RFC7606"/>.</t> <li>The rule regarding the ordering of TLVs has been followed as
described in <xref target="TLV-section" format="default"/>.</li>
<t>The rule regarding the ordering of TLVs been followed as <li>For NLRIs carrying either a Local or Remote Node Descriptor
described in <xref target="TLV-section"/>.</t>
<t>For NLRIs carrying either a Local or Remote Node Descriptor
TLV, there is not more than one instance of a sub-TLV TLV, there is not more than one instance of a sub-TLV
present.</t> present.</li>
</list></t> </ul>
<t>When the error that is determined allows for the router to skip <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 the malformed NLRI(s) and continue the processing of the rest of the
BGP UPDATE message (e.g. when the TLV ordering rule is violated), BGP UPDATE message (e.g., when the TLV ordering rule is violated),
then it MUST handle such malformed NLRIs as 'NLRI discard' (i.e., then it <bcp14>MUST</bcp14> handle such malformed NLRIs as 'NLRI disca
processing similar to what is described in section 5.4 of <xref rd' (i.e.,
target="RFC7606"/>). In other cases, where the error in the NLRI processing similar to what is described in <xref target="RFC7606" sect
ion="5.4" sectionFormat="of" format="default"/>). In other cases, where the erro
r in the NLRI
encoding results in the inability to process the BGP UPDATE message encoding results in the inability to process the BGP UPDATE message
(e.g. length related encoding errors), then the router SHOULD handle (e.g., length-related encoding errors), then the router <bcp14>SHOULD< /bcp14> handle
such malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI such malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI
besides BGP-LS are being advertised over the same session. besides BGP-LS are being advertised over the same session.
Alternately, the router MUST perform a 'session reset' when the Alternately, the router <bcp14>MUST</bcp14> perform a 'session reset' when the
session is only being used for BGP-LS or if 'AFI/SAFI disable' session is only being used for BGP-LS or if 'AFI/SAFI disable'
action is not possible.</t> action is not possible.</t>
<t>A BGP-LS Attribute <bcp14>MUST NOT</bcp14> be considered malformed
<t>A BGP-LS Attribute MUST NOT be considered malformed or invalid or invalid
based on the inclusion/exclusion of TLVs or contents of the TLV based on the inclusion/exclusion of TLVs or contents of the TLV
fields (i.e. semantic errors), as described in <xref fields (i.e., semantic errors), as described in Sections <xref target=
target="TLV-section"/> and <xref target="BGPLSATTR"/>.</t> "TLV-section" format="counter"/> and <xref target="BGPLSATTR" format="counter"/>
.</t>
<t>A BGP-LS Speaker MUST perform the following syntactic validation <t>A BGP-LS Speaker <bcp14>MUST</bcp14> perform the following syntacti
of the BGP-LS Attribute to determine if it is malformed.<list c validation
style="symbols"> of the BGP-LS Attribute to determine if it is malformed.</t>
<t>The sum of all TLVs lengths found in the BGP-LS Attribute <ul spacing="normal">
corresponds to the BGP-LS Attribute length.</t> <li>The sum of all TLV lengths found in the BGP-LS Attribute
corresponds to the BGP-LS Attribute length.</li>
<t>The syntactic correctness of the Attributes (including BGP-LS <li>The syntactic correctness of the Attributes (including the BGP-L
Attribute) been verified as per <xref target="RFC7606"/>.</t> S
Attribute) have been verified as per <xref target="RFC7606" format
<t>The length of each TLV and, when the TLV is recognized then, ="default"/>.</li>
the length of its sub-TLVs in the BGP-LS Attribute is valid.</t> <li>The length of each TLV and, when the TLV is recognized then,
</list></t> the length of its sub-TLVs in the BGP-LS Attribute are valid.</li>
</ul>
<t>When the error that is determined allows for the router to skip <t>When the error that is determined allows for the router to skip
the malformed BGP-LS Attribute and continue the processing of the the malformed BGP-LS Attribute and continue the processing of the
rest of the BGP UPDATE message (e.g. when the BGP-LS Attribute rest of the BGP UPDATE message (e.g., when the BGP-LS Attribute
length and the total Path Attribute Length are correct but some length and the total Path Attribute Length are correct but some
TLV/sub-TLV length within the BGP-LS Attribute is invalid), then it TLV/sub-TLV length within the BGP-LS Attribute is invalid), then it
MUST handle such malformed BGP-LS Attribute as 'Attribute Discard'. <bcp14>MUST</bcp14> handle such malformed BGP-LS Attribute as 'Attribu te Discard'.
In other cases, where the error in the BGP-LS Attribute encoding In other cases, where the error in the BGP-LS Attribute encoding
results in the inability to process the BGP UPDATE message then the results in the inability to process the BGP UPDATE message, the
handling is the same as described above for the malformed NLRI.</t> handling is the same as described above for the malformed NLRI.</t>
<t>Note that the 'Attribute Discard' action results in the loss of <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 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 malformed TLV. The removal of specific malformed TLVs may give a
wrong indication to a BGP-LS Consumer of that specific information wrong indication to a BGP-LS Consumer of that specific information
being deleted or not available.</t> being deleted or not available.</t>
<t>When a BGP Speaker receives an UPDATE message with Link-State <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 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 most likely an indication that a BGP Speaker preceding it has
performed the 'Attribute Discard' fault handling. An implementation performed the 'Attribute Discard' fault handling. An implementation
SHOULD preserve and propagate the Link-State NLRIs, unless denied by <bcp14>SHOULD</bcp14> preserve and propagate the Link-State NLRIs, unl ess denied by
local policy, in such an UPDATE message so that the BGP-LS Consumers 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 can detect the loss of link-state information for that object and
not assume its deletion/withdrawal. This also makes it possible for not assume its deletion/withdrawal. This also makes it possible for
a network operator to trace back to the BGP-LS Propagator that a network operator to trace back to the BGP-LS Propagator that
detected the fault with the BGP-LS Attribute.</t> detected the fault with the BGP-LS Attribute.</t>
<t>An implementation <bcp14>SHOULD</bcp14> log a message for any error
<t>An implementation SHOULD log a message for any errors found s found
during syntax validation for further analysis.</t> during syntax validation for further analysis.</t>
<t>A BGP-LS Propagator, even when it has a coexisting BGP-LS <t>A BGP-LS Propagator, even when it has a coexisting BGP-LS
Consumer on the same node, should not perform semantic validation of 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 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 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 to be performed by a BGP-LS Propagator are as follows (and this is
not to be considered as an exhaustive list):<list style="symbols"> not to be considered as an exhaustive list):</t>
<t>presence of mandatory TLV</t> <ul spacing="normal">
<li>presence of a mandatory TLV</li>
<t>the length of a fixed-length TLV correct or the length of a <li>the length of a fixed-length TLV is correct or the length of a
variable length TLV is valid or permissible</t> variable length TLV is valid or permissible</li>
<li>the values of TLV fields are valid or permissible</li>
<t>the values of TLV fields are valid or permissible</t> <li>the inclusion and use of TLVs/sub-TLVs with specific
Link-State NLRI types is valid</li>
<t>the inclusion and use of TLVs/sub-TLVs with specific </ul>
Link-State NLRI types is valid</t>
</list></t>
<t>Each TLV may indicate the valid and permissible values and their <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 semantics that can be used only by a BGP-LS Consumer for its
semantic validation. However, the handling of any errors may be semantic validation. However, the handling of any errors may be
specific to the particular application and outside the scope of this specific to the particular application and outside the scope of this
document.</t> document.</t>
</section> </section>
<section anchor="Configuration-Management" numbered="true" toc="default"
<section anchor="Configuration-Management" >
title="Configuration Management"> <name>Configuration Management</name>
<t>An implementation SHOULD allow the operator to specify neighbors <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to speci
fy neighbors
to which Link-State NLRIs will be advertised and from which to which Link-State NLRIs will be advertised and from which
Link-State NLRIs will be accepted.</t> Link-State NLRIs will be accepted.</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to speci
<t>An implementation SHOULD allow the operator to specify the fy the
maximum rate at which Link-State NLRIs will be advertised/withdrawn maximum rate at which Link-State NLRIs will be advertised/withdrawn
from neighbors.</t> from neighbors.</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to speci
<t>An implementation SHOULD allow the operator to specify the fy the
maximum number of Link-State NLRIs stored in a router's Routing maximum number of Link-State NLRIs stored in a router's Routing
Information Base (RIB).</t> Information Base (RIB).</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to creat
<t>An implementation SHOULD allow the operator to create abstracted e abstracted
topologies that are advertised to neighbors and create different topologies that are advertised to neighbors and create different
abstractions for different neighbors.</t> abstractions for different neighbors.</t>
<t>An implementation <bcp14>MUST</bcp14> allow the operator to configu
<t>An implementation MUST allow the operator to configure an 8-octet re an 8-octet
BGP-LS Instance-ID. Refer to <xref target="BGPLSNLRI"/> for guidance BGP-LS Instance-ID. Refer to <xref target="BGPLSNLRI" format="default"
/> for guidance
to the operator for the configuration of BGP-LS Instance-ID.</t> to the operator for the configuration of BGP-LS Instance-ID.</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to confi
<t>An implementation SHOULD allow the operator to configure ASN and gure Autonomous System Number (ASN) and
BGP-LS identifiers (refer to <xref target="node_desc_tlvs"/>).</t> BGP-LS identifiers (refer to <xref target="node_desc_tlvs" format="def
ault"/>).</t>
<t>An implementation SHOULD allow the operator to configure limiting <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to confi
of maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS gure limiting
Producer or to allow larger values when they know that <xref the maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS
target="RFC8654"/> is supported on all BGP-LS Speakers.</t> Producer or to allow larger values when they know that <xref target="R
FC8654" format="default"/> is supported on all BGP-LS Speakers.</t>
</section> </section>
<section anchor="Accounting-Management" numbered="true" toc="default">
<section anchor="Accounting-Management" title="Accounting Management"> <name>Accounting Management</name>
<t>Not Applicable.</t> <t>Not Applicable.</t>
</section> </section>
<section anchor="Performance-Management" numbered="true" toc="default">
<section anchor="Performance-Management" <name>Performance Management</name>
title="Performance Management"> <t>An implementation <bcp14>SHOULD</bcp14> provide the following stati
<t>An implementation SHOULD provide the following statistics: <list stics: </t>
style="symbols"> <ul spacing="normal">
<t>Total number of Link-State NLRI updates sent/received</t> <li>Total number of Link-State NLRI updates sent/received</li>
<li>Number of Link-State NLRI updates sent/received, per
<t>Number of Link-State NLRI updates sent/received, per neighbor</li>
neighbor</t> <li>Number of errored received Link-State NLRI updates, per
neighbor</li>
<t>Number of errored received Link-State NLRI updates, per <li>Total number of locally originated Link-State NLRIs</li>
neighbor</t> </ul>
<t>Total number of locally originated Link-State NLRIs</t>
</list></t>
<t>These statistics should be recorded as absolute counts since the <t>These statistics should be recorded as absolute counts since the
system or session start time. An implementation MAY also enhance system or session start time. An implementation <bcp14>MAY</bcp14> als o enhance
this information by recording peak per-second counts in each this information by recording peak per-second counts in each
case.</t> case.</t>
</section> </section>
<section anchor="Security-Management" numbered="true" toc="default">
<section anchor="Security-Management" title="Security Management"> <name>Security Management</name>
<t>An operator MUST define an import policy to limit inbound updates <t>An operator <bcp14>MUST</bcp14> define an import policy to limit in
as follows: <list style="symbols"> bound updates
<t>Drop all updates from peers that are only serving BGP-LS as follows: </t>
Consumers.</t> <ul spacing="normal">
</list></t> <li>Drop all updates from peers that are only serving BGP-LS
Consumers.</li>
<t>An implementation MUST have the means to limit inbound </ul>
<t>An implementation <bcp14>MUST</bcp14> have the means to limit inbou
nd
updates.</t> updates.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="TLVSUMMARY" numbered="true" toc="default">
<section anchor="TLVSUMMARY" title="TLV/Sub-TLV Code Points Summary"> <name>TLV/Sub-TLV Code Points Summary</name>
<t>This section contains the global table of all TLVs/sub-TLVs defined <t>This section contains the global table of all TLVs/sub-TLVs defined
in this document.</t> in this document.</t>
<table anchor="BGPLSCODEPOINTS" align="center">
<texttable anchor="BGPLSCODEPOINTS" <name>Summary Table of TLV/Sub-TLV Code Points</name>
title="Summary Table of TLV/Sub-TLV Code Points"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="left">Reference Section</th>
<ttcol align="left">Reference Section</ttcol> </tr>
</thead>
<c>256</c> <tbody>
<tr>
<c>Local Node Descriptors</c> <td align="center">256</td>
<td align="left">Local Node Descriptors</td>
<c><xref target="LOCALNODEDESC"/></c> <td align="left">
<xref target="LOCALNODEDESC" format="default"/></td>
<c>257</c> </tr>
<tr>
<c>Remote Node Descriptors</c> <td align="center">257</td>
<td align="left">Remote Node Descriptors</td>
<c><xref target="REMOTENODEDESC"/></c> <td align="left">
<xref target="REMOTENODEDESC" format="default"/></td>
<c>258</c> </tr>
<tr>
<c>Link Local/Remote Identifiers</c> <td align="center">258</td>
<td align="left">Link Local/Remote Identifiers</td>
<c><xref target="LINKDESC"/></c> <td align="left">
<xref target="LINKDESC" format="default"/></td>
<c>259</c> </tr>
<tr>
<c>IPv4 interface address</c> <td align="center">259</td>
<td align="left">IPv4 interface address</td>
<c><xref target="LINKDESC"/></c> <td align="left">
<xref target="LINKDESC" format="default"/></td>
<c>260</c> </tr>
<tr>
<c>IPv4 neighbor address</c> <td align="center">260</td>
<td align="left">IPv4 neighbor address</td>
<c><xref target="LINKDESC"/></c> <td align="left">
<xref target="LINKDESC" format="default"/></td>
<c>261</c> </tr>
<tr>
<c>IPv6 interface address</c> <td align="center">261</td>
<td align="left">IPv6 interface address</td>
<c><xref target="LINKDESC"/></c> <td align="left">
<xref target="LINKDESC" format="default"/></td>
<c>262</c> </tr>
<tr>
<c>IPv6 neighbor address</c> <td align="center">262</td>
<td align="left">IPv6 neighbor address</td>
<c><xref target="LINKDESC"/></c> <td align="left">
<xref target="LINKDESC" format="default"/></td>
<c>263</c> </tr>
<tr>
<c>Multi-Topology ID</c> <td align="center">263</td>
<td align="left">Multi-Topology Identifier</td>
<c><xref target="MT-ID"/></c> <td align="left">
<xref target="MT-ID" format="default"/></td>
<c>264</c> </tr>
<tr>
<c>OSPF Route Type</c> <td align="center">264</td>
<td align="left">OSPF Route Type</td>
<c><xref target="PREFIXDESC"/></c> <td align="left">
<xref target="OSPFRTETYPE" format="default"/></td>
<c>265</c> </tr>
<tr>
<c>IP Reachability Information</c> <td align="center">265</td>
<td align="left">IP Reachability Information</td>
<c><xref target="PREFIXDESC"/></c> <td align="left">
<xref target="IPREACHINFO" format="default"/></td>
<c>512</c> </tr>
<tr>
<c>Autonomous System</c> <td align="center">512</td>
<td align="left">Autonomous System</td>
<c><xref target="node_desc_tlvs"/></c> <td align="left">
<xref target="node_desc_tlvs" format="default"/></td>
<c>513</c> </tr>
<tr>
<c>BGP-LS Identifier (deprecated)</c> <td align="center">513</td>
<td align="left">BGP-LS Identifier (deprecated)</td>
<c><xref target="node_desc_tlvs"/></c> <td align="left">
<xref target="node_desc_tlvs" format="default"/></td>
<c>514</c> </tr>
<tr>
<c>OSPF Area-ID</c> <td align="center">514</td>
<td align="left">OSPF Area-ID</td>
<c><xref target="node_desc_tlvs"/></c> <td align="left">
<xref target="node_desc_tlvs" format="default"/></td>
<c>515</c> </tr>
<tr>
<c>IGP Router-ID</c> <td align="center">515</td>
<td align="left">IGP Router-ID</td>
<c><xref target="node_desc_tlvs"/></c> <td align="left">
<xref target="node_desc_tlvs" format="default"/></td>
<c>1024</c> </tr>
<tr>
<c>Node Flag Bits</c> <td align="center">1024</td>
<td align="left">Node Flag Bits</td>
<c><xref target="NODEFLAGBITS"/></c> <td align="left">
<xref target="NODEFLAGBITS" format="default"/></td>
<c>1025</c> </tr>
<tr>
<c>Opaque Node Attribute</c> <td align="center">1025</td>
<td align="left">Opaque Node Attribute</td>
<c><xref target="OPAQUENODE"/></c> <td align="left">
<xref target="OPAQUENODE" format="default"/></td>
<c>1026</c> </tr>
<tr>
<c>Node Name</c> <td align="center">1026</td>
<td align="left">Node Name</td>
<c><xref target="NODENAME"/></c> <td align="left">
<xref target="NODENAME" format="default"/></td>
<c>1027</c> </tr>
<tr>
<c>IS-IS Area Identifier</c> <td align="center">1027</td>
<td align="left">IS-IS Area Identifier</td>
<c><xref target="ISISAREA"/></c> <td align="left">
<xref target="ISISAREA" format="default"/></td>
<c>1028</c> </tr>
<tr>
<c>IPv4 Router-ID of Local Node</c> <td align="center">1028</td>
<td align="left">IPv4 Router-ID of Local Node</td>
<c><xref target="aux_routerid_node"/> / <xref <td align="left">Sections
target="aux_routerid_link"/></c> <xref target="aux_routerid_node" format="counter"/> and <xref targ
et="aux_routerid_link" format="counter"/></td>
<c>1029</c> </tr>
<tr>
<c>IPv6 Router-ID of Local Node</c> <td align="center">1029</td>
<td align="left">IPv6 Router-ID of Local Node</td>
<c><xref target="aux_routerid_node"/> / <xref <td align="left">Sections
target="aux_routerid_link"/></c> <xref target="aux_routerid_node" format="counter"/> and <xref targ
et="aux_routerid_link" format="counter"/></td>
<c>1030</c> </tr>
<tr>
<c>IPv4 Router-ID of Remote Node</c> <td align="center">1030</td>
<td align="left">IPv4 Router-ID of Remote Node</td>
<c><xref target="aux_routerid_link"/></c> <td align="left">
<xref target="aux_routerid_link" format="default"/></td>
<c>1031</c> </tr>
<tr>
<c>IPv6 Router-ID of Remote Node</c> <td align="center">1031</td>
<td align="left">IPv6 Router-ID of Remote Node</td>
<c><xref target="aux_routerid_link"/></c> <td align="left">
<xref target="aux_routerid_link" format="default"/></td>
<c>1088</c> </tr>
<tr>
<c>Administrative group (color)</c> <td align="center">1088</td>
<td align="left">Administrative group (color)</td>
<c><xref target="link_attribute"/></c> <td align="left">
<xref target="link_attribute" format="default"/></td>
<c>1089</c> </tr>
<tr>
<c>Maximum link bandwidth</c> <td align="center">1089</td>
<td align="left">Maximum link bandwidth</td>
<c><xref target="link_attribute"/></c> <td align="left">
<xref target="link_attribute" format="default"/></td>
<c>1090</c> </tr>
<tr>
<c>Max. reservable link bandwidth</c> <td align="center">1090</td>
<td align="left">Max. reservable link bandwidth</td>
<c><xref target="link_attribute"/></c> <td align="left">
<xref target="link_attribute" format="default"/></td>
<c>1091</c> </tr>
<tr>
<c>Unreserved bandwidth</c> <td align="center">1091</td>
<td align="left">Unreserved bandwidth</td>
<c><xref target="link_attribute"/></c> <td align="left">
<xref target="link_attribute" format="default"/></td>
<c>1092</c> </tr>
<tr>
<c>TE Default Metric</c> <td align="center">1092</td>
<td align="left">TE Default Metric</td>
<c><xref target="TEDEFAULTMETTLV"/></c> <td align="left">
<xref target="TEDEFAULTMETTLV" format="default"/></td>
<c>1093</c> </tr>
<tr>
<c>Link Protection Type</c> <td align="center">1093</td>
<td align="left">Link Protection Type</td>
<c><xref target="link_attribute"/></c> <td align="left">
<xref target="link_attribute" format="default"/></td>
<c>1094</c> </tr>
<tr>
<c>MPLS Protocol Mask</c> <td align="center">1094</td>
<td align="left">MPLS Protocol Mask</td>
<c><xref target="MPLSPROTOTLV"/></c> <td align="left">
<xref target="MPLSPROTOTLV" format="default"/></td>
<c>1095</c> </tr>
<tr>
<c>IGP Metric</c> <td align="center">1095</td>
<td align="left">IGP Metric</td>
<c><xref target="IGPMETTLV"/></c> <td align="left">
<xref target="IGPMETTLV" format="default"/></td>
<c>1096</c> </tr>
<tr>
<c>Shared Risk Link Group</c> <td align="center">1096</td>
<td align="left">Shared Risk Link Group</td>
<c><xref target="SRLGTLV"/></c> <td align="left">
<xref target="SRLGTLV" format="default"/></td>
<c>1097</c> </tr>
<tr>
<c>Opaque Link Attribute</c> <td align="center">1097</td>
<td align="left">Opaque Link Attribute</td>
<c><xref target="OPAQUELINK"/></c> <td align="left">
<xref target="OPAQUELINK" format="default"/></td>
<c>1098</c> </tr>
<tr>
<c>Link Name</c> <td align="center">1098</td>
<td align="left">Link Name</td>
<c><xref target="LINKNAME"/></c> <td align="left">
<xref target="LINKNAME" format="default"/></td>
<c>1152</c> </tr>
<tr>
<c>IGP Flags</c> <td align="center">1152</td>
<td align="left">IGP Flags</td>
<c><xref target="IGPFLAGS"/></c> <td align="left">
<xref target="IGPFLAGS" format="default"/></td>
<c>1153</c> </tr>
<tr>
<c>IGP Route Tag</c> <td align="center">1153</td>
<td align="left">IGP Route Tag</td>
<c><xref target="route_tag"/></c> <td align="left">
<xref target="route_tag" format="default"/></td>
<c>1154</c> </tr>
<tr>
<c>IGP Extended Route Tag</c> <td align="center">1154</td>
<td align="left">IGP Extended Route Tag</td>
<c><xref target="ext_route_tag"/></c> <td align="left">
<xref target="ext_route_tag" format="default"/></td>
<c>1155</c> </tr>
<tr>
<c>Prefix Metric</c> <td align="center">1155</td>
<td align="left">Prefix Metric</td>
<c><xref target="prefix_metric"/></c> <td align="left">
<xref target="prefix_metric" format="default"/></td>
<c>1156</c> </tr>
<tr>
<c>OSPF Forwarding Address</c> <td align="center">1156</td>
<td align="left">OSPF Forwarding Address</td>
<c><xref target="ospf_fwd_addr"/></c> <td align="left">
<xref target="ospf_fwd_addr" format="default"/></td>
<c>1157</c> </tr>
<tr>
<c>Opaque Prefix Attribute</c> <td align="center">1157</td>
<td align="left">Opaque Prefix Attribute</td>
<c><xref target="OPAQUEPREFIX"/></c> <td align="left">
</texttable> <xref target="OPAQUEPREFIX" format="default"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>Procedures and protocol extensions defined in this document do not <t>Procedures and protocol extensions defined in this document do not
affect the BGP security model. See the Security Considerations section affect the BGP security model. See the Security Considerations section
of <xref target="RFC4271"/> for a discussion of BGP security. Also, of <xref target="RFC4271" format="default"/> for a discussion of BGP secur
refer to <xref target="RFC4272"/> and <xref target="RFC6952"/> for ity. Also,
refer to <xref target="RFC4272" format="default"/> and <xref target="RFC69
52" format="default"/> for
analysis of security issues for BGP.</t> analysis of security issues for BGP.</t>
<t>The operator should ensure that a BGP-LS Speaker does not accept
<t>The operator should ensure that a BGP-LS speaker does not accept
UPDATE messages from a peer that only provides information to a BGP-LS UPDATE messages from a peer that only provides information to a BGP-LS
Consumer by using the policy configuration options discussed in <xref Consumer by using the policy configuration options discussed in Sections <
target="Configuration-Management"/> and <xref xref target="Configuration-Management" format="counter"/> and <xref target="Secu
target="Security-Management"/>. Generally, an operator is aware of the rity-Management" format="counter"/>. Generally, an operator is aware of the
BGP-LS speaker's role and link-state peerings. Therefore, the operator BGP-LS Speaker's role and link-state peerings. Therefore, the operator
can protect the BGP-LS speaker from peers sending updates that may can protect the BGP-LS Speaker from peers sending updates that may
represent erroneous information, feedback loops, or false input.</t> represent erroneous information, feedback loops, or false input.</t>
<t>An error or tampering of the link-state information that is <t>An error or tampering of the link-state information that is
originated into BGP-LS and propagated through the network for use by originated into BGP-LS and propagated through the network for use by
BGP-LS Consumers applications can result in the malfunction of those BGP-LS Consumers applications can result in the malfunction of those
applications. Some examples of such risks are the origination of applications. Some examples of such risks are the origination of
incorrect information that is not present or consistent with the IGP incorrect information that is not present or consistent with the IGP
LSDB at the BGP-LS Producer, incorrect ordering of TLVs in the NLRI or LSDB at the BGP-LS Producer, incorrect ordering of TLVs in the NLRI, or
inconsistent origination from multiple BGP-LS Producers and updates to inconsistent origination from multiple BGP-LS Producers and updates to
either the NLRI or BGP-LS Attribute during propagation (including either the NLRI or BGP-LS Attribute during propagation (including
discarding due to errors). These are not new risks from a BGP protocol discarding due to errors). These are not new risks from a BGP protocol
perspective, however, in the case of BGP-LS impact reflects on the perspective; however, in the case of BGP-LS, impact reflects on the
consumer applications instead of BGP routing functionalities.</t> consumer applications instead of BGP routing functionalities.</t>
<t>Additionally, it may be considered that the export of link-state and <t>Additionally, it may be considered that the export of link-state and
TE information as described in this document constitutes a risk to TE information as described in this document constitutes a risk to
confidentiality of mission-critical or commercially sensitive confidentiality of mission-critical or commercially sensitive
information about the network. BGP peerings are not automatic and information about the network. BGP peerings are not automatic and
require configuration; thus, it is the responsibility of the network require configuration; thus, it is the responsibility of the network
operator to ensure that only trusted BGP Speakers are configured to operator to ensure that only trusted BGP Speakers are configured to
receive such information. Similar security considerations also arise on receive such information. Similar security considerations also arise on
the interface between BGP Speaker and BGP-LS Consumers, but their the interface between BGP Speakers and BGP-LS Consumers, but their
discussion is outside the scope of this document.</t> discussion is outside the scope of this document.</t>
</section> </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> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119.xml"?> <name>References</name>
<references>
<?rfc include="reference.RFC.2328.xml"?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.2545.xml"?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.3209.xml"?> 328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.4202.xml"?> 545.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<?rfc include="reference.RFC.4203.xml"?> 209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="reference.RFC.4271.xml"?> 202.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="reference.RFC.4760.xml"?> 203.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="reference.RFC.4915.xml"?> 271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="reference.RFC.5036.xml"?> 760.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="reference.RFC.5120.xml"?> 915.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.5130.xml"?> 036.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.5301.xml"?> 120.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.5642.xml"?> 130.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.8126.xml"?> 301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.5305.xml"?> 642.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.5307.xml"?> 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.5340.xml"?> 305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.5890.xml"?> 307.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.6119.xml"?> 340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.7606.xml"?> 890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include="reference.RFC.8174.xml"?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.8654.xml'?> 606.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.4577.xml'?> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.6565.xml'?> 654.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include='reference.RFC.7684.xml'?> 577.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.8362.xml'?> 565.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="reference.RFC.7770.xml"?> 684.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<reference anchor="ISO10589"> 362.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<title>Intermediate System to Intermediate System intra-domain 770.xml"/>
<reference anchor="ISO10589">
<front>
<title>Information technology - Telecommunications and
information exchange between systems -
Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in conjunction with routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network service the protocol for providing the connectionless-mode network service
(ISO 8473)</title> (ISO 8473)</title>
<author>
<author> <organization>ISO</organization>
<organization>International Organization for </author>
Standardization</organization> <date month="November" year="2002"/>
</author> </front>
<seriesInfo name="ISO/IEC" value="10589:2002"/>
<date month="November" year="2002"/> </reference>
</front> <reference anchor="ENTNUM" target="https://www.iana.org/assignments/ente
rprise-numbers/">
<seriesInfo name="ISO/IEC" value="10589"/> <front>
</reference> <title>Private Enterprise Numbers (PENs)</title>
<author>
<reference anchor="ENTNUM" <organization>IANA</organization>
target="https://www.iana.org/assignments/enterprise-numbers/"> </author>
<front> </front>
<title>Private Enterprise Numbers</title> </reference>
</references>
<author> <references>
<organization>IANA</organization> <name>Informative References</name>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
918.xml"/>
<date year=""/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 272.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</references> 364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<references title="Informative References"> 655.xml"/>
<?rfc include="reference.RFC.1918.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
152.xml"/>
<?rfc include="reference.RFC.4272.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
346.xml"/>
<?rfc include="reference.RFC.4364.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
392.xml"/>
<?rfc include="reference.RFC.4655.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
693.xml"/>
<?rfc include="reference.RFC.5152.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
706.xml"/>
<?rfc include="reference.RFC.9346.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
549.xml"/>
<?rfc include="reference.RFC.5392.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
952.xml"/>
<?rfc include="reference.RFC.5693.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
285.xml"/>
<?rfc include="reference.RFC.5706.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
752.xml"/>
<?rfc include="reference.RFC.6549.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
911.xml"/>
<?rfc include="reference.RFC.6952.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
202.xml"/>
<?rfc include="reference.RFC.7285.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
029.xml"/>
<?rfc include="reference.RFC.7752.xml"?> </references>
<?rfc include="reference.RFC.7911.xml"?>
<?rfc include="reference.RFC.8202.xml"?>
<?rfc include='reference.RFC.9029.xml'?>
</references> </references>
<section anchor="CHANGES" numbered="true" toc="default">
<section anchor="CHANGES" title="Changes from RFC 7752"> <name>Changes from RFC 7752</name>
<t>This section lists the high-level changes from RFC 7752 and provides <t>This section lists the high-level changes from RFC 7752 and provides
reference to the document sections wherein those have been reference to the document sections wherein those have been
introduced.</t> introduced.</t>
<ol spacing="normal" type="1"><li>Updated <xref target="MECHANISM-OVERVIEW
<t><list style="numbers"> " format="default"/> in <xref target="INTRO" format="default"/> and added <xref
<t>Updated the <xref target="MECHANISM-OVERVIEW"/> in <xref target="ROLES" format="default"/> to illustrate the
target="INTRO"/> and added <xref target="ROLES"/> to illustrate the
different roles of a BGP implementation in conveying link-state different roles of a BGP implementation in conveying link-state
information.</t> information.</li>
<li>Clarified aspects related to advertisement of link-state
<t>Clarified aspects related to advertisement of link-state information from IGPs into BGP-LS in <xref target="IGPTOBGP" format="d
information from IGPs into BGP-LS in <xref target="IGPTOBGP"/>.</t> efault"/>.</li>
<li>In <xref target="TLV-section" format="default"/>, clarified aspects
<t>In <xref target="TLV-section"/>, clarification about the TLV about TLV
handling aspects that apply to both the NLRI and BGP-LS Attribute handling that apply to both the NLRI and BGP-LS Attribute
parts and those that are applicable only for the NLRI portion. An parts as well as those that are applicable only for the NLRI portion.
implementation may have missed the part about the handling of An
unknown TLV and so, based on <xref target="RFC7606"/> guidelines, implementation may have missed the part about the handling of an
unknown TLV and so, based on <xref target="RFC7606" format="default"/>
guidelines,
might discard the unknown NLRI types. This aspect is now might discard the unknown NLRI types. This aspect is now
unambiguously clarified in <xref target="BGPLSNLRI"/>. Also, the unambiguously clarified in <xref target="BGPLSNLRI" format="default"/> . Also, the
TLVs in the BGP-LS Attribute that are not ordered are not to be TLVs in the BGP-LS Attribute that are not ordered are not to be
considered malformed.</t> considered malformed.</li>
<li>Clarified aspects of mandatory and optional TLVs in both NLRI and
<t>Clarification of mandatory and optional TLVs in both NLRI and BGP-LS Attribute portions all through the document.</li>
BGP-LS Attribute portions all through the document.</t> <li>In <xref target="BGPLSATTR" format="default"/>, the handling of a la
rge-sized BGP-LS Attribute with growth in BGP-LS
<t>Handling of large size of BGP-LS Attribute with growth in BGP-LS information is explained along with
information is explained in <xref target="BGPLSATTR"/> along with mitigation of errors arising out of it.</li>
mitigation of errors arising out of it.</t> <li>Clarified that the document describes the NLRI descriptor TLVs
for the protocols and NLRI types specified in this document as well as
<t>Clarified that the document describes the NLRI descriptor TLVs
for the protocols and NLRI types specified in this document and
future BGP-LS extensions must describe the same for other protocols future BGP-LS extensions must describe the same for other protocols
and NLRI types that they introduce.</t> and NLRI types that they introduce.</li>
<li>In <xref target="BGPLSNLRI" format="default"/>, clarified the use of
<t>Clarification on the use of the Identifier field in the the Identifier field in the
Link-State NLRI in <xref target="BGPLSNLRI"/> is provided. It was Link-State NLRI. It was
defined ambiguously to refer to only multi-instance IGP on a single defined ambiguously to refer to only multi-instance IGP on a single
link while it can also be used for multiple IGP protocol instances link while it can also be used for multiple IGP protocol instances
on a router. The IANA registry is accordingly being removed.</t> on a router. The IANA registry is accordingly being removed.</li>
<li>The BGP-LS Identifier TLV in the Node Descriptors has been
<t>The BGP-LS Identifier TLV in the Node Descriptors has been deprecated. Its use was not well specified by <xref target="RFC7752" f
deprecated. Its use was not well specified by <xref ormat="default"/>, and there has been some amount of confusion
target="RFC7752"/> and there has been some amount of confusion between implementors on its usage for identification of IGP
between implementators on its usage for identification of IGP
domains as against the use of the Identifier field carrying the domains as against the use of the Identifier field carrying the
BGP-LS Instance-ID when running multiple instances of IGP routing BGP-LS Instance-ID when running multiple instances of IGP routing
protocols. The original purpose of the BGP-LS Identifier was that, protocols. The original purpose of the BGP-LS Identifier was that,
in conjunction with Autonomous System Number (ASN), it would in conjunction with the ASN, it would
uniquely identify the BGP-LS domain and that the combination of ASN uniquely identify the BGP-LS domain and that the combination of ASN
and BGP-LS ID would be globally unique. However, the BGP-LS 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 Instance-ID carried in the Identifier field in the fixed part of the
NLRI also provides a similar functionality. Hence, the inclusion of NLRI also provides a similar functionality. Hence, the inclusion of
the BGP-LS Identifier TLV is not necessary. If advertised, all the BGP-LS Identifier TLV is not necessary. If advertised, all
BGP-LS speakers within an IGP flooding-set (set of IGP nodes within BGP-LS Speakers within an IGP flooding-set (set of IGP nodes within
which an LSP/LSA is flooded) had to use the same (ASN, BGP-LS ID) which an LSP/LSA is flooded) had to use the same (ASN, BGP-LS ID)
tuple and if an IGP domain consists of multiple flooding-sets, then tuple, and if an IGP domain consists of multiple flooding-sets, then
all BGP-LS speakers within the IGP domain had to use the same (ASN, all BGP-LS Speakers within the IGP domain had to use the same (ASN,
BGP-LS ID) tuple.</t> BGP-LS ID) tuple.</li>
<li>Clarified that the Area-ID TLV is mandatory in the Node
<t>Clarification that the Area-ID TLV is mandatory in the Node
Descriptor for the origination of information from OSPF except for Descriptor for the origination of information from OSPF except for
when sourcing information from AS-scope LSAs where this TLV is not when sourcing information from AS-scope LSAs where this TLV is not
applicable. Also clarified on the IS-IS area and area addresses.</t> applicable. Also clarified the IS-IS area and area addresses.</li>
<li>Moved the MT-ID TLV from the Node Descriptor section to under the
<t>Moved MT-ID TLV from the Node Descriptor section to under the
Link Descriptor section since it is not a Node Descriptor sub-TLV. 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. Fixed the ambiguity in the encoding of OSPF MT-ID in this TLV.
Updated the IS-IS specification reference section and describe the Updated the IS-IS specification reference section and described the
differences in the applicability of the R flags when MT-ID TLV is differences in the applicability of the R flags when the MT-ID TLV is
used as link descriptor TLV and Prefix Attribute TLV. MT-ID TLV use used as the Link Descriptor TLV and Prefix Attribute TLV. The MT-ID TL
is now elevated to SHOULD when it is enabled in the underlying V use
IGP.</t> is now elevated to <bcp14>SHOULD</bcp14> when it is enabled in the und
erlying
<t>Clarified that IPv6 Link-Local Addresses are not advertised in IGP.</li>
<li>Clarified that IPv6 link-local addresses are not advertised in
the Link Descriptor TLVs and the local/remote identifiers are to be the Link Descriptor TLVs and the local/remote identifiers are to be
used instead for links with IPv6 link-local addresses only.</t> used instead for links with IPv6 link-local addresses only.</li>
<li>Updated the usage of OSPF Route Type TLV to mandate its use for
<t>Update the usage of OSPF Route Type TLV to mandate its use for OSPF prefixes in <xref target="OSPFRTETYPE" format="default"/> since t
OSPF prefixes in <xref target="OSPFRTETYPE"/> since this is required his is required
for segregation of intra-area prefixes that are used to reach a node for segregation of intra-area prefixes that are used to reach a node
(e.g. a loopback) from other types of inter-area and external (e.g., a loopback) from other types of inter-area and external
prefixes.</t> prefixes.</li>
<li>Clarified the specific OSPFv2 and OSPFv3 protocol TLV
<t>Clarification of the specific OSPFv2 and OSPFv3 protocol TLV space to be used in the Node, Link, and Prefix Opaque Attribute
space to be used in the node, link, and prefix opaque attribute TLVs.</li>
TLVs.</t> <li>Clarified that the length of the Node Flag Bits and IGP Flags
TLVs are to be one octet.</li>
<t>Clarification on the length of the Node Flag Bits and IGP Flags <li>Updated the Node Name TLV in <xref target="NODENAME" format="default
TLVs to be one octet.</t> "/> with the
OSPF specification.</li>
<t>Updated the Node Name TLV in <xref target="NODENAME"/> with the <li>Clarified the size of the IS-IS Narrow Metric
OSPF specification.</t>
<t>Clarification on the size of the IS-IS Narrow Metric
advertisement via the IGP Metric TLV and the handling of the unused advertisement via the IGP Metric TLV and the handling of the unused
bits.</t> bits.</li>
<li>Clarified the advertisement of the prefix corresponding to the
<t>Clarified the advertisement of the prefix corresponding to the LAN segment in an OSPF network in <xref target="OSPFPN" format="defaul
LAN segment in an OSPF network in <xref target="OSPFPN"/>.</t> t"/>.</li>
<li>Clarified the advertisement and support for OSPF-specific
<t>Clarified the advertisement and support for OSPF specific concepts like virtual links, sham links, and Type 4 LSAs in Sections <
concepts like Virtual links, Sham links, and Type 4 LSAs in <xref xref target="OSPFVL" format="counter"/> and <xref target="OSPFTYPE4" format="cou
target="OSPFVL"/> and <xref target="OSPFTYPE4"/>.</t> nter"/>.</li>
<li>Introduced the Private Use TLV code point space and specified their
<t>Introduced Private Use TLV code point space and specified their encoding in <xref target="PRIVATE" format="default"/>.</li>
encoding in <xref target="PRIVATE"/>.</t> <li>In <xref target="UNREACHNODES" format="default"/>, introduced where
issues related to
<t>Introduced <xref target="UNREACHNODES"/> where issues related to
the consistency of reporting IGP link-state along with their the consistency of reporting IGP link-state along with their
solutions are covered.</t> solutions are covered.</li>
<li>Added a recommendation for isolation of BGP-LS sessions from other
<t>Added recommendation for isolation of BGP-LS sessions from other BGP route exchanges to avoid errors and faults in BGP-LS affecting
BGP route exchange to avoid errors and faults in BGP-LS affecting the normal BGP routing.</li>
the normal BGP routing.</t> <li>Updated the Fault Management section with detailed rules based on
<t>Updated the Fault Management section with detailed rules based on
the role of the BGP Speaker in the BGP-LS information propagation the role of the BGP Speaker in the BGP-LS information propagation
flow.</t> flow.</li>
<li>Changed the management of BGP-LS IANA registries from
<t>Change to the management of BGP-LS IANA registries from
"Specification Required" to "Expert Review" along with updated "Specification Required" to "Expert Review" along with updated
guidelines for Designated Experts. More specifically the inclusion guidelines for designated experts, more specifically, the inclusion
of changes introduced via <xref target="RFC9029"/> that is obsoleted of changes introduced via <xref target="RFC9029" format="default"/> th
by this document.</t> at are obsoleted
by this document.</li>
<t>Added BGP-LS IANA registries with "Expert Review" policy for the <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 flag fields of various TLVs that was missed out. Renamed the BGP-LS
TLV registry and removed the "IS-IS TLV/Sub-TLV" column from it.</t> TLV registry and removed the "IS-IS TLV/Sub-TLV" column from it.</li>
</list></t> </ol>
</section>
<t/> <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"/>, <conta
ct fullname="Srihari Sangli"/>, <contact fullname="Shraddha Hegde"/>,
<contact fullname="Andrew Stone"/>, <contact fullname="Jeff Tantsura"/>, <
contact fullname="Acee Lindem"/>, <contact fullname="Les Ginsberg"/>, <contact f
ullname="Jie Dong"/>,
<contact fullname="Aijun Wang"/>, <contact fullname="Nandan Saha"/>, <cont
act fullname="Joel Halpern"/>, and <contact fullname="Gyan Mishra"/> for their r
eview
and feedback on this document. Thanks to <contact fullname="Tom Petch"/> f
or 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 in
put for improving
the document.</t>
<t>The detailed AD review by <contact fullname="Alvaro Retana"/> and his s
uggestions 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 fu
llname="Alia Atlas"/>, <contact fullname="David Ward"/>, <contact fullname="Dere
k 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 fu
llname="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"/>, <co
ntact 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 th
eir
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="RFC
7752"/> 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> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 462 change blocks. 
2463 lines changed or deleted 2449 lines changed or added

This html diff was produced by rfcdiff 1.48.