Distribution of
Link-State and Traffic Engineering Information Using BGPCisco SystemsIndiaketant.ietf@gmail.com
Routing
Inter-Domain RoutingIn many environments, a component external to a network is called
upon to perform computations based on the network topology and the
current state of the connections within the network, including Traffic
Engineering (TE) information. This is information typically distributed
by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE
information can be collected from networks and shared with external
components using the BGP routing protocol. This is achieved using a BGP
Network Layer Reachability Information (NLRI) encoding format. The
mechanism applies to physical and virtual (e.g., tunnel) IGP links. The
mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic
Optimization (ALTO) servers and Path Computation Elements (PCEs).This document obsoletes RFC7752 by completely replacing that
document. It makes some small changes and clarifications to the previous
specification. This document also obsoletes RFC9029 by incorporating the
updates that it made to RFC7752.The contents of a Link-State Database (LSDB) or of an IGP's Traffic
Engineering Database (TED) describe only the links and nodes within an
IGP area. Some applications, such as end-to-end Traffic Engineering
(TE), would benefit from visibility outside one area or Autonomous
System (AS) to make better decisions.The IETF has defined the Path Computation Element (PCE) as a mechanism for achieving the computation of
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
also defined the ALTO server as an entity that
generates an abstracted network topology and provides it to
network-aware applications.Both a PCE and an ALTO server need to gather information about the
topologies and capabilities of the network to be able to fulfill their
function.This document describes a mechanism by which link-state and TE
information can be collected from networks and shared with external
components using the BGP routing protocol . This
is achieved using a BGP Network Layer Reachability Information (NLRI)
encoding format. The mechanism applies to physical and virtual (e.g.,
tunnel) links. The mechanism described is subject to policy control.A router maintains one or more databases for storing link-state
information about nodes and links in any given area. Link attributes
stored in these databases include: local/remote IP addresses,
local/remote interface identifiers, link IGP metric, link TE metric,
link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class
reservation state, preemption, and Shared Risk Link Groups (SRLGs). The
router's BGP Link-State (BGP-LS) process can retrieve topology from
these LSDBs and distribute it to a consumer, either directly or via a
peer BGP speaker (typically a dedicated Route Reflector), using the
encoding specified in this document.An illustration of the collection of link-state and TE information
and its distribution to consumers is shown in below.| Speaker | +-----------+
| RR1 | | RRm | | Consumer |
+-----------+ +-----------+ +-----------+
^ ^ ^ ^
| | | |
+-----+ +---------+ +---------+ |
| | | |
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
| R1 | | R2 | | Rn |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
]]>A BGP speaker may apply a configurable policy to the information that
it distributes. Thus, it may distribute the real physical topology from
the LSDB or the TED. Alternatively, it may create an abstracted
topology, where virtual, aggregated nodes are connected by virtual
paths. Aggregated nodes can be created, for example, out of multiple
routers in a Point of Presence (POP). Abstracted topology can also be a
mix of physical and virtual nodes and physical and virtual links.
Furthermore, the BGP speaker can apply policy to determine when
information is updated to the consumer so that there is a reduction in
information flow from the network to the consumers. Mechanisms through
which topologies can be aggregated or virtualized are outside the scope
of this document.This document focuses on the specifications related to the
origination of IGP-derived information and their propagation via BGP-LS.
It also describes the advertisement into BGP-LS of information, either
configured or derived, that is local to a node. In general, the
procedures in this document form part of the base BGP-LS protocol
specification and apply to information from other sources that are
introduced into BGP-LS.This document obsoletes by completely
replacing that document. It makes some small changes and clarifications
to the previous specification as documented in .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only
when, they appear in all capitals, as shown here.This section describes use cases from which the requirements can be
derived.As described in , a PCE can be used to
compute MPLS-TE paths within a "domain" (such as an IGP area) or
across multiple domains (such as a multi-area AS or multiple ASes).
Within a single area, the PCE offers enhanced computational
power that may not be available on individual routers,
sophisticated policy control and algorithms, and coordination of
computation across the whole area.If a router wants to compute an MPLS-TE path across IGP areas,
then its own TED lacks visibility of the complete topology. That
means that the router cannot determine the end-to-end path and
cannot even select the right exit router (Area Border Router
(ABR)) for an optimal path. This is an issue for large-scale
networks that need to segment their core networks into distinct
areas but still want to take advantage of MPLS-TE.Previous solutions used per-domain path computation . The source router could only compute the path for
the first area because the router only has full topological visibility
for the first area along the path, but not for subsequent areas.
Per-domain path computation uses a technique called
"loose-hop-expansion" and selects the exit
ABR and other ABRs or AS Border Routers (ASBRs) using the IGP-computed
shortest path topology for the remainder of the path. This may lead to
suboptimal paths, makes alternate/back-up path computation hard, and
might result in no TE path being found when one does exist.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
perform distributed path computation. The PCE needs access to the TED
for the area(s) it serves, but does not
describe how this is achieved. Many implementations make the PCE a
passive participant in the IGP so that it can learn the latest state
of the network, but this may be sub-optimal when the network is
subject to a high degree of churn or when the PCE is responsible for
multiple areas.The following figure shows how a PCE can get its TED information
using the mechanism described in this document.| Speaker |
| ----- | TED synchronization | |
| | | mechanism +---------+
| | |
| v |
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
]]>The mechanism in this document allows the necessary TED information
to be collected from the IGP within the network, filtered according to
configurable policy, and distributed to the PCE as necessary.An ALTO server is an entity that generates
an abstracted network topology and provides it to network-aware
applications over a web-service-based API. Example applications are
peer-to-peer (P2P) clients or trackers, or Content Distribution
Networks (CDNs). The abstracted network topology comes in the form of
two maps: a Network Map that specifies the allocation of prefixes to
Partition Identifiers (PIDs), and a Cost Map that specifies the cost
between PIDs listed in the Network Map. For more details, see .ALTO abstract network topologies can be auto-generated from the
physical topology of the underlying network. The generation would
typically be based on policies and rules set by the operator. Both
prefix and TE data are required: prefix data is required to generate
ALTO Network Maps and TE (topology) data is required to generate ALTO
Cost Maps. Prefix data is carried and originated in BGP, and TE data
is originated and carried in an IGP. The mechanism defined in this
document provides a single interface through which an ALTO server can
retrieve all the necessary prefixes and network topology data from the
underlying network. Note that an ALTO server can use other mechanisms
to get network data, for example, peering with multiple IGP and BGP
speakers.The following figure shows how an ALTO server can get network
topology information from the underlying network using the mechanism
described in this document.In the illustration shown in , the
BGP Speakers can be seen playing different roles in the distribution of
information using BGP-LS. This section introduces terms that explain the
different roles of the BGP Speakers which are then used through the rest
of this document.BGP-LS Producer: The term BGP-LS Producer refers to a BGP Speaker
that is originating link-state information into BGP. The BGP
Speakers R1, R2, ... Rn, originate link-state information from their
underlying link-state IGP protocols into BGP-LS. If R1 and R2 are in
the same IGP flooding domain, then they would ordinarily originate
the same link-state information into BGP-LS. R1 may also originate
information from sources other than IGP, e.g. its local node
information.BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer
application/process and not a BGP Speaker. The BGP Speakers RR1 and
Rn are handing off the BGP-LS information that they have collected
to a consumer application. The BGP protocol implementation and the
consumer application may be on the same or different nodes. This
document only covers the BGP implementation. The consumer
application and the design of the interface between BGP and the
consumer application may be implementation specific and are outside
the scope of this document. The communication of information MUST be
unidirectional (i.e., from a BGP Speaker to the BGP-LS Consumer
application) and a BGP-LS Consumer MUST NOT be able to send
information to a BGP Speaker for origination into BGP-LS.BGP-LS Propagator: The term BGP-LS Propagator refers to a BGP
Speaker that is performing BGP protocol processing on the link-state
information. The BGP Speaker RRm propagates the BGP-LS information
between the BGP Speaker Rn and the BGP Speaker RR1. The BGP
implementation on RRm is propagating BGP-LS information. It performs
handling of BGP-LS UPDATE messages and performs the BGP Decision
Process as part of deciding what information is to be propagated.
Similarly, the BGP Speaker RR1 is receiving BGP-LS information from
R1, R2, and RRm and propagating the information to the BGP-LS
Consumer after performing BGP Decision Process.The above roles are not mutually exclusive. The same BGP
Speaker may be the BGP-LS Producer for some link-state information and
BGP-LS Propagator for some other link-state information while also
providing this information to a BGP-LS Consumer.The rest of this document refers to the role when describing
procedures that are specific to that role. When the role is not
specified, then the said procedure applies to all BGP Speakers.The origination and propagation of IGP link-state information via BGP
needs to provide a consistent and accurate view of the topology of the
IGP domain. BGP-LS provides an abstraction of the IGP specifics and
BGP-LS Consumers may be varied types of applications.The link-state information advertised in BGP-LS from the IGPs is
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
serve as a verbatim reflection of the originating router's LSDB. It does
not include the LSA/LSP sequence number information since a single
link-state object may be put together with information that is coming
from multiple LSAs/LSPs. Also, not all of the information carried in
LSAs/LSPs may be required or suitable for advertisement via BGP-LS
(e.g., ASBR reachability in OSPF, OSPF virtual links, link-local scoped
information, etc.). The LSAs/LSPs that are purged or max-aged are not
included in the BGP-LS advertisement even though they may be present in
the LSDB (e.g., for the IGP flooding purposes). The information from the
LSAs/LSPs that is invalid or malformed or that which needs to be ignored
per the respective IGP protocol specifications are also not included in
the BGP-LS advertisement.The details of the interface between IGPs and BGP for the
advertisement of link-state information are outside the scope of this
document. In some cases, the information derived from IGP processing
(e.g., combination of link-state object from across multiple LSAs/LSPs,
leveraging reachability and two-way connectivity checks, etc.) is
required for advertisement of link-state information into BGP-LS.The link-state information is carried in BGP UPDATE messages as: (1)
BGP NLRI information carried within MP_REACH_NLRI and MP_UNREACH_NLRI
attributes that describes link, node, or prefix object, and (2) a BGP
path attribute (BGP-LS Attribute) that carries properties of the link,
node, or prefix objects such as the link and prefix metric or auxiliary
Router-IDs of nodes, etc.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
way, such that applications that want to learn about a link-state
topology do not need to know about any OSPF or IS-IS protocol
specifics.This section mainly describes the procedures for a BGP-LS Producer to
originate link-state information into BGP-LS.Information in the Link-State NLRIs and the BGP-LS Attribute is
encoded in Type/Length/Value triplets. The TLV format is shown in
and applies to both the NLRI and the
BGP-LS Attribute encodings.The Length field defines the length of the value portion in octets
(thus, a TLV with no value portion would have a length of zero). The
TLV is not padded to 4-octet alignment. Unknown and unsupported types
MUST be preserved and propagated within both the NLRI and the BGP-LS
Attribute. The presence of unknown or unexpected TLVs MUST NOT result
in the NLRI or the BGP-LS Attribute being considered malformed. An
example of an unexpected TLV is when a TLV is received along with an
update for a link state object other than the one that the TLV is
specified as associated with.To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST
be ordered in ascending order by TLV Type. If there are multiple TLVs
of the same type within a single NLRI, then the TLVs sharing the same
type MUST be first in ascending order based on the length field
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 as a symbol to compare, with the symbols ordered by their
numerical value). NLRIs having TLVs which do not follow the above
ordering rules MUST be considered as malformed by a BGP-LS Propagator.
This insistence on canonical ordering ensures that multiple variant
copies of the same NLRI from multiple BGP-LS Producers and the
ambiguity arising therefrom is prevented.For both the NLRI and BGP-LS Attribute parts, all TLVs are
considered as optional except where explicitly specified as mandatory
or required in specific conditions.The TLVs within the BGP-LS Attribute SHOULD be ordered in ascending
order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be
considered malformed.The origination of the same link-state information by multiple
BGP-LS Producers may result in differences and inconsistencies due to
the inclusion or exclusion of optional TLVs. Different optional TLVs
in the NLRI results in multiple NLRIs being generated for the same
link-state object. Different optional TLVs in the BGP-LS Attribute may
result in the propagation of partial information. To address these
inconsistencies, the BGP-LS Consumer will need to recognize and merge
the duplicate information, or to deal with missing information. The
deployment of BGP-LS Producers that consistently originate the same
set of optional TLVs is recommended to mitigate such situations.The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's
containers for carrying opaque information. This specification defines
three Link-State NLRI types that describe either a node, a link, or a
prefix.All non-VPN link, node, and prefix information SHALL be encoded
using AFI 16388 / SAFI 71. VPN link, node, and prefix information
SHALL be encoded using AFI 16388 / SAFI 72.For two BGP speakers to exchange Link-State NLRI, they MUST use BGP
Capabilities Advertisement to ensure that they are both capable of
properly processing such NLRI. This is done as specified in , by using capability code 1 (multiprotocol BGP),
with AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for
BGP&nbhy;LS&nbhy;VPN.New Link-State NLRI Types may be introduced in the future. Since
supported NLRI type values within the address family are not expressed
in the Multiprotocol BGP (MP-BGP) capability ,
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
introduction of new Link-State NLRI types seamlessly in the future,
without the need for upgrading all BGP speakers in the propagation
path (e.g., a route reflector), this document deviates from the
default handling behavior specified by section 5.4 (paragraph 2) of
for Link-State address-family. An
implementation MUST handle unknown Link-State NLRI types as opaque
objects and MUST preserve and propagate them.The format of the Link-State NLRI is shown in the following
figures.The Total NLRI Length field contains the cumulative length, in
octets, of the rest of the NLRI, not including the NLRI Type field or
itself. For VPN applications, it also includes the length of the Route
Distinguisher.TypeNLRI Type1Node NLRI2Link NLRI3IPv4 Topology Prefix NLRI4IPv6 Topology Prefix NLRIRoute Distinguishers are defined and discussed in .The Node NLRI (NLRI Type = 1) is shown in the following figure.The Link NLRI (NLRI Type = 2) is shown in the following figure.The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the
same format, as shown in the following figure.The Protocol-ID field can contain one of the following values:Protocol-IDNLRI information source protocol1IS-IS Level 12IS-IS Level 23OSPFv24Direct5Static configuration6OSPFv3The 'Direct' and 'Static configuration' protocol types SHOULD be
used when BGP-LS is sourcing local information. For all information
derived from other protocols, the corresponding Protocol-ID MUST be
used. If BGP-LS has direct access to interface information and wants
to advertise a local link, then the Protocol-ID 'Direct' SHOULD be
used. For modeling virtual links, such as described in , the Protocol-ID 'Static configuration'
SHOULD be used.A router may run multiple protocol instances of OSPF or IS-IS
whereby it becomes a border router between multiple IGP domains. Both
OSPF and IS-IS may also run multiple routing protocol instances over
the same link. See and . These instances define independent IGP routing
domains. The Identifier field carries an 8-octet BGP-LS Instance
Identifier (Instance-ID) number that is used to identify the IGP
routing domain where the NLRI belongs. The NLRIs representing
link-state objects (nodes, links, or prefixes) from the same IGP
routing instance should have the same BGP-LS Instance-ID. NLRIs with
different BGP-LS Instance-IDs are considered to be from different IGP
routing instances.To support multiple IGP instances, an implementation needs to
support the configuration of unique BGP-LS Instance-IDs at the routing
protocol instance level. The BGP-LS Instance-ID 0 is RECOMMENDED to be
used when there is only a single protocol instance in the network
where BGP-LS is operational. The network operator MUST assign the same
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
instances operating in different IGP domains. This can allow the
BGP-LS Consumer to build an accurate segregated multi-domain topology
based on the BGP-LS Instance-ID.When the above-described semantics and recommendations are not
followed, a BGP-LS Consumer may see more than one link-state objects
for the same node, link, or prefix (each with a different BGP-LS
Instance-ID) when there are multiple BGP-LS Producers deployed. This
may also result in the BGP-LS Consumers getting an inaccurate
network-wide topology.Each Node Descriptor, Link Descriptor, and Prefix Descriptor
consists of one or more TLVs, as described in the following sections.
These Descriptor TLVs are applicable for the Node, Link, and Prefix
NLRI Types for the protocols that are listed in . Documents extending BGP-LS specifications
with new NLRI Types and/or protocols MUST specify the NLRI Descriptors
for them.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
in the MP_UNREACH_NLRI. Not doing so can result in duplicate and
in-consistent link-state objects hanging around in the BGP-LS
table.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
32-bit Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
additional auxiliary Router-IDs, mainly for Traffic Engineering
purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
Router-IDs . When
configured, these auxiliary TE Router-IDs (TLV 1028/1029) MUST be
included in the node attribute described in and MAY be included in the link attribute
described in . The advertisement of
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)
to the same node in the network.It is desirable that the Router-ID assignments inside the Node
Descriptors are globally unique. However, there may be Router-ID
spaces (e.g., ISO) where no global registry exists, or worse,
Router-IDs have been allocated following the private-IP allocation
described in . BGP-LS uses the Autonomous
System (AS) Number to disambiguate the Router-IDs, as described in
.One problem that needs to be addressed is the ability to
identify an IGP node globally (by "globally", we mean within the
BGP-LS database collected by all BGP-LS speakers that talk to each
other). This can be expressed through the following two
requirements: The same node MUST NOT be represented by two
keys (otherwise, one node will look like two nodes).Two different nodes MUST NOT be represented
by the same key (otherwise, two nodes will look like one
node).We define an "IGP domain" to be the set of nodes (hence, by
extension links and prefixes) within which each node has a unique
IGP representation by using the combination of OSPF Area-ID,
Router-ID, Protocol-ID, Multi-Topology ID, and BGP-LS Instance-ID.
The problem is that BGP may receive node/link/prefix information
from multiple independent "IGP domains", and we need to
distinguish between them. Moreover, we can't assume there is
always one and only one IGP domain per AS. During IGP transitions,
it may happen that two redundant IGPs are in place.Furthermore, in deployments where BGP-LS is used to advertise
topology from multiple-ASes, the AS Number is used to distinguish
topology information reported from different ASes.The BGP-LS Instance-ID carried in the Identifier field as
described earlier along with a set of sub-TLVs described in , allows specification of a flexible key
for any given node/link information such that the global
uniqueness of the NLRI is ensured. Since the BGP-LS Instance-ID is
operator assigned, its allocation scheme can ensure that each IGP
domain is uniquely identified even across a multi-AS network.The Local Node Descriptors TLV contains Node Descriptors for
the node anchoring the local end of the link. This is a mandatory
TLV in all three types of NLRIs (node, link, and prefix). The Type
is 256. The length of this TLV is variable. The value contains one
or more Node Descriptor Sub-TLVs defined in .The Remote Node Descriptors TLV contains Node Descriptors for
the node anchoring the remote end of the link. This is a mandatory
TLV for Link NLRIs. The type is 257. The length of this TLV is
variable. The value contains one or more Node Descriptor Sub-TLVs
defined in .The Node Descriptor Sub-TLV type code points and lengths are
listed in the following table:Sub-TLV Code PointDescriptionLength512Autonomous System4513BGP-LS Identifier (deprecated)4514OSPF Area-ID4515IGP Router-IDVariableThe sub-TLV values in Node Descriptor TLVs are defined as
follows:Opaque value (32-bit AS
Number). This is an optional TLV. The value SHOULD be set to
the AS Number associated with the BGP process originating the
link-state information. An implementation MAY provide a
configuration option on the BGP-LS Producer to use a different
value; e.g., to avoid collisions when using private AS
numbers.Opaque value (32-bit ID).
This is an optional TLV which has been deprecated by this
document (refer to for more details).
It MAY be advertised for compatibility with implementations. See the final paragraph of
this section for further considerations and recommended
default value.Used to identify the 32-bit area
to which the information advertised in the NLRI belongs. This
is a mandatory TLV when originating information from OSPF that
is derived from area-scope LSAs. The OSPF Area Identifier
allows different NLRIs of the same router to be differentiated
on a per-area basis. It is not used for NLRIs when carrying
information that is derived from AS-scope LSAs as that
information is not associated with a specific area.Opaque value. This is a mandatory
TLV when originating information from IS-IS, OSPF, direct or
static. For an IS-IS non-pseudonode, this contains a 6-octet
ISO Node-ID (ISO system-ID). For an IS-IS pseudonode
corresponding to a LAN, this contains the 6-octet ISO Node-ID
of the Designated Intermediate System (DIS) followed by a
1-octet, nonzero PSN identifier (7 octets in total). For an
OSPFv2 or OSPFv3 non-pseudonode, this contains the 4-octet
Router-ID. For an OSPFv2 pseudonode representing a LAN, this
contains the 4-octet Router-ID of the Designated Router (DR)
followed by the 4-octet IPv4 address of the DR's interface to
the LAN (8 octets in total). Similarly, for an OSPFv3
pseudonode, this contains the 4-octet Router-ID of the DR
followed by the 4-octet interface identifier of the DR's
interface to the LAN (8 octets in total). The TLV size in
combination with the protocol identifier enables the decoder
to determine the type of the node. For Direct or Static
configuration, the value SHOULD be taken from an IPv4 or IPv6
address (e.g. loopback interface) configured on the node. When
the node is running an IGP protocol, an implementation MAY
choose to use the IGP Router-ID for direct or static.There MUST be at most one instance of each sub-TLV type present
in any Node Descriptor. The sub-TLVs within a Node Descriptor MUST
be arranged in ascending order by sub-TLV type. This needs to be
done to compare NLRIs, even when an implementation encounters an
unknown sub-TLV. Using stable sorting, an implementation can do a
binary comparison of NLRIs and hence allow incremental deployment
of new key sub-TLVs.The BGP-LS Identifier was introduced by and its use is being deprecated by this
document. Implementations SHOULD support the advertisement of this
sub-TLV for backward compatibility in deployments where there are
BGP-LS Producer implementations that conform to to ensure consistency of NLRI encoding for
link-state objects. The default value of 0 is RECOMMENDED to be
used when a BGP-LS Producer includes this sub-TLV when originating
information into BGP-LS. Implementations SHOULD provide an option
to configure this value for backward compatibility reasons. As a
reminder, the use of the BGP-LS Instance-ID that is carried in the
Identifier field is the way of segregation of link-state objects
of different IGP domains in BGP-LS.The Link Descriptor field is a set of Type/Length/Value (TLV)
triplets. The format of each TLV is shown in . The Link Descriptor TLVs uniquely identify a
link among multiple parallel links between a pair of anchor routers.
A link described by the Link Descriptor TLVs actually is a
"half-link", a unidirectional representation of a logical link. To
fully describe a single logical link, two anchor routers advertise a
half-link each, i.e., two Link NLRIs are advertised for a given
point-to-point link.A link between two nodes is not considered as complete (or
available) unless it is described by the two Link NLRIs
corresponding to the half-link representation from the pair of
anchor nodes. This check is similar to the 'two-way connectivity
check' that is performed by link-state IGPs.An implementation MAY suppress the advertisement of a Link NLRI,
corresponding to a half-link, from a link-state IGP unless the IGP
has verified that the link is being reported in the IS-IS LSP or
OSPF Router LSA by both the nodes connected by that link. This
'two-way connectivity check' is performed by link-state IGPs during
their computation and can be leveraged before passing information
for any half-link that is reported from these IGPs into BGP-LS. This
ensures that only those Link State IGP adjacencies which are
established get reported via Link NLRIs. Such a 'two-way
connectivity check' could be also required in certain cases (e.g.,
with OSPF) to obtain the proper link identifiers of the remote
node.The format and semantics of the Value fields in most Link
Descriptor TLVs correspond to the format and semantics of value
fields in IS-IS Extended IS Reachability sub-TLVs, defined in , , and . Although the encodings for Link Descriptor TLVs
were originally defined for IS-IS, the TLVs can carry data sourced
by either IS-IS or OSPF.The following TLVs are defined as Link Descriptors in the Link
NLRI:TLV Code PointDescriptionIS-IS TLV/Sub-TLVReference (RFC/Section)258Link Local/Remote Identifiers22/4 / 1.1259IPv4 interface address22/6 / 3.2260IPv4 neighbor address22/8 / 3.3261IPv6 interface address22/12 / 4.2262IPv6 neighbor address22/13 / 4.3263Multi-Topology Identifier---The information about a link present in the LSA/LSP originated by
the local node of the link determines the set of TLVs in the Link
Descriptor of the link. If interface and neighbor addresses, either IPv4 or IPv6, are
present, then the interface/neighbor address TLVs MUST be
included, and the Link Local/Remote Identifiers TLV MUST NOT be
included in the Link Descriptor. The Link Local/Remote
Identifiers TLV MAY be included in the link attribute when
available. IPv4/IPv6 link-local addresses MUST NOT be carried in
the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262)
as descriptors of a link as they are not considered unique.If interface and neighbor addresses are not present and the
link local/remote identifiers are present, then the Link
Local/Remote Identifiers TLV MUST be included in the Link
Descriptor. The Link Local/Remote Identifiers MUST be included
in the Link Descriptor also in the case of links having only
IPv6 link-local addressing on them.The Multi-Topology Identifier TLV MUST be included as a Link
Descriptor if the underlying IGP link object is associated with
a non-default topology.The TLVs/sub-TLVs corresponding to the interface addresses and/or
the local/remote identifiers may not always be signaled in the IGPs
unless their advertisement is enabled specifically. In such cases,
it is valid to advertise a BGP-LS Link NLRI without any of these
identifiers.The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or
OSPF Multi-Topology IDs for a link, node, or prefix.The semantics of the IS-IS MT-ID are defined in sections 7.1
and 7.2 of . The semantics of the OSPF
MT-ID are defined in section 3.7 of . If
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
0 to 127 are valid for the MT-ID.The format of the MT-ID TLV is shown in the following
figure.where Type is 263, Length is 2*n, and n is the number of MT-IDs
carried in the TLV.The MT-ID TLV MAY be included as a Link Descriptor, a Prefix
Descriptor, or in the BGP-LS Attribute of a Node NLRI. When
included as a Link or Prefix Descriptor, only a single MT-ID TLV
containing the MT-ID of the topology where the link or the prefix
is reachable is allowed. In case one wants to advertise multiple
topologies for a given Link Descriptor or Prefix Descriptor,
multiple NLRIs MUST be generated where each NLRI contains a single
unique MT-ID. When used as a Link or Prefix Descriptor for IS-IS,
the Bits R are reserved and MUST be set to 0 (as per section 7.2
of ) when originated and ignored on
receipt.In the BGP-LS Attribute of a Node NLRI, one MT-ID TLV
containing the array of MT-IDs of all topologies where the node is
reachable is allowed. When used in the Node Attribute TLV for
IS-IS, the Bits R are set as per section 7.1 of .The Prefix Descriptor field is a set of Type/Length/Value (TLV)
triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6
prefix originated by a node. The following TLVs are defined as
Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:TLV Code PointDescriptionLengthReference (RFC/Section)263Multi-Topology Identifiervariable264OSPF Route Type1265IP Reachability InformationvariableThe Multi-Topology Identifier TLV MUST be included in the Prefix
Descriptor if the underlying IGP prefix object is associated with a
non-default topology.The OSPF Route Type TLV is an optional TLV corresponding to
Prefix NLRIs originated from OSPF. It is used to identify the OSPF
route type of the prefix. An OSPF prefix MAY be advertised in the
OSPF domain with multiple route types. The Route Type TLV allows
the discrimination of these advertisements. The OSPF Route Type
TLV MUST be included in the advertisement when the type is either
being signaled explicitly in the underlying LSA or can be
determined via another LSA for the same prefix when it is not
signaled explicitly (e.g., in the case of OSPFv2 Extended Prefix
Opaque LSA ). The route type advertised in
the OSPFv2 Extended Prefix TLV (section 2.1 of ) does not make a distinction between Type 1 and
2 for AS external and NSSA external routes. In this case, the
route type to be used in the BGP-LS advertisement can be
determined by checking the OSPFv2 External or NSSA External LSA
for the prefix. A similar check for the base OSPFv2 LSAs can be
done to determine the route type to be used when the route type
value 0 is carried in the OSPFv2 Extended Prefix TLV.The format of the OSPF Route Type TLV is shown in the following
figure.where the Type and Length fields of the TLV are defined in
. The OSPF Route Type
field follows the route types defined in the OSPF protocol and can
be one of the following: Intra-Area (0x1)Inter-Area (0x2)External 1 (0x3)External 2 (0x4)NSSA 1 (0x5)NSSA 2 (0x6)The IP Reachability Information TLV is a mandatory TLV for IPv4
& IPv6 Prefix NLRI types. The TLV contains one IP address
prefix (IPv4 or IPv6) originally advertised in the IGP topology. A
router SHOULD advertise an IP Prefix NLRI for each of its BGP
next-hops. The format of the IP Reachability Information TLV is
shown in the following figure:The Type and Length fields of the TLV are defined in . The following two fields
determine the reachability information of the address family. The
Prefix Length field contains the length of the prefix in bits. The
IP Prefix field contains an IP address prefix, followed by the
minimum number of trailing bits needed to make the end of the
field fall on an octet boundary. Any trailing bits MUST be set to
0. Thus, the IP Prefix field contains the most significant octets
of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 octets
for prefix length 9 to 16, 3 octets for prefix length 17 up to 24,
4 octets for prefix length 25 up to 32, etc.The BGP-LS Attribute (assigned value 29 by IANA) is an optional,
non-transitive BGP attribute that is used to carry link, node, and
prefix parameters and attributes. It is defined as a set of
Type/Length/Value (TLV) triplets, described in the following section.
This attribute SHOULD only be included with Link-State NLRIs. The use
of this attribute for other address families is outside the scope of
this document.The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute
TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute
associated with a Node NLRI, Link NLRI, and Prefix NLRI
respectively.The size of the BGP-LS Attribute may potentially grow large
depending on the amount of link-state information associated with a
single Link-State NLRI. The BGP specification
mandates a maximum BGP message size of 4096 octets. It is RECOMMENDED
that an implementation supports to
accommodate a larger size of information within the BGP-LS Attribute.
BGP-LS Producers MUST ensure that the TLVs included in the BGP-LS
Attribute does not result in a BGP UPDATE message for a single
Link-State NLRI that crosses the maximum limit for a BGP message.An implementation MAY adopt mechanisms to avoid this problem that
may be based the BGP-LS Consumer applications' requirement; these
mechanisms are beyond the scope of this specification. However, if an
implementation chooses to mitigate the problem by excluding some TLVs
from the BGP-LS Attribute, this exclusion SHOULD be done consistently
by all BGP-LS Producers within a given BGP-LS domain. In the event of
inconsistent exclusion of TLVs from the BGP-LS Attribute, the result
would be a differing set of attributes of the link-state object being
propagated to BGP-LS Consumers based on the BGP decision process at
BGP-LS Propagators.When a BGP-LS Propagator finds that it is exceeding the maximum BGP
message size due to the addition or update of some other BGP Attribute
(e.g. AS_PATH), it MUST consider the BGP-LS Attribute to be malformed,
apply the "Attribute Discard" error-handling approach , and handle the propagation as described in . When a BGP-LS Propagator needs to perform
"Attribute Discard" for reducing the BGP UPDATE message size as
specified in section 4 of , it MUST first
discard the BGP-LS Attribute to enable the detection and diagnosis of
this error condition as discussed in . This brings the deployment consideration
that the consistent propagation of BGP-LS information with a BGP
UPDATE message size larger than 4096 octets can only happen along a
set of BGP Speakers that all support .The following Node Attribute TLVs are defined for the BGP-LS
Attribute associated with a Node NLRI:TLV Code PointDescriptionLengthReference (RFC/Section)263Multi-Topology Identifiervariable1024Node Flag Bits11025Opaque Node Attributevariable1026Node Namevariable1027IS-IS Area Identifiervariable1028IPv4 Router-ID of Local Node4 / 4.31029IPv6 Router-ID of Local Node16 / 4.1The Node Flag Bits TLV carries a bitmask describing node
attributes. The value is a 1 octet length bit array of flags,
where each bit represents a node operational state or
attribute.The bits are defined as follows:BitDescriptionReference'O'Overload Bit'T'Attached Bit'E'External Bit'B'ABR Bit'R'Router Bit'V'V6 BitThe bits that are not defined MUST be set to 0 by the
originator and MUST be ignored by the receiver.An IS-IS node can be part of only a single IS-IS area. However,
a node can have multiple synonymous area addresses. Each of these
area addresses is carried in the IS-IS Area Identifier TLV. If
multiple area addresses are present, multiple TLVs are used to
encode them. The IS-IS Area Identifier TLV may be present in the
BGP-LS Attribute only when advertised in the Link-State Node
NLRI.The Node Name TLV is optional. The encoding semantics for the
node name has been borrowed from . The
Value field identifies the symbolic name of the router node. This
symbolic name can either be the Fully Qualified Domain Name (FQDN)
for the router, or it can be a substring of the FQDN (e.g., a
hostname), or it can be any string that an operator wants to use
for the router. The use of FQDN or a substring of it is strongly
RECOMMENDED. The maximum length of the Node Name TLV is 255
octets.The Value field is encoded in 7-bit ASCII. If a user interface
for configuring or displaying this field permits Unicode
characters, that the user interface is responsible for applying
the ToASCII and/or ToUnicode algorithm as described in to achieve the correct format for transmission
or display. describes an IS-IS-specific extension
and describes an OSPF extension for the
advertisement of Node Name which may be encoded in the Node Name
TLV.The local IPv4/IPv6 Router-ID TLVs are used to describe
auxiliary Router-IDs that the IGP might be using, e.g., for TE and
migration purposes such as correlating a Node-ID between different
protocols. If there is more than one auxiliary Router-ID of a
given type, then each one is encoded as a separate TLV.The Opaque Node Attribute TLV is an envelope that transparently
carries optional Node Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID
field or new protocol extensions to the protocol as advertised in
the NLRI header Protocol-ID field for which there is no
protocol-neutral representation in the BGP Link-State NLRI. The
primary use of the Opaque Node Attribute TLV is to bridge the
document lag between a new IGP link-state attribute and its
protocol-neutral BGP-LS extension being defined. Once the
protocol-neutral BGP-LS extensions are defined, the BGP-LS
implementations may still need to advertise the information both
within the Opaque Attribute TLV and the new TLV definition for
incremental deployment and transition.In the case of OSPF, this TLV MUST NOT be used to advertise
TLVs other than those in the OSPF Router Information (RI) LSA
.The type is as specified in . Length is variable.Link Attribute TLVs are TLVs that may be encoded in the BGP-LS
Attribute with a Link NLRI. Each 'Link Attribute' is a
Type/Length/Value (TLV) triplet formatted as defined in . The format and semantics of the Value fields
in some Link Attribute TLVs correspond to the format and semantics
of the Value fields in IS-IS Extended IS Reachability sub-TLVs,
defined in and .
Other Link Attribute TLVs are defined in this document. Although the
encodings for Link Attribute TLVs were originally defined for IS-IS,
the TLVs can carry data sourced by either IS-IS or OSPF.The following Link Attribute TLVs are defined for the BGP-LS
Attribute associated with a Link NLRI:TLV Code PointDescriptionIS-IS TLV/Sub-TLVReference (RFC/Section)1028IPv4 Router-ID of Local Node134/--- / 4.31029IPv6 Router-ID of Local Node140/--- / 4.11030IPv4 Router-ID of Remote Node134/--- / 4.31031IPv6 Router-ID of Remote Node140/--- / 4.11088Administrative group (color)22/3 / 3.11089Maximum link bandwidth22/9 / 3.41090Max. reservable link bandwidth22/10 / 3.51091Unreserved bandwidth22/11 / 3.61092TE Default Metric22/181093Link Protection Type22/20 / 1.21094MPLS Protocol Mask---1095IGP Metric---1096Shared Risk Link Group---1097Opaque Link Attribute---1098Link Name---The local/remote IPv4/IPv6 Router-ID TLVs are used to describe
auxiliary Router-IDs that the IGP might be using, e.g., for TE
purposes. All auxiliary Router-IDs of both the local and the
remote node MUST be included in the link attribute of each Link
NLRI. If there is more than one auxiliary Router-ID of a given
type, then multiple TLVs are used to encode them.The MPLS Protocol Mask TLV carries a bitmask describing which
MPLS signaling protocols are enabled. The length of this TLV is 1.
The value is a bit array of 8 flags, where each bit represents an
MPLS Protocol capability.Generation of the MPLS Protocol Mask TLV is only valid for and
SHOULD only be used with originators that have local link insight,
for example, the Protocol-IDs 'Static configuration' or 'Direct'
as per . The MPLS Protocol Mask TLV
MUST NOT be included in NLRIs with the other Protocol-IDs listed
in .The following bits are defined, and the reserved bits MUST be
set to zero and SHOULD be ignored on receipt:BitDescriptionReference'L'Label Distribution Protocol (LDP)'R'Extension to RSVP for LSP Tunnels (RSVP&nbhy;TE)The bits that are not defined MUST be set to 0 by the
originator and MUST be ignored by the receiver.The TE Default Metric TLV carries the Traffic Engineering
metric for this link. The length of this TLV is fixed at 4 octets.
If a source protocol uses a metric width of fewer than 32 bits,
then the high-order bits of this field MUST be padded with
zero.The IGP Metric TLV carries the metric for this link. The length
of this TLV is variable, depending on the metric width of the
underlying protocol. IS-IS small metrics are of 6-bit size, but
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
ignored by the receiver. OSPF link metrics have a length of 2
octets. IS-IS wide metrics have a length of 3 octets.The Shared Risk Link Group (SRLG) TLV carries the Shared Risk
Link Group information (see Section 2.3 ("Shared Risk Link Group
Information") of ). It contains a data
structure consisting of a (variable) list of SRLG values, where
each element in the list has 4 octets, as shown in . The length of this TLV is 4 * (number of SRLG
values).The SRLG TLV for OSPF-TE is defined in . In IS-IS, the SRLG information is carried in
two different TLVs: the IPv4 (SRLG) TLV (Type 138) defined in
and the IPv6 SRLG TLV (Type 139) defined
in . Both IPv4 and IPv6 SRLG information
is carried in a single TLV.The Opaque Link Attribute TLV is an envelope that transparently
carries optional Link Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID
field or new protocol extensions to the protocol as advertised in
the NLRI header Protocol-ID field for which there is no
protocol-neutral representation in the BGP Link-State NLRI. The
primary use of the Opaque Link Attribute TLV is to bridge the
document lag between a new IGP link-state attribute and its
'protocol-neutral' BGP-LS extension being defined. Once the
protocol-neutral BGP-LS extensions are defined, the BGP-LS
implementations may still need to advertise the information both
within the Opaque Attribute TLV and the new TLV definition for
incremental deployment and transition.In the case of OSPFv2, this TLV MUST NOT be used to advertise
information carried using TLVs other than those in the OSPFv2
Extended Link Opaque LSA . In the case of
OSPFv3, this TLV MUST NOT be used to advertise TLVs other than
those in the OSPFv3 E-Router-LSA or E-Link-LSA .The Link Name TLV is optional. The Value field identifies the
symbolic name of the router link. This symbolic name can either be
the FQDN for the link, or it can be a substring of the FQDN, or it
can be any string that an operator wants to use for the link. The
use of FQDN or a substring of it is strongly RECOMMENDED. The
maximum length of the Link Name TLV is 255 octets.The Value field is encoded in 7-bit ASCII. If a user interface
for configuring or displaying this field permits Unicode
characters, that the user interface is responsible for applying
the ToASCII and/or ToUnicode algorithm as described in to achieve the correct format for transmission
or display.How a router derives and injects link names is outside of the
scope of this document.Prefixes are learned from the IGP topology (IS-IS or OSPF) with a
set of IGP attributes (such as metric, route tags, etc.) that are
advertised in the BGP-LS Attribute with Prefix NLRI types 3 and
4.The following Prefix Attribute TLVs are defined for the BGP-LS
Attribute associated with a Prefix NLRI:TLV Code PointDescriptionLengthReference1152IGP Flags11153IGP Route Tag4*n1154IGP Extended Route Tag8*n1155Prefix Metric41156OSPF Forwarding Address41157Opaque Prefix AttributevariableThe IGP Flags TLV contains one octet of IS-IS and OSPF flags
and bits originally assigned to the prefix. The IGP Flags TLV is
encoded as follows:The Value field contains bits defined according to the table
below:BitDescriptionReference'D'IS-IS Up/Down Bit'N'OSPF "no unicast" Bit'L'OSPF "local address" Bit'P'OSPF "propagate NSSA" BitThe bits that are not defined MUST be set to 0 by the
originator and MUST be ignored by the receiver.The IGP Route Tag TLV carries original IGP Tags (IS-IS or OSPF) of the prefix and is encoded as
follows:Length is a multiple of 4.The Value field contains one or more Route Tags as learned in
the IGP topology.The Extended IGP Route Tag TLV carries IS-IS Extended Route
Tags of the prefix and is encoded as
follows:Length is a multiple of 8.The Extended Route Tag field contains one or more Extended
Route Tags as learned in the IGP topology.The Prefix Metric TLV is an optional attribute and may only
appear once. If present, it carries the metric of the prefix as
known in the IGP topology as described in Section 4 of (and therefore represents the reachability cost
to the prefix). If not present, it means that the prefix is
advertised without any reachability.Length is 4.The OSPF Forwarding Address TLV carries the OSPF forwarding address as known in
the original OSPF advertisement. The forwarding address can be
either IPv4 or IPv6.Length is 4 for an IPv4 forwarding address, and 16 for an IPv6
forwarding address.The Opaque Prefix Attribute TLV is an envelope that
transparently carries optional Prefix Attribute TLVs advertised by
a router. An originating router shall use this TLV for encoding
information specific to the protocol advertised in the NLRI header
Protocol-ID field or new protocol extensions to the protocol as
advertised in the NLRI header Protocol-ID field for which there is
no protocol-neutral representation in the BGP Link-State NLRI. The
primary use of the Opaque Prefix Attribute TLV is to bridge the
document lag between a new IGP link-state attribute and its
protocol-neutral BGP-LS extension being defined. Once the
protocol-neutral BGP-LS extensions are defined, the BGP-LS
implementations may still need to advertise the information both
within the Opaque Attribute TLV and the new TLV definition for
incremental deployment and transition.In the case of OSPFv2, this TLV MUST NOT be used to advertise
information carried using TLVs other than those in the OSPFv2
Extended Prefix Opaque LSA . In the case
of OSPFv3, this TLV MUST NOT be used to advertise TLVs other than
those in the OSPFv3 E-Inter-Area-Prefix-LSA,
E-Intra-Area-Prefix-LSA, E-AS-External-Prefix-LSA, and E-NSSA-LSA
.The format of the TLV is as follows:The type is as specified in . Length is variable.TLVs for Vendor Private use are supported using the code point
range reserved as indicated in . For such TLV use
in the NLRI or BGP-LS Attribute, the format as described in is to be used and a 4-octet field MUST be
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
first field in the NLRI immediately following the Total NLRI Length
field of the Link-State NLRI format as described in to carry the Enterprise Code . This enables the use of vendor-specific extensions
without conflicts.Multiple instances of private-use TLVs MAY appear in the BGP-LS
Attribute.BGP link-state information for both IPv4 and IPv6 networks can be
carried over either an IPv4 BGP session or an IPv6 BGP session. If an
IPv4 BGP session is used, then the next-hop in the MP_REACH_NLRI
SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is used,
then the next-hop in the MP_REACH_NLRI SHOULD be an IPv6 address.
Usually, the next-hop will be set to the local endpoint address of the
BGP session. The next-hop address MUST be encoded as described in
. The Length field of the next-hop address
will specify the next-hop address family. If the next-hop length is 4,
then the next-hop is an IPv4 address; if the next-hop length is 16,
then it is a global IPv6 address; and if the next-hop length is 32,
then there is one global IPv6 address followed by a link-local IPv6
address. The link-local IPv6 address should be used as described in
. For VPN Subsequent Address Family Identifier
(SAFI), as per custom, an 8-byte Route Distinguisher set to all zero
is prepended to the next-hop.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
BGP-LS Producers, the BGP Next-Hop is used to tiebreak as per the
standard BGP path decision process. This specification doesn't mandate
any rule regarding the rewrite of the BGP Next-Hop.The main source of TE information is the IGP, which is not active
on inter-AS links. In some cases, the IGP may have information of
inter-AS links . In
other cases, an implementation SHOULD provide a means to inject
inter-AS links into BGP-LS. The exact mechanism used to advertise the
inter-AS links is outside the scope of this document.In an OSPF
network, OSPF virtual links serve to connect physically separate
components of the backbone to establish/maintain continuity of the
backbone area. While OSPF virtual links are modeled as point-to-point
unnumbered links in the OSPF topology, their characteristics and
purpose are different from other types of links in the OSPF topology.
They are advertised using a distinct "virtual link" type in OSPF LSAs.
The mechanism for the advertisement of OSPF virtual links via BGP-LS
is outside the scope of this document.In an OSPF network, sham links are used to provide intra-area connectivity between
VPN Routing and Forwarding (VRF) instances on PE routers over the VPN
provider's network. These links are advertised in OSPF as
point-to-point unnumbered links and represent connectivity over a
service provider network using encapsulation mechanisms like MPLS. As
such, the mechanism for the advertisement of OSPF sham links follows
the same procedures as other point-to-point unnumbered links as
described previously in this document.OSPFv2 defines the Type 4 Summary LSA and
OSPFv3 the Inter-area-router-LSA for an Area
Border Router (ABR) to advertise reachability to an AS Border Router
(ASBR) that is external to the area yet internal to the AS. The nature
of information advertised by OSPF using this type of LSA does not map
to either a node or a link or a prefix as discussed in this document.
Therefore, the mechanism for the advertisement of the information
carried by these LSAs is outside the scope of this document.Consider an OSPF network as shown in , where R2 and R3 are the BGP-LS Producers
and also the OSPF Area Border Routers (ABRs). The link between R2 and
R3 is in area 0 while the other links are in area 1 as indicated by
the a0 and a1 references respectively against the links.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 the BGP-LS
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
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.Consider a scenario where the link between R5 and R6 is
lost (thereby partitioning the area 1) and its impact on the OSPF LSDB
at R2 and R3.Now, R5 will remove the link R5-R6 from its Router LSA, and this
updated LSA is available at R2. R2 also has a stale copy of R6's
Router LSA that still has the link R6-R5 in it. Based on this view in
its LSDB, R2 will advertise only the half-link R6-R5 that it derives
from R6's stale Router LSA.At the same time, R6 has removed the link R6-R5 from its Router
LSA, and this updated LSA is available at R3. Similarly, R3 also has a
stale copy of R5's Router LSA having the link R5-R6 in it. Based on
its LSDB, R3 will advertise only the half-link R5-R6 that it has
derived from R5's stale Router LSA.Now, the BGP-LS Consumer receives both the Link NLRIs corresponding
to the half-links from R2 and R3 via RR0. When viewed together, it
would not detect or realize that area 1 is partitioned. Also, if R2
continues to report Node and Prefix NLRIs corresponding to the stale
copy of R4 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
depending on RR0's BGP decision process. This would result in the
BGP-LS Consumer getting stale and inaccurate topology information.
This problem scenario is avoided if R2 were to not advertise the
link-state information corresponding to R4 and R6 and if R3 were to
not advertise similarly for R1 and R5.A BGP-LS Producer SHOULD withdraw all link-state objects advertised
by it in BGP when the node that originated its corresponding LSP/LSAs
is determined to have become unreachable in the IGP. An implementation
MAY continue to advertise link-state objects corresponding to
unreachable nodes in a deployment use-case where the BGP-LS Consumer
is interested in receiving a topology feed corresponding to a complete
IGP LSDB view. In such deployments, it is expected that the problem
described above is mitigated by the BGP-LS Consumer via appropriate
handling of such a topology feed in addition to the use of either a
direct BGP peering with the BGP-LS Producer nodes or mechanisms such
as when using RRs. Details of these
mechanisms are outside the scope of this document.If the BGP-LS Producer does withdraw link-state objects associated
with an IGP node based on the failure of reachability check for that
node, then it MUST re-advertise those link-state objects after that
node becomes reachable again in the IGP domain.The encoding of a broadcast LAN in IS-IS provides a good example of
how Router-IDs are encoded. Consider .
This represents a Broadcast LAN between a pair of routers. The "real"
(non-pseudonode) routers have both an IPv4 Router-ID and IS-IS
Node-ID. The pseudonode does not have an IPv4 Router-ID. Node1 is the
DIS for the LAN. Two unidirectional links (Node1, Pseudonode1) and
(Pseudonode1, Node2) are being generated.The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The
IGP Router-ID TLV of the local Node Descriptor is 6 octets long and
contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV of
the remote Node Descriptor is 7 octets long and contains the ISO-ID of
Pseudonode1, 1920.0000.2001.02. The BGP-LS Attribute of this link
contains one local IPv4 Router-ID TLV (TLV type 1028) containing
192.0.2.1, the IPv4 Router-ID of Node1.The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The
IGP Router-ID TLV of the local Node Descriptor is 7 octets long and
contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP
Router-ID TLV of the remote Node Descriptor is 6 octets long and
contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS Attribute of
this link contains one remote IPv4 Router-ID TLV (TLV type 1030)
containing 192.0.2.2, the IPv4 Router-ID of Node2.|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+
]]>The encoding of a broadcast LAN in OSPF provides a good example of
how Router-IDs and local Interface IPs are encoded. Consider . This represents a Broadcast LAN between a
pair of routers. The "real" (non-pseudonode) routers have both an IPv4
Router-ID and an Area Identifier. The pseudonode does have an IPv4
Router-ID, an IPv4 Interface Address (for disambiguation), and an OSPF
Area. Node1 is the DR for the LAN; hence, its local IP address
198.51.100.1 is used as both the Router-ID and Interface IP for the
pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and
(Pseudonode1, Node2), are being generated.The Link NLRI of (Node1, Pseudonode1) is encoded as follows: Local Node Descriptor TLV #515: IGP Router-ID: 192.0.2.1TLV #514: OSPF Area-ID: ID:0.0.0.0Remote Node Descriptor TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1TLV #514: OSPF Area-ID: ID:0.0.0.0The Link NLRI of (Pseudonode1, Node2) is encoded as follows: Local Node Descriptor TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1TLV #514: OSPF Area-ID: ID:0.0.0.0Remote Node Descriptor TLV #515: IGP Router-ID: 192.0.2.2TLV #514: OSPF Area-ID: ID:0.0.0.0| 192.0.2.1 |--->| 192.0.2.2 |
| | |198.51.100.1 | | |
| Area 0 | | Area 0 | | Area 0 |
+-------------+ +-------------+ +-------------+
]]>The LAN subnet 198.51.100.0/24 is not included in the Router LSA of
Node1 or Node2. The Network LSA for this LAN advertised by the DR
Node1 contains the subnet mask for the LAN along with the DR address.
A Prefix NLRI corresponding to the LAN subnet is advertised with the
Pseudonode1 used as the Local node using the DR address and the subnet
mask from the Network LSA.Graceful migration from one IGP to another requires coordinated
operation of both protocols during the migration period. Such
coordination requires identifying a given physical link in both IGPs.
The IPv4 Router-ID provides that "glue", which is present in the Node
Descriptors of the OSPF Link NLRI and in the link attribute of the
IS-IS Link NLRI.Consider a point-to-point link between two routers, A and B, that
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
Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the
link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link NLRI
for the link is encoded with the IPv4 Router-ID of nodes A and B in
the local and remote Node Descriptors, respectively. The IS-IS Link
NLRI for the link is encoded with the ISO-ID of nodes A and B in the
local and remote Node Descriptors, respectively. In addition, the
BGP-LS Attribute of the IS-IS Link NLRI contains the TLV type 1028
containing the IPv4 Router-ID of node A, TLV type 1030 containing the
IPv4 Router-ID of node B, and TLV type 1031 containing the IPv6
Router-ID of node B. In this case, by using IPv4 Router-ID, the link
(A, B) can be identified in both the IS-IS and OSPF protocols.Distribution of all links available on the global Internet is
certainly possible; however, it is not desirable from a scaling and
privacy point of view. Therefore, an implementation may support a link
to path aggregation. Rather than advertising all specific links of a
domain, an ASBR may advertise an "aggregate link" between a non-adjacent
pair of nodes. The "aggregate link" represents the aggregated set of
link properties between a pair of non-adjacent nodes. The actual methods
to compute the path properties (of bandwidth, metric, etc.) are outside
the scope of this document. The decision of whether to advertise all
specific links or aggregated links is an operator's policy choice. To
highlight the varying levels of exposure, the following deployment
examples are discussed.Consider . Both AS1 and AS2
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
R3, it needs to "see" an alternate path to R3. Therefore, the AS2
operator exposes its topology. All BGP-TE-enabled routers in AS1 "see"
the full topology of AS2 and therefore can compute a backup path. Note
that the computing router decides if the direct link between {R3, R4}
or the {R4, R5, R3} path is used. The brief difference between the "no-link aggregation" example and
this example is that no specific link gets exposed. Consider . The only link that gets advertised
by AS2 is an "aggregate" link between R3 and R4. This is enough to
tell AS1 that there is a backup path. However, the actual links being
used are hidden from the topology.Service providers in control of multiple ASes may even decide to
not expose their internal inter-AS links. Consider . AS3 is modeled as a single node that
connects to the border routers of the aggregated domain. As this document obsoletes and , IANA is requested to change all registration
information that references those documents to instead reference this
document.IANA has assigned address family number 16388 (BGP-LS) in the
"Address Family Numbers" registry.IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the
"SAFI Values" registry under the "Subsequent Address Family Identifiers
(SAFI) Parameters" registry group.IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path
Attributes" registry under the "Border Gateway Protocol (BGP)
Parameters" registry group.IANA has created a "Border Gateway Protocol - Link-State (BGP-LS)
Parameters" registry group at
<https://www.iana.org/assignments/bgp-ls-parameters>.This section also incorporates all the changes to the allocation
procedures for the BGP-LS IANA registry group as well as the guidelines
for designated experts introduced by .All of the registries listed in the following subsections are
BGP-LS specific and are accessible under this registry.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
populated with the values shown below:TypeNLRI TypeReference0Reserved[This document]1Node NLRI[This document]2Link NLRI[This document]3IPv4 Topology Prefix NLRI[This document]4IPv6 Topology Prefix NLRI[This document]65000-65535Private Use[This document]A range is reserved for Private Use . All
other allocations within the registry are to be made using the
"Expert Review" policy that requires
documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG.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
populated with the values shown below:Protocol-IDNLRI information source protocolReference0Reserved[This document]1IS-IS Level 1[This document]2IS-IS Level 2[This document]3OSPFv2[This document]4Direct[This document]5Static configuration[This document]6OSPFv3[This document]200-255Private Use[This document]A range is reserved for Private Use . All
other allocations within the registry are to be made using the
"Expert Review" policy that requires
documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG.The "BGP-LS Well-Known Instance-IDs" registry that was set up via
is no longer required. IANA is requested to
mark this registry as obsolete and to change its registration
procedure to "registry closed".The "BGP-LS Node Flags" registry is requested to be created for
the one octet-sized flags field of the Node Flag Bits TLV (1024) and
populated with the initial values shown below:BitDescriptionReference0Overload Bit (O-bit)[This document]1Attached Bit (A-bit)[This document]2External Bit (E-bit)[This document]3ABR Bit (B-bit)[This document]4Router Bit (R-bit)[This document]5V6 Bit (V-bit)[This document]6-7Unassigned[This document]Allocations within the registry are to be made using the "Expert
Review" policy that requires documentation
of the proposed use of the allocated value and approval by the
Designated Expert assigned by the IESG.The "BGP-LS MPLS Protocol Mask" registry is requested to be
created for the one octet-sized flags field of the MPLS Protocol
Mask TLV (1094) and populated with the initial values shown
below:BitDescriptionReference0Label Distribution Protocol (L-bit)[This document]1Extension to RSVP for LSP Tunnels (R-bit)[This document]2-7Unassigned[This document]Allocations within the registry are to be made using the "Expert
Review" policy that requires documentation
of the proposed use of the allocated value and approval by the
Designated Expert assigned by the IESG.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
populated with the initial values shown below:BitDescriptionReference0IS-IS Up/Down Bit (D-bit)[This document]1OSPF "no unicast" Bit (N-bit)[This document]2OSPF "local address" Bit (L-bit)[This document]3OSPF "propagate NSSA" Bit (P-bit)[This document]4-7Unassigned[This document]Allocations within the registry are to be made using the "Expert
Review" policy that requires documentation
of the proposed use of the allocated value and approval by the
Designated Expert assigned by the IESG.The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor,
and Attribute TLVs" registry was created via . This document requests IANA to rename that
registry to "BGP-LS NLRI and Attribute TLVs" and to remove the
column for "IS-IS TLV/Sub-TLV". The registration procedures are as
below:TLV Code PointRegistration Process0-255Reserved (not to be allocated)256-64999Expert Review65000-65535Private UseA range is reserved for Private Use . All
other allocations except for the reserved range within the registry
are to be made using the "Expert Review" policy that requires documentation of the proposed use
of the allocated value and approval by the Designated Expert
assigned by the IESG.The registry was pre-populated with the values shown in and the reference for all those
allocations should be changed to this document and the respective
section where those TLVs are specified.In all cases of review by the designated expert described here, the
designated expert is expected to check the clarity of purpose and use
of the requested code points. The following points apply to the
registries discussed in this document:Application for a code point allocation may be made to the
designated experts at any time and MUST be accompanied by
technical documentation explaining the use of the code point. Such
documentation SHOULD be presented in the form of an
Internet-Draft, but MAY arrive in any form that can be reviewed
and exchanged among reviewers.The designated experts SHOULD only consider requests that arise
from Internet-Drafts that have already been accepted as working
group documents or that are planned for progression as
AD-Sponsored documents in the absence of a suitably chartered
working group.In the case of working group documents, the designated experts
MUST check with the working group chairs that there is a consensus
within the working group to allocate at this time. In the case of
AD-Sponsored documents, the designated experts MUST check with the
AD for approval to allocate at this time.If the document is not adopted by the IDR Working Group (or its
successor), the designated expert MUST notify the IDR mailing list
(or its successor) of the request and MUST provide access to the
document. The designated expert MUST allow two weeks for any
response. Any comments received MUST be considered by the
designated expert as part of the subsequent step.The designated experts MUST then review the assignment requests
on their technical merit. The designated experts MAY raise issues
related to the allocation request with the authors and on the IDR
(or successor) mailing list for further consideration before the
assignments are made.The designated expert MUST ensure that any request for a code
point does not conflict with work that is active or already
published within the IETF.Once the designated experts have approved, IANA will update the
registry by marking the allocated code points with a reference to
the associated document.In the event that the document is a working group document or
is AD-Sponsored, and that document fails to progress to
publication as an RFC, the working group chairs or AD SHOULD
contact IANA to coordinate about marking the code points as
deprecated. A deprecated code point is not marked as allocated for
use and is not available for allocation in a future document. The
WG chairs may inform IANA that a deprecated code point can be
completely deallocated (i.e., made available for new allocations)
at any time after it has been deprecated if there is a shortage of
unallocated code points in the registry.This section is structured as recommended in .Existing BGP operational procedures apply. No new operation
procedures are defined in this document. It is noted that the NLRI
information present in this document carries purely
application-level data that has no immediate impact on the
corresponding forwarding state computed by BGP. As such, any churn
in reachability information has a different impact than regular BGP
updates, which need to change the forwarding state for an entire
router. Distribution of the BGP-LS NLRIs SHOULD be handled by
dedicated route reflectors in most deployments providing a level of
isolation and fault containment between different BGP address
families. In the event of dedicated route reflectors not being
available, other alternate mechanisms like separation of BGP
instances or separate BGP sessions (e.g. using different addresses
for peering) for Link-State information distribution SHOULD be
used.It is RECOMMENDED that operators deploying BGP-LS enable two or
more BGP-LS Producers in each IGP flooding domain to achieve
redundancy in the origination of link-state information into BGP-LS.
It is also RECOMMENDED that operators ensure BGP peering designs
that ensure redundancy in the BGP update propagation paths (e.g.,
using at least a pair of route reflectors) and ensuring that BGP-LS
Consumers are receiving the topology information from at least two
BGP-LS Speakers.In a multi-domain IGP network, the correct provisioning of the
BGP-LS Instance-IDs on the BGP-LS Producers is required for
consistent reporting of the multi-domain link-state topology. Refer
to for more details.Configuration parameters defined in SHOULD be initialized to the
following default values: The Link-State NLRI capability is turned off for all
neighbors.The maximum rate at which Link-State NLRIs will be
advertised/withdrawn from neighbors is set to 200 updates per
second.The proposed extension is only activated between BGP peers after
capability negotiation. Moreover, the extensions can be turned
on/off on an individual peer basis (see ), so the extension can be
gradually rolled out in the network.The protocol extension defined in this document does not put new
requirements on other protocols or functional components.The frequency of Link-State NLRI updates could interfere with
regular BGP prefix distribution. A network operator should use a
dedicated route reflector infrastructure to distribute Link-State
NLRIs as discussed in .Distribution of Link-State NLRIs SHOULD be limited to a single
admin domain, which can consist of multiple areas within an AS or
multiple ASes.Existing BGP procedures apply. In addition, an implementation
SHOULD allow an operator to: List neighbors with whom the speaker is exchanging Link-State
NLRIs.The IDR working group has documented and continues to document
parts of the Management Information Base and YANG models for
managing and monitoring BGP speakers and the sessions between them.
It is currently believed that the BGP session running BGP-LS is not
substantially different from any other BGP session and can be
managed using the same data models.This section describes the fault management actions, as described
in , that are to be performed for the
handling of BGP UPDATE messages for BGP-LS.A Link-State NLRI MUST NOT be considered malformed or invalid
based on the inclusion/exclusion of TLVs or contents of the TLV
fields (i.e. semantic errors), as described in and .A BGP-LS Speaker MUST perform the following syntactic validation
of the Link-State NLRI to determine if it is malformed.The sum of all TLVs lengths found in the BGP MP_REACH_NLRI
attribute corresponds to the BGP MP_REACH_NLRI length.The sum of all TLVs lengths found in the BGP MP_UNREACH_NLRI
attribute corresponds to the BGP MP_UNREACH_NLRI length.The sum of all TLVs lengths found in a Link-State NLRI
corresponds to the Total NLRI Length field of all its
Descriptors.The length of the TLVs and, when the TLV is recognized then,
the length of its sub-TLVs in the NLRI is valid.The syntactic correctness of the NLRI fields been verified as
per .The rule regarding the ordering of TLVs been followed as
described in .For NLRIs carrying either a Local or Remote Node Descriptor
TLV, there is not more than one instance of a sub-TLV
present.When the error that is determined allows for the router to skip
the malformed NLRI(s) and continue the processing of the rest of the
BGP UPDATE message (e.g. when the TLV ordering rule is violated),
then it MUST handle such malformed NLRIs as 'NLRI discard' (i.e.,
processing similar to what is described in section 5.4 of ). In other cases, where the error in the NLRI
encoding results in the inability to process the BGP UPDATE message
(e.g. length related encoding errors), then the router SHOULD handle
such malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI
besides BGP-LS are being advertised over the same session.
Alternately, the router MUST perform a 'session reset' when the
session is only being used for BGP-LS or if 'AFI/SAFI disable'
action is not possible.A BGP-LS Attribute MUST NOT be considered malformed or invalid
based on the inclusion/exclusion of TLVs or contents of the TLV
fields (i.e. semantic errors), as described in and .A BGP-LS Speaker MUST perform the following syntactic validation
of the BGP-LS Attribute to determine if it is malformed.The sum of all TLVs lengths found in the BGP-LS Attribute
corresponds to the BGP-LS Attribute length.The syntactic correctness of the Attributes (including BGP-LS
Attribute) been verified as per .The length of each TLV and, when the TLV is recognized then,
the length of its sub-TLVs in the BGP-LS Attribute is valid.When the error that is determined allows for the router to skip
the malformed BGP-LS Attribute and continue the processing of the
rest of the BGP UPDATE message (e.g. when the BGP-LS Attribute
length and the total Path Attribute Length are correct but some
TLV/sub-TLV length within the BGP-LS Attribute is invalid), then it
MUST handle such malformed BGP-LS Attribute as 'Attribute Discard'.
In other cases, where the error in the BGP-LS Attribute encoding
results in the inability to process the BGP UPDATE message then the
handling is the same as described above for the malformed NLRI.Note that the 'Attribute Discard' action results in the loss of
all TLVs in the BGP-LS Attribute and not the removal of a specific
malformed TLV. The removal of specific malformed TLVs may give a
wrong indication to a BGP-LS Consumer of that specific information
being deleted or not available.When a BGP Speaker receives an UPDATE message with Link-State
NLRI(s) in the MP_REACH_NLRI but without the BGP-LS Attribute, it is
most likely an indication that a BGP Speaker preceding it has
performed the 'Attribute Discard' fault handling. An implementation
SHOULD preserve and propagate the Link-State NLRIs, unless denied by
local policy, in such an UPDATE message so that the BGP-LS Consumers
can detect the loss of link-state information for that object and
not assume its deletion/withdrawal. This also makes it possible for
a network operator to trace back to the BGP-LS Propagator that
detected the fault with the BGP-LS Attribute.An implementation SHOULD log a message for any errors found
during syntax validation for further analysis.A BGP-LS Propagator, even when it has a coexisting BGP-LS
Consumer on the same node, should not perform semantic validation of
the Link-State NLRI or the BGP-LS Attribute to determine if it is
malformed or invalid. Some types of semantic validation that are not
to be performed by a BGP-LS Propagator are as follows (and this is
not to be considered as an exhaustive list):presence of mandatory TLVthe length of a fixed-length TLV correct or the length of a
variable length TLV is valid or permissiblethe values of TLV fields are valid or permissiblethe inclusion and use of TLVs/sub-TLVs with specific
Link-State NLRI types is validEach TLV may indicate the valid and permissible values and their
semantics that can be used only by a BGP-LS Consumer for its
semantic validation. However, the handling of any errors may be
specific to the particular application and outside the scope of this
document.An implementation SHOULD allow the operator to specify neighbors
to which Link-State NLRIs will be advertised and from which
Link-State NLRIs will be accepted.An implementation SHOULD allow the operator to specify the
maximum rate at which Link-State NLRIs will be advertised/withdrawn
from neighbors.An implementation SHOULD allow the operator to specify the
maximum number of Link-State NLRIs stored in a router's Routing
Information Base (RIB).An implementation SHOULD allow the operator to create abstracted
topologies that are advertised to neighbors and create different
abstractions for different neighbors.An implementation MUST allow the operator to configure an 8-octet
BGP-LS Instance-ID. Refer to for guidance
to the operator for the configuration of BGP-LS Instance-ID.An implementation SHOULD allow the operator to configure ASN and
BGP-LS identifiers (refer to ).An implementation SHOULD allow the operator to configure limiting
of maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS
Producer or to allow larger values when they know that is supported on all BGP-LS Speakers.Not Applicable.An implementation SHOULD provide the following statistics: Total number of Link-State NLRI updates sent/receivedNumber of Link-State NLRI updates sent/received, per
neighborNumber of errored received Link-State NLRI updates, per
neighborTotal number of locally originated Link-State NLRIsThese statistics should be recorded as absolute counts since the
system or session start time. An implementation MAY also enhance
this information by recording peak per-second counts in each
case.An operator MUST define an import policy to limit inbound updates
as follows: Drop all updates from peers that are only serving BGP-LS
Consumers.An implementation MUST have the means to limit inbound
updates.This section contains the global table of all TLVs/sub-TLVs defined
in this document.TLV Code PointDescriptionReference Section256Local Node Descriptors257Remote Node Descriptors258Link Local/Remote Identifiers259IPv4 interface address260IPv4 neighbor address261IPv6 interface address262IPv6 neighbor address263Multi-Topology ID264OSPF Route Type265IP Reachability Information512Autonomous System513BGP-LS Identifier (deprecated)514OSPF Area-ID515IGP Router-ID1024Node Flag Bits1025Opaque Node Attribute1026Node Name1027IS-IS Area Identifier1028IPv4 Router-ID of Local Node / 1029IPv6 Router-ID of Local Node / 1030IPv4 Router-ID of Remote Node1031IPv6 Router-ID of Remote Node1088Administrative group (color)1089Maximum link bandwidth1090Max. reservable link bandwidth1091Unreserved bandwidth1092TE Default Metric1093Link Protection Type1094MPLS Protocol Mask1095IGP Metric1096Shared Risk Link Group1097Opaque Link Attribute1098Link Name1152IGP Flags1153IGP Route Tag1154IGP Extended Route Tag1155Prefix Metric1156OSPF Forwarding Address1157Opaque Prefix AttributeProcedures and protocol extensions defined in this document do not
affect the BGP security model. See the Security Considerations section
of for a discussion of BGP security. Also,
refer to and for
analysis of security issues for BGP.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
Consumer by using the policy configuration options discussed in and . Generally, an operator is aware of the
BGP-LS speaker's role and link-state peerings. Therefore, the operator
can protect the BGP-LS speaker from peers sending updates that may
represent erroneous information, feedback loops, or false input.An error or tampering of the link-state information that is
originated into BGP-LS and propagated through the network for use by
BGP-LS Consumers applications can result in the malfunction of those
applications. Some examples of such risks are the origination of
incorrect information that is not present or consistent with the IGP
LSDB at the BGP-LS Producer, incorrect ordering of TLVs in the NLRI or
inconsistent origination from multiple BGP-LS Producers and updates to
either the NLRI or BGP-LS Attribute during propagation (including
discarding due to errors). These are not new risks from a BGP protocol
perspective, however, in the case of BGP-LS impact reflects on the
consumer applications instead of BGP routing functionalities.Additionally, it may be considered that the export of link-state and
TE information as described in this document constitutes a risk to
confidentiality of mission-critical or commercially sensitive
information about the network. BGP peerings are not automatic and
require configuration; thus, it is the responsibility of the network
operator to ensure that only trusted BGP Speakers are configured to
receive such information. Similar security considerations also arise on
the interface between BGP Speaker and BGP-LS Consumers, but their
discussion is outside the scope of this document.The following persons contributed significant text to RFC7752 and
this document. They should be considered co-authors.This document update to the BGP-LS specification 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.Cengiz Alaettinoglu and Parag Amritkar brought forward the need to
clarify the advertisement of a LAN subnet for OSPF.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.The detailed AD review by Alvaro Retana and his suggestions have
helped improve this document significantly.We would like to thank Robert Varga for his significant contribution
to RFC7752.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.Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network service
(ISO 8473)International Organization for
StandardizationPrivate Enterprise NumbersIANAThis section lists the high-level changes from RFC 7752 and provides
reference to the document sections wherein those have been
introduced.Updated the in and added to illustrate the
different roles of a BGP implementation in conveying link-state
information.Clarified aspects related to advertisement of link-state
information from IGPs into BGP-LS in .In , clarification about the TLV
handling aspects that apply to both the NLRI and BGP-LS Attribute
parts and those that are applicable only for the NLRI portion. An
implementation may have missed the part about the handling of
unknown TLV and so, based on guidelines,
might discard the unknown NLRI types. This aspect is now
unambiguously clarified in . Also, the
TLVs in the BGP-LS Attribute that are not ordered are not to be
considered malformed.Clarification of mandatory and optional TLVs in both NLRI and
BGP-LS Attribute portions all through the document.Handling of large size of BGP-LS Attribute with growth in BGP-LS
information is explained in along with
mitigation of errors arising out of it.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
and NLRI types that they introduce.Clarification on the use of the Identifier field in the
Link-State NLRI in is provided. It was
defined ambiguously to refer to only multi-instance IGP on a single
link while it can also be used for multiple IGP protocol instances
on a router. The IANA registry is accordingly being removed.The BGP-LS Identifier TLV in the Node Descriptors has been
deprecated. Its use was not well specified by and there has been some amount of confusion
between implementators on its usage for identification of IGP
domains as against the use of the Identifier field carrying the
BGP-LS Instance-ID when running multiple instances of IGP routing
protocols. The original purpose of the BGP-LS Identifier was that,
in conjunction with Autonomous System Number (ASN), it would
uniquely identify the BGP-LS domain and that the combination of ASN
and BGP-LS ID would be globally unique. However, the BGP-LS
Instance-ID carried in the Identifier field in the fixed part of the
NLRI also provides a similar functionality. Hence, the inclusion of
the BGP-LS Identifier TLV is not necessary. If advertised, all
BGP-LS speakers within an IGP flooding-set (set of IGP nodes within
which an LSP/LSA is flooded) had to use the same (ASN, BGP-LS ID)
tuple 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,
BGP-LS ID) tuple.Clarification that the Area-ID TLV is mandatory in the Node
Descriptor for the origination of information from OSPF except for
when sourcing information from AS-scope LSAs where this TLV is not
applicable. Also clarified on the IS-IS area and area addresses.Moved MT-ID TLV from the Node Descriptor section to under the
Link Descriptor section since it is not a Node Descriptor sub-TLV.
Fixed the ambiguity in the encoding of OSPF MT-ID in this TLV.
Updated the IS-IS specification reference section and describe the
differences in the applicability of the R flags when MT-ID TLV is
used as link descriptor TLV and Prefix Attribute TLV. MT-ID TLV use
is now elevated to SHOULD when it is enabled in the underlying
IGP.Clarified that IPv6 Link-Local Addresses are not advertised in
the Link Descriptor TLVs and the local/remote identifiers are to be
used instead for links with IPv6 link-local addresses only.Update the usage of OSPF Route Type TLV to mandate its use for
OSPF prefixes in since this is required
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
prefixes.Clarification of the specific OSPFv2 and OSPFv3 protocol TLV
space to be used in the node, link, and prefix opaque attribute
TLVs.Clarification on the length of the Node Flag Bits and IGP Flags
TLVs to be one octet.Updated the Node Name TLV in with the
OSPF specification.Clarification on the size of the IS-IS Narrow Metric
advertisement via the IGP Metric TLV and the handling of the unused
bits.Clarified the advertisement of the prefix corresponding to the
LAN segment in an OSPF network in .Clarified the advertisement and support for OSPF specific
concepts like Virtual links, Sham links, and Type 4 LSAs in and .Introduced Private Use TLV code point space and specified their
encoding in .Introduced where issues related to
the consistency of reporting IGP link-state along with their
solutions are covered.Added recommendation for isolation of BGP-LS sessions from other
BGP route exchange to avoid errors and faults in BGP-LS affecting
the normal BGP routing.Updated the Fault Management section with detailed rules based on
the role of the BGP Speaker in the BGP-LS information propagation
flow.Change to the management of BGP-LS IANA registries from
"Specification Required" to "Expert Review" along with updated
guidelines for Designated Experts. More specifically the inclusion
of changes introduced via that is obsoleted
by this document.Added BGP-LS IANA registries with "Expert Review" policy for the
flag fields of various TLVs that was missed out. Renamed the BGP-LS
TLV registry and removed the "IS-IS TLV/Sub-TLV" column from it.