idnits 2.17.1 draft-ietf-idr-ls-distribution-03.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 (May 21, 2013) is 3992 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 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6822 (Obsoleted by RFC 8202) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-13 -- 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: 3 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: November 22, 2013 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 Cisco Systems, Inc. 11 May 21, 2013 13 North-Bound Distribution of Link-State and TE Information using BGP 14 draft-ietf-idr-ls-distribution-03 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 November 22, 2013. 58 Copyright Notice 60 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 6 77 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . . 6 78 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 8 79 3. Carrying Link State Information in BGP . . . . . . . . . . . . 9 80 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.2. The Link State NLRI . . . . . . . . . . . . . . . . . . . 10 82 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . . 13 83 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . . 17 84 3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . . 18 85 3.3. The LINK_STATE Attribute . . . . . . . . . . . . . . . . . 20 86 3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 20 87 3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 23 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: OSPFv2 to IS-IS Migration . . 32 93 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . . 32 94 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . . 33 95 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . . 33 96 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . . 34 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 98 6. Manageability Considerations . . . . . . . . . . . . . . . . . 34 99 6.1. Operational Considerations . . . . . . . . . . . . . . . . 35 100 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . . 35 101 6.1.2. Installation and Initial Setup . . . . . . . . . . . . 35 102 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . . 35 103 6.1.4. Requirements on Other Protocols and Functional 104 Components . . . . . . . . . . . . . . . . . . . . . . 35 105 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 35 106 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 36 107 6.2. Management Considerations . . . . . . . . . . . . . . . . 36 108 6.2.1. Management Information . . . . . . . . . . . . . . . . 36 109 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . . 36 110 6.2.3. Configuration Management . . . . . . . . . . . . . . . 36 111 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 36 112 6.2.5. Performance Management . . . . . . . . . . . . . . . . 36 113 6.2.6. Security Management . . . . . . . . . . . . . . . . . 37 114 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 37 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 116 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 119 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 120 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 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 form 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 its 217 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 which 222 still 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/ 232 back-up path computation hard, and might result in no TE path being 233 found when one really does exist. 235 The PCE presents a computation server that may have visibility into 236 more than one IGP area or AS, or may cooperate with other PCEs to 237 perform distributed path computation. The PCE obviously needs access 238 to the TED for the area(s) it serves, but [RFC4655] does not describe 239 how this is achieved. Many implementations make the PCE a passive 240 participant in the IGP so that it can learn the latest state of the 241 network, but this may be sub-optimal when the network is subject to a 242 high degree of churn, or when the PCE is responsible for multiple 243 areas. 245 The following figure shows how a PCE can get its TED information 246 using the mechanism described in this document. 248 +----------+ +---------+ 249 | ----- | | BGP | 250 | | TED |<-+-------------------------->| Speaker | 251 | ----- | TED synchronization | | 252 | | | mechanism: +---------+ 253 | | | BGP with Link-State NLRI 254 | v | 255 | ----- | 256 | | PCE | | 257 | ----- | 258 +----------+ 259 ^ 260 | Request/ 261 | Response 262 v 263 Service +----------+ Signaling +----------+ 264 Request | Head-End | Protocol | Adjacent | 265 -------->| Node |<------------>| Node | 266 +----------+ +----------+ 268 Figure 2: External PCE node using a TED synchronization mechanism 270 The mechanism in this document allows the necessary TED information 271 to be collected from the IGP within the network, filtered according 272 to configurable policy, and distributed to the PCE as necessary. 274 2.2. ALTO Server Network API 276 An ALTO Server [RFC5693] is an entity that generates an abstracted 277 network topology and provides it to network-aware applications over a 278 web service based API. Example applications are p2p clients or 279 trackers, or CDNs. The abstracted network topology comes in the form 280 of two maps: a Network Map that specifies allocation of prefixes to 281 Partition Identifiers (PIDs), and a Cost Map that specifies the cost 282 between PIDs listed in the Network Map. For more details, see 283 [I-D.ietf-alto-protocol]. 285 ALTO abstract network topologies can be auto-generated from the 286 physical topology of the underlying network. The generation would 287 typically be based on policies and rules set by the operator. Both 288 prefix and TE data are required: prefix data is required to generate 289 ALTO Network Maps, TE (topology) data is required to generate ALTO 290 Cost Maps. Prefix data is carried and originated in BGP, TE data is 291 originated and carried in an IGP. The mechanism defined in this 292 document provides a single interface through which an ALTO Server can 293 retrieve all the necessary prefix and network topology data from the 294 underlying network. Note an ALTO Server can use other mechanisms to 295 get network data, for example, peering with multiple IGP and BGP 296 Speakers. 298 The following figure shows how an ALTO Server can get network 299 topology information from the underlying network using the mechanism 300 described in this document. 302 +--------+ 303 | Client |<--+ 304 +--------+ | 305 | ALTO +--------+ BGP with +---------+ 306 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 307 | Client |<--+------------| Server |<----------------| Speaker | 308 +--------+ | | | | | 309 | +--------+ +---------+ 310 +--------+ | 311 | Client |<--+ 312 +--------+ 314 Figure 3: ALTO Server using network topology information 316 3. Carrying Link State Information in BGP 318 This specification contains two parts: definition of a new BGP NLRI 319 that describes links, nodes and prefixes comprising IGP link state 320 information, and definition of a new BGP path attribute (BGP-LS 321 attribute) that carries link, node and prefix properties and 322 attributes, such as the link and prefix metric or auxiliary Router- 323 IDs of nodes, etc. 325 3.1. TLV Format 327 Information in the new link state NLRIs and attributes is encoded in 328 Type/Length/Value triplets. The TLV format is shown in Figure 4. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 // Value (variable) // 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 4: TLV format 340 The Length field defines the length of the value portion in octets 341 (thus a TLV with no value portion would have a length of zero). The 342 TLV is not padded to four-octet alignment. Unrecognized types are 343 preserved and propagated. In order to compare NLRIs with unknown 344 TLVs all TLVs MUST be ordered in ascending order. If there are more 345 TLVs of the same type, then the TLVs MUST be ordered in ascending 346 order of the TLV value within the set of TLVs with the same type. 347 All TLVs that are not specified as mandatory are considered optional. 349 3.2. The Link State NLRI 351 The MP_REACH and MP_UNREACH attributes are BGP's containers for 352 carrying opaque information. Each Link State NLRI describes either a 353 node, a link or a prefix. 355 All non-VPN link, node and prefix information SHALL be encoded using 356 AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be 357 encoded using AFI 16388 / SAFI 128. 359 In order for two BGP speakers to exchange Link-State NLRI, they MUST 360 use BGP Capabilities Advertisement to ensure that they both are 361 capable of properly processing such NLRI. This is done as specified 362 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 363 an AFI 16388 / SAFI 71 and AFI 16388 / SAFI 128 for the VPN flavor. 365 The format of the Link State NLRI is shown in the following figure. 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | NLRI Type | Total NLRI Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 // Link-State NLRI (variable) // 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 5: Link State AFI 16388 / SAFI 71 NLRI Format 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | NLRI Type | Total NLRI Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 + Route Distinguisher + 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 // Link-State NLRI (variable) // 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 6: Link State VPN AFI 16388 / SAFI 128 NLRI Format 395 The 'Total NLRI Length' field contains the cumulative length, in 396 octets, of rest of the NLRI not including the NLRI Type field or 397 itself. For VPN applications it also includes the length of the 398 Route Distinguisher. 400 The 'NLRI Type' field can contain one of the following values: 402 Type = 1: Node NLRI 404 Type = 2: Link NLRI 406 Type = 3: IPv4 Topology Prefix NLRI 408 Type = 4: IPv6 Topology Prefix NLRI 410 The Node NLRI (NLRI Type = 1) is shown in the following figure. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+ 415 | Protocol-ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Identifier | 418 | (64 bits) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 // Local Node Descriptors (variable) // 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 7: The Node NLRI format 425 The Link NLRI (NLRI Type = 2) is shown in the following figure. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+ 430 | Protocol-ID | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Identifier | 433 | (64 bits) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 // Local Node Descriptors (variable) // 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 // Remote Node Descriptors (variable) // 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 // Link Descriptors (variable) // 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Figure 8: The Link NLRI format 444 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 445 same format as shown in the following figure. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+ 450 | Protocol-ID | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Identifier | 453 | (64 bits) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 // Local Node Descriptor (variable) // 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 // Prefix Descriptors (variable) // 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 9: The IPv4/IPv6 Topology Prefix NLRI format 462 The 'Protocol-ID' field can contain one of the following values: 464 Protocol-ID = 0: Unknown, The source of NLRI information could not 465 be determined 467 Protocol-ID = 1: IS-IS Level 1, The NLRI information has been 468 sourced by IS-IS Level 1 470 Protocol-ID = 2: IS-IS Level 2, The NLRI information has been 471 sourced by IS-IS Level 2 472 Protocol-ID = 3: OSPF, The NLRI information has been sourced by 473 OSPF 475 Protocol-ID = 4: Direct, The NLRI information has been sourced 476 from local interface state 478 Protocol-ID = 5: Static, The NLRI information has been sourced by 479 static configuration 481 Both OSPF and IS-IS may run multiple routing protocol instances over 482 the same link. See [RFC6822] and [RFC6549]. These instances define 483 independent "routing universes". The 64-Bit 'Identifier' field is 484 used to identify the "routing universe" where the NLRI belongs. The 485 NLRIs representing IGP objects (nodes, links or prefixes) from the 486 same routing universe MUST have the same 'Identifier' value; NLRIs 487 with different 'Identifier' values MUST be considered to be from 488 different routing universes. Table Table 1 lists the 'Identifier' 489 values that are defined as well-known in this draft. 491 +------------+---------------------+ 492 | Identifier | Routing Universe | 493 +------------+---------------------+ 494 | 0 | L3 packet topology | 495 | 1 | L1 optical topology | 496 +------------+---------------------+ 498 Table 1: Well-known Instance Identifiers 500 Each Node Descriptor and Link Descriptor consists of one or more TLVs 501 described in the following sections. 503 3.2.1. Node Descriptors 505 Each link is anchored by a pair of Router-IDs that are used by the 506 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 507 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 508 additional auxiliary Router-IDs, mainly for traffic engineering 509 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 510 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 511 included in the link attribute described in Section Section 3.3.2. 513 It is desirable that the Router-ID assignments inside the Node 514 Descriptor are globally unique. However there may be Router-ID 515 spaces (e.g. ISO) where no global registry exists, or worse, Router- 516 IDs have been allocated following private-IP RFC 1918 [RFC1918] 517 allocation. We use Autonomous System (AS) Number and BGP-LS 518 Identifier in order to disambiguate the Router-IDs, as described in 519 Section 3.2.1.1. 521 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 523 One problem that needs to be addressed is the ability to identify an 524 IGP node globally (by "global", we mean within the BGP-LS database 525 collected by all BGP-LS speakers that talk to each other). This can 526 be expressed through the following two requirements: 528 (A) The same node must not be represented by two keys (otherwise one 529 node will look like two nodes). 531 (B) Two different nodes must not be represented by the same key 532 (otherwise, two nodes will look like one node). 534 We define an "IGP domain" to be the set of nodes (hence, by extension 535 links and prefixes), within which, each node has a unique IGP 536 representation by using the combination of Area-ID, Router-ID, 537 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 538 receive node/link/prefix information from multiple independent "IGP 539 domains" and we need to distinguish between them. Moreover, we can't 540 assume there is always one and only one IGP domain per AS. During 541 IGP transitions it may happen that two redundant IGPs are in place. 543 In section Section 3.2.1.4 a set of sub-TLVs is described, which 544 allows to specify a flexible key for any given Node/Link information 545 such that global uniqueness of the NLRI is ensured. 547 3.2.1.2. Local Node Descriptors 549 The Local Node Descriptors TLV contains Node Descriptors for the node 550 anchoring the local end of the link. This is a mandatory TLV in all 551 three types of NLRIs. The length of this TLV is variable. The value 552 contains one or more Node Descriptor Sub-TLVs defined in 553 Section 3.2.1.4. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 // Node Descriptor Sub-TLVs (variable) // 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 10: Local Node Descriptors TLV format 567 3.2.1.3. Remote Node Descriptors 569 The Remote Node Descriptors contains Node Descriptors for the node 570 anchoring the remote end of the link. This is a mandatory TLV for 571 link NLRIs. The length of this TLV is variable. The value contains 572 one or more Node Descriptor Sub-TLVs defined in Section 3.2.1.4. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Type | Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 // Node Descriptor Sub-TLVs (variable) // 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 11: Remote Node Descriptors TLV format 586 3.2.1.4. Node Descriptor Sub-TLVs 588 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 589 the following table: 591 +--------------------+-------------------+----------+ 592 | Sub-TLV Code Point | Description | Length | 593 +--------------------+-------------------+----------+ 594 | 512 | Autonomous System | 4 | 595 | 513 | BGP-LS Identifier | 4 | 596 | 514 | Area-ID | 4 | 597 | 515 | IGP Router-ID | Variable | 598 +--------------------+-------------------+----------+ 600 Table 2: Node Descriptor Sub-TLVs 602 The sub-TLV values in Node Descriptor TLVs are defined as follows: 604 Autonomous System: opaque value (32 Bit AS Number) 606 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 607 ASN, uniquely identifies the BGP-LS domain. The combination of 608 ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers 609 within an IGP flooding-set (set of IGP nodes within which an LSP/ 610 LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP 611 domain consists of multiple flooding-sets, then all BGP-LS 612 speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID 613 tuple. The ASN, BGP Router-ID tuple (which is globally unique 614 [RFC6286] ) of one of the BGP-LS speakers within the flooding-set 615 (or IGP domain) may be used for all BGP-LS speakers in that 616 flooding-set (or IGP domain). 618 Area ID: It is used to identify the 32 Bit area to which the NLRI 619 belongs. Area Identifier allows the different NLRIs of the same 620 router to be discriminated. 622 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 623 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 624 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 625 octet ISO node-ID of the "Designated Intermediate System" (DIS) 626 followed by one octet nonzero PSN identifier (7 octet in total). 627 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains 4 octet 628 Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this 629 contains 4 octet Router-ID of the designated router (DR) followed 630 by 4 octet IPv4 address of the DR's interface to the LAN (8 octet 631 in total). Similarly, for an OSPFv3 "Pseudonode", this contains 4 632 octet Router-ID of the DR followed by 4 octet interface identifier 633 of the DR's interface to the LAN (8 octet in total). The TLV size 634 in combination with protocol identifier enables the decoder to 635 determine the type of the node. 637 There can be at most one instance of each sub-TLV type present in 638 any Node Descriptor. The TLV ordering within a Node descriptor 639 MUST be kept in order of increasing numeric value of type. This 640 needs to be done in order to compare NLRIs, even when an 641 implementation encounters an unknown sub-TLV. Using stable 642 sorting an implementation can do binary comparison of NLRIs and 643 hence allow incremental deployment of new key sub-TLVs. 645 3.2.1.5. Multi-Topology ID 647 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 648 Multi-Topology IDs for a link, node or prefix. 650 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 651 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 652 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 653 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 654 SHOULD be set to 0 when originated and ignored on receipt. 656 The format of the MT-ID TLV is shown in the following figure. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Type | Length=2*n | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |R R R R| Multi-Topology ID 1 | .... // 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 // .... |R R R R| Multi-Topology ID n | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 12: Multi-Topology ID TLV format 670 where Type is 263, Length is 2*n and n is the number of MT-IDs 671 carried in the TLV. 673 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 674 Descriptor, or in the BGP-LS attribute of a node NLRI. In Link or 675 Prefix Descriptor, only one MT-ID TLV containing only the MT-ID of 676 the topology where the link or the prefix belongs is allowed. In the 677 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array 678 of MT-IDs of all topologies where the node belongs can be present. 680 3.2.2. Link Descriptors 682 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 683 triplets. The format of each TLV is shown in Section 3.1. The 'Link 684 descriptor' TLVs uniquely identify a link among multiple parallel 685 links between a pair of anchor routers. A link described by the Link 686 descriptor TLVs actually is a "half-link", a unidirectional 687 representation of a logical link. In order to fully describe a 688 single logical link two originating routers advertise a half-link 689 each, i.e. two link NLRIs are advertised for a given point-to-point 690 link. 692 The format and semantics of the 'value' fields in most 'Link 693 Descriptor' TLVs correspond to the format and semantics of value 694 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 695 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 696 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 697 carry data sourced either by IS-IS or OSPF. 699 The following TLVs are valid as Link Descriptors in the Link NLRI: 701 +-----------+---------------------+---------------+-----------------+ 702 | TLV Code | Description | IS-IS | Value defined | 703 | Point | | TLV/Sub-TLV | in: | 704 +-----------+---------------------+---------------+-----------------+ 705 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 706 | | Identifiers | | | 707 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 708 | | address | | | 709 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 710 | | address | | | 711 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 712 | | address | | | 713 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 714 | | address | | | 715 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 716 | | Identifier | | | 717 +-----------+---------------------+---------------+-----------------+ 719 Table 3: Link Descriptor TLVs 721 3.2.3. Prefix Descriptors 723 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 724 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 725 Prefix originated by a Node. The following TLVs are valid as Prefix 726 Descriptors in the IPv4/IPv6 Prefix NLRI: 728 +--------------+-----------------------+----------+-----------------+ 729 | TLV Code | Description | Length | Value defined | 730 | Point | | | in: | 731 +--------------+-----------------------+----------+-----------------+ 732 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 733 | | Identifier | | | 734 | 264 | OSPF Route Type | 1 | Section 3.2.3.1 | 735 | 265 | IP Reachability | variable | Section 3.2.3.2 | 736 | | Information | | | 737 +--------------+-----------------------+----------+-----------------+ 739 Table 4: Prefix Descriptor TLVs 741 3.2.3.1. OSPF Route Type 743 OSPF Route Type is an optional TLV that MAY be present in Prefix 744 NLRIs. It is used to identify the OSPF route-type of the prefix. It 745 is used when an OSPF prefix is advertised in the OSPF domain with 746 multiple different route-types. The Route Type TLV allows to 747 discriminate these advertisements. The format of the OSPF Route Type 748 TLV is shown in the following figure. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Type | Length | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Route Type | 756 +-+-+-+-+-+-+-+-+ 758 Figure 13: OSPF Route Type TLV Format 760 where the Type and Length fields of the TLV are defined in Table 4. 761 The OSPF Route Type field values are defined in the OSPF protocol, 762 and can be one of the following: 764 Intra-Area (0x1) 766 Inter-Area (0x2) 768 External 1 (0x3) 770 External 2 (0x4) 772 NSSA 1 (0x5) 774 NSSA 2 (0x6) 776 3.2.3.2. IP Reachability Information 778 The IP Reachability Information is a mandatory TLV that contains one 779 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 780 topology. Its purpose is to glue a particular BGP service NLRI vi 781 virtue of its BGP next-hop to a given Node in the LSDB. A router 782 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 783 The format of the IP Reachability Information TLV is shown in the 784 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 | Prefix Length | IP Prefix (variable) // 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Figure 14: IP Reachability Information TLV Format 796 The Type and Length fields of the TLV are defined in Table 4. The 797 following two fields determine the address-family reachability 798 information. The 'Prefix Length' field contains the length of the 799 prefix in bits. The 'IP Prefix' field contains the most significant 800 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 801 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 802 24 and 4 octets for prefix length 25 up to 32, etc. 804 3.3. The LINK_STATE Attribute 806 This is an optional, non-transitive BGP attribute that is used to 807 carry link, node and prefix parameters and attributes. It is defined 808 as a set of Type/Length/Value (TLV) triplets, described in the 809 following section. This attribute SHOULD only be included with Link 810 State NLRIs. This attribute MUST be ignored for all other address- 811 families. 813 3.3.1. Node Attribute TLVs 815 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 816 attribute with a node NLRI. The following node attribute TLVs are 817 defined: 819 +--------------+-----------------------+----------+-----------------+ 820 | TLV Code | Description | Length | Value defined | 821 | Point | | | in: | 822 +--------------+-----------------------+----------+-----------------+ 823 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 824 | | Identifier | | | 825 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 826 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 827 | | Properties | | | 828 | 1026 | Node Name | variable | Section 3.3.1.3 | 829 | 1027 | IS-IS Area Identifier | variable | Section 3.3.1.2 | 830 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 831 | | Local Node | | | 832 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 833 | | Local Node | | | 834 +--------------+-----------------------+----------+-----------------+ 836 Table 5: Node Attribute TLVs 838 3.3.1.1. Node Flag Bits TLV 840 The Node Flag Bits TLV carries a bit mask describing node attributes. 841 The value is a variable length bit array of flags, where each bit 842 represents a node capability. 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Type | Length | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |O|T|E|A| Reserved| 850 +-+-+-+-+-+-+-+-+-+ 852 Figure 15: Node Flag Bits TLV format 854 The bits are defined as follows: 856 +----------+-------------------------+-----------+ 857 | Bit | Description | Reference | 858 +----------+-------------------------+-----------+ 859 | 'O' | Overload Bit | [RFC1195] | 860 | 'T' | Attached Bit | [RFC1195] | 861 | 'E' | External Bit | [RFC2328] | 862 | 'A' | ABR Bit | [RFC2328] | 863 | Reserved | Reserved for future use | | 864 +----------+-------------------------+-----------+ 866 Table 6: Node Flag Bits Definitions 868 3.3.1.2. IS-IS Area Identifier TLV 870 An IS-IS node can be part of one or more IS-IS areas. Each of these 871 area addresses is carried in the IS-IS Area Identifier TLV. If more 872 than one Area Addresses are present, multiple TLVs are used to encode 873 them. The IS-IS Area Identifier TLV may be present in the LINK_STATE 874 attribute only with the Link State Node NLRI. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Type | Length | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 // Area Identifier (variable) // 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Figure 16: IS-IS Area Identifier TLV Format 886 3.3.1.3. Node Name TLV 888 The Node Name TLV is optional. Its structure and encoding has been 889 borrowed from [RFC5301]. The value field identifies the symbolic 890 name of the router node. This symbolic name can be the FQDN for the 891 router, it can be a subset of the FQDN, or it can be any string 892 operators want to use for the router. The use of FQDN or a subset of 893 it is strongly recommended. 895 The Value field is encoded in 7-bit ASCII. If a user-interface for 896 configuring or displaying this field permits Unicode characters, that 897 user-interface is responsible for applying the ToASCII and/or 898 ToUnicode algorithm as described in [RFC3490] to achieve the correct 899 format for transmission or display. 901 Altough [RFC5301] is a IS-IS specific extension, usage of the Node 902 Name TLV is possible for all protocols. How a router derives and 903 injects node names for e.g. OSPF nodes, is outside of the scope of 904 this document. 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Type | Length | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 // Node Name (variable) // 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 17: Node Name format 916 3.3.1.4. Local IPv4/IPv6 Router-ID 918 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 919 Router-IDs that the IGP might be using, e.g., for TE and migration 920 purposes like correlating a Node-ID between different protocols. If 921 there is more than one auxiliary Router-ID of a given type, then each 922 one is encoded in its own TLV. 924 3.3.1.5. Opaque Node Attribute TLV 926 The Opaque Node attribute TLV is an envelope that transparently 927 carries optional node attribute TLVs advertised by a router. An 928 originating router shall use this TLV for encoding information 929 specific to the protocol advertised in the NLRI header Protocol-ID 930 field or new protocol extensions to the protocol as advertised in the 931 NLRI header Protocol-ID field for which there is no protocol neutral 932 representation in the BGP link-state NLRI. A router for example 933 could use this extension in order to advertise the native protocols 934 node attribute TLVs, such as the OSPF Router Informational 935 Capabilities TLV defined in [RFC4970], or the IGP TE Node Capability 936 Descriptor TLV described in [RFC5073]. 938 0 1 2 3 939 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 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Type | Length | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 // Opaque node attributes (variable) // 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Figure 18: Opaque Node attribute format 948 3.3.2. Link Attribute TLVs 950 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 951 attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ 952 Value (TLV) triplet formatted as defined in Section 3.1. The format 953 and semantics of the 'value' fields in some 'Link Attribute' TLVs 954 correspond to the format and semantics of value fields in IS-IS 955 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 956 [RFC5307]. Other 'Link Attribute' TLVs are defined in this document. 957 Although the encodings for 'Link Attribute' TLVs were originally 958 defined for IS-IS, the TLVs can carry data sourced either by IS-IS or 959 OSPF. 961 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 962 attribute: 964 +------------+---------------------+--------------+-----------------+ 965 | TLV Code | Description | IS-IS | Defined in: | 966 | Point | | TLV/Sub-TLV | | 967 +------------+---------------------+--------------+-----------------+ 968 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 969 | | Local Node | | | 970 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 971 | | Local Node | | | 972 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 973 | | Remote Node | | | 974 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 975 | | Remote Node | | | 976 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 977 | | group (color) | | | 978 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 979 | | bandwidth | | | 980 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 981 | | link bandwidth | | | 982 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 983 | | bandwidth | | | 984 | 1092 | TE Default Metric | 22/18 | [RFC5305]/3.7 | 985 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 986 | | Type | | | 987 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 988 | 1095 | Metric | --- | Section 3.3.2.3 | 989 | 1096 | Shared Risk Link | --- | Section 3.3.2.4 | 990 | | Group | | | 991 | 1097 | Opaque link | --- | Section 3.3.2.5 | 992 | | attribute | | | 993 | 1098 | Link Name attribute | --- | Section 3.3.2.6 | 994 +------------+---------------------+--------------+-----------------+ 996 Table 7: Link Attribute TLVs 998 3.3.2.1. IPv4/IPv6 Router-ID 1000 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 1001 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1002 purposes. All auxiliary Router-IDs of both the local and the remote 1003 node MUST be included in the link attribute of each link NLRI. If 1004 there are more than one auxiliary Router-ID of a given type, then 1005 multiple TLVs are used to encode them. 1007 3.3.2.2. MPLS Protocol Mask TLV 1009 The MPLS Protocol TLV carries a bit mask describing which MPLS 1010 signaling protocols are enabled. The length of this TLV is 1. The 1011 value is a bit array of 8 flags, where each bit represents an MPLS 1012 Protocol capability. 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Type | Length | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 |L|R| Reserved | 1020 +-+-+-+-+-+-+-+-+ 1022 Figure 19: MPLS Protocol TLV 1024 The following bits are defined: 1026 +------------+------------------------------------------+-----------+ 1027 | Bit | Description | Reference | 1028 +------------+------------------------------------------+-----------+ 1029 | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | 1030 | 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] | 1031 | | (RSVP-TE) | | 1032 | 'Reserved' | Reserved for future use | | 1033 +------------+------------------------------------------+-----------+ 1035 Table 8: MPLS Protocol Mask TLV Codes 1037 3.3.2.3. Metric TLV 1039 The IGP Metric TLV carries the metric for this link. The length of 1040 this TLV is variable, depending on the metric width of the underlying 1041 protocol. IS-IS small metrics have a length of 1 octet (the two most 1042 significant bits are ignored). OSPF metrics have a length of two 1043 octects. IS-IS wide-metrics have a length of three octets. 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Type | Length | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 // IGP Link Metric (variable length) // 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Figure 20: Metric TLV format 1055 3.3.2.4. Shared Risk Link Group TLV 1057 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1058 Group information (see Section 2.3, "Shared Risk Link Group 1059 Information", of [RFC4202]). It contains a data structure consisting 1060 of a (variable) list of SRLG values, where each element in the list 1061 has 4 octets, as shown in Figure 21. The length of this TLV is 4 * 1062 (number of SRLG values). 1064 0 1 2 3 1065 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 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Type | Length | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Shared Risk Link Group Value | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 // ............ // 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Shared Risk Link Group Value | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Figure 21: Shared Risk Link Group TLV format 1078 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 1079 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1080 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1081 defined in [RFC6119]. In Link State NLRI both IPv4 and IPv6 SRLG 1082 information are carried in a single TLV. 1084 3.3.2.5. Opaque Link Attribute TLV 1086 The Opaque link attribute TLV is an envelope that transparently 1087 carries optional link atrribute TLVs advertised by a router. An 1088 originating router shall use this TLV for encoding information 1089 specific to the protocol advertised in the NLRI header Protocol-ID 1090 field or new protocol extensions to the protocol as advertised in the 1091 NLRI header Protocol-ID field for which there is no protocol neutral 1092 representation in the BGP link-state NLRI. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Type | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 // Opaque link attributes (variable) // 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Figure 22: Opaque link attribute format 1104 3.3.2.6. Link Name TLV 1106 The Link Name TLV is optional. The value field identifies the 1107 symbolic name of the router link. This symbolic name can be the FQDN 1108 for the link, it can be a subset of the FQDN, or it can be any string 1109 operators want to use for the link. The use of FQDN or a subset of 1110 it is strongly recommended. 1112 The Value field is encoded in 7-bit ASCII. If a user-interface for 1113 configuring or displaying this field permits Unicode characters, that 1114 user-interface is responsible for applying the ToASCII and/or 1115 ToUnicode algorithm as described in [RFC3490] to achieve the correct 1116 format for transmission or display. 1118 How a router derives and injects link names is outside of the scope 1119 of this document. 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Type | Length | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 // Link Name (variable) // 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 Figure 23: Link Name format 1131 3.3.3. Prefix Attribute TLVs 1133 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1134 of IGP attributes (such as metric, route tags, etc.) that MUST be 1135 reflected into the LINK_STATE attribute. This section describes the 1136 different attributes related to the IPv4/IPv6 prefixes. Prefix 1137 Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 1138 only. The following attributes TLVs are defined: 1140 +---------------+----------------------+----------+-----------------+ 1141 | TLV Code | Description | Length | Reference | 1142 | Point | | | | 1143 +---------------+----------------------+----------+-----------------+ 1144 | 1152 | IGP Flags | 1 | Section 3.3.3.1 | 1145 | 1153 | Route Tag | 4*n | Section 3.3.3.2 | 1146 | 1154 | Extended Tag | 8*n | Section 3.3.3.3 | 1147 | 1155 | Prefix Metric | 4 | Section 3.3.3.4 | 1148 | 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 | 1149 | | Address | | | 1150 | 1157 | Opaque Prefix | variable | Section 3.3.3.6 | 1151 | | Attribute | | | 1152 +---------------+----------------------+----------+-----------------+ 1154 Table 9: Prefix Attribute TLVs 1156 3.3.3.1. IGP Flags TLV 1158 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1159 assigned to the prefix. The IGP Flags TLV is encoded as follows: 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 |D| Reserved | 1167 +-+-+-+-+-+-+-+-+ 1169 Figure 24: IGP Flag TLV format 1171 The value field contains bits defined according to the table below: 1173 +----------+--------------------------+-----------+ 1174 | Bit | Description | Reference | 1175 +----------+--------------------------+-----------+ 1176 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1177 | Reserved | Reserved for future use. | | 1178 +----------+--------------------------+-----------+ 1180 Table 10: IGP Flag Bits Definitions 1182 3.3.3.2. Route Tag 1184 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1185 the prefix and is encoded as follows: 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Type | Length | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 // Route Tags (one or more) // 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Figure 25: IGP Route TAG TLV format 1197 Length is a multiple of 4. 1199 The value field contains one or more Route Tags as learned in the IGP 1200 topology. 1202 3.3.3.3. Extended Route Tag 1204 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1205 prefix [RFC5130] and is encoded as follows: 1207 0 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Type | Length | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 // Extended Route Tag (one or more) // 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Figure 26: Extended IGP Route TAG TLV format 1217 Length is a multiple of 8. 1219 The 'Extended Route Tag' field contains one or more Extended Route 1220 Tags as learned in the IGP topology. 1222 3.3.3.4. Prefix Metric TLV 1224 Prefix Metric TLV carries the metric of the prefix as known in the 1225 IGP topology [RFC5305]. The attribute is mandatory and can only 1226 appear once. 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 | Metric | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 Figure 27: Prefix Metric TLV Format 1238 Length is 4. 1240 3.3.3.5. OSPF Forwarding Address TLV 1242 OSPF Forwarding Address TLV [RFC2328] carries the OSPF forwarding 1243 address as known in the original OSPF advertisement. Forwarding 1244 address can be either IPv4 or IPv6. 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Type | Length | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 // Forwarding Address (variable) // 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 Figure 28: OSPF Forwarding Address TLV Format 1256 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1257 forwarding address. 1259 3.3.3.6. Opaque Prefix Attribute TLV 1261 The Opaque Prefix attribute TLV is an envelope that transparently 1262 carries optional prefix attribute TLVs advertised by a router. An 1263 originating router shall use this TLV for encoding information 1264 specific to the protocol advertised in the NLRI header Protocol-ID 1265 field or new protocol extensions to the protocol as advertised in the 1266 NLRI header Protocol-ID field for which there is no protocol neutral 1267 representation in the BGP link-state NLRI. 1269 The format of the TLV is as follows: 1271 0 1 2 3 1272 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 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Type | Length | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 // Opaque Prefix Attributes (variable) // 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 Figure 29: Opaque Prefix Attribute TLV Format 1281 Type is as specified in Table 9 and Length is variable. 1283 3.4. BGP Next Hop Information 1285 BGP link-state information for both IPv4 and IPv6 networks can be 1286 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1287 IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1288 SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, 1289 then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. 1290 Usually the next hop will be set to the local end-point address of 1291 the BGP session. The next hop address MUST be encoded as described 1292 in [RFC4760]. The length field of the next hop address will specify 1293 the next hop address-family. If the next hop length is 4, then the 1294 next hop is an IPv4 address; if the next hop length is 16, then it is 1295 a global IPv6 address and if the next hop length is 32, then there is 1296 one global IPv6 address followed by a link-local IPv6 address. The 1297 link-local IPv6 address should be used as described in [RFC2545]. 1298 For VPN SAFI, as per custom, an 8 byte route-distinguisher set to all 1299 zero is prepended to the next hop. 1301 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1302 the NLRI it receives. However, this specification doesn't mandate 1303 any rule regarding the re-write of the BGP Next Hop attribute. 1305 3.5. Inter-AS Links 1307 The main source of TE information is the IGP, which is not active on 1308 inter-AS links. In some cases, the IGP may have information of 1309 inter-AS links ([RFC5392], [RFC5316]). In other cases, for injecting 1310 a non-IGP enabled link into the BGP link-state RIB, an implementation 1311 MUST support configuration of either 'Static' or 'Direct' links. 1313 3.6. Router-ID Anchoring Example: ISO Pseudonode 1315 Encoding of a broadcast LAN in IS-IS provides a good example of how 1316 Router-IDs are encoded. Consider Figure 30. This represents a 1317 Broadcast LAN between a pair of routers. The "real" (=non 1318 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1319 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1320 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1321 (Pseudonode1, Node2) are being generated. 1323 The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP 1324 Router-ID TLV of the local node descriptor is 6 octets long 1325 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1326 the remote node descriptor is 7 octets long containing the ISO-ID of 1327 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1328 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1329 192.0.2.1, the IPv4 Router-ID of Node1. 1331 The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP 1332 Router-ID TLV of the local node descriptor is 7 octets long 1333 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1334 Router-ID TLV of the remote node descriptor is 6 octets long 1335 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1336 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1337 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1339 +-----------------+ +-----------------+ +-----------------+ 1340 | Node1 | | Pseudonode1 | | Node2 | 1341 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1342 | 192.0.2.1 | | | | 192.0.2.2 | 1343 +-----------------+ +-----------------+ +-----------------+ 1345 Figure 30: IS-IS Pseudonodes 1347 3.7. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1349 Graceful migration from one IGP to another requires coordinated 1350 operation of both protocols during the migration period. Such a 1351 coordination requires identifying a given physical link in both IGPs. 1352 The IPv4 Router-ID provides that "glue" which is present in the node 1353 descriptors of the OSPF link NLRI and in the link attribute of the 1354 IS-IS link NLRI. 1356 Consider a point-to-point link between two routers, A and B, that 1357 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1358 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1359 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1360 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1361 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1362 in the local and remote node descriptors, respectively. The IS-IS 1363 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1364 the local and remote node descriptors, respectively. In addition, 1365 the BGP-LS attribute of the IS-IS link NLRI contains the the TLV type 1366 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1367 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1368 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1369 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1371 4. Link to Path Aggregation 1373 Distribution of all links available in the global Internet is 1374 certainly possible, however not desirable from a scaling and privacy 1375 point of view. Therefore an implementation may support link to path 1376 aggregation. Rather than advertising all specific links of a domain, 1377 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1378 of nodes. The "aggregate link" represents the aggregated set of link 1379 properties between a pair of non-adjacent nodes. The actual methods 1380 to compute the path properties (of bandwidth, metric) are outside the 1381 scope of this document. The decision whether to advertise all 1382 specific links or aggregated links is an operator's policy choice. 1383 To highlight the varying levels of exposure, the following deployment 1384 examples are discussed. 1386 4.1. Example: No Link Aggregation 1388 Consider Figure 31. Both AS1 and AS2 operators want to protect their 1389 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1390 compute its link-protection LSP to R3 it needs to "see" an alternate 1391 path to R3. Therefore the AS2 operator exposes its topology. All 1392 BGP TE enabled routers in AS1 "see" the full topology of AS and 1393 therefore can compute a backup path. Note that the decision if the 1394 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1395 by the computing router. 1397 AS1 : AS2 1398 : 1399 R1-------R3 1400 | : | \ 1401 | : | R5 1402 | : | / 1403 R2-------R4 1404 : 1405 : 1407 Figure 31: No link aggregation 1409 4.2. Example: ASBR to ASBR Path Aggregation 1411 The brief difference between the "no-link aggregation" example and 1412 this example is that no specific link gets exposed. Consider 1413 Figure 32. The only link which gets advertised by AS2 is an 1414 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1415 there is a backup path. However the actual links being used are 1416 hidden from the topology. 1418 AS1 : AS2 1419 : 1420 R1-------R3 1421 | : | 1422 | : | 1423 | : | 1424 R2-------R4 1425 : 1426 : 1428 Figure 32: ASBR link aggregation 1430 4.3. Example: Multi-AS Path Aggregation 1432 Service providers in control of multiple ASes may even decide to not 1433 expose their internal inter-AS links. Consider Figure 33. AS3 is 1434 modeled as a single node which connects to the border routers of the 1435 aggregated domain. 1437 AS1 : AS2 : AS3 1438 : : 1439 R1-------R3----- 1440 | : : \ 1441 | : : vR0 1442 | : : / 1443 R2-------R4----- 1444 : : 1445 : : 1447 Figure 33: Multi-AS aggregation 1449 5. IANA Considerations 1451 This document requests a code point from the registry of Address 1452 Family Numbers. As per early allocation procedure this is AFI 16388. 1454 This document requests a code point from the registry of Subsequent 1455 Address Family Numbers. As per early allocation procedure this is 1456 SAFI 71. 1458 This document requests a code point from the BGP Path Attributes 1459 registry. 1461 This document requests creation of a new registry for node anchor, 1462 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1463 Values 256-65535 will be used for Codepoints. The registry will be 1464 initialized as shown in Table 11. Allocations within the registry 1465 will require documentation of the proposed use of the allocated value 1466 and approval by the Designated Expert assigned by the IESG (see 1467 [RFC5226]). 1469 Note to RFC Editor: this section may be removed on publication as an 1470 RFC. 1472 6. Manageability Considerations 1474 This section is structured as recommended in [RFC5706]. 1476 6.1. Operational Considerations 1478 6.1.1. Operations 1480 Existing BGP operational procedures apply. No new operation 1481 procedures are defined in this document. It is noted that the NLRI 1482 information present in this document purely carries application level 1483 data that has no immediate corresponding forwarding state impact. As 1484 such, any churn in reachability information has different impact than 1485 regular BGP updates which need to change forwarding state for an 1486 entire router. Furthermore it is anticipated that distribution of 1487 this NLRI will be handled by dedicated route-reflectors providing a 1488 level of isolation and fault-containment between different NLRI 1489 types. 1491 6.1.2. Installation and Initial Setup 1493 Configuration parameters defined in Section 6.2.3 SHOULD be 1494 initialized to the following default values: 1496 o The Link-State NLRI capability is turned off for all neighbors. 1498 o The maximum rate at which Link State NLRIs will be advertised/ 1499 withdrawn from neighbors is set to 200 updates per second. 1501 6.1.3. Migration Path 1503 The proposed extension is only activated between BGP peers after 1504 capability negotiation. Moreover, the extensions can be turned on/ 1505 off an individual peer basis (see Section 6.2.3), so the extension 1506 can be gradually rolled out in the network. 1508 6.1.4. Requirements on Other Protocols and Functional Components 1510 The protocol extension defined in this document does not put new 1511 requirements on other protocols or functional components. 1513 6.1.5. Impact on Network Operation 1515 Frequency of Link-State NLRI updates could interfere with regular BGP 1516 prefix distribution. A network operator MAY use a dedicated Route- 1517 Reflector infrastructure to distribute Link-State NLRIs. 1519 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1520 domain, which can consist of multiple areas within an AS or multiple 1521 ASes. 1523 6.1.6. Verifying Correct Operation 1525 Existing BGP procedures apply. In addition, an implementation SHOULD 1526 allow an operator to: 1528 o List neighbors with whom the Speaker is exchanging Link-State 1529 NLRIs 1531 6.2. Management Considerations 1533 6.2.1. Management Information 1535 6.2.2. Fault Management 1537 TBD. 1539 6.2.3. Configuration Management 1541 An implementation SHOULD allow the operator to specify neighbors to 1542 which Link-State NLRIs will be advertised and from which Link-State 1543 NLRIs will be accepted. 1545 An implementation SHOULD allow the operator to specify the maximum 1546 rate at which Link State NLRIs will be advertised/withdrawn from 1547 neighbors 1549 An implementation SHOULD allow the operator to specify the maximum 1550 number of Link State NLRIs stored in router's RIB. 1552 An implementation SHOULD allow the operator to create abstracted 1553 topologies that are advertised to neighbors; Create different 1554 abstractions for different neighbors. 1556 An implementation SHOULD allow the operator to configure a 64-bit 1557 instance ID. 1559 An implementation SHOULD allow the operator to configure a pair of 1560 ASN and BGP-LS identifier per flooding set the node participates in. 1562 6.2.4. Accounting Management 1564 Not Applicable. 1566 6.2.5. Performance Management 1568 An implementation SHOULD provide the following statistics: 1570 o Total number of Link-State NLRI updates sent/received 1572 o Number of Link-State NLRI updates sent/received, per neighbor 1574 o Number of errored received Link-State NLRI updates, per neighbor 1576 o Total number of locally originated Link-State NLRIs 1578 6.2.6. Security Management 1580 An operator SHOULD define ACLs to limit inbound updates as follows: 1582 o Drop all updates from Consumer peers 1584 7. TLV/Sub-TLV Code Points Summary 1586 This section contains the global table of all TLVs/Sub-TLVs defined 1587 in this document. 1589 +-----------+---------------------+---------------+-----------------+ 1590 | TLV Code | Description | IS-IS TLV/ | Value defined | 1591 | Point | | Sub-TLV | in: | 1592 +-----------+---------------------+---------------+-----------------+ 1593 | 256 | Local Node | --- | Section 3.2.1.2 | 1594 | | Descriptors | | | 1595 | 257 | Remote Node | --- | Section 3.2.1.3 | 1596 | | Descriptors | | | 1597 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1598 | | Identifiers | | | 1599 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1600 | | address | | | 1601 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1602 | | address | | | 1603 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1604 | | address | | | 1605 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1606 | | address | | | 1607 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1608 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1609 | 265 | IP Reachability | --- | Section 3.2.3 | 1610 | | Information | | | 1611 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1612 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1613 | 514 | Area ID | --- | Section 3.2.1.4 | 1614 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1615 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1616 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1617 | | Properties | | | 1618 | 1026 | Node Name | variable | Section 3.3.1.3 | 1619 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1620 | | Identifier | | | 1621 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1622 | | Local Node | | | 1623 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1624 | | Local Node | | | 1625 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1626 | | Remote Node | | | 1627 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1628 | | Remote Node | | | 1629 | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | 1630 | | group (color) | | | 1631 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1632 | | bandwidth | | | 1633 | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | 1634 | | link bandwidth | | | 1635 | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | 1636 | | bandwidth | | | 1637 | 1092 | TE Default Metric | 22/18 | [RFC5305]/3.7 | 1638 | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | 1639 | | Type | | | 1640 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1641 | 1095 | Metric | --- | Section 3.3.2.3 | 1642 | 1096 | Shared Risk Link | --- | Section 3.3.2.4 | 1643 | | Group | | | 1644 | 1097 | Opaque link | --- | Section 3.3.2.5 | 1645 | | attribute | | | 1646 | 1098 | Link Name attribute | --- | Section 3.3.2.6 | 1647 | 1152 | IGP Flags | --- | Section 3.3.3.1 | 1648 | 1153 | Route Tag | --- | [RFC5130] | 1649 | 1154 | Extended Tag | --- | [RFC5130] | 1650 | 1155 | Prefix Metric | --- | [RFC5305] | 1651 | 1156 | OSPF Forwarding | --- | [RFC2328] | 1652 | | Address | | | 1653 | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | 1654 | | Attribute | | | 1655 +-----------+---------------------+---------------+-----------------+ 1657 Table 11: Summary Table of TLV/Sub-TLV Codepoints 1659 8. Security Considerations 1661 Procedures and protocol extensions defined in this document do not 1662 affect the BGP security model. See 1663 [I-D.ietf-karp-routing-tcp-analysis] for details. 1665 A BGP Speaker SHOULD NOT accept updates from a Consumer peer. 1667 An operator SHOULD employ a mechanism to protect a BGP Speaker 1668 against DDOS attacks from Consumers. 1670 9. Contributors 1672 We would like to thank Robert Varga for the significant contribution 1673 he gave to this document. 1675 10. Acknowledgements 1677 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1678 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1679 Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex 1680 Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, 1681 Vipin Kumar, Naiming Shen, Balaji Rajagopalan and Yakov Rekhter for 1682 their comments. 1684 11. References 1686 11.1. Normative References 1688 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1689 dual environments", RFC 1195, December 1990. 1691 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1692 E. Lear, "Address Allocation for Private Internets", 1693 BCP 5, RFC 1918, February 1996. 1695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1696 Requirement Levels", BCP 14, RFC 2119, March 1997. 1698 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1700 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1701 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1702 March 1999. 1704 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1705 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1706 Tunnels", RFC 3209, December 2001. 1708 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1709 "Internationalizing Domain Names in Applications (IDNA)", 1710 RFC 3490, March 2003. 1712 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1713 Support of Generalized Multi-Protocol Label Switching 1714 (GMPLS)", RFC 4202, October 2005. 1716 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1717 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1719 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1720 "Multiprotocol Extensions for BGP-4", RFC 4760, 1721 January 2007. 1723 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1724 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1725 RFC 4915, June 2007. 1727 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1728 Specification", RFC 5036, October 2007. 1730 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1731 Topology (MT) Routing in Intermediate System to 1732 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1734 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 1735 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1736 February 2008. 1738 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1739 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1740 May 2008. 1742 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1743 Mechanism for IS-IS", RFC 5301, October 2008. 1745 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1746 Engineering", RFC 5305, October 2008. 1748 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1749 of Generalized Multi-Protocol Label Switching (GMPLS)", 1750 RFC 5307, October 2008. 1752 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1753 Engineering in IS-IS", RFC 6119, February 2011. 1755 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1756 Identifier for BGP-4", RFC 6286, June 2011. 1758 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 1759 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1761 11.2. Informative References 1763 [I-D.ietf-alto-protocol] 1764 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1765 draft-ietf-alto-protocol-13 (work in progress), 1766 September 2012. 1768 [I-D.ietf-karp-routing-tcp-analysis] 1769 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1770 BGP, LDP, PCEP and MSDP Issues According to KARP Design 1771 Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in 1772 progress), April 2013. 1774 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1775 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1777 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1779 Shaffer, "Extensions to OSPF for Advertising Optional 1780 Router Capabilities", RFC 4970, July 2007. 1782 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1783 Extensions for Discovery of Traffic Engineering Node 1784 Capabilities", RFC 5073, December 2007. 1786 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1787 Path Computation Method for Establishing Inter-Domain 1788 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1789 RFC 5152, February 2008. 1791 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1792 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1793 Traffic Engineering", RFC 5316, December 2008. 1795 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1796 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1797 Traffic Engineering", RFC 5392, January 2009. 1799 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1800 Optimization (ALTO) Problem Statement", RFC 5693, 1801 October 2009. 1803 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1804 Management of New Protocols and Protocol Extensions", 1805 RFC 5706, November 2009. 1807 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1808 Instance Extensions", RFC 6549, March 2012. 1810 Authors' Addresses 1812 Hannes Gredler 1813 Juniper Networks, Inc. 1814 1194 N. Mathilda Ave. 1815 Sunnyvale, CA 94089 1816 US 1818 Email: hannes@juniper.net 1819 Jan Medved 1820 Cisco Systems, Inc. 1821 170, West Tasman Drive 1822 San Jose, CA 95134 1823 US 1825 Email: jmedved@cisco.com 1827 Stefano Previdi 1828 Cisco Systems, Inc. 1829 Via Del Serafico, 200 1830 Rome 00142 1831 Italy 1833 Email: sprevidi@cisco.com 1835 Adrian Farrel 1836 Juniper Networks, Inc. 1837 1194 N. Mathilda Ave. 1838 Sunnyvale, CA 94089 1839 US 1841 Email: afarrel@juniper.net 1843 Saikat Ray 1844 Cisco Systems, Inc. 1845 170, West Tasman Drive 1846 San Jose, CA 95134 1847 US 1849 Email: sairay@cisco.com