idnits 2.17.1 draft-ietf-idr-ls-distribution-10.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 (January 26, 2015) is 3350 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 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: July 30, 2015 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 Cisco Systems, Inc. 11 January 26, 2015 13 North-Bound Distribution of Link-State and TE Information using BGP 14 draft-ietf-idr-ls-distribution-10 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 July 30, 2015. 58 Copyright Notice 60 Copyright (c) 2015 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 . . . . . . . . . . . 37 103 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . . . . . 38 111 6.2.3. Configuration Management . . . . . . . . . . . . . . 38 112 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39 113 6.2.5. Performance Management . . . . . . . . . . . . . . . 39 114 6.2.6. Security Management . . . . . . . . . . . . . . . . . 39 115 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39 116 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 117 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 120 11.1. Normative References . . . . . . . . . . . . . . . . . . 42 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 [RFC7285]. 285 ALTO abstract network topologies can be auto-generated from the 286 physical topology of the underlying network. The generation would 287 typically be based on policies and rules set by the operator. Both 288 prefix and TE data are required: prefix data is required to generate 289 ALTO Network Maps, TE (topology) data is required to generate ALTO 290 Cost Maps. Prefix data is carried and originated in BGP, TE data is 291 originated and carried in an IGP. The mechanism defined in this 292 document provides a single interface through which an ALTO Server can 293 retrieve all the necessary prefix and network topology data from the 294 underlying network. Note an ALTO Server can use other mechanisms to 295 get network data, for example, peering with multiple IGP and BGP 296 Speakers. 298 The following figure shows how an ALTO Server can get network 299 topology information from the underlying network using the mechanism 300 described in this document. 302 +--------+ 303 | Client |<--+ 304 +--------+ | 305 | ALTO +--------+ BGP with +---------+ 306 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 307 | Client |<--+------------| Server |<----------------| Speaker | 308 +--------+ | | | | | 309 | +--------+ +---------+ 310 +--------+ | 311 | Client |<--+ 312 +--------+ 314 Figure 3: ALTO Server using network topology information 316 3. Carrying Link State Information in BGP 318 This specification contains two parts: definition of a new BGP NLRI 319 that describes links, nodes and prefixes comprising IGP link state 320 information, and definition of a new BGP path attribute (BGP-LS 321 attribute) that carries link, node and prefix properties and 322 attributes, such as the link and prefix metric or auxiliary Router- 323 IDs of nodes, etc. 325 It is desired to keep the dependencies on the protocol source of this 326 attributes to a minimum and represent any content in an IGP neutral 327 way, such that applications which do want to learn about a Link-state 328 topology do not need to know about any OSPF or IS-IS protocol 329 specifics. 331 3.1. TLV Format 333 Information in the new Link-State NLRIs and attributes is encoded in 334 Type/Length/Value triplets. The TLV format is shown in Figure 4. 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 // Value (variable) // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 4: TLV format 346 The Length field defines the length of the value portion in octets 347 (thus a TLV with no value portion would have a length of zero). The 348 TLV is not padded to four-octet alignment. Unrecognized types 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_NLRI and MP_UNREACH_NLRI attributes are BGP's containers 359 for carrying opaque information. Each Link-State NLRI describes 360 either a 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 TBD. 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 TBD 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 TBD 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 The 'Direct' and 'Static' protocol types SHOULD be used when BGP-LS 486 is sourcing local information. For all information, derived from 487 other protocols the corresponding protocol-ID MUST be used. If BGP- 488 LS has got direct access to interface information and wants to 489 advertise a local link then the protocol-ID 'Direct' SHOULD be used. 490 For modeling virtual links, like described in Section 4 the protocol- 491 ID 'Static configuration' SHOULD be used. 493 Both OSPF and IS-IS MAY run multiple routing protocol instances over 494 the same link. See [RFC6822] and [RFC6549]. These instances define 495 independent "routing universes". The 64-Bit 'Identifier' field is 496 used to identify the "routing universe" where the NLRI belongs. The 497 NLRIs representing Link-state objects (nodes, links or prefixes) from 498 the same routing universe MUST have the same 'Identifier' value; 499 NLRIs with different 'Identifier' values MUST be considered to be 500 from different routing universes. Table Table 3 lists the 501 'Identifier' values that are defined as well-known in this draft. 503 +------------+----------------------------------+ 504 | Identifier | Routing Universe | 505 +------------+----------------------------------+ 506 | 0 | Default Layer 3 Routing topology | 507 | 1-31 | Reserved | 508 +------------+----------------------------------+ 510 Table 3: Well-known Instance Identifiers 512 If a given Protocol does not support multiple routing universes then 513 it SHOULD set the 'Identifier' field according to Table 3. However 514 an implementation MAY make the 'Identifier' configurable, for a given 515 protocol. 517 Each Node Descriptor and Link Descriptor consists of one or more TLVs 518 described in the following sections. 520 3.2.1. Node Descriptors 522 Each link is anchored by a pair of Router-IDs that are used by the 523 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 524 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 525 additional auxiliary Router-IDs, mainly for traffic engineering 526 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 527 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 528 included in the link attribute described in Section Section 3.3.2. 530 It is desirable that the Router-ID assignments inside the Node 531 Descriptor are globally unique. However there may be Router-ID 532 spaces (e.g. ISO) where no global registry exists, or worse, Router- 533 IDs have been allocated following private-IP RFC 1918 [RFC1918] 534 allocation. We use Autonomous System (AS) Number and BGP-LS 535 Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as 536 described in Section 3.2.1.1. 538 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 540 One problem that needs to be addressed is the ability to identify an 541 IGP node globally (by "global", we mean within the BGP-LS database 542 collected by all BGP-LS speakers that talk to each other). This can 543 be expressed through the following two requirements: 545 (A) The same node must not be represented by two keys (otherwise one 546 node will look like two nodes). 548 (B) Two different nodes must not be represented by the same key 549 (otherwise, two nodes will look like one node). 551 We define an "IGP domain" to be the set of nodes (hence, by extension 552 links and prefixes), within which, each node has a unique IGP 553 representation by using the combination of Area-ID, Router-ID, 554 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 555 receive node/link/prefix information from multiple independent "IGP 556 domains" and we need to distinguish between them. Moreover, we can't 557 assume there is always one and only one IGP domain per AS. During 558 IGP transitions it may happen that two redundant IGPs are in place. 560 In section Section 3.2.1.4 a set of sub-TLVs is described, which 561 allows specification of a flexible key for any given Node/Link 562 information such that global uniqueness of the NLRI is ensured. 564 3.2.1.2. Local Node Descriptors 566 The Local Node Descriptors TLV contains Node Descriptors for the node 567 anchoring the local end of the link. This is a mandatory TLV in all 568 three types of NLRIs. The length of this TLV is variable. The value 569 contains one or more Node Descriptor Sub-TLVs defined in 570 Section 3.2.1.4. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 // Node Descriptor Sub-TLVs (variable) // 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 10: Local Node Descriptors TLV format 584 3.2.1.3. Remote Node Descriptors 586 The Remote Node Descriptors contains Node Descriptors for the node 587 anchoring the remote end of the link. This is a mandatory TLV for 588 link NLRIs. The length of this TLV is variable. The value contains 589 one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Length | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | | 597 // Node Descriptor Sub-TLVs (variable) // 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 11: Remote Node Descriptors TLV format 603 3.2.1.4. Node Descriptor Sub-TLVs 605 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 606 the following table: 608 +--------------------+-------------------+----------+ 609 | Sub-TLV Code Point | Description | Length | 610 +--------------------+-------------------+----------+ 611 | 512 | Autonomous System | 4 | 612 | 513 | BGP-LS Identifier | 4 | 613 | 514 | OSPF Area-ID | 4 | 614 | 515 | IGP Router-ID | Variable | 615 +--------------------+-------------------+----------+ 617 Table 4: Node Descriptor Sub-TLVs 619 The sub-TLV values in Node Descriptor TLVs are defined as follows: 621 Autonomous System: opaque value (32 Bit AS Number) 623 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 624 ASN, uniquely identifies the BGP-LS domain. The combination of 625 ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers 626 within an IGP flooding-set (set of IGP nodes within which an LSP/ 627 LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP 628 domain consists of multiple flooding-sets, then all BGP-LS 629 speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID 630 tuple. The ASN, BGP Router-ID tuple (which is globally unique 631 [RFC6286] ) of one of the BGP-LS speakers within the flooding-set 632 (or IGP domain) may be used for all BGP-LS speakers in that 633 flooding-set (or IGP domain). 635 Area ID: It is used to identify the 32 Bit area to which the NLRI 636 belongs. Area Identifier allows the different NLRIs of the same 637 router to be discriminated. 639 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 640 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 641 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 642 octet ISO node-ID of the "Designated Intermediate System" (DIS) 643 followed by one octet nonzero PSN identifier (7 octets in total). 644 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains the 4 645 octet Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, 646 this contains the 4 octet Router-ID of the designated router (DR) 647 followed by the 4 octet IPv4 address of the DR's interface to the 648 LAN (8 octets in total). Similarly, for an OSPFv3 "Pseudonode", 649 this contains the 4 octet Router-ID of the DR followed by the 4 650 octet interface identifier of the DR's interface to the LAN (8 651 octets in total). The TLV size in combination with protocol 652 identifier enables the decoder to determine the type of the node. 654 There can be at most one instance of each sub-TLV type present in 655 any Node Descriptor. The sub-TLVs within a Node descriptor MUST 656 be arranged in ascending order by sub-TLV type. This needs to be 657 done in order to compare NLRIs, even when an implementation 658 encounters an unknown sub-TLV. Using stable sorting an 659 implementation can do binary comparison of NLRIs and hence allow 660 incremental deployment of new key sub-TLVs. 662 3.2.1.5. Multi-Topology ID 664 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 665 Multi-Topology IDs for a link, node or prefix. 667 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 668 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 669 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 670 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 671 SHOULD be set to 0 when originated and ignored on receipt. 673 The format of the MT-ID TLV is shown in the following figure. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Type | Length=2*n | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 |R R R R| Multi-Topology ID 1 | .... // 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 // .... |R R R R| Multi-Topology ID n | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Figure 12: Multi-Topology ID TLV format 687 where Type is 263, Length is 2*n and n is the number of MT-IDs 688 carried in the TLV. 690 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 691 Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or 692 Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of 693 the topology where the link or the prefix is reachable is allowed. 694 In case one wants to advertise multiple topologies for a given Link 695 Descriptor or Prefix Descriptor, multiple NRLIs need to be generated 696 where each NLRI contains an unique MT-ID. In the BGP-LS attribute of 697 a node NLRI, one MT-ID TLV containing the array of MT-IDs of all 698 topologies where the node is reachable is allowed. 700 3.2.2. Link Descriptors 702 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 703 triplets. The format of each TLV is shown in Section 3.1. The 'Link 704 descriptor' TLVs uniquely identify a link among multiple parallel 705 links between a pair of anchor routers. A link described by the Link 706 descriptor TLVs actually is a "half-link", a unidirectional 707 representation of a logical link. In order to fully describe a 708 single logical link, two originating routers advertise a half-link 709 each, i.e., two link NLRIs are advertised for a given point-to-point 710 link. 712 The format and semantics of the 'value' fields in most 'Link 713 Descriptor' TLVs correspond to the format and semantics of value 714 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 715 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 716 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 717 carry data sourced either by IS-IS or OSPF. 719 The following TLVs are valid as Link Descriptors in the Link NLRI: 721 +-----------+---------------------+---------------+-----------------+ 722 | TLV Code | Description | IS-IS TLV | Value defined | 723 | Point | | /Sub-TLV | in: | 724 +-----------+---------------------+---------------+-----------------+ 725 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 726 | | Identifiers | | | 727 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 728 | | address | | | 729 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 730 | | address | | | 731 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 732 | | address | | | 733 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 734 | | address | | | 735 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 736 | | Identifier | | | 737 +-----------+---------------------+---------------+-----------------+ 739 Table 5: Link Descriptor TLVs 741 The information about a link present in the LSA/LSP originated by the 742 local node of the link determines the set of TLVs in the Link 743 Descriptor of the link. 745 If interface and neighbor addresses, either IPv4 or IPv6, are 746 present, then the IP address TLVs are included in the link 747 descriptor, but not the link local/remote Identifier TLV. The 748 link local/remote identifiers MAY be included in the link 749 attribute. 751 If interface and neighbor addresses are not present and the link 752 local/remote identifiers are present, then the link local/remote 753 Identifier TLV is included in the link descriptor. 755 The Multi-Topology Identifier TLV is included in link descriptor 756 if that information is present. 758 3.2.3. Prefix Descriptors 760 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 761 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 762 Prefix originated by a Node. The following TLVs are valid as Prefix 763 Descriptors in the IPv4/IPv6 Prefix NLRI: 765 +--------------+-----------------------+----------+-----------------+ 766 | TLV Code | Description | Length | Value defined | 767 | Point | | | in: | 768 +--------------+-----------------------+----------+-----------------+ 769 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 770 | | Identifier | | | 771 | 264 | OSPF Route Type | 1 | Section 3.2.3.1 | 772 | 265 | IP Reachability | variable | Section 3.2.3.2 | 773 | | Information | | | 774 +--------------+-----------------------+----------+-----------------+ 776 Table 6: Prefix Descriptor TLVs 778 3.2.3.1. OSPF Route Type 780 OSPF Route Type is an optional TLV that MAY be present in Prefix 781 NLRIs. It is used to identify the OSPF route-type of the prefix. It 782 is used when an OSPF prefix is advertised in the OSPF domain with 783 multiple route-types. The Route Type TLV allows to discrimination of 784 these advertisements. The format of the OSPF Route Type TLV is shown 785 in the following figure. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type | Length | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Route Type | 793 +-+-+-+-+-+-+-+-+ 795 Figure 13: OSPF Route Type TLV Format 797 where the Type and Length fields of the TLV are defined in Table 6. 798 The OSPF Route Type field values are defined in the OSPF protocol, 799 and can be one of the following: 801 Intra-Area (0x1) 803 Inter-Area (0x2) 805 External 1 (0x3) 807 External 2 (0x4) 809 NSSA 1 (0x5) 811 NSSA 2 (0x6) 813 3.2.3.2. IP Reachability Information 815 The IP Reachability Information is a mandatory TLV that contains one 816 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 817 topology. Its purpose is to glue a particular BGP service NLRI by 818 virtue of its BGP next-hop to a given Node in the LSDB. A router 819 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 820 The format of the IP Reachability Information TLV is shown in the 821 following figure: 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type | Length | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Prefix Length | IP Prefix (variable) // 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Figure 14: IP Reachability Information TLV Format 833 The Type and Length fields of the TLV are defined in Table 6. The 834 following two fields determine the address-family reachability 835 information. The 'Prefix Length' field contains the length of the 836 prefix in bits. The 'IP Prefix' field contains the most significant 837 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 838 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 839 24 and 4 octets for prefix length 25 up to 32, etc. 841 3.3. The BGP-LS Attribute 843 This is an optional, non-transitive BGP attribute that is used to 844 carry link, node and prefix parameters and attributes. It is defined 845 as a set of Type/Length/Value (TLV) triplets, described in the 846 following section. This attribute SHOULD only be included with Link- 847 State NLRIs. This attribute MUST be ignored for all other address- 848 families. 850 3.3.1. Node Attribute TLVs 852 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 853 attribute with a node NLRI. The following node attribute TLVs are 854 defined: 856 +--------------+-----------------------+----------+-----------------+ 857 | TLV Code | Description | Length | Value defined | 858 | Point | | | in: | 859 +--------------+-----------------------+----------+-----------------+ 860 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 861 | | Identifier | | | 862 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 863 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 864 | | Properties | | | 865 | 1026 | Node Name | variable | Section 3.3.1.3 | 866 | 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 | 867 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 868 | | Local Node | | | 869 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 870 | | Local Node | | | 871 +--------------+-----------------------+----------+-----------------+ 873 Table 7: Node Attribute TLVs 875 3.3.1.1. Node Flag Bits TLV 877 The Node Flag Bits TLV carries a bit mask describing node attributes. 878 The value is a variable length bit array of flags, where each bit 879 represents a node capability. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Type | Length | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 |O|T|E|B| Reserved| 887 +-+-+-+-+-+-+-+-+-+ 889 Figure 15: Node Flag Bits TLV format 891 The bits are defined as follows: 893 +----------+-------------------------+-----------+ 894 | Bit | Description | Reference | 895 +----------+-------------------------+-----------+ 896 | 'O' | Overload Bit | [RFC1195] | 897 | 'T' | Attached Bit | [RFC1195] | 898 | 'E' | External Bit | [RFC2328] | 899 | 'B' | ABR Bit | [RFC2328] | 900 | Reserved | Reserved for future use | | 901 +----------+-------------------------+-----------+ 903 Table 8: Node Flag Bits Definitions 905 3.3.1.2. IS-IS Area Identifier TLV 907 An IS-IS node can be part of one or more IS-IS areas. Each of these 908 area addresses is carried in the IS-IS Area Identifier TLV. If 909 multiple Area Addresses are present, multiple TLVs are used to encode 910 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 911 attribute only when advertised in the Link-State Node NLRI. 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Type | Length | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 // Area Identifier (variable) // 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Figure 16: IS-IS Area Identifier TLV Format 923 3.3.1.3. Node Name TLV 925 The Node Name TLV is optional. Its structure and encoding has been 926 borrowed from [RFC5301]. The value field identifies the symbolic 927 name of the router node. This symbolic name can be the FQDN for the 928 router, it can be a subset of the FQDN, or it can be any string 929 operators want to use for the router. The use of FQDN or a subset of 930 it is strongly RECOMMENDED. The maximum length of the 'Node Name 931 TLV' is 255 octets. 933 The Value field is encoded in 7-bit ASCII. If a user-interface for 934 configuring or displaying this field permits Unicode characters, that 935 user-interface is responsible for applying the ToASCII and/or 936 ToUnicode algorithm as described in [RFC5890] to achieve the correct 937 format for transmission or display. 939 Although [RFC5301] is an IS-IS specific extension, usage of the Node 940 Name TLV is possible for all protocols. How a router derives and 941 injects node names for e.g. OSPF nodes, is outside of the scope of 942 this document. 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 // Node Name (variable) // 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 Figure 17: Node Name format 954 3.3.1.4. Local IPv4/IPv6 Router-ID 956 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 957 Router-IDs that the IGP might be using, e.g., for TE and migration 958 purposes like correlating a Node-ID between different protocols. If 959 there is more than one auxiliary Router-ID of a given type, then each 960 one is encoded in its own TLV. 962 3.3.1.5. Opaque Node Attribute TLV 964 The Opaque Node Attribute TLV is an envelope that transparently 965 carries optional node attribute TLVs advertised by a router. An 966 originating router shall use this TLV for encoding information 967 specific to the protocol advertised in the NLRI header Protocol-ID 968 field or new protocol extensions to the protocol as advertised in the 969 NLRI header Protocol-ID field for which there is no protocol neutral 970 representation in the BGP link-state NLRI. The primary use of the 971 Opaque Node Attribute TLV is to bridge the document lag between e.g. 972 a new IGP Link-state attribute being defined and the 'protocol- 973 neutral' BGP-LS extensions being published. A router for example 974 could use this extension in order to advertise the native protocols 975 node attribute TLVs, such as the OSPF Router Informational 976 Capabilities TLV defined in [RFC4970], or the IGP TE Node Capability 977 Descriptor TLV described in [RFC5073]. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type | Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 // Opaque node attributes (variable) // 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Figure 18: Opaque Node attribute format 989 3.3.2. Link Attribute TLVs 991 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 992 attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ 993 Value (TLV) triplet formatted as defined in Section 3.1. The format 994 and semantics of the 'value' fields in some 'Link Attribute' TLVs 995 correspond to the format and semantics of value fields in IS-IS 996 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 997 [RFC5307]. Other 'Link Attribute' TLVs are defined in this document. 998 Although the encodings for 'Link Attribute' TLVs were originally 999 defined for IS-IS, the TLVs can carry data sourced either by IS-IS or 1000 OSPF. 1002 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 1003 attribute: 1005 +-----------+---------------------+--------------+------------------+ 1006 | TLV Code | Description | IS-IS TLV | Defined in: | 1007 | Point | | /Sub-TLV | | 1008 +-----------+---------------------+--------------+------------------+ 1009 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1010 | | Local Node | | | 1011 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1012 | | Local Node | | | 1013 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1014 | | Remote Node | | | 1015 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1016 | | Remote Node | | | 1017 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1018 | | group (color) | | | 1019 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1020 | | bandwidth | | | 1021 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1022 | | link bandwidth | | | 1023 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1024 | | bandwidth | | | 1025 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3/ | 1026 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1027 | | Type | | | 1028 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1029 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1030 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1031 | | Group | | | 1032 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1033 | | attribute | | | 1034 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1035 +-----------+---------------------+--------------+------------------+ 1037 Table 9: Link Attribute TLVs 1039 3.3.2.1. IPv4/IPv6 Router-ID 1041 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1042 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1043 purposes. All auxiliary Router-IDs of both the local and the remote 1044 node MUST be included in the link attribute of each link NLRI. If 1045 there are more than one auxiliary Router-ID of a given type, then 1046 multiple TLVs are used to encode them. 1048 3.3.2.2. MPLS Protocol Mask TLV 1050 The MPLS Protocol TLV carries a bit mask describing which MPLS 1051 signaling protocols are enabled. The length of this TLV is 1. The 1052 value is a bit array of 8 flags, where each bit represents an MPLS 1053 Protocol capability. 1055 Generation of the MPLS Protocol Mask TLV is only valid for 1056 originators which have local link insight, like for example Protocol- 1057 IDs 'Static' or 'Direct' as per Table 2. The 'MPLS Protocol Mask' 1058 TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS- 1059 IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2. 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type | Length | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 |L|R| Reserved | 1067 +-+-+-+-+-+-+-+-+ 1069 Figure 19: MPLS Protocol TLV 1071 The following bits are defined: 1073 +------------+------------------------------------------+-----------+ 1074 | Bit | Description | Reference | 1075 +------------+------------------------------------------+-----------+ 1076 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1077 | 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] | 1078 | | TE) | | 1079 | 'Reserved' | Reserved for future use | | 1080 +------------+------------------------------------------+-----------+ 1082 Table 10: MPLS Protocol Mask TLV Codes 1084 3.3.2.3. TE Default Metric TLV 1086 The TE Default Metric TLV carries the TE-metric for this link. The 1087 length of this TLV is fixed at 4 octets. If a source protocol (e.g. 1088 IS-IS) does not support a Metric width of 32 bits then the high order 1089 octet MUST be set to zero. 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Type | Length | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | TE Default Link Metric | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Figure 20: TE Default Metric TLV format 1101 3.3.2.4. IGP Metric TLV 1103 The IGP Metric TLV carries the metric for this link. The length of 1104 this TLV is variable, depending on the metric width of the underlying 1105 protocol. IS-IS small metrics have a length of 1 octet (the two most 1106 significant bits are ignored). OSPF link metrics have a length of 1107 two octets. IS-IS wide-metrics have a length of three octets. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Type | Length | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 // IGP Link Metric (variable length) // 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 Figure 21: Metric TLV format 1119 3.3.2.5. Shared Risk Link Group TLV 1121 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1122 Group information (see Section 2.3, "Shared Risk Link Group 1123 Information", of [RFC4202]). It contains a data structure consisting 1124 of a (variable) list of SRLG values, where each element in the list 1125 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1126 (number of SRLG values). 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Type | Length | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Shared Risk Link Group Value | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 // ............ // 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Shared Risk Link Group Value | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 Figure 22: Shared Risk Link Group TLV format 1142 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 1143 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1144 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1145 defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG 1146 information are carried in a single TLV. 1148 3.3.2.6. Opaque Link Attribute TLV 1150 The Opaque link Attribute TLV is an envelope that transparently 1151 carries optional link attribute TLVs advertised by a router. An 1152 originating router shall use this TLV for encoding information 1153 specific to the protocol advertised in the NLRI header Protocol-ID 1154 field or new protocol extensions to the protocol as advertised in the 1155 NLRI header Protocol-ID field for which there is no protocol neutral 1156 representation in the BGP link-state NLRI. The primary use of the 1157 Opaque Link Attribute TLV is to bridge the document lag between e.g. 1158 a new IGP Link-state attribute being defined and the 'protocol- 1159 neutral' BGP-LS extensions being published. 1161 0 1 2 3 1162 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Type | Length | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 // Opaque link attributes (variable) // 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Figure 23: Opaque link attribute format 1171 3.3.2.7. Link Name TLV 1173 The Link Name TLV is optional. The value field identifies the 1174 symbolic name of the router link. This symbolic name can be the FQDN 1175 for the link, it can be a subset of the FQDN, or it can be any string 1176 operators want to use for the link. The use of FQDN or a subset of 1177 it is strongly RECOMMENDED. The maximum length of the 'Link Name 1178 TLV' is 255 octets. 1180 The Value field is encoded in 7-bit ASCII. If a user-interface for 1181 configuring or displaying this field permits Unicode characters, that 1182 user-interface is responsible for applying the ToASCII and/or 1183 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1184 format for transmission or display. 1186 How a router derives and injects link names is outside of the scope 1187 of this document. 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Type | Length | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 // Link Name (variable) // 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Figure 24: Link Name format 1199 3.3.3. Prefix Attribute TLVs 1201 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1202 of IGP attributes (such as metric, route tags, etc.) that MUST be 1203 reflected into the LINK_STATE attribute. This section describes the 1204 different attributes related to the IPv4/IPv6 prefixes. Prefix 1205 Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 1206 only. The following attributes TLVs are defined: 1208 +---------------+----------------------+----------+-----------------+ 1209 | TLV Code | Description | Length | Reference | 1210 | Point | | | | 1211 +---------------+----------------------+----------+-----------------+ 1212 | 1152 | IGP Flags | 1 | Section 3.3.3.1 | 1213 | 1153 | Route Tag | 4*n | Section 3.3.3.2 | 1214 | 1154 | Extended Tag | 8*n | Section 3.3.3.3 | 1215 | 1155 | Prefix Metric | 4 | Section 3.3.3.4 | 1216 | 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 | 1217 | | Address | | | 1218 | 1157 | Opaque Prefix | variable | Section 3.3.3.6 | 1219 | | Attribute | | | 1220 +---------------+----------------------+----------+-----------------+ 1222 Table 11: Prefix Attribute TLVs 1224 3.3.3.1. IGP Flags TLV 1226 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1227 assigned tothe prefix. The IGP Flags TLV is encoded as follows: 1229 0 1 2 3 1230 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 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Type | Length | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 |D|N|L|P| Resvd.| 1235 +-+-+-+-+-+-+-+-+ 1237 Figure 25: IGP Flag TLV format 1239 The value field contains bits defined according to the table below: 1241 +----------+---------------------------+-----------+ 1242 | Bit | Description | Reference | 1243 +----------+---------------------------+-----------+ 1244 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1245 | 'N' | OSPF "no unicast" Bit | [RFC5340] | 1246 | 'L' | OSPF "local address" Bit | [RFC5340] | 1247 | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | 1248 | Reserved | Reserved for future use. | | 1249 +----------+---------------------------+-----------+ 1251 Table 12: IGP Flag Bits Definitions 1253 3.3.3.2. Route Tag 1255 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1256 the prefix and is encoded as follows: 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Type | Length | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 // Route Tags (one or more) // 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 Figure 26: IGP Route TAG TLV format 1268 Length is a multiple of 4. 1270 The value field contains one or more Route Tags as learned in the IGP 1271 topology. 1273 3.3.3.3. Extended Route Tag 1275 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1276 prefix [RFC5130] and is encoded as follows: 1278 0 1 2 3 1279 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 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Type | Length | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 // Extended Route Tag (one or more) // 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 Figure 27: Extended IGP Route TAG TLV format 1288 Length is a multiple of 8. 1290 The 'Extended Route Tag' field contains one or more Extended Route 1291 Tags as learned in the IGP topology. 1293 3.3.3.4. Prefix Metric TLV 1295 Prefix Metric TLV is an optional attribute and may only appear once. 1296 If present, it carries the metric of the prefix as known in the IGP 1297 topology [RFC5305] (and therefore represents the reachability cost to 1298 the prefix). If not present, it means that the prefix is advertised 1299 without any reachability. 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Type | Length | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Metric | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 Figure 28: Prefix Metric TLV Format 1311 Length is 4. 1313 3.3.3.5. OSPF Forwarding Address TLV 1315 OSPF Forwarding Address TLV [RFC2328] and [RFC5340] carries the OSPF 1316 forwarding address as known in the original OSPF advertisement. 1317 Forwarding address can be either IPv4 or IPv6. 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Type | Length | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 // Forwarding Address (variable) // 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Figure 29: OSPF Forwarding Address TLV Format 1329 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1330 forwarding address. 1332 3.3.3.6. Opaque Prefix Attribute TLV 1334 The Opaque Prefix Attribute TLV is an envelope that transparently 1335 carries optional prefix attribute TLVs advertised by a router. An 1336 originating router shall use this TLV for encoding information 1337 specific to the protocol advertised in the NLRI header Protocol-ID 1338 field or new protocol extensions to the protocol as advertised in the 1339 NLRI header Protocol-ID field for which there is no protocol neutral 1340 representation in the BGP link-state NLRI. The primary use of the 1341 Opaque Prefix Attribute TLV is to bridge the document lag between 1342 e.g. a new IGP Link-state attribute being defined and the 'protocol- 1343 neutral' BGP-LS extensions being published. 1345 The format of the TLV is as follows: 1347 0 1 2 3 1348 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 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Type | Length | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 // Opaque Prefix Attributes (variable) // 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 Figure 30: Opaque Prefix Attribute TLV Format 1357 Type is as specified in Table 11 and Length is variable. 1359 3.4. BGP Next Hop Information 1361 BGP link-state information for both IPv4 and IPv6 networks can be 1362 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1363 an IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1364 SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is 1365 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 1366 address. Usually the next hop will be set to the local end-point 1367 address of the BGP session. The next hop address MUST be encoded as 1368 described in [RFC4760]. The length field of the next hop address 1369 will specify the next hop address-family. If the next hop length is 1370 4, then the next hop is an IPv4 address; if the next hop length is 1371 16, then it is a global IPv6 address and if the next hop length is 1372 32, then there is one global IPv6 address followed by a link-local 1373 IPv6 address. The link-local IPv6 address should be used as 1374 described in [RFC2545]. For VPN SAFI, as per custom, an 8 byte 1375 route-distinguisher set to all zero is prepended to the next hop. 1377 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1378 the NLRI it receives. In case identical NLRIs are sourced by 1379 multiple originators the BGP next hop attribute is used to tie-break 1380 as per the standard BGP path decision process. This specification 1381 doesn't mandate any rule regarding the re-write of the BGP Next Hop 1382 attribute. 1384 3.5. Inter-AS Links 1386 The main source of TE information is the IGP, which is not active on 1387 inter-AS links. In some cases, the IGP may have information of 1388 inter-AS links ([RFC5392], [RFC5316]). In other cases, an 1389 implementation SHOULD provide a means to inject inter-AS links into 1390 BGP-LS. The exact mechanism used to provision the inter-AS links is 1391 outside the scope of this document 1393 3.6. Router-ID Anchoring Example: ISO Pseudonode 1395 Encoding of a broadcast LAN in IS-IS provides a good example of how 1396 Router-IDs are encoded. Consider Figure 31. This represents a 1397 Broadcast LAN between a pair of routers. The "real" (=non 1398 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1399 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1400 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1401 (Pseudonode1, Node2) are being generated. 1403 The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP 1404 Router-ID TLV of the local node descriptor is 6 octets long 1405 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1406 the remote node descriptor is 7 octets long containing the ISO-ID of 1407 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1408 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1409 192.0.2.1, the IPv4 Router-ID of Node1. 1411 The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP 1412 Router-ID TLV of the local node descriptor is 7 octets long 1413 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1414 Router-ID TLV of the remote node descriptor is 6 octets long 1415 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1416 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1417 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1419 +-----------------+ +-----------------+ +-----------------+ 1420 | Node1 | | Pseudonode1 | | Node2 | 1421 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1422 | 192.0.2.1 | | | | 192.0.2.2 | 1423 +-----------------+ +-----------------+ +-----------------+ 1425 Figure 31: IS-IS Pseudonodes 1427 3.7. Router-ID Anchoring Example: OSPF Pseudonode 1429 Encoding of a broadcast LAN in OSPF provides a good example of how 1430 Router-IDs and local Interface IPs are encoded. Consider Figure 32. 1431 This represents a Broadcast LAN between a pair of routers. The 1432 "real" (=non pseudonode) routers have both an IPv4 Router-ID and an 1433 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 1434 interface Address (for disambiguation) and an OSPF Area. Node1 is 1435 the DR for the LAN, hence its local IP address 10.1.1.1 is used both 1436 as the Router-ID and Interface IP for the Pseudonode keys. Two 1437 unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2) 1438 are being generated. 1440 The link NRLI of (Node1, Pseudonode1) is encoded as follows: 1442 o Local Node Descriptor 1444 TLV #515: IGP Router ID: 11.11.11.11 1446 TLV #514: OSPF Area-ID: ID:0.0.0.0 1448 o Remote Node Descriptor 1450 TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 1452 TLV #514: OSPF Area-ID: ID:0.0.0.0 1454 The link NRLI of (Pseudonode1, Node2) is encoded as follows: 1456 o Local Node Descriptor 1458 TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 1460 TLV #514: OSPF Area-ID: ID:0.0.0.0 1462 o Remote Node Descriptor 1463 TLV #515: IGP Router ID: 33.33.33.34 1465 TLV #514: OSPF Area-ID: ID:0.0.0.0 1467 +-----------------+ +-----------------+ +-----------------+ 1468 | Node1 | | Pseudonode1 | | Node2 | 1469 | 11.11.11.11 |--->| 10.1.1.1 |--->| 33.33.33.34 | 1470 | | | 10.1.1.1 | | | 1471 | Area 0 | | Area 0 | | Area 0 | 1472 +-----------------+ +-----------------+ +-----------------+ 1474 Figure 32: OSPF Pseudonodes 1476 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1478 Graceful migration from one IGP to another requires coordinated 1479 operation of both protocols during the migration period. Such a 1480 coordination requires identifying a given physical link in both IGPs. 1481 The IPv4 Router-ID provides that "glue" which is present in the node 1482 descriptors of the OSPF link NLRI and in the link attribute of the 1483 IS-IS link NLRI. 1485 Consider a point-to-point link between two routers, A and B, that 1486 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1487 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1488 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1489 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1490 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1491 in the local and remote node descriptors, respectively. The IS-IS 1492 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1493 the local and remote node descriptors, respectively. In addition, 1494 the BGP-LS attribute of the IS-IS link NLRI contains the TLV type 1495 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1496 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1497 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1498 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1500 4. Link to Path Aggregation 1502 Distribution of all links available in the global Internet is 1503 certainly possible, however not desirable from a scaling and privacy 1504 point of view. Therefore an implementation may support link to path 1505 aggregation. Rather than advertising all specific links of a domain, 1506 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1507 of nodes. The "aggregate link" represents the aggregated set of link 1508 properties between a pair of non-adjacent nodes. The actual methods 1509 to compute the path properties (of bandwidth, metric) are outside the 1510 scope of this document. The decision whether to advertise all 1511 specific links or aggregated links is an operator's policy choice. 1512 To highlight the varying levels of exposure, the following deployment 1513 examples are discussed. 1515 4.1. Example: No Link Aggregation 1517 Consider Figure 33. Both AS1 and AS2 operators want to protect their 1518 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1519 compute its link-protection LSP to R3 it needs to "see" an alternate 1520 path to R3. Therefore the AS2 operator exposes its topology. All 1521 BGP TE enabled routers in AS1 "see" the full topology of AS and 1522 therefore can compute a backup path. Note that the decision if the 1523 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1524 by the computing router. 1526 AS1 : AS2 1527 : 1528 R1-------R3 1529 | : | \ 1530 | : | R5 1531 | : | / 1532 R2-------R4 1533 : 1534 : 1536 Figure 33: No link aggregation 1538 4.2. Example: ASBR to ASBR Path Aggregation 1540 The brief difference between the "no-link aggregation" example and 1541 this example is that no specific link gets exposed. Consider 1542 Figure 34. The only link which gets advertised by AS2 is an 1543 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1544 there is a backup path. However the actual links being used are 1545 hidden from the topology. 1547 AS1 : AS2 1548 : 1549 R1-------R3 1550 | : | 1551 | : | 1552 | : | 1553 R2-------R4 1554 : 1555 : 1557 Figure 34: ASBR link aggregation 1559 4.3. Example: Multi-AS Path Aggregation 1561 Service providers in control of multiple ASes may even decide to not 1562 expose their internal inter-AS links. Consider Figure 35. AS3 is 1563 modeled as a single node which connects to the border routers of the 1564 aggregated domain. 1566 AS1 : AS2 : AS3 1567 : : 1568 R1-------R3----- 1569 | : : \ 1570 | : : vR0 1571 | : : / 1572 R2-------R4----- 1573 : : 1574 : : 1576 Figure 35: Multi-AS aggregation 1578 5. IANA Considerations 1580 This document requests a code point from the registry of Address 1581 Family Numbers. As per early allocation procedure this is AFI 16388. 1583 This document requests a code point from the registry of Subsequent 1584 Address Family Numbers named 'BGP-LS'. As per early allocation 1585 procedure this is SAFI 71. 1587 This document requests a code point from the registry of Subsequent 1588 Address Family Numbers named 'BGP-LS-VPN'. The SAFI assignment does 1589 NOT need to be out of the range 1-63. 1591 This document requests a code point from the BGP Path Attributes 1592 registry. As per early allocation procedure this is Path Attribute 1593 29. 1595 All the following Registries are BGP-LS specific and shall be 1596 acessible under the following URL: "http://www.iana.org/assignments/ 1597 bgp-ls-parameters" Title "Border Gateway Protocol - Link State (BGP- 1598 LS) Parameters" 1600 This document requests creation of a new registry for BGP-LS NLRI- 1601 Types. Value 0 is reserved. The maximum value is 65535. The 1602 registry will be initialized as shown in Table 1. Allocations within 1603 the registry will require documentation of the proposed use of the 1604 allocated value (=Specification required) and approval by the 1605 Designated Expert assigned by the IESG (see [RFC5226]). 1607 This document requests creation of a new registry for BGP-LS 1608 Protocol-IDs. Value 0 is reserved. The maximum value is 255. The 1609 registry will be initialized as shown in Table 2. Allocations within 1610 the registry will require documentation of the proposed use of the 1611 allocated value (=Specification required) and approval by the 1612 Designated Expert assigned by the IESG (see [RFC5226]). 1614 This document requests creation of a new registry for BGP-LS Well- 1615 known Instance-IDs. The registry will be initialized as shown in 1616 Table 3. Allocations within the registry will require documentation 1617 of the proposed use of the allocated value (=Specification required) 1618 and approval by the Designated Expert assigned by the IESG (see 1619 [RFC5226]). 1621 This document requests creation of a new registry for node anchor, 1622 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1623 Values 256-65535 will be used for code points. The registry will be 1624 initialized as shown in Table 13. Allocations within the registry 1625 will require documentation of the proposed use of the allocated value 1626 (=Specification required) and approval by the Designated Expert 1627 assigned by the IESG (see [RFC5226]). 1629 Note to RFC Editor: this section may be removed on publication as an 1630 RFC. 1632 6. Manageability Considerations 1634 This section is structured as recommended in [RFC5706]. 1636 6.1. Operational Considerations 1638 6.1.1. Operations 1640 Existing BGP operational procedures apply. No new operation 1641 procedures are defined in this document. It is noted that the NLRI 1642 information present in this document purely carries application level 1643 data that has no immediate corresponding forwarding state impact. As 1644 such, any churn in reachability information has different impact than 1645 regular BGP updates which need to change forwarding state for an 1646 entire router. Furthermore it is anticipated that distribution of 1647 this NLRI will be handled by dedicated route-reflectors providing a 1648 level of isolation and fault-containment between different NLRI 1649 types. 1651 6.1.2. Installation and Initial Setup 1653 Configuration parameters defined in Section 6.2.3 SHOULD be 1654 initialized to the following default values: 1656 o The Link-State NLRI capability is turned off for all neighbors. 1658 o The maximum rate at which Link-State NLRIs will be advertised/ 1659 withdrawn from neighbors is set to 200 updates per second. 1661 6.1.3. Migration Path 1663 The proposed extension is only activated between BGP peers after 1664 capability negotiation. Moreover, the extensions can be turned on/ 1665 off an individual peer basis (see Section 6.2.3), so the extension 1666 can be gradually rolled out in the network. 1668 6.1.4. Requirements on Other Protocols and Functional Components 1670 The protocol extension defined in this document does not put new 1671 requirements on other protocols or functional components. 1673 6.1.5. Impact on Network Operation 1675 Frequency of Link-State NLRI updates could interfere with regular BGP 1676 prefix distribution. A network operator MAY use a dedicated Route- 1677 Reflector infrastructure to distribute Link-State NLRIs. 1679 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1680 domain, which can consist of multiple areas within an AS or multiple 1681 ASes. 1683 6.1.6. Verifying Correct Operation 1685 Existing BGP procedures apply. In addition, an implementation SHOULD 1686 allow an operator to: 1688 o List neighbors with whom the Speaker is exchanging Link-State 1689 NLRIs 1691 6.2. Management Considerations 1693 6.2.1. Management Information 1695 This document does not mandate any new MIB information or NETCONF/ 1696 YANG models. 1698 6.2.2. Fault Management 1700 If an implementation of BGP-LS detects a malformed attribute, then it 1701 SHOULD use the 'Attribute Discard' action as per 1702 [I-D.ietf-idr-error-handling] Section 2. 1704 An implementation of BGP-LS MUST perform the following syntactic 1705 checks for determining if a message is malformed. 1707 o Does the sum of all TLVs found in the BGP LS attribute correspond 1708 to the BGP LS path attribute length ? 1710 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 1711 correspond to the BGP MP_REACH_NLRI length ? 1713 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 1714 attribute correspond to the BGP MP_UNREACH_NLRI length ? 1716 o Does the sum of all TLVs found in a Node-, Link or Prefix 1717 Descriptor NLRI attribute correspond to the Node-, Link- or Prefix 1718 Descriptors 'Total NLRI Length' field ? 1720 o Does any fixed length TLV correspond to the TLV Length field in 1721 this document ? 1723 6.2.3. Configuration Management 1725 An implementation SHOULD allow the operator to specify neighbors to 1726 which Link-State NLRIs will be advertised and from which Link-State 1727 NLRIs will be accepted. 1729 An implementation SHOULD allow the operator to specify the maximum 1730 rate at which Link-State NLRIs will be advertised/withdrawn from 1731 neighbors. 1733 An implementation SHOULD allow the operator to specify the maximum 1734 number of Link-State NLRIs stored in router's RIB. 1736 An implementation SHOULD allow the operator to create abstracted 1737 topologies that are advertised to neighbors; Create different 1738 abstractions for different neighbors. 1740 An implementation SHOULD allow the operator to configure a 64-bit 1741 instance ID. 1743 An implementation SHOULD allow the operator to configure a pair of 1744 ASN and BGP-LS identifier (Paragraph 2) per flooding set in which the 1745 node participates. 1747 6.2.4. Accounting Management 1749 Not Applicable. 1751 6.2.5. Performance Management 1753 An implementation SHOULD provide the following statistics: 1755 o Total number of Link-State NLRI updates sent/received 1757 o Number of Link-State NLRI updates sent/received, per neighbor 1759 o Number of errored received Link-State NLRI updates, per neighbor 1761 o Total number of locally originated Link-State NLRIs 1763 6.2.6. Security Management 1765 An operator SHOULD define ACLs to limit inbound updates as follows: 1767 o Drop all updates from Consumer peers 1769 7. TLV/Sub-TLV Code Points Summary 1771 This section contains the global table of all TLVs/Sub-TLVs defined 1772 in this document. 1774 +-----------+---------------------+---------------+-----------------+ 1775 | TLV Code | Description | IS-IS TLV/ | Value defined | 1776 | Point | | Sub-TLV | in: | 1777 +-----------+---------------------+---------------+-----------------+ 1778 | 256 | Local Node | --- | Section 3.2.1.2 | 1779 | | Descriptors | | | 1780 | 257 | Remote Node | --- | Section 3.2.1.3 | 1781 | | Descriptors | | | 1782 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1783 | | Identifiers | | | 1784 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1785 | | address | | | 1786 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1787 | | address | | | 1788 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1789 | | address | | | 1790 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1791 | | address | | | 1792 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1793 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1794 | 265 | IP Reachability | --- | Section 3.2.3 | 1795 | | Information | | | 1796 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1797 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1798 | 514 | OSPF Area ID | --- | Section 3.2.1.4 | 1799 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1800 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1801 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1802 | | Properties | | | 1803 | 1026 | Node Name | variable | Section 3.3.1.3 | 1804 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1805 | | Identifier | | | 1806 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1807 | | Local Node | | | 1808 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1809 | | Local Node | | | 1810 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1811 | | Remote Node | | | 1812 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1813 | | Remote Node | | | 1814 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1815 | | group (color) | | | 1816 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1817 | | bandwidth | | | 1818 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1819 | | link bandwidth | | | 1820 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1821 | | bandwidth | | | 1822 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | 1823 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1824 | | Type | | | 1825 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1826 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1827 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1828 | | Group | | | 1829 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1830 | | attribute | | | 1831 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1832 | 1152 | IGP Flags | --- | Section 3.3.3.1 | 1833 | 1153 | Route Tag | --- | [RFC5130] | 1834 | 1154 | Extended Tag | --- | [RFC5130] | 1835 | 1155 | Prefix Metric | --- | [RFC5305] | 1836 | 1156 | OSPF Forwarding | --- | [RFC2328] | 1837 | | Address | | | 1838 | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | 1839 | | Attribute | | | 1840 +-----------+---------------------+---------------+-----------------+ 1842 Table 13: Summary Table of TLV/Sub-TLV code points 1844 8. Security Considerations 1846 Procedures and protocol extensions defined in this document do not 1847 affect the BGP security model. See the 'Security Considerations' 1848 section of [RFC4271] for a discussion of BGP security. Also refer to 1849 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 1851 In the context of the BGP peerings associated with this document, a 1852 BGP Speaker SHOULD NOT accept updates from a Consumer peer. That is, 1853 a participating BGP Speaker, should be aware of the nature of its 1854 relationships for link state relationships and should protect itself 1855 from peers sending updates that either represent erroneous 1856 information feedback loops, or are false input. Such protection can 1857 be achieved by manual configuration of Consumer peers at the BGP 1858 Speaker. 1860 An operator SHOULD employ a mechanism to protect a BGP Speaker 1861 against DDoS attacks from Consumers. The principal attack a consumer 1862 may apply is to attempt to start multiple sessions either 1863 sequentially or simultaneously. Protection can be applied by 1864 imposing rate limits. 1866 Additionally, it may be considered that the export of link state and 1867 TE information as described in this document constitutes a risk to 1868 confidentiality of mission-critical or commercially-sensitive 1869 information about the network. BGP peerings are not automatic and 1870 require configuration, thus it is the responsibility of the network 1871 operator to ensure that only trusted Consumers are configured to 1872 receive such information. 1874 9. Contributors 1876 We would like to thank Robert Varga for the significant contribution 1877 he gave to this document. 1879 10. Acknowledgements 1881 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1882 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1883 Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex 1884 Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, 1885 Vipin Kumar, Naiming Shen, Balaji Rajagopalan and Yakov Rekhter for 1886 their comments. 1888 11. References 1890 11.1. Normative References 1892 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1893 dual environments", RFC 1195, December 1990. 1895 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1896 E. Lear, "Address Allocation for Private Internets", BCP 1897 5, RFC 1918, February 1996. 1899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1900 Requirement Levels", BCP 14, RFC 2119, March 1997. 1902 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1904 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1905 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1906 1999. 1908 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1909 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1910 Tunnels", RFC 3209, December 2001. 1912 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1913 Support of Generalized Multi-Protocol Label Switching 1914 (GMPLS)", RFC 4202, October 2005. 1916 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1917 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1919 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1920 "Multiprotocol Extensions for BGP-4", RFC 4760, January 1921 2007. 1923 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1924 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1925 4915, June 2007. 1927 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1928 Specification", RFC 5036, October 2007. 1930 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1931 Topology (MT) Routing in Intermediate System to 1932 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1934 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 1935 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1936 February 2008. 1938 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1939 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1940 May 2008. 1942 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1943 Mechanism for IS-IS", RFC 5301, October 2008. 1945 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1946 Engineering", RFC 5305, October 2008. 1948 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1949 of Generalized Multi-Protocol Label Switching (GMPLS)", 1950 RFC 5307, October 2008. 1952 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1953 for IPv6", RFC 5340, July 2008. 1955 [RFC5890] Klensin, J., "Internationalized Domain Names for 1956 Applications (IDNA): Definitions and Document Framework", 1957 RFC 5890, August 2010. 1959 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1960 Engineering in IS-IS", RFC 6119, February 2011. 1962 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1963 Identifier for BGP-4", RFC 6286, June 2011. 1965 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1966 Instance Extensions", RFC 6549, March 2012. 1968 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 1969 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1971 11.2. Informative References 1973 [I-D.ietf-idr-error-handling] 1974 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 1975 "Revised Error Handling for BGP UPDATE Messages", draft- 1976 ietf-idr-error-handling-18 (work in progress), December 1977 2014. 1979 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 1980 4272, January 2006. 1982 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1983 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1985 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1986 Shaffer, "Extensions to OSPF for Advertising Optional 1987 Router Capabilities", RFC 4970, July 2007. 1989 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1990 Extensions for Discovery of Traffic Engineering Node 1991 Capabilities", RFC 5073, December 2007. 1993 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1994 Path Computation Method for Establishing Inter-Domain 1995 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1996 5152, February 2008. 1998 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1999 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2000 Traffic Engineering", RFC 5316, December 2008. 2002 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 2003 Support of Inter-Autonomous System (AS) MPLS and GMPLS 2004 Traffic Engineering", RFC 5392, January 2009. 2006 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 2007 Optimization (ALTO) Problem Statement", RFC 5693, October 2008 2009. 2010 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 2011 Management of New Protocols and Protocol Extensions", RFC 2012 5706, November 2009. 2014 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2015 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2016 and Authentication for Routing Protocols (KARP) Design 2017 Guide", RFC 6952, May 2013. 2019 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 2020 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 2021 Traffic Optimization (ALTO) Protocol", RFC 7285, September 2022 2014. 2024 Authors' Addresses 2025 Hannes Gredler 2026 Juniper Networks, Inc. 2027 1194 N. Mathilda Ave. 2028 Sunnyvale, CA 94089 2029 US 2031 Email: hannes@juniper.net 2033 Jan Medved 2034 Cisco Systems, Inc. 2035 170, West Tasman Drive 2036 San Jose, CA 95134 2037 US 2039 Email: jmedved@cisco.com 2041 Stefano Previdi 2042 Cisco Systems, Inc. 2043 Via Del Serafico, 200 2044 Rome 00142 2045 Italy 2047 Email: sprevidi@cisco.com 2049 Adrian Farrel 2050 Juniper Networks, Inc. 2051 1194 N. Mathilda Ave. 2052 Sunnyvale, CA 94089 2053 US 2055 Email: afarrel@juniper.net 2057 Saikat Ray 2058 Cisco Systems, Inc. 2059 170, West Tasman Drive 2060 San Jose, CA 95134 2061 US 2063 Email: sairay@cisco.com