idnits 2.17.1 draft-ietf-idr-rfc7752bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 February 2023) is 431 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ENTNUM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 9029 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing K. Talaulikar, Ed. 3 Internet-Draft Cisco Systems 4 Obsoletes: 7752, 9029 (if approved) 21 February 2023 5 Intended status: Standards Track 6 Expires: 25 August 2023 8 Distribution of Link-State and Traffic Engineering Information Using BGP 9 draft-ietf-idr-rfc7752bis-16 11 Abstract 13 In many environments, a component external to a network is called 14 upon to perform computations based on the network topology and the 15 current state of the connections within the network, including 16 Traffic Engineering (TE) information. This is information typically 17 distributed by IGP routing protocols within the network. 19 This document describes a mechanism by which link-state and TE 20 information can be collected from networks and shared with external 21 components using the BGP routing protocol. This is achieved using a 22 BGP Network Layer Reachability Information (NLRI) encoding format. 23 The mechanism applies to physical and virtual (e.g., tunnel) IGP 24 links. The mechanism described is subject to policy control. 26 Applications of this technique include Application-Layer Traffic 27 Optimization (ALTO) servers and Path Computation Elements (PCEs). 29 This document obsoletes RFC7752 by completely replacing that 30 document. It makes some small changes and clarifications to the 31 previous specification. This document also obsoletes RFC9029 by 32 incorporating the updates that it made to RFC7752. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 25 August 2023. 50 Copyright Notice 52 Copyright (c) 2023 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 68 2. Motivation and Applicability . . . . . . . . . . . . . . . . 6 69 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 6 70 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 71 3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 8 72 4. Advertising IGP Information into BGP-LS . . . . . . . . . . . 10 73 5. Carrying Link-State Information in BGP . . . . . . . . . . . 10 74 5.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 12 76 5.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 16 77 5.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 20 78 5.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 24 79 5.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 26 80 5.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 27 81 5.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 31 82 5.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 36 83 5.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 41 84 5.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 41 85 5.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 42 86 5.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 42 87 5.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router 88 LSA . . . . . . . . . . . . . . . . . . . . . . . . . . 42 89 5.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 43 90 5.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 44 91 5.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 45 92 5.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 46 93 6. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 47 94 6.1. Example: No Link Aggregation . . . . . . . . . . . . . . 47 95 6.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 48 96 6.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 48 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 98 7.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 49 99 7.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 49 100 7.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 50 101 7.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 51 102 7.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 51 103 7.1.5. BGP-LS MPLS Protocol Mask Registry . . . . . . . . . 52 104 7.1.6. BGP-LS IGP Prefix Flags Registry . . . . . . . . . . 53 105 7.1.7. BGP-LS TLVs Registry . . . . . . . . . . . . . . . . 53 106 7.2. Guidance for Designated Experts . . . . . . . . . . . . . 54 107 8. Manageability Considerations . . . . . . . . . . . . . . . . 55 108 8.1. Operational Considerations . . . . . . . . . . . . . . . 55 109 8.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 55 110 8.1.2. Installation and Initial Setup . . . . . . . . . . . 56 111 8.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 56 112 8.1.4. Requirements for Other Protocols and Functional 113 Components . . . . . . . . . . . . . . . . . . . . . 56 114 8.1.5. Impact on Network Operation . . . . . . . . . . . . . 56 115 8.1.6. Verifying Correct Operation . . . . . . . . . . . . . 57 116 8.2. Management Considerations . . . . . . . . . . . . . . . . 57 117 8.2.1. Management Information . . . . . . . . . . . . . . . 57 118 8.2.2. Fault Management . . . . . . . . . . . . . . . . . . 57 119 8.2.3. Configuration Management . . . . . . . . . . . . . . 59 120 8.2.4. Accounting Management . . . . . . . . . . . . . . . . 60 121 8.2.5. Performance Management . . . . . . . . . . . . . . . 60 122 8.2.6. Security Management . . . . . . . . . . . . . . . . . 60 123 9. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 61 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 63 125 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 126 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 128 13.1. Normative References . . . . . . . . . . . . . . . . . . 65 129 13.2. Informative References . . . . . . . . . . . . . . . . . 68 130 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 70 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 72 133 1. Introduction 135 The contents of a Link-State Database (LSDB) or of an IGP's Traffic 136 Engineering Database (TED) describe only the links and nodes within 137 an IGP area. Some applications, such as end-to-end Traffic 138 Engineering (TE), would benefit from visibility outside one area or 139 Autonomous System (AS) to make better decisions. 141 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 142 a mechanism for achieving the computation of end-to-end TE paths that 143 cross the visibility of more than one TED or that requires CPU- 144 intensive or coordinated computations. The IETF has also defined the 145 ALTO server [RFC5693] as an entity that generates an abstracted 146 network topology and provides it to network-aware applications. 148 Both a PCE and an ALTO server need to gather information about the 149 topologies and capabilities of the network to be able to fulfill 150 their function. 152 This document describes a mechanism by which link-state and TE 153 information can be collected from networks and shared with external 154 components using the BGP routing protocol [RFC4271]. This is 155 achieved using a BGP Network Layer Reachability Information (NLRI) 156 encoding format. The mechanism applies to physical and virtual 157 (e.g., tunnel) links. The mechanism described is subject to policy 158 control. 160 A router maintains one or more databases for storing link-state 161 information about nodes and links in any given area. Link attributes 162 stored in these databases include: local/remote IP addresses, local/ 163 remote interface identifiers, link IGP metric, link TE metric, link 164 bandwidth, reservable bandwidth, per Class-of-Service (CoS) class 165 reservation state, preemption, and Shared Risk Link Groups (SRLGs). 166 The router's BGP Link-State (BGP-LS) process can retrieve topology 167 from these LSDBs and distribute it to a consumer, either directly or 168 via a peer BGP speaker (typically a dedicated Route Reflector), using 169 the encoding specified in this document. 171 An illustration of the collection of link-state and TE information 172 and its distribution to consumers is shown in Figure 1 below. 174 +-----------+ 175 | Consumer | 176 +-----------+ 177 ^ 178 | 179 +-----------+ +-----------+ 180 | BGP | | BGP | 181 | Speaker |<----------->| Speaker | +-----------+ 182 | RR1 | | RRm | | Consumer | 183 +-----------+ +-----------+ +-----------+ 184 ^ ^ ^ ^ 185 | | | | 186 +-----+ +---------+ +---------+ | 187 | | | | 188 +-----------+ +-----------+ +-----------+ 189 | BGP | | BGP | | BGP | 190 | Speaker | | Speaker | . . . | Speaker | 191 | R1 | | R2 | | Rn | 192 +-----------+ +-----------+ +-----------+ 193 ^ ^ ^ 194 | | | 195 IGP IGP IGP 197 Figure 1: Collection of Link-State and TE Information 199 A BGP speaker may apply a configurable policy to the information that 200 it distributes. Thus, it may distribute the real physical topology 201 from the LSDB or the TED. Alternatively, it may create an abstracted 202 topology, where virtual, aggregated nodes are connected by virtual 203 paths. Aggregated nodes can be created, for example, out of multiple 204 routers in a Point of Presence (POP). Abstracted topology can also 205 be a mix of physical and virtual nodes and physical and virtual 206 links. Furthermore, the BGP speaker can apply policy to determine 207 when information is updated to the consumer so that there is a 208 reduction in information flow from the network to the consumers. 209 Mechanisms through which topologies can be aggregated or virtualized 210 are outside the scope of this document. 212 This document focuses on the specifications related to the 213 origination of IGP-derived information and their propagation via BGP- 214 LS. It also describes the advertisement into BGP-LS of information, 215 either configured or derived, that is local to a node. In general, 216 the procedures in this document form part of the base BGP-LS protocol 217 specification and apply to information from other sources that are 218 introduced into BGP-LS. 220 This document obsoletes [RFC7752] by completely replacing that 221 document. It makes some small changes and clarifications to the 222 previous specification as documented in Appendix A. 224 1.1. Requirements Language 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 228 "OPTIONAL" in this document are to be interpreted as described in BCP 229 14 [RFC2119] [RFC8174] when, and only when, they appear in all 230 capitals, as shown here. 232 2. Motivation and Applicability 234 This section describes use cases from which the requirements can be 235 derived. 237 2.1. MPLS-TE with PCE 239 As described in [RFC4655], a PCE can be used to compute MPLS-TE paths 240 within a "domain" (such as an IGP area) or across multiple domains 241 (such as a multi-area AS or multiple ASes). 243 * Within a single area, the PCE offers enhanced computational power 244 that may not be available on individual routers, sophisticated 245 policy control and algorithms, and coordination of computation 246 across the whole area. 248 * If a router wants to compute an MPLS-TE path across IGP areas, 249 then its own TED lacks visibility of the complete topology. That 250 means that the router cannot determine the end-to-end path and 251 cannot even select the right exit router (Area Border Router 252 (ABR)) for an optimal path. This is an issue for large-scale 253 networks that need to segment their core networks into distinct 254 areas but still want to take advantage of MPLS-TE. 256 Previous solutions used per-domain path computation [RFC5152]. The 257 source router could only compute the path for the first area because 258 the router only has full topological visibility for the first area 259 along the path, but not for subsequent areas. Per-domain path 260 computation uses a technique called "loose-hop-expansion" [RFC3209] 261 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 262 using the IGP-computed shortest path topology for the remainder of 263 the path. This may lead to suboptimal paths, makes alternate/back-up 264 path computation hard, and might result in no TE path being found 265 when one does exist. 267 The PCE presents a computation server that may have visibility into 268 more than one IGP area or AS, or may cooperate with other PCEs to 269 perform distributed path computation. The PCE needs access to the 270 TED for the area(s) it serves, but [RFC4655] does not describe how 271 this is achieved. Many implementations make the PCE a passive 272 participant in the IGP so that it can learn the latest state of the 273 network, but this may be sub-optimal when the network is subject to a 274 high degree of churn or when the PCE is responsible for multiple 275 areas. 277 The following figure shows how a PCE can get its TED information 278 using the mechanism described in this document. 280 +----------+ +---------+ 281 | ----- | | BGP | 282 | | TED |<-+-------------------------->| Speaker | 283 | ----- | TED synchronization | | 284 | | | mechanism +---------+ 285 | | | 286 | v | 287 | ----- | 288 | | PCE | | 289 | ----- | 290 +----------+ 291 ^ 292 | Request/ 293 | Response 294 v 295 Service +----------+ Signaling +----------+ 296 Request | Head-End | Protocol | Adjacent | 297 -------->| Node |<------------>| Node | 298 +----------+ +----------+ 300 Figure 2: External PCE Node Using a TED Synchronization Mechanism 302 The mechanism in this document allows the necessary TED information 303 to be collected from the IGP within the network, filtered according 304 to configurable policy, and distributed to the PCE as necessary. 306 2.2. ALTO Server Network API 308 An ALTO server [RFC5693] is an entity that generates an abstracted 309 network topology and provides it to network-aware applications over a 310 web-service-based API. Example applications are peer-to-peer (P2P) 311 clients or trackers, or Content Distribution Networks (CDNs). The 312 abstracted network topology comes in the form of two maps: a Network 313 Map that specifies the allocation of prefixes to Partition 314 Identifiers (PIDs), and a Cost Map that specifies the cost between 315 PIDs listed in the Network Map. For more details, see [RFC7285]. 317 ALTO abstract network topologies can be auto-generated from the 318 physical topology of the underlying network. The generation would 319 typically be based on policies and rules set by the operator. Both 320 prefix and TE data are required: prefix data is required to generate 321 ALTO Network Maps and TE (topology) data is required to generate ALTO 322 Cost Maps. Prefix data is carried and originated in BGP, and TE data 323 is originated and carried in an IGP. The mechanism defined in this 324 document provides a single interface through which an ALTO server can 325 retrieve all the necessary prefixes and network topology data from 326 the underlying network. Note that an ALTO server can use other 327 mechanisms to get network data, for example, peering with multiple 328 IGP and BGP speakers. 330 The following figure shows how an ALTO server can get network 331 topology information from the underlying network using the mechanism 332 described in this document. 334 +--------+ 335 | Client |<--+ 336 +--------+ | 337 | ALTO +--------+ Topology +---------+ 338 +--------+ | Protocol | ALTO | Sync Mechanism | BGP | 339 | Client |<--+------------| Server |<----------------| Speaker | 340 +--------+ | | | | | 341 | +--------+ +---------+ 342 +--------+ | 343 | Client |<--+ 344 +--------+ 346 Figure 3: ALTO Server Using Network Topology Information 348 3. BGP Speaker Roles for BGP-LS 350 In the illustration shown in Figure 1, the BGP Speakers can be seen 351 playing different roles in the distribution of information using BGP- 352 LS. This section introduces terms that explain the different roles 353 of the BGP Speakers which are then used through the rest of this 354 document. 356 * BGP-LS Producer: The term BGP-LS Producer refers to a BGP Speaker 357 that is originating link-state information into BGP. The BGP 358 Speakers R1, R2, ... Rn, originate link-state information from 359 their underlying link-state IGP protocols into BGP-LS. If R1 and 360 R2 are in the same IGP flooding domain, then they would ordinarily 361 originate the same link-state information into BGP-LS. R1 may 362 also originate information from sources other than IGP, e.g. its 363 local node information. 365 * BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer 366 application/process and not a BGP Speaker. The BGP Speakers RR1 367 and Rn are handing off the BGP-LS information that they have 368 collected to a consumer application. The BGP protocol 369 implementation and the consumer application may be on the same or 370 different nodes. This document only covers the BGP 371 implementation. The consumer application and the design of the 372 interface between BGP and the consumer application may be 373 implementation specific and are outside the scope of this 374 document. The communication of information MUST be unidirectional 375 (i.e., from a BGP Speaker to the BGP-LS Consumer application) and 376 a BGP-LS Consumer MUST NOT be able to send information to a BGP 377 Speaker for origination into BGP-LS. 379 * BGP-LS Propagator: The term BGP-LS Propagator refers to a BGP 380 Speaker that is performing BGP protocol processing on the link- 381 state information. The BGP Speaker RRm propagates the BGP-LS 382 information between the BGP Speaker Rn and the BGP Speaker RR1. 383 The BGP implementation on RRm is propagating BGP-LS information. 384 It performs handling of BGP-LS UPDATE messages and performs the 385 BGP Decision Process as part of deciding what information is to be 386 propagated. Similarly, the BGP Speaker RR1 is receiving BGP-LS 387 information from R1, R2, and RRm and propagating the information 388 to the BGP-LS Consumer after performing BGP Decision Process. 390 The above roles are not mutually exclusive. The same BGP Speaker may 391 be the BGP-LS Producer for some link-state information and BGP-LS 392 Propagator for some other link-state information while also providing 393 this information to a BGP-LS Consumer. 395 The rest of this document refers to the role when describing 396 procedures that are specific to that role. When the role is not 397 specified, then the said procedure applies to all BGP Speakers. 399 4. Advertising IGP Information into BGP-LS 401 The origination and propagation of IGP link-state information via BGP 402 needs to provide a consistent and accurate view of the topology of 403 the IGP domain. BGP-LS provides an abstraction of the IGP specifics 404 and BGP-LS Consumers may be varied types of applications. 406 The link-state information advertised in BGP-LS from the IGPs is 407 derived from the IGP LSDB built using the OSPF Link State 408 Advertisements (LSAs) or the IS-IS Link State Packets (LSPs). 409 However, it does not serve as a verbatim reflection of the 410 originating router's LSDB. It does not include the LSA/LSP sequence 411 number information since a single link-state object may be put 412 together with information that is coming from multiple LSAs/LSPs. 413 Also, not all of the information carried in LSAs/LSPs may be required 414 or suitable for advertisement via BGP-LS (e.g., ASBR reachability in 415 OSPF, OSPF virtual links, link-local scoped information, etc.). The 416 LSAs/LSPs that are purged or max-aged are not included in the BGP-LS 417 advertisement even though they may be present in the LSDB (e.g., for 418 the IGP flooding purposes). The information from the LSAs/LSPs that 419 is invalid or malformed or that which needs to be ignored per the 420 respective IGP protocol specifications are also not included in the 421 BGP-LS advertisement. 423 The details of the interface between IGPs and BGP for the 424 advertisement of link-state information are outside the scope of this 425 document. In some cases, the information derived from IGP processing 426 (e.g., combination of link-state object from across multiple LSAs/ 427 LSPs, leveraging reachability and two-way connectivity checks, etc.) 428 is required for advertisement of link-state information into BGP-LS. 430 5. Carrying Link-State Information in BGP 432 The link-state information is carried in BGP UPDATE messages as: (1) 433 BGP NLRI information carried within MP_REACH_NLRI and MP_UNREACH_NLRI 434 attributes that describes link, node, or prefix object, and (2) a BGP 435 path attribute (BGP-LS Attribute) that carries properties of the 436 link, node, or prefix objects such as the link and prefix metric or 437 auxiliary Router-IDs of nodes, etc. 439 It is desirable to keep the dependencies on the protocol source of 440 this attribute to a minimum and represent any content in an IGP- 441 neutral way, such that applications that want to learn about a link- 442 state topology do not need to know about any OSPF or IS-IS protocol 443 specifics. 445 This section mainly describes the procedures for a BGP-LS Producer to 446 originate link-state information into BGP-LS. 448 5.1. TLV Format 450 Information in the Link-State NLRIs and the BGP-LS Attribute is 451 encoded in Type/Length/Value triplets. The TLV format is shown in 452 Figure 4 and applies to both the NLRI and the BGP-LS Attribute 453 encodings. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 // Value (variable) // 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 4: TLV Format 465 The Length field defines the length of the value portion in octets 466 (thus, a TLV with no value portion would have a length of zero). The 467 TLV is not padded to 4-octet alignment. Unknown and unsupported 468 types MUST be preserved and propagated within both the NLRI and the 469 BGP-LS Attribute. The presence of unknown or unexpected TLVs MUST 470 NOT result in the NLRI or the BGP-LS Attribute being considered 471 malformed. An example of an unexpected TLV is when a TLV is received 472 along with an update for a link state object other than the one that 473 the TLV is specified as associated with. 475 To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be 476 ordered in ascending order by TLV Type. If there are multiple TLVs 477 of the same type within a single NLRI, then the TLVs sharing the same 478 type MUST be first in ascending order based on the length field 479 followed by ascending order based on the value field. Comparison of 480 the value fields is performed by treating the entire field as opaque 481 binary data and ordered lexicographically (i.e., treating each byte 482 of binary data as a symbol to compare, with the symbols ordered by 483 their numerical value). NLRIs having TLVs which do not follow the 484 above ordering rules MUST be considered as malformed by a BGP-LS 485 Propagator. This insistence on canonical ordering ensures that 486 multiple variant copies of the same NLRI from multiple BGP-LS 487 Producers and the ambiguity arising therefrom is prevented. 489 For both the NLRI and BGP-LS Attribute parts, all TLVs are considered 490 as optional except where explicitly specified as mandatory or 491 required in specific conditions. 493 The TLVs within the BGP-LS Attribute SHOULD be ordered in ascending 494 order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be 495 considered malformed. 497 The origination of the same link-state information by multiple BGP-LS 498 Producers may result in differences and inconsistencies due to the 499 inclusion or exclusion of optional TLVs. Different optional TLVs in 500 the NLRI results in multiple NLRIs being generated for the same link- 501 state object. Different optional TLVs in the BGP-LS Attribute may 502 result in the propagation of partial information. To address these 503 inconsistencies, the BGP-LS Consumer will need to recognize and merge 504 the duplicate information, or to deal with missing information. The 505 deployment of BGP-LS Producers that consistently originate the same 506 set of optional TLVs is recommended to mitigate such situations. 508 5.2. The Link-State NLRI 510 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 511 for carrying opaque information. This specification defines three 512 Link-State NLRI types that describe either a node, a link, or a 513 prefix. 515 All non-VPN link, node, and prefix information SHALL be encoded using 516 AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be 517 encoded using AFI 16388 / SAFI 72. 519 For two BGP speakers to exchange Link-State NLRI, they MUST use BGP 520 Capabilities Advertisement to ensure that they are both capable of 521 properly processing such NLRI. This is done as specified in 522 [RFC4760], by using capability code 1 (multiprotocol BGP), with AFI 523 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN. 525 New Link-State NLRI Types may be introduced in the future. Since 526 supported NLRI type values within the address family are not 527 expressed in the Multiprotocol BGP (MP-BGP) capability [RFC4760], it 528 is possible that a BGP speaker has advertised support for BGP-LS but 529 does not support a particular Link-State NLRI type. To allow the 530 introduction of new Link-State NLRI types seamlessly in the future, 531 without the need for upgrading all BGP speakers in the propagation 532 path (e.g., a route reflector), this document deviates from the 533 default handling behavior specified by section 5.4 (paragraph 2) of 534 [RFC7606] for Link-State address-family. An implementation MUST 535 handle unknown Link-State NLRI types as opaque objects and MUST 536 preserve and propagate them. 538 The format of the Link-State NLRI is shown in the following figures. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | NLRI Type | Total NLRI Length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 // Link-State NLRI (variable) // 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | NLRI Type | Total NLRI Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | 558 + Route Distinguisher (8 octets) + 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 // Link-State NLRI (variable) // 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format 568 The Total NLRI Length field contains the cumulative length, in 569 octets, of the rest of the NLRI, not including the NLRI Type field or 570 itself. For VPN applications, it also includes the length of the 571 Route Distinguisher. 573 +======+===========================+ 574 | Type | NLRI Type | 575 +======+===========================+ 576 | 1 | Node NLRI | 577 +------+---------------------------+ 578 | 2 | Link NLRI | 579 +------+---------------------------+ 580 | 3 | IPv4 Topology Prefix NLRI | 581 +------+---------------------------+ 582 | 4 | IPv6 Topology Prefix NLRI | 583 +------+---------------------------+ 585 Table 1: NLRI Types 587 Route Distinguishers are defined and discussed in [RFC4364]. 589 The Node NLRI (NLRI Type = 1) is shown in the following figure. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+ 594 | Protocol-ID | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Identifier | 597 + (8 octets) + 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 // Local Node Descriptors TLV (variable) // 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 7: The Node NLRI Format 605 The Link NLRI (NLRI Type = 2) is shown in the following figure. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+ 610 | Protocol-ID | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Identifier | 613 + (8 octets) + 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 // Local Node Descriptors TLV (variable) // 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 // Remote Node Descriptors TLV (variable) // 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 // Link Descriptors TLVs (variable) // 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 8: The Link NLRI Format 625 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 626 same format, as shown in the following figure. 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+ 631 | Protocol-ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Identifier | 634 + (8 octets) + 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 // Local Node Descriptors TLV (variable) // 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 // Prefix Descriptors TLVs (variable) // 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format 644 The Protocol-ID field can contain one of the following values: 646 +=============+==================================+ 647 | Protocol-ID | NLRI information source protocol | 648 +=============+==================================+ 649 | 1 | IS-IS Level 1 | 650 +-------------+----------------------------------+ 651 | 2 | IS-IS Level 2 | 652 +-------------+----------------------------------+ 653 | 3 | OSPFv2 | 654 +-------------+----------------------------------+ 655 | 4 | Direct | 656 +-------------+----------------------------------+ 657 | 5 | Static configuration | 658 +-------------+----------------------------------+ 659 | 6 | OSPFv3 | 660 +-------------+----------------------------------+ 662 Table 2: Protocol Identifiers 664 The 'Direct' and 'Static configuration' protocol types SHOULD be used 665 when BGP-LS is sourcing local information. For all information 666 derived from other protocols, the corresponding Protocol-ID MUST be 667 used. If BGP-LS has direct access to interface information and wants 668 to advertise a local link, then the Protocol-ID 'Direct' SHOULD be 669 used. For modeling virtual links, such as described in Section 6, 670 the Protocol-ID 'Static configuration' SHOULD be used. 672 A router may run multiple protocol instances of OSPF or IS-IS whereby 673 it becomes a border router between multiple IGP domains. Both OSPF 674 and IS-IS may also run multiple routing protocol instances over the 675 same link. See [RFC8202] and [RFC6549]. These instances define 676 independent IGP routing domains. The Identifier field carries an 677 8-octet BGP-LS Instance Identifier (Instance-ID) number that is used 678 to identify the IGP routing domain where the NLRI belongs. The NLRIs 679 representing link-state objects (nodes, links, or prefixes) from the 680 same IGP routing instance should have the same BGP-LS Instance-ID. 681 NLRIs with different BGP-LS Instance-IDs are considered to be from 682 different IGP routing instances. 684 To support multiple IGP instances, an implementation needs to support 685 the configuration of unique BGP-LS Instance-IDs at the routing 686 protocol instance level. The BGP-LS Instance-ID 0 is RECOMMENDED to 687 be used when there is only a single protocol instance in the network 688 where BGP-LS is operational. The network operator MUST assign the 689 same BGP-LS Instance-IDs on all BGP-LS Producers within a given IGP 690 domain. Unique BGP-LS Instance-ID MUST be assigned to routing 691 protocol instances operating in different IGP domains. This can 692 allow the BGP-LS Consumer to build an accurate segregated multi- 693 domain topology based on the BGP-LS Instance-ID. 695 When the above-described semantics and recommendations are not 696 followed, a BGP-LS Consumer may see more than one link-state objects 697 for the same node, link, or prefix (each with a different BGP-LS 698 Instance-ID) when there are multiple BGP-LS Producers deployed. This 699 may also result in the BGP-LS Consumers getting an inaccurate 700 network-wide topology. 702 Each Node Descriptor, Link Descriptor, and Prefix Descriptor consists 703 of one or more TLVs, as described in the following sections. These 704 Descriptor TLVs are applicable for the Node, Link, and Prefix NLRI 705 Types for the protocols that are listed in Table 2. Documents 706 extending BGP-LS specifications with new NLRI Types and/or protocols 707 MUST specify the NLRI Descriptors for them. 709 When adding, removing, or modifying a TLV/sub-TLV from a Link-State 710 NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it 711 in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in- 712 consistent link-state objects hanging around in the BGP-LS table. 714 5.2.1. Node Descriptors 716 Each link is anchored by a pair of Router-IDs that are used by the 717 underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit 718 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 719 additional auxiliary Router-IDs, mainly for Traffic Engineering 720 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 721 Router-IDs [RFC5305] [RFC6119]. When configured, these auxiliary TE 722 Router-IDs (TLV 1028/1029) MUST be included in the node attribute 723 described in Section 5.3.1 and MAY be included in the link attribute 724 described in Section 5.3.2. The advertisement of the TE Router-IDs 725 can help a BGP-LS Consumer to correlate multiple link-state objects 726 (e.g. in different IGP instances or areas/levels) to the same node in 727 the network. 729 It is desirable that the Router-ID assignments inside the Node 730 Descriptors are globally unique. However, there may be Router-ID 731 spaces (e.g., ISO) where no global registry exists, or worse, Router- 732 IDs have been allocated following the private-IP allocation described 733 in [RFC1918]. BGP-LS uses the Autonomous System (AS) Number to 734 disambiguate the Router-IDs, as described in Section 5.2.1.1. 736 5.2.1.1. Globally Unique Node/Link/Prefix Identifiers 738 One problem that needs to be addressed is the ability to identify an 739 IGP node globally (by "globally", we mean within the BGP-LS database 740 collected by all BGP-LS speakers that talk to each other). This can 741 be expressed through the following two requirements: 743 (A) The same node MUST NOT be represented by two keys (otherwise, 744 one node will look like two nodes). 746 (B) Two different nodes MUST NOT be represented by the same key 747 (otherwise, two nodes will look like one node). 749 We define an "IGP domain" to be the set of nodes (hence, by extension 750 links and prefixes) within which each node has a unique IGP 751 representation by using the combination of OSPF Area-ID, Router-ID, 752 Protocol-ID, Multi-Topology ID, and BGP-LS Instance-ID. The problem 753 is that BGP may receive node/link/prefix information from multiple 754 independent "IGP domains", and we need to distinguish between them. 755 Moreover, we can't assume there is always one and only one IGP domain 756 per AS. During IGP transitions, it may happen that two redundant 757 IGPs are in place. 759 Furthermore, in deployments where BGP-LS is used to advertise 760 topology from multiple-ASes, the AS Number is used to distinguish 761 topology information reported from different ASes. 763 The BGP-LS Instance-ID carried in the Identifier field as described 764 earlier along with a set of sub-TLVs described in Section 5.2.1.4, 765 allows specification of a flexible key for any given node/link 766 information such that the global uniqueness of the NLRI is ensured. 767 Since the BGP-LS Instance-ID is operator assigned, its allocation 768 scheme can ensure that each IGP domain is uniquely identified even 769 across a multi-AS network. 771 5.2.1.2. Local Node Descriptors 773 The Local Node Descriptors TLV contains Node Descriptors for the node 774 anchoring the local end of the link. This is a mandatory TLV in all 775 three types of NLRIs (node, link, and prefix). The Type is 256. The 776 length of this TLV is variable. The value contains one or more Node 777 Descriptor Sub-TLVs defined in Section 5.2.1.4. 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type | Length | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 // Node Descriptor Sub-TLVs (variable) // 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Figure 10: Local Node Descriptors TLV Format 791 5.2.1.3. Remote Node Descriptors 793 The Remote Node Descriptors TLV contains Node Descriptors for the 794 node anchoring the remote end of the link. This is a mandatory TLV 795 for Link NLRIs. The type is 257. The length of this TLV is 796 variable. The value contains one or more Node Descriptor Sub-TLVs 797 defined in Section 5.2.1.4. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Type | Length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | | 805 // Node Descriptor Sub-TLVs (variable) // 806 | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 11: Remote Node Descriptors TLV Format 811 5.2.1.4. Node Descriptor Sub-TLVs 813 The Node Descriptor Sub-TLV type code points and lengths are listed 814 in the following table: 816 +====================+================================+==========+ 817 | Sub-TLV Code Point | Description | Length | 818 +====================+================================+==========+ 819 | 512 | Autonomous System | 4 | 820 +--------------------+--------------------------------+----------+ 821 | 513 | BGP-LS Identifier (deprecated) | 4 | 822 +--------------------+--------------------------------+----------+ 823 | 514 | OSPF Area-ID | 4 | 824 +--------------------+--------------------------------+----------+ 825 | 515 | IGP Router-ID | Variable | 826 +--------------------+--------------------------------+----------+ 828 Table 3: Node Descriptor Sub-TLVs 830 The sub-TLV values in Node Descriptor TLVs are defined as follows: 832 Autonomous System: Opaque value (32-bit AS Number). This is an 833 optional TLV. The value SHOULD be set to the AS Number associated 834 with the BGP process originating the link-state information. An 835 implementation MAY provide a configuration option on the BGP-LS 836 Producer to use a different value; e.g., to avoid collisions when 837 using private AS numbers. 839 BGP-LS Identifier: Opaque value (32-bit ID). This is an optional 840 TLV which has been deprecated by this document (refer to 841 Appendix A for more details). It MAY be advertised for 842 compatibility with [RFC7752] implementations. See the final 843 paragraph of this section for further considerations and 844 recommended default value. 846 OSPF Area-ID: Used to identify the 32-bit area to which the 847 information advertised in the NLRI belongs. This is a mandatory 848 TLV when originating information from OSPF that is derived from 849 area-scope LSAs. The OSPF Area Identifier allows different NLRIs 850 of the same router to be differentiated on a per-area basis. It 851 is not used for NLRIs when carrying information that is derived 852 from AS-scope LSAs as that information is not associated with a 853 specific area. 855 IGP Router-ID: Opaque value. This is a mandatory TLV when 856 originating information from IS-IS, OSPF, direct or static. For 857 an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO 858 system-ID). For an IS-IS pseudonode corresponding to a LAN, this 859 contains the 6-octet ISO Node-ID of the Designated Intermediate 860 System (DIS) followed by a 1-octet, nonzero PSN identifier (7 861 octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this 862 contains the 4-octet Router-ID. For an OSPFv2 pseudonode 863 representing a LAN, this contains the 4-octet Router-ID of the 864 Designated Router (DR) followed by the 4-octet IPv4 address of the 865 DR's interface to the LAN (8 octets in total). Similarly, for an 866 OSPFv3 pseudonode, this contains the 4-octet Router-ID of the DR 867 followed by the 4-octet interface identifier of the DR's interface 868 to the LAN (8 octets in total). The TLV size in combination with 869 the protocol identifier enables the decoder to determine the type 870 of the node. For Direct or Static configuration, the value SHOULD 871 be taken from an IPv4 or IPv6 address (e.g. loopback interface) 872 configured on the node. When the node is running an IGP protocol, 873 an implementation MAY choose to use the IGP Router-ID for direct 874 or static. 876 There MUST be at most one instance of each sub-TLV type present in 877 any Node Descriptor. The sub-TLVs within a Node Descriptor MUST be 878 arranged in ascending order by sub-TLV type. This needs to be done 879 to compare NLRIs, even when an implementation encounters an unknown 880 sub-TLV. Using stable sorting, an implementation can do a binary 881 comparison of NLRIs and hence allow incremental deployment of new key 882 sub-TLVs. 884 The BGP-LS Identifier was introduced by [RFC7752] and its use is 885 being deprecated by this document. Implementations SHOULD support 886 the advertisement of this sub-TLV for backward compatibility in 887 deployments where there are BGP-LS Producer implementations that 888 conform to [RFC7752] to ensure consistency of NLRI encoding for link- 889 state objects. The default value of 0 is RECOMMENDED to be used when 890 a BGP-LS Producer includes this sub-TLV when originating information 891 into BGP-LS. Implementations SHOULD provide an option to configure 892 this value for backward compatibility reasons. As a reminder, the 893 use of the BGP-LS Instance-ID that is carried in the Identifier field 894 is the way of segregation of link-state objects of different IGP 895 domains in BGP-LS. 897 5.2.2. Link Descriptors 899 The Link Descriptor field is a set of Type/Length/Value (TLV) 900 triplets. The format of each TLV is shown in Section 5.1. The Link 901 Descriptor TLVs uniquely identify a link among multiple parallel 902 links between a pair of anchor routers. A link described by the Link 903 Descriptor TLVs actually is a "half-link", a unidirectional 904 representation of a logical link. To fully describe a single logical 905 link, two anchor routers advertise a half-link each, i.e., two Link 906 NLRIs are advertised for a given point-to-point link. 908 A link between two nodes is not considered as complete (or available) 909 unless it is described by the two Link NLRIs corresponding to the 910 half-link representation from the pair of anchor nodes. This check 911 is similar to the 'two-way connectivity check' that is performed by 912 link-state IGPs. 914 An implementation MAY suppress the advertisement of a Link NLRI, 915 corresponding to a half-link, from a link-state IGP unless the IGP 916 has verified that the link is being reported in the IS-IS LSP or OSPF 917 Router LSA by both the nodes connected by that link. This 'two-way 918 connectivity check' is performed by link-state IGPs during their 919 computation and can be leveraged before passing information for any 920 half-link that is reported from these IGPs into BGP-LS. This ensures 921 that only those Link State IGP adjacencies which are established get 922 reported via Link NLRIs. Such a 'two-way connectivity check' could 923 be also required in certain cases (e.g., with OSPF) to obtain the 924 proper link identifiers of the remote node. 926 The format and semantics of the Value fields in most Link Descriptor 927 TLVs correspond to the format and semantics of value fields in IS-IS 928 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], 929 and [RFC6119]. Although the encodings for Link Descriptor TLVs were 930 originally defined for IS-IS, the TLVs can carry data sourced by 931 either IS-IS or OSPF. 933 The following TLVs are defined as Link Descriptors in the Link NLRI: 935 +================+===================+============+===============+ 936 | TLV Code Point | Description | IS-IS TLV/ | Reference | 937 | | | Sub-TLV | (RFC/Section) | 938 +================+===================+============+===============+ 939 | 258 | Link Local/Remote | 22/4 | [RFC5307] / | 940 | | Identifiers | | 1.1 | 941 +----------------+-------------------+------------+---------------+ 942 | 259 | IPv4 interface | 22/6 | [RFC5305] / | 943 | | address | | 3.2 | 944 +----------------+-------------------+------------+---------------+ 945 | 260 | IPv4 neighbor | 22/8 | [RFC5305] / | 946 | | address | | 3.3 | 947 +----------------+-------------------+------------+---------------+ 948 | 261 | IPv6 interface | 22/12 | [RFC6119] / | 949 | | address | | 4.2 | 950 +----------------+-------------------+------------+---------------+ 951 | 262 | IPv6 neighbor | 22/13 | [RFC6119] / | 952 | | address | | 4.3 | 953 +----------------+-------------------+------------+---------------+ 954 | 263 | Multi-Topology | --- | Section | 955 | | Identifier | | 5.2.2.1 | 956 +----------------+-------------------+------------+---------------+ 958 Table 4: Link Descriptor TLVs 960 The information about a link present in the LSA/LSP originated by the 961 local node of the link determines the set of TLVs in the Link 962 Descriptor of the link. 964 If interface and neighbor addresses, either IPv4 or IPv6, are 965 present, then the interface/neighbor address TLVs MUST be 966 included, and the Link Local/Remote Identifiers TLV MUST NOT be 967 included in the Link Descriptor. The Link Local/Remote 968 Identifiers TLV MAY be included in the link attribute when 969 available. IPv4/IPv6 link-local addresses MUST NOT be carried in 970 the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262) as 971 descriptors of a link as they are not considered unique. 973 If interface and neighbor addresses are not present and the link 974 local/remote identifiers are present, then the Link Local/Remote 975 Identifiers TLV MUST be included in the Link Descriptor. The Link 976 Local/Remote Identifiers MUST be included in the Link Descriptor 977 also in the case of links having only IPv6 link-local addressing 978 on them. 980 The Multi-Topology Identifier TLV MUST be included as a Link 981 Descriptor if the underlying IGP link object is associated with a 982 non-default topology. 984 The TLVs/sub-TLVs corresponding to the interface addresses and/or the 985 local/remote identifiers may not always be signaled in the IGPs 986 unless their advertisement is enabled specifically. In such cases, 987 it is valid to advertise a BGP-LS Link NLRI without any of these 988 identifiers. 990 5.2.2.1. Multi-Topology ID 992 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 993 Multi-Topology IDs for a link, node, or prefix. 995 The semantics of the IS-IS MT-ID are defined in sections 7.1 and 7.2 996 of [RFC5120]. The semantics of the OSPF MT-ID are defined in section 997 3.7 of [RFC4915]. If the value in the MT-ID TLV is derived from 998 OSPF, then the upper R bits of the MT-ID field MUST be set to 0 and 999 only the values from 0 to 127 are valid for the MT-ID. 1001 The format of the MT-ID TLV is shown in the following figure. 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Type | Length=2*n | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |R R R R| Multi-Topology ID 1 | .... // 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 // .... |R R R R| Multi-Topology ID n | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 Figure 12: Multi-Topology ID TLV Format 1015 where Type is 263, Length is 2*n, and n is the number of MT-IDs 1016 carried in the TLV. 1018 The MT-ID TLV MAY be included as a Link Descriptor, a Prefix 1019 Descriptor, or in the BGP-LS Attribute of a Node NLRI. When included 1020 as a Link or Prefix Descriptor, only a single MT-ID TLV containing 1021 the MT-ID of the topology where the link or the prefix is reachable 1022 is allowed. In case one wants to advertise multiple topologies for a 1023 given Link Descriptor or Prefix Descriptor, multiple NLRIs MUST be 1024 generated where each NLRI contains a single unique MT-ID. When used 1025 as a Link or Prefix Descriptor for IS-IS, the Bits R are reserved and 1026 MUST be set to 0 (as per section 7.2 of [RFC5120]) when originated 1027 and ignored on receipt. 1029 In the BGP-LS Attribute of a Node NLRI, one MT-ID TLV containing the 1030 array of MT-IDs of all topologies where the node is reachable is 1031 allowed. When used in the Node Attribute TLV for IS-IS, the Bits R 1032 are set as per section 7.1 of [RFC5120]. 1034 5.2.3. Prefix Descriptors 1036 The Prefix Descriptor field is a set of Type/Length/Value (TLV) 1037 triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 1038 prefix originated by a node. The following TLVs are defined as 1039 Prefix Descriptors in the IPv4/IPv6 Prefix NLRI: 1041 +================+=================+==========+===============+ 1042 | TLV Code Point | Description | Length | Reference | 1043 | | | | (RFC/Section) | 1044 +================+=================+==========+===============+ 1045 | 263 | Multi-Topology | variable | Section | 1046 | | Identifier | | 5.2.2.1 | 1047 +----------------+-----------------+----------+---------------+ 1048 | 264 | OSPF Route Type | 1 | Section | 1049 | | | | 5.2.3.1 | 1050 +----------------+-----------------+----------+---------------+ 1051 | 265 | IP Reachability | variable | Section | 1052 | | Information | | 5.2.3.2 | 1053 +----------------+-----------------+----------+---------------+ 1055 Table 5: Prefix Descriptor TLVs 1057 The Multi-Topology Identifier TLV MUST be included in the Prefix 1058 Descriptor if the underlying IGP prefix object is associated with a 1059 non-default topology. 1061 5.2.3.1. OSPF Route Type 1063 The OSPF Route Type TLV is an optional TLV corresponding to Prefix 1064 NLRIs originated from OSPF. It is used to identify the OSPF route 1065 type of the prefix. An OSPF prefix MAY be advertised in the OSPF 1066 domain with multiple route types. The Route Type TLV allows the 1067 discrimination of these advertisements. The OSPF Route Type TLV MUST 1068 be included in the advertisement when the type is either being 1069 signaled explicitly in the underlying LSA or can be determined via 1070 another LSA for the same prefix when it is not signaled explicitly 1071 (e.g., in the case of OSPFv2 Extended Prefix Opaque LSA [RFC7684]). 1072 The route type advertised in the OSPFv2 Extended Prefix TLV (section 1073 2.1 of [RFC7684]) does not make a distinction between Type 1 and 2 1074 for AS external and NSSA external routes. In this case, the route 1075 type to be used in the BGP-LS advertisement can be determined by 1076 checking the OSPFv2 External or NSSA External LSA for the prefix. A 1077 similar check for the base OSPFv2 LSAs can be done to determine the 1078 route type to be used when the route type value 0 is carried in the 1079 OSPFv2 Extended Prefix TLV. 1081 The format of the OSPF Route Type TLV is shown in the following 1082 figure. 1084 0 1 2 3 1085 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 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Type | Length | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Route Type | 1090 +-+-+-+-+-+-+-+-+ 1092 Figure 13: OSPF Route Type TLV Format 1094 where the Type and Length fields of the TLV are defined in Table 5. 1095 The OSPF Route Type field follows the route types defined in the OSPF 1096 protocol and can be one of the following: 1098 * Intra-Area (0x1) 1100 * Inter-Area (0x2) 1102 * External 1 (0x3) 1104 * External 2 (0x4) 1106 * NSSA 1 (0x5) 1108 * NSSA 2 (0x6) 1110 5.2.3.2. IP Reachability Information 1112 The IP Reachability Information TLV is a mandatory TLV for IPv4 & 1113 IPv6 Prefix NLRI types. The TLV contains one IP address prefix (IPv4 1114 or IPv6) originally advertised in the IGP topology. A router SHOULD 1115 advertise an IP Prefix NLRI for each of its BGP next-hops. The 1116 format of the IP Reachability Information TLV is shown in the 1117 following figure: 1119 0 1 2 3 1120 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 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Type | Length | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Prefix Length | IP Prefix (variable) // 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 14: IP Reachability Information TLV Format 1129 The Type and Length fields of the TLV are defined in Table 5. The 1130 following two fields determine the reachability information of the 1131 address family. The Prefix Length field contains the length of the 1132 prefix in bits. The IP Prefix field contains an IP address prefix, 1133 followed by the minimum number of trailing bits needed to make the 1134 end of the field fall on an octet boundary. Any trailing bits MUST 1135 be set to 0. Thus, the IP Prefix field contains the most significant 1136 octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 1137 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 1138 24, 4 octets for prefix length 25 up to 32, etc. 1140 5.3. The BGP-LS Attribute 1142 The BGP-LS Attribute (assigned value 29 by IANA) is an optional, non- 1143 transitive BGP attribute that is used to carry link, node, and prefix 1144 parameters and attributes. It is defined as a set of Type/Length/ 1145 Value (TLV) triplets, described in the following section. This 1146 attribute SHOULD only be included with Link-State NLRIs. This 1147 attribute MUST be ignored for all other address families. 1149 The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute 1150 TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute 1151 associated with a Node NLRI, Link NLRI, and Prefix NLRI respectively. 1153 The size of the BGP-LS Attribute may potentially grow large depending 1154 on the amount of link-state information associated with a single 1155 Link-State NLRI. The BGP specification [RFC4271] mandates a maximum 1156 BGP message size of 4096 octets. It is RECOMMENDED that an 1157 implementation supports [RFC8654] to accommodate a larger size of 1158 information within the BGP-LS Attribute. BGP-LS Producers MUST 1159 ensure that the TLVs included in the BGP-LS Attribute does not result 1160 in a BGP UPDATE message for a single Link-State NLRI that crosses the 1161 maximum limit for a BGP message. 1163 An implementation MAY adopt mechanisms to avoid this problem that may 1164 be based the BGP-LS Consumer applications' requirement; these 1165 mechanisms are beyond the scope of this specification. However, if 1166 an implementation chooses to mitigate the problem by excluding some 1167 TLVs from the BGP-LS Attribute, this exclusion SHOULD be done 1168 consistently by all BGP-LS Producers within a given BGP-LS domain. 1169 In the event of inconsistent exclusion of TLVs from the BGP-LS 1170 Attribute, the result would be a differing set of attributes of the 1171 link-state object being propagated to BGP-LS Consumers based on the 1172 BGP decision process at BGP-LS Propagators. 1174 When a BGP-LS Propagator finds that it is exceeding the maximum BGP 1175 message size due to the addition or update of some other BGP 1176 Attribute (e.g. AS_PATH), it MUST consider the BGP-LS Attribute to 1177 be malformed, apply the "Attribute Discard" error-handling approach 1178 [RFC7606], and handle the propagation as described in Section 8.2.2. 1179 When a BGP-LS Propagator needs to perform "Attribute Discard" for 1180 reducing the BGP UPDATE message size as specified in section 4 of 1181 [RFC8654], it MUST first discard the BGP-LS Attribute to enable the 1182 detection and diagnosis of this error condition as discussed in 1183 Section 8.2.2. This brings the deployment consideration that the 1184 consistent propagation of BGP-LS information with a BGP UPDATE 1185 message size larger than 4096 octets can only happen along a set of 1186 BGP Speakers that all support [RFC8654]. 1188 5.3.1. Node Attribute TLVs 1190 The following Node Attribute TLVs are defined for the BGP-LS 1191 Attribute associated with a Node NLRI: 1193 +================+================+==========+===============+ 1194 | TLV Code Point | Description | Length | Reference | 1195 | | | | (RFC/Section) | 1196 +================+================+==========+===============+ 1197 | 263 | Multi-Topology | variable | Section | 1198 | | Identifier | | 5.2.2.1 | 1199 +----------------+----------------+----------+---------------+ 1200 | 1024 | Node Flag Bits | 1 | Section | 1201 | | | | 5.3.1.1 | 1202 +----------------+----------------+----------+---------------+ 1203 | 1025 | Opaque Node | variable | Section | 1204 | | Attribute | | 5.3.1.5 | 1205 +----------------+----------------+----------+---------------+ 1206 | 1026 | Node Name | variable | Section | 1207 | | | | 5.3.1.3 | 1208 +----------------+----------------+----------+---------------+ 1209 | 1027 | IS-IS Area | variable | Section | 1210 | | Identifier | | 5.3.1.2 | 1211 +----------------+----------------+----------+---------------+ 1212 | 1028 | IPv4 Router-ID | 4 | [RFC5305] / | 1213 | | of Local Node | | 4.3 | 1214 +----------------+----------------+----------+---------------+ 1215 | 1029 | IPv6 Router-ID | 16 | [RFC6119] / | 1216 | | of Local Node | | 4.1 | 1217 +----------------+----------------+----------+---------------+ 1219 Table 6: Node Attribute TLVs 1221 5.3.1.1. Node Flag Bits TLV 1223 The Node Flag Bits TLV carries a bitmask describing node attributes. 1224 The value is a 1 octet length bit array of flags, where each bit 1225 represents a node operational state or attribute. 1227 0 1 2 3 1228 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 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Type | Length | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 |O|T|E|B|R|V| | 1233 +-+-+-+-+-+-+-+-+ 1235 Figure 15: Node Flag Bits TLV Format 1237 The bits are defined as follows: 1239 +=====+==============+============+ 1240 | Bit | Description | Reference | 1241 +=====+==============+============+ 1242 | 'O' | Overload Bit | [ISO10589] | 1243 +-----+--------------+------------+ 1244 | 'T' | Attached Bit | [ISO10589] | 1245 +-----+--------------+------------+ 1246 | 'E' | External Bit | [RFC2328] | 1247 +-----+--------------+------------+ 1248 | 'B' | ABR Bit | [RFC2328] | 1249 +-----+--------------+------------+ 1250 | 'R' | Router Bit | [RFC5340] | 1251 +-----+--------------+------------+ 1252 | 'V' | V6 Bit | [RFC5340] | 1253 +-----+--------------+------------+ 1255 Table 7: Node Flag Bits Definitions 1257 The bits that are not defined MUST be set to 0 by the originator and 1258 MUST be ignored by the receiver. 1260 5.3.1.2. IS-IS Area Identifier TLV 1262 An IS-IS node can be part of only a single IS-IS area. However, a 1263 node can have multiple synonymous area addresses. Each of these area 1264 addresses is carried in the IS-IS Area Identifier TLV. If multiple 1265 area addresses are present, multiple TLVs are used to encode them. 1266 The IS-IS Area Identifier TLV may be present in the BGP-LS Attribute 1267 only when advertised in the Link-State Node NLRI. 1269 0 1 2 3 1270 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 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Type | Length | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 // IS-IS Area Identifier (variable) // 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 Figure 16: IS-IS Area Identifier TLV Format 1279 5.3.1.3. Node Name TLV 1281 The Node Name TLV is optional. The encoding semantics for the node 1282 name has been borrowed from [RFC5301]. The Value field identifies 1283 the symbolic name of the router node. This symbolic name can either 1284 be the Fully Qualified Domain Name (FQDN) for the router, or it can 1285 be a substring of the FQDN (e.g., a hostname), or it can be any 1286 string that an operator wants to use for the router. The use of FQDN 1287 or a substring of it is strongly RECOMMENDED. The maximum length of 1288 the Node Name TLV is 255 octets. 1290 The Value field is encoded in 7-bit ASCII. If a user interface for 1291 configuring or displaying this field permits Unicode characters, that 1292 the user interface is responsible for applying the ToASCII and/or 1293 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1294 format for transmission or display. 1296 [RFC5301] describes an IS-IS-specific extension and [RFC5642] 1297 describes an OSPF extension for the advertisement of Node Name which 1298 may be encoded in the Node Name TLV. 1300 0 1 2 3 1301 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 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Type | Length | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 // Node Name (variable) // 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 Figure 17: Node Name Format 1310 5.3.1.4. Local IPv4/IPv6 Router-ID TLVs 1312 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 1313 Router-IDs that the IGP might be using, e.g., for TE and migration 1314 purposes such as correlating a Node-ID between different protocols. 1315 If there is more than one auxiliary Router-ID of a given type, then 1316 each one is encoded as a separate TLV. 1318 5.3.1.5. Opaque Node Attribute TLV 1320 The Opaque Node Attribute TLV is an envelope that transparently 1321 carries optional Node Attribute TLVs advertised by a router. An 1322 originating router shall use this TLV for encoding information 1323 specific to the protocol advertised in the NLRI header Protocol-ID 1324 field or new protocol extensions to the protocol as advertised in the 1325 NLRI header Protocol-ID field for which there is no protocol-neutral 1326 representation in the BGP Link-State NLRI. The primary use of the 1327 Opaque Node Attribute TLV is to bridge the document lag between a new 1328 IGP link-state attribute and its protocol-neutral BGP-LS extension 1329 being defined. Once the protocol-neutral BGP-LS extensions are 1330 defined, the BGP-LS implementations may still need to advertise the 1331 information both within the Opaque Attribute TLV and the new TLV 1332 definition for incremental deployment and transition. 1334 In the case of OSPF, this TLV MUST NOT be used to advertise TLVs 1335 other than those in the OSPF Router Information (RI) LSA [RFC7770]. 1337 0 1 2 3 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Type | Length | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 // Opaque node attributes (variable) // 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 Figure 18: Opaque Node Attribute Format 1347 The type is as specified in Table 6. Length is variable. 1349 5.3.2. Link Attribute TLVs 1351 Link Attribute TLVs are TLVs that may be encoded in the BGP-LS 1352 Attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ 1353 Value (TLV) triplet formatted as defined in Section 5.1. The format 1354 and semantics of the Value fields in some Link Attribute TLVs 1355 correspond to the format and semantics of the Value fields in IS-IS 1356 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 1357 [RFC5307]. Other Link Attribute TLVs are defined in this document. 1358 Although the encodings for Link Attribute TLVs were originally 1359 defined for IS-IS, the TLVs can carry data sourced by either IS-IS or 1360 OSPF. 1362 The following Link Attribute TLVs are defined for the BGP-LS 1363 Attribute associated with a Link NLRI: 1365 +================+=================+============+===============+ 1366 | TLV Code Point | Description | IS-IS TLV/ | Reference | 1367 | | | Sub-TLV | (RFC/Section) | 1368 +================+=================+============+===============+ 1369 | 1028 | IPv4 Router-ID | 134/--- | [RFC5305] / | 1370 | | of Local Node | | 4.3 | 1371 +----------------+-----------------+------------+---------------+ 1372 | 1029 | IPv6 Router-ID | 140/--- | [RFC6119] / | 1373 | | of Local Node | | 4.1 | 1374 +----------------+-----------------+------------+---------------+ 1375 | 1030 | IPv4 Router-ID | 134/--- | [RFC5305] / | 1376 | | of Remote Node | | 4.3 | 1377 +----------------+-----------------+------------+---------------+ 1378 | 1031 | IPv6 Router-ID | 140/--- | [RFC6119] / | 1379 | | of Remote Node | | 4.1 | 1380 +----------------+-----------------+------------+---------------+ 1381 | 1088 | Administrative | 22/3 | [RFC5305] / | 1382 | | group (color) | | 3.1 | 1383 +----------------+-----------------+------------+---------------+ 1384 | 1089 | Maximum link | 22/9 | [RFC5305] / | 1385 | | bandwidth | | 3.4 | 1386 +----------------+-----------------+------------+---------------+ 1387 | 1090 | Max. reservable | 22/10 | [RFC5305] / | 1388 | | link bandwidth | | 3.5 | 1389 +----------------+-----------------+------------+---------------+ 1390 | 1091 | Unreserved | 22/11 | [RFC5305] / | 1391 | | bandwidth | | 3.6 | 1392 +----------------+-----------------+------------+---------------+ 1393 | 1092 | TE Default | 22/18 | Section | 1394 | | Metric | | 5.3.2.3 | 1395 +----------------+-----------------+------------+---------------+ 1396 | 1093 | Link Protection | 22/20 | [RFC5307] / | 1397 | | Type | | 1.2 | 1398 +----------------+-----------------+------------+---------------+ 1399 | 1094 | MPLS Protocol | --- | Section | 1400 | | Mask | | 5.3.2.2 | 1401 +----------------+-----------------+------------+---------------+ 1402 | 1095 | IGP Metric | --- | Section | 1403 | | | | 5.3.2.4 | 1404 +----------------+-----------------+------------+---------------+ 1405 | 1096 | Shared Risk | --- | Section | 1406 | | Link Group | | 5.3.2.5 | 1407 +----------------+-----------------+------------+---------------+ 1408 | 1097 | Opaque Link | --- | Section | 1409 | | Attribute | | 5.3.2.6 | 1410 +----------------+-----------------+------------+---------------+ 1411 | 1098 | Link Name | --- | Section | 1412 | | | | 5.3.2.7 | 1413 +----------------+-----------------+------------+---------------+ 1415 Table 8: Link Attribute TLVs 1417 5.3.2.1. IPv4/IPv6 Router-ID TLVs 1419 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1420 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1421 purposes. All auxiliary Router-IDs of both the local and the remote 1422 node MUST be included in the link attribute of each Link NLRI. If 1423 there is more than one auxiliary Router-ID of a given type, then 1424 multiple TLVs are used to encode them. 1426 5.3.2.2. MPLS Protocol Mask TLV 1428 The MPLS Protocol Mask TLV carries a bitmask describing which MPLS 1429 signaling protocols are enabled. The length of this TLV is 1. The 1430 value is a bit array of 8 flags, where each bit represents an MPLS 1431 Protocol capability. 1433 Generation of the MPLS Protocol Mask TLV is only valid for and SHOULD 1434 only be used with originators that have local link insight, for 1435 example, the Protocol-IDs 'Static configuration' or 'Direct' as per 1436 Table 2. The MPLS Protocol Mask TLV MUST NOT be included in NLRIs 1437 with the other Protocol-IDs listed in Table 2. 1439 0 1 2 3 1440 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 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Type | Length | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 |L|R| Reserved | 1445 +-+-+-+-+-+-+-+-+ 1447 Figure 19: MPLS Protocol Mask TLV 1449 The following bits are defined, and the reserved bits MUST be set to 1450 zero and SHOULD be ignored on receipt: 1452 +=====+=============================================+===========+ 1453 | Bit | Description | Reference | 1454 +=====+=============================================+===========+ 1455 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1456 +-----+---------------------------------------------+-----------+ 1457 | 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | 1458 +-----+---------------------------------------------+-----------+ 1460 Table 9: MPLS Protocol Mask TLV Codes 1462 The bits that are not defined MUST be set to 0 by the originator and 1463 MUST be ignored by the receiver. 1465 5.3.2.3. TE Default Metric TLV 1467 The TE Default Metric TLV carries the Traffic Engineering metric for 1468 this link. The length of this TLV is fixed at 4 octets. If a source 1469 protocol uses a metric width of fewer than 32 bits, then the high- 1470 order bits of this field MUST be padded with zero. 1472 0 1 2 3 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Type | Length | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | TE Default Link Metric | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 Figure 20: TE Default Metric TLV Format 1482 5.3.2.4. IGP Metric TLV 1484 The IGP Metric TLV carries the metric for this link. The length of 1485 this TLV is variable, depending on the metric width of the underlying 1486 protocol. IS-IS small metrics are of 6-bit size, but are encoded in 1487 a 1 octet field; therefore the two most significant bits of the field 1488 MUST be set to 0 by the originator and MUST be ignored by the 1489 receiver. OSPF link metrics have a length of 2 octets. IS-IS wide 1490 metrics have a length of 3 octets. 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Type | Length | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 // IGP Link Metric (variable length) // 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Figure 21: IGP Metric TLV Format 1502 5.3.2.5. Shared Risk Link Group TLV 1504 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1505 Group information (see Section 2.3 ("Shared Risk Link Group 1506 Information") of [RFC4202]). It contains a data structure consisting 1507 of a (variable) list of SRLG values, where each element in the list 1508 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1509 (number of SRLG values). 1511 0 1 2 3 1512 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 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Type | Length | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Shared Risk Link Group Value | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 // ............ // 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Shared Risk Link Group Value | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Figure 22: Shared Risk Link Group TLV Format 1525 The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS, the SRLG 1526 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1527 (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) 1528 defined in [RFC6119]. Both IPv4 and IPv6 SRLG information is carried 1529 in a single TLV. 1531 5.3.2.6. Opaque Link Attribute TLV 1533 The Opaque Link Attribute TLV is an envelope that transparently 1534 carries optional Link Attribute TLVs advertised by a router. An 1535 originating router shall use this TLV for encoding information 1536 specific to the protocol advertised in the NLRI header Protocol-ID 1537 field or new protocol extensions to the protocol as advertised in the 1538 NLRI header Protocol-ID field for which there is no protocol-neutral 1539 representation in the BGP Link-State NLRI. The primary use of the 1540 Opaque Link Attribute TLV is to bridge the document lag between a new 1541 IGP link-state attribute and its 'protocol-neutral' BGP-LS extension 1542 being defined. Once the protocol-neutral BGP-LS extensions are 1543 defined, the BGP-LS implementations may still need to advertise the 1544 information both within the Opaque Attribute TLV and the new TLV 1545 definition for incremental deployment and transition. 1547 In the case of OSPFv2, this TLV MUST NOT be used to advertise 1548 information carried using TLVs other than those in the OSPFv2 1549 Extended Link Opaque LSA [RFC7684]. In the case of OSPFv3, this TLV 1550 MUST NOT be used to advertise TLVs other than those in the OSPFv3 E- 1551 Router-LSA or E-Link-LSA [RFC8362]. 1553 0 1 2 3 1554 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 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Type | Length | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 // Opaque link attributes (variable) // 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 Figure 23: Opaque Link Attribute TLV Format 1563 5.3.2.7. Link Name TLV 1565 The Link Name TLV is optional. The Value field identifies the 1566 symbolic name of the router link. This symbolic name can either be 1567 the FQDN for the link, or it can be a substring of the FQDN, or it 1568 can be any string that an operator wants to use for the link. The 1569 use of FQDN or a substring of it is strongly RECOMMENDED. The 1570 maximum length of the Link Name TLV is 255 octets. 1572 The Value field is encoded in 7-bit ASCII. If a user interface for 1573 configuring or displaying this field permits Unicode characters, that 1574 the user interface is responsible for applying the ToASCII and/or 1575 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1576 format for transmission or display. 1578 How a router derives and injects link names is outside of the scope 1579 of this document. 1581 0 1 2 3 1582 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 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | Type | Length | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 // Link Name (variable) // 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 Figure 24: Link Name TLV Format 1591 5.3.3. Prefix Attribute TLVs 1593 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1594 of IGP attributes (such as metric, route tags, etc.) that are 1595 advertised in the BGP-LS Attribute with Prefix NLRI types 3 and 4. 1597 The following Prefix Attribute TLVs are defined for the BGP-LS 1598 Attribute associated with a Prefix NLRI: 1600 +================+=================+==========+=================+ 1601 | TLV Code Point | Description | Length | Reference | 1602 +================+=================+==========+=================+ 1603 | 1152 | IGP Flags | 1 | Section 5.3.3.1 | 1604 +----------------+-----------------+----------+-----------------+ 1605 | 1153 | IGP Route Tag | 4*n | [RFC5130] | 1606 +----------------+-----------------+----------+-----------------+ 1607 | 1154 | IGP Extended | 8*n | [RFC5130] | 1608 | | Route Tag | | | 1609 +----------------+-----------------+----------+-----------------+ 1610 | 1155 | Prefix Metric | 4 | [RFC5305] | 1611 +----------------+-----------------+----------+-----------------+ 1612 | 1156 | OSPF Forwarding | 4 | [RFC2328] | 1613 | | Address | | | 1614 +----------------+-----------------+----------+-----------------+ 1615 | 1157 | Opaque Prefix | variable | Section 5.3.3.6 | 1616 | | Attribute | | | 1617 +----------------+-----------------+----------+-----------------+ 1619 Table 10: Prefix Attribute TLVs 1621 5.3.3.1. IGP Flags TLV 1623 The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits 1624 originally assigned to the prefix. The IGP Flags TLV is encoded as 1625 follows: 1627 0 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Type | Length | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 |D|N|L|P| | 1633 +-+-+-+-+-+-+-+-+ 1635 Figure 25: IGP Flag TLV Format 1637 The Value field contains bits defined according to the table below: 1639 +=====+===========================+===========+ 1640 | Bit | Description | Reference | 1641 +=====+===========================+===========+ 1642 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1643 +-----+---------------------------+-----------+ 1644 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1645 +-----+---------------------------+-----------+ 1646 | 'L' | OSPF "local address" Bit | [RFC5340] | 1647 +-----+---------------------------+-----------+ 1648 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1649 +-----+---------------------------+-----------+ 1651 Table 11: IGP Flag Bits Definitions 1653 The bits that are not defined MUST be set to 0 by the originator and 1654 MUST be ignored by the receiver. 1656 5.3.3.2. IGP Route Tag TLV 1658 The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or 1659 OSPF) of the prefix and is encoded as follows: 1661 0 1 2 3 1662 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 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Type | Length | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 // Route Tags (one or more) // 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 Figure 26: IGP Route Tag TLV Format 1671 Length is a multiple of 4. 1673 The Value field contains one or more Route Tags as learned in the IGP 1674 topology. 1676 5.3.3.3. Extended IGP Route Tag TLV 1678 The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of 1679 the prefix [RFC5130] and is encoded as follows: 1681 0 1 2 3 1682 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 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | Type | Length | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 // Extended Route Tag (one or more) // 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 Figure 27: Extended IGP Route Tag TLV Format 1691 Length is a multiple of 8. 1693 The Extended Route Tag field contains one or more Extended Route Tags 1694 as learned in the IGP topology. 1696 5.3.3.4. Prefix Metric TLV 1698 The Prefix Metric TLV is an optional attribute and may only appear 1699 once. If present, it carries the metric of the prefix as known in 1700 the IGP topology as described in Section 4 of [RFC5305] (and 1701 therefore represents the reachability cost to the prefix). If not 1702 present, it means that the prefix is advertised without any 1703 reachability. 1705 0 1 2 3 1706 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 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Type | Length | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Metric | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Figure 28: Prefix Metric TLV Format 1715 Length is 4. 1717 5.3.3.5. OSPF Forwarding Address TLV 1719 The OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF 1720 forwarding address as known in the original OSPF advertisement. The 1721 forwarding address can be either IPv4 or IPv6. 1723 0 1 2 3 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Type | Length | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 // Forwarding Address (variable) // 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1731 Figure 29: OSPF Forwarding Address TLV Format 1733 Length is 4 for an IPv4 forwarding address, and 16 for an IPv6 1734 forwarding address. 1736 5.3.3.6. Opaque Prefix Attribute TLV 1738 The Opaque Prefix Attribute TLV is an envelope that transparently 1739 carries optional Prefix Attribute TLVs advertised by a router. An 1740 originating router shall use this TLV for encoding information 1741 specific to the protocol advertised in the NLRI header Protocol-ID 1742 field or new protocol extensions to the protocol as advertised in the 1743 NLRI header Protocol-ID field for which there is no protocol-neutral 1744 representation in the BGP Link-State NLRI. The primary use of the 1745 Opaque Prefix Attribute TLV is to bridge the document lag between a 1746 new IGP link-state attribute and its protocol-neutral BGP-LS 1747 extension being defined. Once the protocol-neutral BGP-LS extensions 1748 are defined, the BGP-LS implementations may still need to advertise 1749 the information both within the Opaque Attribute TLV and the new TLV 1750 definition for incremental deployment and transition. 1752 In the case of OSPFv2, this TLV MUST NOT be used to advertise 1753 information carried using TLVs other than those in the OSPFv2 1754 Extended Prefix Opaque LSA [RFC7684]. In the case of OSPFv3, this 1755 TLV MUST NOT be used to advertise TLVs other than those in the OSPFv3 1756 E-Inter-Area-Prefix-LSA, E-Intra-Area-Prefix-LSA, E-AS-External- 1757 Prefix-LSA, and E-NSSA-LSA [RFC8362]. 1759 The format of the TLV is as follows: 1761 0 1 2 3 1762 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 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Type | Length | 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 // Opaque Prefix Attributes (variable) // 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 Figure 30: Opaque Prefix Attribute TLV Format 1771 The type is as specified in Table 10. Length is variable. 1773 5.4. Private Use 1775 TLVs for Vendor Private use are supported using the code point range 1776 reserved as indicated in Section 7. For such TLV use in the NLRI or 1777 BGP-LS Attribute, the format as described in Section 5.1 is to be 1778 used and a 4-octet field MUST be included as the first field in the 1779 value to carry the Enterprise Code. For a private use NLRI Type, a 4 1780 octet field MUST be included as the first field in the NLRI 1781 immediately following the Total NLRI Length field of the Link-State 1782 NLRI format as described in Section 5.2 to carry the Enterprise Code 1783 [ENTNUM]. This enables the use of vendor-specific extensions without 1784 conflicts. 1786 Multiple instances of private-use TLVs MAY appear in the BGP-LS 1787 Attribute. 1789 5.5. BGP Next-Hop Information 1791 BGP link-state information for both IPv4 and IPv6 networks can be 1792 carried over either an IPv4 BGP session or an IPv6 BGP session. If 1793 an IPv4 BGP session is used, then the next-hop in the MP_REACH_NLRI 1794 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1795 used, then the next-hop in the MP_REACH_NLRI SHOULD be an IPv6 1796 address. Usually, the next-hop will be set to the local endpoint 1797 address of the BGP session. The next-hop address MUST be encoded as 1798 described in [RFC4760]. The Length field of the next-hop address 1799 will specify the next-hop address family. If the next-hop length is 1800 4, then the next-hop is an IPv4 address; if the next-hop length is 1801 16, then it is a global IPv6 address; and if the next-hop length is 1802 32, then there is one global IPv6 address followed by a link-local 1803 IPv6 address. The link-local IPv6 address should be used as 1804 described in [RFC2545]. For VPN Subsequent Address Family Identifier 1805 (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero 1806 is prepended to the next-hop. 1808 The BGP Next-Hop is used by each BGP-LS speaker to validate the NLRI 1809 it receives. In case identical NLRIs are sourced by multiple BGP-LS 1810 Producers, the BGP Next-Hop is used to tiebreak as per the standard 1811 BGP path decision process. This specification doesn't mandate any 1812 rule regarding the rewrite of the BGP Next-Hop. 1814 5.6. Inter-AS Links 1816 The main source of TE information is the IGP, which is not active on 1817 inter-AS links. In some cases, the IGP may have information of 1818 inter-AS links [RFC5392] [RFC9346]. In other cases, an 1819 implementation SHOULD provide a means to inject inter-AS links into 1820 BGP-LS. The exact mechanism used to advertise the inter-AS links is 1821 outside the scope of this document. 1823 5.7. OSPF Virtual Links and Sham Links 1825 In an OSPF [RFC2328] [RFC5340] network, OSPF virtual links serve to 1826 connect physically separate components of the backbone to establish/ 1827 maintain continuity of the backbone area. While OSPF virtual links 1828 are modeled as point-to-point unnumbered links in the OSPF topology, 1829 their characteristics and purpose are different from other types of 1830 links in the OSPF topology. They are advertised using a distinct 1831 "virtual link" type in OSPF LSAs. The mechanism for the 1832 advertisement of OSPF virtual links via BGP-LS is outside the scope 1833 of this document. 1835 In an OSPF network, sham links [RFC4577] [RFC6565] are used to 1836 provide intra-area connectivity between VPN Routing and Forwarding 1837 (VRF) instances on PE routers over the VPN provider's network. These 1838 links are advertised in OSPF as point-to-point unnumbered links and 1839 represent connectivity over a service provider network using 1840 encapsulation mechanisms like MPLS. As such, the mechanism for the 1841 advertisement of OSPF sham links follows the same procedures as other 1842 point-to-point unnumbered links as described previously in this 1843 document. 1845 5.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 1847 OSPFv2 [RFC2328] defines the Type 4 Summary LSA and OSPFv3 [RFC5340] 1848 the Inter-area-router-LSA for an Area Border Router (ABR) to 1849 advertise reachability to an AS Border Router (ASBR) that is external 1850 to the area yet internal to the AS. The nature of information 1851 advertised by OSPF using this type of LSA does not map to either a 1852 node or a link or a prefix as discussed in this document. Therefore, 1853 the mechanism for the advertisement of the information carried by 1854 these LSAs is outside the scope of this document. 1856 5.9. Handling of Unreachable IGP Nodes 1858 Consider an OSPF network as shown in Figure 31, where R2 and R3 are 1859 the BGP-LS Producers and also the OSPF Area Border Routers (ABRs). 1860 The link between R2 and R3 is in area 0 while the other links are in 1861 area 1 as indicated by the a0 and a1 references respectively against 1862 the links. 1864 A BGP-LS Consumer talks to a BGP route reflector RR0 which is a BGP- 1865 LS Propagator that is aggregating the BGP-LS feed from the BGP-LS 1866 Producers R2 and R3. Here R2 and R3 provide a redundant topology 1867 feed via BGP-LS to RR0. Normally, RR0 would receive two identical 1868 copies of all the Link-State NLRIs from both R2 and R3 and it would 1869 pick one of them (say R2) based on the standard BGP Decision Process. 1871 BGP-LS Consumer 1872 ^ 1873 | 1874 RR0 1875 (BGP Route Reflector) 1876 / \ 1877 / \ 1878 a1 / a0 \ a1 1879 R1 ------ R2 -------- R3 ------ R4 1880 a1 | | a1 1881 | | 1882 R5 ---------------------------- R6 1883 a1 1885 Figure 31: Incorrect Reporting due to BGP Path Selection 1887 Consider a scenario where the link between R5 and R6 is lost (thereby 1888 partitioning the area 1) and its impact on the OSPF LSDB at R2 and 1889 R3. 1891 Now, R5 will remove the link R5-R6 from its Router LSA, and this 1892 updated LSA is available at R2. R2 also has a stale copy of R6's 1893 Router LSA that still has the link R6-R5 in it. Based on this view 1894 in its LSDB, R2 will advertise only the half-link R6-R5 that it 1895 derives from R6's stale Router LSA. 1897 At the same time, R6 has removed the link R6-R5 from its Router LSA, 1898 and this updated LSA is available at R3. Similarly, R3 also has a 1899 stale copy of R5's Router LSA having the link R5-R6 in it. Based on 1900 its LSDB, R3 will advertise only the half-link R5-R6 that it has 1901 derived from R5's stale Router LSA. 1903 Now, the BGP-LS Consumer receives both the Link NLRIs corresponding 1904 to the half-links from R2 and R3 via RR0. When viewed together, it 1905 would not detect or realize that area 1 is partitioned. Also, if R2 1906 continues to report Node and Prefix NLRIs corresponding to the stale 1907 copy of R4 and R6's Router LSAs then RR0 could prefer them over the 1908 valid Node and Prefix NLRIs for R4 and R6 that it is receiving from 1909 R3 depending on RR0's BGP decision process. This would result in the 1910 BGP-LS Consumer getting stale and inaccurate topology information. 1911 This problem scenario is avoided if R2 were to not advertise the 1912 link-state information corresponding to R4 and R6 and if R3 were to 1913 not advertise similarly for R1 and R5. 1915 A BGP-LS Producer SHOULD withdraw all link-state objects advertised 1916 by it in BGP when the node that originated its corresponding LSP/LSAs 1917 is determined to have become unreachable in the IGP. An 1918 implementation MAY continue to advertise link-state objects 1919 corresponding to unreachable nodes in a deployment use-case where the 1920 BGP-LS Consumer is interested in receiving a topology feed 1921 corresponding to a complete IGP LSDB view. In such deployments, it 1922 is expected that the problem described above is mitigated by the BGP- 1923 LS Consumer via appropriate handling of such a topology feed in 1924 addition to the use of either a direct BGP peering with the BGP-LS 1925 Producer nodes or mechanisms such as [RFC7911] when using RRs. 1926 Details of these mechanisms are outside the scope of this document. 1928 If the BGP-LS Producer does withdraw link-state objects associated 1929 with an IGP node based on the failure of reachability check for that 1930 node, then it MUST re-advertise those link-state objects after that 1931 node becomes reachable again in the IGP domain. 1933 5.10. Router-ID Anchoring Example: ISO Pseudonode 1935 The encoding of a broadcast LAN in IS-IS provides a good example of 1936 how Router-IDs are encoded. Consider Figure 32. This represents a 1937 Broadcast LAN between a pair of routers. The "real" (non-pseudonode) 1938 routers have both an IPv4 Router-ID and IS-IS Node-ID. The 1939 pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the 1940 LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, 1941 Node2) are being generated. 1943 The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP 1944 Router-ID TLV of the local Node Descriptor is 6 octets long and 1945 contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV 1946 of the remote Node Descriptor is 7 octets long and contains the ISO- 1947 ID of Pseudonode1, 1920.0000.2001.02. The BGP-LS Attribute of this 1948 link contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1949 192.0.2.1, the IPv4 Router-ID of Node1. 1951 The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The IGP 1952 Router-ID TLV of the local Node Descriptor is 7 octets long and 1953 contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP 1954 Router-ID TLV of the remote Node Descriptor is 6 octets long and 1955 contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS Attribute 1956 of this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1957 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1959 +-----------------+ +-----------------+ +-----------------+ 1960 | Node1 | | Pseudonode1 | | Node2 | 1961 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1962 | 192.0.2.1 | | | | 192.0.2.2 | 1963 +-----------------+ +-----------------+ +-----------------+ 1965 Figure 32: IS-IS Pseudonodes 1967 5.11. Router-ID Anchoring Example: OSPF Pseudonode 1969 The encoding of a broadcast LAN in OSPF provides a good example of 1970 how Router-IDs and local Interface IPs are encoded. Consider 1971 Figure 33. This represents a Broadcast LAN between a pair of 1972 routers. The "real" (non-pseudonode) routers have both an IPv4 1973 Router-ID and an Area Identifier. The pseudonode does have an IPv4 1974 Router-ID, an IPv4 Interface Address (for disambiguation), and an 1975 OSPF Area. Node1 is the DR for the LAN; hence, its local IP address 1976 198.51.100.1 is used as both the Router-ID and Interface IP for the 1977 pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and 1978 (Pseudonode1, Node2), are being generated. 1980 The Link NLRI of (Node1, Pseudonode1) is encoded as follows: 1982 * Local Node Descriptor 1984 TLV #515: IGP Router-ID: 192.0.2.1 1986 TLV #514: OSPF Area-ID: ID:0.0.0.0 1988 * Remote Node Descriptor 1990 TLV #515: IGP Router-ID: 192.0.2.1:10.1.1.1 1992 TLV #514: OSPF Area-ID: ID:0.0.0.0 1994 The Link NLRI of (Pseudonode1, Node2) is encoded as follows: 1996 * Local Node Descriptor 1998 TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1 1999 TLV #514: OSPF Area-ID: ID:0.0.0.0 2001 * Remote Node Descriptor 2003 TLV #515: IGP Router-ID: 192.0.2.2 2005 TLV #514: OSPF Area-ID: ID:0.0.0.0 2007 198.51.100.1/24 198.51.100.2/24 2008 +-------------+ +-------------+ +-------------+ 2009 | Node1 | | Pseudonode1 | | Node2 | 2010 | 192.0.2.1 |--->| 192.0.2.1 |--->| 192.0.2.2 | 2011 | | |198.51.100.1 | | | 2012 | Area 0 | | Area 0 | | Area 0 | 2013 +-------------+ +-------------+ +-------------+ 2015 Figure 33: OSPF Pseudonodes 2017 The LAN subnet 198.51.100.0/24 is not included in the Router LSA of 2018 Node1 or Node2. The Network LSA for this LAN advertised by the DR 2019 Node1 contains the subnet mask for the LAN along with the DR address. 2020 A Prefix NLRI corresponding to the LAN subnet is advertised with the 2021 Pseudonode1 used as the Local node using the DR address and the 2022 subnet mask from the Network LSA. 2024 5.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 2026 Graceful migration from one IGP to another requires coordinated 2027 operation of both protocols during the migration period. Such 2028 coordination requires identifying a given physical link in both IGPs. 2029 The IPv4 Router-ID provides that "glue", which is present in the Node 2030 Descriptors of the OSPF Link NLRI and in the link attribute of the 2031 IS-IS Link NLRI. 2033 Consider a point-to-point link between two routers, A and B, that 2034 initially were OSPFv2-only routers and then IS-IS is enabled on them. 2035 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 2036 Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the 2037 link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link 2038 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 2039 in the local and remote Node Descriptors, respectively. The IS-IS 2040 Link NLRI for the link is encoded with the ISO-ID of nodes A and B in 2041 the local and remote Node Descriptors, respectively. In addition, 2042 the BGP-LS Attribute of the IS-IS Link NLRI contains the TLV type 2043 1028 containing the IPv4 Router-ID of node A, TLV type 1030 2044 containing the IPv4 Router-ID of node B, and TLV type 1031 containing 2045 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 2046 the link (A, B) can be identified in both the IS-IS and OSPF 2047 protocols. 2049 6. Link to Path Aggregation 2051 Distribution of all links available on the global Internet is 2052 certainly possible; however, it is not desirable from a scaling and 2053 privacy point of view. Therefore, an implementation may support a 2054 link to path aggregation. Rather than advertising all specific links 2055 of a domain, an ASBR may advertise an "aggregate link" between a non- 2056 adjacent pair of nodes. The "aggregate link" represents the 2057 aggregated set of link properties between a pair of non-adjacent 2058 nodes. The actual methods to compute the path properties (of 2059 bandwidth, metric, etc.) are outside the scope of this document. The 2060 decision of whether to advertise all specific links or aggregated 2061 links is an operator's policy choice. To highlight the varying 2062 levels of exposure, the following deployment examples are discussed. 2064 6.1. Example: No Link Aggregation 2066 Consider Figure 34. Both AS1 and AS2 operators want to protect their 2067 inter-AS {R1, R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants 2068 to compute its link-protection LSP to R3, it needs to "see" an 2069 alternate path to R3. Therefore, the AS2 operator exposes its 2070 topology. All BGP-TE-enabled routers in AS1 "see" the full topology 2071 of AS2 and therefore can compute a backup path. Note that the 2072 computing router decides if the direct link between {R3, R4} or the 2073 {R4, R5, R3} path is used. 2075 AS1 : AS2 2076 : 2077 R1-------R3 2078 | : | \ 2079 | : | R5 2080 | : | / 2081 R2-------R4 2082 : 2083 : 2085 Figure 34: No Link Aggregation 2087 6.2. Example: ASBR to ASBR Path Aggregation 2089 The brief difference between the "no-link aggregation" example and 2090 this example is that no specific link gets exposed. Consider 2091 Figure 35. The only link that gets advertised by AS2 is an 2092 "aggregate" link between R3 and R4. This is enough to tell AS1 that 2093 there is a backup path. However, the actual links being used are 2094 hidden from the topology. 2096 AS1 : AS2 2097 : 2098 R1-------R3 2099 | : | 2100 | : | 2101 | : | 2102 R2-------R4 2103 : 2104 : 2106 Figure 35: ASBR Link Aggregation 2108 6.3. Example: Multi-AS Path Aggregation 2110 Service providers in control of multiple ASes may even decide to not 2111 expose their internal inter-AS links. Consider Figure 36. AS3 is 2112 modeled as a single node that connects to the border routers of the 2113 aggregated domain. 2115 AS1 : AS2 : AS3 2116 : : 2117 R1-------R3----- 2118 | : : \ 2119 | : : vR0 2120 | : : / 2121 R2-------R4----- 2122 : : 2123 : : 2125 Figure 36: Multi-AS Aggregation 2127 7. IANA Considerations 2129 As this document obsoletes [RFC7752] and [RFC9029], IANA is requested 2130 to change all registration information that references those 2131 documents to instead reference this document. 2133 IANA has assigned address family number 16388 (BGP-LS) in the 2134 "Address Family Numbers" registry. 2136 IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the 2137 "SAFI Values" registry under the "Subsequent Address Family 2138 Identifiers (SAFI) Parameters" registry group. 2140 IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path 2141 Attributes" registry under the "Border Gateway Protocol (BGP) 2142 Parameters" registry group. 2144 IANA has created a "Border Gateway Protocol - Link-State (BGP-LS) 2145 Parameters" registry group at . 2148 This section also incorporates all the changes to the allocation 2149 procedures for the BGP-LS IANA registry group as well as the 2150 guidelines for designated experts introduced by [RFC9029]. 2152 7.1. BGP-LS Registries 2154 All of the registries listed in the following subsections are BGP-LS 2155 specific and are accessible under this registry. 2157 7.1.1. BGP-LS NLRI Types Registry 2159 The "BGP-LS NLRI Types" registry has been set up for assignment for 2160 the two-octet sized code-points for BGP-LS NLRI types and populated 2161 with the values shown below: 2163 +=============+===========================+=================+ 2164 | Type | NLRI Type | Reference | 2165 +=============+===========================+=================+ 2166 | 0 | Reserved | [This document] | 2167 +-------------+---------------------------+-----------------+ 2168 | 1 | Node NLRI | [This document] | 2169 +-------------+---------------------------+-----------------+ 2170 | 2 | Link NLRI | [This document] | 2171 +-------------+---------------------------+-----------------+ 2172 | 3 | IPv4 Topology Prefix NLRI | [This document] | 2173 +-------------+---------------------------+-----------------+ 2174 | 4 | IPv6 Topology Prefix NLRI | [This document] | 2175 +-------------+---------------------------+-----------------+ 2176 | 65000-65535 | Private Use | [This document] | 2177 +-------------+---------------------------+-----------------+ 2179 Table 12: BGP-LS NLRI Types 2181 A range is reserved for Private Use [RFC8126]. All other allocations 2182 within the registry are to be made using the "Expert Review" policy 2183 [RFC8126] that requires documentation of the proposed use of the 2184 allocated value and approval by the Designated Expert assigned by the 2185 IESG. 2187 7.1.2. BGP-LS Protocol-IDs Registry 2189 The "BGP-LS Protocol-IDs" registry has been set up for assignment for 2190 the one-octet sized code-points for BGP-LS Protocol-IDs and populated 2191 with the values shown below: 2193 +=============+==================================+=================+ 2194 | Protocol-ID | NLRI information source protocol | Reference | 2195 +=============+==================================+=================+ 2196 | 0 | Reserved | [This document] | 2197 +-------------+----------------------------------+-----------------+ 2198 | 1 | IS-IS Level 1 | [This document] | 2199 +-------------+----------------------------------+-----------------+ 2200 | 2 | IS-IS Level 2 | [This document] | 2201 +-------------+----------------------------------+-----------------+ 2202 | 3 | OSPFv2 | [This document] | 2203 +-------------+----------------------------------+-----------------+ 2204 | 4 | Direct | [This document] | 2205 +-------------+----------------------------------+-----------------+ 2206 | 5 | Static configuration | [This document] | 2207 +-------------+----------------------------------+-----------------+ 2208 | 6 | OSPFv3 | [This document] | 2209 +-------------+----------------------------------+-----------------+ 2210 | 200-255 | Private Use | [This document] | 2211 +-------------+----------------------------------+-----------------+ 2213 Table 13: BGP-LS Protocol-IDs 2215 A range is reserved for Private Use [RFC8126]. All other allocations 2216 within the registry are to be made using the "Expert Review" policy 2217 [RFC8126] that requires documentation of the proposed use of the 2218 allocated value and approval by the Designated Expert assigned by the 2219 IESG. 2221 7.1.3. BGP-LS Well-Known Instance-IDs Registry 2223 The "BGP-LS Well-Known Instance-IDs" registry that was set up via 2224 [RFC7752] is no longer required. IANA is requested to mark this 2225 registry as obsolete and to change its registration procedure to 2226 "registry closed". 2228 7.1.4. BGP-LS Node Flags Registry 2230 The "BGP-LS Node Flags" registry is requested to be created for the 2231 one octet-sized flags field of the Node Flag Bits TLV (1024) and 2232 populated with the initial values shown below: 2234 +=====+======================+=================+ 2235 | Bit | Description | Reference | 2236 +=====+======================+=================+ 2237 | 0 | Overload Bit (O-bit) | [This document] | 2238 +-----+----------------------+-----------------+ 2239 | 1 | Attached Bit (A-bit) | [This document] | 2240 +-----+----------------------+-----------------+ 2241 | 2 | External Bit (E-bit) | [This document] | 2242 +-----+----------------------+-----------------+ 2243 | 3 | ABR Bit (B-bit) | [This document] | 2244 +-----+----------------------+-----------------+ 2245 | 4 | Router Bit (R-bit) | [This document] | 2246 +-----+----------------------+-----------------+ 2247 | 5 | V6 Bit (V-bit) | [This document] | 2248 +-----+----------------------+-----------------+ 2249 | 6-7 | Unassigned | [This document] | 2250 +-----+----------------------+-----------------+ 2252 Table 14: BGP-LS Node Flags 2254 Allocations within the registry are to be made using the "Expert 2255 Review" policy [RFC8126] that requires documentation of the proposed 2256 use of the allocated value and approval by the Designated Expert 2257 assigned by the IESG. 2259 7.1.5. BGP-LS MPLS Protocol Mask Registry 2261 The "BGP-LS MPLS Protocol Mask" registry is requested to be created 2262 for the one octet-sized flags field of the MPLS Protocol Mask TLV 2263 (1094) and populated with the initial values shown below: 2265 +=====+===========================================+=================+ 2266 | Bit | Description | Reference | 2267 +=====+===========================================+=================+ 2268 | 0 | Label Distribution Protocol (L-bit) | [This document] | 2269 +-----+-------------------------------------------+-----------------+ 2270 | 1 | Extension to RSVP for LSP Tunnels | [This document] | 2271 | | (R-bit) | | 2272 +-----+-------------------------------------------+-----------------+ 2273 | 2-7 | Unassigned | [This document] | 2274 +-----+-------------------------------------------+-----------------+ 2276 Table 15: BGP-LS MPLS Protocol Mask 2278 Allocations within the registry are to be made using the "Expert 2279 Review" policy [RFC8126] that requires documentation of the proposed 2280 use of the allocated value and approval by the Designated Expert 2281 assigned by the IESG. 2283 7.1.6. BGP-LS IGP Prefix Flags Registry 2285 The "BGP-LS IGP Prefix Flags" registry is requested to be created for 2286 the one octet-sized flags field of the IGP Flags TLV (1152) and 2287 populated with the initial values shown below: 2289 +=====+===================================+=================+ 2290 | Bit | Description | Reference | 2291 +=====+===================================+=================+ 2292 | 0 | IS-IS Up/Down Bit (D-bit) | [This document] | 2293 +-----+-----------------------------------+-----------------+ 2294 | 1 | OSPF "no unicast" Bit (N-bit) | [This document] | 2295 +-----+-----------------------------------+-----------------+ 2296 | 2 | OSPF "local address" Bit (L-bit) | [This document] | 2297 +-----+-----------------------------------+-----------------+ 2298 | 3 | OSPF "propagate NSSA" Bit (P-bit) | [This document] | 2299 +-----+-----------------------------------+-----------------+ 2300 | 4-7 | Unassigned | [This document] | 2301 +-----+-----------------------------------+-----------------+ 2303 Table 16: BGP-LS IGP Prefix Flags 2305 Allocations within the registry are to be made using the "Expert 2306 Review" policy [RFC8126] that requires documentation of the proposed 2307 use of the allocated value and approval by the Designated Expert 2308 assigned by the IESG. 2310 7.1.7. BGP-LS TLVs Registry 2312 The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 2313 Attribute TLVs" registry was created via [RFC7752]. This document 2314 requests IANA to rename that registry to "BGP-LS NLRI and Attribute 2315 TLVs" and to remove the column for "IS-IS TLV/Sub-TLV". The 2316 registration procedures are as below: 2318 +================+================================+ 2319 | TLV Code Point | Registration Process | 2320 +================+================================+ 2321 | 0-255 | Reserved (not to be allocated) | 2322 +----------------+--------------------------------+ 2323 | 256-64999 | Expert Review | 2324 +----------------+--------------------------------+ 2325 | 65000-65535 | Private Use | 2326 +----------------+--------------------------------+ 2328 Table 17: BGP-LS TLVs Registration Process 2330 A range is reserved for Private Use [RFC8126]. All other allocations 2331 except for the reserved range within the registry are to be made 2332 using the "Expert Review" policy [RFC8126] that requires 2333 documentation of the proposed use of the allocated value and approval 2334 by the Designated Expert assigned by the IESG. 2336 The registry was pre-populated with the values shown in Table 18 and 2337 the reference for all those allocations should be changed to this 2338 document and the respective section where those TLVs are specified. 2340 7.2. Guidance for Designated Experts 2342 In all cases of review by the designated expert described here, the 2343 designated expert is expected to check the clarity of purpose and use 2344 of the requested code points. The following points apply to the 2345 registries discussed in this document: 2347 1. Application for a code point allocation may be made to the 2348 designated experts at any time and MUST be accompanied by 2349 technical documentation explaining the use of the code point. 2350 Such documentation SHOULD be presented in the form of an 2351 Internet-Draft, but MAY arrive in any form that can be reviewed 2352 and exchanged among reviewers. 2354 2. The designated experts SHOULD only consider requests that arise 2355 from Internet-Drafts that have already been accepted as working 2356 group documents or that are planned for progression as AD- 2357 Sponsored documents in the absence of a suitably chartered 2358 working group. 2360 3. In the case of working group documents, the designated experts 2361 MUST check with the working group chairs that there is a 2362 consensus within the working group to allocate at this time. In 2363 the case of AD-Sponsored documents, the designated experts MUST 2364 check with the AD for approval to allocate at this time. 2366 4. If the document is not adopted by the IDR Working Group (or its 2367 successor), the designated expert MUST notify the IDR mailing 2368 list (or its successor) of the request and MUST provide access to 2369 the document. The designated expert MUST allow two weeks for any 2370 response. Any comments received MUST be considered by the 2371 designated expert as part of the subsequent step. 2373 5. The designated experts MUST then review the assignment requests 2374 on their technical merit. The designated experts MAY raise 2375 issues related to the allocation request with the authors and on 2376 the IDR (or successor) mailing list for further consideration 2377 before the assignments are made. 2379 6. The designated expert MUST ensure that any request for a code 2380 point does not conflict with work that is active or already 2381 published within the IETF. 2383 7. Once the designated experts have approved, IANA will update the 2384 registry by marking the allocated code points with a reference to 2385 the associated document. 2387 8. In the event that the document is a working group document or is 2388 AD-Sponsored, and that document fails to progress to publication 2389 as an RFC, the working group chairs or AD SHOULD contact IANA to 2390 coordinate about marking the code points as deprecated. A 2391 deprecated code point is not marked as allocated for use and is 2392 not available for allocation in a future document. The WG chairs 2393 may inform IANA that a deprecated code point can be completely 2394 deallocated (i.e., made available for new allocations) at any 2395 time after it has been deprecated if there is a shortage of 2396 unallocated code points in the registry. 2398 8. Manageability Considerations 2400 This section is structured as recommended in [RFC5706]. 2402 8.1. Operational Considerations 2404 8.1.1. Operations 2406 Existing BGP operational procedures apply. No new operation 2407 procedures are defined in this document. It is noted that the NLRI 2408 information present in this document carries purely application-level 2409 data that has no immediate impact on the corresponding forwarding 2410 state computed by BGP. As such, any churn in reachability 2411 information has a different impact than regular BGP updates, which 2412 need to change the forwarding state for an entire router. 2413 Distribution of the BGP-LS NLRIs SHOULD be handled by dedicated route 2414 reflectors in most deployments providing a level of isolation and 2415 fault containment between different BGP address families. In the 2416 event of dedicated route reflectors not being available, other 2417 alternate mechanisms like separation of BGP instances or separate BGP 2418 sessions (e.g. using different addresses for peering) for Link-State 2419 information distribution SHOULD be used. 2421 It is RECOMMENDED that operators deploying BGP-LS enable two or more 2422 BGP-LS Producers in each IGP flooding domain to achieve redundancy in 2423 the origination of link-state information into BGP-LS. It is also 2424 RECOMMENDED that operators ensure BGP peering designs that ensure 2425 redundancy in the BGP update propagation paths (e.g., using at least 2426 a pair of route reflectors) and ensuring that BGP-LS Consumers are 2427 receiving the topology information from at least two BGP-LS Speakers. 2429 In a multi-domain IGP network, the correct provisioning of the BGP-LS 2430 Instance-IDs on the BGP-LS Producers is required for consistent 2431 reporting of the multi-domain link-state topology. Refer to 2432 Section 5.2 for more details. 2434 8.1.2. Installation and Initial Setup 2436 Configuration parameters defined in Section 8.2.3 SHOULD be 2437 initialized to the following default values: 2439 * The Link-State NLRI capability is turned off for all neighbors. 2441 * The maximum rate at which Link-State NLRIs will be advertised/ 2442 withdrawn from neighbors is set to 200 updates per second. 2444 8.1.3. Migration Path 2446 The proposed extension is only activated between BGP peers after 2447 capability negotiation. Moreover, the extensions can be turned on/ 2448 off on an individual peer basis (see Section 8.2.3), so the extension 2449 can be gradually rolled out in the network. 2451 8.1.4. Requirements for Other Protocols and Functional Components 2453 The protocol extension defined in this document does not put new 2454 requirements on other protocols or functional components. 2456 8.1.5. Impact on Network Operation 2458 The frequency of Link-State NLRI updates could interfere with regular 2459 BGP prefix distribution. A network operator should use a dedicated 2460 route reflector infrastructure to distribute Link-State NLRIs as 2461 discussed in Section 8.1.1. 2463 Distribution of Link-State NLRIs SHOULD be limited to a single admin 2464 domain, which can consist of multiple areas within an AS or multiple 2465 ASes. 2467 8.1.6. Verifying Correct Operation 2469 Existing BGP procedures apply. In addition, an implementation SHOULD 2470 allow an operator to: 2472 * List neighbors with whom the speaker is exchanging Link-State 2473 NLRIs. 2475 8.2. Management Considerations 2477 8.2.1. Management Information 2479 The IDR working group has documented and continues to document parts 2480 of the Management Information Base and YANG models for managing and 2481 monitoring BGP speakers and the sessions between them. It is 2482 currently believed that the BGP session running BGP-LS is not 2483 substantially different from any other BGP session and can be managed 2484 using the same data models. 2486 8.2.2. Fault Management 2488 This section describes the fault management actions, as described in 2489 [RFC7606], that are to be performed for the handling of BGP UPDATE 2490 messages for BGP-LS. 2492 A Link-State NLRI MUST NOT be considered malformed or invalid based 2493 on the inclusion/exclusion of TLVs or contents of the TLV fields 2494 (i.e. semantic errors), as described in Section 5.1 and Section 5.2. 2496 A BGP-LS Speaker MUST perform the following syntactic validation of 2497 the Link-State NLRI to determine if it is malformed. 2499 * The sum of all TLVs lengths found in the BGP MP_REACH_NLRI 2500 attribute corresponds to the BGP MP_REACH_NLRI length. 2502 * The sum of all TLVs lengths found in the BGP MP_UNREACH_NLRI 2503 attribute corresponds to the BGP MP_UNREACH_NLRI length. 2505 * The sum of all TLVs lengths found in a Link-State NLRI corresponds 2506 to the Total NLRI Length field of all its Descriptors. 2508 * The length of the TLVs and, when the TLV is recognized then, the 2509 length of its sub-TLVs in the NLRI is valid. 2511 * The syntactic correctness of the NLRI fields been verified as per 2512 [RFC7606]. 2514 * The rule regarding the ordering of TLVs been followed as described 2515 in Section 5.1. 2517 * For NLRIs carrying either a Local or Remote Node Descriptor TLV, 2518 there is not more than one instance of a sub-TLV present. 2520 When the error that is determined allows for the router to skip the 2521 malformed NLRI(s) and continue the processing of the rest of the BGP 2522 UPDATE message (e.g. when the TLV ordering rule is violated), then it 2523 MUST handle such malformed NLRIs as 'NLRI discard' (i.e., processing 2524 similar to what is described in section 5.4 of [RFC7606]). In other 2525 cases, where the error in the NLRI encoding results in the inability 2526 to process the BGP UPDATE message (e.g. length related encoding 2527 errors), then the router SHOULD handle such malformed NLRIs as 'AFI/ 2528 SAFI disable' when other AFI/SAFI besides BGP-LS are being advertised 2529 over the same session. Alternately, the router MUST perform a 2530 'session reset' when the session is only being used for BGP-LS or if 2531 'AFI/SAFI disable' action is not possible. 2533 A BGP-LS Attribute MUST NOT be considered malformed or invalid based 2534 on the inclusion/exclusion of TLVs or contents of the TLV fields 2535 (i.e. semantic errors), as described in Section 5.1 and Section 5.3. 2537 A BGP-LS Speaker MUST perform the following syntactic validation of 2538 the BGP-LS Attribute to determine if it is malformed. 2540 * The sum of all TLVs lengths found in the BGP-LS Attribute 2541 corresponds to the BGP-LS Attribute length. 2543 * The syntactic correctness of the Attributes (including BGP-LS 2544 Attribute) been verified as per [RFC7606]. 2546 * The length of each TLV and, when the TLV is recognized then, the 2547 length of its sub-TLVs in the BGP-LS Attribute is valid. 2549 When the error that is determined allows for the router to skip the 2550 malformed BGP-LS Attribute and continue the processing of the rest of 2551 the BGP UPDATE message (e.g. when the BGP-LS Attribute length and the 2552 total Path Attribute Length are correct but some TLV/sub-TLV length 2553 within the BGP-LS Attribute is invalid), then it MUST handle such 2554 malformed BGP-LS Attribute as 'Attribute Discard'. In other cases, 2555 where the error in the BGP-LS Attribute encoding results in the 2556 inability to process the BGP UPDATE message then the handling is the 2557 same as described above for the malformed NLRI. 2559 Note that the 'Attribute Discard' action results in the loss of all 2560 TLVs in the BGP-LS Attribute and not the removal of a specific 2561 malformed TLV. The removal of specific malformed TLVs may give a 2562 wrong indication to a BGP-LS Consumer of that specific information 2563 being deleted or not available. 2565 When a BGP Speaker receives an UPDATE message with Link-State NLRI(s) 2566 in the MP_REACH_NLRI but without the BGP-LS Attribute, it is most 2567 likely an indication that a BGP Speaker preceding it has performed 2568 the 'Attribute Discard' fault handling. An implementation SHOULD 2569 preserve and propagate the Link-State NLRIs, unless denied by local 2570 policy, in such an UPDATE message so that the BGP-LS Consumers can 2571 detect the loss of link-state information for that object and not 2572 assume its deletion/withdrawal. This also makes it possible for a 2573 network operator to trace back to the BGP-LS Propagator that detected 2574 the fault with the BGP-LS Attribute. 2576 An implementation SHOULD log a message for any errors found during 2577 syntax validation for further analysis. 2579 A BGP-LS Propagator, even when it has a coexisting BGP-LS Consumer on 2580 the same node, should not perform semantic validation of the Link- 2581 State NLRI or the BGP-LS Attribute to determine if it is malformed or 2582 invalid. Some types of semantic validation that are not to be 2583 performed by a BGP-LS Propagator are as follows (and this is not to 2584 be considered as an exhaustive list): 2586 * presence of mandatory TLV 2588 * the length of a fixed-length TLV correct or the length of a 2589 variable length TLV is valid or permissible 2591 * the values of TLV fields are valid or permissible 2593 * the inclusion and use of TLVs/sub-TLVs with specific Link-State 2594 NLRI types is valid 2596 Each TLV may indicate the valid and permissible values and their 2597 semantics that can be used only by a BGP-LS Consumer for its semantic 2598 validation. However, the handling of any errors may be specific to 2599 the particular application and outside the scope of this document. 2601 8.2.3. Configuration Management 2603 An implementation SHOULD allow the operator to specify neighbors to 2604 which Link-State NLRIs will be advertised and from which Link-State 2605 NLRIs will be accepted. 2607 An implementation SHOULD allow the operator to specify the maximum 2608 rate at which Link-State NLRIs will be advertised/withdrawn from 2609 neighbors. 2611 An implementation SHOULD allow the operator to specify the maximum 2612 number of Link-State NLRIs stored in a router's Routing Information 2613 Base (RIB). 2615 An implementation SHOULD allow the operator to create abstracted 2616 topologies that are advertised to neighbors and create different 2617 abstractions for different neighbors. 2619 An implementation MUST allow the operator to configure an 8-octet 2620 BGP-LS Instance-ID. Refer to Section 5.2 for guidance to the 2621 operator for the configuration of BGP-LS Instance-ID. 2623 An implementation SHOULD allow the operator to configure ASN and BGP- 2624 LS identifiers (refer to Section 5.2.1.4). 2626 An implementation SHOULD allow the operator to configure limiting of 2627 maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS 2628 Producer or to allow larger values when they know that [RFC8654] is 2629 supported on all BGP-LS Speakers. 2631 8.2.4. Accounting Management 2633 Not Applicable. 2635 8.2.5. Performance Management 2637 An implementation SHOULD provide the following statistics: 2639 * Total number of Link-State NLRI updates sent/received 2641 * Number of Link-State NLRI updates sent/received, per neighbor 2643 * Number of errored received Link-State NLRI updates, per neighbor 2645 * Total number of locally originated Link-State NLRIs 2647 These statistics should be recorded as absolute counts since the 2648 system or session start time. An implementation MAY also enhance 2649 this information by recording peak per-second counts in each case. 2651 8.2.6. Security Management 2653 An operator MUST define an import policy to limit inbound updates as 2654 follows: 2656 * Drop all updates from peers that are only serving BGP-LS 2657 Consumers. 2659 An implementation MUST have the means to limit inbound updates. 2661 9. TLV/Sub-TLV Code Points Summary 2663 This section contains the global table of all TLVs/sub-TLVs defined 2664 in this document. 2666 +================+=========================+===================+ 2667 | TLV Code Point | Description | Reference Section | 2668 +================+=========================+===================+ 2669 | 256 | Local Node Descriptors | Section 5.2.1.2 | 2670 +----------------+-------------------------+-------------------+ 2671 | 257 | Remote Node Descriptors | Section 5.2.1.3 | 2672 +----------------+-------------------------+-------------------+ 2673 | 258 | Link Local/Remote | Section 5.2.2 | 2674 | | Identifiers | | 2675 +----------------+-------------------------+-------------------+ 2676 | 259 | IPv4 interface address | Section 5.2.2 | 2677 +----------------+-------------------------+-------------------+ 2678 | 260 | IPv4 neighbor address | Section 5.2.2 | 2679 +----------------+-------------------------+-------------------+ 2680 | 261 | IPv6 interface address | Section 5.2.2 | 2681 +----------------+-------------------------+-------------------+ 2682 | 262 | IPv6 neighbor address | Section 5.2.2 | 2683 +----------------+-------------------------+-------------------+ 2684 | 263 | Multi-Topology ID | Section 5.2.2.1 | 2685 +----------------+-------------------------+-------------------+ 2686 | 264 | OSPF Route Type | Section 5.2.3 | 2687 +----------------+-------------------------+-------------------+ 2688 | 265 | IP Reachability | Section 5.2.3 | 2689 | | Information | | 2690 +----------------+-------------------------+-------------------+ 2691 | 512 | Autonomous System | Section 5.2.1.4 | 2692 +----------------+-------------------------+-------------------+ 2693 | 513 | BGP-LS Identifier | Section 5.2.1.4 | 2694 | | (deprecated) | | 2695 +----------------+-------------------------+-------------------+ 2696 | 514 | OSPF Area-ID | Section 5.2.1.4 | 2697 +----------------+-------------------------+-------------------+ 2698 | 515 | IGP Router-ID | Section 5.2.1.4 | 2699 +----------------+-------------------------+-------------------+ 2700 | 1024 | Node Flag Bits | Section 5.3.1.1 | 2701 +----------------+-------------------------+-------------------+ 2702 | 1025 | Opaque Node Attribute | Section 5.3.1.5 | 2703 +----------------+-------------------------+-------------------+ 2704 | 1026 | Node Name | Section 5.3.1.3 | 2705 +----------------+-------------------------+-------------------+ 2706 | 1027 | IS-IS Area Identifier | Section 5.3.1.2 | 2707 +----------------+-------------------------+-------------------+ 2708 | 1028 | IPv4 Router-ID of Local | Section 5.3.1.4 / | 2709 | | Node | Section 5.3.2.1 | 2710 +----------------+-------------------------+-------------------+ 2711 | 1029 | IPv6 Router-ID of Local | Section 5.3.1.4 / | 2712 | | Node | Section 5.3.2.1 | 2713 +----------------+-------------------------+-------------------+ 2714 | 1030 | IPv4 Router-ID of | Section 5.3.2.1 | 2715 | | Remote Node | | 2716 +----------------+-------------------------+-------------------+ 2717 | 1031 | IPv6 Router-ID of | Section 5.3.2.1 | 2718 | | Remote Node | | 2719 +----------------+-------------------------+-------------------+ 2720 | 1088 | Administrative group | Section 5.3.2 | 2721 | | (color) | | 2722 +----------------+-------------------------+-------------------+ 2723 | 1089 | Maximum link bandwidth | Section 5.3.2 | 2724 +----------------+-------------------------+-------------------+ 2725 | 1090 | Max. reservable link | Section 5.3.2 | 2726 | | bandwidth | | 2727 +----------------+-------------------------+-------------------+ 2728 | 1091 | Unreserved bandwidth | Section 5.3.2 | 2729 +----------------+-------------------------+-------------------+ 2730 | 1092 | TE Default Metric | Section 5.3.2.3 | 2731 +----------------+-------------------------+-------------------+ 2732 | 1093 | Link Protection Type | Section 5.3.2 | 2733 +----------------+-------------------------+-------------------+ 2734 | 1094 | MPLS Protocol Mask | Section 5.3.2.2 | 2735 +----------------+-------------------------+-------------------+ 2736 | 1095 | IGP Metric | Section 5.3.2.4 | 2737 +----------------+-------------------------+-------------------+ 2738 | 1096 | Shared Risk Link Group | Section 5.3.2.5 | 2739 +----------------+-------------------------+-------------------+ 2740 | 1097 | Opaque Link Attribute | Section 5.3.2.6 | 2741 +----------------+-------------------------+-------------------+ 2742 | 1098 | Link Name | Section 5.3.2.7 | 2743 +----------------+-------------------------+-------------------+ 2744 | 1152 | IGP Flags | Section 5.3.3.1 | 2745 +----------------+-------------------------+-------------------+ 2746 | 1153 | IGP Route Tag | Section 5.3.3.2 | 2747 +----------------+-------------------------+-------------------+ 2748 | 1154 | IGP Extended Route Tag | Section 5.3.3.3 | 2749 +----------------+-------------------------+-------------------+ 2750 | 1155 | Prefix Metric | Section 5.3.3.4 | 2751 +----------------+-------------------------+-------------------+ 2752 | 1156 | OSPF Forwarding Address | Section 5.3.3.5 | 2753 +----------------+-------------------------+-------------------+ 2754 | 1157 | Opaque Prefix Attribute | Section 5.3.3.6 | 2755 +----------------+-------------------------+-------------------+ 2757 Table 18: Summary Table of TLV/Sub-TLV Code Points 2759 10. Security Considerations 2761 Procedures and protocol extensions defined in this document do not 2762 affect the BGP security model. See the Security Considerations 2763 section of [RFC4271] for a discussion of BGP security. Also, refer 2764 to [RFC4272] and [RFC6952] for analysis of security issues for BGP. 2766 The operator should ensure that a BGP-LS speaker does not accept 2767 UPDATE messages from a peer that only provides information to a BGP- 2768 LS Consumer by using the policy configuration options discussed in 2769 Section 8.2.3 and Section 8.2.6. Generally, an operator is aware of 2770 the BGP-LS speaker's role and link-state peerings. Therefore, the 2771 operator can protect the BGP-LS speaker from peers sending updates 2772 that may represent erroneous information, feedback loops, or false 2773 input. 2775 An error or tampering of the link-state information that is 2776 originated into BGP-LS and propagated through the network for use by 2777 BGP-LS Consumers applications can result in the malfunction of those 2778 applications. Some examples of such risks are the origination of 2779 incorrect information that is not present or consistent with the IGP 2780 LSDB at the BGP-LS Producer, incorrect ordering of TLVs in the NLRI 2781 or inconsistent origination from multiple BGP-LS Producers and 2782 updates to either the NLRI or BGP-LS Attribute during propagation 2783 (including discarding due to errors). These are not new risks from a 2784 BGP protocol perspective, however, in the case of BGP-LS impact 2785 reflects on the consumer applications instead of BGP routing 2786 functionalities. 2788 Additionally, it may be considered that the export of link-state and 2789 TE information as described in this document constitutes a risk to 2790 confidentiality of mission-critical or commercially sensitive 2791 information about the network. BGP peerings are not automatic and 2792 require configuration; thus, it is the responsibility of the network 2793 operator to ensure that only trusted BGP Speakers are configured to 2794 receive such information. Similar security considerations also arise 2795 on the interface between BGP Speaker and BGP-LS Consumers, but their 2796 discussion is outside the scope of this document. 2798 11. Contributors 2800 The following persons contributed significant text to RFC7752 and 2801 this document. They should be considered co-authors. 2803 Hannes Gredler 2804 Rtbrick 2805 Email: hannes@rtbrick.com 2807 Jan Medved 2808 Cisco Systems Inc. 2809 USA 2810 Email: jmedved@cisco.com 2812 Stefano Previdi 2813 Huawei Technologies 2814 Italy 2815 Email: stefano@previdi.net 2817 Adrian Farrel 2818 Old Dog Consulting 2819 Email: adrian@olddog.co.uk 2821 Saikat Ray 2822 Individual 2823 USA 2824 Email: raysaikat@gmail.com 2826 12. Acknowledgements 2828 This document update to the BGP-LS specification [RFC7752] is a 2829 result of feedback and inputs from the discussions in the IDR working 2830 group. It also incorporates certain details and clarifications based 2831 on implementation and deployment experience with BGP-LS. 2833 Cengiz Alaettinoglu and Parag Amritkar brought forward the need to 2834 clarify the advertisement of a LAN subnet for OSPF. 2836 We would like to thank Balaji Rajagopalan, Srihari Sangli, Shraddha 2837 Hegde, Andrew Stone, Jeff Tantsura, Acee Lindem, Les Ginsberg, Jie 2838 Dong, Aijun Wang, Nandan Saha, Joel Halpern, and Gyan Mishra for 2839 their review and feedback on this document. Thanks to Tom Petch for 2840 his review and comments on the IANA Considerations section. Would 2841 also like to thank Jeffrey Haas for his detailed shepherd review and 2842 inputs for improving the document. 2844 The detailed AD review by Alvaro Retana and his suggestions have 2845 helped improve this document significantly. 2847 We would like to thank Robert Varga for his significant contribution 2848 to RFC7752. 2850 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 2851 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 2852 Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, 2853 Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas 2854 Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, 2855 Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and 2856 Ben Campbell for their comments on RFC7752. 2858 13. References 2860 13.1. Normative References 2862 [ENTNUM] IANA, "Private Enterprise Numbers", 2863 . 2865 [ISO10589] International Organization for Standardization, 2866 "Intermediate System to Intermediate System intra-domain 2867 routeing information exchange protocol for use in 2868 conjunction with the protocol for providing the 2869 connectionless-mode network service (ISO 8473)", ISO/ 2870 IEC 10589, November 2002. 2872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2873 Requirement Levels", BCP 14, RFC 2119, 2874 DOI 10.17487/RFC2119, March 1997, 2875 . 2877 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 2878 DOI 10.17487/RFC2328, April 1998, 2879 . 2881 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2882 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2883 DOI 10.17487/RFC2545, March 1999, 2884 . 2886 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2887 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2888 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2889 . 2891 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 2892 in Support of Generalized Multi-Protocol Label Switching 2893 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 2894 . 2896 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 2897 Support of Generalized Multi-Protocol Label Switching 2898 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 2899 . 2901 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2902 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2903 DOI 10.17487/RFC4271, January 2006, 2904 . 2906 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 2907 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 2908 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 2909 June 2006, . 2911 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2912 "Multiprotocol Extensions for BGP-4", RFC 4760, 2913 DOI 10.17487/RFC4760, January 2007, 2914 . 2916 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 2917 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 2918 RFC 4915, DOI 10.17487/RFC4915, June 2007, 2919 . 2921 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 2922 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 2923 October 2007, . 2925 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 2926 Topology (MT) Routing in Intermediate System to 2927 Intermediate Systems (IS-ISs)", RFC 5120, 2928 DOI 10.17487/RFC5120, February 2008, 2929 . 2931 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 2932 Control Mechanism in IS-IS Using Administrative Tags", 2933 RFC 5130, DOI 10.17487/RFC5130, February 2008, 2934 . 2936 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 2937 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 2938 October 2008, . 2940 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2941 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2942 2008, . 2944 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 2945 in Support of Generalized Multi-Protocol Label Switching 2946 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 2947 . 2949 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2950 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2951 . 2953 [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, 2954 "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, 2955 DOI 10.17487/RFC5642, August 2009, 2956 . 2958 [RFC5890] Klensin, J., "Internationalized Domain Names for 2959 Applications (IDNA): Definitions and Document Framework", 2960 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2961 . 2963 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 2964 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 2965 February 2011, . 2967 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 2968 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 2969 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 2970 June 2012, . 2972 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2973 Patel, "Revised Error Handling for BGP UPDATE Messages", 2974 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2975 . 2977 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 2978 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 2979 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2980 2015, . 2982 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 2983 S. Shaffer, "Extensions to OSPF for Advertising Optional 2984 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 2985 February 2016, . 2987 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2988 Writing an IANA Considerations Section in RFCs", BCP 26, 2989 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2990 . 2992 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2993 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2994 May 2017, . 2996 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 2997 F. Baker, "OSPFv3 Link State Advertisement (LSA) 2998 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2999 2018, . 3001 [RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message 3002 Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October 3003 2019, . 3005 13.2. Informative References 3007 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 3008 J., and E. Lear, "Address Allocation for Private 3009 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 3010 February 1996, . 3012 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 3013 RFC 4272, DOI 10.17487/RFC4272, January 2006, 3014 . 3016 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 3017 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 3018 2006, . 3020 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 3021 Computation Element (PCE)-Based Architecture", RFC 4655, 3022 DOI 10.17487/RFC4655, August 2006, 3023 . 3025 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 3026 Per-Domain Path Computation Method for Establishing Inter- 3027 Domain Traffic Engineering (TE) Label Switched Paths 3028 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 3029 . 3031 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 3032 Support of Inter-Autonomous System (AS) MPLS and GMPLS 3033 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 3034 January 2009, . 3036 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 3037 Optimization (ALTO) Problem Statement", RFC 5693, 3038 DOI 10.17487/RFC5693, October 2009, 3039 . 3041 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 3042 Management of New Protocols and Protocol Extensions", 3043 RFC 5706, DOI 10.17487/RFC5706, November 2009, 3044 . 3046 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 3047 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 3048 March 2012, . 3050 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 3051 BGP, LDP, PCEP, and MSDP Issues According to the Keying 3052 and Authentication for Routing Protocols (KARP) Design 3053 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 3054 . 3056 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 3057 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 3058 "Application-Layer Traffic Optimization (ALTO) Protocol", 3059 RFC 7285, DOI 10.17487/RFC7285, September 2014, 3060 . 3062 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 3063 S. Ray, "North-Bound Distribution of Link-State and 3064 Traffic Engineering (TE) Information Using BGP", RFC 7752, 3065 DOI 10.17487/RFC7752, March 2016, 3066 . 3068 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 3069 "Advertisement of Multiple Paths in BGP", RFC 7911, 3070 DOI 10.17487/RFC7911, July 2016, 3071 . 3073 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 3074 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 3075 2017, . 3077 [RFC9029] Farrel, A., "Updates to the Allocation Policy for the 3078 Border Gateway Protocol - Link State (BGP-LS) Parameters 3079 Registries", RFC 9029, DOI 10.17487/RFC9029, June 2021, 3080 . 3082 [RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS- 3083 IS Extensions in Support of Inter-Autonomous System (AS) 3084 MPLS and GMPLS Traffic Engineering", RFC 9346, 3085 DOI 10.17487/RFC9346, February 2023, 3086 . 3088 Appendix A. Changes from RFC 7752 3090 This section lists the high-level changes from RFC 7752 and provides 3091 reference to the document sections wherein those have been 3092 introduced. 3094 1. Updated the Figure 1 in Section 1 and added Section 3 to 3095 illustrate the different roles of a BGP implementation in 3096 conveying link-state information. 3098 2. Clarified aspects related to advertisement of link-state 3099 information from IGPs into BGP-LS in Section 4. 3101 3. In Section 5.1, clarification about the TLV handling aspects 3102 that apply to both the NLRI and BGP-LS Attribute parts and those 3103 that are applicable only for the NLRI portion. An 3104 implementation may have missed the part about the handling of 3105 unknown TLV and so, based on [RFC7606] guidelines, might discard 3106 the unknown NLRI types. This aspect is now unambiguously 3107 clarified in Section 5.2. Also, the TLVs in the BGP-LS 3108 Attribute that are not ordered are not to be considered 3109 malformed. 3111 4. Clarification of mandatory and optional TLVs in both NLRI and 3112 BGP-LS Attribute portions all through the document. 3114 5. Handling of large size of BGP-LS Attribute with growth in BGP-LS 3115 information is explained in Section 5.3 along with mitigation of 3116 errors arising out of it. 3118 6. Clarified that the document describes the NLRI descriptor TLVs 3119 for the protocols and NLRI types specified in this document and 3120 future BGP-LS extensions must describe the same for other 3121 protocols and NLRI types that they introduce. 3123 7. Clarification on the use of the Identifier field in the Link- 3124 State NLRI in Section 5.2 is provided. It was defined 3125 ambiguously to refer to only multi-instance IGP on a single link 3126 while it can also be used for multiple IGP protocol instances on 3127 a router. The IANA registry is accordingly being removed. 3129 8. The BGP-LS Identifier TLV in the Node Descriptors has been 3130 deprecated. Its use was not well specified by [RFC7752] and 3131 there has been some amount of confusion between implementators 3132 on its usage for identification of IGP domains as against the 3133 use of the Identifier field carrying the BGP-LS Instance-ID when 3134 running multiple instances of IGP routing protocols. The 3135 original purpose of the BGP-LS Identifier was that, in 3136 conjunction with Autonomous System Number (ASN), it would 3137 uniquely identify the BGP-LS domain and that the combination of 3138 ASN and BGP-LS ID would be globally unique. However, the BGP-LS 3139 Instance-ID carried in the Identifier field in the fixed part of 3140 the NLRI also provides a similar functionality. Hence, the 3141 inclusion of the BGP-LS Identifier TLV is not necessary. If 3142 advertised, all BGP-LS speakers within an IGP flooding-set (set 3143 of IGP nodes within which an LSP/LSA is flooded) had to use the 3144 same (ASN, BGP-LS ID) tuple and if an IGP domain consists of 3145 multiple flooding-sets, then all BGP-LS speakers within the IGP 3146 domain had to use the same (ASN, BGP-LS ID) tuple. 3148 9. Clarification that the Area-ID TLV is mandatory in the Node 3149 Descriptor for the origination of information from OSPF except 3150 for when sourcing information from AS-scope LSAs where this TLV 3151 is not applicable. Also clarified on the IS-IS area and area 3152 addresses. 3154 10. Moved MT-ID TLV from the Node Descriptor section to under the 3155 Link Descriptor section since it is not a Node Descriptor sub- 3156 TLV. Fixed the ambiguity in the encoding of OSPF MT-ID in this 3157 TLV. Updated the IS-IS specification reference section and 3158 describe the differences in the applicability of the R flags 3159 when MT-ID TLV is used as link descriptor TLV and Prefix 3160 Attribute TLV. MT-ID TLV use is now elevated to SHOULD when it 3161 is enabled in the underlying IGP. 3163 11. Clarified that IPv6 Link-Local Addresses are not advertised in 3164 the Link Descriptor TLVs and the local/remote identifiers are to 3165 be used instead for links with IPv6 link-local addresses only. 3167 12. Update the usage of OSPF Route Type TLV to mandate its use for 3168 OSPF prefixes in Section 5.2.3.1 since this is required for 3169 segregation of intra-area prefixes that are used to reach a node 3170 (e.g. a loopback) from other types of inter-area and external 3171 prefixes. 3173 13. Clarification of the specific OSPFv2 and OSPFv3 protocol TLV 3174 space to be used in the node, link, and prefix opaque attribute 3175 TLVs. 3177 14. Clarification on the length of the Node Flag Bits and IGP Flags 3178 TLVs to be one octet. 3180 15. Updated the Node Name TLV in Section 5.3.1.3 with the OSPF 3181 specification. 3183 16. Clarification on the size of the IS-IS Narrow Metric 3184 advertisement via the IGP Metric TLV and the handling of the 3185 unused bits. 3187 17. Clarified the advertisement of the prefix corresponding to the 3188 LAN segment in an OSPF network in Section 5.11. 3190 18. Clarified the advertisement and support for OSPF specific 3191 concepts like Virtual links, Sham links, and Type 4 LSAs in 3192 Section 5.7 and Section 5.8. 3194 19. Introduced Private Use TLV code point space and specified their 3195 encoding in Section 5.4. 3197 20. Introduced Section 5.9 where issues related to the consistency 3198 of reporting IGP link-state along with their solutions are 3199 covered. 3201 21. Added recommendation for isolation of BGP-LS sessions from other 3202 BGP route exchange to avoid errors and faults in BGP-LS 3203 affecting the normal BGP routing. 3205 22. Updated the Fault Management section with detailed rules based 3206 on the role of the BGP Speaker in the BGP-LS information 3207 propagation flow. 3209 23. Change to the management of BGP-LS IANA registries from 3210 "Specification Required" to "Expert Review" along with updated 3211 guidelines for Designated Experts. More specifically the 3212 inclusion of changes introduced via [RFC9029] that is obsoleted 3213 by this document. 3215 24. Added BGP-LS IANA registries with "Expert Review" policy for the 3216 flag fields of various TLVs that was missed out. Renamed the 3217 BGP-LS TLV registry and removed the "IS-IS TLV/Sub-TLV" column 3218 from it. 3220 Author's Address 3222 Ketan Talaulikar (editor) 3223 Cisco Systems 3224 India 3225 Email: ketant.ietf@gmail.com