idnits 2.17.1 draft-ietf-idr-ls-distribution-06.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 (September 16, 2014) is 3503 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 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: March 20, 2015 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 Cisco Systems, Inc. 11 September 16, 2014 13 North-Bound Distribution of Link-State and TE Information using BGP 14 draft-ietf-idr-ls-distribution-06 16 Abstract 18 In a number of environments, a component external to a network is 19 called upon to perform computations based on the network topology and 20 current state of the connections within the network, including 21 traffic engineering information. This is information typically 22 distributed by IGP routing protocols within the network. 24 This document describes a mechanism by which links state and traffic 25 engineering information can be collected from networks and shared 26 with external components using the BGP routing protocol. This is 27 achieved using a new BGP Network Layer Reachability Information 28 (NLRI) encoding format. The mechanism is applicable to physical and 29 virtual IGP links. The mechanism described is subject to policy 30 control. 32 Applications of this technique include Application Layer Traffic 33 Optimization (ALTO) servers, and Path Computation Elements (PCEs). 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on March 20, 2015. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 77 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 78 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6 79 3. Carrying Link State Information in BGP . . . . . . . . . . . 7 80 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8 82 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 12 83 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 16 84 3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 17 85 3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 19 86 3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19 87 3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 22 88 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 27 89 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 30 90 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 31 91 3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 31 92 3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 32 93 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 33 94 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 33 95 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 34 96 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 34 97 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 35 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 99 6. Manageability Considerations . . . . . . . . . . . . . . . . 36 100 6.1. Operational Considerations . . . . . . . . . . . . . . . 36 101 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 36 102 6.1.2. Installation and Initial Setup . . . . . . . . . . . 36 103 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 36 104 6.1.4. Requirements on Other Protocols and Functional 105 Components . . . . . . . . . . . . . . . . . . . . . 37 106 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 37 107 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 37 108 6.2. Management Considerations . . . . . . . . . . . . . . . . 37 109 6.2.1. Management Information . . . . . . . . . . . . . . . 37 110 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 37 111 6.2.3. Configuration Management . . . . . . . . . . . . . . 37 112 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 38 113 6.2.5. Performance Management . . . . . . . . . . . . . . . 38 114 6.2.6. Security Management . . . . . . . . . . . . . . . . . 38 115 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 38 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 117 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 120 11.1. Normative References . . . . . . . . . . . . . . . . . . 41 121 11.2. Informative References . . . . . . . . . . . . . . . . . 43 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 124 1. Introduction 126 The contents of a Link State Database (LSDB) or a Traffic Engineering 127 Database (TED) has the scope of an IGP area. Some applications, such 128 as end-to-end Traffic Engineering (TE), would benefit from visibility 129 outside one area or Autonomous System (AS) in order to make better 130 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 [I-D.ietf-alto-protocol]. 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 are 349 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. All TLVs that are not specified as mandatory are considered 354 optional. 356 3.2. The Link-State NLRI 358 The MP_REACH and MP_UNREACH attributes are BGP's containers for 359 carrying opaque information. Each Link-State NLRI describes either a 360 node, a link or a prefix. 362 All non-VPN link, node and prefix information SHALL be encoded using 363 AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be 364 encoded using AFI 16388 / SAFI 128. 366 In order for two BGP speakers to exchange Link-State NLRI, they MUST 367 use BGP Capabilities Advertisement to ensure that they both are 368 capable of properly processing such NLRI. This is done as specified 369 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 370 an AFI 16388 / SAFI 71 and AFI 16388 / SAFI 128 for the VPN flavor. 372 The format of the Link-State NLRI is shown in the following figure. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | NLRI Type | Total NLRI Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 // Link-State NLRI (variable) // 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | NLRI Type | Total NLRI Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 + Route Distinguisher + 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 // Link-State NLRI (variable) // 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 6: Link-State VPN AFI 16388 / SAFI 128 NLRI Format 402 The 'Total NLRI Length' field contains the cumulative length, in 403 octets, of rest of the NLRI not including the NLRI Type field or 404 itself. For VPN applications, it also includes the length of the 405 Route Distinguisher. 407 +------+---------------------------+ 408 | Type | NLRI Type | 409 +------+---------------------------+ 410 | 1 | Node NLRI | 411 | 2 | Link NLRI | 412 | 3 | IPv4 Topology Prefix NLRI | 413 | 4 | IPv6 Topology Prefix NLRI | 414 +------+---------------------------+ 416 Table 1: NLRI Types 418 The Node NLRI (NLRI Type = 1) is shown in the following figure. 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+ 423 | Protocol-ID | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Identifier | 426 | (64 bits) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 // Local Node Descriptors (variable) // 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 7: The Node NLRI format 433 The Link NLRI (NLRI Type = 2) is shown in the following figure. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+ 438 | Protocol-ID | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Identifier | 441 | (64 bits) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 // Local Node Descriptors (variable) // 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 // Remote Node Descriptors (variable) // 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 // Link Descriptors (variable) // 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 8: The Link NLRI format 452 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 453 same format as shown in the following figure. 455 0 1 2 3 456 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 457 +-+-+-+-+-+-+-+-+ 458 | Protocol-ID | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Identifier | 461 | (64 bits) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 // Local Node Descriptor (variable) // 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 // Prefix Descriptors (variable) // 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 9: The IPv4/IPv6 Topology Prefix NLRI format 470 The 'Protocol-ID' field can contain one of the following values: 472 +-------------+----------------------------------+ 473 | Protocol-ID | NLRI information source protocol | 474 +-------------+----------------------------------+ 475 | 1 | IS-IS Level 1 | 476 | 2 | IS-IS Level 2 | 477 | 3 | OSPFv2 | 478 | 4 | Direct | 479 | 5 | Static configuration | 480 | 6 | OSPFv3 | 481 +-------------+----------------------------------+ 483 Table 2: Protocol Identifiers 485 Both OSPF and IS-IS may run multiple routing protocol instances over 486 the same link. See [RFC6822] and [RFC6549]. These instances define 487 independent "routing universes". The 64-Bit 'Identifier' field is 488 used to identify the "routing universe" where the NLRI belongs. The 489 NLRIs representing IGP objects (nodes, links or prefixes) from the 490 same routing universe MUST have the same 'Identifier' value; NLRIs 491 with different 'Identifier' values MUST be considered to be from 492 different routing universes. Table Table 3 lists the 'Identifier' 493 values that are defined as well-known in this draft. 495 +------------+---------------------+ 496 | Identifier | Routing Universe | 497 +------------+---------------------+ 498 | 0 | L3 packet topology | 499 | 1 | L1 optical topology | 500 +------------+---------------------+ 502 Table 3: Well-known Instance Identifiers 504 Each Node Descriptor and Link Descriptor consists of one or more TLVs 505 described in the following sections. 507 3.2.1. Node Descriptors 509 Each link is anchored by a pair of Router-IDs that are used by the 510 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 511 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 512 additional auxiliary Router-IDs, mainly for traffic engineering 513 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 514 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 515 included in the link attribute described in Section Section 3.3.2. 517 It is desirable that the Router-ID assignments inside the Node 518 Descriptor are globally unique. However there may be Router-ID 519 spaces (e.g. ISO) where no global registry exists, or worse, Router- 520 IDs have been allocated following private-IP RFC 1918 [RFC1918] 521 allocation. We use Autonomous System (AS) Number and BGP-LS 522 Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as 523 described in Section 3.2.1.1. 525 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 527 One problem that needs to be addressed is the ability to identify an 528 IGP node globally (by "global", we mean within the BGP-LS database 529 collected by all BGP-LS speakers that talk to each other). This can 530 be expressed through the following two requirements: 532 (A) The same node must not be represented by two keys (otherwise one 533 node will look like two nodes). 535 (B) Two different nodes must not be represented by the same key 536 (otherwise, two nodes will look like one node). 538 We define an "IGP domain" to be the set of nodes (hence, by extension 539 links and prefixes), within which, each node has a unique IGP 540 representation by using the combination of Area-ID, Router-ID, 541 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 542 receive node/link/prefix information from multiple independent "IGP 543 domains" and we need to distinguish between them. Moreover, we can't 544 assume there is always one and only one IGP domain per AS. During 545 IGP transitions it may happen that two redundant IGPs are in place. 547 In section Section 3.2.1.4 a set of sub-TLVs is described, which 548 allows specification of a flexible key for any given Node/Link 549 information such that global uniqueness of the NLRI is ensured. 551 3.2.1.2. Local Node Descriptors 553 The Local Node Descriptors TLV contains Node Descriptors for the node 554 anchoring the local end of the link. This is a mandatory TLV in all 555 three types of NLRIs. The length of this TLV is variable. The value 556 contains one or more Node Descriptor Sub-TLVs defined in 557 Section 3.2.1.4. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 // Node Descriptor Sub-TLVs (variable) // 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 10: Local Node Descriptors TLV format 571 3.2.1.3. Remote Node Descriptors 573 The Remote Node Descriptors contains Node Descriptors for the node 574 anchoring the remote end of the link. This is a mandatory TLV for 575 link NLRIs. The length of this TLV is variable. The value contains 576 one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type | Length | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | | 584 // Node Descriptor Sub-TLVs (variable) // 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 11: Remote Node Descriptors TLV format 590 3.2.1.4. Node Descriptor Sub-TLVs 592 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 593 the following table: 595 +--------------------+-------------------+----------+ 596 | Sub-TLV Code Point | Description | Length | 597 +--------------------+-------------------+----------+ 598 | 512 | Autonomous System | 4 | 599 | 513 | BGP-LS Identifier | 4 | 600 | 514 | OSPF Area-ID | 4 | 601 | 515 | IGP Router-ID | Variable | 602 +--------------------+-------------------+----------+ 604 Table 4: Node Descriptor Sub-TLVs 606 The sub-TLV values in Node Descriptor TLVs are defined as follows: 608 Autonomous System: opaque value (32 Bit AS Number) 610 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 611 ASN, uniquely identifies the BGP-LS domain. The combination of 612 ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers 613 within an IGP flooding-set (set of IGP nodes within which an LSP/ 614 LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP 615 domain consists of multiple flooding-sets, then all BGP-LS 616 speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID 617 tuple. The ASN, BGP Router-ID tuple (which is globally unique 618 [RFC6286] ) of one of the BGP-LS speakers within the flooding-set 619 (or IGP domain) may be used for all BGP-LS speakers in that 620 flooding-set (or IGP domain). 622 Area ID: It is used to identify the 32 Bit area to which the NLRI 623 belongs. Area Identifier allows the different NLRIs of the same 624 router to be discriminated. 626 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 627 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 628 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 629 octet ISO node-ID of the "Designated Intermediate System" (DIS) 630 followed by one octet nonzero PSN identifier (7 octets in total). 631 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 632 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, 633 this contains the 4 octet Router-ID of the designated router (DR) 634 followed by the 4 octet IPv4 address of the DR's interface to the 635 LAN (8 octets in total). Similarly, for an OSPFv3 "Pseudonode", 636 this contains the 4 octet Router-ID of the DR followed by the 4 637 octet interface identifier of the DR's interface to the LAN (8 638 octets in total). The TLV size in combination with protocol 639 identifier enables the decoder to determine the type of the node. 641 There can be at most one instance of each sub-TLV type present in 642 any Node Descriptor. The sub-TLVs within a Node descriptor MUST 643 be arranged in ascending order by sub-TLV type. This needs to be 644 done in order to compare NLRIs, even when an implementation 645 encounters an unknown sub-TLV. Using stable sorting an 646 implementation can do binary comparison of NLRIs and hence allow 647 incremental deployment of new key sub-TLVs. 649 3.2.1.5. Multi-Topology ID 651 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 652 Multi-Topology IDs for a link, node or prefix. 654 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 655 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 656 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 657 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 658 SHOULD be set to 0 when originated and ignored on receipt. 660 The format of the MT-ID TLV is shown in the following figure. 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Type | Length=2*n | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |R R R R| Multi-Topology ID 1 | .... // 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 // .... |R R R R| Multi-Topology ID n | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Figure 12: Multi-Topology ID TLV format 674 where Type is 263, Length is 2*n and n is the number of MT-IDs 675 carried in the TLV. 677 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 678 Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or 679 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 680 the topology where the link or the prefix is reachable is allowed. 681 In case one wants to advertise multiple topologies for a given Link 682 Descriptor or Prefix Descriptor, multiple NRLIs need to be generated 683 where each NLRI contains an unique MT-ID. In the BGP-LS attribute of 684 a node NLRI, one MT-ID TLV containing the array of MT-IDs of all 685 topologies where the node is reachable is allowed. 687 3.2.2. Link Descriptors 689 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 690 triplets. The format of each TLV is shown in Section 3.1. The 'Link 691 descriptor' TLVs uniquely identify a link among multiple parallel 692 links between a pair of anchor routers. A link described by the Link 693 descriptor TLVs actually is a "half-link", a unidirectional 694 representation of a logical link. In order to fully describe a 695 single logical link, two originating routers advertise a half-link 696 each, i.e., two link NLRIs are advertised for a given point-to-point 697 link. 699 The format and semantics of the 'value' fields in most 'Link 700 Descriptor' TLVs correspond to the format and semantics of value 701 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 702 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 703 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 704 carry data sourced either by IS-IS or OSPF. 706 The following TLVs are valid as Link Descriptors in the Link NLRI: 708 +-----------+---------------------+---------------+-----------------+ 709 | TLV Code | Description | IS-IS TLV | Value defined | 710 | Point | | /Sub-TLV | in: | 711 +-----------+---------------------+---------------+-----------------+ 712 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 713 | | Identifiers | | | 714 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 715 | | address | | | 716 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 717 | | address | | | 718 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 719 | | address | | | 720 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 721 | | address | | | 722 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 723 | | Identifier | | | 724 +-----------+---------------------+---------------+-----------------+ 726 Table 5: Link Descriptor TLVs 728 The information about a link present in the LSA/LSP originated by the 729 local node of the link determines the set of TLVs in the Link 730 Descriptor of the link. 732 If interface and neighbor addresses, either IPv4 or IPv6, are 733 present, then the IP address TLVs are included in the link 734 descriptor, but not the link local/remote Identifier TLV. The 735 link local/remote identifiers MAY be included in the link 736 attribute. 738 If interface and neighbor addresses are not present and the link 739 local/remote identifiers are present, then the link local/remote 740 Identifier TLV is included in the link descriptor. 742 The Multi-Topology Identifier TLV is included in link descriptor 743 if that information is present. 745 3.2.3. Prefix Descriptors 747 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 748 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 749 Prefix originated by a Node. The following TLVs are valid as Prefix 750 Descriptors in the IPv4/IPv6 Prefix NLRI: 752 +--------------+-----------------------+----------+-----------------+ 753 | TLV Code | Description | Length | Value defined | 754 | Point | | | in: | 755 +--------------+-----------------------+----------+-----------------+ 756 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 757 | | Identifier | | | 758 | 264 | OSPF Route Type | 1 | Section 3.2.3.1 | 759 | 265 | IP Reachability | variable | Section 3.2.3.2 | 760 | | Information | | | 761 +--------------+-----------------------+----------+-----------------+ 763 Table 6: Prefix Descriptor TLVs 765 3.2.3.1. OSPF Route Type 767 OSPF Route Type is an optional TLV that MAY be present in Prefix 768 NLRIs. It is used to identify the OSPF route-type of the prefix. It 769 is used when an OSPF prefix is advertised in the OSPF domain with 770 multiple route-types. The Route Type TLV allows to discrimination of 771 these advertisements. The format of the OSPF Route Type TLV is shown 772 in the following figure. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Route Type | 780 +-+-+-+-+-+-+-+-+ 782 Figure 13: OSPF Route Type TLV Format 784 where the Type and Length fields of the TLV are defined in Table 6. 785 The OSPF Route Type field values are defined in the OSPF protocol, 786 and can be one of the following: 788 Intra-Area (0x1) 790 Inter-Area (0x2) 792 External 1 (0x3) 794 External 2 (0x4) 796 NSSA 1 (0x5) 798 NSSA 2 (0x6) 800 3.2.3.2. IP Reachability Information 802 The IP Reachability Information is a mandatory TLV that contains one 803 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 804 topology. Its purpose is to glue a particular BGP service NLRI by 805 virtue of its BGP next-hop to a given Node in the LSDB. A router 806 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 807 The format of the IP Reachability Information TLV is shown in the 808 following figure: 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type | Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Prefix Length | IP Prefix (variable) // 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Figure 14: IP Reachability Information TLV Format 820 The Type and Length fields of the TLV are defined in Table 6. The 821 following two fields determine the address-family reachability 822 information. The 'Prefix Length' field contains the length of the 823 prefix in bits. The 'IP Prefix' field contains the most significant 824 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 825 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 826 24 and 4 octets for prefix length 25 up to 32, etc. 828 3.3. The BGP-LS Attribute 830 This is an optional, non-transitive BGP attribute that is used to 831 carry link, node and prefix parameters and attributes. It is defined 832 as a set of Type/Length/Value (TLV) triplets, described in the 833 following section. This attribute SHOULD only be included with Link- 834 State NLRIs. This attribute MUST be ignored for all other address- 835 families. 837 3.3.1. Node Attribute TLVs 839 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 840 attribute with a node NLRI. The following node attribute TLVs are 841 defined: 843 +--------------+-----------------------+----------+-----------------+ 844 | TLV Code | Description | Length | Value defined | 845 | Point | | | in: | 846 +--------------+-----------------------+----------+-----------------+ 847 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 848 | | Identifier | | | 849 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 850 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 851 | | Properties | | | 852 | 1026 | Node Name | variable | Section 3.3.1.3 | 853 | 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 | 854 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 855 | | Local Node | | | 856 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 857 | | Local Node | | | 858 +--------------+-----------------------+----------+-----------------+ 860 Table 7: Node Attribute TLVs 862 3.3.1.1. Node Flag Bits TLV 864 The Node Flag Bits TLV carries a bit mask describing node attributes. 865 The value is a variable length bit array of flags, where each bit 866 represents a node capability. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type | Length | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |O|T|E|B| Reserved| 874 +-+-+-+-+-+-+-+-+-+ 876 Figure 15: Node Flag Bits TLV format 878 The bits are defined as follows: 880 +----------+-------------------------+-----------+ 881 | Bit | Description | Reference | 882 +----------+-------------------------+-----------+ 883 | 'O' | Overload Bit | [RFC1195] | 884 | 'T' | Attached Bit | [RFC1195] | 885 | 'E' | External Bit | [RFC2328] | 886 | 'B' | ABR Bit | [RFC2328] | 887 | Reserved | Reserved for future use | | 888 +----------+-------------------------+-----------+ 890 Table 8: Node Flag Bits Definitions 892 3.3.1.2. IS-IS Area Identifier TLV 894 An IS-IS node can be part of one or more IS-IS areas. Each of these 895 area addresses is carried in the IS-IS Area Identifier TLV. If 896 multiple Area Addresses are present, multiple TLVs are used to encode 897 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 898 attribute only when advertised in the Link-State Node NLRI. 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type | Length | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 // Area Identifier (variable) // 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Figure 16: IS-IS Area Identifier TLV Format 910 3.3.1.3. Node Name TLV 912 The Node Name TLV is optional. Its structure and encoding has been 913 borrowed from [RFC5301]. The value field identifies the symbolic 914 name of the router node. This symbolic name can be the FQDN for the 915 router, it can be a subset of the FQDN, or it can be any string 916 operators want to use for the router. The use of FQDN or a subset of 917 it is strongly RECOMMENDED. 919 The Value field is encoded in 7-bit ASCII. If a user-interface for 920 configuring or displaying this field permits Unicode characters, that 921 user-interface is responsible for applying the ToASCII and/or 922 ToUnicode algorithm as described in [RFC5890] to achieve the correct 923 format for transmission or display. 925 Altough [RFC5301] is an IS-IS specific extension, usage of the Node 926 Name TLV is possible for all protocols. How a router derives and 927 injects node names for e.g. OSPF nodes, is outside of the scope of 928 this document. 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Type | Length | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 // Node Name (variable) // 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Figure 17: Node Name format 940 3.3.1.4. Local IPv4/IPv6 Router-ID 942 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 943 Router-IDs that the IGP might be using, e.g., for TE and migration 944 purposes like correlating a Node-ID between different protocols. If 945 there is more than one auxiliary Router-ID of a given type, then each 946 one is encoded in its own TLV. 948 3.3.1.5. Opaque Node Attribute TLV 950 The Opaque Node Attribute TLV is an envelope that transparently 951 carries optional node attribute TLVs advertised by a router. An 952 originating router shall use this TLV for encoding information 953 specific to the protocol advertised in the NLRI header Protocol-ID 954 field or new protocol extensions to the protocol as advertised in the 955 NLRI header Protocol-ID field for which there is no protocol neutral 956 representation in the BGP link-state NLRI. The primary use of the 957 Opaque Node Attribute TLV is to bridge the document lag between e.g. 958 a new IGP Link-state attribute being defined and the 'protocol- 959 neutral' BGP-LS extensions being published. A router for example 960 could use this extension in order to advertise the native protocols 961 node attribute TLVs, such as the OSPF Router Informational 962 Capabilities TLV defined in [RFC4970], or the IGP TE Node Capability 963 Descriptor TLV described in [RFC5073]. 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Type | Length | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 // Opaque node attributes (variable) // 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Figure 18: Opaque Node attribute format 975 3.3.2. Link Attribute TLVs 977 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 978 attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ 979 Value (TLV) triplet formatted as defined in Section 3.1. The format 980 and semantics of the 'value' fields in some 'Link Attribute' TLVs 981 correspond to the format and semantics of value fields in IS-IS 982 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 983 [RFC5307]. Other 'Link Attribute' TLVs are defined in this document. 984 Although the encodings for 'Link Attribute' TLVs were originally 985 defined for IS-IS, the TLVs can carry data sourced either by IS-IS or 986 OSPF. 988 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 989 attribute: 991 +-----------+---------------------+--------------+------------------+ 992 | TLV Code | Description | IS-IS TLV | Defined in: | 993 | Point | | /Sub-TLV | | 994 +-----------+---------------------+--------------+------------------+ 995 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 996 | | Local Node | | | 997 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 998 | | Local Node | | | 999 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1000 | | Remote Node | | | 1001 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1002 | | Remote Node | | | 1003 | 1032 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1004 | | Identifiers | | | 1005 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1006 | | group (color) | | | 1007 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1008 | | bandwidth | | | 1009 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1010 | | link bandwidth | | | 1011 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1012 | | bandwidth | | | 1013 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3/ | 1014 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1015 | | Type | | | 1016 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1017 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1018 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1019 | | Group | | | 1020 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1021 | | attribute | | | 1022 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1023 +-----------+---------------------+--------------+------------------+ 1025 Table 9: Link Attribute TLVs 1027 3.3.2.1. IPv4/IPv6 Router-ID 1029 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1030 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1031 purposes. All auxiliary Router-IDs of both the local and the remote 1032 node MUST be included in the link attribute of each link NLRI. If 1033 there are more than one auxiliary Router-ID of a given type, then 1034 multiple TLVs are used to encode them. 1036 3.3.2.2. MPLS Protocol Mask TLV 1038 The MPLS Protocol TLV carries a bit mask describing which MPLS 1039 signaling protocols are enabled. The length of this TLV is 1. The 1040 value is a bit array of 8 flags, where each bit represents an MPLS 1041 Protocol capability. 1043 Generation of the MPLS Protocol Mask TLV is only valid for 1044 originators which have local link insight, like for example Protocol- 1045 IDs 'Static' or 'Direct' as per Table 2. The MPLS Protocol Mask TLV 1046 MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-IS 1047 L2', 'OSPFv2' or 'OSPFv3' as per Table 2. 1049 0 1 2 3 1050 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 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Type | Length | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 |L|R| Reserved | 1055 +-+-+-+-+-+-+-+-+ 1057 Figure 19: MPLS Protocol TLV 1059 The following bits are defined: 1061 +------------+------------------------------------------+-----------+ 1062 | Bit | Description | Reference | 1063 +------------+------------------------------------------+-----------+ 1064 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1065 | 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] | 1066 | | TE) | | 1067 | 'Reserved' | Reserved for future use | | 1068 +------------+------------------------------------------+-----------+ 1070 Table 10: MPLS Protocol Mask TLV Codes 1072 3.3.2.3. TE Default Metric TLV 1074 The TE Default Metric TLV carries the TE-metric for this link. The 1075 length of this TLV is fixed at 4 octets. If a source protocol (e.g. 1076 IS-IS) does not support a Metric width of 32 bits then the high order 1077 octet MUST be set to zero. 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Type | Length | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | TE Default Link Metric | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Figure 20: TE Default Metric TLV format 1089 3.3.2.4. IGP Metric TLV 1091 The IGP Metric TLV carries the metric for this link. The length of 1092 this TLV is variable, depending on the metric width of the underlying 1093 protocol. IS-IS small metrics have a length of 1 octet (the two most 1094 significant bits are ignored). OSPF link metrics have a length of 1095 two octects. IS-IS wide-metrics have a length of three octets. 1097 0 1 2 3 1098 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Type | Length | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 // IGP Link Metric (variable length) // 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 21: Metric TLV format 1107 3.3.2.5. Shared Risk Link Group TLV 1109 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1110 Group information (see Section 2.3, "Shared Risk Link Group 1111 Information", of [RFC4202]). It contains a data structure consisting 1112 of a (variable) list of SRLG values, where each element in the list 1113 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1114 (number of SRLG values). 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 | Shared Risk Link Group Value | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 // ............ // 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Shared Risk Link Group Value | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 Figure 22: Shared Risk Link Group TLV format 1130 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 1131 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1132 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1133 defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG 1134 information are carried in a single TLV. 1136 3.3.2.6. Opaque Link Attribute TLV 1138 The Opaque link Attribute TLV is an envelope that transparently 1139 carries optional link atrribute TLVs advertised by a router. An 1140 originating router shall use this TLV for encoding information 1141 specific to the protocol advertised in the NLRI header Protocol-ID 1142 field or new protocol extensions to the protocol as advertised in the 1143 NLRI header Protocol-ID field for which there is no protocol neutral 1144 representation in the BGP link-state NLRI. The primary use of the 1145 Opaque Link Attribute TLV is to bridge the document lag between e.g. 1146 a new IGP Link-state attribute being defined and the 'protocol- 1147 neutral' BGP-LS extensions being published. 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Type | Length | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 // Opaque link attributes (variable) // 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Figure 23: Opaque link attribute format 1159 3.3.2.7. Link Name TLV 1161 The Link Name TLV is optional. The value field identifies the 1162 symbolic name of the router link. This symbolic name can be the FQDN 1163 for the link, it can be a subset of the FQDN, or it can be any string 1164 operators want to use for the link. The use of FQDN or a subset of 1165 it is strongly RECOMMENDED. 1167 The Value field is encoded in 7-bit ASCII. If a user-interface for 1168 configuring or displaying this field permits Unicode characters, that 1169 user-interface is responsible for applying the ToASCII and/or 1170 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1171 format for transmission or display. 1173 How a router derives and injects link names is outside of the scope 1174 of this document. 1176 0 1 2 3 1177 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 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Type | Length | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 // Link Name (variable) // 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 Figure 24: Link Name format 1186 3.3.3. Prefix Attribute TLVs 1188 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1189 of IGP attributes (such as metric, route tags, etc.) that MUST be 1190 reflected into the LINK_STATE attribute. This section describes the 1191 different attributes related to the IPv4/IPv6 prefixes. Prefix 1192 Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 1193 only. The following attributes TLVs are defined: 1195 +---------------+----------------------+----------+-----------------+ 1196 | TLV Code | Description | Length | Reference | 1197 | Point | | | | 1198 +---------------+----------------------+----------+-----------------+ 1199 | 1152 | IGP Flags | 1 | Section 3.3.3.1 | 1200 | 1153 | Route Tag | 4*n | Section 3.3.3.2 | 1201 | 1154 | Extended Tag | 8*n | Section 3.3.3.3 | 1202 | 1155 | Prefix Metric | 4 | Section 3.3.3.4 | 1203 | 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 | 1204 | | Address | | | 1205 | 1157 | Opaque Prefix | variable | Section 3.3.3.6 | 1206 | | Attribute | | | 1207 +---------------+----------------------+----------+-----------------+ 1209 Table 11: Prefix Attribute TLVs 1211 3.3.3.1. IGP Flags TLV 1213 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1214 assigned tothe prefix. The IGP Flags TLV is encoded as follows: 1216 0 1 2 3 1217 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 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Type | Length | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 |D|N|L|P| Resvd.| 1222 +-+-+-+-+-+-+-+-+ 1224 Figure 25: IGP Flag TLV format 1226 The value field contains bits defined according to the table below: 1228 +----------+---------------------------+-----------+ 1229 | Bit | Description | Reference | 1230 +----------+---------------------------+-----------+ 1231 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1232 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1233 | 'L' | OSPF "local address" Bit | [RFC5340] | 1234 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1235 | Reserved | Reserved for future use. | | 1236 +----------+---------------------------+-----------+ 1238 Table 12: IGP Flag Bits Definitions 1240 3.3.3.2. Route Tag 1242 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1243 the prefix and is encoded as follows: 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Type | Length | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 // Route Tags (one or more) // 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 Figure 26: IGP Route TAG TLV format 1255 Length is a multiple of 4. 1257 The value field contains one or more Route Tags as learned in the IGP 1258 topology. 1260 3.3.3.3. Extended Route Tag 1262 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1263 prefix [RFC5130] 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 // Extended Route Tag (one or more) // 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Figure 27: Extended IGP Route TAG TLV format 1275 Length is a multiple of 8. 1277 The 'Extended Route Tag' field contains one or more Extended Route 1278 Tags as learned in the IGP topology. 1280 3.3.3.4. Prefix Metric TLV 1282 Prefix Metric TLV is an optional attribute and may only appear once. 1283 If present, it carries the metric of the prefix as known in the IGP 1284 topology [RFC5305] (and therefore represents the reachability cost to 1285 the prefix). If not present, it means that the prefix is advertised 1286 without any reachability. 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Type | Length | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Metric | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Figure 28: Prefix Metric TLV Format 1298 Length is 4. 1300 3.3.3.5. OSPF Forwarding Address TLV 1302 OSPF Forwarding Address TLV [RFC2328] and [RFC5340] carries the OSPF 1303 forwarding address as known in the original OSPF advertisement. 1304 Forwarding address can be either IPv4 or IPv6. 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Type | Length | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 // Forwarding Address (variable) // 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 Figure 29: OSPF Forwarding Address TLV Format 1316 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1317 forwarding address. 1319 3.3.3.6. Opaque Prefix Attribute TLV 1321 The Opaque Prefix Attribute TLV is an envelope that transparently 1322 carries optional prefix attribute TLVs advertised by a router. An 1323 originating router shall use this TLV for encoding information 1324 specific to the protocol advertised in the NLRI header Protocol-ID 1325 field or new protocol extensions to the protocol as advertised in the 1326 NLRI header Protocol-ID field for which there is no protocol neutral 1327 representation in the BGP link-state NLRI. The primary use of the 1328 Opaque Prefix Attribute TLV is to bridge the document lag between 1329 e.g. a new IGP Link-state attribute being defined and the 'protocol- 1330 neutral' BGP-LS extensions being published. 1332 The format of the TLV is as follows: 1334 0 1 2 3 1335 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 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Type | Length | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 // Opaque Prefix Attributes (variable) // 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Figure 30: Opaque Prefix Attribute TLV Format 1344 Type is as specified in Table 11 and Length is variable. 1346 3.4. BGP Next Hop Information 1348 BGP link-state information for both IPv4 and IPv6 networks can be 1349 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1350 an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1351 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1352 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 1353 address. Usually the next hop will be set to the local end-point 1354 address of the BGP session. The next hop address MUST be encoded as 1355 described in [RFC4760]. The length field of the next hop address 1356 will specify the next hop address-family. If the next hop length is 1357 4, then the next hop is an IPv4 address; if the next hop length is 1358 16, then it is a global IPv6 address and if the next hop length is 1359 32, then there is one global IPv6 address followed by a link-local 1360 IPv6 address. The link-local IPv6 address should be used as 1361 described in [RFC2545]. For VPN SAFI, as per custom, an 8 byte 1362 route-distinguisher set to all zero is prepended to the next hop. 1364 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1365 the NLRI it receives. In case identical NLRIs are sourced by 1366 multiple originators the BGP next hop attribute is used to tie-break 1367 as per the standard BGP path decision process. This specification 1368 doesn't mandate any rule regarding the re-write of the BGP Next Hop 1369 attribute. 1371 3.5. Inter-AS Links 1373 The main source of TE information is the IGP, which is not active on 1374 inter-AS links. In some cases, the IGP may have information of 1375 inter-AS links ([RFC5392], [RFC5316]). In other cases, an 1376 implementation SHOULD provide a means to inject inter-AS links into 1377 BGP-LS. The exact mechanism used to provision the inter-AS links is 1378 outside the scope of this document 1380 3.6. Router-ID Anchoring Example: ISO Pseudonode 1382 Encoding of a broadcast LAN in IS-IS provides a good example of how 1383 Router-IDs are encoded. Consider Figure 31. This represents a 1384 Broadcast LAN between a pair of routers. The "real" (=non 1385 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1386 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1387 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1388 (Pseudonode1, Node2) are being generated. 1390 The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP 1391 Router-ID TLV of the local node descriptor is 6 octets long 1392 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1393 the remote node descriptor is 7 octets long containing the ISO-ID of 1394 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1395 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1396 192.0.2.1, the IPv4 Router-ID of Node1. 1398 The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP 1399 Router-ID TLV of the local node descriptor is 7 octets long 1400 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1401 Router-ID TLV of the remote node descriptor is 6 octets long 1402 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1403 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1404 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1406 +-----------------+ +-----------------+ +-----------------+ 1407 | Node1 | | Pseudonode1 | | Node2 | 1408 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1409 | 192.0.2.1 | | | | 192.0.2.2 | 1410 +-----------------+ +-----------------+ +-----------------+ 1412 Figure 31: IS-IS Pseudonodes 1414 3.7. Router-ID Anchoring Example: OSPF Pseudonode 1416 Encoding of a broadcast LAN in OSPF provides a good example of how 1417 Router-IDs and local Interface IPs are encoded. Consider Figure 32. 1418 This represents a Broadcast LAN between a pair of routers. The 1419 "real" (=non pseudonode) routers have both an IPv4 Router-ID and an 1420 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1421 interface Address (for disambiguation) and an OSPF Area. Node1 is 1422 the DIS for the LAN, hence its local IP address 10.1.1.1 is used both 1423 as the Router-ID and Interface IP for the Pseudonode keys. Two 1424 unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2) 1425 are being generated. 1427 The link NRLI of (Node1, Pseudonode1) is encoded as follows: 1429 o Local Node Descriptor 1431 TLV #515: IGP Router ID: 11.11.11.11 1433 TLV #514: OSPF Area-ID: ID:0.0.0.0 1435 o Remote Node Descriptor 1437 TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 1439 TLV #514: OSPF Area-ID: ID:0.0.0.0 1441 The link NRLI of (Pseudonode1, Node2) is encoded as follows: 1443 o Local Node Descriptor 1445 TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 1447 TLV #514: OSPF Area-ID: ID:0.0.0.0 1449 o Remote Node Descriptor 1450 TLV #515: IGP Router ID: 33.33.33.34 1452 TLV #514: OSPF Area-ID: ID:0.0.0.0 1454 +-----------------+ +-----------------+ +-----------------+ 1455 | Node1 | | Pseudonode1 | | Node2 | 1456 | 11.11.11.11 |--->| 10.1.1.1 |--->| 33.33.33.34 | 1457 | | | 10.1.1.1 | | | 1458 | Area 0 | | Area 0 | | Area 0 | 1459 +-----------------+ +-----------------+ +-----------------+ 1461 Figure 32: OSPF Pseudonodes 1463 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1465 Graceful migration from one IGP to another requires coordinated 1466 operation of both protocols during the migration period. Such a 1467 coordination requires identifying a given physical link in both IGPs. 1468 The IPv4 Router-ID provides that "glue" which is present in the node 1469 descriptors of the OSPF link NLRI and in the link attribute of the 1470 IS-IS link NLRI. 1472 Consider a point-to-point link between two routers, A and B, that 1473 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1474 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1475 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1476 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1477 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1478 in the local and remote node descriptors, respectively. The IS-IS 1479 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1480 the local and remote node descriptors, respectively. In addition, 1481 the BGP-LS attribute of the IS-IS link NLRI contains the TLV type 1482 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1483 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1484 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1485 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1487 4. Link to Path Aggregation 1489 Distribution of all links available in the global Internet is 1490 certainly possible, however not desirable from a scaling and privacy 1491 point of view. Therefore an implementation may support link to path 1492 aggregation. Rather than advertising all specific links of a domain, 1493 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1494 of nodes. The "aggregate link" represents the aggregated set of link 1495 properties between a pair of non-adjacent nodes. The actual methods 1496 to compute the path properties (of bandwidth, metric) are outside the 1497 scope of this document. The decision whether to advertise all 1498 specific links or aggregated links is an operator's policy choice. 1499 To highlight the varying levels of exposure, the following deployment 1500 examples are discussed. 1502 4.1. Example: No Link Aggregation 1504 Consider Figure 33. Both AS1 and AS2 operators want to protect their 1505 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1506 compute its link-protection LSP to R3 it needs to "see" an alternate 1507 path to R3. Therefore the AS2 operator exposes its topology. All 1508 BGP TE enabled routers in AS1 "see" the full topology of AS and 1509 therefore can compute a backup path. Note that the decision if the 1510 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1511 by the computing router. 1513 AS1 : AS2 1514 : 1515 R1-------R3 1516 | : | \ 1517 | : | R5 1518 | : | / 1519 R2-------R4 1520 : 1521 : 1523 Figure 33: No link aggregation 1525 4.2. Example: ASBR to ASBR Path Aggregation 1527 The brief difference between the "no-link aggregation" example and 1528 this example is that no specific link gets exposed. Consider 1529 Figure 34. The only link which gets advertised by AS2 is an 1530 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1531 there is a backup path. However the actual links being used are 1532 hidden from the topology. 1534 AS1 : AS2 1535 : 1536 R1-------R3 1537 | : | 1538 | : | 1539 | : | 1540 R2-------R4 1541 : 1542 : 1544 Figure 34: ASBR link aggregation 1546 4.3. Example: Multi-AS Path Aggregation 1548 Service providers in control of multiple ASes may even decide to not 1549 expose their internal inter-AS links. Consider Figure 35. AS3 is 1550 modeled as a single node which connects to the border routers of the 1551 aggregated domain. 1553 AS1 : AS2 : AS3 1554 : : 1555 R1-------R3----- 1556 | : : \ 1557 | : : vR0 1558 | : : / 1559 R2-------R4----- 1560 : : 1561 : : 1563 Figure 35: Multi-AS aggregation 1565 5. IANA Considerations 1567 This document requests a code point from the registry of Address 1568 Family Numbers. As per early allocation procedure this is AFI 16388. 1570 This document requests a code point from the registry of Subsequent 1571 Address Family Numbers. As per early allocation procedure this is 1572 SAFI 71. 1574 This document requests a code point from the BGP Path Attributes 1575 registry. As per early allocation procedure this is Path Attribute 1576 29. 1578 This document requests creation of a new registry for BGP-LS NLRI- 1579 Types. Value 0 is reserved. The registry will be initialized as 1580 shown in Table 1. Allocations within the registry will require 1581 documentation of the proposed use of the allocated value and approval 1582 by the Designated Expert assigned by the IESG (see [RFC5226]). 1584 This document requests creation of a new registry for BGP-LS 1585 Protocol-IDs. Value 0 is reserved. The registry will be initialized 1586 as shown in Table 2. Allocations within the registry will require 1587 documentation of the proposed use of the allocated value and approval 1588 by the Designated Expert assigned by the IESG (see [RFC5226]). 1590 This document requests creation of a new registry for BGP-LS Well- 1591 known Instance-IDs. The registry will be initialized as shown in 1592 Table 3. Allocations within the registry will require documentation 1593 of the proposed use of the allocated value and approval by the 1594 Designated Expert assigned by the IESG (see [RFC5226]). 1596 This document requests creation of a new registry for node anchor, 1597 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1598 Values 256-65535 will be used for Codepoints. The registry will be 1599 initialized as shown in Table 13. Allocations within the registry 1600 will require documentation of the proposed use of the allocated value 1601 and approval by the Designated Expert assigned by the IESG (see 1602 [RFC5226]). 1604 Note to RFC Editor: this section may be removed on publication as an 1605 RFC. 1607 6. Manageability Considerations 1609 This section is structured as recommended in [RFC5706]. 1611 6.1. Operational Considerations 1613 6.1.1. Operations 1615 Existing BGP operational procedures apply. No new operation 1616 procedures are defined in this document. It is noted that the NLRI 1617 information present in this document purely carries application level 1618 data that has no immediate corresponding forwarding state impact. As 1619 such, any churn in reachability information has different impact than 1620 regular BGP updates which need to change forwarding state for an 1621 entire router. Furthermore it is anticipated that distribution of 1622 this NLRI will be handled by dedicated route-reflectors providing a 1623 level of isolation and fault-containment between different NLRI 1624 types. 1626 6.1.2. Installation and Initial Setup 1628 Configuration parameters defined in Section 6.2.3 SHOULD be 1629 initialized to the following default values: 1631 o The Link-State NLRI capability is turned off for all neighbors. 1633 o The maximum rate at which Link-State NLRIs will be advertised/ 1634 withdrawn from neighbors is set to 200 updates per second. 1636 6.1.3. Migration Path 1638 The proposed extension is only activated between BGP peers after 1639 capability negotiation. Moreover, the extensions can be turned on/ 1640 off an individual peer basis (see Section 6.2.3), so the extension 1641 can be gradually rolled out in the network. 1643 6.1.4. Requirements on Other Protocols and Functional Components 1645 The protocol extension defined in this document does not put new 1646 requirements on other protocols or functional components. 1648 6.1.5. Impact on Network Operation 1650 Frequency of Link-State NLRI updates could interfere with regular BGP 1651 prefix distribution. A network operator MAY use a dedicated Route- 1652 Reflector infrastructure to distribute Link-State NLRIs. 1654 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1655 domain, which can consist of multiple areas within an AS or multiple 1656 ASes. 1658 6.1.6. Verifying Correct Operation 1660 Existing BGP procedures apply. In addition, an implementation SHOULD 1661 allow an operator to: 1663 o List neighbors with whom the Speaker is exchanging Link-State 1664 NLRIs 1666 6.2. Management Considerations 1668 6.2.1. Management Information 1670 6.2.2. Fault Management 1672 TBD. 1674 6.2.3. Configuration Management 1676 An implementation SHOULD allow the operator to specify neighbors to 1677 which Link-State NLRIs will be advertised and from which Link-State 1678 NLRIs will be accepted. 1680 An implementation SHOULD allow the operator to specify the maximum 1681 rate at which Link-State NLRIs will be advertised/withdrawn from 1682 neighbors. 1684 An implementation SHOULD allow the operator to specify the maximum 1685 number of Link-State NLRIs stored in router's RIB. 1687 An implementation SHOULD allow the operator to create abstracted 1688 topologies that are advertised to neighbors; Create different 1689 abstractions for different neighbors. 1691 An implementation SHOULD allow the operator to configure a 64-bit 1692 instance ID. 1694 An implementation SHOULD allow the operator to configure a pair of 1695 ASN and BGP-LS identifier (Paragraph 2) per flooding set in which the 1696 node participates. 1698 6.2.4. Accounting Management 1700 Not Applicable. 1702 6.2.5. Performance Management 1704 An implementation SHOULD provide the following statistics: 1706 o Total number of Link-State NLRI updates sent/received 1708 o Number of Link-State NLRI updates sent/received, per neighbor 1710 o Number of errored received Link-State NLRI updates, per neighbor 1712 o Total number of locally originated Link-State NLRIs 1714 6.2.6. Security Management 1716 An operator SHOULD define ACLs to limit inbound updates as follows: 1718 o Drop all updates from Consumer peers 1720 7. TLV/Sub-TLV Code Points Summary 1722 This section contains the global table of all TLVs/Sub-TLVs defined 1723 in this document. 1725 +-----------+---------------------+---------------+-----------------+ 1726 | TLV Code | Description | IS-IS TLV/ | Value defined | 1727 | Point | | Sub-TLV | in: | 1728 +-----------+---------------------+---------------+-----------------+ 1729 | 256 | Local Node | --- | Section 3.2.1.2 | 1730 | | Descriptors | | | 1731 | 257 | Remote Node | --- | Section 3.2.1.3 | 1732 | | Descriptors | | | 1733 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1734 | | Identifiers | | | 1735 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1736 | | address | | | 1737 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1738 | | address | | | 1739 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1740 | | address | | | 1741 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1742 | | address | | | 1743 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1744 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1745 | 265 | IP Reachability | --- | Section 3.2.3 | 1746 | | Information | | | 1747 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1748 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1749 | 514 | OSPF Area ID | --- | Section 3.2.1.4 | 1750 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1751 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1752 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1753 | | Properties | | | 1754 | 1026 | Node Name | variable | Section 3.3.1.3 | 1755 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1756 | | Identifier | | | 1757 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1758 | | Local Node | | | 1759 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1760 | | Local Node | | | 1761 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1762 | | Remote Node | | | 1763 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1764 | | Remote Node | | | 1765 | 1032 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1766 | | Identifiers | | | 1767 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1768 | | group (color) | | | 1769 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1770 | | bandwidth | | | 1771 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1772 | | link bandwidth | | | 1773 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1774 | | bandwidth | | | 1775 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | 1776 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1777 | | Type | | | 1778 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1779 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1780 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1781 | | Group | | | 1782 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1783 | | attribute | | | 1784 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1785 | 1152 | IGP Flags | --- | Section 3.3.3.1 | 1786 | 1153 | Route Tag | --- | [RFC5130] | 1787 | 1154 | Extended Tag | --- | [RFC5130] | 1788 | 1155 | Prefix Metric | --- | [RFC5305] | 1789 | 1156 | OSPF Forwarding | --- | [RFC2328] | 1790 | | Address | | | 1791 | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | 1792 | | Attribute | | | 1793 +-----------+---------------------+---------------+-----------------+ 1795 Table 13: Summary Table of TLV/Sub-TLV Codepoints 1797 8. Security Considerations 1799 Procedures and protocol extensions defined in this document do not 1800 affect the BGP security model. See the 'Security Considerations' 1801 section of [RFC4271] for a discussion of BGP security. Also refer to 1802 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 1804 In the context of the BGP peerings associated with this document, a 1805 BGP Speaker SHOULD NOT accept updates from a Consumer peer. That is, 1806 a participating BGP Speaker, should be aware of the nature of its 1807 relationships for link state relationships and should protect itself 1808 from peers sending updates that either represent erroneous 1809 information feedback loops, or are false input. Such protection can 1810 be achieved by manual configuration of Consumer peers at the BGP 1811 Speaker. 1813 An operator SHOULD employ a mechanism to protect a BGP Speaker 1814 against DDoS attacks from Consumers. The principal attack a consumer 1815 may apply is to attempt to start multiple sessions either 1816 sequentially or simultaneously. Protection can be applied by 1817 imposing rate limits. 1819 Additionally, it may be considered that the export of link state and 1820 TE information as described in this document constitutes a risk to 1821 confidentiality of mission-critical or commercially-sensitive 1822 information about the network. BGP peerings are not automatic and 1823 require configuration, thus it is the responsibility of the network 1824 operator to ensure that only trusted Consumers are configured to 1825 receive such information. 1827 9. Contributors 1829 We would like to thank Robert Varga for the significant contribution 1830 he gave to this document. 1832 10. Acknowledgements 1834 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1835 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1836 Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex 1837 Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, 1838 Vipin Kumar, Naiming Shen, Balaji Rajagopalan and Yakov Rekhter for 1839 their comments. 1841 11. References 1843 11.1. Normative References 1845 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1846 dual environments", RFC 1195, December 1990. 1848 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1849 E. Lear, "Address Allocation for Private Internets", BCP 1850 5, RFC 1918, February 1996. 1852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1853 Requirement Levels", BCP 14, RFC 2119, March 1997. 1855 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1857 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1858 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1859 1999. 1861 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1862 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1863 Tunnels", RFC 3209, December 2001. 1865 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1866 Support of Generalized Multi-Protocol Label Switching 1867 (GMPLS)", RFC 4202, October 2005. 1869 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1870 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1872 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1873 "Multiprotocol Extensions for BGP-4", RFC 4760, January 1874 2007. 1876 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1877 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1878 4915, June 2007. 1880 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1881 Specification", RFC 5036, October 2007. 1883 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1884 Topology (MT) Routing in Intermediate System to 1885 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1887 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 1888 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1889 February 2008. 1891 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1892 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1893 May 2008. 1895 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1896 Mechanism for IS-IS", RFC 5301, October 2008. 1898 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1899 Engineering", RFC 5305, October 2008. 1901 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1902 of Generalized Multi-Protocol Label Switching (GMPLS)", 1903 RFC 5307, October 2008. 1905 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1906 for IPv6", RFC 5340, July 2008. 1908 [RFC5890] Klensin, J., "Internationalized Domain Names for 1909 Applications (IDNA): Definitions and Document Framework", 1910 RFC 5890, August 2010. 1912 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1913 Engineering in IS-IS", RFC 6119, February 2011. 1915 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1916 Identifier for BGP-4", RFC 6286, June 2011. 1918 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1919 Instance Extensions", RFC 6549, March 2012. 1921 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 1922 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1924 11.2. Informative References 1926 [I-D.ietf-alto-protocol] 1927 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 1928 ietf-alto-protocol-27 (work in progress), March 2014. 1930 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 1931 4272, January 2006. 1933 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1934 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1936 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1937 Shaffer, "Extensions to OSPF for Advertising Optional 1938 Router Capabilities", RFC 4970, July 2007. 1940 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1941 Extensions for Discovery of Traffic Engineering Node 1942 Capabilities", RFC 5073, December 2007. 1944 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1945 Path Computation Method for Establishing Inter-Domain 1946 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1947 5152, February 2008. 1949 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1950 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1951 Traffic Engineering", RFC 5316, December 2008. 1953 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1954 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1955 Traffic Engineering", RFC 5392, January 2009. 1957 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1958 Optimization (ALTO) Problem Statement", RFC 5693, October 1959 2009. 1961 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1962 Management of New Protocols and Protocol Extensions", RFC 1963 5706, November 2009. 1965 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1966 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1967 and Authentication for Routing Protocols (KARP) Design 1968 Guide", RFC 6952, May 2013. 1970 Authors' Addresses 1972 Hannes Gredler 1973 Juniper Networks, Inc. 1974 1194 N. Mathilda Ave. 1975 Sunnyvale, CA 94089 1976 US 1978 Email: hannes@juniper.net 1980 Jan Medved 1981 Cisco Systems, Inc. 1982 170, West Tasman Drive 1983 San Jose, CA 95134 1984 US 1986 Email: jmedved@cisco.com 1988 Stefano Previdi 1989 Cisco Systems, Inc. 1990 Via Del Serafico, 200 1991 Rome 00142 1992 Italy 1994 Email: sprevidi@cisco.com 1996 Adrian Farrel 1997 Juniper Networks, Inc. 1998 1194 N. Mathilda Ave. 1999 Sunnyvale, CA 94089 2000 US 2002 Email: afarrel@juniper.net 2004 Saikat Ray 2005 Cisco Systems, Inc. 2006 170, West Tasman Drive 2007 San Jose, CA 95134 2008 US 2010 Email: sairay@cisco.com