idnits 2.17.1 draft-ietf-idr-ls-distribution-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2015) is 3108 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6822 (Obsoleted by RFC 8202) -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing H. Gredler, Ed. 3 Internet-Draft Private Contributor 4 Intended status: Standards Track J. Medved 5 Expires: April 18, 2016 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 October 16, 2015 12 North-Bound Distribution of Link-State and TE Information using BGP 13 draft-ietf-idr-ls-distribution-13 15 Abstract 17 In a number of environments, a component external to a network is 18 called upon to perform computations based on the network topology and 19 current state of the connections within the network, including 20 traffic engineering information. This is information typically 21 distributed by IGP routing protocols within the network. 23 This document describes a mechanism by which links state and traffic 24 engineering information can be collected from networks and shared 25 with external components using the BGP routing protocol. This is 26 achieved using a new BGP Network Layer Reachability Information 27 (NLRI) encoding format. The mechanism is applicable to physical and 28 virtual IGP links. The mechanism described is subject to policy 29 control. 31 Applications of this technique include Application Layer Traffic 32 Optimization (ALTO) servers, and Path Computation Elements (PCEs). 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 18, 2016. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 76 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 77 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6 78 3. Carrying Link State Information in BGP . . . . . . . . . . . 7 79 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8 81 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 12 82 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 16 83 3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 17 84 3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 19 85 3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19 86 3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 23 87 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 28 88 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 31 89 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 32 90 3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 32 91 3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 33 92 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 34 93 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 34 94 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 35 95 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 35 96 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 36 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 98 5.1. Guidance for Designated Experts . . . . . . . . . . . . . 37 99 6. Manageability Considerations . . . . . . . . . . . . . . . . 37 100 6.1. Operational Considerations . . . . . . . . . . . . . . . 37 101 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 37 102 6.1.2. Installation and Initial Setup . . . . . . . . . . . 38 103 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 38 104 6.1.4. Requirements on Other Protocols and Functional 105 Components . . . . . . . . . . . . . . . . . . . . . 38 106 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 38 107 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 38 108 6.2. Management Considerations . . . . . . . . . . . . . . . . 39 109 6.2.1. Management Information . . . . . . . . . . . . . . . 39 110 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 39 111 6.2.3. Configuration Management . . . . . . . . . . . . . . 39 112 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 40 113 6.2.5. Performance Management . . . . . . . . . . . . . . . 40 114 6.2.6. Security Management . . . . . . . . . . . . . . . . . 40 115 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 40 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 117 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 43 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 120 11.1. Normative References . . . . . . . . . . . . . . . . . . 43 121 11.2. Informative References . . . . . . . . . . . . . . . . . 45 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 124 1. Introduction 126 The contents of a Link State Database (LSDB) or of an IGP's Traffic 127 Engineering Database (TED) describe only the links and nodes within 128 an IGP area. Some applications, such as end-to-end Traffic 129 Engineering (TE), would benefit from visibility outside one area or 130 Autonomous System (AS) in order to make better decisions. 132 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 133 a mechanism for achieving the computation of end-to-end TE paths that 134 cross the visibility of more than one TED or which require CPU- 135 intensive or coordinated computations. The IETF has also defined the 136 ALTO Server [RFC5693] as an entity that generates an abstracted 137 network topology and provides it to network-aware applications. 139 Both a PCE and an ALTO Server need to gather information about the 140 topologies and capabilities of the network in order to be able to 141 fulfill their function. 143 This document describes a mechanism by which Link State and TE 144 information can be collected from networks and shared with external 145 components using the BGP routing protocol [RFC4271]. This is 146 achieved using a new BGP Network Layer Reachability Information 147 (NLRI) encoding format. The mechanism is applicable to physical and 148 virtual links. The mechanism described is subject to policy control. 150 A router maintains one or more databases for storing link-state 151 information about nodes and links in any given area. Link attributes 152 stored in these databases include: local/remote IP addresses, local/ 153 remote interface identifiers, link metric and TE metric, link 154 bandwidth, reservable bandwidth, per CoS class reservation state, 155 preemption and Shared Risk Link Groups (SRLG). The router's BGP 156 process can retrieve topology from these LSDBs and distribute it to a 157 consumer, either directly or via a peer BGP Speaker (typically a 158 dedicated Route Reflector), using the encoding specified in this 159 document. 161 The collection of Link State and TE link state information and its 162 distribution to consumers is shown in the following figure. 164 +-----------+ 165 | Consumer | 166 +-----------+ 167 ^ 168 | 169 +-----------+ 170 | BGP | +-----------+ 171 | Speaker | | Consumer | 172 +-----------+ +-----------+ 173 ^ ^ ^ ^ 174 | | | | 175 +---------------+ | +-------------------+ | 176 | | | | 177 +-----------+ +-----------+ +-----------+ 178 | BGP | | BGP | | BGP | 179 | Speaker | | Speaker | . . . | Speaker | 180 +-----------+ +-----------+ +-----------+ 181 ^ ^ ^ 182 | | | 183 IGP IGP IGP 185 Figure 1: TE Link State info collection 187 A BGP Speaker may apply configurable policy to the information that 188 it distributes. Thus, it may distribute the real physical topology 189 from the LSDB or the TED. Alternatively, it may create an abstracted 190 topology, where virtual, aggregated nodes are connected by virtual 191 paths. Aggregated nodes can be created, for example, out of multiple 192 routers in a POP. Abstracted topology can also be a mix of physical 193 and virtual nodes and physical and virtual links. Furthermore, the 194 BGP Speaker can apply policy to determine when information is updated 195 to the consumer so that there is reduction of information flow from 196 the network to the consumers. Mechanisms through which topologies 197 can be aggregated or virtualized are outside the scope of this 198 document 200 2. Motivation and Applicability 202 This section describes use cases from which the requirements can be 203 derived. 205 2.1. MPLS-TE with PCE 207 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 208 within a "domain" (such as an IGP area) or across multiple domains 209 (such as a multi-area AS, or multiple ASes). 211 o Within a single area, the PCE offers enhanced computational power 212 that may not be available on individual routers, sophisticated 213 policy control and algorithms, and coordination of computation 214 across the whole area. 216 o If a router wants to compute a MPLS-TE path across IGP areas, then 217 its own TED lacks visibility of the complete topology. That means 218 that the router cannot determine the end-to-end path, and cannot 219 even select the right exit router (Area Border Router - ABR) for 220 an optimal path. This is an issue for large-scale networks that 221 need to segment their core networks into distinct areas, but still 222 want to take advantage of MPLS-TE. 224 Previous solutions used per-domain path computation [RFC5152]. The 225 source router could only compute the path for the first area because 226 the router only has full topological visibility for the first area 227 along the path, but not for subsequent areas. Per-domain path 228 computation uses a technique called "loose-hop-expansion" [RFC3209], 229 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 230 using the IGP computed shortest path topology for the remainder of 231 the path. This may lead to sub-optimal paths, makes alternate/back- 232 up path computation hard, and might result in no TE path being found 233 when one really does exist. 235 The PCE presents a computation server that may have visibility into 236 more than one IGP area or AS, or may cooperate with other PCEs to 237 perform distributed path computation. The PCE obviously needs access 238 to the TED for the area(s) it serves, but [RFC4655] does not describe 239 how this is achieved. Many implementations make the PCE a passive 240 participant in the IGP so that it can learn the latest state of the 241 network, but this may be sub-optimal when the network is subject to a 242 high degree of churn, or when the PCE is responsible for multiple 243 areas. 245 The following figure shows how a PCE can get its TED information 246 using the mechanism described in this document. 248 +----------+ +---------+ 249 | ----- | | BGP | 250 | | TED |<-+-------------------------->| Speaker | 251 | ----- | TED synchronization | | 252 | | | mechanism: +---------+ 253 | | | BGP with Link-State NLRI 254 | v | 255 | ----- | 256 | | PCE | | 257 | ----- | 258 +----------+ 259 ^ 260 | Request/ 261 | Response 262 v 263 Service +----------+ Signaling +----------+ 264 Request | Head-End | Protocol | Adjacent | 265 -------->| Node |<------------>| Node | 266 +----------+ +----------+ 268 Figure 2: External PCE node using a TED synchronization mechanism 270 The mechanism in this document allows the necessary TED information 271 to be collected from the IGP within the network, filtered according 272 to configurable policy, and distributed to the PCE as necessary. 274 2.2. ALTO Server Network API 276 An ALTO Server [RFC5693] is an entity that generates an abstracted 277 network topology and provides it to network-aware applications over a 278 web service based API. Example applications are p2p clients or 279 trackers, or CDNs. The abstracted network topology comes in the form 280 of two maps: a Network Map that specifies allocation of prefixes to 281 Partition Identifiers (PIDs), and a Cost Map that specifies the cost 282 between PIDs listed in the Network Map. For more details, see 283 [RFC7285]. 285 ALTO abstract network topologies can be auto-generated from the 286 physical topology of the underlying network. The generation would 287 typically be based on policies and rules set by the operator. Both 288 prefix and TE data are required: prefix data is required to generate 289 ALTO Network Maps, TE (topology) data is required to generate ALTO 290 Cost Maps. Prefix data is carried and originated in BGP, TE data is 291 originated and carried in an IGP. The mechanism defined in this 292 document provides a single interface through which an ALTO Server can 293 retrieve all the necessary prefix and network topology data from the 294 underlying network. Note an ALTO Server can use other mechanisms to 295 get network data, for example, peering with multiple IGP and BGP 296 Speakers. 298 The following figure shows how an ALTO Server can get network 299 topology information from the underlying network using the mechanism 300 described in this document. 302 +--------+ 303 | Client |<--+ 304 +--------+ | 305 | ALTO +--------+ BGP with +---------+ 306 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 307 | Client |<--+------------| Server |<----------------| Speaker | 308 +--------+ | | | | | 309 | +--------+ +---------+ 310 +--------+ | 311 | Client |<--+ 312 +--------+ 314 Figure 3: ALTO Server using network topology information 316 3. Carrying Link State Information in BGP 318 This specification contains two parts: definition of a new BGP NLRI 319 that describes links, nodes and prefixes comprising IGP link state 320 information, and definition of a new BGP path attribute (BGP-LS 321 attribute) that carries link, node and prefix properties and 322 attributes, such as the link and prefix metric or auxiliary Router- 323 IDs of nodes, etc. 325 It is desired to keep the dependencies on the protocol source of this 326 attributes to a minimum and represent any content in an IGP neutral 327 way, such that applications which do want to learn about a Link-state 328 topology do not need to know about any OSPF or IS-IS protocol 329 specifics. 331 3.1. TLV Format 333 Information in the new Link-State NLRIs and attributes is encoded in 334 Type/Length/Value triplets. The TLV format is shown in Figure 4. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 // Value (variable) // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 4: TLV format 346 The Length field defines the length of the value portion in octets 347 (thus a TLV with no value portion would have a length of zero). The 348 TLV is not padded to four-octet alignment. Unrecognized types MUST 349 be preserved and propagated. In order to compare NLRIs with unknown 350 TLVs all TLVs MUST be ordered in ascending order by TLV Type. If 351 there are more TLVs of the same type, then the TLVs MUST be ordered 352 in ascending order of the TLV value within the TLVs with the same 353 type by treating the entire value field an opaque hexadecimal string 354 and comparing leftmost octets first regardless of the length of the 355 string. . All TLVs that are not specified as mandatory are 356 considered optional. 358 3.2. The Link-State NLRI 360 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 361 for carrying opaque information. Each Link-State NLRI describes 362 either a node, a link or a prefix. 364 All non-VPN link, node and prefix information SHALL be encoded using 365 AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be 366 encoded using AFI 16388 / SAFI TBD. 368 In order for two BGP speakers to exchange Link-State NLRI, they MUST 369 use BGP Capabilities Advertisement to ensure that they both are 370 capable of properly processing such NLRI. This is done as specified 371 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 372 AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI TBD for BGP-LS- 373 VPN. 375 The format of the Link-State NLRI is shown in the following figure. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | NLRI Type | Total NLRI Length | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 // Link-State NLRI (variable) // 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | NLRI Type | Total NLRI Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 + Route Distinguisher + 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 // Link-State NLRI (variable) // 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 6: Link-State VPN AFI 16388 / SAFI TBD NLRI Format 405 The 'Total NLRI Length' field contains the cumulative length, in 406 octets, of rest of the NLRI not including the NLRI Type field or 407 itself. For VPN applications, it also includes the length of the 408 Route Distinguisher. 410 +------+---------------------------+ 411 | Type | NLRI Type | 412 +------+---------------------------+ 413 | 1 | Node NLRI | 414 | 2 | Link NLRI | 415 | 3 | IPv4 Topology Prefix NLRI | 416 | 4 | IPv6 Topology Prefix NLRI | 417 +------+---------------------------+ 419 Table 1: NLRI Types 421 Route Distinguishers are defined and discussed in [RFC4364]. 423 The Node NLRI (NLRI Type = 1) is shown in the following figure. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+ 428 | Protocol-ID | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Identifier | 431 | (64 bits) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 // Local Node Descriptors (variable) // 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 7: The Node NLRI format 438 The Link NLRI (NLRI Type = 2) is shown in the following figure. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+ 443 | Protocol-ID | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Identifier | 446 | (64 bits) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 // Local Node Descriptors (variable) // 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 // Remote Node Descriptors (variable) // 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 // Link Descriptors (variable) // 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 8: The Link NLRI format 457 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 458 same format as shown in the following figure. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+ 463 | Protocol-ID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Identifier | 466 | (64 bits) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 // Local Node Descriptor (variable) // 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 // Prefix Descriptors (variable) // 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 9: The IPv4/IPv6 Topology Prefix NLRI format 475 The 'Protocol-ID' field can contain one of the following values: 477 +-------------+----------------------------------+ 478 | Protocol-ID | NLRI information source protocol | 479 +-------------+----------------------------------+ 480 | 1 | IS-IS Level 1 | 481 | 2 | IS-IS Level 2 | 482 | 3 | OSPFv2 | 483 | 4 | Direct | 484 | 5 | Static configuration | 485 | 6 | OSPFv3 | 486 +-------------+----------------------------------+ 488 Table 2: Protocol Identifiers 490 The 'Direct' and 'Static configuration' protocol types SHOULD be used 491 when BGP-LS is sourcing local information. For all information, 492 derived from other protocols the corresponding protocol-ID MUST be 493 used. If BGP-LS has got direct access to interface information and 494 wants to advertise a local link then the protocol-ID 'Direct' SHOULD 495 be used. For modeling virtual links, like described in Section 4 the 496 protocol-ID 'Static configuration' SHOULD be used. 498 Both OSPF and IS-IS MAY run multiple routing protocol instances over 499 the same link. See [RFC6822] and [RFC6549]. These instances define 500 independent "routing universes". The 64-Bit 'Identifier' field is 501 used to identify the "routing universe" where the NLRI belongs. The 502 NLRIs representing Link-state objects (nodes, links or prefixes) from 503 the same routing universe MUST have the same 'Identifier' value. 504 NLRIs with different 'Identifier' values MUST be considered to be 505 from different routing universes. Table 3 lists the 'Identifier' 506 values that are defined as well-known in this draft. 508 +------------+----------------------------------+ 509 | Identifier | Routing Universe | 510 +------------+----------------------------------+ 511 | 0 | Default Layer 3 Routing topology | 512 | 1-31 | Reserved | 513 +------------+----------------------------------+ 515 Table 3: Well-known Instance Identifiers 517 If a given Protocol does not support multiple routing universes then 518 it SHOULD set the 'Identifier' field according to Table 3. However 519 an implementation MAY make the 'Identifier' configurable, for a given 520 protocol. 522 Each Node Descriptor and Link Descriptor consists of one or more TLVs 523 described in the following sections. 525 3.2.1. Node Descriptors 527 Each link is anchored by a pair of Router-IDs that are used by the 528 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 529 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 530 additional auxiliary Router-IDs, mainly for traffic engineering 531 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 532 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 533 included in the link attribute described in Section 3.3.2. 535 It is desirable that the Router-ID assignments inside the Node 536 Descriptor are globally unique. However there may be Router-ID 537 spaces (e.g. ISO) where no global registry exists, or worse, Router- 538 IDs have been allocated following private-IP RFC 1918 [RFC1918] 539 allocation. BGP-LS uses the Autonomous System (AS) Number and BGP-LS 540 Identifier (see Section 3.2.1.4) to disambiguate the Router-IDs, as 541 described in Section 3.2.1.1. 543 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 545 One problem that needs to be addressed is the ability to identify an 546 IGP node globally (by "global", we mean within the BGP-LS database 547 collected by all BGP-LS speakers that talk to each other). This can 548 be expressed through the following two requirements: 550 (A) The same node MUST NOT be represented by two keys (otherwise one 551 node will look like two nodes). 553 (B) Two different nodes MUST NOT be represented by the same key 554 (otherwise, two nodes will look like one node). 556 We define an "IGP domain" to be the set of nodes (hence, by extension 557 links and prefixes), within which, each node has a unique IGP 558 representation by using the combination of Area-ID, Router-ID, 559 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 560 receive node/link/prefix information from multiple independent "IGP 561 domains" and we need to distinguish between them. Moreover, we can't 562 assume there is always one and only one IGP domain per AS. During 563 IGP transitions it may happen that two redundant IGPs are in place. 565 In Section 3.2.1.4 a set of sub-TLVs is described, which allows 566 specification of a flexible key for any given Node/Link information 567 such that global uniqueness of the NLRI is ensured. 569 3.2.1.2. Local Node Descriptors 571 The Local Node Descriptors TLV contains Node Descriptors for the node 572 anchoring the local end of the link. This is a mandatory TLV in all 573 three types of NLRIs (node, link, and prefix). The length of this 574 TLV is variable. The value contains one or more Node Descriptor Sub- 575 TLVs defined in Section 3.2.1.4. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | | 583 // Node Descriptor Sub-TLVs (variable) // 584 | | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 10: Local Node Descriptors TLV format 589 3.2.1.3. Remote Node Descriptors 591 The Remote Node Descriptors contains Node Descriptors for the node 592 anchoring the remote end of the link. This is a mandatory TLV for 593 link NLRIs. The length of this TLV is variable. The value contains 594 one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Length | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | | 602 // Node Descriptor Sub-TLVs (variable) // 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Figure 11: Remote Node Descriptors TLV format 608 3.2.1.4. Node Descriptor Sub-TLVs 610 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 611 the following table: 613 +--------------------+-------------------+----------+ 614 | Sub-TLV Code Point | Description | Length | 615 +--------------------+-------------------+----------+ 616 | 512 | Autonomous System | 4 | 617 | 513 | BGP-LS Identifier | 4 | 618 | 514 | OSPF Area-ID | 4 | 619 | 515 | IGP Router-ID | Variable | 620 +--------------------+-------------------+----------+ 622 Table 4: Node Descriptor Sub-TLVs 624 The sub-TLV values in Node Descriptor TLVs are defined as follows: 626 Autonomous System: opaque value (32 Bit AS Number) 628 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 629 ASN, uniquely identifies the BGP-LS domain. The combination of 630 ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers 631 within an IGP flooding-set (set of IGP nodes within which an LSP/ 632 LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP 633 domain consists of multiple flooding-sets, then all BGP-LS 634 speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID 635 tuple. The ASN, BGP Router-ID tuple (which is globally unique 636 [RFC6286] ) of one of the BGP-LS speakers within the flooding-set 637 (or IGP domain) may be used for all BGP-LS speakers in that 638 flooding-set (or IGP domain). 640 Area ID: It is used to identify the 32 Bit area to which the NLRI 641 belongs. Area Identifier allows the different NLRIs of the same 642 router to be discriminated. 644 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 645 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 646 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 647 octet ISO node-ID of the "Designated Intermediate System" (DIS) 648 followed by one octet nonzero PSN identifier (7 octets in total). 649 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 650 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, 651 this contains the 4 octet Router-ID of the designated router (DR) 652 followed by the 4 octet IPv4 address of the DR's interface to the 653 LAN (8 octets in total). Similarly, for an OSPFv3 "Pseudonode", 654 this contains the 4 octet Router-ID of the DR followed by the 4 655 octet interface identifier of the DR's interface to the LAN (8 656 octets in total). The TLV size in combination with protocol 657 identifier enables the decoder to determine the type of the node. 659 There can be at most one instance of each sub-TLV type present in 660 any Node Descriptor. The sub-TLVs within a Node descriptor MUST 661 be arranged in ascending order by sub-TLV type. This needs to be 662 done in order to compare NLRIs, even when an implementation 663 encounters an unknown sub-TLV. Using stable sorting an 664 implementation can do binary comparison of NLRIs and hence allow 665 incremental deployment of new key sub-TLVs. 667 3.2.1.5. Multi-Topology ID 669 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 670 Multi-Topology IDs for a link, node or prefix. 672 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 673 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 674 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 675 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 676 SHOULD be set to 0 when originated and ignored on receipt. 678 The format of the MT-ID TLV is shown in the following figure. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length=2*n | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 |R R R R| Multi-Topology ID 1 | .... // 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 // .... |R R R R| Multi-Topology ID n | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Figure 12: Multi-Topology ID TLV format 692 where Type is 263, Length is 2*n and n is the number of MT-IDs 693 carried in the TLV. 695 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 696 Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or 697 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 698 the topology where the link or the prefix is reachable is allowed. 699 In case one wants to advertise multiple topologies for a given Link 700 Descriptor or Prefix Descriptor, multiple NLRIs need to be generated 701 where each NLRI contains an unique MT-ID. In the BGP-LS attribute of 702 a node NLRI, one MT-ID TLV containing the array of MT-IDs of all 703 topologies where the node is reachable is allowed. 705 3.2.2. Link Descriptors 707 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 708 triplets. The format of each TLV is shown in Section 3.1. The 'Link 709 descriptor' TLVs uniquely identify a link among multiple parallel 710 links between a pair of anchor routers. A link described by the Link 711 descriptor TLVs actually is a "half-link", a unidirectional 712 representation of a logical link. In order to fully describe a 713 single logical link, two originating routers advertise a half-link 714 each, i.e., two link NLRIs are advertised for a given point-to-point 715 link. 717 The format and semantics of the 'value' fields in most 'Link 718 Descriptor' TLVs correspond to the format and semantics of value 719 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 720 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 721 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 722 carry data sourced either by IS-IS or OSPF. 724 The following TLVs are valid as Link Descriptors in the Link NLRI: 726 +-----------+---------------------+---------------+-----------------+ 727 | TLV Code | Description | IS-IS TLV | Value defined | 728 | Point | | /Sub-TLV | in: | 729 +-----------+---------------------+---------------+-----------------+ 730 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 731 | | Identifiers | | | 732 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 733 | | address | | | 734 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 735 | | address | | | 736 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 737 | | address | | | 738 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 739 | | address | | | 740 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 741 | | Identifier | | | 742 +-----------+---------------------+---------------+-----------------+ 744 Table 5: Link Descriptor TLVs 746 The information about a link present in the LSA/LSP originated by the 747 local node of the link determines the set of TLVs in the Link 748 Descriptor of the link. 750 If interface and neighbor addresses, either IPv4 or IPv6, are 751 present, then the IP address TLVs are included in the link 752 descriptor, but not the link local/remote Identifier TLV. The 753 link local/remote identifiers MAY be included in the link 754 attribute. 756 If interface and neighbor addresses are not present and the link 757 local/remote identifiers are present, then the link local/remote 758 Identifier TLV is included in the link descriptor. 760 The Multi-Topology Identifier TLV is included in link descriptor 761 if that information is present. 763 3.2.3. Prefix Descriptors 765 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 766 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 767 Prefix originated by a Node. The following TLVs are valid as Prefix 768 Descriptors in the IPv4/IPv6 Prefix NLRI: 770 +--------------+-----------------------+----------+-----------------+ 771 | TLV Code | Description | Length | Value defined | 772 | Point | | | in: | 773 +--------------+-----------------------+----------+-----------------+ 774 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 775 | | Identifier | | | 776 | 264 | OSPF Route Type | 1 | Section 3.2.3.1 | 777 | 265 | IP Reachability | variable | Section 3.2.3.2 | 778 | | Information | | | 779 +--------------+-----------------------+----------+-----------------+ 781 Table 6: Prefix Descriptor TLVs 783 3.2.3.1. OSPF Route Type 785 OSPF Route Type is an optional TLV that MAY be present in Prefix 786 NLRIs. It is used to identify the OSPF route-type of the prefix. It 787 is used when an OSPF prefix is advertised in the OSPF domain with 788 multiple route-types. The Route Type TLV allows the discrimination 789 of these advertisements. The format of the OSPF Route Type TLV is 790 shown in the following figure. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type | Length | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Route Type | 798 +-+-+-+-+-+-+-+-+ 800 Figure 13: OSPF Route Type TLV Format 802 where the Type and Length fields of the TLV are defined in Table 6. 803 The OSPF Route Type field values are defined in the OSPF protocol, 804 and can be one of the following: 806 Intra-Area (0x1) 808 Inter-Area (0x2) 810 External 1 (0x3) 812 External 2 (0x4) 814 NSSA 1 (0x5) 816 NSSA 2 (0x6) 818 3.2.3.2. IP Reachability Information 820 The IP Reachability Information is a mandatory TLV that contains one 821 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 822 topology. Its purpose is to glue a particular BGP service NLRI by 823 virtue of its BGP next-hop to a given Node in the LSDB. A router 824 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 825 The format of the IP Reachability Information TLV is shown in the 826 following figure: 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Length | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Prefix Length | IP Prefix (variable) // 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 14: IP Reachability Information TLV Format 838 The Type and Length fields of the TLV are defined in Table 6. The 839 following two fields determine the address-family reachability 840 information. The 'Prefix Length' field contains the length of the 841 prefix in bits. The 'IP Prefix' field contains the most significant 842 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 843 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 844 24 and 4 octets for prefix length 25 up to 32, etc. 846 3.3. The BGP-LS Attribute 848 This is an optional, non-transitive BGP attribute that is used to 849 carry link, node and prefix parameters and attributes. It is defined 850 as a set of Type/Length/Value (TLV) triplets, described in the 851 following section. This attribute SHOULD only be included with Link- 852 State NLRIs. This attribute MUST be ignored for all other address- 853 families. 855 3.3.1. Node Attribute TLVs 857 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 858 attribute with a node NLRI. The following node attribute TLVs are 859 defined: 861 +--------------+-----------------------+----------+-----------------+ 862 | TLV Code | Description | Length | Value defined | 863 | Point | | | in: | 864 +--------------+-----------------------+----------+-----------------+ 865 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 866 | | Identifier | | | 867 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 868 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 869 | | Properties | | | 870 | 1026 | Node Name | variable | Section 3.3.1.3 | 871 | 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 | 872 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 873 | | Local Node | | | 874 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 875 | | Local Node | | | 876 +--------------+-----------------------+----------+-----------------+ 878 Table 7: Node Attribute TLVs 880 3.3.1.1. Node Flag Bits TLV 882 The Node Flag Bits TLV carries a bit mask describing node attributes. 883 The value is a variable length bit array of flags, where each bit 884 represents a node capability. 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Type | Length | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |O|T|E|B|R|V| Rsvd| 892 +-+-+-+-+-+-+-+-+-+ 894 Figure 15: Node Flag Bits TLV format 896 The bits are defined as follows: 898 +-----------------+-------------------------+-----------+ 899 | Bit | Description | Reference | 900 +-----------------+-------------------------+-----------+ 901 | 'O' | Overload Bit | [RFC1195] | 902 | 'T' | Attached Bit | [RFC1195] | 903 | 'E' | External Bit | [RFC2328] | 904 | 'B' | ABR Bit | [RFC2328] | 905 | 'R' | Router Bit | [RFC5340] | 906 | 'V' | V6 Bit | [RFC5340] | 907 | Reserved (Rsvd) | Reserved for future use | | 908 +-----------------+-------------------------+-----------+ 910 Table 8: Node Flag Bits Definitions 912 3.3.1.2. IS-IS Area Identifier TLV 914 An IS-IS node can be part of one or more IS-IS areas. Each of these 915 area addresses is carried in the IS-IS Area Identifier TLV. If 916 multiple Area Addresses are present, multiple TLVs are used to encode 917 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 918 attribute only when advertised in the Link-State Node NLRI. 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Type | Length | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 // Area Identifier (variable) // 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Figure 16: IS-IS Area Identifier TLV Format 930 3.3.1.3. Node Name TLV 932 The Node Name TLV is optional. Its structure and encoding has been 933 borrowed from [RFC5301]. The value field identifies the symbolic 934 name of the router node. This symbolic name can be the FQDN for the 935 router, it can be a subset of the FQDN (e.g. a hostname), or it can 936 be any string operators want to use for the router. The use of FQDN 937 or a subset of it is strongly RECOMMENDED. The maximum length of the 938 'Node Name TLV' is 255 octets. 940 The Value field is encoded in 7-bit ASCII. If a user-interface for 941 configuring or displaying this field permits Unicode characters, that 942 user-interface is responsible for applying the ToASCII and/or 943 ToUnicode algorithm as described in [RFC5890] to achieve the correct 944 format for transmission or display. 946 Although [RFC5301] is an IS-IS specific extension, usage of the Node 947 Name TLV is possible for all protocols. How a router derives and 948 injects node names for e.g. OSPF nodes, is outside of the scope of 949 this document. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Type | Length | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 // Node Name (variable) // 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Figure 17: Node Name format 961 3.3.1.4. Local IPv4/IPv6 Router-ID 963 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 964 Router-IDs that the IGP might be using, e.g., for TE and migration 965 purposes like correlating a Node-ID between different protocols. If 966 there is more than one auxiliary Router-ID of a given type, then each 967 one is encoded in its own TLV. 969 3.3.1.5. Opaque Node Attribute TLV 971 The Opaque Node Attribute TLV is an envelope that transparently 972 carries optional node attribute TLVs advertised by a router. An 973 originating router shall use this TLV for encoding information 974 specific to the protocol advertised in the NLRI header Protocol-ID 975 field or new protocol extensions to the protocol as advertised in the 976 NLRI header Protocol-ID field for which there is no protocol neutral 977 representation in the BGP link-state NLRI. The primary use of the 978 Opaque Node Attribute TLV is to bridge the document lag between e.g. 979 a new IGP Link-state attribute being defined and the 'protocol- 980 neutral' BGP-LS extensions being published. A router for example 981 could use this extension in order to advertise the native protocols 982 node attribute TLVs, such as the OSPF Router Informational 983 Capabilities TLV defined in [RFC4970], or the IGP TE Node Capability 984 Descriptor TLV described in [RFC5073]. 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Type | Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 // Opaque node attributes (variable) // 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 Figure 18: Opaque Node attribute format 996 3.3.2. Link Attribute TLVs 998 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 999 attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ 1000 Value (TLV) triplet formatted as defined in Section 3.1. The format 1001 and semantics of the 'value' fields in some 'Link Attribute' TLVs 1002 correspond to the format and semantics of value fields in IS-IS 1003 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 1004 [RFC5307]. Other 'Link Attribute' TLVs are defined in this document. 1005 Although the encodings for 'Link Attribute' TLVs were originally 1006 defined for IS-IS, the TLVs can carry data sourced either by IS-IS or 1007 OSPF. 1009 The following 'Link Attribute' TLVs are valid in the BGP-LS attribute 1010 with a link NLRI: 1012 +-----------+---------------------+--------------+------------------+ 1013 | TLV Code | Description | IS-IS TLV | Defined in: | 1014 | Point | | /Sub-TLV | | 1015 +-----------+---------------------+--------------+------------------+ 1016 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1017 | | Local Node | | | 1018 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1019 | | Local Node | | | 1020 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1021 | | Remote Node | | | 1022 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1023 | | Remote Node | | | 1024 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1025 | | group (color) | | | 1026 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1027 | | bandwidth | | | 1028 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1029 | | link bandwidth | | | 1030 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1031 | | bandwidth | | | 1032 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3/ | 1033 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1034 | | Type | | | 1035 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1036 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1037 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1038 | | Group | | | 1039 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1040 | | attribute | | | 1041 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1042 +-----------+---------------------+--------------+------------------+ 1044 Table 9: Link Attribute TLVs 1046 3.3.2.1. IPv4/IPv6 Router-ID 1048 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1049 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1050 purposes. All auxiliary Router-IDs of both the local and the remote 1051 node MUST be included in the link attribute of each link NLRI. If 1052 there are more than one auxiliary Router-ID of a given type, then 1053 multiple TLVs are used to encode them. 1055 3.3.2.2. MPLS Protocol Mask TLV 1057 The MPLS Protocol Mask TLV carries a bit mask describing which MPLS 1058 signaling protocols are enabled. The length of this TLV is 1. The 1059 value is a bit array of 8 flags, where each bit represents an MPLS 1060 Protocol capability. 1062 >Generation of the MPLS Protocol Mask TLV is only valid for and 1063 SHOULD only be used with originators that have local link insight, 1064 like for example the Protocol-IDs 'Static' or 'Direct' as per 1065 Table 2. The 'MPLS Protocol Mask' TLV MUST NOT be included in NLRIs 1066 with the other Protocol-IDs listed in Table 2. 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Type | Length | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |L|R| Reserved | 1074 +-+-+-+-+-+-+-+-+ 1076 Figure 19: MPLS Protocol Mask TLV 1078 The following bits are defined: 1080 +------------+------------------------------------------+-----------+ 1081 | Bit | Description | Reference | 1082 +------------+------------------------------------------+-----------+ 1083 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1084 | 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] | 1085 | | TE) | | 1086 | 'Reserved' | Reserved for future use | | 1087 +------------+------------------------------------------+-----------+ 1089 Table 10: MPLS Protocol Mask TLV Codes 1091 3.3.2.3. TE Default Metric TLV 1093 The TE Default Metric TLV carries the Traffic Engineering metric for 1094 this link. The length of this TLV is fixed at 4 octets. If a source 1095 protocol uses a Metric width of less than 32 bits then the high order 1096 bits of this field MUST be padded with zero. 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Type | Length | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | TE Default Link Metric | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 20: TE Default Metric TLV format 1108 3.3.2.4. IGP Metric TLV 1110 The IGP Metric TLV carries the metric for this link. The length of 1111 this TLV is variable, depending on the metric width of the underlying 1112 protocol. IS-IS small metrics have a length of 1 octet (the two most 1113 significant bits are ignored). OSPF link metrics have a length of 1114 two octets. IS-IS wide-metrics have a length of three octets. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type | Length | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 // IGP Link Metric (variable length) // 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Figure 21: Metric TLV format 1126 3.3.2.5. Shared Risk Link Group TLV 1128 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1129 Group information (see Section 2.3, "Shared Risk Link Group 1130 Information", of [RFC4202]). It contains a data structure consisting 1131 of a (variable) list of SRLG values, where each element in the list 1132 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1133 (number of SRLG values). 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Type | Length | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Shared Risk Link Group Value | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 // ............ // 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Shared Risk Link Group Value | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 Figure 22: Shared Risk Link Group TLV format 1149 The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS the SRLG 1150 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1151 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1152 defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG 1153 information are carried in a single TLV. 1155 3.3.2.6. Opaque Link Attribute TLV 1157 The Opaque link Attribute TLV is an envelope that transparently 1158 carries optional link attribute TLVs advertised by a router. An 1159 originating router shall use this TLV for encoding information 1160 specific to the protocol advertised in the NLRI header Protocol-ID 1161 field or new protocol extensions to the protocol as advertised in the 1162 NLRI header Protocol-ID field for which there is no protocol neutral 1163 representation in the BGP link-state NLRI. The primary use of the 1164 Opaque Link Attribute TLV is to bridge the document lag between e.g. 1165 a new IGP Link-state attribute being defined and the 'protocol- 1166 neutral' BGP-LS extensions being published. 1168 0 1 2 3 1169 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 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Type | Length | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 // Opaque link attributes (variable) // 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Figure 23: Opaque link attribute format 1178 3.3.2.7. Link Name TLV 1180 The Link Name TLV is optional. The value field identifies the 1181 symbolic name of the router link. This symbolic name can be the FQDN 1182 for the link, it can be a subset of the FQDN, or it can be any string 1183 operators want to use for the link. The use of FQDN or a subset of 1184 it is strongly RECOMMENDED. The maximum length of the 'Link Name 1185 TLV' is 255 octets. 1187 The Value field is encoded in 7-bit ASCII. If a user-interface for 1188 configuring or displaying this field permits Unicode characters, that 1189 user-interface is responsible for applying the ToASCII and/or 1190 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1191 format for transmission or display. 1193 How a router derives and injects link names is outside of the scope 1194 of this document. 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Type | Length | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 // Link Name (variable) // 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 Figure 24: Link Name format 1206 3.3.3. Prefix Attribute TLVs 1208 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1209 of IGP attributes (such as metric, route tags, etc.) that MUST be 1210 reflected into the BGP-LS attribute with a link NLRI. This section 1211 describes the different attributes related to the IPv4/IPv6 prefixes. 1212 Prefix Attributes TLVs SHOULD be used when advertising NLRI types 3 1213 and 4 only. The following attributes TLVs are defined: 1215 +---------------+----------------------+----------+-----------------+ 1216 | TLV Code | Description | Length | Reference | 1217 | Point | | | | 1218 +---------------+----------------------+----------+-----------------+ 1219 | 1152 | IGP Flags | 1 | Section 3.3.3.1 | 1220 | 1153 | Route Tag | 4*n | Section 3.3.3.2 | 1221 | 1154 | Extended Tag | 8*n | Section 3.3.3.3 | 1222 | 1155 | Prefix Metric | 4 | Section 3.3.3.4 | 1223 | 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 | 1224 | | Address | | | 1225 | 1157 | Opaque Prefix | variable | Section 3.3.3.6 | 1226 | | Attribute | | | 1227 +---------------+----------------------+----------+-----------------+ 1229 Table 11: Prefix Attribute TLVs 1231 3.3.3.1. IGP Flags TLV 1233 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1234 assigned to the prefix. The IGP Flags TLV is encoded as follows: 1236 0 1 2 3 1237 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 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | Type | Length | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 |D|N|L|P| Resvd.| 1242 +-+-+-+-+-+-+-+-+ 1244 Figure 25: IGP Flag TLV format 1246 The value field contains bits defined according to the table below: 1248 +----------+---------------------------+-----------+ 1249 | Bit | Description | Reference | 1250 +----------+---------------------------+-----------+ 1251 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1252 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1253 | 'L' | OSPF "local address" Bit | [RFC5340] | 1254 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1255 | Reserved | Reserved for future use. | | 1256 +----------+---------------------------+-----------+ 1258 Table 12: IGP Flag Bits Definitions 1260 3.3.3.2. Route Tag 1262 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1263 the prefix and is encoded as follows: 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Type | Length | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 // Route Tags (one or more) // 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Figure 26: IGP Route TAG TLV format 1275 Length is a multiple of 4. 1277 The value field contains one or more Route Tags as learned in the IGP 1278 topology. 1280 3.3.3.3. Extended Route Tag 1282 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1283 prefix [RFC5130] and is encoded as follows: 1285 0 1 2 3 1286 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 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Type | Length | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 // Extended Route Tag (one or more) // 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Figure 27: Extended IGP Route TAG TLV format 1295 Length is a multiple of 8. 1297 The 'Extended Route Tag' field contains one or more Extended Route 1298 Tags as learned in the IGP topology. 1300 3.3.3.4. Prefix Metric TLV 1302 Prefix Metric TLV is an optional attribute and may only appear once. 1303 If present, it carries the metric of the prefix as known in the IGP 1304 topology as described in Section 4 of [RFC5305] (and therefore 1305 represents the reachability cost to the prefix). If not present, it 1306 means that the prefix is advertised without any reachability. 1308 0 1 2 3 1309 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 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Type | Length | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Metric | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 Figure 28: Prefix Metric TLV Format 1318 Length is 4. 1320 3.3.3.5. OSPF Forwarding Address TLV 1322 OSPF Forwarding Address TLV [RFC2328] and [RFC5340] carries the OSPF 1323 forwarding address as known in the original OSPF advertisement. 1324 Forwarding address can be either IPv4 or IPv6. 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Type | Length | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 // Forwarding Address (variable) // 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 Figure 29: OSPF Forwarding Address TLV Format 1336 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1337 forwarding address. 1339 3.3.3.6. Opaque Prefix Attribute TLV 1341 The Opaque Prefix Attribute TLV is an envelope that transparently 1342 carries optional prefix attribute TLVs advertised by a router. An 1343 originating router shall use this TLV for encoding information 1344 specific to the protocol advertised in the NLRI header Protocol-ID 1345 field or new protocol extensions to the protocol as advertised in the 1346 NLRI header Protocol-ID field for which there is no protocol neutral 1347 representation in the BGP link-state NLRI. The primary use of the 1348 Opaque Prefix Attribute TLV is to bridge the document lag between 1349 e.g. a new IGP Link-state attribute being defined and the 'protocol- 1350 neutral' BGP-LS extensions being published. 1352 The format of the TLV is as follows: 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Type | Length | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 // Opaque Prefix Attributes (variable) // 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 Figure 30: Opaque Prefix Attribute TLV Format 1364 Type is as specified in Table 11 and Length is variable. 1366 3.4. BGP Next Hop Information 1368 BGP link-state information for both IPv4 and IPv6 networks can be 1369 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1370 an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1371 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1372 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 1373 address. Usually the next hop will be set to the local end-point 1374 address of the BGP session. The next hop address MUST be encoded as 1375 described in [RFC4760]. The length field of the next hop address 1376 will specify the next hop address-family. If the next hop length is 1377 4, then the next hop is an IPv4 address; if the next hop length is 1378 16, then it is a global IPv6 address and if the next hop length is 1379 32, then there is one global IPv6 address followed by a link-local 1380 IPv6 address. The link-local IPv6 address should be used as 1381 described in [RFC2545]. For VPN SAFI, as per custom, an 8 byte 1382 route-distinguisher set to all zero is prepended to the next hop. 1384 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1385 the NLRI it receives. In case identical NLRIs are sourced by 1386 multiple originators the BGP next hop attribute is used to tie-break 1387 as per the standard BGP path decision process. This specification 1388 doesn't mandate any rule regarding the re-write of the BGP Next Hop 1389 attribute. 1391 3.5. Inter-AS Links 1393 The main source of TE information is the IGP, which is not active on 1394 inter-AS links. In some cases, the IGP may have information of 1395 inter-AS links ([RFC5392], [RFC5316]). In other cases, an 1396 implementation SHOULD provide a means to inject inter-AS links into 1397 BGP-LS. The exact mechanism used to provision the inter-AS links is 1398 outside the scope of this document 1400 3.6. Router-ID Anchoring Example: ISO Pseudonode 1402 Encoding of a broadcast LAN in IS-IS provides a good example of how 1403 Router-IDs are encoded. Consider Figure 31. This represents a 1404 Broadcast LAN between a pair of routers. The "real" (=non 1405 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1406 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1407 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1408 (Pseudonode1, Node2) are being generated. 1410 The link NLRI of (Node1, Pseudonode1) is encoded as follows: the IGP 1411 Router-ID TLV of the local node descriptor is 6 octets long 1412 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1413 the remote node descriptor is 7 octets long containing the ISO-ID of 1414 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1415 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1416 192.0.2.1, the IPv4 Router-ID of Node1. 1418 The link NLRI of (Pseudonode1. Node2) is encoded as follows: the IGP 1419 Router-ID TLV of the local node descriptor is 7 octets long 1420 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1421 Router-ID TLV of the remote node descriptor is 6 octets long 1422 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1423 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1424 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1426 +-----------------+ +-----------------+ +-----------------+ 1427 | Node1 | | Pseudonode1 | | Node2 | 1428 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1429 | 192.0.2.1 | | | | 192.0.2.2 | 1430 +-----------------+ +-----------------+ +-----------------+ 1432 Figure 31: IS-IS Pseudonodes 1434 3.7. Router-ID Anchoring Example: OSPF Pseudonode 1436 Encoding of a broadcast LAN in OSPF provides a good example of how 1437 Router-IDs and local Interface IPs are encoded. Consider Figure 32. 1438 This represents a Broadcast LAN between a pair of routers. The 1439 "real" (=non pseudonode) routers have both an IPv4 Router-ID and an 1440 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1441 interface Address (for disambiguation) and an OSPF Area. Node1 is 1442 the DR for the LAN, hence its local IP address 10.1.1.1 is used both 1443 as the Router-ID and Interface IP for the Pseudonode keys. Two 1444 unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2) 1445 are being generated. 1447 The link NLRI of (Node1, Pseudonode1) is encoded as follows: 1449 o Local Node Descriptor 1451 TLV #515: IGP Router ID: 11.11.11.11 1453 TLV #514: OSPF Area-ID: ID:0.0.0.0 1455 o Remote Node Descriptor 1457 TLV #515: IGP Router ID: 11.11.11.11:10.1.1.1 1459 TLV #514: OSPF Area-ID: ID:0.0.0.0 1461 The link NLRI of (Pseudonode1, Node2) is encoded as follows: 1463 o Local Node Descriptor 1465 TLV #515: IGP Router ID: 11.11.11.11:10.1.1.1 1467 TLV #514: OSPF Area-ID: ID:0.0.0.0 1469 o Remote Node Descriptor 1470 TLV #515: IGP Router ID: 33.33.33.34 1472 TLV #514: OSPF Area-ID: ID:0.0.0.0 1474 +-----------------+ +-----------------+ +-----------------+ 1475 | Node1 | | Pseudonode1 | | Node2 | 1476 | 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 | 1477 | | | 10.1.1.1 | | | 1478 | Area 0 | | Area 0 | | Area 0 | 1479 +-----------------+ +-----------------+ +-----------------+ 1481 Figure 32: OSPF Pseudonodes 1483 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1485 Graceful migration from one IGP to another requires coordinated 1486 operation of both protocols during the migration period. Such a 1487 coordination requires identifying a given physical link in both IGPs. 1488 The IPv4 Router-ID provides that "glue" which is present in the node 1489 descriptors of the OSPF link NLRI and in the link attribute of the 1490 IS-IS link NLRI. 1492 Consider a point-to-point link between two routers, A and B, that 1493 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1494 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1495 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1496 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1497 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1498 in the local and remote node descriptors, respectively. The IS-IS 1499 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1500 the local and remote node descriptors, respectively. In addition, 1501 the BGP-LS attribute of the IS-IS link NLRI contains the TLV type 1502 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1503 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1504 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1505 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1507 4. Link to Path Aggregation 1509 Distribution of all links available in the global Internet is 1510 certainly possible, however not desirable from a scaling and privacy 1511 point of view. Therefore an implementation may support link to path 1512 aggregation. Rather than advertising all specific links of a domain, 1513 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1514 of nodes. The "aggregate link" represents the aggregated set of link 1515 properties between a pair of non-adjacent nodes. The actual methods 1516 to compute the path properties (of bandwidth, metric) are outside the 1517 scope of this document. The decision whether to advertise all 1518 specific links or aggregated links is an operator's policy choice. 1519 To highlight the varying levels of exposure, the following deployment 1520 examples are discussed. 1522 4.1. Example: No Link Aggregation 1524 Consider Figure 33. Both AS1 and AS2 operators want to protect their 1525 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1526 compute its link-protection LSP to R3 it needs to "see" an alternate 1527 path to R3. Therefore the AS2 operator exposes its topology. All 1528 BGP TE enabled routers in AS1 "see" the full topology of AS2 and 1529 therefore can compute a backup path. Note that the decision if the 1530 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1531 by the computing router. 1533 AS1 : AS2 1534 : 1535 R1-------R3 1536 | : | \ 1537 | : | R5 1538 | : | / 1539 R2-------R4 1540 : 1541 : 1543 Figure 33: No link aggregation 1545 4.2. Example: ASBR to ASBR Path Aggregation 1547 The brief difference between the "no-link aggregation" example and 1548 this example is that no specific link gets exposed. Consider 1549 Figure 34. The only link which gets advertised by AS2 is an 1550 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1551 there is a backup path. However the actual links being used are 1552 hidden from the topology. 1554 AS1 : AS2 1555 : 1556 R1-------R3 1557 | : | 1558 | : | 1559 | : | 1560 R2-------R4 1561 : 1562 : 1564 Figure 34: ASBR link aggregation 1566 4.3. Example: Multi-AS Path Aggregation 1568 Service providers in control of multiple ASes may even decide to not 1569 expose their internal inter-AS links. Consider Figure 35. AS3 is 1570 modeled as a single node which connects to the border routers of the 1571 aggregated domain. 1573 AS1 : AS2 : AS3 1574 : : 1575 R1-------R3----- 1576 | : : \ 1577 | : : vR0 1578 | : : / 1579 R2-------R4----- 1580 : : 1581 : : 1583 Figure 35: Multi-AS aggregation 1585 5. IANA Considerations 1587 This document is the reference for Address Family Number 16388, 'BGP- 1588 LS'. 1590 This document requests code point 71 from the registry of Subsequent 1591 Address Family Numbers named 'BGP-LS'. 1593 This document requests a code point from the registry of Subsequent 1594 Address Family Numbers named 'BGP-LS-VPN'. The SAFI assignment does 1595 not need to be out of the range 1-63 and may come out of the "First 1596 Come First Served" range 128-240. 1598 This document requests a code point from the BGP Path Attributes 1599 registry. As per early allocation procedure this is Path Attribute 1600 29. 1602 All the following Registries are BGP-LS specific and shall be 1603 accessible under the following URL: "http://www.iana.org/assignments/ 1604 bgp-ls-parameters" Title "Border Gateway Protocol - Link State (BGP- 1605 LS) Parameters" 1607 This document requests creation of a new registry for BGP-LS NLRI- 1608 Types. Value 0 is reserved. The maximum value is 65535. The 1609 registry will be initialized as shown in Table 1. Allocations within 1610 the registry will require documentation of the proposed use of the 1611 allocated value (=Specification required) and approval by the 1612 Designated Expert assigned by the IESG (see [RFC5226]). 1614 This document requests creation of a new registry for BGP-LS 1615 Protocol-IDs. Value 0 is reserved. The maximum value is 255. The 1616 registry will be initialized as shown in Table 2. Allocations within 1617 the registry will require documentation of the proposed use of the 1618 allocated value (=Specification required) and approval by the 1619 Designated Expert assigned by the IESG (see [RFC5226]). 1621 This document requests creation of a new registry for BGP-LS Well- 1622 known Instance-IDs. The registry will be initialized as shown in 1623 Table 3. Allocations within the registry will require documentation 1624 of the proposed use of the allocated value (=Specification required) 1625 and approval by the Designated Expert assigned by the IESG (see 1626 [RFC5226]). 1628 This document requests creation of a new registry for node anchor, 1629 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1630 Values 256-65535 will be used for code points. The registry will be 1631 initialized as shown in Table 13. Allocations within the registry 1632 will require documentation of the proposed use of the allocated value 1633 (=Specification required) and approval by the Designated Expert 1634 assigned by the IESG (see [RFC5226]). 1636 5.1. Guidance for Designated Experts 1638 In all cases of review by Designated Expert (DE) described here, the 1639 DE is expected to ascertain the existence of suitable documentation 1640 (a specification) as described in [RFC5226], and to verify the 1641 permanent and publically ready availability of the document. The DE 1642 is also expected to check the clarity of purpose and use of the 1643 requested code points. Lastly, the DE must verify that any 1644 specification produced in the IETF that requests one of these code 1645 points has been made available for review by the IDR working group, 1646 and that any specification produced outside the IETF does not 1647 conflict with work that is active or already published within the 1648 IETF. 1650 6. Manageability Considerations 1652 This section is structured as recommended in [RFC5706]. 1654 6.1. Operational Considerations 1656 6.1.1. Operations 1658 Existing BGP operational procedures apply. No new operation 1659 procedures are defined in this document. It is noted that the NLRI 1660 information present in this document purely carries application level 1661 data that has no immediate corresponding forwarding state impact. As 1662 such, any churn in reachability information has different impact than 1663 regular BGP updates which need to change forwarding state for an 1664 entire router. Furthermore it is anticipated that distribution of 1665 this NLRI will be handled by dedicated route-reflectors providing a 1666 level of isolation and fault-containment between different NLRI 1667 types. 1669 6.1.2. Installation and Initial Setup 1671 Configuration parameters defined in Section 6.2.3 SHOULD be 1672 initialized to the following default values: 1674 o The Link-State NLRI capability is turned off for all neighbors. 1676 o The maximum rate at which Link-State NLRIs will be advertised/ 1677 withdrawn from neighbors is set to 200 updates per second. 1679 6.1.3. Migration Path 1681 The proposed extension is only activated between BGP peers after 1682 capability negotiation. Moreover, the extensions can be turned on/ 1683 off an individual peer basis (see Section 6.2.3), so the extension 1684 can be gradually rolled out in the network. 1686 6.1.4. Requirements on Other Protocols and Functional Components 1688 The protocol extension defined in this document does not put new 1689 requirements on other protocols or functional components. 1691 6.1.5. Impact on Network Operation 1693 Frequency of Link-State NLRI updates could interfere with regular BGP 1694 prefix distribution. A network operator MAY use a dedicated Route- 1695 Reflector infrastructure to distribute Link-State NLRIs. 1697 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1698 domain, which can consist of multiple areas within an AS or multiple 1699 ASes. 1701 6.1.6. Verifying Correct Operation 1703 Existing BGP procedures apply. In addition, an implementation SHOULD 1704 allow an operator to: 1706 o List neighbors with whom the Speaker is exchanging Link-State 1707 NLRIs 1709 6.2. Management Considerations 1711 6.2.1. Management Information 1713 The IDR working group has documented and continues to document parts 1714 of the Management Information Base and YANG models for managing and 1715 monitoring BGP speakers and the sessions between them. It is 1716 currently believed that the BGP session running BGP-LS is not 1717 substantially different from any other BGP session and can be managed 1718 using the same data models. 1720 6.2.2. Fault Management 1722 If an implementation of BGP-LS detects a malformed attribute, then it 1723 MUST use the 'Attribute Discard' action as per [RFC7606] Section 2. 1725 An implementation of BGP-LS MUST perform the following syntactic 1726 checks for determining if a message is malformed. 1728 o Does the sum of all TLVs found in the BGP LS attribute correspond 1729 to the BGP LS path attribute length? 1731 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 1732 correspond to the BGP MP_REACH_NLRI length? 1734 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 1735 attribute correspond to the BGP MP_UNREACH_NLRI length? 1737 o Does the sum of all TLVs found in a Node-, Link or Prefix 1738 Descriptor NLRI attribute correspond to the Node-, Link- or Prefix 1739 Descriptors 'Total NLRI Length' field? 1741 o Does any fixed length TLV correspond to the TLV Length field in 1742 this document? 1744 6.2.3. Configuration Management 1746 An implementation SHOULD allow the operator to specify neighbors to 1747 which Link-State NLRIs will be advertised and from which Link-State 1748 NLRIs will be accepted. 1750 An implementation SHOULD allow the operator to specify the maximum 1751 rate at which Link-State NLRIs will be advertised/withdrawn from 1752 neighbors. 1754 An implementation SHOULD allow the operator to specify the maximum 1755 number of Link-State NLRIs stored in router's RIB. 1757 An implementation SHOULD allow the operator to create abstracted 1758 topologies that are advertised to neighbors; Create different 1759 abstractions for different neighbors. 1761 An implementation SHOULD allow the operator to configure a 64-bit 1762 instance ID. 1764 An implementation SHOULD allow the operator to configure a pair of 1765 ASN and BGP-LS identifier (Section 3.2.1.4) per flooding set in which 1766 the node participates. 1768 6.2.4. Accounting Management 1770 Not Applicable. 1772 6.2.5. Performance Management 1774 An implementation SHOULD provide the following statistics: 1776 o Total number of Link-State NLRI updates sent/received 1778 o Number of Link-State NLRI updates sent/received, per neighbor 1780 o Number of errored received Link-State NLRI updates, per neighbor 1782 o Total number of locally originated Link-State NLRIs 1784 These statistics should be recorded as absolute counts since system 1785 or session start time. An implementation MAY also enhance this 1786 information by also recording peak per-second counts in each case. 1788 6.2.6. Security Management 1790 An operator SHOULD define an import policy to limit inbound updates 1791 as follows: 1793 o Drop all updates from Consumer peers 1795 An implementation MUST have means to limit inbound updates. 1797 7. TLV/Sub-TLV Code Points Summary 1799 This section contains the global table of all TLVs/Sub-TLVs defined 1800 in this document. 1802 +-----------+---------------------+---------------+-----------------+ 1803 | TLV Code | Description | IS-IS TLV/ | Value defined | 1804 | Point | | Sub-TLV | in: | 1805 +-----------+---------------------+---------------+-----------------+ 1806 | 256 | Local Node | --- | Section 3.2.1.2 | 1807 | | Descriptors | | | 1808 | 257 | Remote Node | --- | Section 3.2.1.3 | 1809 | | Descriptors | | | 1810 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1811 | | Identifiers | | | 1812 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1813 | | address | | | 1814 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1815 | | address | | | 1816 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1817 | | address | | | 1818 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1819 | | address | | | 1820 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1821 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1822 | 265 | IP Reachability | --- | Section 3.2.3 | 1823 | | Information | | | 1824 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1825 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1826 | 514 | OSPF Area ID | --- | Section 3.2.1.4 | 1827 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1828 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1829 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1830 | | Properties | | | 1831 | 1026 | Node Name | variable | Section 3.3.1.3 | 1832 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1833 | | Identifier | | | 1834 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1835 | | Local Node | | | 1836 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1837 | | Local Node | | | 1838 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1839 | | Remote Node | | | 1840 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1841 | | Remote Node | | | 1842 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1843 | | group (color) | | | 1844 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1845 | | bandwidth | | | 1846 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1847 | | link bandwidth | | | 1848 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1849 | | bandwidth | | | 1850 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | 1851 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1852 | | Type | | | 1853 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1854 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1855 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1856 | | Group | | | 1857 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1858 | | attribute | | | 1859 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1860 | 1152 | IGP Flags | --- | Section 3.3.3.1 | 1861 | 1153 | Route Tag | --- | [RFC5130] | 1862 | 1154 | Extended Tag | --- | [RFC5130] | 1863 | 1155 | Prefix Metric | --- | [RFC5305] | 1864 | 1156 | OSPF Forwarding | --- | [RFC2328] | 1865 | | Address | | | 1866 | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | 1867 | | Attribute | | | 1868 +-----------+---------------------+---------------+-----------------+ 1870 Table 13: Summary Table of TLV/Sub-TLV code points 1872 8. Security Considerations 1874 Procedures and protocol extensions defined in this document do not 1875 affect the BGP security model. See the 'Security Considerations' 1876 section of [RFC4271] for a discussion of BGP security. Also refer to 1877 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 1879 In the context of the BGP peerings associated with this document, a 1880 BGP Speaker MUST NOT accept updates from a Consumer peer. That is, a 1881 participating BGP Speaker, should be aware of the nature of its 1882 relationships for link state relationships and should protect itself 1883 from peers sending updates that either represent erroneous 1884 information feedback loops, or are false input. Such protection can 1885 be achieved by manual configuration of Consumer peers at the BGP 1886 Speaker. 1888 An operator SHOULD employ a mechanism to protect a BGP Speaker 1889 against DDoS attacks from Consumers. The principal attack a consumer 1890 may apply is to attempt to start multiple sessions either 1891 sequentially or simultaneously. Protection can be applied by 1892 imposing rate limits. 1894 Additionally, it may be considered that the export of link state and 1895 TE information as described in this document constitutes a risk to 1896 confidentiality of mission-critical or commercially-sensitive 1897 information about the network. BGP peerings are not automatic and 1898 require configuration, thus it is the responsibility of the network 1899 operator to ensure that only trusted Consumers are configured to 1900 receive such information. 1902 9. Contributors 1904 We would like to thank Robert Varga for the significant contribution 1905 he gave to this document. 1907 10. Acknowledgements 1909 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1910 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1911 Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, 1912 Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas 1913 Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, 1914 Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and 1915 Ben Campbell for their comments. 1917 11. References 1919 11.1. Normative References 1921 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1922 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1923 December 1990, . 1925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1926 Requirement Levels", BCP 14, RFC 2119, 1927 DOI 10.17487/RFC2119, March 1997, 1928 . 1930 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1931 DOI 10.17487/RFC2328, April 1998, 1932 . 1934 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1935 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1936 DOI 10.17487/RFC2545, March 1999, 1937 . 1939 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1940 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1941 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1942 . 1944 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1945 in Support of Generalized Multi-Protocol Label Switching 1946 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1947 . 1949 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1950 Support of Generalized Multi-Protocol Label Switching 1951 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1952 . 1954 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1955 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1956 DOI 10.17487/RFC4271, January 2006, 1957 . 1959 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1960 "Multiprotocol Extensions for BGP-4", RFC 4760, 1961 DOI 10.17487/RFC4760, January 2007, 1962 . 1964 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1965 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1966 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1967 . 1969 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1970 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1971 October 2007, . 1973 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1974 Topology (MT) Routing in Intermediate System to 1975 Intermediate Systems (IS-ISs)", RFC 5120, 1976 DOI 10.17487/RFC5120, February 2008, 1977 . 1979 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy 1980 Control Mechanism in IS-IS Using Administrative Tags", 1981 RFC 5130, DOI 10.17487/RFC5130, February 2008, 1982 . 1984 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1985 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1986 DOI 10.17487/RFC5226, May 2008, 1987 . 1989 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1990 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 1991 October 2008, . 1993 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1994 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1995 2008, . 1997 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1998 in Support of Generalized Multi-Protocol Label Switching 1999 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 2000 . 2002 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2003 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2004 . 2006 [RFC5890] Klensin, J., "Internationalized Domain Names for 2007 Applications (IDNA): Definitions and Document Framework", 2008 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2009 . 2011 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 2012 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 2013 February 2011, . 2015 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 2016 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 2017 June 2011, . 2019 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 2020 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 2021 March 2012, . 2023 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 2024 Ward, "IS-IS Multi-Instance", RFC 6822, 2025 DOI 10.17487/RFC6822, December 2012, 2026 . 2028 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2029 Patel, "Revised Error Handling for BGP UPDATE Messages", 2030 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2031 . 2033 11.2. Informative References 2035 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2036 and E. Lear, "Address Allocation for Private Internets", 2037 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2038 . 2040 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 2041 RFC 4272, DOI 10.17487/RFC4272, January 2006, 2042 . 2044 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2045 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2046 2006, . 2048 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2049 Element (PCE)-Based Architecture", RFC 4655, 2050 DOI 10.17487/RFC4655, August 2006, 2051 . 2053 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 2054 S. Shaffer, "Extensions to OSPF for Advertising Optional 2055 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 2056 2007, . 2058 [RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing 2059 Protocol Extensions for Discovery of Traffic Engineering 2060 Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, 2061 December 2007, . 2063 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 2064 Per-Domain Path Computation Method for Establishing Inter- 2065 Domain Traffic Engineering (TE) Label Switched Paths 2066 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 2067 . 2069 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 2070 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2071 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 2072 December 2008, . 2074 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 2075 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2076 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 2077 January 2009, . 2079 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2080 Optimization (ALTO) Problem Statement", RFC 5693, 2081 DOI 10.17487/RFC5693, October 2009, 2082 . 2084 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 2085 Management of New Protocols and Protocol Extensions", 2086 RFC 5706, DOI 10.17487/RFC5706, November 2009, 2087 . 2089 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2090 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2091 and Authentication for Routing Protocols (KARP) Design 2092 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2093 . 2095 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 2096 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 2097 "Application-Layer Traffic Optimization (ALTO) Protocol", 2098 RFC 7285, DOI 10.17487/RFC7285, September 2014, 2099 . 2101 Authors' Addresses 2103 Hannes Gredler (editor) 2104 Private Contributor 2106 Email: hannes@gredler.at 2108 Jan Medved 2109 Cisco Systems, Inc. 2110 170, West Tasman Drive 2111 San Jose, CA 95134 2112 US 2114 Email: jmedved@cisco.com 2116 Stefano Previdi 2117 Cisco Systems, Inc. 2118 Via Del Serafico, 200 2119 Rome 00142 2120 Italy 2122 Email: sprevidi@cisco.com 2124 Adrian Farrel 2125 Juniper Networks, Inc. 2127 Email: adrian@olddog.co.uk 2129 Saikat Ray 2131 Email: raysaikat@gmail.com