idnits 2.17.1 draft-ketant-idr-rfc7752bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1726 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) == Outdated reference: A later version (-36) exists of draft-ietf-idr-bgp-extended-messages-33 -- 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 (~~), 3 warnings (==), 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 Intended status: Standards Track H. Gredler 5 Expires: January 9, 2020 Rtbrick 6 J. Medved 7 Cisco Systems, Inc. 8 S. Previdi 9 Individual Contributor 10 A. Farrel 11 Old Dog Consulting 12 S. Ray 13 Individual Contributor 14 July 8, 2019 16 Distribution of Link-State and Traffic Engineering Information Using BGP 17 draft-ketant-idr-rfc7752bis-01 19 Abstract 21 In a number of environments, a component external to a network is 22 called upon to perform computations based on the network topology and 23 current state of the connections within the network, including 24 Traffic Engineering (TE) information. This is information typically 25 distributed by IGP routing protocols within the network. 27 This document describes a mechanism by which link-state and TE 28 information can be collected from networks and shared with external 29 components using the BGP routing protocol. This is achieved using a 30 new BGP Network Layer Reachability Information (NLRI) encoding 31 format. The mechanism is applicable to physical and virtual IGP 32 links. The mechanism described is subject to policy control. 34 Applications of this technique include Application-Layer Traffic 35 Optimization (ALTO) servers and Path Computation Elements (PCEs). 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 41 "OPTIONAL" in this document are to be interpreted as described in BCP 42 14 [RFC2119] [RFC8174] when, and only when, they appear in all 43 capitals, as shown here. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on January 9, 2020. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 81 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 82 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 83 3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 8 84 4. Carrying Link-State Information in BGP . . . . . . . . . . . 9 85 4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10 87 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 15 88 4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 19 89 4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 21 90 4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 23 91 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 24 92 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27 93 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32 94 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 35 95 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36 96 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36 97 4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 36 98 4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38 99 4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39 100 4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40 101 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 40 102 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41 103 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 41 104 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 106 6.1. Guidance for Designated Experts . . . . . . . . . . . . . 43 107 7. Manageability Considerations . . . . . . . . . . . . . . . . 44 108 7.1. Operational Considerations . . . . . . . . . . . . . . . 44 109 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44 110 7.1.2. Installation and Initial Setup . . . . . . . . . . . 44 111 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 44 112 7.1.4. Requirements on Other Protocols and Functional 113 Components . . . . . . . . . . . . . . . . . . . . . 44 114 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45 115 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45 116 7.2. Management Considerations . . . . . . . . . . . . . . . . 45 117 7.2.1. Management Information . . . . . . . . . . . . . . . 45 118 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 45 119 7.2.3. Configuration Management . . . . . . . . . . . . . . 48 120 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 48 121 7.2.5. Performance Management . . . . . . . . . . . . . . . 48 122 7.2.6. Security Management . . . . . . . . . . . . . . . . . 49 123 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 125 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 126 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 128 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 129 12.2. Informative References . . . . . . . . . . . . . . . . . 54 130 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 56 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 133 1. Introduction 135 The contents of a Link-State Database (LSDB) or of an IGP's Traffic 136 Engineering Database (TED) describe only the links and nodes within 137 an IGP area. Some applications, such as end-to-end Traffic 138 Engineering (TE), would benefit from visibility outside one area or 139 Autonomous System (AS) in order to make better decisions. 141 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 142 a mechanism for achieving the computation of end-to-end TE paths that 143 cross the visibility of more than one TED or that require CPU- 144 intensive or coordinated computations. The IETF has also defined the 145 ALTO server [RFC5693] as an entity that generates an abstracted 146 network topology and provides it to network-aware applications. 148 Both a PCE and an ALTO server need to gather information about the 149 topologies and capabilities of the network in order to be able to 150 fulfill their function. 152 This document describes a mechanism by which link-state and TE 153 information can be collected from networks and shared with external 154 components using the BGP routing protocol [RFC4271]. This is 155 achieved using a new BGP Network Layer Reachability Information 156 (NLRI) encoding format. The mechanism is applicable to physical and 157 virtual links. The mechanism described is subject to policy control. 159 A router maintains one or more databases for storing link-state 160 information about nodes and links in any given area. Link attributes 161 stored in these databases include: local/remote IP addresses, local/ 162 remote interface identifiers, link metric and TE metric, link 163 bandwidth, reservable bandwidth, per Class-of-Service (CoS) class 164 reservation state, preemption, and Shared Risk Link Groups (SRLGs). 165 The router's BGP process can retrieve topology from these LSDBs and 166 distribute it to a consumer, either directly or via a peer BGP 167 speaker (typically a dedicated Route Reflector), using the encoding 168 specified in this document. 170 An illustration of the collection of link-state and TE information 171 and its distribution to consumers is shown in the Figure 1 below. 173 +-----------+ 174 | Consumer | 175 +-----------+ 176 ^ 177 | 178 +-----------+ +-----------+ 179 | BGP | | BGP | 180 | Speaker |<----------->| Speaker | +-----------+ 181 | RR1 | | RRm | | Consumer | 182 +-----------+ +-----------+ +-----------+ 183 ^ ^ ^ ^ 184 | | | | 185 +-----+ +---------+ +---------+ | 186 | | | | 187 +-----------+ +-----------+ +-----------+ 188 | BGP | | BGP | | BGP | 189 | Speaker | | Speaker | . . . | Speaker | 190 | R1 | | R2 | | Rn | 191 +-----------+ +-----------+ +-----------+ 192 ^ ^ ^ 193 | | | 194 IGP IGP IGP 196 Figure 1: Collection of Link-State and TE Information 198 A BGP speaker may apply configurable policy to the information that 199 it distributes. Thus, it may distribute the real physical topology 200 from the LSDB or the TED. Alternatively, it may create an abstracted 201 topology, where virtual, aggregated nodes are connected by virtual 202 paths. Aggregated nodes can be created, for example, out of multiple 203 routers in a Point of Presence (POP). Abstracted topology can also 204 be a mix of physical and virtual nodes and physical and virtual 205 links. Furthermore, the BGP speaker can apply policy to determine 206 when information is updated to the consumer so that there is a 207 reduction of information flow from the network to the consumers. 208 Mechanisms through which topologies can be aggregated or virtualized 209 are outside the scope of this document 211 2. Motivation and Applicability 213 This section describes use cases from which the requirements can be 214 derived. 216 2.1. MPLS-TE with PCE 218 As described in [RFC4655], a PCE can be used to compute MPLS-TE paths 219 within a "domain" (such as an IGP area) or across multiple domains 220 (such as a multi-area AS or multiple ASes). 222 o Within a single area, the PCE offers enhanced computational power 223 that may not be available on individual routers, sophisticated 224 policy control and algorithms, and coordination of computation 225 across the whole area. 227 o If a router wants to compute a MPLS-TE path across IGP areas, then 228 its own TED lacks visibility of the complete topology. That means 229 that the router cannot determine the end-to-end path and cannot 230 even select the right exit router (Area Border Router (ABR)) for 231 an optimal path. This is an issue for large-scale networks that 232 need to segment their core networks into distinct areas but still 233 want to take advantage of MPLS-TE. 235 Previous solutions used per-domain path computation [RFC5152]. The 236 source router could only compute the path for the first area because 237 the router only has full topological visibility for the first area 238 along the path, but not for subsequent areas. Per-domain path 239 computation uses a technique called "loose-hop-expansion" [RFC3209] 240 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 241 using the IGP-computed shortest path topology for the remainder of 242 the path. This may lead to sub-optimal paths, makes alternate/back- 243 up path computation hard, and might result in no TE path being found 244 when one really does exist. 246 The PCE presents a computation server that may have visibility into 247 more than one IGP area or AS, or may cooperate with other PCEs to 248 perform distributed path computation. The PCE obviously needs access 249 to the TED for the area(s) it serves, but [RFC4655] does not describe 250 how this is achieved. Many implementations make the PCE a passive 251 participant in the IGP so that it can learn the latest state of the 252 network, but this may be sub-optimal when the network is subject to a 253 high degree of churn or when the PCE is responsible for multiple 254 areas. 256 The following figure shows how a PCE can get its TED information 257 using the mechanism described in this document. 259 +----------+ +---------+ 260 | ----- | | BGP | 261 | | TED |<-+-------------------------->| Speaker | 262 | ----- | TED synchronization | | 263 | | | mechanism: +---------+ 264 | | | BGP with Link-State NLRI 265 | v | 266 | ----- | 267 | | PCE | | 268 | ----- | 269 +----------+ 270 ^ 271 | Request/ 272 | Response 273 v 274 Service +----------+ Signaling +----------+ 275 Request | Head-End | Protocol | Adjacent | 276 -------->| Node |<------------>| Node | 277 +----------+ +----------+ 279 Figure 2: External PCE Node Using a TED Synchronization Mechanism 281 The mechanism in this document allows the necessary TED information 282 to be collected from the IGP within the network, filtered according 283 to configurable policy, and distributed to the PCE as necessary. 285 2.2. ALTO Server Network API 287 An ALTO server [RFC5693] is an entity that generates an abstracted 288 network topology and provides it to network-aware applications over a 289 web-service-based API. Example applications are peer-to-peer (P2P) 290 clients or trackers, or Content Distribution Networks (CDNs). The 291 abstracted network topology comes in the form of two maps: a Network 292 Map that specifies allocation of prefixes to Partition Identifiers 293 (PIDs), and a Cost Map that specifies the cost between PIDs listed in 294 the Network Map. For more details, see [RFC7285]. 296 ALTO abstract network topologies can be auto-generated from the 297 physical topology of the underlying network. The generation would 298 typically be based on policies and rules set by the operator. Both 299 prefix and TE data are required: prefix data is required to generate 300 ALTO Network Maps, and TE (topology) data is required to generate 301 ALTO Cost Maps. Prefix data is carried and originated in BGP, and TE 302 data is originated and carried in an IGP. The mechanism defined in 303 this document provides a single interface through which an ALTO 304 server can retrieve all the necessary prefix and network topology 305 data from the underlying network. Note that an ALTO server can use 306 other mechanisms to get network data, for example, peering with 307 multiple IGP and BGP speakers. 309 The following figure shows how an ALTO server can get network 310 topology information from the underlying network using the mechanism 311 described in this document. 313 +--------+ 314 | Client |<--+ 315 +--------+ | 316 | ALTO +--------+ BGP with +---------+ 317 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 318 | Client |<--+------------| Server |<----------------| Speaker | 319 +--------+ | | | | | 320 | +--------+ +---------+ 321 +--------+ | 322 | Client |<--+ 323 +--------+ 325 Figure 3: ALTO Server Using Network Topology Information 327 3. BGP Speaker Roles for BGP-LS 329 In the illustration shown in Figure 1, the BGP Speakers can be seen 330 playing different roles in the distribution of information using BGP- 331 LS. This section introduces terms that explain the different roles 332 of the BGP Speakers which are then used through the rest of this 333 document. 335 o BGP-LS Producer: The BGP Speakers R1, R2, ... Rn, originate link- 336 state information from their underlying link-state IGP protocols 337 into BGP-LS. If R1 and R2 are in the same IGP area, then likely 338 they are originating the same link-state information into BGP-LS. 339 R1 may also source information from sources other than IGP, e.g. 340 its local node information. The term BGP-LS Producer refers to 341 the BGP Speaker that is originating link-state information into 342 BGP. 344 o BGP-LS Consumer: The BGP Speakers RR1 and Rn are handing off the 345 BGP-LS information that they have collected to a consumer 346 application. The BGP protocol implementation and the consumer 347 application may be on the same or different nodes. The term BGP- 348 LS Consumer refers to the consumer application/process and not the 349 BGP Speaker. This document only covers the BGP implementation. 350 The consumer application and the design of interface between BGP 351 and consumer application may be implementation specific and 352 outside the scope of this document. 354 o BGP-LS Propagator: The BGP Speaker RRm propagates the BGP-LS 355 information between the BGP Speaker Rn and the BGP Speaker RR1. 356 The BGP implementation on RRm is doing the propagation of BGP-LS 357 updates and performing BGP best path calculations. Similarly, the 358 BGP Speaker RR1 is receiving BGP-LS information from R1, R2 and 359 RRm and propagating the information to the BGP-LS Consumer after 360 performing BGP best path calculations. The term BGP-LS Propagator 361 refers to the BGP Speaker that is performing BGP protocol 362 processing on the link-state information. 364 The above roles are not mutually exclusive. The same BGP Speaker may 365 be the producer for some link-state information and propagator for 366 some other link-state information while also providing this 367 information to a consumer application. Nothing precludes a BGP 368 implementation performing some of the validation and processing on 369 behalf of the BGP-LS Consumer as long as it does not impact the 370 semantics of its role as BGP-LS Propagator as described in this 371 document. 373 The rest of this document refers to the role when describing 374 procedures that are specific to that role. When the role is not 375 specified, then the said procedure applies to all BGP Speakers. 377 4. Carrying Link-State Information in BGP 379 This specification contains two parts: definition of a new BGP NLRI 380 that describes links, nodes, and prefixes comprising IGP link-state 381 information and definition of a new BGP path attribute (BGP-LS 382 Attribute) that carries link, node, and prefix properties and 383 attributes, such as the link and prefix metric or auxiliary Router- 384 IDs of nodes, etc. 386 It is desirable to keep the dependencies on the protocol source of 387 this attribute to a minimum and represent any content in an IGP- 388 neutral way, such that applications that want to learn about a link- 389 state topology do not need to know about any OSPF or IS-IS protocol 390 specifics. 392 This section mainly describes the procedures at a BGP-LS Producer 393 that originate link-state information into BGP-LS. 395 4.1. TLV Format 397 Information in the new Link-State NLRIs and the BGP-LS Attribute is 398 encoded in Type/Length/Value triplets. The TLV format is shown in 399 Figure 4 and applies to both the NLRI and the BGP-LS Attribute 400 encodings. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 // Value (variable) // 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 4: TLV Format 412 The Length field defines the length of the value portion in octets 413 (thus, a TLV with no value portion would have a length of zero). The 414 TLV is not padded to 4-octet alignment. Unknown and unsupported 415 types MUST be preserved and propagated within both the NLRI and the 416 BGP-LS Attribute. The presence of unrecognized or unexpected TLVs 417 MUST NOT result in the NLRI or the BGP-LS Attribute being considered 418 as malformed. 420 In order to compare NLRIs with unknown TLVs, all TLVs within the NLRI 421 MUST be ordered in ascending order by TLV Type. If there are 422 multiple TLVs of the same type within a single NLRI, then the TLVs 423 sharing the same type MUST be in ascending order based on the value 424 field. Comparison of the value fields is performed by treating the 425 entire field as an opaque hexadecimal string. Standard string 426 comparison rules apply. NLRIs having TLVs which do not follow the 427 above ordering rules MUST be considered as malformed by a BGP-LS 428 Propagator. This ensures that multiple copies of the same NLRI from 429 multiple BGP-LS Producers and the ambiguity arising there from is 430 prevented. 432 All TLVs within the NLRI that are not specified as mandatory are 433 considered optional. All TLVs within the BGP-LS Attribute are 434 considered optional unless specified otherwise. 436 The TLVs within the BGP-LS Attribute need not be ordered in any 437 specific order. 439 4.2. The Link-State NLRI 441 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 442 for carrying opaque information. This specification defines three 443 Link-State NLRI types that describes either a node, a link, and a 444 prefix. 446 All non-VPN link, node, and prefix information SHALL be encoded using 447 AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be 448 encoded using AFI 16388 / SAFI 72. 450 In order for two BGP speakers to exchange Link-State NLRI, they MUST 451 use BGP Capabilities Advertisement to ensure that they are both 452 capable of properly processing such NLRI. This is done as specified 453 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 454 AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for 455 BGP-LS-VPN. 457 New Link-State NLRI Types may be introduced in the future. Since 458 supported NLRI type values within the address family are not 459 expressed in the Multiprotocol BGP (MP-BGP) capability [RFC4760], it 460 is possible that a BGP speaker has advertised support for Link-State 461 but does not support a particular Link-State NLRI type. In order to 462 allow introduction of new Link-State NLRI types seamlessly in the 463 future, without the need for upgrading all BGP speakers in the 464 propagation path (e.g. a route reflector), this document deviates 465 from the default handling behavior specified by [RFC7606] for Link- 466 State address-family. An implementation MUST handle unrecognized 467 Link-State NLRI types as opaque objects and MUST preserve and 468 propagate them. 470 The format of the Link-State NLRI is shown in the following figures. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | NLRI Type | Total NLRI Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | | 478 // Link-State NLRI (variable) // 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 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 + Route Distinguisher + 491 | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | 494 // Link-State NLRI (variable) // 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format 500 The Total NLRI Length field contains the cumulative length, in 501 octets, of the rest of the NLRI, not including the NLRI Type field or 502 itself. For VPN applications, it also includes the length of the 503 Route Distinguisher. 505 +-------------+---------------------------+ 506 | Type | NLRI Type | 507 +-------------+---------------------------+ 508 | 1 | Node NLRI | 509 | 2 | Link NLRI | 510 | 3 | IPv4 Topology Prefix NLRI | 511 | 4 | IPv6 Topology Prefix NLRI | 512 | 65000-65535 | Private Use | 513 +-------------+---------------------------+ 515 Table 1: NLRI Types 517 Route Distinguishers are defined and discussed in [RFC4364]. 519 The Node NLRI (NLRI Type = 1) is shown in the following figure. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+ 524 | Protocol-ID | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Identifier | 527 | (64 bits) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 // Local Node Descriptors (variable) // 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 7: The Node NLRI Format 534 The Link NLRI (NLRI Type = 2) is shown in the following figure. 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+ 539 | Protocol-ID | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Identifier | 542 | (64 bits) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 // Local Node Descriptors (variable) // 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 // Remote Node Descriptors (variable) // 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 // Link Descriptors (variable) // 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 8: The Link NLRI Format 553 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 554 same format, as shown in the following figure. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+ 559 | Protocol-ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Identifier | 562 | (64 bits) | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 // Local Node Descriptors (variable) // 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 // Prefix Descriptors (variable) // 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 9: The IPv4/IPv6 Topology Prefix NLRI Format 571 The Protocol-ID field can contain one of the following values: 573 +-------------+----------------------------------+ 574 | Protocol-ID | NLRI information source protocol | 575 +-------------+----------------------------------+ 576 | 1 | IS-IS Level 1 | 577 | 2 | IS-IS Level 2 | 578 | 3 | OSPFv2 | 579 | 4 | Direct | 580 | 5 | Static configuration | 581 | 6 | OSPFv3 | 582 | 200-255 | Private Use | 583 +-------------+----------------------------------+ 585 Table 2: Protocol Identifiers 587 The 'Direct' and 'Static configuration' protocol types SHOULD be used 588 when BGP-LS is sourcing local information. For all information 589 derived from other protocols, the corresponding Protocol-ID MUST be 590 used. If BGP-LS has direct access to interface information and wants 591 to advertise a local link, then the Protocol-ID 'Direct' SHOULD be 592 used. For modeling virtual links, such as described in Section 5, 593 the Protocol-ID 'Static configuration' SHOULD be used. 595 A router MAY run multiple protocol instances of OSPF or ISIS where by 596 it becomes a border router between multiple IGP domains. Both OSPF 597 and IS-IS MAY also run multiple routing protocol instances over the 598 same link. See [RFC8202] and [RFC6549]. These instances define 599 independent IGP routing domains. The 64-bit Identifier field carries 600 a BGP-LS Instance Identifier (Instance-ID) that is used to identify 601 the IGP routing domain where the NLRI belongs. The NLRIs 602 representing link-state objects (nodes, links, or prefixes) from the 603 same IGP routing instance MUST have the same Identifier field value. 605 NLRIs with different Identifier field values MUST be considered to be 606 from different IGP routing instances. The Identifier field value 0 607 is RECOMMENDED to be used when there is only a single protocol 608 instance in the network where BGP-LS is operational. 610 An implementation which supports multiple IGP instances MUST support 611 the configuration of unique BGP-LS Instance-IDs at the routing 612 protocol instance level. The network operator MUST assign consistent 613 BGP-LS Instance-ID values on all BGP-LS Producers within a given IGP 614 domain. Unique BGP-LS Instance-ID values MUST be assigned to routing 615 protocol instances operating in different IGP domains. This allows 616 the BGP-LS Consumer to build an accurate segregated multi-domain 617 topology based on the Identifier field even when the topology is 618 advertised via BGP-LS by multiple BGP-LS Producers in the network. 620 When the above described semantics and recommendations are not 621 followed, a BGP-LS Consumer may see duplicate link-state objects for 622 the same node, link or prefix when there are multiple BGP-LS 623 Producers deployed. This may also result in the BGP-LS Consumers 624 getting an inaccurate network-wide topology. 626 When adding, removing or modifying a TLV/sub-TLV from a Link-State 627 NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it 628 in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in- 629 consistent link-state objects hanging around in the BGP-LS table. 631 Each Node Descriptor and Link Descriptor consists of one or more 632 TLVs, as described in the following sections. 634 4.2.1. Node Descriptors 636 Each link is anchored by a pair of Router-IDs that are used by the 637 underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit 638 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 639 additional auxiliary Router-IDs, mainly for Traffic Engineering 640 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 641 Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be 642 included in the node attribute described in Section 4.3.1 and MAY be 643 included in link attribute described in Section 4.3.2. The 644 advertisement of the TE Router-IDs help a BGP-LS Consumer to 645 correlate multiple link-state objects (e.g. in different IGP 646 instances or areas/levels) to the same node in the network. 648 It is desirable that the Router-ID assignments inside the Node 649 Descriptor are globally unique. However, there may be Router-ID 650 spaces (e.g., ISO) where no global registry exists, or worse, Router- 651 IDs have been allocated following the private-IP allocation described 652 in RFC 1918 [RFC1918]. BGP-LS uses the Autonomous System (AS) Number 653 to disambiguate the Router-IDs, as described in Section 4.2.1.1. 655 4.2.1.1. Globally Unique Node/Link/Prefix Identifiers 657 One problem that needs to be addressed is the ability to identify an 658 IGP node globally (by "globally", we mean within the BGP-LS database 659 collected by all BGP-LS speakers that talk to each other). This can 660 be expressed through the following two requirements: 662 (A) The same node MUST NOT be represented by two keys (otherwise, 663 one node will look like two nodes). 665 (B) Two different nodes MUST NOT be represented by the same key 666 (otherwise, two nodes will look like one node). 668 We define an "IGP domain" to be the set of nodes (hence, by extension 669 links and prefixes) within which each node has a unique IGP 670 representation by using the combination of Area-ID, Router-ID, 671 Protocol-ID, Multi-Topology ID, and Instance-ID. The problem is that 672 BGP may receive node/link/prefix information from multiple 673 independent "IGP domains", and we need to distinguish between them. 674 Moreover, we can't assume there is always one and only one IGP domain 675 per AS. During IGP transitions, it may happen that two redundant 676 IGPs are in place. 678 The mapping of the Instance-ID to the Identifier field as described 679 earlier along with a set of sub-TLVs described in Section 4.2.1.4, 680 allows specification of a flexible key for any given node/link 681 information such that global uniqueness of the NLRI is ensured. 683 4.2.1.2. Local Node Descriptors 685 The Local Node Descriptors TLV contains Node Descriptors for the node 686 anchoring the local end of the link. This is a mandatory TLV in all 687 three types of NLRIs (node, link, and prefix). The Type is 256. The 688 length of this TLV is variable. The value contains one or more Node 689 Descriptor Sub-TLVs defined in Section 4.2.1.4. 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | | 697 // Node Descriptor Sub-TLVs (variable) // 698 | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Figure 10: Local Node Descriptors TLV Format 703 4.2.1.3. Remote Node Descriptors 705 The Remote Node Descriptors TLV contains Node Descriptors for the 706 node anchoring the remote end of the link. This is a mandatory TLV 707 for Link NLRIs. The type is 257. The length of this TLV is 708 variable. The value contains one or more Node Descriptor Sub-TLVs 709 defined in Section 4.2.1.4. 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Type | Length | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | | 717 // Node Descriptor Sub-TLVs (variable) // 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Figure 11: Remote Node Descriptors TLV Format 723 4.2.1.4. Node Descriptor Sub-TLVs 725 The Node Descriptor Sub-TLV type code points and lengths are listed 726 in the following table: 728 +--------------------+--------------------------------+----------+ 729 | Sub-TLV Code Point | Description | Length | 730 +--------------------+--------------------------------+----------+ 731 | 512 | Autonomous System | 4 | 732 | 513 | BGP-LS Identifier (deprecated) | 4 | 733 | 514 | OSPF Area-ID | 4 | 734 | 515 | IGP Router-ID | Variable | 735 +--------------------+--------------------------------+----------+ 737 Table 3: Node Descriptor Sub-TLVs 739 The sub-TLV values in Node Descriptor TLVs are defined as follows: 741 Autonomous System: Opaque value (32-bit AS Number). This is an 742 optional TLV. The value SHOULD be set to the AS Number associated 743 with the BGP process originating the link-state information. An 744 implementation MAY provide a configuration option on the BGP-LS 745 Producer to use a value different. 747 BGP-LS Identifier: Opaque value (32-bit ID). This is an optional 748 TLV. In conjunction with Autonomous System Number (ASN), uniquely 749 identifies the BGP-LS domain. The combination of ASN and BGP-LS 750 ID MUST be globally unique. All BGP-LS speakers within an IGP 751 flooding-set (set of IGP nodes within which an LSP/LSA is flooded) 752 MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists 753 of multiple flooding-sets, then all BGP-LS speakers within the IGP 754 domain SHOULD use the same ASN, BGP-LS ID tuple. 756 Area-ID: Used to identify the 32-bit area to which the NLRI belongs. 757 This is a mandatory TLV when originating information from OSPF. 758 The Area Identifier allows different NLRIs of the same router to 759 be discriminated. 761 IGP Router-ID: Opaque value. This is a mandatory TLV when 762 originating information from IS-IS, OSPF, direct or static. For 763 an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO 764 system-ID). For an IS-IS pseudonode corresponding to a LAN, this 765 contains the 6-octet ISO Node-ID of the Designated Intermediate 766 System (DIS) followed by a 1-octet, nonzero PSN identifier (7 767 octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this 768 contains the 4-octet Router-ID. For an OSPFv2 pseudonode 769 representing a LAN, this contains the 4-octet Router-ID of the 770 Designated Router (DR) followed by the 4-octet IPv4 address of the 771 DR's interface to the LAN (8 octets in total). Similarly, for an 772 OSPFv3 pseudonode, this contains the 4-octet Router-ID of the DR 773 followed by the 4-octet interface identifier of the DR's interface 774 to the LAN (8 octets in total). The TLV size in combination with 775 the protocol identifier enables the decoder to determine the type 776 of the node. For Direct or Static configuration, the value SHOULD 777 be taken from an IPv4 or IPv6 address (e.g. loopback interface) 778 configured on the node. 780 There can be at most one instance of each sub-TLV type present in 781 any Node Descriptor. The sub-TLVs within a Node Descriptor MUST 782 be arranged in ascending order by sub-TLV type. This needs to be 783 done in order to compare NLRIs, even when an implementation 784 encounters an unknown sub-TLV. Using stable sorting, an 785 implementation can do binary comparison of NLRIs and hence allow 786 incremental deployment of new key sub-TLVs. 788 The BGP-LS Identifier was introduced by [RFC7752] and it's use is 789 being deprecated by this document. Implementations MUST continue to 790 support this sub-TLV for backward compatibility. The default value 791 of 0 is RECOMMENDED to be use when a BGP-LS Producer includes this 792 sub-TLV when originating information into BGP-LS. Implementations 793 MAY provide an option to configure this value for backward 794 compatibility reasons. The use of the Instance-ID in the Identifier 795 field is the RECOMMENDED way of segregation of different IGP domains 796 in BGP-LS. 798 4.2.2. Link Descriptors 800 The Link Descriptor field is a set of Type/Length/Value (TLV) 801 triplets. The format of each TLV is shown in Section 4.1. The Link 802 Descriptor TLVs uniquely identify a link among multiple parallel 803 links between a pair of anchor routers. A link described by the Link 804 Descriptor TLVs actually is a "half-link", a unidirectional 805 representation of a logical link. In order to fully describe a 806 single logical link, two originating routers advertise a half-link 807 each, i.e., two Link NLRIs are advertised for a given point-to-point 808 link. 810 A BGP-LS Consumer should not consider a link between two nodes as 811 being available unless it has received the two Link NLRIs 812 corresponding to the half-link representation of that link from both 813 the nodes. This check is similar to the 'two way connectivity check' 814 that is performed by link-state IGPs and is also required to be done 815 by BGP-LS Consumers of link-state topology. 817 A BGP-LS Producer MAY supress the advertisement of a Link NLRI, 818 corresponding to a half link, from a link-state IGP unless it has 819 verified that the link is being reported in the IS-IS LSP or OSPF 820 Router LSA by both the nodes connected by that link. This 'two way 821 connectivity check' is performed by link-state IGPs during their 822 computation and may be leveraged before passing information for any 823 half-link that is reported from these IGPs in to BGP-LS. This 824 ensures that only those Link State IGP adjacencies which are 825 established get reported via Link NLRIs. Such a 'two way 826 connectivity check' may be also required in certain cases (e.g. with 827 OSPF) to obtain the proper link identifiers of the remote node. 829 The format and semantics of the Value fields in most Link Descriptor 830 TLVs correspond to the format and semantics of Value fields in IS-IS 831 Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], 832 and [RFC6119]. Although the encodings for Link Descriptor TLVs were 833 originally defined for IS-IS, the TLVs can carry data sourced by 834 either IS-IS or OSPF. 836 The following TLVs are defined as Link Descriptors in the Link NLRI: 838 +-----------+---------------------+--------------+------------------+ 839 | TLV Code | Description | IS-IS TLV | Reference | 840 | Point | | /Sub-TLV | (RFC/Section) | 841 +-----------+---------------------+--------------+------------------+ 842 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 843 | | Identifiers | | | 844 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 845 | | address | | | 846 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 847 | | address | | | 848 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 849 | | address | | | 850 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 851 | | address | | | 852 | 263 | Multi-Topology | --- | Section 4.2.2.1 | 853 | | Identifier | | | 854 +-----------+---------------------+--------------+------------------+ 856 Table 4: Link Descriptor TLVs 858 The information about a link present in the LSA/LSP originated by the 859 local node of the link determines the set of TLVs in the Link 860 Descriptor of the link. 862 If interface and neighbor addresses, either IPv4 or IPv6, are 863 present, then the IP address TLVs MUST be included and the Link 864 Local/Remote Identifiers TLV MUST NOT be included in the Link 865 Descriptor. The Link Local/Remote Identifiers TLV MAY be included 866 in the link attribute when available. 868 If interface and neighbor addresses are not present and the link 869 local/remote identifiers are present, then the Link Local/Remote 870 Identifiers TLV MUST be included in the Link Descriptor. 872 The Multi-Topology Identifier TLV MUST be included in Link 873 Descriptor if the underlying IGP link object is associated with a 874 non-default topology. 876 4.2.2.1. Multi-Topology ID 878 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 879 Multi-Topology IDs for a link, node, or prefix. 881 Semantics of the IS-IS MT-ID are defined in Section 7.2 of RFC 5120 882 [RFC5120]. Semantics of the OSPF MT-ID are defined in Section 3.7 of 883 RFC 4915 [RFC4915]. Bits R are reserved and SHOULD be set to 0 when 884 originated and ignored on receipt. If the value in the MT-ID TLV is 885 derived from OSPF, then the upper 5 bits of the MT-ID field MUST be 886 set to 0. 888 The format of the MT-ID TLV is shown in the following figure. 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Type | Length=2*n | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |R R R R| Multi-Topology ID 1 | .... // 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 // .... |R R R R| Multi-Topology ID n | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Figure 12: Multi-Topology ID TLV Format 902 where Type is 263, Length is 2*n, and n is the number of MT-IDs 903 carried in the TLV. 905 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 906 Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or 907 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 908 the topology where the link or the prefix is reachable is allowed. 909 In case one wants to advertise multiple topologies for a given Link 910 Descriptor or Prefix Descriptor, multiple NLRIs MUST be generated 911 where each NLRI contains a single unique MT-ID. In the BGP-LS 912 attribute of a Node NLRI, one MT-ID TLV containing the array of MT- 913 IDs of all topologies where the node is reachable is allowed. 915 4.2.3. Prefix Descriptors 917 The Prefix Descriptor field is a set of Type/Length/Value (TLV) 918 triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 919 prefix originated by a node. The following TLVs are defined as 920 Prefix Descriptors in the IPv4/IPv6 Prefix NLRI: 922 +-------------+---------------------+----------+--------------------+ 923 | TLV Code | Description | Length | Reference | 924 | Point | | | (RFC/Section) | 925 +-------------+---------------------+----------+--------------------+ 926 | 263 | Multi-Topology | variable | Section 4.2.2.1 | 927 | | Identifier | | | 928 | 264 | OSPF Route Type | 1 | Section 4.2.3.1 | 929 | 265 | IP Reachability | variable | Section 4.2.3.2 | 930 | | Information | | | 931 +-------------+---------------------+----------+--------------------+ 933 Table 5: Prefix Descriptor TLVs 935 The Multi-Topology Identifier TLV MUST be included in Prefix 936 Descriptor if the underlying IGP prefix object is associated with a 937 non-default topology. 939 4.2.3.1. OSPF Route Type 941 The OSPF Route Type TLV is a mandatory TLV corresponding to Prefix 942 NLRIs originated from OSPF. It is used to identify the OSPF route 943 type of the prefix. An OSPF prefix MAY be advertised in the OSPF 944 domain with multiple route types. The Route Type TLV allows the 945 discrimination of these advertisements. The format of the OSPF Route 946 Type TLV is shown in the following figure. 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Type | Length | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Route Type | 954 +-+-+-+-+-+-+-+-+ 956 Figure 13: OSPF Route Type TLV Format 958 where the Type and Length fields of the TLV are defined in Table 5. 959 The OSPF Route Type field values are defined in the OSPF protocol and 960 can be one of the following: 962 o Intra-Area (0x1) 964 o Inter-Area (0x2) 966 o External 1 (0x3) 968 o External 2 (0x4) 969 o NSSA 1 (0x5) 971 o NSSA 2 (0x6) 973 4.2.3.2. IP Reachability Information 975 The IP Reachability Information TLV is a mandatory TLV for IPv4 & 976 IPv6 Prefix NLRI types. The TLV contains one IP address prefix (IPv4 977 or IPv6) originally advertised in the IGP topology. Its purpose is 978 to glue a particular BGP service NLRI by virtue of its BGP next hop 979 to a given node in the LSDB. A router SHOULD advertise an IP Prefix 980 NLRI for each of its BGP next hops. The format of the IP 981 Reachability Information TLV is shown in the following figure: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Type | Length | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Prefix Length | IP Prefix (variable) // 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Figure 14: IP Reachability Information TLV Format 993 The Type and Length fields of the TLV are defined in Table 5. The 994 following two fields determine the reachability information of the 995 address family. The Prefix Length field contains the length of the 996 prefix in bits. The IP Prefix field contains the most significant 997 octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 998 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 999 24, 4 octets for prefix length 25 up to 32, etc. 1001 4.3. The BGP-LS Attribute 1003 The BGP-LS Attribute is an optional, non-transitive BGP attribute 1004 that is used to carry link, node, and prefix parameters and 1005 attributes. It is defined as a set of Type/Length/Value (TLV) 1006 triplets, described in the following section. This attribute SHOULD 1007 only be included with Link-State NLRIs. This attribute MUST be 1008 ignored for all other address families. 1010 The Node Attribute TLVs, Link Attribute TLVs and Prefix Attribute 1011 TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute 1012 associated with a Node NLRI, Link NLRI and Prefix NLRI respectively. 1014 The BGP-LS Attribute may potentially grow large in size depending on 1015 the amount of link-state information associated with a single Link- 1016 State NLRI. The BGP specification [RFC4271] mandates a maximum BGP 1017 message size of 4096 octets. It is RECOMMENDED that an 1018 implementation support [I-D.ietf-idr-bgp-extended-messages] in order 1019 to accommodate larger size of information within the BGP-LS 1020 Attribute. BGP-LS Producers MUST ensure that they limit the TLVs 1021 included in the BGP-LS Attribute to ensure that a BGP update message 1022 for a single Link-State NLRI does not cross the maximum limit for a 1023 BGP message. The determination of the types of TLVs to be included 1024 MAY be made by the BGP-LS Producer based on the BGP-LS Consumer 1025 applications requirement and is outside the scope of this document. 1026 When a BGP-LS Propagator finds that it is exceeding the maximum BGP 1027 message size due to addition or update of some other BGP Attribute 1028 (e.g. AS_PATH), it MUST consider the BGP-LS Attribute to be 1029 malformed and handle the propagation as described in Section 7.2.2. 1031 4.3.1. Node Attribute TLVs 1033 The following Node Attribute TLVs are defined for the BGP-LS 1034 Attribute associated with a Node NLRI: 1036 +-------------+----------------------+----------+-------------------+ 1037 | TLV Code | Description | Length | Reference | 1038 | Point | | | (RFC/Section) | 1039 +-------------+----------------------+----------+-------------------+ 1040 | 263 | Multi-Topology | variable | Section 4.2.2.1 | 1041 | | Identifier | | | 1042 | 1024 | Node Flag Bits | 1 | Section 4.3.1.1 | 1043 | 1025 | Opaque Node | variable | Section 4.3.1.5 | 1044 | | Attribute | | | 1045 | 1026 | Node Name | variable | Section 4.3.1.3 | 1046 | 1027 | IS-IS Area | variable | Section 4.3.1.2 | 1047 | | Identifier | | | 1048 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 1049 | | Local Node | | | 1050 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 1051 | | Local Node | | | 1052 +-------------+----------------------+----------+-------------------+ 1054 Table 6: Node Attribute TLVs 1056 4.3.1.1. Node Flag Bits TLV 1058 The Node Flag Bits TLV carries a bit mask describing node attributes. 1059 The value is a variable-length bit array of flags, where each bit 1060 represents a node capability. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type | Length | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 |O|T|E|B|R|V| Rsvd| 1068 +-+-+-+-+-+-+-+-+-+ 1070 Figure 15: Node Flag Bits TLV Format 1072 The bits are defined as follows: 1074 +-----------------+-------------------------+------------+ 1075 | Bit | Description | Reference | 1076 +-----------------+-------------------------+------------+ 1077 | 'O' | Overload Bit | [ISO10589] | 1078 | 'T' | Attached Bit | [ISO10589] | 1079 | 'E' | External Bit | [RFC2328] | 1080 | 'B' | ABR Bit | [RFC2328] | 1081 | 'R' | Router Bit | [RFC5340] | 1082 | 'V' | V6 Bit | [RFC5340] | 1083 | Reserved (Rsvd) | Reserved for future use | | 1084 +-----------------+-------------------------+------------+ 1086 Table 7: Node Flag Bits Definitions 1088 4.3.1.2. IS-IS Area Identifier TLV 1090 An IS-IS node can be part of one or more IS-IS areas. Each of these 1091 area addresses is carried in the IS-IS Area Identifier TLV. If 1092 multiple area addresses are present, multiple TLVs are used to encode 1093 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 1094 attribute only when advertised in the Link-State Node NLRI. 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type | Length | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 // Area Identifier (variable) // 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 16: IS-IS Area Identifier TLV Format 1106 4.3.1.3. Node Name TLV 1108 The Node Name TLV is optional. Its structure and encoding has been 1109 borrowed from [RFC5301]. The Value field identifies the symbolic 1110 name of the router node. This symbolic name can be the Fully 1111 Qualified Domain Name (FQDN) for the router, it can be a subset of 1112 the FQDN (e.g., a hostname), or it can be any string operators want 1113 to use for the router. The use of FQDN or a subset of it is strongly 1114 RECOMMENDED. The maximum length of the Node Name TLV is 255 octets. 1116 The Value field is encoded in 7-bit ASCII. If a user interface for 1117 configuring or displaying this field permits Unicode characters, that 1118 user interface is responsible for applying the ToASCII and/or 1119 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1120 format for transmission or display. 1122 [RFC5301] describes an IS-IS-specific extension and [RFC5642] 1123 describes an OSPF extension for advertisement of Node Name which MAY 1124 encoded in the Node Name TLV. 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Type | Length | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 // Node Name (variable) // 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 Figure 17: Node Name Format 1136 4.3.1.4. Local IPv4/IPv6 Router-ID TLVs 1138 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 1139 Router-IDs that the IGP might be using, e.g., for TE and migration 1140 purposes such as correlating a Node-ID between different protocols. 1141 If there is more than one auxiliary Router-ID of a given type, then 1142 each one is encoded in its own TLV. 1144 4.3.1.5. Opaque Node Attribute TLV 1146 The Opaque Node Attribute TLV is an envelope that transparently 1147 carries optional Node Attribute TLVs advertised by a router. An 1148 originating router shall use this TLV for encoding information 1149 specific to the protocol advertised in the NLRI header Protocol-ID 1150 field or new protocol extensions to the protocol as advertised in the 1151 NLRI header Protocol-ID field for which there is no protocol-neutral 1152 representation in the BGP Link-State NLRI. The primary use of the 1153 Opaque Node Attribute TLV is to bridge the document lag between, 1154 e.g., a new IGP link-state attribute being defined and the protocol- 1155 neutral BGP-LS extensions being published. A router, for example, 1156 could use this extension in order to advertise the native protocol's 1157 Node Attribute TLVs, such as the OSPF Router Informational 1158 Capabilities TLV defined in [RFC7770] or the IGP TE Node Capability 1159 Descriptor TLV described in [RFC5073]. 1161 0 1 2 3 1162 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 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Type | Length | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 // Opaque node attributes (variable) // 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Figure 18: Opaque Node Attribute Format 1171 4.3.2. Link Attribute TLVs 1173 Link Attribute TLVs are TLVs that may be encoded in the BGP-LS 1174 attribute with a Link NLRI. Each 'Link Attribute' is a Type/Length/ 1175 Value (TLV) triplet formatted as defined in Section 4.1. The format 1176 and semantics of the Value fields in some Link Attribute TLVs 1177 correspond to the format and semantics of the Value fields in IS-IS 1178 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 1179 [RFC5307]. Other Link Attribute TLVs are defined in this document. 1180 Although the encodings for Link Attribute TLVs were originally 1181 defined for IS-IS, the TLVs can carry data sourced by either IS-IS or 1182 OSPF. 1184 The following Link Attribute TLVs are defined for the BGP-LS 1185 Attribute associated with a Link NLRI: 1187 +-----------+---------------------+--------------+------------------+ 1188 | TLV Code | Description | IS-IS TLV | Reference | 1189 | Point | | /Sub-TLV | (RFC/Section) | 1190 +-----------+---------------------+--------------+------------------+ 1191 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1192 | | Local Node | | | 1193 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1194 | | Local Node | | | 1195 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1196 | | Remote Node | | | 1197 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1198 | | Remote Node | | | 1199 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1200 | | group (color) | | | 1201 | 1089 | Maximum link | 22/9 | [RFC5305]/3.4 | 1202 | | bandwidth | | | 1203 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1204 | | link bandwidth | | | 1205 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1206 | | bandwidth | | | 1207 | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | 1208 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1209 | | Type | | | 1210 | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | 1211 | 1095 | IGP Metric | --- | Section 4.3.2.4 | 1212 | 1096 | Shared Risk Link | --- | Section 4.3.2.5 | 1213 | | Group | | | 1214 | 1097 | Opaque Link | --- | Section 4.3.2.6 | 1215 | | Attribute | | | 1216 | 1098 | Link Name | --- | Section 4.3.2.7 | 1217 +-----------+---------------------+--------------+------------------+ 1219 Table 8: Link Attribute TLVs 1221 4.3.2.1. IPv4/IPv6 Router-ID TLVs 1223 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1224 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1225 purposes. All auxiliary Router-IDs of both the local and the remote 1226 node MUST be included in the link attribute of each Link NLRI. If 1227 there is more than one auxiliary Router-ID of a given type, then 1228 multiple TLVs are used to encode them. 1230 4.3.2.2. MPLS Protocol Mask TLV 1232 The MPLS Protocol Mask TLV carries a bit mask describing which MPLS 1233 signaling protocols are enabled. The length of this TLV is 1. The 1234 value is a bit array of 8 flags, where each bit represents an MPLS 1235 Protocol capability. 1237 Generation of the MPLS Protocol Mask TLV is only valid for and SHOULD 1238 only be used with originators that have local link insight, for 1239 example, the Protocol-IDs 'Static configuration' or 'Direct' as per 1240 Table 2. The MPLS Protocol Mask TLV MUST NOT be included in NLRIs 1241 with the other Protocol-IDs listed in Table 2. 1243 0 1 2 3 1244 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 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Type | Length | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 |L|R| Reserved | 1249 +-+-+-+-+-+-+-+-+ 1251 Figure 19: MPLS Protocol Mask TLV 1253 The following bits are defined: 1255 +------------+------------------------------------------+-----------+ 1256 | Bit | Description | Reference | 1257 +------------+------------------------------------------+-----------+ 1258 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1259 | 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] | 1260 | | (RSVP-TE) | | 1261 | 'Reserved' | Reserved for future use | | 1262 +------------+------------------------------------------+-----------+ 1264 Table 9: MPLS Protocol Mask TLV Codes 1266 4.3.2.3. TE Default Metric TLV 1268 The TE Default Metric TLV carries the Traffic Engineering metric for 1269 this link. The length of this TLV is fixed at 4 octets. If a source 1270 protocol uses a metric width of less than 32 bits, then the high- 1271 order bits of this field MUST be padded with zero. 1273 0 1 2 3 1274 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 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Type | Length | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | TE Default Link Metric | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 Figure 20: TE Default Metric TLV Format 1283 4.3.2.4. IGP Metric TLV 1285 The IGP Metric TLV carries the metric for this link. The length of 1286 this TLV is variable, depending on the metric width of the underlying 1287 protocol. IS-IS small metrics have a length of 1 octet (the two most 1288 significant bits are ignored). OSPF link metrics have a length of 2 1289 octets. IS-IS wide metrics have a length of 3 octets. 1291 0 1 2 3 1292 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 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Type | Length | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 // IGP Link Metric (variable length) // 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 Figure 21: IGP Metric TLV Format 1301 4.3.2.5. Shared Risk Link Group TLV 1303 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1304 Group information (see Section 2.3 ("Shared Risk Link Group 1305 Information") of [RFC4202]). It contains a data structure consisting 1306 of a (variable) list of SRLG values, where each element in the list 1307 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1308 (number of SRLG values). 1310 0 1 2 3 1311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Type | Length | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Shared Risk Link Group Value | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 // ............ // 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Shared Risk Link Group Value | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 Figure 22: Shared Risk Link Group TLV Format 1324 The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS, the SRLG 1325 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1326 (Type 138) defined in [RFC5307] and the IPv6 SRLG TLV (Type 139) 1327 defined in [RFC6119]. In Link-State NLRI, both IPv4 and IPv6 SRLG 1328 information are carried in a single TLV. 1330 4.3.2.6. Opaque Link Attribute TLV 1332 The Opaque Link Attribute TLV is an envelope that transparently 1333 carries optional Link Attribute TLVs advertised by a router. An 1334 originating router shall use this TLV for encoding information 1335 specific to the protocol advertised in the NLRI header Protocol-ID 1336 field or new protocol extensions to the protocol as advertised in the 1337 NLRI header Protocol-ID field for which there is no protocol-neutral 1338 representation in the BGP Link-State NLRI. The primary use of the 1339 Opaque Link Attribute TLV is to bridge the document lag between, 1340 e.g., a new IGP link-state attribute being defined and the 'protocol- 1341 neutral' BGP-LS extensions being published. 1343 0 1 2 3 1344 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 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Type | Length | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 // Opaque link attributes (variable) // 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 Figure 23: Opaque Link Attribute TLV Format 1353 4.3.2.7. Link Name TLV 1355 The Link Name TLV is optional. The Value field identifies the 1356 symbolic name of the router link. This symbolic name can be the FQDN 1357 for the link, it can be a subset of the FQDN, or it can be any string 1358 operators want to use for the link. The use of FQDN or a subset of 1359 it is strongly RECOMMENDED. The maximum length of the Link Name TLV 1360 is 255 octets. 1362 The Value field is encoded in 7-bit ASCII. If a user interface for 1363 configuring or displaying this field permits Unicode characters, that 1364 user interface is responsible for applying the ToASCII and/or 1365 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1366 format for transmission or display. 1368 How a router derives and injects link names is outside of the scope 1369 of this document. 1371 0 1 2 3 1372 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 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Type | Length | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 // Link Name (variable) // 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Figure 24: Link Name TLV Format 1381 4.3.3. Prefix Attribute TLVs 1383 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1384 of IGP attributes (such as metric, route tags, etc.) that are 1385 advertised in the BGP-LS Attribute with Prefix NLRI types 3 and 4. 1387 The following Prefix Attribute TLVs are defined for the BGP-LS 1388 Attribute associated with a Prefix NLRI: 1390 +---------------+-----------------------+----------+----------------+ 1391 | TLV Code | Description | Length | Reference | 1392 | Point | | | | 1393 +---------------+-----------------------+----------+----------------+ 1394 | 1152 | IGP Flags | 1 | Section | 1395 | | | | 4.3.3.1 | 1396 | 1153 | IGP Route Tag | 4*n | [RFC5130] | 1397 | 1154 | IGP Extended Route | 8*n | [RFC5130] | 1398 | | Tag | | | 1399 | 1155 | Prefix Metric | 4 | [RFC5305] | 1400 | 1156 | OSPF Forwarding | 4 | [RFC2328] | 1401 | | Address | | | 1402 | 1157 | Opaque Prefix | variable | Section | 1403 | | Attribute | | 4.3.3.6 | 1404 +---------------+-----------------------+----------+----------------+ 1406 Table 10: Prefix Attribute TLVs 1408 4.3.3.1. IGP Flags TLV 1410 The IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1411 assigned to the prefix. The IGP Flags TLV is encoded as follows: 1413 0 1 2 3 1414 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 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Type | Length | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 |D|N|L|P| Resvd.| 1419 +-+-+-+-+-+-+-+-+ 1421 Figure 25: IGP Flag TLV Format 1423 The Value field contains bits defined according to the table below: 1425 +----------+---------------------------+-----------+ 1426 | Bit | Description | Reference | 1427 +----------+---------------------------+-----------+ 1428 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1429 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1430 | 'L' | OSPF "local address" Bit | [RFC5340] | 1431 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1432 | Reserved | Reserved for future use. | | 1433 +----------+---------------------------+-----------+ 1435 Table 11: IGP Flag Bits Definitions 1437 4.3.3.2. IGP Route Tag TLV 1439 The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or 1440 OSPF) of the prefix and is encoded as follows: 1442 0 1 2 3 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Type | Length | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 // Route Tags (one or more) // 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 Figure 26: IGP Route Tag TLV Format 1452 Length is a multiple of 4. 1454 The Value field contains one or more Route Tags as learned in the IGP 1455 topology. 1457 4.3.3.3. Extended IGP Route Tag TLV 1459 The Extended IGP Route Tag TLV carries IS-IS Extended Route Tags of 1460 the prefix [RFC5130] and is encoded as follows: 1462 0 1 2 3 1463 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 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Type | Length | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 // Extended Route Tag (one or more) // 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 Figure 27: Extended IGP Route Tag TLV Format 1472 Length is a multiple of 8. 1474 The Extended Route Tag field contains one or more Extended Route Tags 1475 as learned in the IGP topology. 1477 4.3.3.4. Prefix Metric TLV 1479 The Prefix Metric TLV is an optional attribute and may only appear 1480 once. If present, it carries the metric of the prefix as known in 1481 the IGP topology as described in Section 4 of [RFC5305] (and 1482 therefore represents the reachability cost to the prefix). If not 1483 present, it means that the prefix is advertised without any 1484 reachability. 1486 0 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Type | Length | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Metric | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 Figure 28: Prefix Metric TLV Format 1496 Length is 4. 1498 4.3.3.5. OSPF Forwarding Address TLV 1500 The OSPF Forwarding Address TLV [RFC2328] [RFC5340] carries the OSPF 1501 forwarding address as known in the original OSPF advertisement. 1502 Forwarding address can be either IPv4 or IPv6. 1504 0 1 2 3 1505 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 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Type | Length | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 // Forwarding Address (variable) // 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 Figure 29: OSPF Forwarding Address TLV Format 1514 Length is 4 for an IPv4 forwarding address, and 16 for an IPv6 1515 forwarding address. 1517 4.3.3.6. Opaque Prefix Attribute TLV 1519 The Opaque Prefix Attribute TLV is an envelope that transparently 1520 carries optional Prefix Attribute TLVs advertised by a router. An 1521 originating router shall use this TLV for encoding information 1522 specific to the protocol advertised in the NLRI header Protocol-ID 1523 field or new protocol extensions to the protocol as advertised in the 1524 NLRI header Protocol-ID field for which there is no protocol-neutral 1525 representation in the BGP Link-State NLRI. The primary use of the 1526 Opaque Prefix Attribute TLV is to bridge the document lag between, 1527 e.g., a new IGP link-state attribute being defined and the protocol- 1528 neutral BGP-LS extensions being published. 1530 The format of the TLV is as follows: 1532 0 1 2 3 1533 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 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Type | Length | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 // Opaque Prefix Attributes (variable) // 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 Figure 30: Opaque Prefix Attribute TLV Format 1542 Type is as specified in Table 10. Length is variable. 1544 4.4. Private Use 1546 TLVs for Vendor Private use are supported using the code point range 1547 reserved as indicated in Section 6. For such TLV use in the NLRI or 1548 BGP-LS Attribute, the format as described in Section 4.1 is to be 1549 used and a 4 octet field MUST be included as the first field in the 1550 value to carry the Enterprise Code. For a private use NLRI Type, a 4 1551 octet field MUST be included as the first field in the NLRI 1552 immediately following the Total NLRI Length field of the Link-State 1553 NLRI format as described in Section 4.2 to carry the Enterprise Code. 1554 The Enterprise Codes are listed at . This enables use vendor specific extensions 1556 without conflicts. 1558 4.5. BGP Next-Hop Information 1560 BGP link-state information for both IPv4 and IPv6 networks can be 1561 carried over either an IPv4 BGP session or an IPv6 BGP session. If 1562 an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1563 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1564 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 1565 address. Usually, the next hop will be set to the local endpoint 1566 address of the BGP session. The next-hop address MUST be encoded as 1567 described in [RFC4760]. The Length field of the next-hop address 1568 will specify the next-hop address family. If the next-hop length is 1569 4, then the next hop is an IPv4 address; if the next-hop length is 1570 16, then it is a global IPv6 address; and if the next-hop length is 1571 32, then there is one global IPv6 address followed by a link-local 1572 IPv6 address. The link-local IPv6 address should be used as 1573 described in [RFC2545]. For VPN Subsequent Address Family Identifier 1574 (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero 1575 is prepended to the next hop. 1577 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1578 the NLRI it receives. In case identical NLRIs are sourced by 1579 multiple BGP-LS Producers, the BGP Next Hop attribute is used to 1580 tiebreak as per the standard BGP path decision process. This 1581 specification doesn't mandate any rule regarding the rewrite of the 1582 BGP Next Hop attribute. 1584 4.6. Inter-AS Links 1586 The main source of TE information is the IGP, which is not active on 1587 inter-AS links. In some cases, the IGP may have information of 1588 inter-AS links [RFC5392] [RFC5316]. In other cases, an 1589 implementation SHOULD provide a means to inject inter-AS links into 1590 BGP-LS. The exact mechanism used to provision the inter-AS links is 1591 outside the scope of this document 1593 4.7. Handling of Unreachable IGP Nodes 1595 The origination and propagation of IGP link-state information via BGP 1596 needs to provide a consistent and true view of the topology of the 1597 IGP domain. BGP-LS provides an abstraction of the protocol specifics 1598 and BGP-LS Consumers may be varied types of applications. 1600 Consider an OSPF network as shown in Figure 31, where R2 and R3 are 1601 the BGP-LS Producers and also the OSPF Area Border Routers (ABRs). 1602 The link between R2 and R3 is in area 0 while the other links shown 1603 are in area 1. 1605 A BGP-LS Consumer talks to a BGP route-reflector (RR) R0 which is 1606 aggregating the BGP-LS feed from the BGP-LS Producers R2 and R3. 1607 Here R2 and R3 provide a redundant topology feed via BGP-LS to R0. 1608 Normally, R0 would receive two identical copies of all the Link-State 1609 NLRIs from both R2 and R3 and it would pick one of them (say R2) 1610 based on the standard BGP best path decision process. 1612 Consumer 1613 ^ 1614 | 1615 R0 1616 (BGP Route Reflector) 1617 / \ 1618 / \ 1619 a1 / a0 \ a1 1620 R1 ------ R2 -------- R3 ------ R4 1621 a1 | | a1 1622 | | 1623 R5 ---------------------------- R6 1624 a1 1626 Figure 31: Incorrect Reporting due to BGP Path Selection 1628 Consider a scenario where the link between R5 and R6 is lost (thereby 1629 partitioning the area 1) and its impact on the OSPF LSDB at R2 and 1630 R3. 1632 Now, R5 will remove the link 5-6 from its Router LSA and this updated 1633 LSA is available at R2. R2 also has a stale copy of R6's Router LSA 1634 which still has the link 6-5 in it. Based on this view in its LSDB, 1635 R2 will advertise only the half-link 6-5 that it derives from R6's 1636 stale Router LSA. 1638 At the same time, R6 has removed the link 6-5 from its Router LSA and 1639 this updated LSA is available at R3. Similarly, R3 also has a stale 1640 copy of R5's Router LSA having the link 5-6 in it. Based on it's 1641 LSDB, R3 will advertise only the half-link 5-6 that it has derived 1642 from R5's stale Router LSA. 1644 Now, the BGP-LS Consumer receives both the Link NLRIs corresponding 1645 to the half-links from R2 and R3 via R0. When viewed together, it 1646 would not detect or realize that the area 1 is actually partitioned. 1648 Also if R2 continues to report Link-State NLRIs corresponding to the 1649 stale copy of Router LSA of R4 and R6 nodes then R0 would prefer them 1650 over the valid Link-State NLRIs for R4 and R6 that it is receiving 1651 from R3 based on its BGP decision process. This would result in the 1652 BGP-LS Consumer getting stale and inaccurate topology information. 1653 This problems scenario is avoided if R2 were to not advertise the 1654 link-state information corresponding to R4 and R6 and if R3 were to 1655 not advertise similarly for R1 and R5. 1657 A BGP-LS Producer MUST withdraw all link-state objects advertised by 1658 it in BGP when the node that originated its corresponding LSP/LSAs is 1659 determined to have become unreachable in the IGP and it MUST re- 1660 advertise those link-state objects only after that node becomes 1661 reachable again in the IGP domain. 1663 4.8. Router-ID Anchoring Example: ISO Pseudonode 1665 Encoding of a broadcast LAN in IS-IS provides a good example of how 1666 Router-IDs are encoded. Consider Figure 32. This represents a 1667 Broadcast LAN between a pair of routers. The "real" (non-pseudonode) 1668 routers have both an IPv4 Router-ID and IS-IS Node-ID. The 1669 pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the 1670 LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, 1671 Node2) are being generated. 1673 The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP 1674 Router-ID TLV of the local Node Descriptor is 6 octets long and 1675 contains the ISO-ID of Node1, 1920.0000.2001. The IGP Router-ID TLV 1676 of the remote Node Descriptor is 7 octets long and contains the ISO- 1677 ID of Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this 1678 link contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1679 192.0.2.1, the IPv4 Router-ID of Node1. 1681 The Link NLRI of (Pseudonode1, Node2) is encoded as follows. The IGP 1682 Router-ID TLV of the local Node Descriptor is 7 octets long and 1683 contains the ISO-ID of Pseudonode1, 1920.0000.2001.02. The IGP 1684 Router-ID TLV of the remote Node Descriptor is 6 octets long and 1685 contains the ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute 1686 of this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1687 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1689 +-----------------+ +-----------------+ +-----------------+ 1690 | Node1 | | Pseudonode1 | | Node2 | 1691 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1692 | 192.0.2.1 | | | | 192.0.2.2 | 1693 +-----------------+ +-----------------+ +-----------------+ 1695 Figure 32: IS-IS Pseudonodes 1697 4.9. Router-ID Anchoring Example: OSPF Pseudonode 1699 Encoding of a broadcast LAN in OSPF provides a good example of how 1700 Router-IDs and local Interface IPs are encoded. Consider Figure 33. 1701 This represents a Broadcast LAN between a pair of routers. The 1702 "real" (non-pseudonode) routers have both an IPv4 Router-ID and an 1703 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1704 Interface Address (for disambiguation), and an OSPF Area. Node1 is 1705 the DR for the LAN; hence, its local IP address 10.1.1.1 is used as 1706 both the Router-ID and Interface IP for the pseudonode keys. Two 1707 unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), 1708 are being generated. 1710 The Link NLRI of (Node1, Pseudonode1) is encoded as follows: 1712 o Local Node Descriptor 1714 TLV #515: IGP Router-ID: 11.11.11.11 1716 TLV #514: OSPF Area-ID: ID:0.0.0.0 1718 o Remote Node Descriptor 1720 TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1 1722 TLV #514: OSPF Area-ID: ID:0.0.0.0 1724 The Link NLRI of (Pseudonode1, Node2) is encoded as follows: 1726 o Local Node Descriptor 1728 TLV #515: IGP Router-ID: 11.11.11.11:10.1.1.1 1730 TLV #514: OSPF Area-ID: ID:0.0.0.0 1732 o Remote Node Descriptor 1734 TLV #515: IGP Router-ID: 33.33.33.34 1736 TLV #514: OSPF Area-ID: ID:0.0.0.0 1737 10.1.1.1/24 10.1.1.2/24 1738 +-------------+ +-------------+ +-------------+ 1739 | Node1 | | Pseudonode1 | | Node2 | 1740 | 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 | 1741 | | | 10.1.1.1 | | | 1742 | Area 0 | | Area 0 | | Area 0 | 1743 +-------------+ +-------------+ +-------------+ 1745 Figure 33: OSPF Pseudonodes 1747 The LAN subnet 10.1.1.0/24 is not included in the Router LSA of Node1 1748 or Node2. The Network LSA for this LAN advertised by the DR Node1 1749 contains the subnet mask for the LAN along with the DR address. A 1750 Prefix NLRI corresponding to the LAN subnet is advertised with the 1751 Pseudonode1 used as the Local node using the DR address and the 1752 subnet mask from the Network LSA. 1754 4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1756 Graceful migration from one IGP to another requires coordinated 1757 operation of both protocols during the migration period. Such a 1758 coordination requires identifying a given physical link in both IGPs. 1759 The IPv4 Router-ID provides that "glue", which is present in the Node 1760 Descriptors of the OSPF Link NLRI and in the link attribute of the 1761 IS-IS Link NLRI. 1763 Consider a point-to-point link between two routers, A and B, that 1764 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1765 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1766 Router-ID, and ISO-ID. Each protocol generates one Link NLRI for the 1767 link (A, B), both of which are carried by BGP-LS. The OSPFv2 Link 1768 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1769 in the local and remote Node Descriptors, respectively. The IS-IS 1770 Link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1771 the local and remote Node Descriptors, respectively. In addition, 1772 the BGP-LS attribute of the IS-IS Link NLRI contains the TLV type 1773 1028 containing the IPv4 Router-ID of node A, TLV type 1030 1774 containing the IPv4 Router-ID of node B, and TLV type 1031 containing 1775 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1776 the link (A, B) can be identified in both the IS-IS and OSPF 1777 protocol. 1779 5. Link to Path Aggregation 1781 Distribution of all links available in the global Internet is 1782 certainly possible; however, it not desirable from a scaling and 1783 privacy point of view. Therefore, an implementation may support a 1784 link to path aggregation. Rather than advertising all specific links 1785 of a domain, an ASBR may advertise an "aggregate link" between a non- 1786 adjacent pair of nodes. The "aggregate link" represents the 1787 aggregated set of link properties between a pair of non-adjacent 1788 nodes. The actual methods to compute the path properties (of 1789 bandwidth, metric, etc.) are outside the scope of this document. The 1790 decision whether to advertise all specific links or aggregated links 1791 is an operator's policy choice. To highlight the varying levels of 1792 exposure, the following deployment examples are discussed. 1794 5.1. Example: No Link Aggregation 1796 Consider Figure 34. Both AS1 and AS2 operators want to protect their 1797 inter-AS {R1, R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants 1798 to compute its link-protection LSP to R3, it needs to "see" an 1799 alternate path to R3. Therefore, the AS2 operator exposes its 1800 topology. All BGP-TE-enabled routers in AS1 "see" the full topology 1801 of AS2 and therefore can compute a backup path. Note that the 1802 computing router decides if the direct link between {R3, R4} or the 1803 {R4, R5, R3} path is used. 1805 AS1 : AS2 1806 : 1807 R1-------R3 1808 | : | \ 1809 | : | R5 1810 | : | / 1811 R2-------R4 1812 : 1813 : 1815 Figure 34: No Link Aggregation 1817 5.2. Example: ASBR to ASBR Path Aggregation 1819 The brief difference between the "no-link aggregation" example and 1820 this example is that no specific link gets exposed. Consider 1821 Figure 35. The only link that gets advertised by AS2 is an 1822 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1823 there is a backup path. However, the actual links being used are 1824 hidden from the topology. 1826 AS1 : AS2 1827 : 1828 R1-------R3 1829 | : | 1830 | : | 1831 | : | 1832 R2-------R4 1833 : 1834 : 1836 Figure 35: ASBR Link Aggregation 1838 5.3. Example: Multi-AS Path Aggregation 1840 Service providers in control of multiple ASes may even decide to not 1841 expose their internal inter-AS links. Consider Figure 36. AS3 is 1842 modeled as a single node that connects to the border routers of the 1843 aggregated domain. 1845 AS1 : AS2 : AS3 1846 : : 1847 R1-------R3----- 1848 | : : \ 1849 | : : vR0 1850 | : : / 1851 R2-------R4----- 1852 : : 1853 : : 1855 Figure 36: Multi-AS Aggregation 1857 6. IANA Considerations 1859 IANA has assigned address family number 16388 (BGP-LS) in the 1860 "Address Family Numbers" registry with [RFC7752] as a reference. 1862 IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the 1863 "SAFI Values" sub-registry under the "Subsequent Address Family 1864 Identifiers (SAFI) Parameters" registry. 1866 IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path 1867 Attributes" sub-registry under the "Border Gateway Protocol (BGP) 1868 Parameters" registry. 1870 IANA has created a new "Border Gateway Protocol - Link State (BGP-LS) 1871 Parameters" registry at . All of the following registries are BGP-LS specific and 1873 are accessible under this registry: 1875 o "BGP-LS NLRI-Types" registry 1877 Value 0 is reserved. The maximum value is 65535. The range 1878 65000-65535 is for Private Use. The registry has been populated 1879 with the values shown in Table 1. Allocations within the registry 1880 require documentation of the proposed use of the allocated value 1881 (Specification Required) and approval by the Designated Expert 1882 assigned by the IESG (see [RFC8126]). 1884 o "BGP-LS Protocol-IDs" registry 1886 Value 0 is reserved. The maximum value is 255. The range 200-255 1887 is for Private Use. The registry has been populated with the 1888 values shown in Table 2. Allocations within the registry require 1889 documentation of the proposed use of the allocated value 1890 (Specification Required) and approval by the Designated Expert 1891 assigned by the IESG (see [RFC8126]). 1893 o "BGP-LS Well-Known Instance-IDs" registry 1895 This registry was setup via [RFC7752] and is no longer required. 1896 It may be retained as deprecated. 1898 o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 1899 Attribute TLVs" registry 1901 Values 0-255 are reserved. Values 256-65535 will be used for code 1902 points. The range 65000-65535 is for Private Use. The registry 1903 has been populated with the values shown in Table 12. Allocations 1904 within the registry require documentation of the proposed use of 1905 the allocated value (Specification Required) and approval by the 1906 Designated Expert assigned by the IESG (see [RFC8126]). 1908 6.1. Guidance for Designated Experts 1910 In all cases of review by the Designated Expert (DE) described here, 1911 the DE is expected to ascertain the existence of suitable 1912 documentation (a specification) as described in [RFC8126] and to 1913 verify that the document is permanently and publicly available. The 1914 DE is also expected to check the clarity of purpose and use of the 1915 requested code points. Last, the DE must verify that any 1916 specification produced in the IETF that requests one of these code 1917 points has been made available for review by the IDR working group 1918 and that any specification produced outside the IETF does not 1919 conflict with work that is active or already published within the 1920 IETF. 1922 7. Manageability Considerations 1924 This section is structured as recommended in [RFC5706]. 1926 7.1. Operational Considerations 1928 7.1.1. Operations 1930 Existing BGP operational procedures apply. No new operation 1931 procedures are defined in this document. It is noted that the NLRI 1932 information present in this document carries purely application-level 1933 data that has no immediate impact on the corresponding forwarding 1934 state computed by BGP. As such, any churn in reachability 1935 information has a different impact than regular BGP updates, which 1936 need to change the forwarding state for an entire router. It is 1937 expected that the distribution of this NLRI SHOULD be handled by 1938 dedicated route reflectors in most deployments providing a level of 1939 isolation and fault containment between different NLRI types. In the 1940 event of dedicated route reflectors not being available, other 1941 alternate mechanisms like separation of BGP instances or separate BGP 1942 sessions (e.g. using different addresses for peering) for Link-State 1943 information distribution SHOULD be used. 1945 7.1.2. Installation and Initial Setup 1947 Configuration parameters defined in Section 7.2.3 SHOULD be 1948 initialized to the following default values: 1950 o The Link-State NLRI capability is turned off for all neighbors. 1952 o The maximum rate at which Link-State NLRIs will be advertised/ 1953 withdrawn from neighbors is set to 200 updates per second. 1955 7.1.3. Migration Path 1957 The proposed extension is only activated between BGP peers after 1958 capability negotiation. Moreover, the extensions can be turned on/ 1959 off on an individual peer basis (see Section 7.2.3), so the extension 1960 can be gradually rolled out in the network. 1962 7.1.4. Requirements on Other Protocols and Functional Components 1964 The protocol extension defined in this document does not put new 1965 requirements on other protocols or functional components. 1967 7.1.5. Impact on Network Operation 1969 Frequency of Link-State NLRI updates could interfere with regular BGP 1970 prefix distribution. A network operator MAY use a dedicated Route- 1971 Reflector infrastructure to distribute Link-State NLRIs. 1973 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1974 domain, which can consist of multiple areas within an AS or multiple 1975 ASes. 1977 7.1.6. Verifying Correct Operation 1979 Existing BGP procedures apply. In addition, an implementation SHOULD 1980 allow an operator to: 1982 o List neighbors with whom the speaker is exchanging Link-State 1983 NLRIs. 1985 7.2. Management Considerations 1987 7.2.1. Management Information 1989 The IDR working group has documented and continues to document parts 1990 of the Management Information Base and YANG models for managing and 1991 monitoring BGP speakers and the sessions between them. It is 1992 currently believed that the BGP session running BGP-LS is not 1993 substantially different from any other BGP session and can be managed 1994 using the same data models. 1996 7.2.2. Fault Management 1998 This section describes the fault management actions, as described in 1999 [RFC7606] , that are to be performed for handling of BGP update 2000 messages for BGP-LS. 2002 A Link-State NLRI MUST NOT be considered as malformed or invalid 2003 based on the inclusion/exclusion of TLVs or contents of the TLV 2004 fields (i.e. semantic errors), as described in Section 4.1 and 2005 Section 4.2. 2007 A BGP-LS Speaker MUST perform the following syntactic validation of 2008 the Link-State NLRI to determine if it is malformed. 2010 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 2011 correspond to the BGP MP_REACH_NLRI length? 2013 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 2014 attribute correspond to the BGP MP_UNREACH_NLRI length? 2016 o Does the sum of all TLVs found in a Link-State NLRI correspond to 2017 the Total NLRI Length field of all its Descriptors? 2019 o Is the length of the TLVs and, when the TLV is recognized then, 2020 its sub-TLVs in the NLRI valid? 2022 o Has the syntactic correctness of the NLRI fields been verified as 2023 per [RFC7606]? 2025 o Has the rule regarding ordering of TLVs been followed as described 2026 in Section 4.1? 2028 When the error determined allows for the router to skip the malformed 2029 NLRI(s) and continue processing of the rest of the update message 2030 (e.g. when the TLV ordering rule is violated), then it MUST handle 2031 such malformed NLRIs as 'Treat-as-withdraw'. In other cases, where 2032 the error in the NLRI encoding results in the inability to process 2033 the BGP update message (e.g. length related encoding errors), then 2034 the router SHOULD handle such malformed NLRIs as 'AFI/SAFI disable' 2035 when other AFI/SAFI besides BGP-LS are being advertised over the same 2036 session. Alternately, the router MUST perform 'session reset' when 2037 the session is only being used for BGP-LS or when it 'AFI/SAFI 2038 disable' action is not possible. 2040 A BGP-LS Attribute MUST NOT be considered as malformed or invalid 2041 based on the inclusion/exclusion of TLVs or contents of the TLV 2042 fields (i.e. semantic errors), as described in Section 4.1 and 2043 Section 4.3. 2045 A BGP-LS Speaker MUST perform the following syntactic validation of 2046 the BGP-LS Attribute to determine if it is malformed. 2048 o Does the sum of all TLVs found in the BGP-LS Attribute correspond 2049 to the BGP-LS Attribute length? 2051 o Has the syntactic correctness of the Attributes (including BGP-LS 2052 Attribute) been verified as per [RFC7606]? 2054 o Is the length of each TLV and, when the TLV is recognized then, 2055 its sub-TLVs in the BGP-LS Attribute valid? 2057 When the error determined allows for the router to skip the malformed 2058 BGP-LS Attribute and continue processing of the rest of the update 2059 message (e.g. when the BGP-LS Attribute length and the total Path 2060 Attribute Length are correct but some TLV/sub-TLV length within the 2061 BGP-LS Attribute is invalid), then it MUST handle such malformed BGP- 2062 LS Attribute as 'Attribute Discard'. In other cases, where the error 2063 in the BGP-LS Attribute encoding results in the inability to process 2064 the BGP update message then the handling is the same as described 2065 above for the malformed NLRI. 2067 Note that the 'Attribute Discard' action results in the loss of all 2068 TLVs in the BGP-LS Attribute and not the removal of a specific 2069 malformed TLV. The removal of specific malformed TLVs may give a 2070 wrong indication to a BGP-LS Consumer of that specific information 2071 being deleted or not available. 2073 When a BGP Speaker receives an update message with Link-State NLRI(s) 2074 in the MP_REACH_NLRI but without the BGP-LS Attribute, it is most 2075 likely an indication that a BGP Speaker preceding it has performed 2076 the 'Attribute Discard' fault handling. An implementation SHOULD 2077 preserve and propagate the Link-State NLRIs in such an update message 2078 so that the BGP-LS Consumers can detect the loss of link-state 2079 information for that object and not assume its deletion/withdraw. 2080 This also makes it possible for a network operator to trace back to 2081 the BGP-LS Propagator which actually detected a fault with the BGP-LS 2082 Attribute. 2084 An implementation SHOULD log an error for any errors found during 2085 syntax validation for further analysis. 2087 A BGP-LS Propagator SHOULD NOT perform semantic validation of the 2088 Link-State NLRI or the BGP-LS Attribute to determine if it is 2089 malformed or invalid. Some types of semantic validation that are not 2090 to be performed by a BGP-LS Propagator are as follows (and this is 2091 not to be considered as an exhaustive list): 2093 o is a mandatory TLV present or not? 2095 o is the length of a fixed length TLV correct or the length of a 2096 variable length TLV a valid/permissible? 2098 o are the values of TLV fields valid or permissible? 2100 o are the inclusion and use of TLVs/sub-TLVs with specific Link- 2101 State NLRI types valid? 2103 Each TLV MAY indicate the valid and permissible values and their 2104 semantics that can to be used only by a BGP-LS Consumer for its 2105 semantic validation. However, the handling of any errors may be 2106 specific to the particular application and outside the scope of this 2107 document. A BGP-LS Consumer should ignore unrecognized and 2108 unexpected TLV types in both the NLRI and BGP-LS Attribute portions 2109 and not consider their presence as an error. 2111 7.2.3. Configuration Management 2113 An implementation SHOULD allow the operator to specify neighbors to 2114 which Link-State NLRIs will be advertised and from which Link-State 2115 NLRIs will be accepted. 2117 An implementation SHOULD allow the operator to specify the maximum 2118 rate at which Link-State NLRIs will be advertised/withdrawn from 2119 neighbors. 2121 An implementation SHOULD allow the operator to specify the maximum 2122 number of Link-State NLRIs stored in a router's Routing Information 2123 Base (RIB). 2125 An implementation SHOULD allow the operator to create abstracted 2126 topologies that are advertised to neighbors and create different 2127 abstractions for different neighbors. 2129 An implementation SHOULD allow the operator to configure a 64-bit 2130 Instance-ID. 2132 An implementation SHOULD allow the operator to configure ASN and BGP- 2133 LS identifiers (refer Section 4.2.1.4). 2135 An implementation SHOULD allow the operator to configure the maximum 2136 size of the BGP-LS Attribute that may be used on a BGP-LS Producer. 2138 7.2.4. Accounting Management 2140 Not Applicable. 2142 7.2.5. Performance Management 2144 An implementation SHOULD provide the following statistics: 2146 o Total number of Link-State NLRI updates sent/received 2148 o Number of Link-State NLRI updates sent/received, per neighbor 2150 o Number of errored received Link-State NLRI updates, per neighbor 2152 o Total number of locally originated Link-State NLRIs 2154 These statistics should be recorded as absolute counts since system 2155 or session start time. An implementation MAY also enhance this 2156 information by recording peak per-second counts in each case. 2158 7.2.6. Security Management 2160 An operator SHOULD define an import policy to limit inbound updates 2161 as follows: 2163 o Drop all updates from peers that are only serving BGP-LS 2164 Consumers. 2166 An implementation MUST have the means to limit inbound updates. 2168 8. TLV/Sub-TLV Code Points Summary 2170 This section contains the global table of all TLVs/sub-TLVs defined 2171 in this document. 2173 +-----------+---------------------+--------------+------------------+ 2174 | TLV Code | Description | IS-IS TLV/ | Reference | 2175 | Point | | Sub-TLV | (RFC/Section) | 2176 +-----------+---------------------+--------------+------------------+ 2177 | 256 | Local Node | --- | Section 4.2.1.2 | 2178 | | Descriptors | | | 2179 | 257 | Remote Node | --- | Section 4.2.1.3 | 2180 | | Descriptors | | | 2181 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 2182 | | Identifiers | | | 2183 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 2184 | | address | | | 2185 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 2186 | | address | | | 2187 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 2188 | | address | | | 2189 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 2190 | | address | | | 2191 | 263 | Multi-Topology ID | --- | Section 4.2.2.1 | 2192 | 264 | OSPF Route Type | --- | Section 4.2.3 | 2193 | 265 | IP Reachability | --- | Section 4.2.3 | 2194 | | Information | | | 2195 | 512 | Autonomous System | --- | Section 4.2.1.4 | 2196 | 513 | BGP-LS Identifier | --- | Section 4.2.1.4 | 2197 | | (deprecated) | | | 2198 | 514 | OSPF Area-ID | --- | Section 4.2.1.4 | 2199 | 515 | IGP Router-ID | --- | Section 4.2.1.4 | 2200 | 1024 | Node Flag Bits | --- | Section 4.3.1.1 | 2201 | 1025 | Opaque Node | --- | Section 4.3.1.5 | 2202 | | Attribute | | | 2203 | 1026 | Node Name | variable | Section 4.3.1.3 | 2204 | 1027 | IS-IS Area | variable | Section 4.3.1.2 | 2205 | | Identifier | | | 2206 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 2207 | | Local Node | | | 2208 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 2209 | | Local Node | | | 2210 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 2211 | | Remote Node | | | 2212 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 2213 | | Remote Node | | | 2214 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 2215 | | group (color) | | | 2216 | 1089 | Maximum link | 22/9 | [RFC5305]/3.4 | 2217 | | bandwidth | | | 2218 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 2219 | | link bandwidth | | | 2220 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 2221 | | bandwidth | | | 2222 | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | 2223 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 2224 | | Type | | | 2225 | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | 2226 | 1095 | IGP Metric | --- | Section 4.3.2.4 | 2227 | 1096 | Shared Risk Link | --- | Section 4.3.2.5 | 2228 | | Group | | | 2229 | 1097 | Opaque Link | --- | Section 4.3.2.6 | 2230 | | Attribute | | | 2231 | 1098 | Link Name | --- | Section 4.3.2.7 | 2232 | 1152 | IGP Flags | --- | Section 4.3.3.1 | 2233 | 1153 | IGP Route Tag | --- | [RFC5130] | 2234 | 1154 | IGP Extended Route | --- | [RFC5130] | 2235 | | Tag | | | 2236 | 1155 | Prefix Metric | --- | [RFC5305] | 2237 | 1156 | OSPF Forwarding | --- | [RFC2328] | 2238 | | Address | | | 2239 | 1157 | Opaque Prefix | --- | Section 4.3.3.6 | 2240 | | Attribute | | | 2241 +-----------+---------------------+--------------+------------------+ 2243 Table 12: Summary Table of TLV/Sub-TLV Code Points 2245 9. Security Considerations 2247 Procedures and protocol extensions defined in this document do not 2248 affect the BGP security model. See the Security Considerations 2249 section of [RFC4271] for a discussion of BGP security. Also refer to 2250 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 2252 In the context of the BGP peerings associated with this document, a 2253 BGP speaker MUST NOT accept updates from a peer that is only 2254 providing information to a BGP-LS Consumer. That is, a participating 2255 BGP speaker should be aware of the nature of its relationships for 2256 link-state relationships and should protect itself from peers sending 2257 updates that either represent erroneous information feedback loops or 2258 are false input. Such protection can be achieved by manual 2259 configuration of consumer peers at the BGP speaker. 2261 An operator SHOULD employ a mechanism to protect a BGP speaker 2262 against DDoS attacks from BGP-LS Consumers. The principal attack a 2263 consumer may apply is to attempt to start multiple sessions either 2264 sequentially or simultaneously. Protection can be applied by 2265 imposing rate limits. 2267 Additionally, it may be considered that the export of link-state and 2268 TE information as described in this document constitutes a risk to 2269 confidentiality of mission-critical or commercially sensitive 2270 information about the network. BGP peerings are not automatic and 2271 require configuration; thus, it is the responsibility of the network 2272 operator to ensure that only trusted consumers are configured to 2273 receive such information. 2275 10. Contributors 2277 We would like to thank Robert Varga for the significant contribution 2278 he gave to RFC7752. 2280 11. Acknowledgements 2282 This document update to the BGP-LS specification [RFC7752] is a 2283 result of feedback and inputs from the discussions in the IDR working 2284 group. It also incorporates certain details and clarifications based 2285 on implementation and deployment experience with BGP-LS. 2287 Cengiz Alaettinoglu and Parag Amritkar brought forward the need to 2288 clarify the advertisement of LAN subnet for OSPF. 2290 We would like to thank Balaji Rajagopalan, Srihari Sangli and 2291 Shraddha Hegde for their review and feedback on this document. 2293 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 2294 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 2295 Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, 2296 Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas 2297 Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, 2298 Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and 2299 Ben Campbell for their comments on RFC7752. 2301 12. References 2303 12.1. Normative References 2305 [I-D.ietf-idr-bgp-extended-messages] 2306 Bush, R., Patel, K., and D. Ward, "Extended Message 2307 support for BGP", draft-ietf-idr-bgp-extended-messages-33 2308 (work in progress), July 2019. 2310 [ISO10589] 2311 International Organization for Standardization, 2312 "Intermediate System to Intermediate System intra-domain 2313 routeing information exchange protocol for use in 2314 conjunction with the protocol for providing the 2315 connectionless-mode network service (ISO 8473)", ISO/ 2316 IEC 10589, November 2002. 2318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2319 Requirement Levels", BCP 14, RFC 2119, 2320 DOI 10.17487/RFC2119, March 1997, 2321 . 2323 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 2324 DOI 10.17487/RFC2328, April 1998, 2325 . 2327 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2328 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2329 DOI 10.17487/RFC2545, March 1999, 2330 . 2332 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2333 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2334 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2335 . 2337 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 2338 in Support of Generalized Multi-Protocol Label Switching 2339 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 2340 . 2342 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 2343 Support of Generalized Multi-Protocol Label Switching 2344 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 2345 . 2347 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2348 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2349 DOI 10.17487/RFC4271, January 2006, 2350 . 2352 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2353 "Multiprotocol Extensions for BGP-4", RFC 4760, 2354 DOI 10.17487/RFC4760, January 2007, 2355 . 2357 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 2358 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 2359 RFC 4915, DOI 10.17487/RFC4915, June 2007, 2360 . 2362 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 2363 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 2364 October 2007, . 2366 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 2367 Topology (MT) Routing in Intermediate System to 2368 Intermediate Systems (IS-ISs)", RFC 5120, 2369 DOI 10.17487/RFC5120, February 2008, 2370 . 2372 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 2373 Control Mechanism in IS-IS Using Administrative Tags", 2374 RFC 5130, DOI 10.17487/RFC5130, February 2008, 2375 . 2377 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 2378 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 2379 October 2008, . 2381 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2382 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2383 2008, . 2385 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 2386 in Support of Generalized Multi-Protocol Label Switching 2387 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 2388 . 2390 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2391 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2392 . 2394 [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, 2395 "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, 2396 DOI 10.17487/RFC5642, August 2009, 2397 . 2399 [RFC5890] Klensin, J., "Internationalized Domain Names for 2400 Applications (IDNA): Definitions and Document Framework", 2401 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2402 . 2404 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 2405 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 2406 February 2011, . 2408 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 2409 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 2410 March 2012, . 2412 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2413 Patel, "Revised Error Handling for BGP UPDATE Messages", 2414 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2415 . 2417 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 2418 S. Ray, "North-Bound Distribution of Link-State and 2419 Traffic Engineering (TE) Information Using BGP", RFC 7752, 2420 DOI 10.17487/RFC7752, March 2016, 2421 . 2423 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2424 Writing an IANA Considerations Section in RFCs", BCP 26, 2425 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2426 . 2428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2430 May 2017, . 2432 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 2433 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2434 2017, . 2436 12.2. Informative References 2438 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2439 and E. Lear, "Address Allocation for Private Internets", 2440 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2441 . 2443 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2444 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2445 . 2447 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2448 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2449 2006, . 2451 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2452 Element (PCE)-Based Architecture", RFC 4655, 2453 DOI 10.17487/RFC4655, August 2006, 2454 . 2456 [RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing 2457 Protocol Extensions for Discovery of Traffic Engineering 2458 Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, 2459 December 2007, . 2461 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 2462 Per-Domain Path Computation Method for Establishing Inter- 2463 Domain Traffic Engineering (TE) Label Switched Paths 2464 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 2465 . 2467 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 2468 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2469 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 2470 December 2008, . 2472 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 2473 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2474 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 2475 January 2009, . 2477 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2478 Optimization (ALTO) Problem Statement", RFC 5693, 2479 DOI 10.17487/RFC5693, October 2009, 2480 . 2482 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 2483 Management of New Protocols and Protocol Extensions", 2484 RFC 5706, DOI 10.17487/RFC5706, November 2009, 2485 . 2487 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2488 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2489 and Authentication for Routing Protocols (KARP) Design 2490 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2491 . 2493 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 2494 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 2495 "Application-Layer Traffic Optimization (ALTO) Protocol", 2496 RFC 7285, DOI 10.17487/RFC7285, September 2014, 2497 . 2499 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 2500 S. Shaffer, "Extensions to OSPF for Advertising Optional 2501 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 2502 February 2016, . 2504 Appendix A. Changes from RFC 7752 2506 This section lists the high-level changes from RFC 7752 and provides 2507 reference to the document sections wherein those have been 2508 introduced. 2510 1. Update the Figure 1 in Section 1 and added Section 3 to 2511 illustrate the different roles of a BGP implementation in 2512 conveying link-state information. 2514 2. In Section 4.1, clarification about the TLV handling aspects 2515 that are applicable to both the NLRI and BGP-LS Attribute parts 2516 and those that are applicable only for the NLRI portion. An 2517 implementation may have missed the part about handling of 2518 unrecognized TLV and so, based on [RFC7606] guidelines, might 2519 discard the unknown NLRI types. This aspect is now 2520 unambiguously clarified in Section 4.2. Also, the ascending 2521 order of TLVs in the BGP-LS Attribute is not necessary. 2523 3. Clarification of mandatory and optional TLVs in both NLRI and 2524 BGP-LS Attribute portions all through the document. 2526 4. Handling of the growth of the BGP-LS Attribute is covered in 2527 Section 4.3. 2529 5. Clarification on the use of Identifier field in the Link-State 2530 NLRI in Section 4.2 is provided. It was defined ambiguously to 2531 refer to only mutli-instance IGP on a single link while it can 2532 also be used for multiple IGP protocol instances on a router. 2533 The IANA registry is accordingly being removed. 2535 6. The BGP-LS Identifier TLV in the Node Descriptors has been 2536 deprecated. Its use was not well specified by [RFC7752] and 2537 there has been some amount of confusion between implementators 2538 on its usage for identification of IGP domains as against the 2539 use of the Identifier doing the same functionality as the 2540 Instance-ID when running multiple instances of IGP routing 2541 protocols. 2543 7. Moved MT-ID TLV from the Node Descriptor section to under the 2544 Link Descriptor section since it is not a Node Descriptor sub- 2545 TLV. Also fixed the ambiguity in the encoding of OSPF MT-ID in 2546 this TLV. MT-ID TLV use is now elevated to SHOULD when it is 2547 enabled in the underlying IGP. 2549 8. Update the usage of OSPF Route Type TLV to mandate its use for 2550 OSPF prefixes in Section 4.2.3.1 since this is required for 2551 segregation of intra-area prefixes that are used to reach a node 2552 (e.g. a loopback) from other types of inter-area and external 2553 prefixes. 2555 9. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF 2556 specification. 2558 10. Clarified the advertisement of the prefix corresponding to the 2559 LAN segment in an OSPF network in Section 4.9. 2561 11. Introduced Private Use TLV code point space and specified their 2562 encoding in Section 4.4. 2564 12. Introduced Section 4.7 where issues related to consistency of 2565 reporting IGP link-state along with their solutions are covered. 2567 13. Handling of large size of BGP-LS Attribute with growth in BGP-LS 2568 information is explained in Section 4.3 along with mitigation of 2569 errors arising out of it. 2571 14. Added recommendation for isolation of BGP-LS sessions from other 2572 BGP route exchange to avoid errors and faults in BGP-LS 2573 affecting the normal BGP routing. 2575 15. Updated the Fault Management section with detailed rules based 2576 on the role in the BGP-LS information propagation flow. 2578 Authors' Addresses 2579 Ketan Talaulikar (editor) 2580 Cisco Systems 2581 India 2583 Email: ketant@cisco.com 2585 Hannes Gredler 2586 Rtbrick 2588 Email: hannes@rtbrick.com 2590 Jan Medved 2591 Cisco Systems, Inc. 2592 170, West Tasman Drive 2593 San Jose, CA 95134 2594 US 2596 Email: jmedved@cisco.com 2598 Stefano Previdi 2599 Individual Contributor 2600 Rome 2601 Italy 2603 Email: stefano@previdi.net 2605 Adrian Farrel 2606 Old Dog Consulting 2608 Email: adrian@olddog.co.uk 2610 Saikat Ray 2611 Individual Contributor 2613 Email: raysaikat@gmail.com