idnits 2.17.1 draft-ietf-idr-rfc7752bis-05.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 2, 2020) is 1270 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' ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 (if approved) November 2, 2020 5 Intended status: Standards Track 6 Expires: May 6, 2021 8 Distribution of Link-State and Traffic Engineering Information Using BGP 9 draft-ietf-idr-rfc7752bis-05 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 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 a number of small changes and clarifications to 31 the previous specification. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 6, 2021. 50 Copyright Notice 52 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . 18 78 4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 22 79 4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 23 80 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 24 81 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27 82 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32 83 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 36 84 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36 85 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36 86 4.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 37 87 4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 37 88 4.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37 89 4.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 39 90 4.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 40 91 4.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 41 92 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 42 93 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 42 94 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 42 95 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 43 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 97 6.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 44 98 6.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 44 99 6.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 44 100 6.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 45 101 6.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 45 102 6.1.5. BGP-LS MPLS Protocol Mask Registry . . . . . . . . . 45 103 6.1.6. BGP-LS IGP Prefix Flags Registry . . . . . . . . . . 45 104 6.1.7. BGP-LS TLVs Registry . . . . . . . . . . . . . . . . 46 105 6.2. Guidance for Designated Experts . . . . . . . . . . . . . 46 106 7. Manageability Considerations . . . . . . . . . . . . . . . . 46 107 7.1. Operational Considerations . . . . . . . . . . . . . . . 46 108 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 47 109 7.1.2. Installation and Initial Setup . . . . . . . . . . . 47 110 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 47 111 7.1.4. Requirements on Other Protocols and Functional 112 Components . . . . . . . . . . . . . . . . . . . . . 47 113 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 47 114 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 48 115 7.2. Management Considerations . . . . . . . . . . . . . . . . 48 116 7.2.1. Management Information . . . . . . . . . . . . . . . 48 117 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 48 118 7.2.3. Configuration Management . . . . . . . . . . . . . . 50 119 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 51 120 7.2.5. Performance Management . . . . . . . . . . . . . . . 51 121 7.2.6. Security Management . . . . . . . . . . . . . . . . . 51 122 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 52 123 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53 124 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 125 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 126 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 127 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 128 12.2. Informative References . . . . . . . . . . . . . . . . . 58 129 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 60 130 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 132 1. Introduction 134 The contents of a Link-State Database (LSDB) or of an IGP's Traffic 135 Engineering Database (TED) describe only the links and nodes within 136 an IGP area. Some applications, such as end-to-end Traffic 137 Engineering (TE), would benefit from visibility outside one area or 138 Autonomous System (AS) in order to make better decisions. 140 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 141 a mechanism for achieving the computation of end-to-end TE paths that 142 cross the visibility of more than one TED or that require CPU- 143 intensive or coordinated computations. The IETF has also defined the 144 ALTO server [RFC5693] as an entity that generates an abstracted 145 network topology and provides it to network-aware applications. 147 Both a PCE and an ALTO server need to gather information about the 148 topologies and capabilities of the network in order to be able to 149 fulfill their function. 151 This document describes a mechanism by which link-state and TE 152 information can be collected from networks and shared with external 153 components using the BGP routing protocol [RFC4271]. This is 154 achieved using a new BGP Network Layer Reachability Information 155 (NLRI) encoding format. The mechanism is applicable to physical and 156 virtual links. The mechanism described is subject to policy control. 158 A router maintains one or more databases for storing link-state 159 information about nodes and links in any given area. Link attributes 160 stored in these databases include: local/remote IP addresses, local/ 161 remote interface identifiers, link metric and TE metric, link 162 bandwidth, reservable bandwidth, per Class-of-Service (CoS) class 163 reservation state, preemption, and Shared Risk Link Groups (SRLGs). 164 The router's BGP process can retrieve topology from these LSDBs and 165 distribute it to a consumer, either directly or via a peer BGP 166 speaker (typically a dedicated Route Reflector), using the encoding 167 specified in this document. 169 An illustration of the collection of link-state and TE information 170 and its distribution to consumers is shown in the Figure 1 below. 172 +-----------+ 173 | Consumer | 174 +-----------+ 175 ^ 176 | 177 +-----------+ +-----------+ 178 | BGP | | BGP | 179 | Speaker |<----------->| Speaker | +-----------+ 180 | RR1 | | RRm | | Consumer | 181 +-----------+ +-----------+ +-----------+ 182 ^ ^ ^ ^ 183 | | | | 184 +-----+ +---------+ +---------+ | 185 | | | | 186 +-----------+ +-----------+ +-----------+ 187 | BGP | | BGP | | BGP | 188 | Speaker | | Speaker | . . . | Speaker | 189 | R1 | | R2 | | Rn | 190 +-----------+ +-----------+ +-----------+ 191 ^ ^ ^ 192 | | | 193 IGP IGP IGP 195 Figure 1: Collection of Link-State and TE Information 197 A BGP speaker may apply configurable policy to the information that 198 it distributes. Thus, it may distribute the real physical topology 199 from the LSDB or the TED. Alternatively, it may create an abstracted 200 topology, where virtual, aggregated nodes are connected by virtual 201 paths. Aggregated nodes can be created, for example, out of multiple 202 routers in a Point of Presence (POP). Abstracted topology can also 203 be a mix of physical and virtual nodes and physical and virtual 204 links. Furthermore, the BGP speaker can apply policy to determine 205 when information is updated to the consumer so that there is a 206 reduction of information flow from the network to the consumers. 207 Mechanisms through which topologies can be aggregated or virtualized 208 are outside the scope of this document. 210 This document obsoletes [RFC7752] by completely replacing that 211 document. It makes a number of small changes and clarifications to 212 the previous specification as documented in Appendix A. 214 1.1. Requirements Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 2. Motivation and Applicability 224 This section describes use cases from which the requirements can be 225 derived. 227 2.1. MPLS-TE with PCE 229 As described in [RFC4655], a PCE can be used to compute MPLS-TE paths 230 within a "domain" (such as an IGP area) or across multiple domains 231 (such as a multi-area AS or multiple ASes). 233 o Within a single area, the PCE offers enhanced computational power 234 that may not be available on individual routers, sophisticated 235 policy control and algorithms, and coordination of computation 236 across the whole area. 238 o If a router wants to compute a MPLS-TE path across IGP areas, then 239 its own TED lacks visibility of the complete topology. That means 240 that the router cannot determine the end-to-end path and cannot 241 even select the right exit router (Area Border Router (ABR)) for 242 an optimal path. This is an issue for large-scale networks that 243 need to segment their core networks into distinct areas but still 244 want to take advantage of MPLS-TE. 246 Previous solutions used per-domain path computation [RFC5152]. The 247 source router could only compute the path for the first area because 248 the router only has full topological visibility for the first area 249 along the path, but not for subsequent areas. Per-domain path 250 computation uses a technique called "loose-hop-expansion" [RFC3209] 251 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 252 using the IGP-computed shortest path topology for the remainder of 253 the path. This may lead to sub-optimal paths, makes alternate/back- 254 up path computation hard, and might result in no TE path being found 255 when one really does exist. 257 The PCE presents a computation server that may have visibility into 258 more than one IGP area or AS, or may cooperate with other PCEs to 259 perform distributed path computation. The PCE obviously needs access 260 to the TED for the area(s) it serves, but [RFC4655] does not describe 261 how this is achieved. Many implementations make the PCE a passive 262 participant in the IGP so that it can learn the latest state of the 263 network, but this may be sub-optimal when the network is subject to a 264 high degree of churn or when the PCE is responsible for multiple 265 areas. 267 The following figure shows how a PCE can get its TED information 268 using the mechanism described in this document. 270 +----------+ +---------+ 271 | ----- | | BGP | 272 | | TED |<-+-------------------------->| Speaker | 273 | ----- | TED synchronization | | 274 | | | mechanism: +---------+ 275 | | | BGP with Link-State NLRI 276 | v | 277 | ----- | 278 | | PCE | | 279 | ----- | 280 +----------+ 281 ^ 282 | Request/ 283 | Response 284 v 285 Service +----------+ Signaling +----------+ 286 Request | Head-End | Protocol | Adjacent | 287 -------->| Node |<------------>| Node | 288 +----------+ +----------+ 290 Figure 2: External PCE Node Using a TED Synchronization Mechanism 292 The mechanism in this document allows the necessary TED information 293 to be collected from the IGP within the network, filtered according 294 to configurable policy, and distributed to the PCE as necessary. 296 2.2. ALTO Server Network API 298 An ALTO server [RFC5693] is an entity that generates an abstracted 299 network topology and provides it to network-aware applications over a 300 web-service-based API. Example applications are peer-to-peer (P2P) 301 clients or trackers, or Content Distribution Networks (CDNs). The 302 abstracted network topology comes in the form of two maps: a Network 303 Map that specifies allocation of prefixes to Partition Identifiers 304 (PIDs), and a Cost Map that specifies the cost between PIDs listed in 305 the Network Map. For more details, see [RFC7285]. 307 ALTO abstract network topologies can be auto-generated from the 308 physical topology of the underlying network. The generation would 309 typically be based on policies and rules set by the operator. Both 310 prefix and TE data are required: prefix data is required to generate 311 ALTO Network Maps, and TE (topology) data is required to generate 312 ALTO Cost Maps. Prefix data is carried and originated in BGP, and TE 313 data is originated and carried in an IGP. The mechanism defined in 314 this document provides a single interface through which an ALTO 315 server can retrieve all the necessary prefix and network topology 316 data from the underlying network. Note that an ALTO server can use 317 other mechanisms to get network data, for example, peering with 318 multiple IGP and BGP speakers. 320 The following figure shows how an ALTO server can get network 321 topology information from the underlying network using the mechanism 322 described in this document. 324 +--------+ 325 | Client |<--+ 326 +--------+ | 327 | ALTO +--------+ BGP with +---------+ 328 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 329 | Client |<--+------------| Server |<----------------| Speaker | 330 +--------+ | | | | | 331 | +--------+ +---------+ 332 +--------+ | 333 | Client |<--+ 334 +--------+ 336 Figure 3: ALTO Server Using Network Topology Information 338 3. BGP Speaker Roles for BGP-LS 340 In the illustration shown in Figure 1, the BGP Speakers can be seen 341 playing different roles in the distribution of information using BGP- 342 LS. This section introduces terms that explain the different roles 343 of the BGP Speakers which are then used through the rest of this 344 document. 346 o BGP-LS Producer: The BGP Speakers R1, R2, ... Rn, originate link- 347 state information from their underlying link-state IGP protocols 348 into BGP-LS. If R1 and R2 are in the same IGP area, then likely 349 they are originating the same link-state information into BGP-LS. 350 R1 may also source information from sources other than IGP, e.g. 351 its local node information. The term BGP-LS Producer refers to 352 the BGP Speaker that is originating link-state information into 353 BGP. 355 o BGP-LS Consumer: The BGP Speakers RR1 and Rn are handing off the 356 BGP-LS information that they have collected to a consumer 357 application. The BGP protocol implementation and the consumer 358 application may be on the same or different nodes. The term BGP- 359 LS Consumer refers to the consumer application/process and not the 360 BGP Speaker. This document only covers the BGP implementation. 361 The consumer application and the design of interface between BGP 362 and consumer application may be implementation specific and 363 outside the scope of this document. 365 o BGP-LS Propagator: The BGP Speaker RRm propagates the BGP-LS 366 information between the BGP Speaker Rn and the BGP Speaker RR1. 367 The BGP implementation on RRm is doing the propagation of BGP-LS 368 updates and performing BGP best path calculations. Similarly, the 369 BGP Speaker RR1 is receiving BGP-LS information from R1, R2 and 370 RRm and propagating the information to the BGP-LS Consumer after 371 performing BGP best path calculations. The term BGP-LS Propagator 372 refers to the BGP Speaker that is performing BGP protocol 373 processing on the link-state information. 375 The above roles are not mutually exclusive. The same BGP Speaker may 376 be the producer for some link-state information and propagator for 377 some other link-state information while also providing this 378 information to a consumer application. Nothing precludes a BGP 379 implementation performing some of the validation and processing on 380 behalf of the BGP-LS Consumer as long as it does not impact the 381 semantics of its role as BGP-LS Propagator as described in this 382 document. 384 The rest of this document refers to the role when describing 385 procedures that are specific to that role. When the role is not 386 specified, then the said procedure applies to all BGP Speakers. 388 4. Carrying Link-State Information in BGP 390 This specification contains two parts: definition of a new BGP NLRI 391 that describes links, nodes, and prefixes comprising IGP link-state 392 information and definition of a new BGP path attribute (BGP-LS 393 Attribute) that carries link, node, and prefix properties and 394 attributes, such as the link and prefix metric or auxiliary Router- 395 IDs of nodes, etc. 397 It is desirable to keep the dependencies on the protocol source of 398 this attribute to a minimum and represent any content in an IGP- 399 neutral way, such that applications that want to learn about a link- 400 state topology do not need to know about any OSPF or IS-IS protocol 401 specifics. 403 This section mainly describes the procedures at a BGP-LS Producer 404 that originate link-state information into BGP-LS. 406 4.1. TLV Format 408 Information in the new Link-State NLRIs and the BGP-LS Attribute is 409 encoded in Type/Length/Value triplets. The TLV format is shown in 410 Figure 4 and applies to both the NLRI and the BGP-LS Attribute 411 encodings. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 // Value (variable) // 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 4: TLV Format 423 The Length field defines the length of the value portion in octets 424 (thus, a TLV with no value portion would have a length of zero). The 425 TLV is not padded to 4-octet alignment. Unknown and unsupported 426 types MUST be preserved and propagated within both the NLRI and the 427 BGP-LS Attribute. The presence of unrecognized or unexpected TLVs 428 MUST NOT result in the NLRI or the BGP-LS Attribute being considered 429 as malformed. 431 In order to compare NLRIs with unknown TLVs, all TLVs within the NLRI 432 MUST be ordered in ascending order by TLV Type. If there are 433 multiple TLVs of the same type within a single NLRI, then the TLVs 434 sharing the same type MUST be in ascending order based on the value 435 field. Comparison of the value fields is performed by treating the 436 entire field as an opaque hexadecimal string. Standard string 437 comparison rules apply. NLRIs having TLVs which do not follow the 438 above ordering rules MUST be considered as malformed by a BGP-LS 439 Propagator. This ensures that multiple copies of the same NLRI from 440 multiple BGP-LS Producers and the ambiguity arising there from is 441 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 MAY be ordered in ascending 448 order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be 449 considered malformed. 451 4.2. The Link-State NLRI 453 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 454 for carrying opaque information. This specification defines three 455 Link-State NLRI types that describes either a node, a link, and a 456 prefix. 458 All non-VPN link, node, and prefix information SHALL be encoded using 459 AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be 460 encoded using AFI 16388 / SAFI 72. 462 In order for two BGP speakers to exchange Link-State NLRI, they MUST 463 use BGP Capabilities Advertisement to ensure that they are both 464 capable of properly processing such NLRI. This is done as specified 465 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 466 AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for 467 BGP-LS-VPN. 469 New Link-State NLRI Types may be introduced in the future. Since 470 supported NLRI type values within the address family are not 471 expressed in the Multiprotocol BGP (MP-BGP) capability [RFC4760], it 472 is possible that a BGP speaker has advertised support for Link-State 473 but does not support a particular Link-State NLRI type. In order to 474 allow introduction of new Link-State NLRI types seamlessly in the 475 future, without the need for upgrading all BGP speakers in the 476 propagation path (e.g. a route reflector), this document deviates 477 from the default handling behavior specified by [RFC7606] for Link- 478 State address-family. An implementation MUST handle unrecognized 479 Link-State NLRI types as opaque objects and MUST preserve and 480 propagate them. 482 The format of the Link-State NLRI is shown in the following figures. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | NLRI Type | Total NLRI Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | 490 // Link-State NLRI (variable) // 491 | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | NLRI Type | Total NLRI Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 + Route Distinguisher + 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 // Link-State NLRI (variable) // 507 | | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format 512 The Total NLRI Length field contains the cumulative length, in 513 octets, of the rest of the NLRI, not including the NLRI Type field or 514 itself. For VPN applications, it also includes the length of the 515 Route Distinguisher. 517 +------+---------------------------+ 518 | Type | NLRI Type | 519 +------+---------------------------+ 520 | 1 | Node NLRI | 521 | 2 | Link NLRI | 522 | 3 | IPv4 Topology Prefix NLRI | 523 | 4 | IPv6 Topology Prefix NLRI | 524 +------+---------------------------+ 526 Table 1: NLRI Types 528 Route Distinguishers are defined and discussed in [RFC4364]. 530 The Node NLRI (NLRI Type = 1) is shown in the following figure. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+ 535 | Protocol-ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Identifier | 538 | (64 bits) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 // Local Node Descriptors (variable) // 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 7: The Node NLRI Format 545 The Link NLRI (NLRI Type = 2) is shown in the following figure. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+ 550 | Protocol-ID | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Identifier | 553 | (64 bits) | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 // Local Node Descriptors (variable) // 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 // Remote Node Descriptors (variable) // 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 // Link Descriptors (variable) // 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 8: The Link NLRI Format 564 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 565 same format, as shown in the following figure. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+ 570 | Protocol-ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Identifier | 573 | (64 bits) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 // Local Node Descriptors (variable) // 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 // Prefix Descriptors (variable) // 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format 582 The Protocol-ID field can contain one of the following values: 584 +-------------+----------------------------------+ 585 | Protocol-ID | NLRI information source protocol | 586 +-------------+----------------------------------+ 587 | 1 | IS-IS Level 1 | 588 | 2 | IS-IS Level 2 | 589 | 3 | OSPFv2 | 590 | 4 | Direct | 591 | 5 | Static configuration | 592 | 6 | OSPFv3 | 593 +-------------+----------------------------------+ 595 Table 2: Protocol Identifiers 597 The 'Direct' and 'Static configuration' protocol types SHOULD be used 598 when BGP-LS is sourcing local information. For all information 599 derived from other protocols, the corresponding Protocol-ID MUST be 600 used. If BGP-LS has direct access to interface information and wants 601 to advertise a local link, then the Protocol-ID 'Direct' SHOULD be 602 used. For modeling virtual links, such as described in Section 5, 603 the Protocol-ID 'Static configuration' SHOULD be used. 605 A router MAY run multiple protocol instances of OSPF or ISIS where by 606 it becomes a border router between multiple IGP domains. Both OSPF 607 and IS-IS MAY also run multiple routing protocol instances over the 608 same link. See [RFC8202] and [RFC6549]. These instances define 609 independent IGP routing domains. The 64-bit Identifier field carries 610 a BGP-LS Instance Identifier (Instance-ID) that is used to identify 611 the IGP routing domain where the NLRI belongs. The NLRIs 612 representing link-state objects (nodes, links, or prefixes) from the 613 same IGP routing instance MUST have the same Identifier field value. 614 NLRIs with different Identifier field values MUST be considered to be 615 from different IGP routing instances. The Identifier field value 0 616 is RECOMMENDED to be used when there is only a single protocol 617 instance in the network where BGP-LS is operational. 619 An implementation which supports multiple IGP instances MUST support 620 the configuration of unique BGP-LS Instance-IDs at the routing 621 protocol instance level. The network operator MUST assign consistent 622 BGP-LS Instance-ID values on all BGP-LS Producers within a given IGP 623 domain. Unique BGP-LS Instance-ID values MUST be assigned to routing 624 protocol instances operating in different IGP domains. This allows 625 the BGP-LS Consumer to build an accurate segregated multi-domain 626 topology based on the Identifier field even when the topology is 627 advertised via BGP-LS by multiple BGP-LS Producers in the network. 629 When the above described semantics and recommendations are not 630 followed, a BGP-LS Consumer may see duplicate link-state objects for 631 the same node, link or prefix when there are multiple BGP-LS 632 Producers deployed. This may also result in the BGP-LS Consumers 633 getting an inaccurate network-wide topology. 635 When adding, removing or modifying a TLV/sub-TLV from a Link-State 636 NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it 637 in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in- 638 consistent link-state objects hanging around in the BGP-LS table. 640 Each Node Descriptor, Link Descriptor and Prefix Descriptor consists 641 of one or more TLVs, as described in the following sections. These 642 Descriptor TLVs are applicable for the Node, Link and Prefix NLRI 643 Types for the protocols listed in Table 2. Documents extending BGP- 644 LS specifications with new NLRI Types and/or protocols MUST specify 645 the NLRI Descriptors for them. 647 4.2.1. Node Descriptors 649 Each link is anchored by a pair of Router-IDs that are used by the 650 underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit 651 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 652 additional auxiliary Router-IDs, mainly for Traffic Engineering 653 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 654 Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be 655 included in the node attribute described in Section 4.3.1 and MAY be 656 included in link attribute described in Section 4.3.2. The 657 advertisement of the TE Router-IDs help a BGP-LS Consumer to 658 correlate multiple link-state objects (e.g. in different IGP 659 instances or areas/levels) to the same node in the network. 661 It is desirable that the Router-ID assignments inside the Node 662 Descriptor are globally unique. However, there may be Router-ID 663 spaces (e.g., ISO) where no global registry exists, or worse, Router- 664 IDs have been allocated following the private-IP allocation described 665 in RFC 1918 [RFC1918]. BGP-LS uses the Autonomous System (AS) Number 666 to disambiguate the Router-IDs, as described in Section 4.2.1.1. 668 4.2.1.1. Globally Unique Node/Link/Prefix Identifiers 670 One problem that needs to be addressed is the ability to identify an 671 IGP node globally (by "globally", we mean within the BGP-LS database 672 collected by all BGP-LS speakers that talk to each other). This can 673 be expressed through the following two requirements: 675 (A) The same node MUST NOT be represented by two keys (otherwise, 676 one node will look like two nodes). 678 (B) Two different nodes MUST NOT be represented by the same key 679 (otherwise, two nodes will look like one node). 681 We define an "IGP domain" to be the set of nodes (hence, by extension 682 links and prefixes) within which each node has a unique IGP 683 representation by using the combination of Area-ID, Router-ID, 684 Protocol-ID, Multi-Topology ID, and Instance-ID. The problem is that 685 BGP may receive node/link/prefix information from multiple 686 independent "IGP domains", and we need to distinguish between them. 687 Moreover, we can't assume there is always one and only one IGP domain 688 per AS. During IGP transitions, it may happen that two redundant 689 IGPs are in place. 691 The mapping of the Instance-ID to the Identifier field as described 692 earlier along with a set of sub-TLVs described in Section 4.2.1.4, 693 allows specification of a flexible key for any given node/link 694 information such that global uniqueness of the NLRI is ensured. 696 4.2.1.2. Local Node Descriptors 698 The Local Node Descriptors TLV contains Node Descriptors for the node 699 anchoring the local end of the link. This is a mandatory TLV in all 700 three types of NLRIs (node, link, and prefix). The Type is 256. The 701 length of this TLV is variable. The value contains one or more Node 702 Descriptor Sub-TLVs defined in Section 4.2.1.4. 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type | Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | | 710 // Node Descriptor Sub-TLVs (variable) // 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Figure 10: Local Node Descriptors TLV Format 716 4.2.1.3. Remote Node Descriptors 718 The Remote Node Descriptors TLV contains Node Descriptors for the 719 node anchoring the remote end of the link. This is a mandatory TLV 720 for Link NLRIs. The type is 257. The length of this TLV is 721 variable. The value contains one or more Node Descriptor Sub-TLVs 722 defined in Section 4.2.1.4. 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Length | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | | 730 // Node Descriptor Sub-TLVs (variable) // 731 | | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Figure 11: Remote Node Descriptors TLV Format 736 4.2.1.4. Node Descriptor Sub-TLVs 738 The Node Descriptor Sub-TLV type code points and lengths are listed 739 in the following table: 741 +--------------------+--------------------------------+----------+ 742 | Sub-TLV Code Point | Description | Length | 743 +--------------------+--------------------------------+----------+ 744 | 512 | Autonomous System | 4 | 745 | 513 | BGP-LS Identifier (deprecated) | 4 | 746 | 514 | OSPF Area-ID | 4 | 747 | 515 | IGP Router-ID | Variable | 748 +--------------------+--------------------------------+----------+ 750 Table 3: Node Descriptor Sub-TLVs 752 The sub-TLV values in Node Descriptor TLVs are defined as follows: 754 Autonomous System: Opaque value (32-bit AS Number). This is an 755 optional TLV. The value SHOULD be set to the AS Number associated 756 with the BGP process originating the link-state information. An 757 implementation MAY provide a configuration option on the BGP-LS 758 Producer to use a value different. 760 BGP-LS Identifier: Opaque value (32-bit ID). This is an optional 761 TLV. In conjunction with Autonomous System Number (ASN), uniquely 762 identifies the BGP-LS domain. The combination of ASN and BGP-LS 763 ID MUST be globally unique. All BGP-LS speakers within an IGP 764 flooding-set (set of IGP nodes within which an LSP/LSA is flooded) 765 MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists 766 of multiple flooding-sets, then all BGP-LS speakers within the IGP 767 domain SHOULD use the same ASN, BGP-LS ID tuple. 769 Area-ID: Used to identify the 32-bit area to which the information 770 advertised in the NLRI belongs. This is a mandatory TLV when 771 originating information from OSPF that is derived from area-scope 772 LSAs. The Area Identifier allows different NLRIs of the same 773 router to be discriminated on a per area basis. It is not used 774 for NLRIs when carrying information that is derived from AS-scope 775 LSAs as it is not associated with a specific area. 777 IGP Router-ID: Opaque value. This is a mandatory TLV when 778 originating information from IS-IS, OSPF, direct or static. For 779 an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO 780 system-ID). For an IS-IS pseudonode corresponding to a LAN, this 781 contains the 6-octet ISO Node-ID of the Designated Intermediate 782 System (DIS) followed by a 1-octet, nonzero PSN identifier (7 783 octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this 784 contains the 4-octet Router-ID. For an OSPFv2 pseudonode 785 representing a LAN, this contains the 4-octet Router-ID of the 786 Designated Router (DR) followed by the 4-octet IPv4 address of the 787 DR's interface to the LAN (8 octets in total). Similarly, for an 788 OSPFv3 pseudonode, this contains the 4-octet Router-ID of the DR 789 followed by the 4-octet interface identifier of the DR's interface 790 to the LAN (8 octets in total). The TLV size in combination with 791 the protocol identifier enables the decoder to determine the type 792 of the node. For Direct or Static configuration, the value SHOULD 793 be taken from an IPv4 or IPv6 address (e.g. loopback interface) 794 configured on the node. 796 There can be at most one instance of each sub-TLV type present in 797 any Node Descriptor. The sub-TLVs within a Node Descriptor MUST 798 be arranged in ascending order by sub-TLV type. This needs to be 799 done in order to compare NLRIs, even when an implementation 800 encounters an unknown sub-TLV. Using stable sorting, an 801 implementation can do binary comparison of NLRIs and hence allow 802 incremental deployment of new key sub-TLVs. 804 The BGP-LS Identifier was introduced by [RFC7752] and it's use is 805 being deprecated by this document. Implementations MUST continue to 806 support this sub-TLV for backward compatibility. The default value 807 of 0 is RECOMMENDED to be use when a BGP-LS Producer includes this 808 sub-TLV when originating information into BGP-LS. Implementations 809 MAY provide an option to configure this value for backward 810 compatibility reasons. The use of the Instance-ID in the Identifier 811 field is the RECOMMENDED way of segregation of different IGP domains 812 in BGP-LS. 814 4.2.2. Link Descriptors 816 The Link Descriptor field is a set of Type/Length/Value (TLV) 817 triplets. The format of each TLV is shown in Section 4.1. The Link 818 Descriptor TLVs uniquely identify a link among multiple parallel 819 links between a pair of anchor routers. A link described by the Link 820 Descriptor TLVs actually is a "half-link", a unidirectional 821 representation of a logical link. In order to fully describe a 822 single logical link, two originating routers advertise a half-link 823 each, i.e., two Link NLRIs are advertised for a given point-to-point 824 link. 826 A BGP-LS Consumer should not consider a link between two nodes as 827 being available unless it has received the two Link NLRIs 828 corresponding to the half-link representation of that link from both 829 the nodes. This check is similar to the 'two way connectivity check' 830 that is performed by link-state IGPs and is also required to be done 831 by BGP-LS Consumers of link-state topology. 833 A BGP-LS Producer MAY supress the advertisement of a Link NLRI, 834 corresponding to a half link, from a link-state IGP unless it has 835 verified that the link is being reported in the IS-IS LSP or OSPF 836 Router LSA by both the nodes connected by that link. This 'two way 837 connectivity check' is performed by link-state IGPs during their 838 computation and may be leveraged before passing information for any 839 half-link that is reported from these IGPs in to BGP-LS. This 840 ensures that only those Link State IGP adjacencies which are 841 established get reported via Link NLRIs. Such a 'two way 842 connectivity check' may be also required in certain cases (e.g. with 843 OSPF) to obtain the proper link identifiers of the remote node. 845 The format and semantics of the Value fields in most Link Descriptor 846 TLVs correspond to the format and semantics of Value fields in IS-IS 847 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], 848 and [RFC6119]. Although the encodings for Link Descriptor TLVs were 849 originally defined for IS-IS, the TLVs can carry data sourced by 850 either IS-IS or OSPF. 852 The following TLVs are defined as Link Descriptors in the Link NLRI: 854 +-----------+---------------------+--------------+------------------+ 855 | TLV Code | Description | IS-IS | Reference | 856 | Point | | TLV/Sub-TLV | (RFC/Section) | 857 +-----------+---------------------+--------------+------------------+ 858 | 258 | Link Local/Remote | 22/4 | [RFC5307] / 1.1 | 859 | | Identifiers | | | 860 | 259 | IPv4 interface | 22/6 | [RFC5305] / 3.2 | 861 | | address | | | 862 | 260 | IPv4 neighbor | 22/8 | [RFC5305] / 3.3 | 863 | | address | | | 864 | 261 | IPv6 interface | 22/12 | [RFC6119] / 4.2 | 865 | | address | | | 866 | 262 | IPv6 neighbor | 22/13 | [RFC6119] / 4.3 | 867 | | address | | | 868 | 263 | Multi-Topology | --- | Section 4.2.2.1 | 869 | | Identifier | | | 870 +-----------+---------------------+--------------+------------------+ 872 Table 4: Link Descriptor TLVs 874 The information about a link present in the LSA/LSP originated by the 875 local node of the link determines the set of TLVs in the Link 876 Descriptor of the link. 878 If interface and neighbor addresses, either IPv4 or IPv6, are 879 present, then the IP address TLVs MUST be included and the Link 880 Local/Remote Identifiers TLV MUST NOT be included in the Link 881 Descriptor. The Link Local/Remote Identifiers TLV MAY be included 882 in the link attribute when available. IPv6 link-local addresses 883 MUST NOT be carried in the IPv6 address TLVs as descriptors of a 884 link as they are not considered unique. 886 If interface and neighbor addresses are not present and the link 887 local/remote identifiers are present, then the Link Local/Remote 888 Identifiers TLV MUST be included in the Link Descriptor. The Link 889 Local/Remote Identifiers MUST be included in the Link Descriptor 890 also in the case of links having only IPv6 link-local addressing 891 on them. 893 The Multi-Topology Identifier TLV MUST be included in Link 894 Descriptor if the underlying IGP link object is associated with a 895 non-default topology. 897 The TLVs/sub-TLVs corresponding to the interface addresses and/or the 898 local/remote identfiers may not always be signaled in the IGPs unless 899 their advertisement is enabled specifically. In such cases, a BGP-LS 900 Producer may not be able to generate valid Link NLRIs for such link 901 advertisements from the IGPs. 903 4.2.2.1. Multi-Topology ID 905 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 906 Multi-Topology IDs for a link, node, or prefix. 908 Semantics of the IS-IS MT-ID are defined in Section 7.1 and 7.2 of 909 RFC 5120 [RFC5120]. Semantics of the OSPF MT-ID are defined in 910 Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV is 911 derived from OSPF, then the upper 5 bits of the MT-ID field MUST be 912 set to 0. 914 The format of the MT-ID TLV is shown in the following figure. 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type | Length=2*n | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |R R R R| Multi-Topology ID 1 | .... // 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 // .... |R R R R| Multi-Topology ID n | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Figure 12: Multi-Topology ID TLV Format 928 where Type is 263, Length is 2*n, and n is the number of MT-IDs 929 carried in the TLV. 931 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 932 Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or 933 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 934 the topology where the link or the prefix is reachable is allowed. 935 In case one wants to advertise multiple topologies for a given Link 936 Descriptor or Prefix Descriptor, multiple NLRIs MUST be generated 937 where each NLRI contains a single unique MT-ID. When used in the 938 Link or Prefix Descriptor TLV for IS-IS, the Bits R are reserved and 939 MUST be set to 0 (as per Section 7.2 of RFC 5120 [RFC5120]) when 940 originated and ignored on receipt. 942 In the BGP-LS attribute of a Node NLRI, one MT-ID TLV containing the 943 array of MT-IDs of all topologies where the node is reachable is 944 allowed. When used in the Node Attribute TLV for IS-IS, the Bits R 945 are set as per Section 7.1 of RFC 5120 [RFC5120]. 947 4.2.3. Prefix Descriptors 949 The Prefix Descriptor field is a set of Type/Length/Value (TLV) 950 triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 951 prefix originated by a node. The following TLVs are defined as 952 Prefix Descriptors in the IPv4/IPv6 Prefix NLRI: 954 +-------------+---------------------+----------+--------------------+ 955 | TLV Code | Description | Length | Reference | 956 | Point | | | (RFC/Section) | 957 +-------------+---------------------+----------+--------------------+ 958 | 263 | Multi-Topology | variable | Section 4.2.2.1 | 959 | | Identifier | | | 960 | 264 | OSPF Route Type | 1 | Section 4.2.3.1 | 961 | 265 | IP Reachability | variable | Section 4.2.3.2 | 962 | | Information | | | 963 +-------------+---------------------+----------+--------------------+ 965 Table 5: Prefix Descriptor TLVs 967 The Multi-Topology Identifier TLV MUST be included in Prefix 968 Descriptor if the underlying IGP prefix object is associated with a 969 non-default topology. 971 4.2.3.1. OSPF Route Type 973 The OSPF Route Type TLV is a mandatory TLV corresponding to Prefix 974 NLRIs originated from OSPF. It is used to identify the OSPF route 975 type of the prefix. An OSPF prefix MAY be advertised in the OSPF 976 domain with multiple route types. The Route Type TLV allows the 977 discrimination of these advertisements. The format of the OSPF Route 978 Type TLV is shown in the following figure. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Type | Length | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Route Type | 986 +-+-+-+-+-+-+-+-+ 988 Figure 13: OSPF Route Type TLV Format 990 where the Type and Length fields of the TLV are defined in Table 5. 991 The OSPF Route Type field values are defined in the OSPF protocol and 992 can be one of the following: 994 o Intra-Area (0x1) 995 o Inter-Area (0x2) 997 o External 1 (0x3) 999 o External 2 (0x4) 1001 o NSSA 1 (0x5) 1003 o NSSA 2 (0x6) 1005 4.2.3.2. IP Reachability Information 1007 The IP Reachability Information TLV is a mandatory TLV for IPv4 & 1008 IPv6 Prefix NLRI types. The TLV contains one IP address prefix (IPv4 1009 or IPv6) originally advertised in the IGP topology. Its purpose is 1010 to glue a particular BGP service NLRI by virtue of its BGP next hop 1011 to a given node in the LSDB. A router SHOULD advertise an IP Prefix 1012 NLRI for each of its BGP next hops. The format of the IP 1013 Reachability Information TLV is shown in the following figure: 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Type | Length | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Prefix Length | IP Prefix (variable) // 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 14: IP Reachability Information TLV Format 1025 The Type and Length fields of the TLV are defined in Table 5. The 1026 following two fields determine the reachability information of the 1027 address family. The Prefix Length field contains the length of the 1028 prefix in bits. The IP Prefix field contains the most significant 1029 octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 1030 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 1031 24, 4 octets for prefix length 25 up to 32, etc. 1033 4.3. The BGP-LS Attribute 1035 The BGP-LS Attribute is an optional, non-transitive BGP attribute 1036 that is used to carry link, node, and prefix parameters and 1037 attributes. It is defined as a set of Type/Length/Value (TLV) 1038 triplets, described in the following section. This attribute SHOULD 1039 only be included with Link-State NLRIs. This attribute MUST be 1040 ignored for all other address families. 1042 The Node Attribute TLVs, Link Attribute TLVs and Prefix Attribute 1043 TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute 1044 associated with a Node NLRI, Link NLRI and Prefix NLRI respectively. 1046 The BGP-LS Attribute may potentially grow large in size depending on 1047 the amount of link-state information associated with a single Link- 1048 State NLRI. The BGP specification [RFC4271] mandates a maximum BGP 1049 message size of 4096 octets. It is RECOMMENDED that an 1050 implementation support [RFC8654] in order to accommodate larger size 1051 of information within the BGP-LS Attribute. BGP-LS Producers MUST 1052 ensure that they limit the TLVs included in the BGP-LS Attribute to 1053 ensure that a BGP update message for a single Link-State NLRI does 1054 not cross the maximum limit for a BGP message. The determination of 1055 the types of TLVs to be included MAY be made by the BGP-LS Producer 1056 based on the BGP-LS Consumer applications requirement and is outside 1057 the scope of this document. When a BGP-LS Propagator finds that it 1058 is exceeding the maximum BGP message size due to addition or update 1059 of some other BGP Attribute (e.g. AS_PATH), it MUST consider the 1060 BGP-LS Attribute to be malformed and handle the propagation as 1061 described in Section 7.2.2. 1063 4.3.1. Node Attribute TLVs 1065 The following Node Attribute TLVs are defined for the BGP-LS 1066 Attribute associated with a Node NLRI: 1068 +-------------+----------------------+----------+-------------------+ 1069 | TLV Code | Description | Length | Reference | 1070 | Point | | | (RFC/Section) | 1071 +-------------+----------------------+----------+-------------------+ 1072 | 263 | Multi-Topology | variable | Section 4.2.2.1 | 1073 | | Identifier | | | 1074 | 1024 | Node Flag Bits | 1 | Section 4.3.1.1 | 1075 | 1025 | Opaque Node | variable | Section 4.3.1.5 | 1076 | | Attribute | | | 1077 | 1026 | Node Name | variable | Section 4.3.1.3 | 1078 | 1027 | IS-IS Area | variable | Section 4.3.1.2 | 1079 | | Identifier | | | 1080 | 1028 | IPv4 Router-ID of | 4 | [RFC5305] / 4.3 | 1081 | | Local Node | | | 1082 | 1029 | IPv6 Router-ID of | 16 | [RFC6119] / 4.1 | 1083 | | Local Node | | | 1084 +-------------+----------------------+----------+-------------------+ 1086 Table 6: Node Attribute TLVs 1088 4.3.1.1. Node Flag Bits TLV 1090 The Node Flag Bits TLV carries a bit mask describing node attributes. 1091 The value is a 1 octet length bit array of flags, where each bit 1092 represents a node operational state or attribute. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Type | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 |O|T|E|B|R|V| | 1100 +-+-+-+-+-+-+-+-+ 1102 Figure 15: Node Flag Bits TLV Format 1104 The bits are defined as follows: 1106 +-----+--------------+------------+ 1107 | Bit | Description | Reference | 1108 +-----+--------------+------------+ 1109 | 'O' | Overload Bit | [ISO10589] | 1110 | 'T' | Attached Bit | [ISO10589] | 1111 | 'E' | External Bit | [RFC2328] | 1112 | 'B' | ABR Bit | [RFC2328] | 1113 | 'R' | Router Bit | [RFC5340] | 1114 | 'V' | V6 Bit | [RFC5340] | 1115 +-----+--------------+------------+ 1117 Table 7: Node Flag Bits Definitions 1119 4.3.1.2. IS-IS Area Identifier TLV 1121 An IS-IS node can be part of one or more IS-IS areas. Each of these 1122 area addresses is carried in the IS-IS Area Identifier TLV. If 1123 multiple area addresses are present, multiple TLVs are used to encode 1124 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 1125 attribute only when advertised in the Link-State Node NLRI. 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Type | Length | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 // Area Identifier (variable) // 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Figure 16: IS-IS Area Identifier TLV Format 1137 4.3.1.3. Node Name TLV 1139 The Node Name TLV is optional. Its structure and encoding has been 1140 borrowed from [RFC5301]. The Value field identifies the symbolic 1141 name of the router node. This symbolic name can be the Fully 1142 Qualified Domain Name (FQDN) for the router, it can be a subset of 1143 the FQDN (e.g., a hostname), or it can be any string operators want 1144 to use for the router. The use of FQDN or a subset of it is strongly 1145 RECOMMENDED. The maximum length of the Node Name TLV is 255 octets. 1147 The Value field is encoded in 7-bit ASCII. If a user interface for 1148 configuring or displaying this field permits Unicode characters, that 1149 user interface is responsible for applying the ToASCII and/or 1150 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1151 format for transmission or display. 1153 [RFC5301] describes an IS-IS-specific extension and [RFC5642] 1154 describes an OSPF extension for advertisement of Node Name which MAY 1155 encoded in the Node Name TLV. 1157 0 1 2 3 1158 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Type | Length | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 // Node Name (variable) // 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 Figure 17: Node Name Format 1167 4.3.1.4. Local IPv4/IPv6 Router-ID TLVs 1169 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 1170 Router-IDs that the IGP might be using, e.g., for TE and migration 1171 purposes such as correlating a Node-ID between different protocols. 1172 If there is more than one auxiliary Router-ID of a given type, then 1173 each one is encoded in its own TLV. 1175 4.3.1.5. Opaque Node Attribute TLV 1177 The Opaque Node Attribute TLV is an envelope that transparently 1178 carries optional Node Attribute TLVs advertised by a router. An 1179 originating router shall use this TLV for encoding information 1180 specific to the protocol advertised in the NLRI header Protocol-ID 1181 field or new protocol extensions to the protocol as advertised in the 1182 NLRI header Protocol-ID field for which there is no protocol-neutral 1183 representation in the BGP Link-State NLRI. The primary use of the 1184 Opaque Node Attribute TLV is to bridge the document lag between, 1185 e.g., a new IGP link-state attribute being defined and the protocol- 1186 neutral BGP-LS extensions being published. 1188 In the case of OSPF, this TLV MAY be used to advertise information 1189 carried using the TLVs in the "OSPF Router Information (RI) TLVs" 1190 registry [RFC7770] under the IANA OSPF Parameters registry. 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Type | Length | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 // Opaque node attributes (variable) // 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 Figure 18: Opaque Node Attribute Format 1202 4.3.2. Link Attribute TLVs 1204 Link Attribute TLVs are TLVs that may be encoded in the BGP-LS 1205 attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ 1206 Value (TLV) triplet formatted as defined in Section 4.1. The format 1207 and semantics of the Value fields in some Link Attribute TLVs 1208 correspond to the format and semantics of the Value fields in IS-IS 1209 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 1210 [RFC5307]. Other Link Attribute TLVs are defined in this document. 1211 Although the encodings for Link Attribute TLVs were originally 1212 defined for IS-IS, the TLVs can carry data sourced by either IS-IS or 1213 OSPF. 1215 The following Link Attribute TLVs are defined for the BGP-LS 1216 Attribute associated with a Link NLRI: 1218 +-----------+---------------------+--------------+------------------+ 1219 | TLV Code | Description | IS-IS | Reference | 1220 | Point | | TLV/Sub-TLV | (RFC/Section) | 1221 +-----------+---------------------+--------------+------------------+ 1222 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 | 1223 | | Local Node | | | 1224 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 | 1225 | | Local Node | | | 1226 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 | 1227 | | Remote Node | | | 1228 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 | 1229 | | Remote Node | | | 1230 | 1088 | Administrative | 22/3 | [RFC5305] / 3.1 | 1231 | | group (color) | | | 1232 | 1089 | Maximum link | 22/9 | [RFC5305] / 3.4 | 1233 | | bandwidth | | | 1234 | 1090 | Max. reservable | 22/10 | [RFC5305] / 3.5 | 1235 | | link bandwidth | | | 1236 | 1091 | Unreserved | 22/11 | [RFC5305] / 3.6 | 1237 | | bandwidth | | | 1238 | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | 1239 | 1093 | Link Protection | 22/20 | [RFC5307] / 1.2 | 1240 | | Type | | | 1241 | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | 1242 | 1095 | IGP Metric | --- | Section 4.3.2.4 | 1243 | 1096 | Shared Risk Link | --- | Section 4.3.2.5 | 1244 | | Group | | | 1245 | 1097 | Opaque Link | --- | Section 4.3.2.6 | 1246 | | Attribute | | | 1247 | 1098 | Link Name | --- | Section 4.3.2.7 | 1248 +-----------+---------------------+--------------+------------------+ 1250 Table 8: Link Attribute TLVs 1252 4.3.2.1. IPv4/IPv6 Router-ID TLVs 1254 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1255 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1256 purposes. All auxiliary Router-IDs of both the local and the remote 1257 node MUST be included in the link attribute of each Link NLRI. If 1258 there is more than one auxiliary Router-ID of a given type, then 1259 multiple TLVs are used to encode them. 1261 4.3.2.2. MPLS Protocol Mask TLV 1263 The MPLS Protocol Mask TLV carries a bit mask describing which MPLS 1264 signaling protocols are enabled. The length of this TLV is 1. The 1265 value is a bit array of 8 flags, where each bit represents an MPLS 1266 Protocol capability. 1268 Generation of the MPLS Protocol Mask TLV is only valid for and SHOULD 1269 only be used with originators that have local link insight, for 1270 example, the Protocol-IDs 'Static configuration' or 'Direct' as per 1271 Table 2. The MPLS Protocol Mask TLV MUST NOT be included in NLRIs 1272 with the other Protocol-IDs listed in Table 2. 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Type | Length | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 |L|R| Reserved | 1280 +-+-+-+-+-+-+-+-+ 1282 Figure 19: MPLS Protocol Mask TLV 1284 The following bits are defined: 1286 +-----+---------------------------------------------+-----------+ 1287 | Bit | Description | Reference | 1288 +-----+---------------------------------------------+-----------+ 1289 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1290 | 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | 1291 +-----+---------------------------------------------+-----------+ 1293 Table 9: MPLS Protocol Mask TLV Codes 1295 4.3.2.3. TE Default Metric TLV 1297 The TE Default Metric TLV carries the Traffic Engineering metric for 1298 this link. The length of this TLV is fixed at 4 octets. If a source 1299 protocol uses a metric width of less than 32 bits, then the high- 1300 order bits of this field MUST be padded with zero. 1302 0 1 2 3 1303 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 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Type | Length | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | TE Default Link Metric | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Figure 20: TE Default Metric TLV Format 1312 4.3.2.4. IGP Metric TLV 1314 The IGP Metric TLV carries the metric for this link. The length of 1315 this TLV is variable, depending on the metric width of the underlying 1316 protocol. IS-IS small metrics have a length of 1 octet. Since the 1317 ISIS small metrics are of 6 bit size, the two most significant bits 1318 MUST be set to 0 and MUST be ignored by receiver. OSPF link metrics 1319 have a length of 2 octets. IS-IS wide metrics have a length of 3 1320 octets. 1322 0 1 2 3 1323 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 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Type | Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 // IGP Link Metric (variable length) // 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 Figure 21: IGP Metric TLV Format 1332 4.3.2.5. Shared Risk Link Group TLV 1334 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1335 Group information (see Section 2.3 ("Shared Risk Link Group 1336 Information") of [RFC4202]). It contains a data structure consisting 1337 of a (variable) list of SRLG values, where each element in the list 1338 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1339 (number of SRLG values). 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Type | Length | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Shared Risk Link Group Value | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 // ............ // 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Shared Risk Link Group Value | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 Figure 22: Shared Risk Link Group TLV Format 1355 The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS, the SRLG 1356 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1357 (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) 1358 defined in [RFC6119]. In Link-State NLRI, both IPv4 and IPv6 SRLG 1359 information are carried in a single TLV. 1361 4.3.2.6. Opaque Link Attribute TLV 1363 The Opaque Link Attribute TLV is an envelope that transparently 1364 carries optional Link Attribute TLVs advertised by a router. An 1365 originating router shall use this TLV for encoding information 1366 specific to the protocol advertised in the NLRI header Protocol-ID 1367 field or new protocol extensions to the protocol as advertised in the 1368 NLRI header Protocol-ID field for which there is no protocol-neutral 1369 representation in the BGP Link-State NLRI. The primary use of the 1370 Opaque Link Attribute TLV is to bridge the document lag between, 1371 e.g., a new IGP link-state attribute being defined and the 'protocol- 1372 neutral' BGP-LS extensions being published. 1374 In the case of OSPFv2, this TLV MAY be used to advertise information 1375 carried using the TLVs in the "OSPFv2 Extended Link Opaque LSA TLVs" 1376 registry [RFC7684] under the IANA OSPFv2 Parameters registry. In the 1377 case of OSPFv3, this TLV MAY be used to advertise information carried 1378 using the TLVs in the "OSPFv3 Extended-LSA Sub-TLVs" registry 1379 [RFC8362] under the IANA OSPFv3 Parameters registry. 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Type | Length | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 // Opaque link attributes (variable) // 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Figure 23: Opaque Link Attribute TLV Format 1391 4.3.2.7. Link Name TLV 1393 The Link Name TLV is optional. The Value field identifies the 1394 symbolic name of the router link. This symbolic name can be the FQDN 1395 for the link, it can be a subset of the FQDN, or it can be any string 1396 operators want to use for the link. The use of FQDN or a subset of 1397 it is strongly RECOMMENDED. The maximum length of the Link Name TLV 1398 is 255 octets. 1400 The Value field is encoded in 7-bit ASCII. If a user interface for 1401 configuring or displaying this field permits Unicode characters, that 1402 user interface is responsible for applying the ToASCII and/or 1403 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1404 format for transmission or display. 1406 How a router derives and injects link names is outside of the scope 1407 of this document. 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Type | Length | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 // Link Name (variable) // 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 Figure 24: Link Name TLV Format 1419 4.3.3. Prefix Attribute TLVs 1421 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1422 of IGP attributes (such as metric, route tags, etc.) that are 1423 advertised in the BGP-LS Attribute with Prefix NLRI types 3 and 4. 1425 The following Prefix Attribute TLVs are defined for the BGP-LS 1426 Attribute associated with a Prefix NLRI: 1428 +---------------+-----------------------+----------+----------------+ 1429 | TLV Code | Description | Length | Reference | 1430 | Point | | | | 1431 +---------------+-----------------------+----------+----------------+ 1432 | 1152 | IGP Flags | 1 | Section 4.3.3. | 1433 | | | | 1 | 1434 | 1153 | IGP Route Tag | 4*n | [RFC5130] | 1435 | 1154 | IGP Extended Route | 8*n | [RFC5130] | 1436 | | Tag | | | 1437 | 1155 | Prefix Metric | 4 | [RFC5305] | 1438 | 1156 | OSPF Forwarding | 4 | [RFC2328] | 1439 | | Address | | | 1440 | 1157 | Opaque Prefix | variable | Section 4.3.3. | 1441 | | Attribute | | 6 | 1442 +---------------+-----------------------+----------+----------------+ 1444 Table 10: Prefix Attribute TLVs 1446 4.3.3.1. IGP Flags TLV 1448 The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits 1449 originally assigned to the prefix. The IGP Flags TLV is encoded as 1450 follows: 1452 0 1 2 3 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Type | Length | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 |D|N|L|P| | 1458 +-+-+-+-+-+-+-+-+ 1460 Figure 25: IGP Flag TLV Format 1462 The Value field contains bits defined according to the table below: 1464 +-----+---------------------------+-----------+ 1465 | Bit | Description | Reference | 1466 +-----+---------------------------+-----------+ 1467 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1468 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1469 | 'L' | OSPF "local address" Bit | [RFC5340] | 1470 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1471 +-----+---------------------------+-----------+ 1473 Table 11: IGP Flag Bits Definitions 1475 4.3.3.2. IGP Route Tag TLV 1477 The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or 1478 OSPF) of the prefix and is encoded as follows: 1480 0 1 2 3 1481 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 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Type | Length | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 // Route Tags (one or more) // 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 Figure 26: IGP Route Tag TLV Format 1490 Length is a multiple of 4. 1492 The Value field contains one or more Route Tags as learned in the IGP 1493 topology. 1495 4.3.3.3. Extended IGP Route Tag TLV 1497 The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of 1498 the prefix [RFC5130] and is encoded as follows: 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Type | Length | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 // Extended Route Tag (one or more) // 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Figure 27: Extended IGP Route Tag TLV Format 1510 Length is a multiple of 8. 1512 The Extended Route Tag field contains one or more Extended Route Tags 1513 as learned in the IGP topology. 1515 4.3.3.4. Prefix Metric TLV 1517 The Prefix Metric TLV is an optional attribute and may only appear 1518 once. If present, it carries the metric of the prefix as known in 1519 the IGP topology as described in Section 4 of [RFC5305] (and 1520 therefore represents the reachability cost to the prefix). If not 1521 present, it means that the prefix is advertised without any 1522 reachability. 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Type | Length | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Metric | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 Figure 28: Prefix Metric TLV Format 1534 Length is 4. 1536 4.3.3.5. OSPF Forwarding Address TLV 1538 The OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF 1539 forwarding address as known in the original OSPF advertisement. 1540 Forwarding address can be either IPv4 or IPv6. 1542 0 1 2 3 1543 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 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | Type | Length | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 // Forwarding Address (variable) // 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 Figure 29: OSPF Forwarding Address TLV Format 1552 Length is 4 for an IPv4 forwarding address, and 16 for an IPv6 1553 forwarding address. 1555 4.3.3.6. Opaque Prefix Attribute TLV 1557 The Opaque Prefix Attribute TLV is an envelope that transparently 1558 carries optional Prefix Attribute TLVs advertised by a router. An 1559 originating router shall use this TLV for encoding information 1560 specific to the protocol advertised in the NLRI header Protocol-ID 1561 field or new protocol extensions to the protocol as advertised in the 1562 NLRI header Protocol-ID field for which there is no protocol-neutral 1563 representation in the BGP Link-State NLRI. The primary use of the 1564 Opaque Prefix Attribute TLV is to bridge the document lag between, 1565 e.g., a new IGP link-state attribute being defined and the protocol- 1566 neutral BGP-LS extensions being published. 1568 In the case of OSPFv2, this TLV MAY be used to advertise information 1569 carried using the TLVs in the "OSPFv2 Extended Prefix Opaque LSA 1570 TLVs" registry [RFC7684] under the IANA OSPFv2 Parameters registry. 1571 In the case of OSPFv3, this TLV MAY be used to advertise information 1572 carried using the TLVs in the "OSPFv3 Extended-LSA Sub-TLVs" registry 1573 [RFC8362] under the IANA OSPFv3 Parameters registry. 1575 The format of the TLV is as follows: 1577 0 1 2 3 1578 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 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Type | Length | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 // Opaque Prefix Attributes (variable) // 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 Figure 30: Opaque Prefix Attribute TLV Format 1587 Type is as specified in Table 10. Length is variable. 1589 4.4. Private Use 1591 TLVs for Vendor Private use are supported using the code point range 1592 reserved as indicated in Section 6. For such TLV use in the NLRI or 1593 BGP-LS Attribute, the format as described in Section 4.1 is to be 1594 used and a 4 octet field MUST be included as the first field in the 1595 value to carry the Enterprise Code. For a private use NLRI Type, a 4 1596 octet field MUST be included as the first field in the NLRI 1597 immediately following the Total NLRI Length field of the Link-State 1598 NLRI format as described in Section 4.2 to carry the Enterprise Code. 1599 The Enterprise Codes are listed at . This enables use vendor specific extensions 1601 without conflicts. 1603 Multiple instances of private-use TLVs MAY appear in the BGP-LS 1604 Attribute. 1606 4.5. BGP Next-Hop Information 1608 BGP link-state information for both IPv4 and IPv6 networks can be 1609 carried over either an IPv4 BGP session or an IPv6 BGP session. If 1610 an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1611 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1612 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 1613 address. Usually, the next hop will be set to the local endpoint 1614 address of the BGP session. The next-hop address MUST be encoded as 1615 described in [RFC4760]. The Length field of the next-hop address 1616 will specify the next-hop address family. If the next-hop length is 1617 4, then the next hop is an IPv4 address; if the next-hop length is 1618 16, then it is a global IPv6 address; and if the next-hop length is 1619 32, then there is one global IPv6 address followed by a link-local 1620 IPv6 address. The link-local IPv6 address should be used as 1621 described in [RFC2545]. For VPN Subsequent Address Family Identifier 1622 (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero 1623 is prepended to the next hop. 1625 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1626 the NLRI it receives. In case identical NLRIs are sourced by 1627 multiple BGP-LS Producers, the BGP Next Hop attribute is used to 1628 tiebreak as per the standard BGP path decision process. This 1629 specification doesn't mandate any rule regarding the rewrite of the 1630 BGP Next Hop attribute. 1632 4.6. Inter-AS Links 1634 The main source of TE information is the IGP, which is not active on 1635 inter-AS links. In some cases, the IGP may have information of 1636 inter-AS links [RFC5392] [RFC5316]. In other cases, an 1637 implementation SHOULD provide a means to inject inter-AS links into 1638 BGP-LS. The exact mechanism used to advertise the inter-AS links is 1639 outside the scope of this document. 1641 4.7. OSPF Virtual Links and Sham Links 1643 In an OSPF [RFC2328] [RFC5340] network, virtual links serve to 1644 connect physically separate components of the backbone to establish/ 1645 maintain continuity of the backbone area. While virtual links are 1646 modeled as point-to-point unnumbered links in the OSPF topology, 1647 their characteristics and purpose are different from other types of 1648 links in the OSPF topology. They are advertised using a distinct 1649 "virtual link" type in OSPF LSAs. The mechanism for advertisement of 1650 OSPF virtual links via BGP-LS is outside the scope of this document. 1652 In an OSPF network, sham links [RFC4577] [RFC6565] are used to 1653 provide an intra-area connectivity between VRFs on PE routers over 1654 the VPN provider's network. These links are advertised in OSPF as a 1655 point-to-point unnumbered links and represent connectivity over a 1656 service provider network using encapsulation mechanisms like MPLS. 1657 As such, the mechanism for advertisement of OSPF sham links follow 1658 the same procedures as other point-to-point unnumbered links as 1659 described previously in this document. 1661 4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 1663 OSPFv2 [RFC2328] defines the Type 4 Summary LSA and OSPFv3 [RFC5340] 1664 the Inter-area-router-LSA for an Area Border Router (ABR) to 1665 advertise reachability to an AS Border Router (ASBR) that is external 1666 to the area yet internal to the AS. The nature of information 1667 advertised by OSPF using this type of LSA does not map to either a 1668 node or a link or a prefix as discussed in this document. Therefore, 1669 the mechanism for advertisement of the information carried by these 1670 LSAs is outside the scope of this document. 1672 4.9. Handling of Unreachable IGP Nodes 1674 The origination and propagation of IGP link-state information via BGP 1675 needs to provide a consistent and true view of the topology of the 1676 IGP domain. BGP-LS provides an abstraction of the protocol specifics 1677 and BGP-LS Consumers may be varied types of applications. While the 1678 information propagated via BGP-LS from a link-state routing protocol 1679 is sourced from that protocol's LSDB, it does not serve as a true 1680 reflection of the originating router's LSDB since it does not include 1681 the LSA/LSP sequence number information. The sequence numbers are 1682 not included since a single NLRI update may be put together with 1683 information that is coming from multiple LSAs/LSPs. 1685 Consider an OSPF network as shown in Figure 31, where R2 and R3 are 1686 the BGP-LS Producers and also the OSPF Area Border Routers (ABRs). 1687 The link between R2 and R3 is in area 0 while the other links shown 1688 are in area 1. 1690 A BGP-LS Consumer talks to a BGP route-reflector (RR) R0 which is 1691 aggregating the BGP-LS feed from the BGP-LS Producers R2 and R3. 1692 Here R2 and R3 provide a redundant topology feed via BGP-LS to R0. 1693 Normally, R0 would receive two identical copies of all the Link-State 1694 NLRIs from both R2 and R3 and it would pick one of them (say R2) 1695 based on the standard BGP best path decision process. 1697 Consumer 1698 ^ 1699 | 1700 R0 1701 (BGP Route Reflector) 1702 / \ 1703 / \ 1704 a1 / a0 \ a1 1705 R1 ------ R2 -------- R3 ------ R4 1706 a1 | | a1 1707 | | 1708 R5 ---------------------------- R6 1709 a1 1711 Figure 31: Incorrect Reporting due to BGP Path Selection 1713 Consider a scenario where the link between R5 and R6 is lost (thereby 1714 partitioning the area 1) and its impact on the OSPF LSDB at R2 and 1715 R3. 1717 Now, R5 will remove the link 5-6 from its Router LSA and this updated 1718 LSA is available at R2. R2 also has a stale copy of R6's Router LSA 1719 which still has the link 6-5 in it. Based on this view in its LSDB, 1720 R2 will advertise only the half-link 6-5 that it derives from R6's 1721 stale Router LSA. 1723 At the same time, R6 has removed the link 6-5 from its Router LSA and 1724 this updated LSA is available at R3. Similarly, R3 also has a stale 1725 copy of R5's Router LSA having the link 5-6 in it. Based on it's 1726 LSDB, R3 will advertise only the half-link 5-6 that it has derived 1727 from R5's stale Router LSA. 1729 Now, the BGP-LS Consumer receives both the Link NLRIs corresponding 1730 to the half-links from R2 and R3 via R0. When viewed together, it 1731 would not detect or realize that the area 1 is actually partitioned. 1733 Also if R2 continues to report Link-State NLRIs corresponding to the 1734 stale copy of Router LSA of R4 and R6 nodes then R0 would prefer them 1735 over the valid Link-State NLRIs for R4 and R6 that it is receiving 1736 from R3 based on its BGP decision process. This would result in the 1737 BGP-LS Consumer getting stale and inaccurate topology information. 1738 This problems scenario is avoided if R2 were to not advertise the 1739 link-state information corresponding to R4 and R6 and if R3 were to 1740 not advertise similarly for R1 and R5. 1742 A BGP-LS Producer SHOULD withdraw all link-state objects advertised 1743 by it in BGP when the node that originated its corresponding LSP/LSAs 1744 is determined to have become unreachable in the IGP. An 1745 implementation MAY continue to advertise link-state objects 1746 corresponding to unreachable nodes in a deployment use-case where the 1747 BGP-LS Consumer is interested in receiving a topology feed 1748 corresponding to a complete IGP LSDB view. In such deployments, it 1749 is expected that the problem described above is mitigated by the BGP- 1750 LS Consumer via appropriate handling of such a topology feed in 1751 addition to the use of either a direct BGP peering with the producer 1752 nodes or mechanisms such as [RFC7911] when using RR. Details of 1753 these mechanisms are outside the scope of this draft. 1755 If the BGP-LS Producer does withdraw link-state objects associated 1756 with an IGP node based on failure of reachability check for that 1757 node, then it MUST re-advertise those link-state objects after that 1758 node becomes reachable again in the IGP domain. 1760 4.10. Router-ID Anchoring Example: ISO Pseudonode 1762 Encoding of a broadcast LAN in IS-IS provides a good example of how 1763 Router-IDs are encoded. Consider Figure 32. This represents a 1764 Broadcast LAN between a pair of routers. The "real" (non-pseudonode) 1765 routers have both an IPv4 Router-ID and IS-IS Node-ID. The 1766 pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the 1767 LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, 1768 Node2) are being generated. 1770 The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP 1771 Router-ID TLV of the local Node Descriptor is 6 octets long and 1772 contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV 1773 of the remote Node Descriptor is 7 octets long and contains the ISO- 1774 ID of Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this 1775 link contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1776 192.0.2.1, the IPv4 Router-ID of Node1. 1778 The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The IGP 1779 Router-ID TLV of the local Node Descriptor is 7 octets long and 1780 contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP 1781 Router-ID TLV of the remote Node Descriptor is 6 octets long and 1782 contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute 1783 of this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1784 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1786 +-----------------+ +-----------------+ +-----------------+ 1787 | Node1 | | Pseudonode1 | | Node2 | 1788 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1789 | 192.0.2.1 | | | | 192.0.2.2 | 1790 +-----------------+ +-----------------+ +-----------------+ 1792 Figure 32: IS-IS Pseudonodes 1794 4.11. Router-ID Anchoring Example: OSPF Pseudonode 1796 Encoding of a broadcast LAN in OSPF provides a good example of how 1797 Router-IDs and local Interface IPs are encoded. Consider Figure 33. 1798 This represents a Broadcast LAN between a pair of routers. The 1799 "real" (non-pseudonode) routers have both an IPv4 Router-ID and an 1800 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1801 Interface Address (for disambiguation), and an OSPF Area. Node1 is 1802 the DR for the LAN; hence, its local IP address 10.1.1.1 is used as 1803 both the Router-ID and Interface IP for the pseudonode keys. Two 1804 unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), 1805 are being generated. 1807 The Link NLRI of (Node1, Pseudonode1) is encoded as follows: 1809 o Local Node Descriptor 1811 TLV #515: IGP Router-ID: 11.11.11.11 1813 TLV #514: OSPF Area-ID: ID:0.0.0.0 1815 o Remote Node Descriptor 1817 TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1 1819 TLV #514: OSPF Area-ID: ID:0.0.0.0 1821 The Link NLRI of (Pseudonode1, Node2) is encoded as follows: 1823 o Local Node Descriptor 1825 TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1 1827 TLV #514: OSPF Area-ID: ID:0.0.0.0 1829 o Remote Node Descriptor 1831 TLV #515: IGP Router-ID: 33.33.33.34 1833 TLV #514: OSPF Area-ID: ID:0.0.0.0 1835 10.1.1.1/24 10.1.1.2/24 1836 +-------------+ +-------------+ +-------------+ 1837 | Node1 | | Pseudonode1 | | Node2 | 1838 | 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 | 1839 | | | 10.1.1.1 | | | 1840 | Area 0 | | Area 0 | | Area 0 | 1841 +-------------+ +-------------+ +-------------+ 1843 Figure 33: OSPF Pseudonodes 1845 The LAN subnet 10.1.1.0/24 is not included in the Router LSA of Node1 1846 or Node2. The Network LSA for this LAN advertised by the DR Node1 1847 contains the subnet mask for the LAN along with the DR address. A 1848 Prefix NLRI corresponding to the LAN subnet is advertised with the 1849 Pseudonode1 used as the Local node using the DR address and the 1850 subnet mask from the Network LSA. 1852 4.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1854 Graceful migration from one IGP to another requires coordinated 1855 operation of both protocols during the migration period. Such a 1856 coordination requires identifying a given physical link in both IGPs. 1857 The IPv4 Router-ID provides that "glue", which is present in the Node 1858 Descriptors of the OSPF Link NLRI and in the link attribute of the 1859 IS-IS Link NLRI. 1861 Consider a point-to-point link between two routers, A and B, that 1862 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1863 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1864 Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the 1865 link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link 1866 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1867 in the local and remote Node Descriptors, respectively. The IS-IS 1868 Link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1869 the local and remote Node Descriptors, respectively. In addition, 1870 the BGP-LS attribute of the IS-IS Link NLRI contains the TLV type 1871 1028 containing the IPv4 Router-ID of node A, TLV type 1030 1872 containing the IPv4 Router-ID of node B, and TLV type 1031 containing 1873 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1874 the link (A, B) can be identified in both the IS-IS and OSPF 1875 protocol. 1877 5. Link to Path Aggregation 1879 Distribution of all links available in the global Internet is 1880 certainly possible; however, it not desirable from a scaling and 1881 privacy point of view. Therefore, an implementation may support a 1882 link to path aggregation. Rather than advertising all specific links 1883 of a domain, an ASBR may advertise an "aggregate link" between a non- 1884 adjacent pair of nodes. The "aggregate link" represents the 1885 aggregated set of link properties between a pair of non-adjacent 1886 nodes. The actual methods to compute the path properties (of 1887 bandwidth, metric, etc.) are outside the scope of this document. The 1888 decision whether to advertise all specific links or aggregated links 1889 is an operator's policy choice. To highlight the varying levels of 1890 exposure, the following deployment examples are discussed. 1892 5.1. Example: No Link Aggregation 1894 Consider Figure 34. Both AS1 and AS2 operators want to protect their 1895 inter-AS {R1, R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants 1896 to compute its link-protection LSP to R3, it needs to "see" an 1897 alternate path to R3. Therefore, the AS2 operator exposes its 1898 topology. All BGP-TE-enabled routers in AS1 "see" the full topology 1899 of AS2 and therefore can compute a backup path. Note that the 1900 computing router decides if the direct link between {R3, R4} or the 1901 {R4, R5, R3} path is used. 1903 AS1 : AS2 1904 : 1905 R1-------R3 1906 | : | \ 1907 | : | R5 1908 | : | / 1909 R2-------R4 1910 : 1911 : 1913 Figure 34: No Link Aggregation 1915 5.2. Example: ASBR to ASBR Path Aggregation 1917 The brief difference between the "no-link aggregation" example and 1918 this example is that no specific link gets exposed. Consider 1919 Figure 35. The only link that gets advertised by AS2 is an 1920 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1921 there is a backup path. However, the actual links being used are 1922 hidden from the topology. 1924 AS1 : AS2 1925 : 1926 R1-------R3 1927 | : | 1928 | : | 1929 | : | 1930 R2-------R4 1931 : 1932 : 1934 Figure 35: ASBR Link Aggregation 1936 5.3. Example: Multi-AS Path Aggregation 1938 Service providers in control of multiple ASes may even decide to not 1939 expose their internal inter-AS links. Consider Figure 36. AS3 is 1940 modeled as a single node that connects to the border routers of the 1941 aggregated domain. 1943 AS1 : AS2 : AS3 1944 : : 1945 R1-------R3----- 1946 | : : \ 1947 | : : vR0 1948 | : : / 1949 R2-------R4----- 1950 : : 1951 : : 1953 Figure 36: Multi-AS Aggregation 1955 6. IANA Considerations 1957 IANA has assigned address family number 16388 (BGP-LS) in the 1958 "Address Family Numbers" registry with [RFC7752] as a reference. 1960 IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the 1961 "SAFI Values" sub-registry under the "Subsequent Address Family 1962 Identifiers (SAFI) Parameters" registry with [RFC7752] as a 1963 reference. 1965 IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path 1966 Attributes" sub-registry under the "Border Gateway Protocol (BGP) 1967 Parameters" registry with [RFC7752] as a reference. 1969 IANA has created a new "Border Gateway Protocol - Link State (BGP-LS) 1970 Parameters" registry at . 1973 6.1. BGP-LS Registries 1975 All of the registries listed in the following sub-sections are BGP-LS 1976 specific and are accessible under this registry. 1978 6.1.1. BGP-LS NLRI Types Registry 1980 The "BGP-LS NLRI Types" registry has been setup for assignment for 1981 the two octet sized code-points for BGP-LS NLRI types and populated 1982 with the values shown below: 1984 Type NLRI Type Reference 1985 ----------------------------------------------------------------- 1986 0 Reserved [RFC7752][This document] 1987 1 Node NLRI [RFC7752][This document] 1988 2 Link NLRI [RFC7752][This document] 1989 3 IPv4 Topology Prefix NLRI [RFC7752][This document] 1990 4 IPv6 Topology Prefix NLRI [RFC7752][This document] 1991 65000-65535 Private Use [This document] 1993 Allocations within the registry under the "Expert Review" policy 1994 require documentation of the proposed use of the allocated value and 1995 approval by the Designated Expert assigned by the IESG (see 1996 [RFC8126]). 1998 6.1.2. BGP-LS Protocol-IDs Registry 2000 The "BGP-LS Protocol-IDs" registry has been setup for assignment for 2001 the one octet sized code-points for BGP-LS Protocol-IDs and populated 2002 with the values shown below: 2004 Protocol-ID NLRI information source protocol Reference 2005 ----------------------------------------------------------------------- 2006 0 Reserved [RFC7752][This document] 2007 1 IS-IS Level 1 [RFC7752][This document] 2008 2 IS-IS Level 2 [RFC7752][This document] 2009 3 OSPFv2 [RFC7752][This document] 2010 4 Direct [RFC7752][This document] 2011 5 Static configuration [RFC7752][This document] 2012 6 OSPFv3 [RFC7752][This document] 2013 200-255 Private Use [This document] 2015 Allocations within the registry under the "Expert Review" policy 2016 require documentation of the proposed use of the allocated value and 2017 approval by the Designated Expert assigned by the IESG (see 2018 [RFC8126]). 2020 6.1.3. BGP-LS Well-Known Instance-IDs Registry 2022 The "BGP-LS Well-Known Instance-IDs" registry that was setup via 2023 [RFC7752] is no longer required. It may be retained as deprecated 2024 and no further assignments be made from it. 2026 6.1.4. BGP-LS Node Flags Registry 2028 The "BGP-LS Node Flags" registry is requested to be created for the 1 2029 octet sized flags field of the Node Flag Bits TLV (1024) and 2030 populated with the initial values shown below: 2032 Bit Description Reference 2033 ----------------------------------------------------------------------- 2034 0 Overload Bit (O-bit) [RFC7752][This document] 2035 1 Attached Bit (A-bit) [RFC7752][This document] 2036 2 External Bit (E-bit) [RFC7752][This document] 2037 3 ABR Bit (B-bit) [RFC7752][This document] 2038 4 Router Bit (R-bit) [RFC7752][This document] 2039 5 V6 Bit (V-bit) [RFC7752][This document] 2040 6-7 Unassigned 2042 Allocations within the registry under the "Specification Required" 2043 policy (see [RFC8126]). 2045 6.1.5. BGP-LS MPLS Protocol Mask Registry 2047 The "BGP-LS MPLS Protocol Mask" registry is requested to be created 2048 for the 1 octet sized flags field of the MPLS Protocol Mask TLV 2049 (1094) and populated with the initial values shown below: 2051 Bit Description Reference 2052 ----------------------------------------------------------------------- 2053 0 Label Distribution Protocol (L-bit) [RFC7752][This document] 2054 1 Extension to RSVP for LSP Tunnels (R-bit) [RFC7752][This document] 2055 2-7 Unassigned 2057 Allocations within the registry under the "Specification Required" 2058 policy (see [RFC8126]). 2060 6.1.6. BGP-LS IGP Prefix Flags Registry 2062 The "BGP-LS IGP Prefix Flags" registry is requested to be created for 2063 the 1 octet sized flags field of the IGP Flags TLV (1152) and 2064 populated with the initial values shown below: 2066 Bit Description Reference 2067 ----------------------------------------------------------------- 2068 0 IS-IS Up/Down Bit (D-bit) [RFC7752][This document] 2069 1 OSPF "no unicast" Bit (N-bit) [RFC7752][This document] 2070 2 OSPF "local address" Bit (L-bit) [RFC7752][This document] 2071 3 OSPF "propagate NSSA" Bit (P-bit) [RFC7752][This document] 2072 4-7 Unassigned 2074 Allocations within the registry under the "Specification Required" 2075 policy (see [RFC8126]). 2077 6.1.7. BGP-LS TLVs Registry 2079 The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 2080 Attribute TLVs" registry was setup via [RFC7752]. Values 0-255 are 2081 reserved. Values 256-65535 will be used for code points. The range 2082 65000-65535 is for Private Use. The registry has been populated with 2083 the values shown in Table 12. Allocations within the registry under 2084 the "Expert Review" policy require documentation of the proposed use 2085 of the allocated value and approval by the Designated Expert assigned 2086 by the IESG (see [RFC8126]). 2088 6.2. Guidance for Designated Experts 2090 In all cases of review by the Designated Expert (DE) described here, 2091 the DE is expected to ascertain the existence of suitable 2092 documentation (a specification) as described in [RFC8126]. The DE is 2093 also expected to check the clarity of purpose and use of the 2094 requested code points. Additionally, the DE must verify that any 2095 request for one of these code points has been made available for 2096 review and comment within the IETF: the DE will post the request to 2097 the IDR Working Group mailing list (or a successor mailing list 2098 designated by the IESG). If the request comes from within the IETF, 2099 it should be documented in an Internet-Draft. Lastly, the DE must 2100 ensure that any other request for a code point does not conflict with 2101 work that is active or already published within the IETF. 2103 7. Manageability Considerations 2105 This section is structured as recommended in [RFC5706]. 2107 7.1. Operational Considerations 2108 7.1.1. Operations 2110 Existing BGP operational procedures apply. No new operation 2111 procedures are defined in this document. It is noted that the NLRI 2112 information present in this document carries purely application-level 2113 data that has no immediate impact on the corresponding forwarding 2114 state computed by BGP. As such, any churn in reachability 2115 information has a different impact than regular BGP updates, which 2116 need to change the forwarding state for an entire router. It is 2117 expected that the distribution of this NLRI SHOULD be handled by 2118 dedicated route reflectors in most deployments providing a level of 2119 isolation and fault containment between different NLRI types. In the 2120 event of dedicated route reflectors not being available, other 2121 alternate mechanisms like separation of BGP instances or separate BGP 2122 sessions (e.g. using different addresses for peering) for Link-State 2123 information distribution SHOULD be used. 2125 7.1.2. Installation and Initial Setup 2127 Configuration parameters defined in Section 7.2.3 SHOULD be 2128 initialized to the following default values: 2130 o The Link-State NLRI capability is turned off for all neighbors. 2132 o The maximum rate at which Link-State NLRIs will be advertised/ 2133 withdrawn from neighbors is set to 200 updates per second. 2135 7.1.3. Migration Path 2137 The proposed extension is only activated between BGP peers after 2138 capability negotiation. Moreover, the extensions can be turned on/ 2139 off on an individual peer basis (see Section 7.2.3), so the extension 2140 can be gradually rolled out in the network. 2142 7.1.4. Requirements on Other Protocols and Functional Components 2144 The protocol extension defined in this document does not put new 2145 requirements on other protocols or functional components. 2147 7.1.5. Impact on Network Operation 2149 Frequency of Link-State NLRI updates could interfere with regular BGP 2150 prefix distribution. A network operator MAY use a dedicated Route- 2151 Reflector infrastructure to distribute Link-State NLRIs. 2153 Distribution of Link-State NLRIs SHOULD be limited to a single admin 2154 domain, which can consist of multiple areas within an AS or multiple 2155 ASes. 2157 7.1.6. Verifying Correct Operation 2159 Existing BGP procedures apply. In addition, an implementation SHOULD 2160 allow an operator to: 2162 o List neighbors with whom the speaker is exchanging Link-State 2163 NLRIs. 2165 7.2. Management Considerations 2167 7.2.1. Management Information 2169 The IDR working group has documented and continues to document parts 2170 of the Management Information Base and YANG models for managing and 2171 monitoring BGP speakers and the sessions between them. It is 2172 currently believed that the BGP session running BGP-LS is not 2173 substantially different from any other BGP session and can be managed 2174 using the same data models. 2176 7.2.2. Fault Management 2178 This section describes the fault management actions, as described in 2179 [RFC7606] , that are to be performed for handling of BGP update 2180 messages for BGP-LS. 2182 A Link-State NLRI MUST NOT be considered as malformed or invalid 2183 based on the inclusion/exclusion of TLVs or contents of the TLV 2184 fields (i.e. semantic errors), as described in Section 4.1 and 2185 Section 4.2. 2187 A BGP-LS Speaker MUST perform the following syntactic validation of 2188 the Link-State NLRI to determine if it is malformed. 2190 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 2191 correspond to the BGP MP_REACH_NLRI length? 2193 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 2194 attribute correspond to the BGP MP_UNREACH_NLRI length? 2196 o Does the sum of all TLVs found in a Link-State NLRI correspond to 2197 the Total NLRI Length field of all its Descriptors? 2199 o Is the length of the TLVs and, when the TLV is recognized then, 2200 its sub-TLVs in the NLRI valid? 2202 o Has the syntactic correctness of the NLRI fields been verified as 2203 per [RFC7606]? 2205 o Has the rule regarding ordering of TLVs been followed as described 2206 in Section 4.1? 2208 When the error determined allows for the router to skip the malformed 2209 NLRI(s) and continue processing of the rest of the update message 2210 (e.g. when the TLV ordering rule is violated), then it MUST handle 2211 such malformed NLRIs as 'Treat-as-withdraw'. In other cases, where 2212 the error in the NLRI encoding results in the inability to process 2213 the BGP update message (e.g. length related encoding errors), then 2214 the router SHOULD handle such malformed NLRIs as 'AFI/SAFI disable' 2215 when other AFI/SAFI besides BGP-LS are being advertised over the same 2216 session. Alternately, the router MUST perform 'session reset' when 2217 the session is only being used for BGP-LS or when it 'AFI/SAFI 2218 disable' action is not possible. 2220 A BGP-LS Attribute MUST NOT be considered as malformed or invalid 2221 based on the inclusion/exclusion of TLVs or contents of the TLV 2222 fields (i.e. semantic errors), as described in Section 4.1 and 2223 Section 4.3. 2225 A BGP-LS Speaker MUST perform the following syntactic validation of 2226 the BGP-LS Attribute to determine if it is malformed. 2228 o Does the sum of all TLVs found in the BGP-LS Attribute correspond 2229 to the BGP-LS Attribute length? 2231 o Has the syntactic correctness of the Attributes (including BGP-LS 2232 Attribute) been verified as per [RFC7606]? 2234 o Is the length of each TLV and, when the TLV is recognized then, 2235 its sub-TLVs in the BGP-LS Attribute valid? 2237 When the error determined allows for the router to skip the malformed 2238 BGP-LS Attribute and continue processing of the rest of the update 2239 message (e.g. when the BGP-LS Attribute length and the total Path 2240 Attribute Length are correct but some TLV/sub-TLV length within the 2241 BGP-LS Attribute is invalid), then it MUST handle such malformed BGP- 2242 LS Attribute as 'Attribute Discard'. In other cases, where the error 2243 in the BGP-LS Attribute encoding results in the inability to process 2244 the BGP update message then the handling is the same as described 2245 above for the malformed NLRI. 2247 Note that the 'Attribute Discard' action results in the loss of all 2248 TLVs in the BGP-LS Attribute and not the removal of a specific 2249 malformed TLV. The removal of specific malformed TLVs may give a 2250 wrong indication to a BGP-LS Consumer of that specific information 2251 being deleted or not available. 2253 When a BGP Speaker receives an update message with Link-State NLRI(s) 2254 in the MP_REACH_NLRI but without the BGP-LS Attribute, it is most 2255 likely an indication that a BGP Speaker preceding it has performed 2256 the 'Attribute Discard' fault handling. An implementation SHOULD 2257 preserve and propagate the Link-State NLRIs in such an update message 2258 so that the BGP-LS Consumers can detect the loss of link-state 2259 information for that object and not assume its deletion/withdraw. 2260 This also makes it possible for a network operator to trace back to 2261 the BGP-LS Propagator which actually detected a fault with the BGP-LS 2262 Attribute. 2264 An implementation SHOULD log an error for any errors found during 2265 syntax validation for further analysis. 2267 A BGP-LS Propagator SHOULD NOT perform semantic validation of the 2268 Link-State NLRI or the BGP-LS Attribute to determine if it is 2269 malformed or invalid. Some types of semantic validation that are not 2270 to be performed by a BGP-LS Propagator are as follows (and this is 2271 not to be considered as an exhaustive list): 2273 o is a mandatory TLV present or not? 2275 o is the length of a fixed length TLV correct or the length of a 2276 variable length TLV a valid/permissible? 2278 o are the values of TLV fields valid or permissible? 2280 o are the inclusion and use of TLVs/sub-TLVs with specific Link- 2281 State NLRI types valid? 2283 Each TLV MAY indicate the valid and permissible values and their 2284 semantics that can to be used only by a BGP-LS Consumer for its 2285 semantic validation. However, the handling of any errors may be 2286 specific to the particular application and outside the scope of this 2287 document. A BGP-LS Consumer should ignore unrecognized and 2288 unexpected TLV types in both the NLRI and BGP-LS Attribute portions 2289 and not consider their presence as an error. 2291 7.2.3. Configuration Management 2293 An implementation SHOULD allow the operator to specify neighbors to 2294 which Link-State NLRIs will be advertised and from which Link-State 2295 NLRIs will be accepted. 2297 An implementation SHOULD allow the operator to specify the maximum 2298 rate at which Link-State NLRIs will be advertised/withdrawn from 2299 neighbors. 2301 An implementation SHOULD allow the operator to specify the maximum 2302 number of Link-State NLRIs stored in a router's Routing Information 2303 Base (RIB). 2305 An implementation SHOULD allow the operator to create abstracted 2306 topologies that are advertised to neighbors and create different 2307 abstractions for different neighbors. 2309 An implementation SHOULD allow the operator to configure a 64-bit 2310 Instance-ID. 2312 An implementation SHOULD allow the operator to configure ASN and BGP- 2313 LS identifiers (refer Section 4.2.1.4). 2315 An implementation SHOULD allow the operator to configure the maximum 2316 size of the BGP-LS Attribute that may be used on a BGP-LS Producer. 2318 7.2.4. Accounting Management 2320 Not Applicable. 2322 7.2.5. Performance Management 2324 An implementation SHOULD provide the following statistics: 2326 o Total number of Link-State NLRI updates sent/received 2328 o Number of Link-State NLRI updates sent/received, per neighbor 2330 o Number of errored received Link-State NLRI updates, per neighbor 2332 o Total number of locally originated Link-State NLRIs 2334 These statistics should be recorded as absolute counts since system 2335 or session start time. An implementation MAY also enhance this 2336 information by recording peak per-second counts in each case. 2338 7.2.6. Security Management 2340 An operator SHOULD define an import policy to limit inbound updates 2341 as follows: 2343 o Drop all updates from peers that are only serving BGP-LS 2344 Consumers. 2346 An implementation MUST have the means to limit inbound updates. 2348 8. TLV/Sub-TLV Code Points Summary 2350 This section contains the global table of all TLVs/sub-TLVs defined 2351 in this document. 2353 +-----------+---------------------+--------------+------------------+ 2354 | TLV Code | Description | IS-IS TLV/ | Reference | 2355 | Point | | Sub-TLV | (RFC/Section) | 2356 +-----------+---------------------+--------------+------------------+ 2357 | 256 | Local Node | --- | Section 4.2.1.2 | 2358 | | Descriptors | | | 2359 | 257 | Remote Node | --- | Section 4.2.1.3 | 2360 | | Descriptors | | | 2361 | 258 | Link Local/Remote | 22/4 | [RFC5307] / 1.1 | 2362 | | Identifiers | | | 2363 | 259 | IPv4 interface | 22/6 | [RFC5305] / 3.2 | 2364 | | address | | | 2365 | 260 | IPv4 neighbor | 22/8 | [RFC5305] / 3.3 | 2366 | | address | | | 2367 | 261 | IPv6 interface | 22/12 | [RFC6119] / 4.2 | 2368 | | address | | | 2369 | 262 | IPv6 neighbor | 22/13 | [RFC6119] / 4.3 | 2370 | | address | | | 2371 | 263 | Multi-Topology ID | --- | Section 4.2.2.1 | 2372 | 264 | OSPF Route Type | --- | Section 4.2.3 | 2373 | 265 | IP Reachability | --- | Section 4.2.3 | 2374 | | Information | | | 2375 | 512 | Autonomous System | --- | Section 4.2.1.4 | 2376 | 513 | BGP-LS Identifier | --- | Section 4.2.1.4 | 2377 | | (deprecated) | | | 2378 | 514 | OSPF Area-ID | --- | Section 4.2.1.4 | 2379 | 515 | IGP Router-ID | --- | Section 4.2.1.4 | 2380 | 1024 | Node Flag Bits | --- | Section 4.3.1.1 | 2381 | 1025 | Opaque Node | --- | Section 4.3.1.5 | 2382 | | Attribute | | | 2383 | 1026 | Node Name | variable | Section 4.3.1.3 | 2384 | 1027 | IS-IS Area | variable | Section 4.3.1.2 | 2385 | | Identifier | | | 2386 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 | 2387 | | Local Node | | | 2388 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 | 2389 | | Local Node | | | 2390 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 | 2391 | | Remote Node | | | 2392 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 | 2393 | | Remote Node | | | 2394 | 1088 | Administrative | 22/3 | [RFC5305] / 3.1 | 2395 | | group (color) | | | 2396 | 1089 | Maximum link | 22/9 | [RFC5305] / 3.4 | 2397 | | bandwidth | | | 2398 | 1090 | Max. reservable | 22/10 | [RFC5305] / 3.5 | 2399 | | link bandwidth | | | 2400 | 1091 | Unreserved | 22/11 | [RFC5305] / 3.6 | 2401 | | bandwidth | | | 2402 | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | 2403 | 1093 | Link Protection | 22/20 | [RFC5307] / 1.2 | 2404 | | Type | | | 2405 | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | 2406 | 1095 | IGP Metric | --- | Section 4.3.2.4 | 2407 | 1096 | Shared Risk Link | --- | Section 4.3.2.5 | 2408 | | Group | | | 2409 | 1097 | Opaque Link | --- | Section 4.3.2.6 | 2410 | | Attribute | | | 2411 | 1098 | Link Name | --- | Section 4.3.2.7 | 2412 | 1152 | IGP Flags | --- | Section 4.3.3.1 | 2413 | 1153 | IGP Route Tag | --- | [RFC5130] | 2414 | 1154 | IGP Extended Route | --- | [RFC5130] | 2415 | | Tag | | | 2416 | 1155 | Prefix Metric | --- | [RFC5305] | 2417 | 1156 | OSPF Forwarding | --- | [RFC2328] | 2418 | | Address | | | 2419 | 1157 | Opaque Prefix | --- | Section 4.3.3.6 | 2420 | | Attribute | | | 2421 +-----------+---------------------+--------------+------------------+ 2423 Table 12: Summary Table of TLV/Sub-TLV Code Points 2425 9. Security Considerations 2427 Procedures and protocol extensions defined in this document do not 2428 affect the BGP security model. See the Security Considerations 2429 section of [RFC4271] for a discussion of BGP security. Also refer to 2430 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 2432 In the context of the BGP peerings associated with this document, a 2433 BGP speaker MUST NOT accept updates from a peer that is only 2434 providing information to a BGP-LS Consumer. That is, a participating 2435 BGP speaker should be aware of the nature of its relationships for 2436 link-state relationships and should protect itself from peers sending 2437 updates that either represent erroneous information feedback loops or 2438 are false input. Such protection can be achieved by manual 2439 configuration of consumer peers at the BGP speaker. 2441 An operator SHOULD employ a mechanism to protect a BGP speaker 2442 against DDoS attacks from BGP-LS Consumers. The principal attack a 2443 consumer may apply is to attempt to start multiple sessions either 2444 sequentially or simultaneously. Protection can be applied by 2445 imposing rate limits. 2447 Additionally, it may be considered that the export of link-state and 2448 TE information as described in this document constitutes a risk to 2449 confidentiality of mission-critical or commercially sensitive 2450 information about the network. BGP peerings are not automatic and 2451 require configuration; thus, it is the responsibility of the network 2452 operator to ensure that only trusted consumers are configured to 2453 receive such information. 2455 10. Contributors 2457 The following persons contributed significant text to RFC7752 and 2458 this document. They should be considered as co-authors. 2460 Hannes Gredler 2461 Rtbrick 2462 Email: hannes@rtbrick.com 2464 Jan Medved 2465 Cisco Systems Inc. 2466 USA 2467 Email: jmedved@cisco.com 2469 Stefano Previdi 2470 Huawei Technologies 2471 Italy 2472 Email: stefano@previdi.net 2474 Adrian Farrel 2475 Old Dog Consulting 2476 Email: adrian@olddog.co.uk 2478 Saikat Ray 2479 Individual 2480 USA 2481 Email: raysaikat@gmail.com 2483 11. Acknowledgements 2485 This document update to the BGP-LS specification [RFC7752] is a 2486 result of feedback and inputs from the discussions in the IDR working 2487 group. It also incorporates certain details and clarifications based 2488 on implementation and deployment experience with BGP-LS. 2490 Cengiz Alaettinoglu and Parag Amritkar brought forward the need to 2491 clarify the advertisement of LAN subnet for OSPF. 2493 We would like to thank Balaji Rajagopalan, Srihari Sangli, Shraddha 2494 Hegde, Andrew Stone, Jeff Tantsura, Acee Lindem, Jie Dong, Aijun Wang 2495 and Nandan Saha for their review and feedback on this document. 2497 We would like to thank Robert Varga for the significant contribution 2498 he gave to RFC7752. 2500 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 2501 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 2502 Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, 2503 Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas 2504 Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, 2505 Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and 2506 Ben Campbell for their comments on RFC7752. 2508 12. References 2510 12.1. Normative References 2512 [ISO10589] 2513 International Organization for Standardization, 2514 "Intermediate System to Intermediate System intra-domain 2515 routeing information exchange protocol for use in 2516 conjunction with the protocol for providing the 2517 connectionless-mode network service (ISO 8473)", ISO/ 2518 IEC 10589, November 2002. 2520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2521 Requirement Levels", BCP 14, RFC 2119, 2522 DOI 10.17487/RFC2119, March 1997, 2523 . 2525 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 2526 DOI 10.17487/RFC2328, April 1998, 2527 . 2529 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2530 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2531 DOI 10.17487/RFC2545, March 1999, 2532 . 2534 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2535 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2536 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2537 . 2539 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 2540 in Support of Generalized Multi-Protocol Label Switching 2541 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 2542 . 2544 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 2545 Support of Generalized Multi-Protocol Label Switching 2546 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 2547 . 2549 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2550 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2551 DOI 10.17487/RFC4271, January 2006, 2552 . 2554 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 2555 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 2556 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 2557 June 2006, . 2559 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2560 "Multiprotocol Extensions for BGP-4", RFC 4760, 2561 DOI 10.17487/RFC4760, January 2007, 2562 . 2564 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 2565 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 2566 RFC 4915, DOI 10.17487/RFC4915, June 2007, 2567 . 2569 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 2570 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 2571 October 2007, . 2573 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 2574 Topology (MT) Routing in Intermediate System to 2575 Intermediate Systems (IS-ISs)", RFC 5120, 2576 DOI 10.17487/RFC5120, February 2008, 2577 . 2579 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 2580 Control Mechanism in IS-IS Using Administrative Tags", 2581 RFC 5130, DOI 10.17487/RFC5130, February 2008, 2582 . 2584 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 2585 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 2586 October 2008, . 2588 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2589 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2590 2008, . 2592 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 2593 in Support of Generalized Multi-Protocol Label Switching 2594 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 2595 . 2597 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2598 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2599 . 2601 [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, 2602 "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, 2603 DOI 10.17487/RFC5642, August 2009, 2604 . 2606 [RFC5890] Klensin, J., "Internationalized Domain Names for 2607 Applications (IDNA): Definitions and Document Framework", 2608 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2609 . 2611 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 2612 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 2613 February 2011, . 2615 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 2616 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 2617 March 2012, . 2619 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 2620 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 2621 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 2622 June 2012, . 2624 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2625 Patel, "Revised Error Handling for BGP UPDATE Messages", 2626 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2627 . 2629 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 2630 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 2631 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2632 2015, . 2634 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 2635 S. Ray, "North-Bound Distribution of Link-State and 2636 Traffic Engineering (TE) Information Using BGP", RFC 7752, 2637 DOI 10.17487/RFC7752, March 2016, 2638 . 2640 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2641 Writing an IANA Considerations Section in RFCs", BCP 26, 2642 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2643 . 2645 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2646 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2647 May 2017, . 2649 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 2650 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2651 2017, . 2653 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 2654 F. Baker, "OSPFv3 Link State Advertisement (LSA) 2655 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2656 2018, . 2658 [RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message 2659 Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October 2660 2019, . 2662 12.2. Informative References 2664 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2665 and E. Lear, "Address Allocation for Private Internets", 2666 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2667 . 2669 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2670 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2671 . 2673 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2674 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2675 2006, . 2677 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2678 Element (PCE)-Based Architecture", RFC 4655, 2679 DOI 10.17487/RFC4655, August 2006, 2680 . 2682 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 2683 Per-Domain Path Computation Method for Establishing Inter- 2684 Domain Traffic Engineering (TE) Label Switched Paths 2685 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 2686 . 2688 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 2689 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2690 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 2691 December 2008, . 2693 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 2694 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2695 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 2696 January 2009, . 2698 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2699 Optimization (ALTO) Problem Statement", RFC 5693, 2700 DOI 10.17487/RFC5693, October 2009, 2701 . 2703 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 2704 Management of New Protocols and Protocol Extensions", 2705 RFC 5706, DOI 10.17487/RFC5706, November 2009, 2706 . 2708 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2709 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2710 and Authentication for Routing Protocols (KARP) Design 2711 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2712 . 2714 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 2715 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 2716 "Application-Layer Traffic Optimization (ALTO) Protocol", 2717 RFC 7285, DOI 10.17487/RFC7285, September 2014, 2718 . 2720 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 2721 S. Shaffer, "Extensions to OSPF for Advertising Optional 2722 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 2723 February 2016, . 2725 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 2726 "Advertisement of Multiple Paths in BGP", RFC 7911, 2727 DOI 10.17487/RFC7911, July 2016, 2728 . 2730 Appendix A. Changes from RFC 7752 2732 This section lists the high-level changes from RFC 7752 and provides 2733 reference to the document sections wherein those have been 2734 introduced. 2736 1. Update the Figure 1 in Section 1 and added Section 3 to 2737 illustrate the different roles of a BGP implementation in 2738 conveying link-state information. 2740 2. In Section 4.1, clarification about the TLV handling aspects 2741 that are applicable to both the NLRI and BGP-LS Attribute parts 2742 and those that are applicable only for the NLRI portion. An 2743 implementation may have missed the part about handling of 2744 unrecognized TLV and so, based on [RFC7606] guidelines, might 2745 discard the unknown NLRI types. This aspect is now 2746 unambiguously clarified in Section 4.2. Also, the TLVs in the 2747 BGP-LS Attribute that are not ordered are not to be considered 2748 as malformed. 2750 3. Clarification of mandatory and optional TLVs in both NLRI and 2751 BGP-LS Attribute portions all through the document. 2753 4. Handling of large size of BGP-LS Attribute with growth in BGP-LS 2754 information is explained in Section 4.3 along with mitigation of 2755 errors arising out of it. 2757 5. Clarified that the document describes the NLRI descriptor TLVs 2758 for the protocols and NLRI types specified in this document and 2759 future BGP-LS extensions must describe the same for other 2760 protocols and NLRI types that they introduce. 2762 6. Clarification on the use of Identifier field in the Link-State 2763 NLRI in Section 4.2 is provided. It was defined ambiguously to 2764 refer to only mutli-instance IGP on a single link while it can 2765 also be used for multiple IGP protocol instances on a router. 2766 The IANA registry is accordingly being removed. 2768 7. The BGP-LS Identifier TLV in the Node Descriptors has been 2769 deprecated. Its use was not well specified by [RFC7752] and 2770 there has been some amount of confusion between implementators 2771 on its usage for identification of IGP domains as against the 2772 use of the Identifier doing the same functionality as the 2773 Instance-ID when running multiple instances of IGP routing 2774 protocols. 2776 8. Clarification that the Area-ID TLV is mandatory in the Node 2777 Descriptor for origination of information from OSPF except for 2778 when sourcing information from AS-scope LSAs where this TLV is 2779 not applicable. 2781 9. Moved MT-ID TLV from the Node Descriptor section to under the 2782 Link Descriptor section since it is not a Node Descriptor sub- 2783 TLV. Fixed the ambiguity in the encoding of OSPF MT-ID in this 2784 TLV. Updated the IS-IS specification reference section and 2785 describe the differences in the applicability of the R flags 2786 when MT-ID TLV is used as link descriptor TLV and Prefix 2787 Attribute TLV. MT-ID TLV use is now elevated to SHOULD when it 2788 is enabled in the underlying IGP. 2790 10. Clarified that IPv6 Link-Local Addresses are not advertised in 2791 the Link Descriptor TLVs and the local/remote identifiers are to 2792 be used instead for links with IPv6 link-local addresses only. 2794 11. Update the usage of OSPF Route Type TLV to mandate its use for 2795 OSPF prefixes in Section 4.2.3.1 since this is required for 2796 segregation of intra-area prefixes that are used to reach a node 2797 (e.g. a loopback) from other types of inter-area and external 2798 prefixes. 2800 12. Clarification on the specific OSPFv2 and OSPFv3 protocol TLV 2801 space to be used in the node, link and prefix opaque attribute 2802 TLVs. 2804 13. Clarification on the length of the Node Flag Bits and IGP Flags 2805 TLVs to be one octet. 2807 14. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF 2808 specification. 2810 15. Clarification on the size of the IS-IS Narrow Metric 2811 advertisement via the IGP Metric TLV and the handling of the 2812 unused bits. 2814 16. Clarified the advertisement of the prefix corresponding to the 2815 LAN segment in an OSPF network in Section 4.11. 2817 17. Clarified the advertisement and support for OSPF specific 2818 concepts like Virtual links, Sham links and Type 4 LSAs in 2819 Section 4.7 and Section 4.8. 2821 18. Introduced Private Use TLV code point space and specified their 2822 encoding in Section 4.4. 2824 19. Introduced Section 4.9 where issues related to consistency of 2825 reporting IGP link-state along with their solutions are covered. 2827 20. Added recommendation for isolation of BGP-LS sessions from other 2828 BGP route exchange to avoid errors and faults in BGP-LS 2829 affecting the normal BGP routing. 2831 21. Updated the Fault Management section with detailed rules based 2832 on the role in the BGP-LS information propagation flow. 2834 22. Change to the management of BGP-LS IANA registries from 2835 "Specification Required" to "Expert Review" along with updated 2836 guidelines for Designated Experts. 2838 23. Added BGP-LS IANA registries with "Specification Required" 2839 policy for the flag fields of various TLVs that was missed out. 2841 Author's Address 2843 Ketan Talaulikar (editor) 2844 Cisco Systems 2845 India 2847 Email: ketant@cisco.com