idnits 2.17.1 draft-ietf-idr-ls-distribution-11.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 (June 4, 2015) is 3249 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) == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-18 -- 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 (~~), 2 warnings (==), 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 Juniper Networks, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: December 6, 2015 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 June 4, 2015 12 North-Bound Distribution of Link-State and TE Information using BGP 13 draft-ietf-idr-ls-distribution-11 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 December 6, 2015. 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 . . . . . . . . . . . . . . . . . 22 87 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 27 88 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 30 89 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 31 90 3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 31 91 3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 32 92 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 33 93 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 33 94 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 34 95 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 34 96 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 35 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 98 6. Manageability Considerations . . . . . . . . . . . . . . . . 36 99 6.1. Operational Considerations . . . . . . . . . . . . . . . 36 100 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 36 101 6.1.2. Installation and Initial Setup . . . . . . . . . . . 37 102 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 37 103 6.1.4. Requirements on Other Protocols and Functional 104 Components . . . . . . . . . . . . . . . . . . . . . 37 105 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 37 106 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 37 107 6.2. Management Considerations . . . . . . . . . . . . . . . . 37 108 6.2.1. Management Information . . . . . . . . . . . . . . . 37 109 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 38 110 6.2.3. Configuration Management . . . . . . . . . . . . . . 38 111 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39 112 6.2.5. Performance Management . . . . . . . . . . . . . . . 39 113 6.2.6. Security Management . . . . . . . . . . . . . . . . . 39 114 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 116 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 119 11.1. Normative References . . . . . . . . . . . . . . . . . . 42 120 11.2. Informative References . . . . . . . . . . . . . . . . . 43 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 123 1. Introduction 125 The contents of a Link State Database (LSDB) or a Traffic Engineering 126 Database (TED) has the scope of an IGP area. Some applications, such 127 as end-to-end Traffic Engineering (TE), would benefit from visibility 128 outside one area or Autonomous System (AS) in order to make better 129 decisions. 131 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 132 a mechanism for achieving the computation of end-to-end TE paths that 133 cross the visibility of more than one TED or which require CPU- 134 intensive or coordinated computations. The IETF has also defined the 135 ALTO Server [RFC5693] as an entity that generates an abstracted 136 network topology and provides it to network-aware applications. 138 Both a PCE and an ALTO Server need to gather information about the 139 topologies and capabilities of the network in order to be able to 140 fulfill their function. 142 This document describes a mechanism by which Link State and TE 143 information can be collected from networks and shared with external 144 components using the BGP routing protocol [RFC4271]. This is 145 achieved using a new BGP Network Layer Reachability Information 146 (NLRI) encoding format. The mechanism is applicable to physical and 147 virtual links. The mechanism described is subject to policy control. 149 A router maintains one or more databases for storing link-state 150 information about nodes and links in any given area. Link attributes 151 stored in these databases include: local/remote IP addresses, local/ 152 remote interface identifiers, link metric and TE metric, link 153 bandwidth, reservable bandwidth, per CoS class reservation state, 154 preemption and Shared Risk Link Groups (SRLG). The router's BGP 155 process can retrieve topology from these LSDBs and distribute it to a 156 consumer, either directly or via a peer BGP Speaker (typically a 157 dedicated Route Reflector), using the encoding specified in this 158 document. 160 The collection of Link State and TE link state information and its 161 distribution to consumers is shown in the following figure. 163 +-----------+ 164 | Consumer | 165 +-----------+ 166 ^ 167 | 168 +-----------+ 169 | BGP | +-----------+ 170 | Speaker | | Consumer | 171 +-----------+ +-----------+ 172 ^ ^ ^ ^ 173 | | | | 174 +---------------+ | +-------------------+ | 175 | | | | 176 +-----------+ +-----------+ +-----------+ 177 | BGP | | BGP | | BGP | 178 | Speaker | | Speaker | . . . | Speaker | 179 +-----------+ +-----------+ +-----------+ 180 ^ ^ ^ 181 | | | 182 IGP IGP IGP 184 Figure 1: TE Link State info collection 186 A BGP Speaker may apply configurable policy to the information that 187 it distributes. Thus, it may distribute the real physical topology 188 from the LSDB or the TED. Alternatively, it may create an abstracted 189 topology, where virtual, aggregated nodes are connected by virtual 190 paths. Aggregated nodes can be created, for example, out of multiple 191 routers in a POP. Abstracted topology can also be a mix of physical 192 and virtual nodes and physical and virtual links. Furthermore, the 193 BGP Speaker can apply policy to determine when information is updated 194 to the consumer so that there is reduction of information flow from 195 the network to the consumers. Mechanisms through which topologies 196 can be aggregated or virtualized are outside the scope of this 197 document 199 2. Motivation and Applicability 201 This section describes use cases from which the requirements can be 202 derived. 204 2.1. MPLS-TE with PCE 206 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 207 within a "domain" (such as an IGP area) or across multiple domains 208 (such as a multi-area AS, or multiple ASes). 210 o Within a single area, the PCE offers enhanced computational power 211 that may not be available on individual routers, sophisticated 212 policy control and algorithms, and coordination of computation 213 across the whole area. 215 o If a router wants to compute a MPLS-TE path across IGP areas, then 216 its own TED lacks visibility of the complete topology. That means 217 that the router cannot determine the end-to-end path, and cannot 218 even select the right exit router (Area Border Router - ABR) for 219 an optimal path. This is an issue for large-scale networks that 220 need to segment their core networks into distinct areas, but still 221 want to take advantage of MPLS-TE. 223 Previous solutions used per-domain path computation [RFC5152]. The 224 source router could only compute the path for the first area because 225 the router only has full topological visibility for the first area 226 along the path, but not for subsequent areas. Per-domain path 227 computation uses a technique called "loose-hop-expansion" [RFC3209], 228 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 229 using the IGP computed shortest path topology for the remainder of 230 the path. This may lead to sub-optimal paths, makes alternate/back- 231 up path computation hard, and might result in no TE path being found 232 when one really does exist. 234 The PCE presents a computation server that may have visibility into 235 more than one IGP area or AS, or may cooperate with other PCEs to 236 perform distributed path computation. The PCE obviously needs access 237 to the TED for the area(s) it serves, but [RFC4655] does not describe 238 how this is achieved. Many implementations make the PCE a passive 239 participant in the IGP so that it can learn the latest state of the 240 network, but this may be sub-optimal when the network is subject to a 241 high degree of churn, or when the PCE is responsible for multiple 242 areas. 244 The following figure shows how a PCE can get its TED information 245 using the mechanism described in this document. 247 +----------+ +---------+ 248 | ----- | | BGP | 249 | | TED |<-+-------------------------->| Speaker | 250 | ----- | TED synchronization | | 251 | | | mechanism: +---------+ 252 | | | BGP with Link-State NLRI 253 | v | 254 | ----- | 255 | | PCE | | 256 | ----- | 257 +----------+ 258 ^ 259 | Request/ 260 | Response 261 v 262 Service +----------+ Signaling +----------+ 263 Request | Head-End | Protocol | Adjacent | 264 -------->| Node |<------------>| Node | 265 +----------+ +----------+ 267 Figure 2: External PCE node using a TED synchronization mechanism 269 The mechanism in this document allows the necessary TED information 270 to be collected from the IGP within the network, filtered according 271 to configurable policy, and distributed to the PCE as necessary. 273 2.2. ALTO Server Network API 275 An ALTO Server [RFC5693] is an entity that generates an abstracted 276 network topology and provides it to network-aware applications over a 277 web service based API. Example applications are p2p clients or 278 trackers, or CDNs. The abstracted network topology comes in the form 279 of two maps: a Network Map that specifies allocation of prefixes to 280 Partition Identifiers (PIDs), and a Cost Map that specifies the cost 281 between PIDs listed in the Network Map. For more details, see 282 [RFC7285]. 284 ALTO abstract network topologies can be auto-generated from the 285 physical topology of the underlying network. The generation would 286 typically be based on policies and rules set by the operator. Both 287 prefix and TE data are required: prefix data is required to generate 288 ALTO Network Maps, TE (topology) data is required to generate ALTO 289 Cost Maps. Prefix data is carried and originated in BGP, TE data is 290 originated and carried in an IGP. The mechanism defined in this 291 document provides a single interface through which an ALTO Server can 292 retrieve all the necessary prefix and network topology data from the 293 underlying network. Note an ALTO Server can use other mechanisms to 294 get network data, for example, peering with multiple IGP and BGP 295 Speakers. 297 The following figure shows how an ALTO Server can get network 298 topology information from the underlying network using the mechanism 299 described in this document. 301 +--------+ 302 | Client |<--+ 303 +--------+ | 304 | ALTO +--------+ BGP with +---------+ 305 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 306 | Client |<--+------------| Server |<----------------| Speaker | 307 +--------+ | | | | | 308 | +--------+ +---------+ 309 +--------+ | 310 | Client |<--+ 311 +--------+ 313 Figure 3: ALTO Server using network topology information 315 3. Carrying Link State Information in BGP 317 This specification contains two parts: definition of a new BGP NLRI 318 that describes links, nodes and prefixes comprising IGP link state 319 information, and definition of a new BGP path attribute (BGP-LS 320 attribute) that carries link, node and prefix properties and 321 attributes, such as the link and prefix metric or auxiliary Router- 322 IDs of nodes, etc. 324 It is desired to keep the dependencies on the protocol source of this 325 attributes to a minimum and represent any content in an IGP neutral 326 way, such that applications which do want to learn about a Link-state 327 topology do not need to know about any OSPF or IS-IS protocol 328 specifics. 330 3.1. TLV Format 332 Information in the new Link-State NLRIs and attributes is encoded in 333 Type/Length/Value triplets. The TLV format is shown in Figure 4. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 // Value (variable) // 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4: TLV format 345 The Length field defines the length of the value portion in octets 346 (thus a TLV with no value portion would have a length of zero). The 347 TLV is not padded to four-octet alignment. Unrecognized types are 348 preserved and propagated. In order to compare NLRIs with unknown 349 TLVs all TLVs MUST be ordered in ascending order by TLV Type. If 350 there are more TLVs of the same type, then the TLVs MUST be ordered 351 in ascending order of the TLV value within the TLVs with the same 352 type. All TLVs that are not specified as mandatory are considered 353 optional. 355 3.2. The Link-State NLRI 357 The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 358 for carrying opaque information. Each Link-State NLRI describes 359 either a node, a link or a prefix. 361 All non-VPN link, node and prefix information SHALL be encoded using 362 AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be 363 encoded using AFI 16388 / SAFI TBD. 365 In order for two BGP speakers to exchange Link-State NLRI, they MUST 366 use BGP Capabilities Advertisement to ensure that they both are 367 capable of properly processing such NLRI. This is done as specified 368 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 369 an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for the VPN flavor. 371 The format of the Link-State NLRI is shown in the following figure. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | NLRI Type | Total NLRI Length | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 // Link-State NLRI (variable) // 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | NLRI Type | Total NLRI Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 + Route Distinguisher + 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 // Link-State NLRI (variable) // 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 6: Link-State VPN AFI 16388 / SAFI TBD NLRI Format 401 The 'Total NLRI Length' field contains the cumulative length, in 402 octets, of rest of the NLRI not including the NLRI Type field or 403 itself. For VPN applications, it also includes the length of the 404 Route Distinguisher. 406 +------+---------------------------+ 407 | Type | NLRI Type | 408 +------+---------------------------+ 409 | 1 | Node NLRI | 410 | 2 | Link NLRI | 411 | 3 | IPv4 Topology Prefix NLRI | 412 | 4 | IPv6 Topology Prefix NLRI | 413 +------+---------------------------+ 415 Table 1: NLRI Types 417 The Node NLRI (NLRI Type = 1) is shown in the following figure. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+ 422 | Protocol-ID | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Identifier | 425 | (64 bits) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 // Local Node Descriptors (variable) // 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 7: The Node NLRI format 432 The Link NLRI (NLRI Type = 2) is shown in the following figure. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+ 437 | Protocol-ID | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Identifier | 440 | (64 bits) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 // Local Node Descriptors (variable) // 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 // Remote Node Descriptors (variable) // 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 // Link Descriptors (variable) // 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Figure 8: The Link NLRI format 451 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 452 same format as shown in the following figure. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+ 457 | Protocol-ID | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Identifier | 460 | (64 bits) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 // Local Node Descriptor (variable) // 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 // Prefix Descriptors (variable) // 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 9: The IPv4/IPv6 Topology Prefix NLRI format 469 The 'Protocol-ID' field can contain one of the following values: 471 +-------------+----------------------------------+ 472 | Protocol-ID | NLRI information source protocol | 473 +-------------+----------------------------------+ 474 | 1 | IS-IS Level 1 | 475 | 2 | IS-IS Level 2 | 476 | 3 | OSPFv2 | 477 | 4 | Direct | 478 | 5 | Static configuration | 479 | 6 | OSPFv3 | 480 +-------------+----------------------------------+ 482 Table 2: Protocol Identifiers 484 The 'Direct' and 'Static' protocol types SHOULD be used when BGP-LS 485 is sourcing local information. For all information, derived from 486 other protocols the corresponding protocol-ID MUST be used. If BGP- 487 LS has got direct access to interface information and wants to 488 advertise a local link then the protocol-ID 'Direct' SHOULD be used. 489 For modeling virtual links, like described in Section 4 the protocol- 490 ID 'Static configuration' SHOULD be used. 492 Both OSPF and IS-IS MAY run multiple routing protocol instances over 493 the same link. See [RFC6822] and [RFC6549]. These instances define 494 independent "routing universes". The 64-Bit 'Identifier' field is 495 used to identify the "routing universe" where the NLRI belongs. The 496 NLRIs representing Link-state objects (nodes, links or prefixes) from 497 the same routing universe MUST have the same 'Identifier' value. 498 NLRIs with different 'Identifier' values MUST be considered to be 499 from different routing universes. Table 3 lists the 'Identifier' 500 values that are defined as well-known in this draft. 502 +------------+----------------------------------+ 503 | Identifier | Routing Universe | 504 +------------+----------------------------------+ 505 | 0 | Default Layer 3 Routing topology | 506 | 1-31 | Reserved | 507 +------------+----------------------------------+ 509 Table 3: Well-known Instance Identifiers 511 If a given Protocol does not support multiple routing universes then 512 it SHOULD set the 'Identifier' field according to Table 3. However 513 an implementation MAY make the 'Identifier' configurable, for a given 514 protocol. 516 Each Node Descriptor and Link Descriptor consists of one or more TLVs 517 described in the following sections. 519 3.2.1. Node Descriptors 521 Each link is anchored by a pair of Router-IDs that are used by the 522 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 523 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 524 additional auxiliary Router-IDs, mainly for traffic engineering 525 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 526 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 527 included in the link attribute described in Section 3.3.2. 529 It is desirable that the Router-ID assignments inside the Node 530 Descriptor are globally unique. However there may be Router-ID 531 spaces (e.g. ISO) where no global registry exists, or worse, Router- 532 IDs have been allocated following private-IP RFC 1918 [RFC1918] 533 allocation. We use Autonomous System (AS) Number and BGP-LS 534 Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as 535 described in Section 3.2.1.1. 537 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 539 One problem that needs to be addressed is the ability to identify an 540 IGP node globally (by "global", we mean within the BGP-LS database 541 collected by all BGP-LS speakers that talk to each other). This can 542 be expressed through the following two requirements: 544 (A) The same node MUST NOT be represented by two keys (otherwise one 545 node will look like two nodes). 547 (B) Two different nodes MUST NOT be represented by the same key 548 (otherwise, two nodes will look like one node). 550 We define an "IGP domain" to be the set of nodes (hence, by extension 551 links and prefixes), within which, each node has a unique IGP 552 representation by using the combination of Area-ID, Router-ID, 553 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 554 receive node/link/prefix information from multiple independent "IGP 555 domains" and we need to distinguish between them. Moreover, we can't 556 assume there is always one and only one IGP domain per AS. During 557 IGP transitions it may happen that two redundant IGPs are in place. 559 In Section 3.2.1.4 a set of sub-TLVs is described, which allows 560 specification of a flexible key for any given Node/Link information 561 such that global uniqueness of the NLRI is ensured. 563 3.2.1.2. Local Node Descriptors 565 The Local Node Descriptors TLV contains Node Descriptors for the node 566 anchoring the local end of the link. This is a mandatory TLV in all 567 three types of NLRIs. The length of this TLV is variable. The value 568 contains one or more Node Descriptor Sub-TLVs defined in 569 Section 3.2.1.4. 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type | Length | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | | 577 // Node Descriptor Sub-TLVs (variable) // 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 10: Local Node Descriptors TLV format 583 3.2.1.3. Remote Node Descriptors 585 The Remote Node Descriptors contains Node Descriptors for the node 586 anchoring the remote end of the link. This is a mandatory TLV for 587 link NLRIs. The length of this TLV is variable. The value contains 588 one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Length | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | | 596 // Node Descriptor Sub-TLVs (variable) // 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 11: Remote Node Descriptors TLV format 602 3.2.1.4. Node Descriptor Sub-TLVs 604 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 605 the following table: 607 +--------------------+-------------------+----------+ 608 | Sub-TLV Code Point | Description | Length | 609 +--------------------+-------------------+----------+ 610 | 512 | Autonomous System | 4 | 611 | 513 | BGP-LS Identifier | 4 | 612 | 514 | OSPF Area-ID | 4 | 613 | 515 | IGP Router-ID | Variable | 614 +--------------------+-------------------+----------+ 616 Table 4: Node Descriptor Sub-TLVs 618 The sub-TLV values in Node Descriptor TLVs are defined as follows: 620 Autonomous System: opaque value (32 Bit AS Number) 622 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 623 ASN, uniquely identifies the BGP-LS domain. The combination of 624 ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers 625 within an IGP flooding-set (set of IGP nodes within which an LSP/ 626 LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP 627 domain consists of multiple flooding-sets, then all BGP-LS 628 speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID 629 tuple. The ASN, BGP Router-ID tuple (which is globally unique 630 [RFC6286] ) of one of the BGP-LS speakers within the flooding-set 631 (or IGP domain) may be used for all BGP-LS speakers in that 632 flooding-set (or IGP domain). 634 Area ID: It is used to identify the 32 Bit area to which the NLRI 635 belongs. Area Identifier allows the different NLRIs of the same 636 router to be discriminated. 638 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 639 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 640 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 641 octet ISO node-ID of the "Designated Intermediate System" (DIS) 642 followed by one octet nonzero PSN identifier (7 octets in total). 643 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 644 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, 645 this contains the 4 octet Router-ID of the designated router (DR) 646 followed by the 4 octet IPv4 address of the DR's interface to the 647 LAN (8 octets in total). Similarly, for an OSPFv3 "Pseudonode", 648 this contains the 4 octet Router-ID of the DR followed by the 4 649 octet interface identifier of the DR's interface to the LAN (8 650 octets in total). The TLV size in combination with protocol 651 identifier enables the decoder to determine the type of the node. 653 There can be at most one instance of each sub-TLV type present in 654 any Node Descriptor. The sub-TLVs within a Node descriptor MUST 655 be arranged in ascending order by sub-TLV type. This needs to be 656 done in order to compare NLRIs, even when an implementation 657 encounters an unknown sub-TLV. Using stable sorting an 658 implementation can do binary comparison of NLRIs and hence allow 659 incremental deployment of new key sub-TLVs. 661 3.2.1.5. Multi-Topology ID 663 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 664 Multi-Topology IDs for a link, node or prefix. 666 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 667 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 668 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 669 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 670 SHOULD be set to 0 when originated and ignored on receipt. 672 The format of the MT-ID TLV is shown in the following figure. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Type | Length=2*n | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |R R R R| Multi-Topology ID 1 | .... // 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 // .... |R R R R| Multi-Topology ID n | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 12: Multi-Topology ID TLV format 686 where Type is 263, Length is 2*n and n is the number of MT-IDs 687 carried in the TLV. 689 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 690 Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or 691 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 692 the topology where the link or the prefix is reachable is allowed. 693 In case one wants to advertise multiple topologies for a given Link 694 Descriptor or Prefix Descriptor, multiple NRLIs need to be generated 695 where each NLRI contains an unique MT-ID. In the BGP-LS attribute of 696 a node NLRI, one MT-ID TLV containing the array of MT-IDs of all 697 topologies where the node is reachable is allowed. 699 3.2.2. Link Descriptors 701 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 702 triplets. The format of each TLV is shown in Section 3.1. The 'Link 703 descriptor' TLVs uniquely identify a link among multiple parallel 704 links between a pair of anchor routers. A link described by the Link 705 descriptor TLVs actually is a "half-link", a unidirectional 706 representation of a logical link. In order to fully describe a 707 single logical link, two originating routers advertise a half-link 708 each, i.e., two link NLRIs are advertised for a given point-to-point 709 link. 711 The format and semantics of the 'value' fields in most 'Link 712 Descriptor' TLVs correspond to the format and semantics of value 713 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 714 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 715 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 716 carry data sourced either by IS-IS or OSPF. 718 The following TLVs are valid as Link Descriptors in the Link NLRI: 720 +-----------+---------------------+---------------+-----------------+ 721 | TLV Code | Description | IS-IS TLV | Value defined | 722 | Point | | /Sub-TLV | in: | 723 +-----------+---------------------+---------------+-----------------+ 724 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 725 | | Identifiers | | | 726 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 727 | | address | | | 728 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 729 | | address | | | 730 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 731 | | address | | | 732 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 733 | | address | | | 734 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 735 | | Identifier | | | 736 +-----------+---------------------+---------------+-----------------+ 738 Table 5: Link Descriptor TLVs 740 The information about a link present in the LSA/LSP originated by the 741 local node of the link determines the set of TLVs in the Link 742 Descriptor of the link. 744 If interface and neighbor addresses, either IPv4 or IPv6, are 745 present, then the IP address TLVs are included in the link 746 descriptor, but not the link local/remote Identifier TLV. The 747 link local/remote identifiers MAY be included in the link 748 attribute. 750 If interface and neighbor addresses are not present and the link 751 local/remote identifiers are present, then the link local/remote 752 Identifier TLV is included in the link descriptor. 754 The Multi-Topology Identifier TLV is included in link descriptor 755 if that information is present. 757 3.2.3. Prefix Descriptors 759 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 760 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 761 Prefix originated by a Node. The following TLVs are valid as Prefix 762 Descriptors in the IPv4/IPv6 Prefix NLRI: 764 +--------------+-----------------------+----------+-----------------+ 765 | TLV Code | Description | Length | Value defined | 766 | Point | | | in: | 767 +--------------+-----------------------+----------+-----------------+ 768 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 769 | | Identifier | | | 770 | 264 | OSPF Route Type | 1 | Section 3.2.3.1 | 771 | 265 | IP Reachability | variable | Section 3.2.3.2 | 772 | | Information | | | 773 +--------------+-----------------------+----------+-----------------+ 775 Table 6: Prefix Descriptor TLVs 777 3.2.3.1. OSPF Route Type 779 OSPF Route Type is an optional TLV that MAY be present in Prefix 780 NLRIs. It is used to identify the OSPF route-type of the prefix. It 781 is used when an OSPF prefix is advertised in the OSPF domain with 782 multiple route-types. The Route Type TLV allows to discrimination of 783 these advertisements. The format of the OSPF Route Type TLV is shown 784 in the following figure. 786 0 1 2 3 787 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 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Type | Length | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Route Type | 792 +-+-+-+-+-+-+-+-+ 794 Figure 13: OSPF Route Type TLV Format 796 where the Type and Length fields of the TLV are defined in Table 6. 797 The OSPF Route Type field values are defined in the OSPF protocol, 798 and can be one of the following: 800 Intra-Area (0x1) 802 Inter-Area (0x2) 804 External 1 (0x3) 806 External 2 (0x4) 808 NSSA 1 (0x5) 810 NSSA 2 (0x6) 812 3.2.3.2. IP Reachability Information 814 The IP Reachability Information is a mandatory TLV that contains one 815 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 816 topology. Its purpose is to glue a particular BGP service NLRI by 817 virtue of its BGP next-hop to a given Node in the LSDB. A router 818 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 819 The format of the IP Reachability Information TLV is shown in the 820 following figure: 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Type | Length | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Prefix Length | IP Prefix (variable) // 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Figure 14: IP Reachability Information TLV Format 832 The Type and Length fields of the TLV are defined in Table 6. The 833 following two fields determine the address-family reachability 834 information. The 'Prefix Length' field contains the length of the 835 prefix in bits. The 'IP Prefix' field contains the most significant 836 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 837 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 838 24 and 4 octets for prefix length 25 up to 32, etc. 840 3.3. The BGP-LS Attribute 842 This is an optional, non-transitive BGP attribute that is used to 843 carry link, node and prefix parameters and attributes. It is defined 844 as a set of Type/Length/Value (TLV) triplets, described in the 845 following section. This attribute SHOULD only be included with Link- 846 State NLRIs. This attribute MUST be ignored for all other address- 847 families. 849 3.3.1. Node Attribute TLVs 851 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 852 attribute with a node NLRI. The following node attribute TLVs are 853 defined: 855 +--------------+-----------------------+----------+-----------------+ 856 | TLV Code | Description | Length | Value defined | 857 | Point | | | in: | 858 +--------------+-----------------------+----------+-----------------+ 859 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 860 | | Identifier | | | 861 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 862 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 863 | | Properties | | | 864 | 1026 | Node Name | variable | Section 3.3.1.3 | 865 | 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 | 866 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 867 | | Local Node | | | 868 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 869 | | Local Node | | | 870 +--------------+-----------------------+----------+-----------------+ 872 Table 7: Node Attribute TLVs 874 3.3.1.1. Node Flag Bits TLV 876 The Node Flag Bits TLV carries a bit mask describing node attributes. 877 The value is a variable length bit array of flags, where each bit 878 represents a node capability. 880 0 1 2 3 881 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 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Type | Length | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 |O|T|E|B| Reserved| 886 +-+-+-+-+-+-+-+-+-+ 888 Figure 15: Node Flag Bits TLV format 890 The bits are defined as follows: 892 +----------+-------------------------+-----------+ 893 | Bit | Description | Reference | 894 +----------+-------------------------+-----------+ 895 | 'O' | Overload Bit | [RFC1195] | 896 | 'T' | Attached Bit | [RFC1195] | 897 | 'E' | External Bit | [RFC2328] | 898 | 'B' | ABR Bit | [RFC2328] | 899 | Reserved | Reserved for future use | | 900 +----------+-------------------------+-----------+ 902 Table 8: Node Flag Bits Definitions 904 3.3.1.2. IS-IS Area Identifier TLV 906 An IS-IS node can be part of one or more IS-IS areas. Each of these 907 area addresses is carried in the IS-IS Area Identifier TLV. If 908 multiple Area Addresses are present, multiple TLVs are used to encode 909 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 910 attribute only when advertised in the Link-State Node NLRI. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Type | Length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 // Area Identifier (variable) // 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 Figure 16: IS-IS Area Identifier TLV Format 922 3.3.1.3. Node Name TLV 924 The Node Name TLV is optional. Its structure and encoding has been 925 borrowed from [RFC5301]. The value field identifies the symbolic 926 name of the router node. This symbolic name can be the FQDN for the 927 router, it can be a subset of the FQDN (e.g. a hostname), or it can 928 be any string operators want to use for the router. The use of FQDN 929 or a subset of it is strongly RECOMMENDED. The maximum length of the 930 'Node Name TLV' is 255 octets. 932 The Value field is encoded in 7-bit ASCII. If a user-interface for 933 configuring or displaying this field permits Unicode characters, that 934 user-interface is responsible for applying the ToASCII and/or 935 ToUnicode algorithm as described in [RFC5890] to achieve the correct 936 format for transmission or display. 938 Although [RFC5301] is an IS-IS specific extension, usage of the Node 939 Name TLV is possible for all protocols. How a router derives and 940 injects node names for e.g. OSPF nodes, is outside of the scope of 941 this document. 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Length | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 // Node Name (variable) // 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Figure 17: Node Name format 953 3.3.1.4. Local IPv4/IPv6 Router-ID 955 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 956 Router-IDs that the IGP might be using, e.g., for TE and migration 957 purposes like correlating a Node-ID between different protocols. If 958 there is more than one auxiliary Router-ID of a given type, then each 959 one is encoded in its own TLV. 961 3.3.1.5. Opaque Node Attribute TLV 963 The Opaque Node Attribute TLV is an envelope that transparently 964 carries optional node attribute TLVs advertised by a router. An 965 originating router shall use this TLV for encoding information 966 specific to the protocol advertised in the NLRI header Protocol-ID 967 field or new protocol extensions to the protocol as advertised in the 968 NLRI header Protocol-ID field for which there is no protocol neutral 969 representation in the BGP link-state NLRI. The primary use of the 970 Opaque Node Attribute TLV is to bridge the document lag between e.g. 971 a new IGP Link-state attribute being defined and the 'protocol- 972 neutral' BGP-LS extensions being published. A router for example 973 could use this extension in order to advertise the native protocols 974 node attribute TLVs, such as the OSPF Router Informational 975 Capabilities TLV defined in [RFC4970], or the IGP TE Node Capability 976 Descriptor TLV described in [RFC5073]. 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Type | Length | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 // Opaque node attributes (variable) // 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 18: Opaque Node attribute format 988 3.3.2. Link Attribute TLVs 990 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 991 attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ 992 Value (TLV) triplet formatted as defined in Section 3.1. The format 993 and semantics of the 'value' fields in some 'Link Attribute' TLVs 994 correspond to the format and semantics of value fields in IS-IS 995 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 996 [RFC5307]. Other 'Link Attribute' TLVs are defined in this document. 997 Although the encodings for 'Link Attribute' TLVs were originally 998 defined for IS-IS, the TLVs can carry data sourced either by IS-IS or 999 OSPF. 1001 The following 'Link Attribute' TLVs are valid in the LINK_STATE 1002 attribute: 1004 +-----------+---------------------+--------------+------------------+ 1005 | TLV Code | Description | IS-IS TLV | Defined in: | 1006 | Point | | /Sub-TLV | | 1007 +-----------+---------------------+--------------+------------------+ 1008 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1009 | | Local Node | | | 1010 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1011 | | Local Node | | | 1012 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1013 | | Remote Node | | | 1014 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1015 | | Remote Node | | | 1016 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1017 | | group (color) | | | 1018 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1019 | | bandwidth | | | 1020 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1021 | | link bandwidth | | | 1022 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1023 | | bandwidth | | | 1024 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3/ | 1025 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1026 | | Type | | | 1027 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1028 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1029 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1030 | | Group | | | 1031 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1032 | | attribute | | | 1033 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1034 +-----------+---------------------+--------------+------------------+ 1036 Table 9: Link Attribute TLVs 1038 3.3.2.1. IPv4/IPv6 Router-ID 1040 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1041 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1042 purposes. All auxiliary Router-IDs of both the local and the remote 1043 node MUST be included in the link attribute of each link NLRI. If 1044 there are more than one auxiliary Router-ID of a given type, then 1045 multiple TLVs are used to encode them. 1047 3.3.2.2. MPLS Protocol Mask TLV 1049 The MPLS Protocol TLV carries a bit mask describing which MPLS 1050 signaling protocols are enabled. The length of this TLV is 1. The 1051 value is a bit array of 8 flags, where each bit represents an MPLS 1052 Protocol capability. 1054 Generation of the MPLS Protocol Mask TLV is only valid for 1055 originators that have local link insight, like for example Protocol- 1056 IDs 'Static' or 'Direct' as per Table 2. The 'MPLS Protocol Mask' 1057 TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS- 1058 IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2. 1060 0 1 2 3 1061 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Type | Length | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 |L|R| Reserved | 1066 +-+-+-+-+-+-+-+-+ 1068 Figure 19: MPLS Protocol TLV 1070 The following bits are defined: 1072 +------------+------------------------------------------+-----------+ 1073 | Bit | Description | Reference | 1074 +------------+------------------------------------------+-----------+ 1075 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1076 | 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] | 1077 | | TE) | | 1078 | 'Reserved' | Reserved for future use | | 1079 +------------+------------------------------------------+-----------+ 1081 Table 10: MPLS Protocol Mask TLV Codes 1083 3.3.2.3. TE Default Metric TLV 1085 The TE Default Metric TLV carries the Traffic engineering metric for 1086 this link. The length of this TLV is fixed at 4 octets. If a source 1087 protocol (e.g. IS-IS) does not support a Metric width of 32 bits 1088 then the high order octet MUST be set to zero. 1090 0 1 2 3 1091 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 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Type | Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | TE Default Link Metric | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Figure 20: TE Default Metric TLV format 1100 3.3.2.4. IGP Metric TLV 1102 The IGP Metric TLV carries the metric for this link. The length of 1103 this TLV is variable, depending on the metric width of the underlying 1104 protocol. IS-IS small metrics have a length of 1 octet (the two most 1105 significant bits are ignored). OSPF link metrics have a length of 1106 two octets. IS-IS wide-metrics have a length of three octets. 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Type | Length | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 // IGP Link Metric (variable length) // 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Figure 21: Metric TLV format 1118 3.3.2.5. Shared Risk Link Group TLV 1120 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1121 Group information (see Section 2.3, "Shared Risk Link Group 1122 Information", of [RFC4202]). It contains a data structure consisting 1123 of a (variable) list of SRLG values, where each element in the list 1124 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1125 (number of SRLG values). 1127 0 1 2 3 1128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Type | Length | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Shared Risk Link Group Value | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 // ............ // 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Shared Risk Link Group Value | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Figure 22: Shared Risk Link Group TLV format 1141 The SRLG TLV for OSPF-TE is defined in [RFC4203]. In IS-IS the SRLG 1142 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1143 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1144 defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG 1145 information are carried in a single TLV. 1147 3.3.2.6. Opaque Link Attribute TLV 1149 The Opaque link Attribute TLV is an envelope that transparently 1150 carries optional link attribute TLVs advertised by a router. An 1151 originating router shall use this TLV for encoding information 1152 specific to the protocol advertised in the NLRI header Protocol-ID 1153 field or new protocol extensions to the protocol as advertised in the 1154 NLRI header Protocol-ID field for which there is no protocol neutral 1155 representation in the BGP link-state NLRI. The primary use of the 1156 Opaque Link Attribute TLV is to bridge the document lag between e.g. 1157 a new IGP Link-state attribute being defined and the 'protocol- 1158 neutral' BGP-LS extensions being published. 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Type | Length | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 // Opaque link attributes (variable) // 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 Figure 23: Opaque link attribute format 1170 3.3.2.7. Link Name TLV 1172 The Link Name TLV is optional. The value field identifies the 1173 symbolic name of the router link. This symbolic name can be the FQDN 1174 for the link, it can be a subset of the FQDN, or it can be any string 1175 operators want to use for the link. The use of FQDN or a subset of 1176 it is strongly RECOMMENDED. The maximum length of the 'Link Name 1177 TLV' is 255 octets. 1179 The Value field is encoded in 7-bit ASCII. If a user-interface for 1180 configuring or displaying this field permits Unicode characters, that 1181 user-interface is responsible for applying the ToASCII and/or 1182 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1183 format for transmission or display. 1185 How a router derives and injects link names is outside of the scope 1186 of this document. 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Type | Length | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 // Link Name (variable) // 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Figure 24: Link Name format 1198 3.3.3. Prefix Attribute TLVs 1200 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1201 of IGP attributes (such as metric, route tags, etc.) that MUST be 1202 reflected into the LINK_STATE attribute. This section describes the 1203 different attributes related to the IPv4/IPv6 prefixes. Prefix 1204 Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 1205 only. The following attributes TLVs are defined: 1207 +---------------+----------------------+----------+-----------------+ 1208 | TLV Code | Description | Length | Reference | 1209 | Point | | | | 1210 +---------------+----------------------+----------+-----------------+ 1211 | 1152 | IGP Flags | 1 | Section 3.3.3.1 | 1212 | 1153 | Route Tag | 4*n | Section 3.3.3.2 | 1213 | 1154 | Extended Tag | 8*n | Section 3.3.3.3 | 1214 | 1155 | Prefix Metric | 4 | Section 3.3.3.4 | 1215 | 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 | 1216 | | Address | | | 1217 | 1157 | Opaque Prefix | variable | Section 3.3.3.6 | 1218 | | Attribute | | | 1219 +---------------+----------------------+----------+-----------------+ 1221 Table 11: Prefix Attribute TLVs 1223 3.3.3.1. IGP Flags TLV 1225 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1226 assigned to the prefix. The IGP Flags TLV is encoded as follows: 1228 0 1 2 3 1229 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Type | Length | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 |D|N|L|P| Resvd.| 1234 +-+-+-+-+-+-+-+-+ 1236 Figure 25: IGP Flag TLV format 1238 The value field contains bits defined according to the table below: 1240 +----------+---------------------------+-----------+ 1241 | Bit | Description | Reference | 1242 +----------+---------------------------+-----------+ 1243 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1244 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1245 | 'L' | OSPF "local address" Bit | [RFC5340] | 1246 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1247 | Reserved | Reserved for future use. | | 1248 +----------+---------------------------+-----------+ 1250 Table 12: IGP Flag Bits Definitions 1252 3.3.3.2. Route Tag 1254 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1255 the prefix and is encoded as follows: 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Type | Length | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 // Route Tags (one or more) // 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 Figure 26: IGP Route TAG TLV format 1267 Length is a multiple of 4. 1269 The value field contains one or more Route Tags as learned in the IGP 1270 topology. 1272 3.3.3.3. Extended Route Tag 1274 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1275 prefix [RFC5130] and is encoded as follows: 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Type | Length | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 // Extended Route Tag (one or more) // 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Figure 27: Extended IGP Route TAG TLV format 1287 Length is a multiple of 8. 1289 The 'Extended Route Tag' field contains one or more Extended Route 1290 Tags as learned in the IGP topology. 1292 3.3.3.4. Prefix Metric TLV 1294 Prefix Metric TLV is an optional attribute and may only appear once. 1295 If present, it carries the metric of the prefix as known in the IGP 1296 topology [RFC5305] (and therefore represents the reachability cost to 1297 the prefix). If not present, it means that the prefix is advertised 1298 without any reachability. 1300 0 1 2 3 1301 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 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Type | Length | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Metric | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 Figure 28: Prefix Metric TLV Format 1310 Length is 4. 1312 3.3.3.5. OSPF Forwarding Address TLV 1314 OSPF Forwarding Address TLV [RFC2328] and [RFC5340] carries the OSPF 1315 forwarding address as known in the original OSPF advertisement. 1316 Forwarding address can be either IPv4 or IPv6. 1318 0 1 2 3 1319 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 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | Type | Length | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 // Forwarding Address (variable) // 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 Figure 29: OSPF Forwarding Address TLV Format 1328 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1329 forwarding address. 1331 3.3.3.6. Opaque Prefix Attribute TLV 1333 The Opaque Prefix Attribute TLV is an envelope that transparently 1334 carries optional prefix attribute TLVs advertised by a router. An 1335 originating router shall use this TLV for encoding information 1336 specific to the protocol advertised in the NLRI header Protocol-ID 1337 field or new protocol extensions to the protocol as advertised in the 1338 NLRI header Protocol-ID field for which there is no protocol neutral 1339 representation in the BGP link-state NLRI. The primary use of the 1340 Opaque Prefix Attribute TLV is to bridge the document lag between 1341 e.g. a new IGP Link-state attribute being defined and the 'protocol- 1342 neutral' BGP-LS extensions being published. 1344 The format of the TLV is as follows: 1346 0 1 2 3 1347 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 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Type | Length | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 // Opaque Prefix Attributes (variable) // 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 30: Opaque Prefix Attribute TLV Format 1356 Type is as specified in Table 11 and Length is variable. 1358 3.4. BGP Next Hop Information 1360 BGP link-state information for both IPv4 and IPv6 networks can be 1361 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1362 an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1363 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1364 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 1365 address. Usually the next hop will be set to the local end-point 1366 address of the BGP session. The next hop address MUST be encoded as 1367 described in [RFC4760]. The length field of the next hop address 1368 will specify the next hop address-family. If the next hop length is 1369 4, then the next hop is an IPv4 address; if the next hop length is 1370 16, then it is a global IPv6 address and if the next hop length is 1371 32, then there is one global IPv6 address followed by a link-local 1372 IPv6 address. The link-local IPv6 address should be used as 1373 described in [RFC2545]. For VPN SAFI, as per custom, an 8 byte 1374 route-distinguisher set to all zero is prepended to the next hop. 1376 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1377 the NLRI it receives. In case identical NLRIs are sourced by 1378 multiple originators the BGP next hop attribute is used to tie-break 1379 as per the standard BGP path decision process. This specification 1380 doesn't mandate any rule regarding the re-write of the BGP Next Hop 1381 attribute. 1383 3.5. Inter-AS Links 1385 The main source of TE information is the IGP, which is not active on 1386 inter-AS links. In some cases, the IGP may have information of 1387 inter-AS links ([RFC5392], [RFC5316]). In other cases, an 1388 implementation SHOULD provide a means to inject inter-AS links into 1389 BGP-LS. The exact mechanism used to provision the inter-AS links is 1390 outside the scope of this document 1392 3.6. Router-ID Anchoring Example: ISO Pseudonode 1394 Encoding of a broadcast LAN in IS-IS provides a good example of how 1395 Router-IDs are encoded. Consider Figure 31. This represents a 1396 Broadcast LAN between a pair of routers. The "real" (=non 1397 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1398 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1399 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1400 (Pseudonode1, Node2) are being generated. 1402 The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP 1403 Router-ID TLV of the local node descriptor is 6 octets long 1404 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1405 the remote node descriptor is 7 octets long containing the ISO-ID of 1406 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1407 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1408 192.0.2.1, the IPv4 Router-ID of Node1. 1410 The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP 1411 Router-ID TLV of the local node descriptor is 7 octets long 1412 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1413 Router-ID TLV of the remote node descriptor is 6 octets long 1414 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1415 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1416 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1418 +-----------------+ +-----------------+ +-----------------+ 1419 | Node1 | | Pseudonode1 | | Node2 | 1420 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1421 | 192.0.2.1 | | | | 192.0.2.2 | 1422 +-----------------+ +-----------------+ +-----------------+ 1424 Figure 31: IS-IS Pseudonodes 1426 3.7. Router-ID Anchoring Example: OSPF Pseudonode 1428 Encoding of a broadcast LAN in OSPF provides a good example of how 1429 Router-IDs and local Interface IPs are encoded. Consider Figure 32. 1430 This represents a Broadcast LAN between a pair of routers. The 1431 "real" (=non pseudonode) routers have both an IPv4 Router-ID and an 1432 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1433 interface Address (for disambiguation) and an OSPF Area. Node1 is 1434 the DR for the LAN, hence its local IP address 10.1.1.1 is used both 1435 as the Router-ID and Interface IP for the Pseudonode keys. Two 1436 unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2) 1437 are being generated. 1439 The link NRLI of (Node1, Pseudonode1) is encoded as follows: 1441 o Local Node Descriptor 1443 TLV #515: IGP Router ID: 11.11.11.11 1445 TLV #514: OSPF Area-ID: ID:0.0.0.0 1447 o Remote Node Descriptor 1449 TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 1451 TLV #514: OSPF Area-ID: ID:0.0.0.0 1453 The link NRLI of (Pseudonode1, Node2) is encoded as follows: 1455 o Local Node Descriptor 1457 TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 1459 TLV #514: OSPF Area-ID: ID:0.0.0.0 1461 o Remote Node Descriptor 1462 TLV #515: IGP Router ID: 33.33.33.34 1464 TLV #514: OSPF Area-ID: ID:0.0.0.0 1466 +-----------------+ +-----------------+ +-----------------+ 1467 | Node1 | | Pseudonode1 | | Node2 | 1468 | 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 | 1469 | | | 10.1.1.1 | | | 1470 | Area 0 | | Area 0 | | Area 0 | 1471 +-----------------+ +-----------------+ +-----------------+ 1473 Figure 32: OSPF Pseudonodes 1475 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1477 Graceful migration from one IGP to another requires coordinated 1478 operation of both protocols during the migration period. Such a 1479 coordination requires identifying a given physical link in both IGPs. 1480 The IPv4 Router-ID provides that "glue" which is present in the node 1481 descriptors of the OSPF link NLRI and in the link attribute of the 1482 IS-IS link NLRI. 1484 Consider a point-to-point link between two routers, A and B, that 1485 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1486 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1487 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1488 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1489 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1490 in the local and remote node descriptors, respectively. The IS-IS 1491 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1492 the local and remote node descriptors, respectively. In addition, 1493 the BGP-LS attribute of the IS-IS link NLRI contains the TLV type 1494 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1495 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1496 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1497 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1499 4. Link to Path Aggregation 1501 Distribution of all links available in the global Internet is 1502 certainly possible, however not desirable from a scaling and privacy 1503 point of view. Therefore an implementation may support link to path 1504 aggregation. Rather than advertising all specific links of a domain, 1505 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1506 of nodes. The "aggregate link" represents the aggregated set of link 1507 properties between a pair of non-adjacent nodes. The actual methods 1508 to compute the path properties (of bandwidth, metric) are outside the 1509 scope of this document. The decision whether to advertise all 1510 specific links or aggregated links is an operator's policy choice. 1511 To highlight the varying levels of exposure, the following deployment 1512 examples are discussed. 1514 4.1. Example: No Link Aggregation 1516 Consider Figure 33. Both AS1 and AS2 operators want to protect their 1517 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1518 compute its link-protection LSP to R3 it needs to "see" an alternate 1519 path to R3. Therefore the AS2 operator exposes its topology. All 1520 BGP TE enabled routers in AS1 "see" the full topology of AS and 1521 therefore can compute a backup path. Note that the decision if the 1522 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1523 by the computing router. 1525 AS1 : AS2 1526 : 1527 R1-------R3 1528 | : | \ 1529 | : | R5 1530 | : | / 1531 R2-------R4 1532 : 1533 : 1535 Figure 33: No link aggregation 1537 4.2. Example: ASBR to ASBR Path Aggregation 1539 The brief difference between the "no-link aggregation" example and 1540 this example is that no specific link gets exposed. Consider 1541 Figure 34. The only link which gets advertised by AS2 is an 1542 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1543 there is a backup path. However the actual links being used are 1544 hidden from the topology. 1546 AS1 : AS2 1547 : 1548 R1-------R3 1549 | : | 1550 | : | 1551 | : | 1552 R2-------R4 1553 : 1554 : 1556 Figure 34: ASBR link aggregation 1558 4.3. Example: Multi-AS Path Aggregation 1560 Service providers in control of multiple ASes may even decide to not 1561 expose their internal inter-AS links. Consider Figure 35. AS3 is 1562 modeled as a single node which connects to the border routers of the 1563 aggregated domain. 1565 AS1 : AS2 : AS3 1566 : : 1567 R1-------R3----- 1568 | : : \ 1569 | : : vR0 1570 | : : / 1571 R2-------R4----- 1572 : : 1573 : : 1575 Figure 35: Multi-AS aggregation 1577 5. IANA Considerations 1579 This document is the reference for Address Family Number 16388, 'BGP- 1580 LS'. 1582 This document requests code point 71 from the registry of Subsequent 1583 Address Family Numbers named 'BGP-LS'. 1585 This document requests a code point from the registry of Subsequent 1586 Address Family Numbers named 'BGP-LS-VPN'. The SAFI assignment does 1587 NOT need to be out of the range 1-63 and MAY come out of the "First 1588 Come First Served" range 128-240. 1590 This document requests a code point from the BGP Path Attributes 1591 registry. As per early allocation procedure this is Path Attribute 1592 29. 1594 All the following Registries are BGP-LS specific and shall be 1595 accessible under the following URL: "http://www.iana.org/assignments/ 1596 bgp-ls-parameters" Title "Border Gateway Protocol - Link State (BGP- 1597 LS) Parameters" 1599 This document requests creation of a new registry for BGP-LS NLRI- 1600 Types. Value 0 is reserved. The maximum value is 65535. The 1601 registry will be initialized as shown in Table 1. Allocations within 1602 the registry will require documentation of the proposed use of the 1603 allocated value (=Specification required) and approval by the 1604 Designated Expert assigned by the IESG (see [RFC5226]). 1606 This document requests creation of a new registry for BGP-LS 1607 Protocol-IDs. Value 0 is reserved. The maximum value is 255. The 1608 registry will be initialized as shown in Table 2. Allocations within 1609 the registry will require documentation of the proposed use of the 1610 allocated value (=Specification required) and approval by the 1611 Designated Expert assigned by the IESG (see [RFC5226]). 1613 This document requests creation of a new registry for BGP-LS Well- 1614 known Instance-IDs. The registry will be initialized as shown in 1615 Table 3. Allocations within the registry will require documentation 1616 of the proposed use of the allocated value (=Specification required) 1617 and approval by the Designated Expert assigned by the IESG (see 1618 [RFC5226]). 1620 This document requests creation of a new registry for node anchor, 1621 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1622 Values 256-65535 will be used for code points. The registry will be 1623 initialized as shown in Table 13. Allocations within the registry 1624 will require documentation of the proposed use of the allocated value 1625 (=Specification required) and approval by the Designated Expert 1626 assigned by the IESG (see [RFC5226]). 1628 Note to RFC Editor: this section may be removed on publication as an 1629 RFC. 1631 6. Manageability Considerations 1633 This section is structured as recommended in [RFC5706]. 1635 6.1. Operational Considerations 1637 6.1.1. Operations 1639 Existing BGP operational procedures apply. No new operation 1640 procedures are defined in this document. It is noted that the NLRI 1641 information present in this document purely carries application level 1642 data that has no immediate corresponding forwarding state impact. As 1643 such, any churn in reachability information has different impact than 1644 regular BGP updates which need to change forwarding state for an 1645 entire router. Furthermore it is anticipated that distribution of 1646 this NLRI will be handled by dedicated route-reflectors providing a 1647 level of isolation and fault-containment between different NLRI 1648 types. 1650 6.1.2. Installation and Initial Setup 1652 Configuration parameters defined in Section 6.2.3 SHOULD be 1653 initialized to the following default values: 1655 o The Link-State NLRI capability is turned off for all neighbors. 1657 o The maximum rate at which Link-State NLRIs will be advertised/ 1658 withdrawn from neighbors is set to 200 updates per second. 1660 6.1.3. Migration Path 1662 The proposed extension is only activated between BGP peers after 1663 capability negotiation. Moreover, the extensions can be turned on/ 1664 off an individual peer basis (see Section 6.2.3), so the extension 1665 can be gradually rolled out in the network. 1667 6.1.4. Requirements on Other Protocols and Functional Components 1669 The protocol extension defined in this document does not put new 1670 requirements on other protocols or functional components. 1672 6.1.5. Impact on Network Operation 1674 Frequency of Link-State NLRI updates could interfere with regular BGP 1675 prefix distribution. A network operator MAY use a dedicated Route- 1676 Reflector infrastructure to distribute Link-State NLRIs. 1678 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1679 domain, which can consist of multiple areas within an AS or multiple 1680 ASes. 1682 6.1.6. Verifying Correct Operation 1684 Existing BGP procedures apply. In addition, an implementation SHOULD 1685 allow an operator to: 1687 o List neighbors with whom the Speaker is exchanging Link-State 1688 NLRIs 1690 6.2. Management Considerations 1692 6.2.1. Management Information 1694 This document does not mandate any new MIB information or NETCONF/ 1695 YANG models. 1697 6.2.2. Fault Management 1699 If an implementation of BGP-LS detects a malformed attribute, then it 1700 MUST use the 'Attribute Discard' action as per 1701 [I-D.ietf-idr-error-handling] Section 2. 1703 An implementation of BGP-LS MUST perform the following syntactic 1704 checks for determining if a message is malformed. 1706 o Does the sum of all TLVs found in the BGP LS attribute correspond 1707 to the BGP LS path attribute length ? 1709 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 1710 correspond to the BGP MP_REACH_NLRI length ? 1712 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 1713 attribute correspond to the BGP MP_UNREACH_NLRI length ? 1715 o Does the sum of all TLVs found in a Node-, Link or Prefix 1716 Descriptor NLRI attribute correspond to the Node-, Link- or Prefix 1717 Descriptors 'Total NLRI Length' field ? 1719 o Does any fixed length TLV correspond to the TLV Length field in 1720 this document ? 1722 6.2.3. Configuration Management 1724 An implementation SHOULD allow the operator to specify neighbors to 1725 which Link-State NLRIs will be advertised and from which Link-State 1726 NLRIs will be accepted. 1728 An implementation SHOULD allow the operator to specify the maximum 1729 rate at which Link-State NLRIs will be advertised/withdrawn from 1730 neighbors. 1732 An implementation SHOULD allow the operator to specify the maximum 1733 number of Link-State NLRIs stored in router's RIB. 1735 An implementation SHOULD allow the operator to create abstracted 1736 topologies that are advertised to neighbors; Create different 1737 abstractions for different neighbors. 1739 An implementation SHOULD allow the operator to configure a 64-bit 1740 instance ID. 1742 An implementation SHOULD allow the operator to configure a pair of 1743 ASN and BGP-LS identifier (Paragraph 2) per flooding set in which the 1744 node participates. 1746 6.2.4. Accounting Management 1748 Not Applicable. 1750 6.2.5. Performance Management 1752 An implementation SHOULD provide the following statistics: 1754 o Total number of Link-State NLRI updates sent/received 1756 o Number of Link-State NLRI updates sent/received, per neighbor 1758 o Number of errored received Link-State NLRI updates, per neighbor 1760 o Total number of locally originated Link-State NLRIs 1762 6.2.6. Security Management 1764 An operator SHOULD define an import policy to limit inbound updates 1765 as follows: 1767 o Drop all updates from Consumer peers 1769 An implementation MUST have means to limit inbound updates. 1771 7. TLV/Sub-TLV Code Points Summary 1773 This section contains the global table of all TLVs/Sub-TLVs defined 1774 in this document. 1776 +-----------+---------------------+---------------+-----------------+ 1777 | TLV Code | Description | IS-IS TLV/ | Value defined | 1778 | Point | | Sub-TLV | in: | 1779 +-----------+---------------------+---------------+-----------------+ 1780 | 256 | Local Node | --- | Section 3.2.1.2 | 1781 | | Descriptors | | | 1782 | 257 | Remote Node | --- | Section 3.2.1.3 | 1783 | | Descriptors | | | 1784 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1785 | | Identifiers | | | 1786 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1787 | | address | | | 1788 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1789 | | address | | | 1790 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1791 | | address | | | 1792 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1793 | | address | | | 1794 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1795 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1796 | 265 | IP Reachability | --- | Section 3.2.3 | 1797 | | Information | | | 1798 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1799 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1800 | 514 | OSPF Area ID | --- | Section 3.2.1.4 | 1801 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1802 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1803 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1804 | | Properties | | | 1805 | 1026 | Node Name | variable | Section 3.3.1.3 | 1806 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1807 | | Identifier | | | 1808 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1809 | | Local Node | | | 1810 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1811 | | Local Node | | | 1812 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1813 | | Remote Node | | | 1814 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1815 | | Remote Node | | | 1816 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1817 | | group (color) | | | 1818 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1819 | | bandwidth | | | 1820 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1821 | | link bandwidth | | | 1822 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1823 | | bandwidth | | | 1824 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | 1825 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1826 | | Type | | | 1827 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1828 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1829 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1830 | | Group | | | 1831 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1832 | | attribute | | | 1833 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1834 | 1152 | IGP Flags | --- | Section 3.3.3.1 | 1835 | 1153 | Route Tag | --- | [RFC5130] | 1836 | 1154 | Extended Tag | --- | [RFC5130] | 1837 | 1155 | Prefix Metric | --- | [RFC5305] | 1838 | 1156 | OSPF Forwarding | --- | [RFC2328] | 1839 | | Address | | | 1840 | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | 1841 | | Attribute | | | 1842 +-----------+---------------------+---------------+-----------------+ 1844 Table 13: Summary Table of TLV/Sub-TLV code points 1846 8. Security Considerations 1848 Procedures and protocol extensions defined in this document do not 1849 affect the BGP security model. See the 'Security Considerations' 1850 section of [RFC4271] for a discussion of BGP security. Also refer to 1851 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 1853 In the context of the BGP peerings associated with this document, a 1854 BGP Speaker MUST NOT accept updates from a Consumer peer. That is, a 1855 participating BGP Speaker, should be aware of the nature of its 1856 relationships for link state relationships and should protect itself 1857 from peers sending updates that either represent erroneous 1858 information feedback loops, or are false input. Such protection can 1859 be achieved by manual configuration of Consumer peers at the BGP 1860 Speaker. 1862 An operator SHOULD employ a mechanism to protect a BGP Speaker 1863 against DDoS attacks from Consumers. The principal attack a consumer 1864 may apply is to attempt to start multiple sessions either 1865 sequentially or simultaneously. Protection can be applied by 1866 imposing rate limits. 1868 Additionally, it may be considered that the export of link state and 1869 TE information as described in this document constitutes a risk to 1870 confidentiality of mission-critical or commercially-sensitive 1871 information about the network. BGP peerings are not automatic and 1872 require configuration, thus it is the responsibility of the network 1873 operator to ensure that only trusted Consumers are configured to 1874 receive such information. 1876 9. Contributors 1878 We would like to thank Robert Varga for the significant contribution 1879 he gave to this document. 1881 10. Acknowledgements 1883 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1884 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1885 Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, 1886 Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas 1887 Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, 1888 Balaji Rajagopalan and Yakov Rekhter for their comments. 1890 11. References 1892 11.1. Normative References 1894 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1895 dual environments", RFC 1195, December 1990. 1897 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1898 E. Lear, "Address Allocation for Private Internets", BCP 1899 5, RFC 1918, February 1996. 1901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1902 Requirement Levels", BCP 14, RFC 2119, March 1997. 1904 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1906 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1907 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1908 1999. 1910 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1911 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1912 Tunnels", RFC 3209, December 2001. 1914 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1915 Support of Generalized Multi-Protocol Label Switching 1916 (GMPLS)", RFC 4202, October 2005. 1918 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 1919 of Generalized Multi-Protocol Label Switching (GMPLS)", 1920 RFC 4203, October 2005. 1922 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1923 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1925 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1926 "Multiprotocol Extensions for BGP-4", RFC 4760, January 1927 2007. 1929 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1930 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1931 4915, June 2007. 1933 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1934 Specification", RFC 5036, October 2007. 1936 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1937 Topology (MT) Routing in Intermediate System to 1938 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1940 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 1941 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1942 February 2008. 1944 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1945 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1946 May 2008. 1948 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1949 Mechanism for IS-IS", RFC 5301, October 2008. 1951 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1952 Engineering", RFC 5305, October 2008. 1954 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1955 of Generalized Multi-Protocol Label Switching (GMPLS)", 1956 RFC 5307, October 2008. 1958 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1959 for IPv6", RFC 5340, July 2008. 1961 [RFC5890] Klensin, J., "Internationalized Domain Names for 1962 Applications (IDNA): Definitions and Document Framework", 1963 RFC 5890, August 2010. 1965 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1966 Engineering in IS-IS", RFC 6119, February 2011. 1968 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1969 Identifier for BGP-4", RFC 6286, June 2011. 1971 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1972 Instance Extensions", RFC 6549, March 2012. 1974 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 1975 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1977 11.2. Informative References 1979 [I-D.ietf-idr-error-handling] 1980 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1981 "Revised Error Handling for BGP UPDATE Messages", draft- 1982 ietf-idr-error-handling-18 (work in progress), December 1983 2014. 1985 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 1986 4272, January 2006. 1988 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1989 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1991 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1992 Shaffer, "Extensions to OSPF for Advertising Optional 1993 Router Capabilities", RFC 4970, July 2007. 1995 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1996 Extensions for Discovery of Traffic Engineering Node 1997 Capabilities", RFC 5073, December 2007. 1999 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 2000 Path Computation Method for Establishing Inter-Domain 2001 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 2002 5152, February 2008. 2004 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 2005 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2006 Traffic Engineering", RFC 5316, December 2008. 2008 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 2009 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2010 Traffic Engineering", RFC 5392, January 2009. 2012 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2013 Optimization (ALTO) Problem Statement", RFC 5693, October 2014 2009. 2016 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 2017 Management of New Protocols and Protocol Extensions", RFC 2018 5706, November 2009. 2020 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2021 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2022 and Authentication for Routing Protocols (KARP) Design 2023 Guide", RFC 6952, May 2013. 2025 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 2026 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 2027 Traffic Optimization (ALTO) Protocol", RFC 7285, September 2028 2014. 2030 Authors' Addresses 2032 Hannes Gredler (editor) 2033 Juniper Networks, Inc. 2034 1194 N. Mathilda Ave. 2035 Sunnyvale, CA 94089 2036 US 2038 Email: hannes@juniper.net 2040 Jan Medved 2041 Cisco Systems, Inc. 2042 170, West Tasman Drive 2043 San Jose, CA 95134 2044 US 2046 Email: jmedved@cisco.com 2048 Stefano Previdi 2049 Cisco Systems, Inc. 2050 Via Del Serafico, 200 2051 Rome 00142 2052 Italy 2054 Email: sprevidi@cisco.com 2056 Adrian Farrel 2057 Juniper Networks, Inc. 2058 1194 N. Mathilda Ave. 2059 Sunnyvale, CA 94089 2060 US 2062 Email: afarrel@juniper.net 2064 Saikat Ray 2066 Email: raysaikat@gmail.com