RFC 7752
North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
RFC 7752 🎀 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
okay so this one is from March 2016 🌸 It's a Standards Track document, which means the IETF community agreed on it, it got public review, and the IESG approved it 💅 The editor is H. Gredler, who wrote it as an Individual Contributor. J. Medved and S. Previdi are from Cisco Systems, Inc., A. Farrel is from Juniper Networks, Inc., and S. Ray's header doesn't list an affiliation. The ISSN is 2070-1721 🦋 The header doesn't list anything this document obsoletes or updates, so no drama there ✨
Abstract 🌸
Picture this: in a lot of setups, some component outside a network has to do computations based on how the network is laid out and what's going on with its connections, including Traffic Engineering (TE) info. 🧚 That info usually gets passed around inside the network by IGP routing protocols.
This document describes a way to collect link-state and TE info from networks and share it with those outside components using BGP 💜 It's done with a brand new BGP Network Layer Reachability Information (NLRI) encoding format. It works for physical AND virtual IGP links, and whatever gets shared is subject to policy control 🔥
Two big applications are Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). Iconic. 👑
Status of This Memo 🍓
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📚
For the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7752 💖
Copyright Notice 🌈
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Motivation and Applicability ....................................5
2.1. MPLS-TE with PCE ...........................................5
2.2. ALTO Server Network API ....................................6
3. Carrying Link-State Information in BGP ..........................7
3.1. TLV Format .................................................8
3.2. The Link-State NLRI ........................................8
3.2.1. Node Descriptors ...................................12
3.2.2. Link Descriptors ...................................16
3.2.3. Prefix Descriptors .................................18
3.3. The BGP-LS Attribute ......................................19
3.3.1. Node Attribute TLVs ................................20
3.3.2. Link Attribute TLVs ................................23
3.3.3. Prefix Attribute TLVs ..............................28
3.4. BGP Next-Hop Information ..................................31
3.5. Inter-AS Links ............................................32
3.6. Router-ID Anchoring Example: ISO Pseudonode ...............32
3.7. Router-ID Anchoring Example: OSPF Pseudonode ..............33
3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration ....34
4. Link to Path Aggregation .......................................34
4.1. Example: No Link Aggregation ..............................35
4.2. Example: ASBR to ASBR Path Aggregation ....................35
4.3. Example: Multi-AS Path Aggregation ........................36
5. IANA Considerations ............................................36
5.1. Guidance for Designated Experts ...........................37
6. Manageability Considerations ...................................38
6.1. Operational Considerations ................................38
6.1.1. Operations .........................................38
6.1.2. Installation and Initial Setup .....................38
6.1.3. Migration Path .....................................38
6.1.4. Requirements on Other Protocols and
Functional Components ..............................38
6.1.5. Impact on Network Operation ........................38
6.1.6. Verifying Correct Operation ........................39
6.2. Management Considerations .................................39
6.2.1. Management Information .............................39
6.2.2. Fault Management ...................................39
6.2.3. Configuration Management ...........................40
6.2.4. Accounting Management ..............................40
6.2.5. Performance Management .............................40
6.2.6. Security Management ................................41
7. TLV/Sub-TLV Code Points Summary ................................41
8. Security Considerations ........................................42
9. References .....................................................43
9.1. Normative References ......................................43
9.2. Informative References ....................................45
Acknowledgements ..................................................47
Contributors ......................................................47
Authors' Addresses ................................................481. Introduction ✨
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, like end-to-end Traffic Engineering (TE), would benefit from seeing beyond one area or Autonomous System (AS) so they can make better decisions.
The IETF has defined the Path Computation Element (PCE) [RFC4655] as a mechanism for computing end-to-end TE paths that cross the visibility of more than one TED, or that need CPU-intensive or coordinated computations. The IETF has also defined the ALTO server [RFC5693] 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 in order to do their job. Obsessed with this, honestly. 🦋
This document describes a mechanism for collecting link-state and TE information from networks and sharing it with external components using the BGP routing protocol [RFC4271]. It's achieved with a new BGP NLRI encoding format. The mechanism works for physical and virtual links, and it's subject to policy control 🔥
A router keeps one or more databases storing link-state information about nodes and links in any given area. The link attributes stored in these databases include local/remote IP addresses, local/remote interface identifiers, link metric and 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 process can pull topology from these LSDBs and distribute it to a consumer, either directly or through a peer BGP speaker (typically a dedicated Route Reflector), using the encoding specified in this document 🌸
Here's the whole collection and distribution flow:
+-----------+
| Consumer |
+-----------+
^
|
+-----------+
| BGP | +-----------+
| Speaker | | Consumer |
+-----------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGPFigure 1: Collection of Link-State and TE Information
A BGP speaker can apply configurable policy to the information it distributes 🎀 So it could distribute the real physical topology from the LSDB or the TED. Or it could create an abstracted topology, where virtual, aggregated nodes are connected by virtual paths. Aggregated nodes can be made, for example, out of multiple routers in a Point of Presence (POP). Abstracted topologies can also mix physical and virtual nodes and physical and virtual links. The BGP speaker can even apply policy to decide when information gets updated to the consumer, which cuts down on the flow of information from the network to the consumers 💅 Mechanisms for aggregating or virtualizing topologies are outside the scope of this document.
1.1. Requirements Language 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
2. Motivation and Applicability 🦋
This section describes use cases that the requirements can be derived from.
2.1. MPLS-TE with PCE 🎀
okay so, as [RFC4655] explains, a PCE can compute MPLS-TE paths inside a "domain" (like one IGP area) or across several domains (like a multi-area AS or a bunch of ASes) 🌸
- Within a single area, the PCE brings serious brainpower 🧠 that individual routers might not have, plus fancy policy control, algorithms, and coordination of the computation across the whole area 💅
- Across IGP areas, things get messy 😭 A router's own TED doesn't see the full topology, so it can't work out the end-to-end path and can't even pick the right exit router (Area Border Router (ABR)) for an optimal path. This hits big networks hard, because they split their core into areas but still want MPLS-TE 🥺
Older solutions used per-domain path computation [RFC5152]. The source router could only compute the path for the first area, since it only has full topology visibility for the first area along the path, not the later ones 🙈 Per-domain path computation uses something called "loose-hop-expansion" [RFC3209] and picks the exit ABR and any other ABRs or AS Border Routers (ASBRs) using the IGP-computed shortest path topology for the rest of the path. Honestly, this can lead to sub-optimal paths, makes alternate/back-up path computation hard, and might mean no TE path gets found even when one really exists 💀
The PCE is a computation server that may see more than one IGP area or AS, or it may team up with other PCEs to do distributed path computation ✨ The PCE obviously needs access to the TED for the area(s) it serves, but [RFC4655] doesn't say how that's achieved. Lots of implementations make the PCE a passive participant in the IGP so it can learn the latest state of the network, but that can be sub-optimal when the network has a high degree of churn or when the PCE is responsible for multiple areas 🌈
Here's how a PCE can get its TED information using the mechanism in this document 👑
+----------+ +---------+
| ----- | | BGP |
| | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | |
| | | mechanism: +---------+
| | | BGP with Link-State NLRI
| v |
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
Figure 2: External PCE Node Using a TED Synchronization MechanismThe mechanism in this document lets the necessary TED information get collected from the IGP inside the network, filtered according to configurable policy, and then distributed to the PCE as needed 🦋
2.2. ALTO Server Network API 🧚
An ALTO server [RFC5693] is an entity that generates an abstracted network topology and hands it to network-aware applications over a web-service-based API 💖 Example apps are peer-to-peer (P2P) clients or trackers, or Content Distribution Networks (CDNs) 📡 The abstracted topology comes as two maps: a Network Map that specifies the allocation of prefixes to Partition Identifiers (PIDs), and a Cost Map that specifies the cost between the PIDs listed in the Network Map. For more details, see [RFC7285] ✨
ALTO abstract network topologies can be auto-generated from the physical topology of the underlying network 🌸 Generation would typically be based on policies and rules set by the operator. Both prefix and TE data are required: prefix data is needed to generate ALTO Network Maps, and TE (topology) data is needed to generate ALTO Cost Maps 🫶 Prefix data is carried and originated in BGP, while TE data is originated and carried in an IGP. The mechanism defined in this document gives you a single interface where an ALTO server can grab all the necessary prefix and network topology data from the underlying network 🔥 Note that an ALTO server can use other mechanisms to get network data too, for example, peering with multiple IGP and BGP speakers 💅
Here's how an ALTO server can get network topology information from the underlying network using this mechanism 👑
+--------+
| Client |<--+
+--------+ |
| ALTO +--------+ BGP with +---------+
+--------+ | Protocol | ALTO | Link-State NLRI | BGP |
| Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | | |
| +--------+ +---------+
+--------+ |
| Client |<--+
+--------+
Figure 3: ALTO Server Using Network Topology Information3. Carrying Link-State Information in BGP 🦋
okay this part is the heart of it 💜 This specification has two parts: a brand-new BGP NLRI that describes the links, nodes, and prefixes that make up IGP link-state information, and a brand-new BGP path attribute (the BGP-LS attribute) that carries the properties and attributes of links, nodes, and prefixes, like the link and prefix metric or the auxiliary Router-IDs of nodes, etc. ✨
The goal is to keep dependencies on the protocol source of this attribute to a minimum and represent everything in an IGP-neutral way 🌈 That way, apps that want to learn about a link-state topology don't need to know any OSPF or IS-IS specifics. Iconic behaviour, honestly 👑
3.1. TLV Format 🎀
All the info in the new Link-State NLRIs and attributes gets encoded in Type/Length/Value triplets 🍓 The TLV format looks like this (Figure 4):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TLV FormatThe Length field defines the length of the value portion in octets (so a TLV with no value portion has a length of zero) 🙈 The TLV is not padded to 4-octet alignment. Unrecognized types MUST be preserved and propagated. 😭 To compare NLRIs with unknown TLVs, all TLVs MUST be ordered in ascending order by TLV Type. If there are more TLVs of the same type, then the TLVs MUST be ordered in ascending order of the TLV value within the TLVs with the same type by treating the entire Value field as an opaque hexadecimal string and comparing leftmost octets first, regardless of the length of the string 🔥 All TLVs that aren't specified as mandatory are considered optional 💅
3.2. The Link-State NLRI ✨
okay so MP_REACH_NLRI and MP_UNREACH_NLRI are BGP's little containers for carrying opaque info 📦 and each Link-State NLRI describes either a node, a link, or a prefix 🧚
All non-VPN link, node, and prefix info SHALL be encoded using AFI 16388 / SAFI 71. VPN link, node, and prefix info SHALL be encoded using AFI 16388 / SAFI 72 💜
Before two BGP speakers can swap Link-State NLRI, they MUST use BGP Capabilities Advertisement so they both know they can actually process it 🫶 This is done as specified in [RFC4760], using capability code 1 (multi-protocol BGP), with AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN.
The Link-State NLRI format is shown in the following figures 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Route Distinguisher +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Link-State NLRI (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI FormatThe Total NLRI Length field is the cumulative length, in octets, of the rest of the NLRI. It doesn't count the NLRI Type field or itself 🙃 For VPN applications, it also counts the length of the Route Distinguisher.
+------+---------------------------+
| Type | NLRI Type |
+------+---------------------------+
| 1 | Node NLRI |
| 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI |
+------+---------------------------+
Table 1: NLRI TypesRoute Distinguishers are defined and discussed in [RFC4364] 🎀
The Node NLRI (NLRI Type = 1) looks like this ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Node NLRI FormatThe Link NLRI (NLRI Type = 2) looks like this 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The Link NLRI FormatThe IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the same format, shown below 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The IPv4/IPv6 Topology Prefix NLRI FormatThe Protocol-ID field can hold one of these values 🔥
+-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+
| 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 |
| 3 | OSPFv2 |
| 4 | Direct |
| 5 | Static configuration |
| 6 | OSPFv3 |
+-------------+----------------------------------+
Table 2: Protocol IdentifiersThe 'Direct' and 'Static configuration' protocol types SHOULD be used when BGP-LS is sourcing local info 💅 For everything derived from other protocols, the matching Protocol-ID MUST be used. If BGP-LS has direct access to interface info and wants to advertise a local link, then 'Direct' SHOULD be used. For modeling virtual links, like the ones described in Section 4, 'Static configuration' SHOULD be used.
Both OSPF and IS-IS MAY run multiple routing protocol instances over the same link 🦋 See [RFC6822] and [RFC6549]. These instances define independent "routing universes". The 64-bit Identifier field tells you which routing universe the NLRI belongs to. NLRIs representing link-state objects (nodes, links, or prefixes) from the same routing universe MUST have the same 'Identifier' value. NLRIs with different 'Identifier' values MUST be considered to be from different routing universes. Table 3 lists the 'Identifier' values that are defined as well-known in this document 🧠
+------------+----------------------------------+
| Identifier | Routing Universe |
+------------+----------------------------------+
| 0 | Default Layer 3 Routing topology |
+------------+----------------------------------+
Table 3: Well-Known Instance IdentifiersIf a protocol doesn't support multiple routing universes, it SHOULD set the Identifier field according to Table 3. However, an implementation MAY make the 'Identifier' configurable for a given protocol 🌈
Each Node Descriptor and Link Descriptor is made of one or more TLVs, as described in the following sections 🧚
3.2.1. Node Descriptors
okay so every link is anchored by a pair of Router-IDs that the underlying IGP uses. That's 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 extra auxiliary Router-IDs, mainly for Traffic Engineering purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be included in the link attribute described in Section 3.3.2 💖
It's desirable that Router-ID assignments inside the Node Descriptor are globally unique 🌸 But some Router-ID spaces (e.g., ISO) have no global registry at all, or worse, Router-IDs were handed out using the private-IP allocation described in RFC 1918 [RFC1918] 🙈 BGP-LS uses the Autonomous System (AS) Number and BGP-LS Identifier (see Section 3.2.1.4) to tell Router-IDs apart, as described in Section 3.2.1.1.
3.2.1.1. Globally Unique Node/Link/Prefix Identifiers
One problem we need to fix is being able to identify an IGP node globally. By "globally", we mean within the BGP-LS database collected by all the BGP-LS speakers that talk to each other 🌍 This comes down to two requirements:
(A) The same node MUST NOT be represented by two keys (otherwise, one node will look like two nodes).
(B) Two different nodes MUST NOT be represented by the same key (otherwise, two nodes will look like one node).
We define an "IGP domain" as the set of nodes (and, by extension, links and prefixes) where each node has a unique IGP representation, using the combination of Area-ID, Router-ID, Protocol-ID, Multi-Topology ID, and Instance-ID. The tricky part is that BGP may get node/link/prefix info from multiple independent "IGP domains", and we need to tell them apart 😭 Also, we can't assume there's always one and only one IGP domain per AS. During IGP transitions, it can happen that two redundant IGPs are in place at once 🙃
In Section 3.2.1.4, there's a set of sub-TLVs that lets you specify a flexible key for any given node/link info, so global uniqueness of the NLRI is ensured ✨
3.2.1.2. Local Node Descriptors
The Local Node Descriptors TLV holds Node Descriptors for the node anchoring the local end of the link 💜 It's mandatory in all three types of NLRIs (node, link, and prefix). Its length is variable. The value contains one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Local Node Descriptors TLV Format3.2.1.3. Remote Node Descriptors ✨
okay so the Remote Node Descriptors TLV 🦋 is the one that describes the node sitting at the far end of the link. it's giving "other side of the call" energy. it is mandatory for Link NLRIs 💅, so you can't skip it. the length is variable, and the value holds one or more Node Descriptor Sub-TLVs (we'll get to those in Section 3.2.1.4 🧚).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Node Descriptor Sub-TLVs (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Remote Node Descriptors TLV Format 🌸
3.2.1.4. Node Descriptor Sub-TLVs 💜
okay this is the sub-TLV menu 🍓. here are the type code points and lengths:
+--------------------+-------------------+----------+
| Sub-TLV Code Point | Description | Length |
+--------------------+-------------------+----------+
| 512 | Autonomous System | 4 |
| 513 | BGP-LS Identifier | 4 |
| 514 | OSPF Area-ID | 4 |
| 515 | IGP Router-ID | Variable |
+--------------------+-------------------+----------+
Table 4: Node Descriptor Sub-TLVsand here's what each sub-TLV value actually means 🔥:
Autonomous System: it's an opaque value, the 32-bit AS Number. simple and iconic.
BGP-LS Identifier: also an opaque value, a 32-bit ID. together with the Autonomous System Number (ASN), it uniquely identifies the BGP-LS domain 👑. the ASN and BGP-LS ID combo MUST be globally unique, no exceptions bestie 🫶. every BGP-LS speaker inside an IGP flooding-set (the group of IGP nodes that an LSP/LSA gets flooded to) MUST use the same ASN, BGP-LS ID tuple. and if the IGP domain has several flooding-sets, then all the BGP-LS speakers in that domain SHOULD still use the same ASN, BGP-LS ID tuple. the SHOULD is doing a lot of work there ngl 💀.
Area-ID: this identifies the 32-bit area the NLRI belongs to. it's how different NLRIs from the same router get told apart 🦋.
IGP Router-ID: this one is opaque and it's a mandatory TLV, so it has to be there ✨. the vibe depends on what kind of node it is:
- for an IS-IS non-pseudonode, it's the 6-octet ISO Node-ID (ISO system-ID)
- for an IS-IS pseudonode representing a LAN, it's the 6-octet ISO Node-ID of the Designated Intermediate System (DIS), followed by a 1-octet, nonzero PSN identifier (7 octets total)
- for an OSPFv2 or OSPFv3 non-pseudonode, it's the 4-octet Router-ID
- for an OSPFv2 pseudonode representing a LAN, it's 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 total)
- for an OSPFv3 pseudonode, it's 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 total)
the TLV size combined with the protocol identifier lets the decoder figure out what type of node it's looking at 🧚. main character decoding energy.
now the rules for the whole Node Descriptor 💅. there can be at most one instance of each sub-TLV type in any Node Descriptor. the sub-TLVs inside a Node Descriptor MUST be arranged in ascending order by sub-TLV type. this has to happen so NLRIs can be compared, even when an implementation runs into a sub-TLV it doesn't recognise 🙈. with stable sorting, an implementation can do binary comparison of NLRIs, which means new key sub-TLVs can be rolled out incrementally 🌈. it's so organised I'm obsessed.
3.2.1.5. Multi-Topology ID 🌈
the Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF Multi-Topology IDs for a link, node, or prefix ⭐.
for the IS-IS MT-ID semantics, check Section 7.2 of RFC 5120 [RFC5120]. for the OSPF MT-ID semantics, check Section 3.7 of RFC 4915 [RFC4915]. if the MT-ID TLV value comes from OSPF, then the upper 9 bits MUST be set to 0 💖. the R bits are reserved, and they SHOULD be set to 0 when originated and ignored on receipt 🫶.
here's how the MT-ID TLV is laid out 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| Multi-Topology ID 1 | .... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// .... |R R R R| Multi-Topology ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Multi-Topology ID TLV Format
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 present in a Link Descriptor, a Prefix Descriptor, or the BGP-LS attribute of a Node NLRI 🦋. in a Link or Prefix Descriptor, only a single MT-ID TLV is allowed, and it has to contain the MT-ID of the topology where the link or prefix is reachable. if you want to advertise several topologies for one Link Descriptor or Prefix Descriptor, you need to generate multiple NLRIs, and each NLRI carries a unique MT-ID 🧚. in the BGP-LS attribute of a Node NLRI, one MT-ID TLV is allowed, containing the array of MT-IDs for every topology where the node is reachable 👑.
3.2.2. Link Descriptors 🔗
the Link Descriptor field is a set of Type/Length/Value (TLV) triplets 💖. each TLV follows the format in Section 3.1. these TLVs together uniquely identify a link among several parallel links between a pair of anchor routers 🫶.
here's the tea 🍵: a link described by Link Descriptor TLVs is actually a "half-link", which is a unidirectional view of a logical link. to fully describe one logical link, the two originating routers each advertise a half-link. so for a given point-to-point link, you get two Link NLRIs ✨. two halves make a whole, iykyk 💅.
the format and semantics of the Value fields in most Link Descriptor TLVs match the Value fields in IS-IS Extended IS Reachability sub-TLVs, which are defined in [RFC5305], [RFC5307], and [RFC6119] 🌸. the Link Descriptor encodings were originally defined for IS-IS, but these TLVs can carry data from either IS-IS or OSPF 🌈.
these TLVs are valid as Link Descriptors in the Link NLRI:
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology | --- | Section 3.2.1.5 |
| | Identifier | | |
+-----------+---------------------+--------------+------------------+
Table 5: Link Descriptor TLVswhich TLVs show up in a link's Link Descriptor depends on what the LSA/LSP from the link's local node says about that link 🧁:
- if interface and neighbor addresses (IPv4 or IPv6) are present, the IP address TLVs go in the Link Descriptor, but the link local/remote Identifier TLV does not. the link local/remote identifiers MAY be included in the link attribute 💜.
- if interface and neighbor addresses are not present but the link local/remote identifiers are, then the link local/remote Identifier TLV goes in the Link Descriptor 🦋.
- the Multi-Topology Identifier TLV is included in the Link Descriptor whenever that information is present ✨.
3.2.3. Prefix Descriptors 🎀
the Prefix Descriptor field is also a set of Type/Length/Value (TLV) triplets 🌸. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 prefix originated by a node 💖. these TLVs are valid as Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:
+-------------+---------------------+----------+--------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+---------------------+----------+--------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 264 | OSPF Route Type | 1 | Section 3.2.3.1 |
| 265 | IP Reachability | variable | Section 3.2.3.2 |
| | Information | | |
+-------------+---------------------+----------+--------------------+
Table 6: Prefix Descriptor TLVs3.2.3.1. OSPF Route Type 🛣️
the OSPF Route Type TLV is an optional TLV that MAY be present in Prefix NLRIs 🧚. it identifies the OSPF route type of the prefix. it's used when an OSPF prefix gets advertised in the OSPF domain with more than one route type, and the Route Type TLV is what lets you tell those advertisements apart 🫶. here's the format 🎀:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type |
+-+-+-+-+-+-+-+-+Figure 13: OSPF Route Type TLV Format
where the Type and Length fields of the TLV are defined in Table 6 🌈. the OSPF Route Type field values are defined in the OSPF protocol, and the field can be one of the following 💅:
- Intra-Area (0x1)
- Inter-Area (0x2)
- External 1 (0x3)
- External 2 (0x4)
- NSSA 1 (0x5)
- NSSA 2 (0x6)
3.2.3.2. IP Reachability Information ✨
okay so the IP Reachability Information TLV is a mandatory TLV 💅 and it holds exactly one IP address prefix (IPv4 or IPv6) that was originally advertised in the IGP topology 🌸. Its whole job is to glue a particular BGP service NLRI, through its BGP next hop, to a given node in the LSDB 🔗. Think of it as the bestie who connects two friends who would never have met otherwise 🫶. A router SHOULD advertise an IP Prefix NLRI for each of its BGP next hops ✨. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IP Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: IP Reachability Information TLV Format
The Type and Length fields of the TLV are explained in Table 6 🧚. The next two fields are where the reachability info for the address family actually lives 📍. Prefix Length tells you how long the prefix is, in bits. IP Prefix holds the most significant octets of the prefix: 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. 💖
3.3. The BGP-LS Attribute
the BGP-LS attribute is an optional, non-transitive BGP attribute 🦋 that carries link, node, and prefix parameters and attributes. It's a set of Type/Length/Value (TLV) triplets, which we'll get into in the following section. This attribute SHOULD only be included with Link-State NLRIs. This attribute MUST be ignored for all other address families 🙅
3.3.1. Node Attribute TLVs
Node attribute TLVs are the TLVs that may be encoded in the BGP-LS attribute with a Node NLRI. These are the Node Attribute TLVs that are defined 👑:
+-------------+----------------------+----------+-------------------+
| TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+
| 263 | Multi-Topology | variable | Section 3.2.1.5 |
| | Identifier | | |
| 1024 | Node Flag Bits | 1 | Section 3.3.1.1 |
| 1025 | Opaque Node | variable | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 |
| | Local Node | | |
+-------------+----------------------+----------+-------------------+Table 7: Node Attribute TLVs
3.3.1.1. Node Flag Bits TLV
The Node Flag Bits TLV carries a bit mask describing node attributes 🌈. The value is a variable-length bit array of flags, and each bit represents a node capability 💜.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+Figure 15: Node Flag Bits TLV Format
The bits are defined as follows 👀:
+-----------------+-------------------------+------------+
| Bit | Description | Reference |
+-----------------+-------------------------+------------+
| 'O' | Overload Bit | [ISO10589] |
| 'T' | Attached Bit | [ISO10589] |
| 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] |
| 'R' | Router Bit | [RFC5340] |
| 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+------------+Table 8: Node Flag Bits Definitions
3.3.1.2. IS-IS Area Identifier TLV
An IS-IS node can be part of one or more IS-IS areas 🏡. 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 it's advertised in the Link-State Node NLRI 🎀.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: IS-IS Area Identifier TLV Format
3.3.1.3. Node Name TLV
The Node Name TLV is optional 🍓. Its structure and encoding were borrowed from [RFC5301]. The Value field identifies the symbolic name of the router node. That name can be the Fully Qualified Domain Name (FQDN) for the router, it can be a subset of the FQDN (like a hostname), or it can be any string operators want to use for the router 🏷️. Using the FQDN or a subset 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 user interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC5890] to get the correct format for transmission or display 🌸.
Although [RFC5301] describes an IS-IS-specific extension, the Node Name TLV can be used for all protocols. How a router derives and injects node names, e.g., for OSPF nodes, is outside the scope of this document 🤷♀️.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 17: Node Name Format
3.3.1.4. Local IPv4/IPv6 Router-ID TLVs
The local IPv4/IPv6 Router-ID TLVs 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 in its own TLV.
3.3.1.5. Opaque Node Attribute 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 for new protocol extensions to that protocol, for which there is no protocol-neutral representation in the BGP Link-State NLRI 🔥. The main use of the Opaque Node Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol-neutral BGP-LS extensions being published 🧚. A router, for example, could use this extension to advertise the native protocol's Node Attribute TLVs, such as the OSPF Router Informational Capabilities TLV defined in [RFC7770] or the IGP TE Node Capability Descriptor TLV described in [RFC5073] ✨.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque node attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 18: Opaque Node Attribute Format
3.3.2. Link Attribute TLVs 🔗✨
Okay so, Link Attribute TLVs are the TLVs that can be stuffed into the BGP-LS attribute alongside a Link NLRI 💅. Each one is a Type/Length/Value (TLV) triplet, formatted the way Section 3.1 says. The Value fields in some of these basically mirror the IS-IS Extended IS Reachability sub-TLVs from [RFC5305] and [RFC5307], and the rest are brand new and defined right here 🎀. Even though these encodings started life for IS-IS, they can carry info that came from either IS-IS or OSPF, which is so iconic 🦋.
These are the Link Attribute TLVs that are valid in the BGP-LS attribute with a Link NLRI:
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
+-----------+---------------------+--------------+------------------+Table 9: Link Attribute TLVs 📋
3.3.2.1. IPv4/IPv6 Router-ID TLVs 🆔
These local and remote IPv4/IPv6 Router-ID TLVs are how we describe the extra Router-IDs the IGP might be using, like for TE stuff 🧚. Every auxiliary Router-ID of both the local and the remote node MUST be included in the link attribute of each Link NLRI 🫶. If there's more than one auxiliary Router-ID of the same type, you use multiple TLVs to encode them, no drama 💖.
3.3.2.2. MPLS Protocol Mask TLV 🌈
The MPLS Protocol Mask TLV tells you which MPLS signaling protocols are turned on 🔥. It's 1 octet long, and the value is an 8-flag bit array where each bit stands for one MPLS Protocol capability 💜.
Using this TLV only makes sense for originators with local link insight, like the Protocol-IDs 'Static configuration' or 'Direct' from Table 2 🍓. So it SHOULD only be used there. And it MUST NOT be included in NLRIs with the other Protocol-IDs listed in Table 2, so don't even try 🙅♀️.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved |
+-+-+-+-+-+-+-+-+Figure 19: MPLS Protocol Mask TLV 📦
These are the bits that are defined:
+------------+------------------------------------------+-----------+
| Bit | Description | Reference |
+------------+------------------------------------------+-----------+
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
| 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] |
| | (RSVP-TE) | |
| 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+Table 10: MPLS Protocol Mask TLV Codes 🧾
3.3.2.3. TE Default Metric TLV 📏
The TE Default Metric TLV carries the Traffic Engineering metric for this link 🚗. Its length is fixed at 4 octets, which is very precise of it 💅. If a source protocol uses a metric width under 32 bits, the high-order bits of this field MUST be padded with zero, no cap 🙈.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 20: TE Default Metric TLV Format 🎀
3.3.2.4. IGP Metric TLV 🚦
The IGP Metric TLV carries the metric for this link, and its length depends on the metric width of the underlying protocol 🧠. IS-IS small metrics are 1 octet long (the two most significant bits get ignored, bestie 🙃). OSPF link metrics are 2 octets. IS-IS wide metrics are 3 octets 💫.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable length) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 21: IGP Metric TLV Format 🍭
3.3.2.5. Shared Risk Link Group TLV 🫧
The Shared Risk Link Group (SRLG) TLV carries the SRLG info (check Section 2.3 ("Shared Risk Link Group Information") of [RFC4202] if you want the full tea ☕). It's a variable list of SRLG values, and each element is 4 octets, as you can see in Figure 22 👀. The length of this TLV is 4 * (number of SRLG values), so the math is literally that easy 🧮.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 22: Shared Risk Link Group TLV Format 🌸
The SRLG TLV for OSPF-TE is defined in [RFC4203] 🐝. In IS-IS, SRLG info lives in two different TLVs: the IPv4 (SRLG) TLV (Type 138) from [RFC5307], and the IPv6 SRLG TLV (Type 139) from [RFC6119]. But in Link-State NLRI, both the IPv4 and IPv6 SRLG info ride together in a single TLV, which is honestly so clean 🧼.
3.3.2.6. Opaque Link Attribute TLV 🫥
The Opaque Link Attribute TLV is an envelope that carries optional Link Attribute TLVs advertised by a router, without looking inside them 🎁. An originating router SHALL use this TLV for encoding info that's specific to the protocol advertised in the NLRI header Protocol-ID field, or for new protocol extensions to that protocol, as long as there's no protocol-neutral representation in the BGP Link-State NLRI 👑. The main job of this TLV is to bridge the document lag between, say, a brand new IGP link-state attribute being defined and the 'protocol-neutral' BGP-LS extensions getting published 🕰️.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque link attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23: Opaque Link Attribute TLV Format 🧩
3.3.2.7. Link Name TLV 🏷️
The Link Name TLV is optional 🙌. Its Value field identifies the symbolic name of the router link. That name can be the FQDN for the link, a subset of the FQDN, or literally any string operators want to use 🌈. Using the FQDN (or a subset of it) is strongly RECOMMENDED, so please do that, bestie 💖. 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 allows Unicode characters, then that interface is responsible for applying the ToASCII and/or ToUnicode algorithm described in [RFC5890] to get the correct format for transmission or display ✨. Not the router's problem, it's the UI's job 💅.
How a router derives and injects link names is outside the scope of this document 🙃.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 24: Link Name TLV Format 🦋
3.3.3. Prefix Attribute TLVs ✨
okay so prefixes get learned from the IGP topology (IS-IS or OSPF), and they come with a whole bundle of IGP attributes (metric, route tags, etc.) that MUST be reflected into the BGP-LS attribute with a prefix NLRI. this section is all about the attributes for IPv4/IPv6 prefixes 🎀 Prefix Attribute TLVs SHOULD be used when advertising NLRI types 3 and 4 only. here's the full lineup:
+---------------+----------------------+----------+-----------------+
| TLV Code | Description | Length | Reference |
| Point | | | |
+---------------+----------------------+----------+-----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | IGP Route Tag | 4*n | [RFC5130] |
| 1154 | IGP Extended Route | 8*n | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | 4 | [RFC5305] |
| 1156 | OSPF Forwarding | 4 | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | variable | Section 3.3.3.6 |
| | Attribute | | |
+---------------+----------------------+----------+-----------------+
Table 11: Prefix Attribute TLVs3.3.3.1. IGP Flags TLV 🚩
the IGP Flags TLV holds the IS-IS and OSPF flags and bits that were originally assigned to the prefix. here's how it's laid out:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+
Figure 25: IGP Flag TLV Formatthe Value field is where the bits live, and they're defined in this table 💅
+----------+---------------------------+-----------+
| Bit | Description | Reference |
+----------+---------------------------+-----------+
| 'D' | IS-IS Up/Down Bit | [RFC5305] |
| 'N' | OSPF "no unicast" Bit | [RFC5340] |
| 'L' | OSPF "local address" Bit | [RFC5340] |
| 'P' | OSPF "propagate NSSA" Bit | [RFC5340] |
| Reserved | Reserved for future use. | |
+----------+---------------------------+-----------+
Table 12: IGP Flag Bits Definitions3.3.3.2. IGP Route Tag TLV 🏷️
the IGP Route Tag TLV carries the original IGP Tags (IS-IS [RFC5130] or OSPF) of the prefix. it's encoded like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Route Tags (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: IGP Route Tag TLV FormatLength is a multiple of 4. the Value field contains one or more Route Tags, exactly as they were learned in the IGP topology.
3.3.3.3. Extended IGP Route Tag TLV 🧚
the Extended IGP Route Tag TLV carries the IS-IS Extended Route Tags of the prefix [RFC5130]. format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Extended Route Tag (one or more) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Extended IGP Route Tag TLV FormatLength is a multiple of 8. the Extended Route Tag field holds one or more Extended Route Tags as learned in the IGP topology.
3.3.3.4. Prefix Metric TLV 📏
the Prefix Metric TLV is an optional attribute and may only appear once 🙈 when it's there, it carries the metric of the prefix as known in the IGP topology, as described in Section 4 of [RFC5305]. so it represents the reachability cost to the prefix. if it's not present, that means the prefix is advertised without any reachability.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Prefix Metric TLV FormatLength is 4.
3.3.3.5. OSPF Forwarding Address TLV 🦋
the OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF forwarding address as it was known in the original OSPF advertisement. the forwarding address can be either IPv4 or IPv6 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Forwarding Address (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OSPF Forwarding Address TLV FormatLength is 4 for an IPv4 forwarding address, and 16 for an IPv6 forwarding address.
3.3.3.6. Opaque Prefix Attribute TLV 🫧
the Opaque Prefix Attribute TLV is an envelope that transparently carries optional Prefix Attribute TLVs advertised by a router. it's basically a carry-all for stuff that has no protocol-neutral home in BGP-LS yet 🫶 an originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field. it's also for new protocol extensions to that protocol (as advertised in the NLRI header Protocol-ID field) that have no protocol-neutral representation in the BGP Link-State NLRI. the big reason it exists is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol-neutral BGP-LS extensions being published. the lag is real, bestie 😭
the format of the TLV is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Opaque Prefix Attributes (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Opaque Prefix Attribute TLV FormatType is as specified in Table 11. Length is variable.
3.4. BGP Next-Hop Information 🌸
BGP link-state information for both IPv4 and IPv6 networks can ride over either an IPv4 BGP session or an IPv6 BGP session. if it's an IPv4 BGP session, the next hop in the MP_REACH_NLRI SHOULD be an IPv4 address. same deal for IPv6: if it's an IPv6 BGP session, the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. usually the next hop is set to the local endpoint address of the BGP session. the next-hop address MUST be encoded as described in [RFC4760]. the Length field of the next-hop address tells you the next-hop address family 👀 a length of 4 means an IPv4 address. a length of 16 means a global IPv6 address. and a length of 32 means there's one global IPv6 address followed by a link-local IPv6 address. the link-local IPv6 address should be used as described in [RFC2545]. 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 attribute is what each BGP-LS speaker uses to validate the NLRI it receives. if identical NLRIs come from multiple originators, the BGP Next Hop attribute is used to tiebreak, as per the standard BGP path decision process. this specification doesn't mandate any rule about rewriting the BGP Next Hop attribute 🤷♀️
3.5. Inter-AS Links 🌉
the main source of TE information is the IGP, and the IGP isn't active on inter-AS links 🙃 sometimes the IGP does have info about inter-AS links [RFC5392] [RFC5316], but not always. in other cases, an implementation SHOULD provide a means to inject inter-AS links into BGP-LS. the exact mechanism for provisioning those inter-AS links is outside the scope of this document.
3.6. Router-ID Anchoring Example: ISO Pseudonode 🍓
encoding a broadcast LAN in IS-IS is a great example of how Router-IDs get encoded ✨ check out Figure 31. it shows a Broadcast LAN between a pair of routers. the "real" (non-pseudonode) routers have both an IPv4 Router-ID and an IS-IS Node-ID. the pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the LAN. two unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), are being generated.
the Link NLRI of (Node1, Pseudonode1) is encoded like this. 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 like this. 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 🎀
+-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+
Figure 31: IS-IS Pseudonodes3.7. Router-ID Anchoring Example: OSPF Pseudonode 🦋
okay so OSPF broadcast LANs are the perfect example of how Router-IDs and local interface IPs get encoded 😭🫶. Check out Figure 32. It shows a broadcast LAN sitting between a pair of routers. The "real" routers (the non-pseudonode ones) each have an IPv4 Router-ID and an Area Identifier. The pseudonode has an IPv4 Router-ID, an IPv4 Interface Address (so it can be told apart), and an OSPF Area. Node1 is the DR for the LAN, so its local IP address 10.1.1.1 gets used as both the Router-ID and the Interface IP for the pseudonode keys ✨. Two unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), are generated.
The Link NLRI of (Node1, Pseudonode1) looks like this:
- Local Node Descriptor
TLV #515: IGP Router-ID: 11.11.11.11
TLV #514: OSPF Area-ID: ID:0.0.0.0- Remote Node Descriptor
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0The Link NLRI of (Pseudonode1, Node2) looks like this:
- Local Node Descriptor
TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0- Remote Node Descriptor
TLV #515: IGP Router-ID: 33.33.33.34
TLV #514: OSPF Area-ID: ID:0.0.0.0 +-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 |
| 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 |
| | | 10.1.1.1 | | |
| Area 0 | | Area 0 | | Area 0 |
+-----------------+ +-----------------+ +-----------------+
Figure 32: OSPF Pseudonodes3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 🌸
moving from one IGP to another gracefully means both protocols have to run together for the whole migration period 💅. To make that work, you need a way to point at the same physical link in both IGPs. That's where the IPv4 Router-ID comes in as the "glue" 🫶. It shows up in the Node Descriptors of the OSPF Link NLRI and in the link attribute of the IS-IS Link NLRI.
Picture a point-to-point link between routers A and B. They started out as OSPFv2-only routers, and then IS-IS got turned on. Node A has an IPv4 Router-ID and an ISO-ID. Node B has an IPv4 Router-ID, an IPv6 Router-ID, and an ISO-ID 👑. Each protocol makes one Link NLRI for the link (A, B), and BGP-LS carries both of them. The OSPFv2 Link NLRI uses the IPv4 Router-ID of node A in its local Node Descriptor and the IPv4 Router-ID of node B in its remote one. The IS-IS Link NLRI uses the ISO-ID of node A in its local Node Descriptor and the ISO-ID of node B in its remote one. On top of that, the BGP-LS attribute of the IS-IS Link NLRI carries TLV type 1028 with node A's IPv4 Router-ID, TLV type 1030 with node B's IPv4 Router-ID, and TLV type 1031 with node B's IPv6 Router-ID. So by using the IPv4 Router-ID, the link (A, B) can be spotted in both IS-IS and OSPF 🧚.
4. Link to Path Aggregation 🎀
sending out every link available in the global Internet is totally possible 🙈, but it's not desirable from a scaling or privacy point of view. So an implementation may support link to path aggregation. Instead of advertising every specific link in a domain, an ASBR may advertise an "aggregate link" between a non-adjacent pair of nodes. That aggregate link stands for the combined set of link properties between those two non-adjacent nodes. How you actually compute path properties (bandwidth, metric, and so on) is outside the scope of this document. Whether to advertise all the specific links or the aggregated ones is up to the operator's policy 💜. To show off the different levels of exposure, here are some deployment examples.
4.1. Example: No Link Aggregation 🍓
Check out Figure 33. Both the AS1 and AS2 operators want to protect their inter-AS {R1, R3} and {R2, R4} links with RSVP-FRR LSPs 🔥. If R1 wants to compute its link-protection LSP to R3, it needs to "see" an alternate path to R3. So the AS2 operator exposes its topology. Every BGP-TE-enabled router in AS1 "sees" the full AS2 topology, which means they can all compute a backup path. Heads up that the computing router is the one that decides whether it uses the direct link between {R3, R4} or the {R4, R5, R3} path.
AS1 : AS2
:
R1-------R3
| : | \
| : | R5
| : | /
R2-------R4
:
:
Figure 33: No Link Aggregation4.2. Example: ASBR to ASBR Path Aggregation 🦋
the big difference between the "no-link aggregation" example and this one is that no specific link gets exposed 🙈. Check out Figure 34. The only link AS2 advertises is an "aggregate" link between R3 and R4. That's enough to tell AS1 there's a backup path, but the actual links being used stay hidden from the topology ✨.
AS1 : AS2
:
R1-------R3
| : |
| : |
| : |
R2-------R4
:
:
Figure 34: ASBR Link Aggregation4.3. Example: Multi-AS Path Aggregation 👑
service providers who control multiple ASes can even choose not to expose their internal inter-AS links 💅. Check out Figure 35. AS3 gets modeled as a single node that connects to the border routers of the aggregated domain.
AS1 : AS2 : AS3
: :
R1-------R3-----
| : : \
| : : vR0
| : : /
R2-------R4-----
: :
: :
Figure 35: Multi-AS Aggregation5. IANA Considerations 🌈
IANA has assigned address family number 16388 (BGP-LS) in the "Address Family Numbers" registry, and this document is listed as the reference ✨.
IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the "SAFI Values" sub-registry, which lives under the "Subsequent Address Family Identifiers (SAFI) Parameters" registry 🫶.
IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path Attributes" sub-registry, which sits under the "Border Gateway Protocol (BGP) Parameters" registry 🎀.
IANA has created a brand-new "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry at http://www.iana.org/assignments/bgp-ls-parameters. Every registry below is BGP-LS specific and lives under this one 💖.
- "BGP-LS NLRI-Types" registry
Value 0 is reserved, and the maximum value is 65535. The registry is populated with the values in Table 1. New allocations need documentation of the proposed use of the value (Specification Required), plus approval from the Designated Expert the IESG assigns (see [RFC5226]) 📝.
- "BGP-LS Protocol-IDs" registry
Value 0 is reserved, and the maximum value is 255. The registry is populated with the values in Table 2. New allocations need documentation of the proposed use of the value (Specification Required), plus approval from the Designated Expert the IESG assigns (see [RFC5226]) 📝.
- "BGP-LS Well-Known Instance-IDs" registry
The registry is populated with the values in Table 3. New allocations from the range 1-31 use the IANA allocation policy "Specification Required" and need approval from the Designated Expert the IESG assigns (see [RFC5226]). Values in the range 32 to 2^64-1 are for "Private Use" and IANA doesn't record them 🧚.
- "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry
Values 0-255 are reserved, and values 256-65535 get used for code points. The registry is populated with the values in Table 13. New allocations need documentation of the proposed use of the value (Specification Required), plus approval from the Designated Expert the IESG assigns (see [RFC5226]) 🔥.
5.1. Guidance for Designated Experts 💜
in every case of Designated Expert (DE) review described here, the DE is expected to confirm that suitable documentation (a specification) exists, as described in [RFC5226], and to verify that the document is permanently and publicly available 🙈. The DE is also expected to check that the purpose and use of the requested code points is clear. Last but not least, the DE must verify that any specification produced in the IETF requesting one of these code points has been made available for review by the IDR working group, and that any specification produced outside the IETF doesn't conflict with work that's active or already published within the IETF 💅.
6. Manageability Considerations 🌸
this section is structured as recommended in [RFC5706] ✨.
6.1. Operational Considerations 🍓
6.1.1. Operations 🫶
existing BGP operational procedures apply, and no new operational procedures are defined in this document. Just so you know, the NLRI info in this document carries purely application-level data with no immediate effect on forwarding state. That means any churn in reachability information hits differently than regular BGP updates, which have to change the forwarding state for an entire router 🧠. It's also expected that distribution of this NLRI will be handled by dedicated route reflectors, which gives a level of isolation and fault containment between different NLRI types 🛡️.
6.1.2. Installation and Initial Setup 🎀
configuration parameters defined in Section 6.2.3 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 are advertised or withdrawn from neighbors is set to 200 updates per second. ⭐
6.1.3. Migration Path 🦋
the proposed extension only activates between BGP peers after capability negotiation. The extensions can also be turned on or off on an individual peer basis (see Section 6.2.3), so the rollout across the network can be gradual 💖.
6.1.4. Requirements on Other Protocols and Functional Components 💅
the protocol extension defined in this document does not put new requirements on other protocols or functional components. no extra homework for anyone 🧚.
6.1.5. Impact on Network Operation 🌈
frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution 😭. A network operator MAY use a dedicated Route-Reflector infrastructure to distribute Link-State NLRIs. It's a choice, not a must 👑.
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 🫶.
6.1.6. Verifying Correct Operation 💜
existing BGP procedures apply. On top of that, an implementation SHOULD allow an operator to:
- List neighbors with whom the speaker is exchanging Link-State NLRIs. 🔍
6.2. Management Considerations 🎀
6.2.1. Management Information 🦋
the IDR working group has documented, and keeps documenting, parts of the Management Information Base and YANG models for managing and monitoring BGP speakers and the sessions between them 📚. It's currently believed that a BGP session running BGP-LS isn't substantially different from any other BGP session, so the same data models can manage it 💖.
6.2.2. Fault Management 🚨
okay bestie, so if a BGP-LS implementation spots a malformed attribute, it MUST use the 'Attribute Discard' action as per [RFC7606], Section 2. no exceptions 💅
An implementation of BGP-LS MUST perform the following syntactic checks to figure out if a message is malformed 🔍
- Does the sum of all TLVs found in the BGP-LS attribute correspond to the BGP-LS path attribute length?
- Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute correspond to the BGP MP_REACH_NLRI length?
- Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI attribute correspond to the BGP MP_UNREACH_NLRI length?
- Does the sum of all TLVs found in a Node, Link or Prefix Descriptor NLRI attribute correspond to the Total NLRI Length field of the Node, Link, or Prefix Descriptors?
- Does any fixed-length TLV correspond to the TLV Length field in this document?
6.2.3. Configuration Management 🎀
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. the operator gets to be the boss here 👑
An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from neighbors. rate limiting, but make it config 🫶
An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in a router's Routing Information Base (RIB). the RIB needs boundaries, bestie 📦
An implementation SHOULD allow the operator to create abstracted topologies that are advertised to neighbors and create different abstractions for different neighbors. custom looks for every friend group 🦋
An implementation SHOULD allow the operator to configure a 64-bit Instance-ID. ✨
An implementation SHOULD allow the operator to configure a pair of ASN and BGP-LS identifiers (Section 3.2.1.4) per flooding set in which the node participates. so iconic 🧚
6.2.4. Accounting Management 🧾
Not Applicable. 🙃
6.2.5. Performance Management 📊
An implementation SHOULD provide the following statistics:
- Total number of Link-State NLRI updates sent/received
- Number of Link-State NLRI updates sent/received, per neighbor
- Number of errored received Link-State NLRI updates, per neighbor
- Total number of locally originated Link-State NLRIs
these statistics should be recorded as absolute counts since system or session start time. An implementation MAY also enhance this information by recording peak per-second counts in each case. the numbers are the tea, so track them 🍓
6.2.6. Security Management 🔐
An operator SHOULD define an import policy to limit inbound updates as follows:
- Drop all updates from consumer peers.
An implementation MUST have the means to limit inbound updates. not optional, babe 🙅♀️
7. TLV/Sub-TLV Code Points Summary 🧚
This section contains the global table of all TLVs/sub-TLVs defined in this document. here's the whole lineup, sorted and ready 💜
+-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV/ | Reference |
| Point | | Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+
| 256 | Local Node | --- | Section 3.2.1.2 |
| | Descriptors | | |
| 257 | Remote Node | --- | Section 3.2.1.3 |
| | Descriptors | | |
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 |
| | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 |
| | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 |
| | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 |
| | address | | |
| 263 | Multi-Topology ID | --- | Section 3.2.1.5 |
| 264 | OSPF Route Type | --- | Section 3.2.3 |
| 265 | IP Reachability | --- | Section 3.2.3 |
| | Information | | |
| 512 | Autonomous System | --- | Section 3.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 3.2.1.4 |
| 514 | OSPF Area-ID | --- | Section 3.2.1.4 |
| 515 | IGP Router-ID | --- | Section 3.2.1.4 |
| 1024 | Node Flag Bits | --- | Section 3.3.1.1 |
| 1025 | Opaque Node | --- | Section 3.3.1.5 |
| | Attribute | | |
| 1026 | Node Name | variable | Section 3.3.1.3 |
| 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | |
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 |
| | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
| | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 |
| 1095 | IGP Metric | --- | Section 3.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 3.3.2.5 |
| | Group | | |
| 1097 | Opaque Link | --- | Section 3.3.2.6 |
| | Attribute | | |
| 1098 | Link Name | --- | Section 3.3.2.7 |
| 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | IGP Route Tag | --- | [RFC5130] |
| 1154 | IGP Extended Route | --- | [RFC5130] |
| | Tag | | |
| 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding | --- | [RFC2328] |
| | Address | | |
| 1157 | Opaque Prefix | --- | Section 3.3.3.6 |
| | Attribute | | |
+-----------+---------------------+--------------+------------------+ Table 13: Summary Table of TLV/Sub-TLV Code Points8. Security Considerations 🛡️
Procedures and protocol extensions defined in this document do not affect the BGP security model. See the Security Considerations section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP.
In the context of the BGP peerings associated with this document, a BGP speaker MUST NOT accept updates from a consumer peer. That is, a participating BGP speaker should be aware of the nature of its relationships for link-state relationships and should protect itself from peers sending updates that either represent erroneous information feedback loops or are false input. Such protection can be achieved by manual configuration of consumer peers at the BGP speaker.
this is the big one, so please don't skip it 🙈 a BGP speaker MUST NOT accept updates from a consumer peer. full stop, no vibes-based exceptions.
An operator SHOULD employ a mechanism to protect a BGP speaker against DDoS attacks from consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits. the attacker energy is giving "spam the door" 💀
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 consumers are configured to receive such information. only trusted friends get the group chat screenshots, periodt 🔥
9. References 📚
9.1. Normative References
Okay bestie, these are the must-reads 📚 This spec leans on these hard, so you need them to fully get it 💅
[ISO10589] International Organization for Standardization,
"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)", ISO/
IEC 10589, November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
DOI 10.17487/RFC2545, March 1999,
<http://www.rfc-editor.org/info/rfc2545>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy
Control Mechanism in IS-IS Using Administrative Tags",
RFC 5130, DOI 10.17487/RFC5130, February 2008,
<http://www.rfc-editor.org/info/rfc5130>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", RFC 6822,
DOI 10.17487/RFC6822, December 2012,
<http://www.rfc-editor.org/info/rfc6822>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>.9.2. Informative References
These ones are the extra-credit reading 🦋 Super useful for background, even if they aren't strictly required 🌸
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5073] Vasseur, JP., Ed. and JL. Le Roux, Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic Engineering
Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<http://www.rfc-editor.org/info/rfc5152>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
January 2009, <http://www.rfc-editor.org/info/rfc5392>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009,
<http://www.rfc-editor.org/info/rfc5693>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<http://www.rfc-editor.org/info/rfc5706>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<http://www.rfc-editor.org/info/rfc6952>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>.Acknowledgements
Big thank-yous, bestie 🫶 The authors want 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 💜
Contributors
A special shoutout 👑 The authors also want to thank Robert Varga for the significant contribution he gave to this document ✨
Authors' Addresses
Meet the squad 🧚
Hannes Gredler (editor)
Individual Contributor
Email: hannes@gredler.at
Jan Medved
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
United States
Email: jmedved@cisco.com
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico, 200
Rome 00142
Italy
Email: sprevidi@cisco.com
Adrian Farrel
Juniper Networks, Inc.
Email: adrian@olddog.co.uk
Saikat Ray
Email: raysaikat@gmail.com📦 where this page comes from
- ietf: rfc7752 2016-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms