idnits 2.17.00 (12 Aug 2021) /tmp/idnits14679/draft-ietf-idr-rfc7752bis-10.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 : ---------------------------------------------------------------------------- -- 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 (November 10, 2021) is 185 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. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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) November 10, 2021 5 Intended status: Standards Track 6 Expires: May 14, 2022 8 Distribution of Link-State and Traffic Engineering Information Using BGP 9 draft-ietf-idr-rfc7752bis-10 11 Abstract 13 In a number of environments, a component external to a network is 14 called upon to perform computations based on the network topology and 15 the 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 new BGP Network Layer Reachability Information (NLRI) encoding 23 format. The mechanism is applicable to physical and virtual 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 RFC 7752 by completely replacing that 30 document. It makes some small changes and clarifications to the 31 previous specification. This document also obsoletes RFC 9029 by 32 incorporating the updates which it made to RFC 7752. 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 May 14, 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 2. Motivation and Applicability . . . . . . . . . . . . . . . . 6 70 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 6 71 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 72 3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 8 73 4. Carrying Link-State Information in BGP . . . . . . . . . . . 9 74 4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 11 76 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 15 77 4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 19 78 4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 22 79 4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 24 80 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 24 81 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 28 82 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 33 83 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 37 84 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 37 85 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 38 86 4.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 38 87 4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 38 88 4.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 38 89 4.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 40 90 4.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 41 91 4.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 42 92 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 43 93 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 43 94 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 44 95 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 44 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 98 6.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 45 99 6.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 45 100 6.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 46 101 6.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 46 102 6.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 46 103 6.1.5. BGP-LS MPLS Protocol Mask Registry . . . . . . . . . 47 104 6.1.6. BGP-LS IGP Prefix Flags Registry . . . . . . . . . . 47 105 6.1.7. BGP-LS TLVs Registry . . . . . . . . . . . . . . . . 47 106 6.2. Guidance for Designated Experts . . . . . . . . . . . . . 48 107 7. Manageability Considerations . . . . . . . . . . . . . . . . 49 108 7.1. Operational Considerations . . . . . . . . . . . . . . . 49 109 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 49 110 7.1.2. Installation and Initial Setup . . . . . . . . . . . 49 111 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 50 112 7.1.4. Requirements on Other Protocols and Functional 113 Components . . . . . . . . . . . . . . . . . . . . . 50 114 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 50 115 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 50 116 7.2. Management Considerations . . . . . . . . . . . . . . . . 50 117 7.2.1. Management Information . . . . . . . . . . . . . . . 50 118 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 50 119 7.2.3. Configuration Management . . . . . . . . . . . . . . 53 120 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 53 121 7.2.5. Performance Management . . . . . . . . . . . . . . . 54 122 7.2.6. Security Management . . . . . . . . . . . . . . . . . 54 123 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 54 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55 125 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 126 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 128 12.1. Normative References . . . . . . . . . . . . . . . . . . 57 129 12.2. Informative References . . . . . . . . . . . . . . . . . 61 130 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 62 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64 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) in order 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 require 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 in order to be able to 150 fulfill 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 new BGP Network Layer Reachability Information 156 (NLRI) encoding format. The mechanism is applicable to physical and 157 virtual links. The mechanism described is subject to policy control. 159 A router maintains one or more databases for storing link-state 160 information about nodes and links in any given area. Link attributes 161 stored in these databases include: local/remote IP addresses, local/ 162 remote interface identifiers, link metric, and TE metric, link 163 bandwidth, reservable bandwidth, per Class-of-Service (CoS) class 164 reservation state, preemption, and Shared Risk Link Groups (SRLGs). 165 The router's BGP process can retrieve topology from these LSDBs and 166 distribute it to a consumer, either directly or via a peer BGP 167 speaker (typically a dedicated Route Reflector), using the encoding 168 specified in this document. 170 An illustration of the collection of link-state and TE information 171 and its distribution to consumers is shown in Figure 1 below. 173 +-----------+ 174 | Consumer | 175 +-----------+ 176 ^ 177 | 178 +-----------+ +-----------+ 179 | BGP | | BGP | 180 | Speaker |<----------->| Speaker | +-----------+ 181 | RR1 | | RRm | | Consumer | 182 +-----------+ +-----------+ +-----------+ 183 ^ ^ ^ ^ 184 | | | | 185 +-----+ +---------+ +---------+ | 186 | | | | 187 +-----------+ +-----------+ +-----------+ 188 | BGP | | BGP | | BGP | 189 | Speaker | | Speaker | . . . | Speaker | 190 | R1 | | R2 | | Rn | 191 +-----------+ +-----------+ +-----------+ 192 ^ ^ ^ 193 | | | 194 IGP IGP IGP 196 Figure 1: Collection of Link-State and TE Information 198 A BGP speaker may apply a configurable policy to the information that 199 it distributes. Thus, it may distribute the real physical topology 200 from the LSDB or the TED. Alternatively, it may create an abstracted 201 topology, where virtual, aggregated nodes are connected by virtual 202 paths. Aggregated nodes can be created, for example, out of multiple 203 routers in a Point of Presence (POP). Abstracted topology can also 204 be a mix of physical and virtual nodes and physical and virtual 205 links. Furthermore, the BGP speaker can apply policy to determine 206 when information is updated to the consumer so that there is a 207 reduction of information flow from the network to the consumers. 208 Mechanisms through which topologies can be aggregated or virtualized 209 are outside the scope of this document. 211 This document obsoletes [RFC7752] by completely replacing that 212 document. It makes some small changes and clarifications to the 213 previous specification as documented in Appendix A. 215 1.1. Requirements Language 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL" in this document are to be interpreted as described in BCP 220 14 [RFC2119] [RFC8174] when, and only when, they appear in all 221 capitals, as shown here. 223 2. Motivation and Applicability 225 This section describes use cases from which the requirements can be 226 derived. 228 2.1. MPLS-TE with PCE 230 As described in [RFC4655], a PCE can be used to compute MPLS-TE paths 231 within a "domain" (such as an IGP area) or across multiple domains 232 (such as a multi-area AS or multiple ASes). 234 o Within a single area, the PCE offers enhanced computational power 235 that may not be available on individual routers, sophisticated 236 policy control and algorithms, and coordination of computation 237 across the whole area. 239 o If a router wants to compute an MPLS-TE path across IGP areas, 240 then its own TED lacks visibility of the complete topology. That 241 means that the router cannot determine the end-to-end path and 242 cannot even select the right exit router (Area Border Router 243 (ABR)) for an optimal path. This is an issue for large-scale 244 networks that need to segment their core networks into distinct 245 areas but still want to take advantage of MPLS-TE. 247 Previous solutions used per-domain path computation [RFC5152]. The 248 source router could only compute the path for the first area because 249 the router only has full topological visibility for the first area 250 along the path, but not for subsequent areas. Per-domain path 251 computation uses a technique called "loose-hop-expansion" [RFC3209] 252 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 253 using the IGP-computed shortest path topology for the remainder of 254 the path. This may lead to sub-optimal paths, makes alternate/back- 255 up path computation hard, and might result in no TE path being found 256 when one really does exist. 258 The PCE presents a computation server that may have visibility into 259 more than one IGP area or AS, or may cooperate with other PCEs to 260 perform distributed path computation. The PCE obviously needs access 261 to the TED for the area(s) it serves, but [RFC4655] does not describe 262 how this is achieved. Many implementations make the PCE a passive 263 participant in the IGP so that it can learn the latest state of the 264 network, but this may be sub-optimal when the network is subject to a 265 high degree of churn or when the PCE is responsible for multiple 266 areas. 268 The following figure shows how a PCE can get its TED information 269 using the mechanism described in this document. 271 +----------+ +---------+ 272 | ----- | | BGP | 273 | | TED |<-+-------------------------->| Speaker | 274 | ----- | TED synchronization | | 275 | | | mechanism: +---------+ 276 | | | BGP with Link-State NLRI 277 | v | 278 | ----- | 279 | | PCE | | 280 | ----- | 281 +----------+ 282 ^ 283 | Request/ 284 | Response 285 v 286 Service +----------+ Signaling +----------+ 287 Request | Head-End | Protocol | Adjacent | 288 -------->| Node |<------------>| Node | 289 +----------+ +----------+ 291 Figure 2: External PCE Node Using a TED Synchronization Mechanism 293 The mechanism in this document allows the necessary TED information 294 to be collected from the IGP within the network, filtered according 295 to configurable policy, and distributed to the PCE as necessary. 297 2.2. ALTO Server Network API 299 An ALTO server [RFC5693] is an entity that generates an abstracted 300 network topology and provides it to network-aware applications over a 301 web-service-based API. Example applications are peer-to-peer (P2P) 302 clients or trackers, or Content Distribution Networks (CDNs). The 303 abstracted network topology comes in the form of two maps: a Network 304 Map that specifies the allocation of prefixes to Partition 305 Identifiers (PIDs), and a Cost Map that specifies the cost between 306 PIDs listed in the Network Map. For more details, see [RFC7285]. 308 ALTO abstract network topologies can be auto-generated from the 309 physical topology of the underlying network. The generation would 310 typically be based on policies and rules set by the operator. Both 311 prefix and TE data are required: prefix data is required to generate 312 ALTO Network Maps and TE (topology) data is required to generate ALTO 313 Cost Maps. Prefix data is carried and originated in BGP, and TE data 314 is originated and carried in an IGP. The mechanism defined in this 315 document provides a single interface through which an ALTO server can 316 retrieve all the necessary prefix and network topology data from the 317 underlying network. Note that an ALTO server can use other 318 mechanisms to get network data, for example, peering with multiple 319 IGP and BGP speakers. 321 The following figure shows how an ALTO server can get network 322 topology information from the underlying network using the mechanism 323 described in this document. 325 +--------+ 326 | Client |<--+ 327 +--------+ | 328 | ALTO +--------+ BGP with +---------+ 329 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 330 | Client |<--+------------| Server |<----------------| Speaker | 331 +--------+ | | | | | 332 | +--------+ +---------+ 333 +--------+ | 334 | Client |<--+ 335 +--------+ 337 Figure 3: ALTO Server Using Network Topology Information 339 3. BGP Speaker Roles for BGP-LS 341 In the illustration shown in Figure 1, the BGP Speakers can be seen 342 playing different roles in the distribution of information using BGP- 343 LS. This section introduces terms that explain the different roles 344 of the BGP Speakers which are then used through the rest of this 345 document. 347 o BGP-LS Producer: The BGP Speakers R1, R2, ... Rn, originate link- 348 state information from their underlying link-state IGP protocols 349 into BGP-LS. If R1 and R2 are in the same IGP area, then likely 350 they are originating the same link-state information into BGP-LS. 351 R1 may also source information from sources other than IGP, e.g. 352 its local node information. The term BGP-LS Producer refers to 353 the BGP Speaker that is originating link-state information into 354 BGP. 356 o BGP-LS Consumer: The BGP Speakers RR1 and Rn are handing off the 357 BGP-LS information that they have collected to a consumer 358 application. The BGP protocol implementation and the consumer 359 application may be on the same or different nodes. The term BGP- 360 LS Consumer refers to the consumer application/process and not the 361 BGP Speaker. This document only covers the BGP implementation. 362 The consumer application and the design of the interface between 363 BGP and consumer application may be implementation specific and 364 outside the scope of this document. 366 o BGP-LS Propagator: The BGP Speaker RRm propagates the BGP-LS 367 information between the BGP Speaker Rn and the BGP Speaker RR1. 368 The BGP implementation on RRm is doing the propagation of BGP-LS 369 updates and performing BGP best path calculations. Similarly, the 370 BGP Speaker RR1 is receiving BGP-LS information from R1, R2 and 371 RRm and propagating the information to the BGP-LS Consumer after 372 performing BGP best path calculations. The term BGP-LS Propagator 373 refers to the BGP Speaker that is performing BGP protocol 374 processing on the link-state information. 376 The above roles are not mutually exclusive. The same BGP Speaker may 377 be the producer for some link-state information and propagator for 378 some other link-state information while also providing this 379 information to a consumer application. Nothing precludes a BGP 380 implementation performing some of the validation and processing on 381 behalf of the BGP-LS Consumer as long as it does not impact the 382 semantics of its role as BGP-LS Propagator as described in this 383 document. 385 The rest of this document refers to the role when describing 386 procedures that are specific to that role. When the role is not 387 specified, then the said procedure applies to all BGP Speakers. 389 4. Carrying Link-State Information in BGP 391 This specification contains two parts: definition of a new BGP NLRI 392 that describes links, nodes, and prefixes comprising IGP link-state 393 information and definition of a new BGP path attribute (BGP-LS 394 Attribute) that carries link, node, and prefix properties and 395 attributes, such as the link and prefix metric or auxiliary Router- 396 IDs of nodes, etc. 398 It is desirable to keep the dependencies on the protocol source of 399 this attribute to a minimum and represent any content in an IGP- 400 neutral way, such that applications that want to learn about a link- 401 state topology do not need to know about any OSPF or IS-IS protocol 402 specifics. 404 This section mainly describes the procedures at a BGP-LS Producer 405 that originate link-state information into BGP-LS. 407 4.1. TLV Format 409 Information in the new Link-State NLRIs and the BGP-LS Attribute is 410 encoded in Type/Length/Value triplets. The TLV format is shown in 411 Figure 4 and applies to both the NLRI and the BGP-LS Attribute 412 encodings. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 // Value (variable) // 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 4: TLV Format 424 The Length field defines the length of the value portion in octets 425 (thus, a TLV with no value portion would have a length of zero). The 426 TLV is not padded to 4-octet alignment. Unknown and unsupported 427 types MUST be preserved and propagated within both the NLRI and the 428 BGP-LS Attribute. The presence of unrecognized or unexpected TLVs 429 MUST NOT result in the NLRI or the BGP-LS Attribute being considered 430 as malformed. 432 To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be 433 ordered in ascending order by TLV Type. If there are multiple TLVs 434 of the same type within a single NLRI, then the TLVs sharing the same 435 type MUST be in ascending order based on the value field. Comparison 436 of the value fields is performed by treating the entire field as 437 opaque binary data and ordered lexicographically. NLRIs having TLVs 438 which do not follow the above ordering rules MUST be considered as 439 malformed by a BGP-LS Propagator. This ensures that multiple copies 440 of the same NLRI from multiple BGP-LS Producers and the ambiguity 441 arising therefrom is prevented. 443 All TLVs within the NLRI that are not specified as mandatory are 444 considered optional. All TLVs within the BGP-LS Attribute are 445 considered optional unless specified otherwise. 447 The TLVs within the BGP-LS Attribute SHOULD be ordered in ascending 448 order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be 449 considered malformed. 451 When there are multiple BGP-LS Producers originating the same link- 452 state information, implementation variations of BGP-LS Producers may 453 result in the generation of different and inconsistent BGP-LS updates 454 for the same link-state object based on the inclusion or exclusion of 455 optional TLVs. An inconsistency between BGP-LS Producers with 456 regards to the inclusion of optional TLVs in the NLRI results in 457 multiple NLRIs being generated for the same link-state object. A 458 BGP-LS Consumer would need the ability to merge such duplicate 459 updates to handle such situations. An inconsistency between BGP-LS 460 Producers with regards to the inclusion of optional TLVs in the BGP- 461 LS Attribute results in one of them being delivered to a BGP-LS 462 Consumer as part the BGP propagation and best-path selection 463 procedures in most typical deployments. This can result in a BGP-LS 464 Consumer missing out on some of the information in a potentially 465 unpredictable manner. The use of BGP-LS Producers that have a 466 consistent support for the origination of optional TLVs between them 467 can help mitigate such situations for the BGP-LS Consumers. 469 4.2. The Link-State NLRI 471 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 472 for carrying opaque information. This specification defines three 473 Link-State NLRI types that describe either a node, a link, or a 474 prefix. 476 All non-VPN link, node, and prefix information SHALL be encoded using 477 AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be 478 encoded using AFI 16388 / SAFI 72. 480 For two BGP speakers to exchange Link-State NLRI, they MUST use BGP 481 Capabilities Advertisement to ensure that they are both capable of 482 properly processing such NLRI. This is done as specified in 483 [RFC4760], by using capability code 1 (multi-protocol BGP), with AFI 484 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN. 486 New Link-State NLRI Types may be introduced in the future. Since 487 supported NLRI type values within the address family are not 488 expressed in the Multiprotocol BGP (MP-BGP) capability [RFC4760], it 489 is possible that a BGP speaker has advertised support for Link-State 490 but does not support a particular Link-State NLRI type. To allow the 491 introduction of new Link-State NLRI types seamlessly in the future, 492 without the need for upgrading all BGP speakers in the propagation 493 path (e.g. a route reflector), this document deviates from the 494 default handling behavior specified by [RFC7606] for Link-State 495 address-family. An implementation MUST handle unrecognized Link- 496 State NLRI types as opaque objects and MUST preserve and propagate 497 them. 499 The format of the Link-State NLRI is shown in the following figures. 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | NLRI Type | Total NLRI Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | | 507 // Link-State NLRI (variable) // 508 | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | NLRI Type | Total NLRI Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 + Route Distinguisher (8 octets) + 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 // Link-State NLRI (variable) // 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format 529 The Total NLRI Length field contains the cumulative length, in 530 octets, of the rest of the NLRI, not including the NLRI Type field or 531 itself. For VPN applications, it also includes the length of the 532 Route Distinguisher. 534 +------+---------------------------+ 535 | Type | NLRI Type | 536 +------+---------------------------+ 537 | 1 | Node NLRI | 538 | 2 | Link NLRI | 539 | 3 | IPv4 Topology Prefix NLRI | 540 | 4 | IPv6 Topology Prefix NLRI | 541 +------+---------------------------+ 543 Table 1: NLRI Types 545 Route Distinguishers are defined and discussed in [RFC4364]. 547 The Node NLRI (NLRI Type = 1) is shown in the following figure. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+ 552 | Protocol-ID | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Identifier | 555 + (8 octets) + 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 // Local Node Descriptors (variable) // 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 7: The Node NLRI Format 563 The Link NLRI (NLRI Type = 2) is shown in the following figure. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+ 568 | Protocol-ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Identifier | 571 + (8 octets) + 572 | | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 // Local Node Descriptors (variable) // 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 // Remote Node Descriptors (variable) // 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 // Link Descriptors (variable) // 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 8: The Link NLRI Format 583 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 584 same format, as shown in the following figure. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+ 589 | Protocol-ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Identifier | 592 + (8 octets) + 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 // Local Node Descriptors (variable) // 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 // Prefix Descriptors (variable) // 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format 602 The Protocol-ID field can contain one of the following values: 604 +-------------+----------------------------------+ 605 | Protocol-ID | NLRI information source protocol | 606 +-------------+----------------------------------+ 607 | 1 | IS-IS Level 1 | 608 | 2 | IS-IS Level 2 | 609 | 3 | OSPFv2 | 610 | 4 | Direct | 611 | 5 | Static configuration | 612 | 6 | OSPFv3 | 613 +-------------+----------------------------------+ 615 Table 2: Protocol Identifiers 617 The 'Direct' and 'Static configuration' protocol types SHOULD be used 618 when BGP-LS is sourcing local information. For all information 619 derived from other protocols, the corresponding Protocol-ID MUST be 620 used. If BGP-LS has direct access to interface information and wants 621 to advertise a local link, then the Protocol-ID 'Direct' SHOULD be 622 used. For modeling virtual links, such as described in Section 5, 623 the Protocol-ID 'Static configuration' SHOULD be used. 625 A router MAY run multiple protocol instances of OSPF or ISIS whereby 626 it becomes a border router between multiple IGP domains. Both OSPF 627 and IS-IS MAY also run multiple routing protocol instances over the 628 same link. See [RFC8202] and [RFC6549]. These instances define 629 independent IGP routing domains. The Identifier field carries a 630 64-bit BGP-LS Instance Identifier (Instance-ID) number that is used 631 to identify the IGP routing domain where the NLRI belongs. The NLRIs 632 representing link-state objects (nodes, links, or prefixes) from the 633 same IGP routing instance MUST have the same Identifier field value. 635 NLRIs with different Identifier field values MUST be considered to be 636 from different IGP routing instances. The Identifier field value 0 637 is RECOMMENDED to be used when there is only a single protocol 638 instance in the network where BGP-LS is operational. 640 An implementation that supports multiple IGP instances MUST support 641 the configuration of unique BGP-LS Instance-IDs at the routing 642 protocol instance level. The network operator MUST assign consistent 643 BGP-LS Instance-ID values on all BGP-LS Producers within a given IGP 644 domain. Unique BGP-LS Instance-ID values MUST be assigned to routing 645 protocol instances operating in different IGP domains. This allows 646 the BGP-LS Consumer to build an accurate segregated multi-domain 647 topology based on the Identifier field even when the topology is 648 advertised via BGP-LS by multiple BGP-LS Producers in the network. 650 When the above-described semantics and recommendations are not 651 followed, a BGP-LS Consumer may see duplicate link-state objects for 652 the same node, link, or prefix when there are multiple BGP-LS 653 Producers deployed. This may also result in the BGP-LS Consumers 654 getting an inaccurate network-wide topology. 656 When adding, removing, or modifying a TLV/sub-TLV from a Link-State 657 NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it 658 in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in- 659 consistent link-state objects hanging around in the BGP-LS table. 661 Each Node Descriptor, Link Descriptor, and Prefix Descriptor consists 662 of one or more TLVs, as described in the following sections. These 663 Descriptor TLVs are applicable for the Node, Link, and Prefix NLRI 664 Types for the protocols that are listed in Table 2. Documents 665 extending BGP-LS specifications with new NLRI Types and/or protocols 666 MUST specify the NLRI Descriptors for them. 668 4.2.1. Node Descriptors 670 Each link is anchored by a pair of Router-IDs that are used by the 671 underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit 672 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 673 additional auxiliary Router-IDs, mainly for Traffic Engineering 674 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 675 Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be 676 included in the node attribute described in Section 4.3.1 and MAY be 677 included in the link attribute described in Section 4.3.2. The 678 advertisement of the TE Router-IDs helps a BGP-LS Consumer to 679 correlate multiple link-state objects (e.g. in different IGP 680 instances or areas/levels) to the same node in the network. 682 It is desirable that the Router-ID assignments inside the Node 683 Descriptor are globally unique. However, there may be Router-ID 684 spaces (e.g., ISO) where no global registry exists, or worse, Router- 685 IDs have been allocated following the private-IP allocation described 686 in RFC 1918 [RFC1918]. BGP-LS uses the Autonomous System (AS) Number 687 to disambiguate the Router-IDs, as described in Section 4.2.1.1. 689 4.2.1.1. Globally Unique Node/Link/Prefix Identifiers 691 One problem that needs to be addressed is the ability to identify an 692 IGP node globally (by "globally", we mean within the BGP-LS database 693 collected by all BGP-LS speakers that talk to each other). This can 694 be expressed through the following two requirements: 696 (A) The same node MUST NOT be represented by two keys (otherwise, 697 one node will look like two nodes). 699 (B) Two different nodes MUST NOT be represented by the same key 700 (otherwise, two nodes will look like one node). 702 We define an "IGP domain" to be the set of nodes (hence, by extension 703 links and prefixes) within which each node has a unique IGP 704 representation by using the combination of Area-ID, Router-ID, 705 Protocol-ID, Multi-Topology ID, and Instance-ID. The problem is that 706 BGP may receive node/link/prefix information from multiple 707 independent "IGP domains", and we need to distinguish between them. 708 Moreover, we can't assume there is always one and only one IGP domain 709 per AS. During IGP transitions, it may happen that two redundant 710 IGPs are in place. 712 The mapping of the Instance-ID to the Identifier field as described 713 earlier along with a set of sub-TLVs described in Section 4.2.1.4, 714 allows specification of a flexible key for any given node/link 715 information such that the global uniqueness of the NLRI is ensured. 717 4.2.1.2. Local Node Descriptors 719 The Local Node Descriptors TLV contains Node Descriptors for the node 720 anchoring the local end of the link. This is a mandatory TLV in all 721 three types of NLRIs (node, link, and prefix). The Type is 256. The 722 length of this TLV is variable. The value contains one or more Node 723 Descriptor Sub-TLVs defined in Section 4.2.1.4. 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Type | Length | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | 731 // Node Descriptor Sub-TLVs (variable) // 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Figure 10: Local Node Descriptors TLV Format 737 4.2.1.3. Remote Node Descriptors 739 The Remote Node Descriptors TLV contains Node Descriptors for the 740 node anchoring the remote end of the link. This is a mandatory TLV 741 for Link NLRIs. The type is 257. The length of this TLV is 742 variable. The value contains one or more Node Descriptor Sub-TLVs 743 defined in Section 4.2.1.4. 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Type | Length | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 // Node Descriptor Sub-TLVs (variable) // 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 11: Remote Node Descriptors TLV Format 757 4.2.1.4. Node Descriptor Sub-TLVs 759 The Node Descriptor Sub-TLV type code points and lengths are listed 760 in the following table: 762 +--------------------+--------------------------------+----------+ 763 | Sub-TLV Code Point | Description | Length | 764 +--------------------+--------------------------------+----------+ 765 | 512 | Autonomous System | 4 | 766 | 513 | BGP-LS Identifier (deprecated) | 4 | 767 | 514 | OSPF Area-ID | 4 | 768 | 515 | IGP Router-ID | Variable | 769 +--------------------+--------------------------------+----------+ 771 Table 3: Node Descriptor Sub-TLVs 773 The sub-TLV values in Node Descriptor TLVs are defined as follows: 775 Autonomous System: Opaque value (32-bit AS Number). This is an 776 optional TLV. The value SHOULD be set to the AS Number associated 777 with the BGP process originating the link-state information. An 778 implementation MAY provide a configuration option on the BGP-LS 779 Producer to use a different value; e.g., to avoid collisions when 780 using private AS numbers. 782 BGP-LS Identifier: Opaque value (32-bit ID). This is an optional 783 TLV. In conjunction with Autonomous System Number (ASN), uniquely 784 identifies the BGP-LS domain. The combination of ASN and BGP-LS 785 ID MUST be globally unique. All BGP-LS speakers within an IGP 786 flooding-set (set of IGP nodes within which an LSP/LSA is flooded) 787 MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists 788 of multiple flooding-sets, then all BGP-LS speakers within the IGP 789 domain SHOULD use the same ASN, BGP-LS ID tuple. 791 Area-ID: Used to identify the 32-bit area to which the information 792 advertised in the NLRI belongs. This is a mandatory TLV when 793 originating information from OSPF that is derived from area-scope 794 LSAs. The Area Identifier allows different NLRIs of the same 795 router to be discriminated on a per-area basis. It is not used 796 for NLRIs when carrying information that is derived from AS-scope 797 LSAs as that information is not associated with a specific area. 799 IGP Router-ID: Opaque value. This is a mandatory TLV when 800 originating information from IS-IS, OSPF, direct or static. For 801 an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO 802 system-ID). For an IS-IS pseudonode corresponding to a LAN, this 803 contains the 6-octet ISO Node-ID of the Designated Intermediate 804 System (DIS) followed by a 1-octet, nonzero PSN identifier (7 805 octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this 806 contains the 4-octet Router-ID. For an OSPFv2 pseudonode 807 representing a LAN, this contains the 4-octet Router-ID of the 808 Designated Router (DR) followed by the 4-octet IPv4 address of the 809 DR's interface to the LAN (8 octets in total). Similarly, for an 810 OSPFv3 pseudonode, this contains the 4-octet Router-ID of the DR 811 followed by the 4-octet interface identifier of the DR's interface 812 to the LAN (8 octets in total). The TLV size in combination with 813 the protocol identifier enables the decoder to determine the type 814 of the node. For Direct or Static configuration, the value SHOULD 815 be taken from an IPv4 or IPv6 address (e.g. loopback interface) 816 configured on the node. 818 There can be at most one instance of each sub-TLV type present in any 819 Node Descriptor. The sub-TLVs within a Node Descriptor MUST be 820 arranged in ascending order by sub-TLV type. This needs to be done 821 to compare NLRIs, even when an implementation encounters an unknown 822 sub-TLV. Using stable sorting, an implementation can do a binary 823 comparison of NLRIs and hence allow incremental deployment of new key 824 sub-TLVs. 826 The BGP-LS Identifier was introduced by [RFC7752] and its use is 827 being deprecated by this document. Implementations MUST continue to 828 support this sub-TLV for backward compatibility. The default value 829 of 0 is RECOMMENDED to be used when a BGP-LS Producer includes this 830 sub-TLV when originating information into BGP-LS. Implementations 831 MAY provide an option to configure this value for backward 832 compatibility reasons. The use of the Instance-ID in the Identifier 833 field is the RECOMMENDED way of segregation of different IGP domains 834 in BGP-LS. 836 4.2.2. Link Descriptors 838 The Link Descriptor field is a set of Type/Length/Value (TLV) 839 triplets. The format of each TLV is shown in Section 4.1. The Link 840 Descriptor TLVs uniquely identify a link among multiple parallel 841 links between a pair of anchor routers. A link described by the Link 842 Descriptor TLVs actually is a "half-link", a unidirectional 843 representation of a logical link. To fully describe a single logical 844 link, two originating routers advertise a half-link each, i.e., two 845 Link NLRIs are advertised for a given point-to-point link. 847 A BGP-LS Consumer should not consider a link between two nodes as 848 being available unless it has received the two Link NLRIs 849 corresponding to the half-link representation of that link from both 850 the nodes. This check is similar to the 'two-way connectivity check' 851 that is performed by link-state IGPs and is also required to be done 852 by BGP-LS Consumers of link-state topology. 854 A BGP-LS Producer MAY suppress the advertisement of a Link NLRI, 855 corresponding to a half link, from a link-state IGP unless it has 856 verified that the link is being reported in the IS-IS LSP or OSPF 857 Router LSA by both the nodes connected by that link. This 'two-way 858 connectivity check' is performed by link-state IGPs during their 859 computation and may be leveraged before passing information for any 860 half-link that is reported from these IGPs into BGP-LS. This ensures 861 that only those Link State IGP adjacencies which are established get 862 reported via Link NLRIs. Such a 'two-way connectivity check' may be 863 also required in certain cases (e.g. with OSPF) to obtain the proper 864 link identifiers of the remote node. 866 The format and semantics of the Value fields in most Link Descriptor 867 TLVs correspond to the format and semantics of value fields in IS-IS 868 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], 869 and [RFC6119]. Although the encodings for Link Descriptor TLVs were 870 originally defined for IS-IS, the TLVs can carry data sourced by 871 either IS-IS or OSPF. 873 The following TLVs are defined as Link Descriptors in the Link NLRI: 875 +-----------+---------------------+--------------+------------------+ 876 | TLV Code | Description | IS-IS | Reference | 877 | Point | | TLV/Sub-TLV | (RFC/Section) | 878 +-----------+---------------------+--------------+------------------+ 879 | 258 | Link Local/Remote | 22/4 | [RFC5307] / 1.1 | 880 | | Identifiers | | | 881 | 259 | IPv4 interface | 22/6 | [RFC5305] / 3.2 | 882 | | address | | | 883 | 260 | IPv4 neighbor | 22/8 | [RFC5305] / 3.3 | 884 | | address | | | 885 | 261 | IPv6 interface | 22/12 | [RFC6119] / 4.2 | 886 | | address | | | 887 | 262 | IPv6 neighbor | 22/13 | [RFC6119] / 4.3 | 888 | | address | | | 889 | 263 | Multi-Topology | --- | Section 4.2.2.1 | 890 | | Identifier | | | 891 +-----------+---------------------+--------------+------------------+ 893 Table 4: Link Descriptor TLVs 895 The information about a link present in the LSA/LSP originated by the 896 local node of the link determines the set of TLVs in the Link 897 Descriptor of the link. 899 If interface and neighbor addresses, either IPv4 or IPv6, are 900 present, then the IP address TLVs MUST be included, and the Link 901 Local/Remote Identifiers TLV MUST NOT be included in the Link 902 Descriptor. The Link Local/Remote Identifiers TLV MAY be included 903 in the link attribute when available. IPv6 link-local addresses 904 MUST NOT be carried in the IPv6 address TLVs as descriptors of a 905 link as they are not considered unique. 907 If interface and neighbor addresses are not present and the link 908 local/remote identifiers are present, then the Link Local/Remote 909 Identifiers TLV MUST be included in the Link Descriptor. The Link 910 Local/Remote Identifiers MUST be included in the Link Descriptor 911 also in the case of links having only IPv6 link-local addressing 912 on them. 914 The Multi-Topology Identifier TLV MUST be included in Link 915 Descriptor if the underlying IGP link object is associated with a 916 non-default topology. 918 The TLVs/sub-TLVs corresponding to the interface addresses and/or the 919 local/remote identifiers may not always be signaled in the IGPs 920 unless their advertisement is enabled specifically. In such cases, 921 it is valid to advertise a BGP-LS Link NLRI without any of these 922 identifiers. 924 4.2.2.1. Multi-Topology ID 926 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 927 Multi-Topology IDs for a link, node, or prefix. 929 The semantics of the IS-IS MT-ID are defined in Section 7.1 and 7.2 930 of RFC 5120 [RFC5120]. The semantics of the OSPF MT-ID are defined 931 in Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV 932 is derived from OSPF, then the upper R bits of the MT-ID field MUST 933 be set to 0 and only the values from 0 to 127 are valid for the MT- 934 ID. 936 The format of the MT-ID TLV is shown in the following figure. 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Type | Length=2*n | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 |R R R R| Multi-Topology ID 1 | .... // 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 // .... |R R R R| Multi-Topology ID n | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Figure 12: Multi-Topology ID TLV Format 950 where Type is 263, Length is 2*n, and n is the number of MT-IDs 951 carried in the TLV. 953 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 954 Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or 955 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 956 the topology where the link or the prefix is reachable is allowed. 957 In case one wants to advertise multiple topologies for a given Link 958 Descriptor or Prefix Descriptor, multiple NLRIs MUST be generated 959 where each NLRI contains a single unique MT-ID. When used in the 960 Link or Prefix Descriptor TLV for IS-IS, the Bits R are reserved and 961 MUST be set to 0 (as per Section 7.2 of RFC 5120 [RFC5120]) when 962 originated and ignored on receipt. 964 In the BGP-LS attribute of a Node NLRI, one MT-ID TLV containing the 965 array of MT-IDs of all topologies where the node is reachable is 966 allowed. When used in the Node Attribute TLV for IS-IS, the Bits R 967 are set as per Section 7.1 of RFC 5120 [RFC5120]. 969 4.2.3. Prefix Descriptors 971 The Prefix Descriptor field is a set of Type/Length/Value (TLV) 972 triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 973 prefix originated by a node. The following TLVs are defined as 974 Prefix Descriptors in the IPv4/IPv6 Prefix NLRI: 976 +-------------+---------------------+----------+--------------------+ 977 | TLV Code | Description | Length | Reference | 978 | Point | | | (RFC/Section) | 979 +-------------+---------------------+----------+--------------------+ 980 | 263 | Multi-Topology | variable | Section 4.2.2.1 | 981 | | Identifier | | | 982 | 264 | OSPF Route Type | 1 | Section 4.2.3.1 | 983 | 265 | IP Reachability | variable | Section 4.2.3.2 | 984 | | Information | | | 985 +-------------+---------------------+----------+--------------------+ 987 Table 5: Prefix Descriptor TLVs 989 The Multi-Topology Identifier TLV MUST be included in Prefix 990 Descriptor if the underlying IGP prefix object is associated with a 991 non-default topology. 993 4.2.3.1. OSPF Route Type 995 The OSPF Route Type TLV is an optional TLV corresponding to Prefix 996 NLRIs originated from OSPF. It is used to identify the OSPF route 997 type of the prefix. An OSPF prefix MAY be advertised in the OSPF 998 domain with multiple route types. The Route Type TLV allows the 999 discrimination of these advertisements. The OSPF Route Type TLV MUST 1000 be included advertisement when the type is either being signaled 1001 explicitly or can be determined via another advertisement for the 1002 same prefix (refer section 2.1 of [RFC7684]). The format of the OSPF 1003 Route Type TLV is shown in the following figure. 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Type | Length | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Route Type | 1011 +-+-+-+-+-+-+-+-+ 1013 Figure 13: OSPF Route Type TLV Format 1015 where the Type and Length fields of the TLV are defined in Table 5. 1016 The OSPF Route Type field follows the route types defined in the OSPF 1017 protocol and can be one of the following: 1019 o Intra-Area (0x1) 1021 o Inter-Area (0x2) 1023 o External 1 (0x3) 1025 o External 2 (0x4) 1027 o NSSA 1 (0x5) 1029 o NSSA 2 (0x6) 1031 4.2.3.2. IP Reachability Information 1033 The IP Reachability Information TLV is a mandatory TLV for IPv4 & 1034 IPv6 Prefix NLRI types. The TLV contains one IP address prefix (IPv4 1035 or IPv6) originally advertised in the IGP topology. A router SHOULD 1036 advertise an IP Prefix NLRI for each of its BGP next-hops. The 1037 format of the IP Reachability Information TLV is shown in the 1038 following figure: 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Type | Length | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Prefix Length | IP Prefix (variable) // 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Figure 14: IP Reachability Information TLV Format 1050 The Type and Length fields of the TLV are defined in Table 5. The 1051 following two fields determine the reachability information of the 1052 address family. The Prefix Length field contains the length of the 1053 prefix in bits. The IP Prefix field contains an IP address prefix, 1054 followed by the minimum number of trailing bits needed to make the 1055 end of the field fall on an octet boundary. Any trailing bits MUST 1056 be set to 0. Thus the IP Prefix field contains the most significant 1057 octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 1058 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 1059 24, 4 octets for prefix length 25 up to 32, etc. 1061 4.3. The BGP-LS Attribute 1063 The BGP-LS Attribute (assigned value 29 by IANA) is an optional, non- 1064 transitive BGP attribute that is used to carry link, node, and prefix 1065 parameters and attributes. It is defined as a set of Type/Length/ 1066 Value (TLV) triplets, described in the following section. This 1067 attribute SHOULD only be included with Link-State NLRIs. This 1068 attribute MUST be ignored for all other address families. 1070 The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute 1071 TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute 1072 associated with a Node NLRI, Link NLRI, and Prefix NLRI respectively. 1074 The size of the BGP-LS Attribute may potentially grow large depending 1075 on the amount of link-state information associated with a single 1076 Link-State NLRI. The BGP specification [RFC4271] mandates a maximum 1077 BGP message size of 4096 octets. It is RECOMMENDED that an 1078 implementation support [RFC8654] to accommodate a larger size of 1079 information within the BGP-LS Attribute. BGP-LS Producers MUST 1080 ensure that they limit the TLVs included in the BGP-LS Attribute to 1081 ensure that a BGP update message for a single Link-State NLRI does 1082 not cross the maximum limit for a BGP message. The determination of 1083 the types of TLVs to be included MAY be made by the BGP-LS Producer 1084 based on the BGP-LS Consumer applications requirement and is outside 1085 the scope of this document. When a BGP-LS Propagator finds that it 1086 is exceeding the maximum BGP message size due to addition or update 1087 of some other BGP Attribute (e.g. AS_PATH), it MUST consider the 1088 BGP-LS Attribute to be malformed and handle the propagation as 1089 described in Section 7.2.2. This brings the deployment consideration 1090 where the consistent propagation of BGP-LS information with an update 1091 size larger than 4096 octets can only happen along a set of BGP 1092 Speakers that all support [RFC8654]. 1094 4.3.1. Node Attribute TLVs 1096 The following Node Attribute TLVs are defined for the BGP-LS 1097 Attribute associated with a Node NLRI: 1099 +-------------+----------------------+----------+-------------------+ 1100 | TLV Code | Description | Length | Reference | 1101 | Point | | | (RFC/Section) | 1102 +-------------+----------------------+----------+-------------------+ 1103 | 263 | Multi-Topology | variable | Section 4.2.2.1 | 1104 | | Identifier | | | 1105 | 1024 | Node Flag Bits | 1 | Section 4.3.1.1 | 1106 | 1025 | Opaque Node | variable | Section 4.3.1.5 | 1107 | | Attribute | | | 1108 | 1026 | Node Name | variable | Section 4.3.1.3 | 1109 | 1027 | IS-IS Area | variable | Section 4.3.1.2 | 1110 | | Identifier | | | 1111 | 1028 | IPv4 Router-ID of | 4 | [RFC5305] / 4.3 | 1112 | | Local Node | | | 1113 | 1029 | IPv6 Router-ID of | 16 | [RFC6119] / 4.1 | 1114 | | Local Node | | | 1115 +-------------+----------------------+----------+-------------------+ 1117 Table 6: Node Attribute TLVs 1119 4.3.1.1. Node Flag Bits TLV 1121 The Node Flag Bits TLV carries a bitmask describing node attributes. 1122 The value is a 1 octet length bit array of flags, where each bit 1123 represents a node operational state or attribute. 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Type | Length | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 |O|T|E|B|R|V| | 1131 +-+-+-+-+-+-+-+-+ 1133 Figure 15: Node Flag Bits TLV Format 1135 The bits are defined as follows: 1137 +-----+--------------+------------+ 1138 | Bit | Description | Reference | 1139 +-----+--------------+------------+ 1140 | 'O' | Overload Bit | [ISO10589] | 1141 | 'T' | Attached Bit | [ISO10589] | 1142 | 'E' | External Bit | [RFC2328] | 1143 | 'B' | ABR Bit | [RFC2328] | 1144 | 'R' | Router Bit | [RFC5340] | 1145 | 'V' | V6 Bit | [RFC5340] | 1146 +-----+--------------+------------+ 1148 Table 7: Node Flag Bits Definitions 1150 4.3.1.2. IS-IS Area Identifier TLV 1152 An IS-IS node can be part of one or more IS-IS areas. Each of these 1153 area addresses is carried in the IS-IS Area Identifier TLV. If 1154 multiple area addresses are present, multiple TLVs are used to encode 1155 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 1156 attribute only when advertised in the Link-State Node NLRI. 1158 0 1 2 3 1159 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 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Type | Length | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 // Area Identifier (variable) // 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Figure 16: IS-IS Area Identifier TLV Format 1168 4.3.1.3. Node Name TLV 1170 The Node Name TLV is optional. Its structure and encoding has been 1171 borrowed from [RFC5301]. The Value field identifies the symbolic 1172 name of the router node. This symbolic name can be the Fully 1173 Qualified Domain Name (FQDN) for the router, or it can be a subset of 1174 the FQDN (e.g., a hostname), or it can be any string that an operator 1175 wants to use for the router. The use of FQDN or a subset of it is 1176 strongly RECOMMENDED. The maximum length of the Node Name TLV is 255 1177 octets. 1179 The Value field is encoded in 7-bit ASCII. If a user interface for 1180 configuring or displaying this field permits Unicode characters, that 1181 the user interface is responsible for applying the ToASCII and/or 1182 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1183 format for transmission or display. 1185 [RFC5301] describes an IS-IS-specific extension and [RFC5642] 1186 describes an OSPF extension for the advertisement of Node Name which 1187 MAY encoded in the Node Name TLV. 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Type | Length | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 // Node Name (variable) // 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Figure 17: Node Name Format 1199 4.3.1.4. Local IPv4/IPv6 Router-ID TLVs 1201 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 1202 Router-IDs that the IGP might be using, e.g., for TE and migration 1203 purposes such as correlating a Node-ID between different protocols. 1204 If there is more than one auxiliary Router-ID of a given type, then 1205 each one is encoded in its own TLV. 1207 4.3.1.5. Opaque Node Attribute TLV 1209 The Opaque Node Attribute TLV is an envelope that transparently 1210 carries optional Node Attribute TLVs advertised by a router. An 1211 originating router shall use this TLV for encoding information 1212 specific to the protocol advertised in the NLRI header Protocol-ID 1213 field or new protocol extensions to the protocol as advertised in the 1214 NLRI header Protocol-ID field for which there is no protocol-neutral 1215 representation in the BGP Link-State NLRI. The primary use of the 1216 Opaque Node Attribute TLV is to bridge the document lag between, 1217 e.g., a new IGP link-state attribute being defined and the protocol- 1218 neutral BGP-LS extensions being published. Once the protocol-neutral 1219 BGP-LS extensions are defined, the BGP-LS implementations would still 1220 need to advertise the information both within the Opaque Attribute 1221 TLV and the new TLV definition for incremental deployment and 1222 transition. 1224 In the case of OSPF, this TLV MAY be used to advertise information 1225 carried using the TLVs in the "OSPF Router Information (RI) TLVs" 1226 registry [RFC7770] under the IANA OSPF Parameters registry. 1228 0 1 2 3 1229 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 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Type | Length | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 // Opaque node attributes (variable) // 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 Figure 18: Opaque Node Attribute Format 1238 4.3.2. Link Attribute TLVs 1240 Link Attribute TLVs are TLVs that may be encoded in the BGP-LS 1241 attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ 1242 Value (TLV) triplet formatted as defined in Section 4.1. The format 1243 and semantics of the Value fields in some Link Attribute TLVs 1244 correspond to the format and semantics of the Value fields in IS-IS 1245 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 1246 [RFC5307]. Other Link Attribute TLVs are defined in this document. 1247 Although the encodings for Link Attribute TLVs were originally 1248 defined for IS-IS, the TLVs can carry data sourced by either IS-IS or 1249 OSPF. 1251 The following Link Attribute TLVs are defined for the BGP-LS 1252 Attribute associated with a Link NLRI: 1254 +-----------+---------------------+--------------+------------------+ 1255 | TLV Code | Description | IS-IS | Reference | 1256 | Point | | TLV/Sub-TLV | (RFC/Section) | 1257 +-----------+---------------------+--------------+------------------+ 1258 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 | 1259 | | Local Node | | | 1260 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 | 1261 | | Local Node | | | 1262 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 | 1263 | | Remote Node | | | 1264 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 | 1265 | | Remote Node | | | 1266 | 1088 | Administrative | 22/3 | [RFC5305] / 3.1 | 1267 | | group (color) | | | 1268 | 1089 | Maximum link | 22/9 | [RFC5305] / 3.4 | 1269 | | bandwidth | | | 1270 | 1090 | Max. reservable | 22/10 | [RFC5305] / 3.5 | 1271 | | link bandwidth | | | 1272 | 1091 | Unreserved | 22/11 | [RFC5305] / 3.6 | 1273 | | bandwidth | | | 1274 | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | 1275 | 1093 | Link Protection | 22/20 | [RFC5307] / 1.2 | 1276 | | Type | | | 1277 | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | 1278 | 1095 | IGP Metric | --- | Section 4.3.2.4 | 1279 | 1096 | Shared Risk Link | --- | Section 4.3.2.5 | 1280 | | Group | | | 1281 | 1097 | Opaque Link | --- | Section 4.3.2.6 | 1282 | | Attribute | | | 1283 | 1098 | Link Name | --- | Section 4.3.2.7 | 1284 +-----------+---------------------+--------------+------------------+ 1286 Table 8: Link Attribute TLVs 1288 4.3.2.1. IPv4/IPv6 Router-ID TLVs 1290 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1291 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1292 purposes. All auxiliary Router-IDs of both the local and the remote 1293 node MUST be included in the link attribute of each Link NLRI. If 1294 there is more than one auxiliary Router-ID of a given type, then 1295 multiple TLVs are used to encode them. 1297 4.3.2.2. MPLS Protocol Mask TLV 1299 The MPLS Protocol Mask TLV carries a bitmask describing which MPLS 1300 signaling protocols are enabled. The length of this TLV is 1. The 1301 value is a bit array of 8 flags, where each bit represents an MPLS 1302 Protocol capability. 1304 Generation of the MPLS Protocol Mask TLV is only valid for and SHOULD 1305 only be used with originators that have local link insight, for 1306 example, the Protocol-IDs 'Static configuration' or 'Direct' as per 1307 Table 2. The MPLS Protocol Mask TLV MUST NOT be included in NLRIs 1308 with the other Protocol-IDs listed in Table 2. 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Type | Length | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 |L|R| Reserved | 1316 +-+-+-+-+-+-+-+-+ 1318 Figure 19: MPLS Protocol Mask TLV 1320 The following bits are defined and the reserved bits MUST be set to 1321 zero and SHOULD be ignored on receipt: 1323 +-----+---------------------------------------------+-----------+ 1324 | Bit | Description | Reference | 1325 +-----+---------------------------------------------+-----------+ 1326 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1327 | 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | 1328 +-----+---------------------------------------------+-----------+ 1330 Table 9: MPLS Protocol Mask TLV Codes 1332 4.3.2.3. TE Default Metric TLV 1334 The TE Default Metric TLV carries the Traffic Engineering metric for 1335 this link. The length of this TLV is fixed at 4 octets. If a source 1336 protocol uses a metric width of fewer than 32 bits, then the high- 1337 order bits of this field MUST be padded with zero. 1339 0 1 2 3 1340 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 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Type | Length | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | TE Default Link Metric | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 Figure 20: TE Default Metric TLV Format 1349 4.3.2.4. IGP Metric TLV 1351 The IGP Metric TLV carries the metric for this link. The length of 1352 this TLV is variable, depending on the metric width of the underlying 1353 protocol. IS-IS small metrics have a length of 1 octet. Since the 1354 ISIS small metrics are of 6-bit size, the two most significant bits 1355 MUST be set to 0 and MUST be ignored by the receiver. OSPF link 1356 metrics have a length of 2 octets. IS-IS wide metrics have a length 1357 of 3 octets. 1359 0 1 2 3 1360 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 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | Type | Length | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 // IGP Link Metric (variable length) // 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 Figure 21: IGP Metric TLV Format 1369 4.3.2.5. Shared Risk Link Group TLV 1371 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1372 Group information (see Section 2.3 ("Shared Risk Link Group 1373 Information") of [RFC4202]). It contains a data structure consisting 1374 of a (variable) list of SRLG values, where each element in the list 1375 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1376 (number of SRLG values). 1378 0 1 2 3 1379 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 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Type | Length | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Shared Risk Link Group Value | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 // ............ // 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Shared Risk Link Group Value | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 Figure 22: Shared Risk Link Group TLV Format 1392 The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS, the SRLG 1393 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1394 (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) 1395 defined in [RFC6119]. Both IPv4 and IPv6 SRLG information is carried 1396 in a single TLV. 1398 4.3.2.6. Opaque Link Attribute TLV 1400 The Opaque Link Attribute TLV is an envelope that transparently 1401 carries optional Link Attribute TLVs advertised by a router. An 1402 originating router shall use this TLV for encoding information 1403 specific to the protocol advertised in the NLRI header Protocol-ID 1404 field or new protocol extensions to the protocol as advertised in the 1405 NLRI header Protocol-ID field for which there is no protocol-neutral 1406 representation in the BGP Link-State NLRI. The primary use of the 1407 Opaque Link Attribute TLV is to bridge the document lag between, 1408 e.g., a new IGP link-state attribute being defined and the 'protocol- 1409 neutral' BGP-LS extensions being published. Once the protocol- 1410 neutral BGP-LS extensions are defined, the BGP-LS implementations 1411 would still need to advertise the information both within the Opaque 1412 Attribute TLV and the new TLV definition for incremental deployment 1413 and transition. 1415 In the case of OSPFv2, this TLV MAY be used to advertise information 1416 carried using the TLVs in the "OSPFv2 Extended Link Opaque LSA TLVs" 1417 registry [RFC7684] under the IANA OSPFv2 Parameters registry. In the 1418 case of OSPFv3, this TLV MAY be used to advertise information carried 1419 using the TLVs in the "OSPFv3 Extended-LSA Sub-TLVs" registry 1420 [RFC8362] under the IANA OSPFv3 Parameters registry. 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Type | Length | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 // Opaque link attributes (variable) // 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 Figure 23: Opaque Link Attribute TLV Format 1432 4.3.2.7. Link Name TLV 1434 The Link Name TLV is optional. The Value field identifies the 1435 symbolic name of the router link. This symbolic name can be the FQDN 1436 for the link, or it can be a subset of the FQDN, or it can be any 1437 string that an operator wants to use for the link. The use of FQDN 1438 or a subset of it is strongly RECOMMENDED. The maximum length of the 1439 Link Name TLV is 255 octets. 1441 The Value field is encoded in 7-bit ASCII. If a user interface for 1442 configuring or displaying this field permits Unicode characters, that 1443 the user interface is responsible for applying the ToASCII and/or 1444 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1445 format for transmission or display. 1447 How a router derives and injects link names is outside of the scope 1448 of this document. 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Type | Length | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 // Link Name (variable) // 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Figure 24: Link Name TLV Format 1460 4.3.3. Prefix Attribute TLVs 1462 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1463 of IGP attributes (such as metric, route tags, etc.) that are 1464 advertised in the BGP-LS Attribute with Prefix NLRI types 3 and 4. 1466 The following Prefix Attribute TLVs are defined for the BGP-LS 1467 Attribute associated with a Prefix NLRI: 1469 +---------------+-----------------------+----------+----------------+ 1470 | TLV Code | Description | Length | Reference | 1471 | Point | | | | 1472 +---------------+-----------------------+----------+----------------+ 1473 | 1152 | IGP Flags | 1 | Section 4.3.3. | 1474 | | | | 1 | 1475 | 1153 | IGP Route Tag | 4*n | [RFC5130] | 1476 | 1154 | IGP Extended Route | 8*n | [RFC5130] | 1477 | | Tag | | | 1478 | 1155 | Prefix Metric | 4 | [RFC5305] | 1479 | 1156 | OSPF Forwarding | 4 | [RFC2328] | 1480 | | Address | | | 1481 | 1157 | Opaque Prefix | variable | Section 4.3.3. | 1482 | | Attribute | | 6 | 1483 +---------------+-----------------------+----------+----------------+ 1485 Table 10: Prefix Attribute TLVs 1487 4.3.3.1. IGP Flags TLV 1489 The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits 1490 originally assigned to the prefix. The IGP Flags TLV is encoded as 1491 follows: 1493 0 1 2 3 1494 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 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Type | Length | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 |D|N|L|P|Reservd| 1499 +-+-+-+-+-+-+-+-+ 1501 Figure 25: IGP Flag TLV Format 1503 The Value field contains bits defined according to the table below 1504 and the reserved bits MUST be set to zero and SHOULD be ignored on 1505 receipt: 1507 +-----+---------------------------+-----------+ 1508 | Bit | Description | Reference | 1509 +-----+---------------------------+-----------+ 1510 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1511 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1512 | 'L' | OSPF "local address" Bit | [RFC5340] | 1513 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1514 +-----+---------------------------+-----------+ 1516 Table 11: IGP Flag Bits Definitions 1518 4.3.3.2. IGP Route Tag TLV 1520 The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or 1521 OSPF) of the prefix and is encoded as follows: 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Type | Length | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 // Route Tags (one or more) // 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 Figure 26: IGP Route Tag TLV Format 1533 Length is a multiple of 4. 1535 The Value field contains one or more Route Tags as learned in the IGP 1536 topology. 1538 4.3.3.3. Extended IGP Route Tag TLV 1540 The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of 1541 the prefix [RFC5130] and is encoded as follows: 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Type | Length | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 // Extended Route Tag (one or more) // 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 Figure 27: Extended IGP Route Tag TLV Format 1553 Length is a multiple of 8. 1555 The Extended Route Tag field contains one or more Extended Route Tags 1556 as learned in the IGP topology. 1558 4.3.3.4. Prefix Metric TLV 1560 The Prefix Metric TLV is an optional attribute and may only appear 1561 once. If present, it carries the metric of the prefix as known in 1562 the IGP topology as described in Section 4 of [RFC5305] (and 1563 therefore represents the reachability cost to the prefix). If not 1564 present, it means that the prefix is advertised without any 1565 reachability. 1567 0 1 2 3 1568 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 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Type | Length | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Metric | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Figure 28: Prefix Metric TLV Format 1577 Length is 4. 1579 4.3.3.5. OSPF Forwarding Address TLV 1581 The OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF 1582 forwarding address as known in the original OSPF advertisement. The 1583 forwarding address can be either IPv4 or IPv6. 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Type | Length | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 // Forwarding Address (variable) // 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 Figure 29: OSPF Forwarding Address TLV Format 1595 Length is 4 for an IPv4 forwarding address, and 16 for an IPv6 1596 forwarding address. 1598 4.3.3.6. Opaque Prefix Attribute TLV 1600 The Opaque Prefix Attribute TLV is an envelope that transparently 1601 carries optional Prefix Attribute TLVs advertised by a router. An 1602 originating router shall use this TLV for encoding information 1603 specific to the protocol advertised in the NLRI header Protocol-ID 1604 field or new protocol extensions to the protocol as advertised in the 1605 NLRI header Protocol-ID field for which there is no protocol-neutral 1606 representation in the BGP Link-State NLRI. The primary use of the 1607 Opaque Prefix Attribute TLV is to bridge the document lag between, 1608 e.g., a new IGP link-state attribute being defined and the protocol- 1609 neutral BGP-LS extensions being published. Once the protocol-neutral 1610 BGP-LS extensions are defined, the BGP-LS implementations would still 1611 need to advertise the information both within the Opaque Attribute 1612 TLV and the new TLV definition for incremental deployment and 1613 transition. 1615 In the case of OSPFv2, this TLV MAY be used to advertise information 1616 carried using the TLVs in the "OSPFv2 Extended Prefix Opaque LSA 1617 TLVs" registry [RFC7684] under the IANA OSPFv2 Parameters registry. 1618 In the case of OSPFv3, this TLV MAY be used to advertise information 1619 carried using the TLVs in the "OSPFv3 Extended-LSA Sub-TLVs" registry 1620 [RFC8362] under the IANA OSPFv3 Parameters registry. 1622 The format of the TLV is as follows: 1624 0 1 2 3 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | Type | Length | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 // Opaque Prefix Attributes (variable) // 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 Figure 30: Opaque Prefix Attribute TLV Format 1634 Type is as specified in Table 10. Length is variable. 1636 4.4. Private Use 1638 TLVs for Vendor Private use are supported using the code point range 1639 reserved as indicated in Section 6. For such TLV use in the NLRI or 1640 BGP-LS Attribute, the format as described in Section 4.1 is to be 1641 used and a 4 octet field MUST be included as the first field in the 1642 value to carry the Enterprise Code. For a private use NLRI Type, a 4 1643 octet field MUST be included as the first field in the NLRI 1644 immediately following the Total NLRI Length field of the Link-State 1645 NLRI format as described in Section 4.2 to carry the Enterprise Code. 1646 The Enterprise Codes are listed at . This enables the use of vendor-specific 1648 extensions without conflicts. 1650 Multiple instances of private-use TLVs MAY appear in the BGP-LS 1651 Attribute. 1653 4.5. BGP Next-Hop Information 1655 BGP link-state information for both IPv4 and IPv6 networks can be 1656 carried over either an IPv4 BGP session or an IPv6 BGP session. If 1657 an IPv4 BGP session is used, then the next-hop in the MP_REACH_NLRI 1658 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1659 used, then the next-hop in the MP_REACH_NLRI SHOULD be an IPv6 1660 address. Usually, the next-hop will be set to the local endpoint 1661 address of the BGP session. The next-hop address MUST be encoded as 1662 described in [RFC4760]. The Length field of the next-hop address 1663 will specify the next-hop address family. If the next-hop length is 1664 4, then the next-hop is an IPv4 address; if the next-hop length is 1665 16, then it is a global IPv6 address; and if the next-hop length is 1666 32, then there is one global IPv6 address followed by a link-local 1667 IPv6 address. The link-local IPv6 address should be used as 1668 described in [RFC2545]. For VPN Subsequent Address Family Identifier 1669 (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero 1670 is prepended to the next-hop. 1672 The BGP Next-Hop attribute is used by each BGP-LS speaker to validate 1673 the NLRI it receives. In case identical NLRIs are sourced by 1674 multiple BGP-LS Producers, the BGP Next-Hop attribute is used to 1675 tiebreak as per the standard BGP path decision process. This 1676 specification doesn't mandate any rule regarding the rewrite of the 1677 BGP Next-Hop attribute. 1679 4.6. Inter-AS Links 1681 The main source of TE information is the IGP, which is not active on 1682 inter-AS links. In some cases, the IGP may have information of 1683 inter-AS links [RFC5392] [RFC5316]. In other cases, an 1684 implementation SHOULD provide a means to inject inter-AS links into 1685 BGP-LS. The exact mechanism used to advertise the inter-AS links is 1686 outside the scope of this document. 1688 4.7. OSPF Virtual Links and Sham Links 1690 In an OSPF [RFC2328] [RFC5340] network, virtual links serve to 1691 connect physically separate components of the backbone to establish/ 1692 maintain continuity of the backbone area. While virtual links are 1693 modeled as point-to-point unnumbered links in the OSPF topology, 1694 their characteristics and purpose are different from other types of 1695 links in the OSPF topology. They are advertised using a distinct 1696 "virtual link" type in OSPF LSAs. The mechanism for the 1697 advertisement of OSPF virtual links via BGP-LS is outside the scope 1698 of this document. 1700 In an OSPF network, sham links [RFC4577] [RFC6565] are used to 1701 provide intra-area connectivity between VRFs on PE routers over the 1702 VPN provider's network. These links are advertised in OSPF as point- 1703 to-point unnumbered links and represent connectivity over a service 1704 provider network using encapsulation mechanisms like MPLS. As such, 1705 the mechanism for the advertisement of OSPF sham links follow the 1706 same procedures as other point-to-point unnumbered links as described 1707 previously in this document. 1709 4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 1711 OSPFv2 [RFC2328] defines the Type 4 Summary LSA and OSPFv3 [RFC5340] 1712 the Inter-area-router-LSA for an Area Border Router (ABR) to 1713 advertise reachability to an AS Border Router (ASBR) that is external 1714 to the area yet internal to the AS. The nature of information 1715 advertised by OSPF using this type of LSA does not map to either a 1716 node or a link or a prefix as discussed in this document. Therefore, 1717 the mechanism for the advertisement of the information carried by 1718 these LSAs is outside the scope of this document. 1720 4.9. Handling of Unreachable IGP Nodes 1722 The origination and propagation of IGP link-state information via BGP 1723 needs to provide a consistent and true view of the topology of the 1724 IGP domain. BGP-LS provides an abstraction of the IGP specifics and 1725 BGP-LS Consumers may be varied types of applications. While the 1726 information propagated via BGP-LS from a link-state routing protocol 1727 is sourced from that protocol's LSDB, it does not serve as a true 1728 reflection of the originating router's LSDB since it does not include 1729 the LSA/LSP sequence number information. The sequence numbers are 1730 not included since a single NLRI update may be put together with 1731 information that is coming from multiple LSAs/LSPs. 1733 Consider an OSPF network as shown in Figure 31, where R2 and R3 are 1734 the BGP-LS Producers and also the OSPF Area Border Routers (ABRs). 1735 The link between R2 and R3 is in area 0 while the other links shown 1736 are in area 1. 1738 A BGP-LS Consumer talks to a BGP route-reflector (RR) R0 which is 1739 aggregating the BGP-LS feed from the BGP-LS Producers R2 and R3. 1740 Here R2 and R3 provide a redundant topology feed via BGP-LS to R0. 1741 Normally, R0 would receive two identical copies of all the Link-State 1742 NLRIs from both R2 and R3 and it would pick one of them (say R2) 1743 based on the standard BGP best-path decision process. 1745 Consumer 1746 ^ 1747 | 1748 R0 1749 (BGP Route Reflector) 1750 / \ 1751 / \ 1752 a1 / a0 \ a1 1753 R1 ------ R2 -------- R3 ------ R4 1754 a1 | | a1 1755 | | 1756 R5 ---------------------------- R6 1757 a1 1759 Figure 31: Incorrect Reporting due to BGP Path Selection 1761 Consider a scenario where the link between R5 and R6 is lost (thereby 1762 partitioning the area 1) and its impact on the OSPF LSDB at R2 and 1763 R3. 1765 Now, R5 will remove the link 5-6 from its Router LSA, and this 1766 updated LSA is available at R2. R2 also has a stale copy of R6's 1767 Router LSA which still has the link 6-5 in it. Based on this view in 1768 its LSDB, R2 will advertise only the half-link 6-5 that it derives 1769 from R6's stale Router LSA. 1771 At the same time, R6 has removed the link 6-5 from its Router LSA, 1772 and this updated LSA is available at R3. Similarly, R3 also has a 1773 stale copy of R5's Router LSA having the link 5-6 in it. Based on 1774 it's LSDB, R3 will advertise only the half-link 5-6 that it has 1775 derived from R5's stale Router LSA. 1777 Now, the BGP-LS Consumer receives both the Link NLRIs corresponding 1778 to the half-links from R2 and R3 via R0. When viewed together, it 1779 would not detect or realize that the area 1 is partitioned. Also if 1780 R2 continues to report Link-State NLRIs corresponding to the stale 1781 copy of Router LSA of R4 and R6 nodes then R0 would prefer them over 1782 the valid Link-State NLRIs for R4 and R6 that it is receiving from R3 1783 based on its BGP decision process. This would result in the BGP-LS 1784 Consumer getting stale and inaccurate topology information. This 1785 problem scenario is avoided if R2 were to not advertise the link- 1786 state information corresponding to R4 and R6 and if R3 were to not 1787 advertise similarly for R1 and R5. 1789 A BGP-LS Producer SHOULD withdraw all link-state objects advertised 1790 by it in BGP when the node that originated its corresponding LSP/LSAs 1791 is determined to have become unreachable in the IGP. An 1792 implementation MAY continue to advertise link-state objects 1793 corresponding to unreachable nodes in a deployment use-case where the 1794 BGP-LS Consumer is interested in receiving a topology feed 1795 corresponding to a complete IGP LSDB view. In such deployments, it 1796 is expected that the problem described above is mitigated by the BGP- 1797 LS Consumer via appropriate handling of such a topology feed in 1798 addition to the use of either a direct BGP peering with the producer 1799 nodes or mechanisms such as [RFC7911] when using RR. Details of 1800 these mechanisms are outside the scope of this draft. 1802 If the BGP-LS Producer does withdraw link-state objects associated 1803 with an IGP node based on the failure of reachability check for that 1804 node, then it MUST re-advertise those link-state objects after that 1805 node becomes reachable again in the IGP domain. 1807 4.10. Router-ID Anchoring Example: ISO Pseudonode 1809 Encoding of a broadcast LAN in IS-IS provides a good example of how 1810 Router-IDs are encoded. Consider Figure 32. This represents a 1811 Broadcast LAN between a pair of routers. The "real" (non-pseudonode) 1812 routers have both an IPv4 Router-ID and IS-IS Node-ID. The 1813 pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the 1814 LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, 1815 Node2) are being generated. 1817 The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP 1818 Router-ID TLV of the local Node Descriptor is 6 octets long and 1819 contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV 1820 of the remote Node Descriptor is 7 octets long and contains the ISO- 1821 ID of Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this 1822 link contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1823 192.0.2.1, the IPv4 Router-ID of Node1. 1825 The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The IGP 1826 Router-ID TLV of the local Node Descriptor is 7 octets long and 1827 contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP 1828 Router-ID TLV of the remote Node Descriptor is 6 octets long and 1829 contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute 1830 of this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1831 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1833 +-----------------+ +-----------------+ +-----------------+ 1834 | Node1 | | Pseudonode1 | | Node2 | 1835 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1836 | 192.0.2.1 | | | | 192.0.2.2 | 1837 +-----------------+ +-----------------+ +-----------------+ 1839 Figure 32: IS-IS Pseudonodes 1841 4.11. Router-ID Anchoring Example: OSPF Pseudonode 1843 Encoding of a broadcast LAN in OSPF provides a good example of how 1844 Router-IDs and local Interface IPs are encoded. Consider Figure 33. 1845 This represents a Broadcast LAN between a pair of routers. The 1846 "real" (non-pseudonode) routers have both an IPv4 Router-ID and an 1847 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1848 Interface Address (for disambiguation), and an OSPF Area. Node1 is 1849 the DR for the LAN; hence, its local IP address 10.1.1.1 is used as 1850 both the Router-ID and Interface IP for the pseudonode keys. Two 1851 unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), 1852 are being generated. 1854 The Link NLRI of (Node1, Pseudonode1) is encoded as follows: 1856 o Local Node Descriptor 1858 TLV #515: IGP Router-ID: 11.11.11.11 1860 TLV #514: OSPF Area-ID: ID:0.0.0.0 1862 o Remote Node Descriptor 1864 TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1 1866 TLV #514: OSPF Area-ID: ID:0.0.0.0 1868 The Link NLRI of (Pseudonode1, Node2) is encoded as follows: 1870 o Local Node Descriptor 1872 TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1 1874 TLV #514: OSPF Area-ID: ID:0.0.0.0 1876 o Remote Node Descriptor 1878 TLV #515: IGP Router-ID: 33.33.33.34 1880 TLV #514: OSPF Area-ID: ID:0.0.0.0 1882 10.1.1.1/24 10.1.1.2/24 1883 +-------------+ +-------------+ +-------------+ 1884 | Node1 | | Pseudonode1 | | Node2 | 1885 | 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 | 1886 | | | 10.1.1.1 | | | 1887 | Area 0 | | Area 0 | | Area 0 | 1888 +-------------+ +-------------+ +-------------+ 1890 Figure 33: OSPF Pseudonodes 1892 The LAN subnet 10.1.1.0/24 is not included in the Router LSA of Node1 1893 or Node2. The Network LSA for this LAN advertised by the DR Node1 1894 contains the subnet mask for the LAN along with the DR address. A 1895 Prefix NLRI corresponding to the LAN subnet is advertised with the 1896 Pseudonode1 used as the Local node using the DR address and the 1897 subnet mask from the Network LSA. 1899 4.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1901 Graceful migration from one IGP to another requires coordinated 1902 operation of both protocols during the migration period. Such 1903 coordination requires identifying a given physical link in both IGPs. 1904 The IPv4 Router-ID provides that "glue", which is present in the Node 1905 Descriptors of the OSPF Link NLRI and in the link attribute of the 1906 IS-IS Link NLRI. 1908 Consider a point-to-point link between two routers, A and B, that 1909 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1910 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1911 Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the 1912 link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link 1913 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1914 in the local and remote Node Descriptors, respectively. The IS-IS 1915 Link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1916 the local and remote Node Descriptors, respectively. In addition, 1917 the BGP-LS attribute of the IS-IS Link NLRI contains the TLV type 1918 1028 containing the IPv4 Router-ID of node A, TLV type 1030 1919 containing the IPv4 Router-ID of node B, and TLV type 1031 containing 1920 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1921 the link (A, B) can be identified in both the IS-IS and OSPF 1922 protocol. 1924 5. Link to Path Aggregation 1926 Distribution of all links available on the global Internet is 1927 certainly possible; however, it not desirable from a scaling and 1928 privacy point of view. Therefore, an implementation may support a 1929 link to path aggregation. Rather than advertising all specific links 1930 of a domain, an ASBR may advertise an "aggregate link" between a non- 1931 adjacent pair of nodes. The "aggregate link" represents the 1932 aggregated set of link properties between a pair of non-adjacent 1933 nodes. The actual methods to compute the path properties (of 1934 bandwidth, metric, etc.) are outside the scope of this document. The 1935 decision of whether to advertise all specific links or aggregated 1936 links is an operator's policy choice. To highlight the varying 1937 levels of exposure, the following deployment examples are discussed. 1939 5.1. Example: No Link Aggregation 1941 Consider Figure 34. Both AS1 and AS2 operators want to protect their 1942 inter-AS {R1, R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants 1943 to compute its link-protection LSP to R3, it needs to "see" an 1944 alternate path to R3. Therefore, the AS2 operator exposes its 1945 topology. All BGP-TE-enabled routers in AS1 "see" the full topology 1946 of AS2 and therefore can compute a backup path. Note that the 1947 computing router decides if the direct link between {R3, R4} or the 1948 {R4, R5, R3} path is used. 1950 AS1 : AS2 1951 : 1952 R1-------R3 1953 | : | \ 1954 | : | R5 1955 | : | / 1956 R2-------R4 1957 : 1958 : 1960 Figure 34: No Link Aggregation 1962 5.2. Example: ASBR to ASBR Path Aggregation 1964 The brief difference between the "no-link aggregation" example and 1965 this example is that no specific link gets exposed. Consider 1966 Figure 35. The only link that gets advertised by AS2 is an 1967 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1968 there is a backup path. However, the actual links being used are 1969 hidden from the topology. 1971 AS1 : AS2 1972 : 1973 R1-------R3 1974 | : | 1975 | : | 1976 | : | 1977 R2-------R4 1978 : 1979 : 1981 Figure 35: ASBR Link Aggregation 1983 5.3. Example: Multi-AS Path Aggregation 1985 Service providers in control of multiple ASes may even decide to not 1986 expose their internal inter-AS links. Consider Figure 36. AS3 is 1987 modeled as a single node that connects to the border routers of the 1988 aggregated domain. 1990 AS1 : AS2 : AS3 1991 : : 1992 R1-------R3----- 1993 | : : \ 1994 | : : vR0 1995 | : : / 1996 R2-------R4----- 1997 : : 1998 : : 2000 Figure 36: Multi-AS Aggregation 2002 6. IANA Considerations 2004 IANA has assigned address family number 16388 (BGP-LS) in the 2005 "Address Family Numbers" registry with [RFC7752] as a reference. 2007 IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the 2008 "SAFI Values" sub-registry under the "Subsequent Address Family 2009 Identifiers (SAFI) Parameters" registry with [RFC7752] as a 2010 reference. 2012 IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path 2013 Attributes" sub-registry under the "Border Gateway Protocol (BGP) 2014 Parameters" registry with [RFC7752] as a reference. 2016 IANA has created a new "Border Gateway Protocol - Link-State (BGP-LS) 2017 Parameters" registry at . 2020 This section also incorporates all the changes to the allocation 2021 procedures for the BGP-LS IANA registries as well as the guidelines 2022 for designated experts introduced by [RFC9029]. 2024 IANA is requested to replace the references indicated above to both 2025 [RFC7752] and [RFC9029] with this document. 2027 6.1. BGP-LS Registries 2029 All of the registries listed in the following sub-sections are BGP-LS 2030 specific and are accessible under this registry. 2032 6.1.1. BGP-LS NLRI Types Registry 2034 The "BGP-LS NLRI Types" registry has been set up for assignment for 2035 the two-octet sized code-points for BGP-LS NLRI types and populated 2036 with the values shown below: 2038 Type NLRI Type Reference 2039 ----------------------------------------------------------- 2040 0 Reserved [This document] 2041 1 Node NLRI [This document] 2042 2 Link NLRI [This document] 2043 3 IPv4 Topology Prefix NLRI [This document] 2044 4 IPv6 Topology Prefix NLRI [This document] 2045 65000-65535 Private Use [This document] 2047 Allocations within the registry under the "Expert Review" policy 2048 require documentation of the proposed use of the allocated value and 2049 approval by the Designated Expert assigned by the IESG (see 2050 [RFC8126]). 2052 6.1.2. BGP-LS Protocol-IDs Registry 2054 The "BGP-LS Protocol-IDs" registry has been set up for assignment for 2055 the one-octet sized code-points for BGP-LS Protocol-IDs and populated 2056 with the values shown below: 2058 Protocol-ID NLRI information source protocol Reference 2059 --------------------------------------------------------------------- 2060 0 Reserved [This document] 2061 1 IS-IS Level 1 [This document] 2062 2 IS-IS Level 2 [This document] 2063 3 OSPFv2 [This document] 2064 4 Direct [This document] 2065 5 Static configuration [This document] 2066 6 OSPFv3 [This document] 2067 200-255 Private Use [This document] 2069 Allocations within the registry under the "Expert Review" policy 2070 require documentation of the proposed use of the allocated value and 2071 approval by the Designated Expert assigned by the IESG (see 2072 [RFC8126]). 2074 6.1.3. BGP-LS Well-Known Instance-IDs Registry 2076 The "BGP-LS Well-Known Instance-IDs" registry that was set up via 2077 [RFC7752] is no longer required. It may be retained as deprecated 2078 and no further assignments be made from it. 2080 6.1.4. BGP-LS Node Flags Registry 2082 The "BGP-LS Node Flags" registry is requested to be created for the 2083 one-octet sized flags field of the Node Flag Bits TLV (1024) and 2084 populated with the initial values shown below: 2086 Bit Description Reference 2087 ----------------------------------------------- 2088 0 Overload Bit (O-bit) [This document] 2089 1 Attached Bit (A-bit) [This document] 2090 2 External Bit (E-bit) [This document] 2091 3 ABR Bit (B-bit) [This document] 2092 4 Router Bit (R-bit) [This document] 2093 5 V6 Bit (V-bit) [This document] 2094 6-7 Unassigned 2096 Allocations within the registry under the "RFC Required" policy (see 2097 [RFC8126]). 2099 6.1.5. BGP-LS MPLS Protocol Mask Registry 2101 The "BGP-LS MPLS Protocol Mask" registry is requested to be created 2102 for the one-octet sized flags field of the MPLS Protocol Mask TLV 2103 (1094) and populated with the initial values shown below: 2105 Bit Description Reference 2106 ------------------------------------------------------------------ 2107 0 Label Distribution Protocol (L-bit) [This document] 2108 1 Extension to RSVP for LSP Tunnels (R-bit) [This document] 2109 2-7 Unassigned 2111 Allocations within the registry under the "RFC Required" policy (see 2112 [RFC8126]). 2114 6.1.6. BGP-LS IGP Prefix Flags Registry 2116 The "BGP-LS IGP Prefix Flags" registry is requested to be created for 2117 the 1 octet sized flags field of the IGP Flags TLV (1152) and 2118 populated with the initial values shown below: 2120 Bit Description Reference 2121 ---------------------------------------------------------- 2122 0 IS-IS Up/Down Bit (D-bit) [This document] 2123 1 OSPF "no unicast" Bit (N-bit) [This document] 2124 2 OSPF "local address" Bit (L-bit) [This document] 2125 3 OSPF "propagate NSSA" Bit (P-bit) [This document] 2126 4-7 Unassigned 2128 Allocations within the registry under the "RFC Required" policy (see 2129 [RFC8126]). 2131 6.1.7. BGP-LS TLVs Registry 2133 The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 2134 Attribute TLVs" registry was setup via [RFC7752]. This document 2135 requests IANA to rename that registry to "BGP-LS NLRI and Attribute 2136 TLVs" and to remove the column for "IS-IS TLV/Sub-TLV" from the 2137 registry since that column is not relevant for the allocation and 2138 maintenance of BGP-LS code points. The values 0-255 are reserved. 2139 The values 256-65535 will be used for code points allocation. The 2140 range 65000-65535 is for Private Use. The registry has been populated 2141 with the values shown in Table 12 and the reference for all those 2142 allocations should be updated to this document instead of [RFC7752]. 2143 Allocations within the registry under the "Expert Review" policy 2144 require documentation of the proposed use of the allocated value and 2145 approval by the Designated Expert assigned by the IESG (see 2146 [RFC8126]). 2148 6.2. Guidance for Designated Experts 2150 In all cases of review by the designated expert described here, the 2151 designated expert is expected to check the clarity of purpose and use 2152 of the requested code points. The following points apply to the 2153 registries discussed in this document: 2155 1. Application for a code point allocation may be made to the 2156 designated experts at any time and MUST be accompanied by 2157 technical documentation explaining the use of the code point. 2158 Such documentation SHOULD be presented in the form of an 2159 Internet-Draft but MAY arrive in any form that can be reviewed 2160 and exchanged amongst reviewers. 2162 2. The designated experts SHOULD only consider requests that arise 2163 from Internet-Drafts that have already been accepted as working 2164 group documents or that are planned for progression as AD- 2165 Sponsored documents in the absence of a suitably chartered 2166 working group. 2168 3. In the case of working group documents, the designated experts 2169 MUST check with the working group chairs that there is consensus 2170 within the working group to make the allocation at this time. In 2171 the case of AD-Sponsored documents, the designated experts MUST 2172 check with the AD for approval to make the allocation at this 2173 time. 2175 4. If the document is not adopted by the IDR Working Group (or its 2176 successor), the designated expert MUST notify the IDR mailing 2177 list (or its successor) of the request and MUST provide access to 2178 the document. The designated expert MUST allow two weeks for any 2179 response. Any comments received MUST be considered by the 2180 designated expert as part of the subsequent step. 2182 5. The designated experts MUST then review the assignment requests 2183 on their technical merit. The designated experts MAY raise 2184 issues related to the allocation request with the authors and on 2185 the IDR (or successor) mailing list for further consideration 2186 before the assignments are made. 2188 6. The designated expert MUST ensure that any request for a code 2189 point does not conflict with work that is active or already 2190 published within the IETF. 2192 7. Once the designated experts have granted approval, IANA will 2193 update the registry by marking the allocated code points with a 2194 reference to the associated document. 2196 8. In the event that the document is a working group document or is 2197 AD-Sponsored, and that document fails to progress to publication 2198 as an RFC, the working group chairs or AD SHOULD contact IANA to 2199 coordinate about marking the code points as deprecated. A 2200 deprecated code point is not marked as allocated for use and is 2201 not available for allocation in a future document. The WG chairs 2202 may inform IANA that a deprecated code point can be completely 2203 deallocated (i.e., made available for new allocations) at any 2204 time after it has been deprecated if there is a shortage of 2205 unallocated code points in the registry. 2207 7. Manageability Considerations 2209 This section is structured as recommended in [RFC5706]. 2211 7.1. Operational Considerations 2213 7.1.1. Operations 2215 Existing BGP operational procedures apply. No new operation 2216 procedures are defined in this document. It is noted that the NLRI 2217 information present in this document carries purely application-level 2218 data that has no immediate impact on the corresponding forwarding 2219 state computed by BGP. As such, any churn in reachability 2220 information has a different impact than regular BGP updates, which 2221 need to change the forwarding state for an entire router. It is 2222 expected that the distribution of this NLRI SHOULD be handled by 2223 dedicated route reflectors in most deployments providing a level of 2224 isolation and fault containment between different NLRI types. In the 2225 event of dedicated route reflectors not being available, other 2226 alternate mechanisms like separation of BGP instances or separate BGP 2227 sessions (e.g. using different addresses for peering) for Link-State 2228 information distribution SHOULD be used. 2230 7.1.2. Installation and Initial Setup 2232 Configuration parameters defined in Section 7.2.3 SHOULD be 2233 initialized to the following default values: 2235 o The Link-State NLRI capability is turned off for all neighbors. 2237 o The maximum rate at which Link-State NLRIs will be advertised/ 2238 withdrawn from neighbors is set to 200 updates per second. 2240 7.1.3. Migration Path 2242 The proposed extension is only activated between BGP peers after 2243 capability negotiation. Moreover, the extensions can be turned on/ 2244 off on an individual peer basis (see Section 7.2.3), so the extension 2245 can be gradually rolled out in the network. 2247 7.1.4. Requirements on Other Protocols and Functional Components 2249 The protocol extension defined in this document does not put new 2250 requirements on other protocols or functional components. 2252 7.1.5. Impact on Network Operation 2254 The frequency of Link-State NLRI updates could interfere with regular 2255 BGP prefix distribution. A network operator MAY use a dedicated 2256 Route-Reflector infrastructure to distribute Link-State NLRIs. 2258 Distribution of Link-State NLRIs SHOULD be limited to a single admin 2259 domain, which can consist of multiple areas within an AS or multiple 2260 ASes. 2262 7.1.6. Verifying Correct Operation 2264 Existing BGP procedures apply. In addition, an implementation SHOULD 2265 allow an operator to: 2267 o List neighbors with whom the speaker is exchanging Link-State 2268 NLRIs. 2270 7.2. Management Considerations 2272 7.2.1. Management Information 2274 The IDR working group has documented and continues to document parts 2275 of the Management Information Base and YANG models for managing and 2276 monitoring BGP speakers and the sessions between them. It is 2277 currently believed that the BGP session running BGP-LS is not 2278 substantially different from any other BGP session and can be managed 2279 using the same data models. 2281 7.2.2. Fault Management 2283 This section describes the fault management actions, as described in 2284 [RFC7606], that are to be performed for the handling of BGP update 2285 messages for BGP-LS. 2287 A Link-State NLRI MUST NOT be considered as malformed or invalid 2288 based on the inclusion/exclusion of TLVs or contents of the TLV 2289 fields (i.e. semantic errors), as described in Section 4.1 and 2290 Section 4.2. 2292 A BGP-LS Speaker MUST perform the following syntactic validation of 2293 the Link-State NLRI to determine if it is malformed. 2295 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 2296 correspond to the BGP MP_REACH_NLRI length? 2298 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 2299 attribute correspond to the BGP MP_UNREACH_NLRI length? 2301 o Does the sum of all TLVs found in a Link-State NLRI correspond to 2302 the Total NLRI Length field of all its Descriptors? 2304 o Is the length of the TLVs and, when the TLV is recognized then, 2305 its sub-TLVs in the NLRI valid? 2307 o Has the syntactic correctness of the NLRI fields been verified as 2308 per [RFC7606]? 2310 o Has the rule regarding the ordering of TLVs been followed as 2311 described in Section 4.1? 2313 When the error determined allows for the router to skip the malformed 2314 NLRI(s) and continue the processing of the rest of the update message 2315 (e.g. when the TLV ordering rule is violated), then it MUST handle 2316 such malformed NLRIs as 'Treat-as-withdraw'. In other cases, where 2317 the error in the NLRI encoding results in the inability to process 2318 the BGP update message (e.g. length related encoding errors), then 2319 the router SHOULD handle such malformed NLRIs as 'AFI/SAFI disable' 2320 when other AFI/SAFI besides BGP-LS are being advertised over the same 2321 session. Alternately, the router MUST perform 'session reset' when 2322 the session is only being used for BGP-LS or when it 'AFI/SAFI 2323 disable' action is not possible. 2325 A BGP-LS Attribute MUST NOT be considered as malformed or invalid 2326 based on the inclusion/exclusion of TLVs or contents of the TLV 2327 fields (i.e. semantic errors), as described in Section 4.1 and 2328 Section 4.3. 2330 A BGP-LS Speaker MUST perform the following syntactic validation of 2331 the BGP-LS Attribute to determine if it is malformed. 2333 o Does the sum of all TLVs found in the BGP-LS Attribute correspond 2334 to the BGP-LS Attribute length? 2336 o Has the syntactic correctness of the Attributes (including BGP-LS 2337 Attribute) been verified as per [RFC7606]? 2339 o Is the length of each TLV and, when the TLV is recognized then, 2340 its sub-TLVs in the BGP-LS Attribute valid? 2342 When the error determined allows for the router to skip the malformed 2343 BGP-LS Attribute and continue the processing of the rest of the 2344 update message (e.g. when the BGP-LS Attribute length and the total 2345 Path Attribute Length are correct but some TLV/sub-TLV length within 2346 the BGP-LS Attribute is invalid), then it MUST handle such malformed 2347 BGP-LS Attribute as 'Attribute Discard'. In other cases, where the 2348 error in the BGP-LS Attribute encoding results in the inability to 2349 process the BGP update message then the handling is the same as 2350 described above for the malformed NLRI. 2352 Note that the 'Attribute Discard' action results in the loss of all 2353 TLVs in the BGP-LS Attribute and not the removal of a specific 2354 malformed TLV. The removal of specific malformed TLVs may give a 2355 wrong indication to a BGP-LS Consumer of that specific information 2356 being deleted or not available. 2358 When a BGP Speaker receives an update message with Link-State NLRI(s) 2359 in the MP_REACH_NLRI but without the BGP-LS Attribute, it is most 2360 likely an indication that a BGP Speaker preceding it has performed 2361 the 'Attribute Discard' fault handling. An implementation SHOULD 2362 preserve and propagate the Link-State NLRIs in such an update message 2363 so that the BGP-LS Consumers can detect the loss of link-state 2364 information for that object and not assume its deletion/withdraw. 2365 This also makes it possible for a network operator to trace back to 2366 the BGP-LS Propagator that detected the fault with the BGP-LS 2367 Attribute. 2369 An implementation SHOULD log an error for any errors found during 2370 syntax validation for further analysis. 2372 A BGP-LS Propagator, even when also operating as a BGP-LS Consumer, 2373 SHOULD NOT perform semantic validation of the Link-State NLRI or the 2374 BGP-LS Attribute to determine if it is malformed or invalid. Some 2375 types of semantic validation that are not to be performed by a BGP-LS 2376 Propagator are as follows (and this is not to be considered as an 2377 exhaustive list): 2379 o is a mandatory TLV present or not? 2381 o is the length of a fixed-length TLV correct or the length of a 2382 variable length TLV a valid/permissible? 2384 o are the values of TLV fields valid or permissible? 2386 o are the inclusion and use of TLVs/sub-TLVs with specific Link- 2387 State NLRI types valid? 2389 Each TLV MAY indicate the valid and permissible values and their 2390 semantics that can to be used only by a BGP-LS Consumer for its 2391 semantic validation. However, the handling of any errors may be 2392 specific to the particular application and outside the scope of this 2393 document. A BGP-LS Consumer should ignore unrecognized and 2394 unexpected TLV types in both the NLRI and BGP-LS Attribute portions 2395 and not consider their presence as an error. 2397 7.2.3. Configuration Management 2399 An implementation SHOULD allow the operator to specify neighbors to 2400 which Link-State NLRIs will be advertised and from which Link-State 2401 NLRIs will be accepted. 2403 An implementation SHOULD allow the operator to specify the maximum 2404 rate at which Link-State NLRIs will be advertised/withdrawn from 2405 neighbors. 2407 An implementation SHOULD allow the operator to specify the maximum 2408 number of Link-State NLRIs stored in a router's Routing Information 2409 Base (RIB). 2411 An implementation SHOULD allow the operator to create abstracted 2412 topologies that are advertised to neighbors and create different 2413 abstractions for different neighbors. 2415 An implementation SHOULD allow the operator to configure a 64-bit 2416 Instance-ID. 2418 An implementation SHOULD allow the operator to configure ASN and BGP- 2419 LS identifiers (refer to Section 4.2.1.4). 2421 An implementation SHOULD allow the operator to configure the maximum 2422 size of the BGP-LS Attribute that may be used on a BGP-LS Producer. 2424 7.2.4. Accounting Management 2426 Not Applicable. 2428 7.2.5. Performance Management 2430 An implementation SHOULD provide the following statistics: 2432 o Total number of Link-State NLRI updates sent/received 2434 o Number of Link-State NLRI updates sent/received, per neighbor 2436 o Number of errored received Link-State NLRI updates, per neighbor 2438 o Total number of locally originated Link-State NLRIs 2440 These statistics should be recorded as absolute counts since system 2441 or session start time. An implementation MAY also enhance this 2442 information by recording peak per-second counts in each case. 2444 7.2.6. Security Management 2446 An operator SHOULD define an import policy to limit inbound updates 2447 as follows: 2449 o Drop all updates from peers that are only serving BGP-LS 2450 Consumers. 2452 An implementation MUST have the means to limit inbound updates. 2454 8. TLV/Sub-TLV Code Points Summary 2456 This section contains the global table of all TLVs/sub-TLVs defined 2457 in this document. 2459 +---------------+---------------------------+-----------------------+ 2460 | TLV Code | Description | Reference | 2461 | Point | | (RFC/Section) | 2462 +---------------+---------------------------+-----------------------+ 2463 | 256 | Local Node Descriptors | Section 4.2.1.2 | 2464 | 257 | Remote Node Descriptors | Section 4.2.1.3 | 2465 | 258 | Link Local/Remote | [RFC5307] / 1.1 | 2466 | | Identifiers | | 2467 | 259 | IPv4 interface address | [RFC5305] / 3.2 | 2468 | 260 | IPv4 neighbor address | [RFC5305] / 3.3 | 2469 | 261 | IPv6 interface address | [RFC6119] / 4.2 | 2470 | 262 | IPv6 neighbor address | [RFC6119] / 4.3 | 2471 | 263 | Multi-Topology ID | Section 4.2.2.1 | 2472 | 264 | OSPF Route Type | Section 4.2.3 | 2473 | 265 | IP Reachability | Section 4.2.3 | 2474 | | Information | | 2475 | 512 | Autonomous System | Section 4.2.1.4 | 2476 | 513 | BGP-LS Identifier | Section 4.2.1.4 | 2477 | | (deprecated) | | 2478 | 514 | OSPF Area-ID | Section 4.2.1.4 | 2479 | 515 | IGP Router-ID | Section 4.2.1.4 | 2480 | 1024 | Node Flag Bits | Section 4.3.1.1 | 2481 | 1025 | Opaque Node Attribute | Section 4.3.1.5 | 2482 | 1026 | Node Name | Section 4.3.1.3 | 2483 | 1027 | IS-IS Area Identifier | Section 4.3.1.2 | 2484 | 1028 | IPv4 Router-ID of Local | [RFC5305] / 4.3 | 2485 | | Node | | 2486 | 1029 | IPv6 Router-ID of Local | [RFC6119] / 4.1 | 2487 | | Node | | 2488 | 1030 | IPv4 Router-ID of Remote | [RFC5305] / 4.3 | 2489 | | Node | | 2490 | 1031 | IPv6 Router-ID of Remote | [RFC6119] / 4.1 | 2491 | | Node | | 2492 | 1088 | Administrative group | [RFC5305] / 3.1 | 2493 | | (color) | | 2494 | 1089 | Maximum link bandwidth | [RFC5305] / 3.4 | 2495 | 1090 | Max. reservable link | [RFC5305] / 3.5 | 2496 | | bandwidth | | 2497 | 1091 | Unreserved bandwidth | [RFC5305] / 3.6 | 2498 | 1092 | TE Default Metric | Section 4.3.2.3 | 2499 | 1093 | Link Protection Type | [RFC5307] / 1.2 | 2500 | 1094 | MPLS Protocol Mask | Section 4.3.2.2 | 2501 | 1095 | IGP Metric | Section 4.3.2.4 | 2502 | 1096 | Shared Risk Link Group | Section 4.3.2.5 | 2503 | 1097 | Opaque Link Attribute | Section 4.3.2.6 | 2504 | 1098 | Link Name | Section 4.3.2.7 | 2505 | 1152 | IGP Flags | Section 4.3.3.1 | 2506 | 1153 | IGP Route Tag | [RFC5130] | 2507 | 1154 | IGP Extended Route Tag | [RFC5130] | 2508 | 1155 | Prefix Metric | [RFC5305] | 2509 | 1156 | OSPF Forwarding Address | [RFC2328] | 2510 | 1157 | Opaque Prefix Attribute | Section 4.3.3.6 | 2511 +---------------+---------------------------+-----------------------+ 2513 Table 12: Summary Table of TLV/Sub-TLV Code Points 2515 9. Security Considerations 2517 Procedures and protocol extensions defined in this document do not 2518 affect the BGP security model. See the Security Considerations 2519 section of [RFC4271] for a discussion of BGP security. Also, refer 2520 to [RFC4272] and [RFC6952] for analysis of security issues for BGP. 2522 In the context of the BGP peerings associated with this document, a 2523 BGP speaker MUST NOT accept updates from a peer that is only 2524 providing information to a BGP-LS Consumer. That is, a participating 2525 BGP speaker should be aware of the nature of its relationships for 2526 link-state relationships and should protect itself from peers sending 2527 updates that either represent erroneous information feedback loops or 2528 are false input. Such protection can be achieved by manual 2529 configuration of consumer peers at the BGP speaker. 2531 An operator SHOULD employ a mechanism to protect a BGP speaker 2532 against DDoS attacks from BGP-LS Consumers. The principal attack a 2533 consumer may apply is to attempt to start multiple sessions either 2534 sequentially or simultaneously. Protection can be applied by 2535 imposing rate limits. 2537 Additionally, it may be considered that the export of link-state and 2538 TE information as described in this document constitutes a risk to 2539 confidentiality of mission-critical or commercially sensitive 2540 information about the network. BGP peerings are not automatic and 2541 require configuration; thus, it is the responsibility of the network 2542 operator to ensure that only trusted consumers are configured to 2543 receive such information. 2545 10. Contributors 2547 The following persons contributed significant text to RFC7752 and 2548 this document. They should be considered as co-authors. 2550 Hannes Gredler 2551 Rtbrick 2552 Email: hannes@rtbrick.com 2554 Jan Medved 2555 Cisco Systems Inc. 2556 USA 2557 Email: jmedved@cisco.com 2559 Stefano Previdi 2560 Huawei Technologies 2561 Italy 2562 Email: stefano@previdi.net 2564 Adrian Farrel 2565 Old Dog Consulting 2566 Email: adrian@olddog.co.uk 2568 Saikat Ray 2569 Individual 2570 USA 2571 Email: raysaikat@gmail.com 2573 11. Acknowledgements 2575 This document update to the BGP-LS specification [RFC7752] is a 2576 result of feedback and inputs from the discussions in the IDR working 2577 group. It also incorporates certain details and clarifications based 2578 on implementation and deployment experience with BGP-LS. 2580 Cengiz Alaettinoglu and Parag Amritkar brought forward the need to 2581 clarify the advertisement of LAN subnet for OSPF. 2583 We would like to thank Balaji Rajagopalan, Srihari Sangli, Shraddha 2584 Hegde, Andrew Stone, Jeff Tantsura, Acee Lindem, Les Ginsberg, Jie 2585 Dong, Aijun Wang and Nandan Saha for their review and feedback on 2586 this document. Thanks to Tom Petch for his review and comments on 2587 the IANA Considerations section. Would also like to thank Jeffery 2588 Haas for his detailed shepherd review and inputs for improving the 2589 document. 2591 We would like to thank Robert Varga for his significant contribution 2592 to RFC7752. 2594 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 2595 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 2596 Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, 2597 Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas 2598 Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, 2599 Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and 2600 Ben Campbell for their comments on RFC7752. 2602 12. References 2604 12.1. Normative References 2606 [ISO10589] 2607 International Organization for Standardization, 2608 "Intermediate System to Intermediate System intra-domain 2609 routeing information exchange protocol for use in 2610 conjunction with the protocol for providing the 2611 connectionless-mode network service (ISO 8473)", ISO/ 2612 IEC 10589, November 2002. 2614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2615 Requirement Levels", BCP 14, RFC 2119, 2616 DOI 10.17487/RFC2119, March 1997, 2617 . 2619 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 2620 DOI 10.17487/RFC2328, April 1998, 2621 . 2623 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2624 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2625 DOI 10.17487/RFC2545, March 1999, 2626 . 2628 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2629 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2630 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2631 . 2633 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 2634 in Support of Generalized Multi-Protocol Label Switching 2635 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 2636 . 2638 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 2639 Support of Generalized Multi-Protocol Label Switching 2640 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 2641 . 2643 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2644 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2645 DOI 10.17487/RFC4271, January 2006, 2646 . 2648 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 2649 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 2650 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 2651 June 2006, . 2653 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2654 "Multiprotocol Extensions for BGP-4", RFC 4760, 2655 DOI 10.17487/RFC4760, January 2007, 2656 . 2658 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 2659 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 2660 RFC 4915, DOI 10.17487/RFC4915, June 2007, 2661 . 2663 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 2664 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 2665 October 2007, . 2667 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 2668 Topology (MT) Routing in Intermediate System to 2669 Intermediate Systems (IS-ISs)", RFC 5120, 2670 DOI 10.17487/RFC5120, February 2008, 2671 . 2673 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 2674 Control Mechanism in IS-IS Using Administrative Tags", 2675 RFC 5130, DOI 10.17487/RFC5130, February 2008, 2676 . 2678 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 2679 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 2680 October 2008, . 2682 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2683 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2684 2008, . 2686 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 2687 in Support of Generalized Multi-Protocol Label Switching 2688 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 2689 . 2691 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2692 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2693 . 2695 [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, 2696 "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, 2697 DOI 10.17487/RFC5642, August 2009, 2698 . 2700 [RFC5890] Klensin, J., "Internationalized Domain Names for 2701 Applications (IDNA): Definitions and Document Framework", 2702 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2703 . 2705 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 2706 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 2707 February 2011, . 2709 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 2710 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 2711 March 2012, . 2713 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 2714 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 2715 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 2716 June 2012, . 2718 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2719 Patel, "Revised Error Handling for BGP UPDATE Messages", 2720 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2721 . 2723 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 2724 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 2725 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2726 2015, . 2728 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 2729 S. Ray, "North-Bound Distribution of Link-State and 2730 Traffic Engineering (TE) Information Using BGP", RFC 7752, 2731 DOI 10.17487/RFC7752, March 2016, 2732 . 2734 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2735 Writing an IANA Considerations Section in RFCs", BCP 26, 2736 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2737 . 2739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2741 May 2017, . 2743 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 2744 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2745 2017, . 2747 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 2748 F. Baker, "OSPFv3 Link State Advertisement (LSA) 2749 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2750 2018, . 2752 [RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message 2753 Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October 2754 2019, . 2756 [RFC9029] Farrel, A., "Updates to the Allocation Policy for the 2757 Border Gateway Protocol - Link State (BGP-LS) Parameters 2758 Registries", RFC 9029, DOI 10.17487/RFC9029, June 2021, 2759 . 2761 12.2. Informative References 2763 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2764 and E. Lear, "Address Allocation for Private Internets", 2765 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2766 . 2768 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2769 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2770 . 2772 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2773 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2774 2006, . 2776 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2777 Element (PCE)-Based Architecture", RFC 4655, 2778 DOI 10.17487/RFC4655, August 2006, 2779 . 2781 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 2782 Per-Domain Path Computation Method for Establishing Inter- 2783 Domain Traffic Engineering (TE) Label Switched Paths 2784 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 2785 . 2787 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 2788 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2789 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 2790 December 2008, . 2792 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 2793 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2794 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 2795 January 2009, . 2797 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2798 Optimization (ALTO) Problem Statement", RFC 5693, 2799 DOI 10.17487/RFC5693, October 2009, 2800 . 2802 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 2803 Management of New Protocols and Protocol Extensions", 2804 RFC 5706, DOI 10.17487/RFC5706, November 2009, 2805 . 2807 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2808 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2809 and Authentication for Routing Protocols (KARP) Design 2810 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2811 . 2813 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 2814 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 2815 "Application-Layer Traffic Optimization (ALTO) Protocol", 2816 RFC 7285, DOI 10.17487/RFC7285, September 2014, 2817 . 2819 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 2820 S. Shaffer, "Extensions to OSPF for Advertising Optional 2821 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 2822 February 2016, . 2824 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 2825 "Advertisement of Multiple Paths in BGP", RFC 7911, 2826 DOI 10.17487/RFC7911, July 2016, 2827 . 2829 Appendix A. Changes from RFC 7752 2831 This section lists the high-level changes from RFC 7752 and provides 2832 reference to the document sections wherein those have been 2833 introduced. 2835 1. Update the Figure 1 in Section 1 and added Section 3 to 2836 illustrate the different roles of a BGP implementation in 2837 conveying link-state information. 2839 2. In Section 4.1, clarification about the TLV handling aspects 2840 that are applicable to both the NLRI and BGP-LS Attribute parts 2841 and those that are applicable only for the NLRI portion. An 2842 implementation may have missed the part about handling of 2843 unrecognized TLV and so, based on [RFC7606] guidelines, might 2844 discard the unknown NLRI types. This aspect is now 2845 unambiguously clarified in Section 4.2. Also, the TLVs in the 2846 BGP-LS Attribute that are not ordered are not to be considered 2847 as malformed. 2849 3. Clarification of mandatory and optional TLVs in both NLRI and 2850 BGP-LS Attribute portions all through the document. 2852 4. Handling of large size of BGP-LS Attribute with growth in BGP-LS 2853 information is explained in Section 4.3 along with mitigation of 2854 errors arising out of it. 2856 5. Clarified that the document describes the NLRI descriptor TLVs 2857 for the protocols and NLRI types specified in this document and 2858 future BGP-LS extensions must describe the same for other 2859 protocols and NLRI types that they introduce. 2861 6. Clarification on the use of Identifier field in the Link-State 2862 NLRI in Section 4.2 is provided. It was defined ambiguously to 2863 refer to only mutli-instance IGP on a single link while it can 2864 also be used for multiple IGP protocol instances on a router. 2865 The IANA registry is accordingly being removed. 2867 7. The BGP-LS Identifier TLV in the Node Descriptors has been 2868 deprecated. Its use was not well specified by [RFC7752] and 2869 there has been some amount of confusion between implementators 2870 on its usage for identification of IGP domains as against the 2871 use of the Identifier doing the same functionality as the 2872 Instance-ID when running multiple instances of IGP routing 2873 protocols. 2875 8. Clarification that the Area-ID TLV is mandatory in the Node 2876 Descriptor for origination of information from OSPF except for 2877 when sourcing information from AS-scope LSAs where this TLV is 2878 not applicable. 2880 9. Moved MT-ID TLV from the Node Descriptor section to under the 2881 Link Descriptor section since it is not a Node Descriptor sub- 2882 TLV. Fixed the ambiguity in the encoding of OSPF MT-ID in this 2883 TLV. Updated the IS-IS specification reference section and 2884 describe the differences in the applicability of the R flags 2885 when MT-ID TLV is used as link descriptor TLV and Prefix 2886 Attribute TLV. MT-ID TLV use is now elevated to SHOULD when it 2887 is enabled in the underlying IGP. 2889 10. Clarified that IPv6 Link-Local Addresses are not advertised in 2890 the Link Descriptor TLVs and the local/remote identifiers are to 2891 be used instead for links with IPv6 link-local addresses only. 2893 11. Update the usage of OSPF Route Type TLV to mandate its use for 2894 OSPF prefixes in Section 4.2.3.1 since this is required for 2895 segregation of intra-area prefixes that are used to reach a node 2896 (e.g. a loopback) from other types of inter-area and external 2897 prefixes. 2899 12. Clarification on the specific OSPFv2 and OSPFv3 protocol TLV 2900 space to be used in the node, link and prefix opaque attribute 2901 TLVs. 2903 13. Clarification on the length of the Node Flag Bits and IGP Flags 2904 TLVs to be one octet. 2906 14. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF 2907 specification. 2909 15. Clarification on the size of the IS-IS Narrow Metric 2910 advertisement via the IGP Metric TLV and the handling of the 2911 unused bits. 2913 16. Clarified the advertisement of the prefix corresponding to the 2914 LAN segment in an OSPF network in Section 4.11. 2916 17. Clarified the advertisement and support for OSPF specific 2917 concepts like Virtual links, Sham links and Type 4 LSAs in 2918 Section 4.7 and Section 4.8. 2920 18. Introduced Private Use TLV code point space and specified their 2921 encoding in Section 4.4. 2923 19. Introduced Section 4.9 where issues related to consistency of 2924 reporting IGP link-state along with their solutions are covered. 2926 20. Added recommendation for isolation of BGP-LS sessions from other 2927 BGP route exchange to avoid errors and faults in BGP-LS 2928 affecting the normal BGP routing. 2930 21. Updated the Fault Management section with detailed rules based 2931 on the role in the BGP-LS information propagation flow. 2933 22. Change to the management of BGP-LS IANA registries from 2934 "Specification Required" to "Expert Review" along with updated 2935 guidelines for Designated Experts. More specifically the 2936 inclusion of changes introduced via [RFC9029] that is obsoleted 2937 by this document. 2939 23. Added BGP-LS IANA registries with "RFC Required" policy for the 2940 flag fields of various TLVs that was missed out. Removed the 2941 "IS-IS TLV/Sub-TLV" column from the BGP-LS TLV registry. 2943 Author's Address 2945 Ketan Talaulikar (editor) 2946 Cisco Systems 2947 India 2949 Email: ketant.ietf@gmail.com