idnits 2.17.1 draft-ietf-idr-ls-distribution-04.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 : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 (November 18, 2013) is 3812 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) ** Downref: Normative reference to an Informational RFC: RFC 4272 ** 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: 4 errors (**), 0 flaws (~~), 3 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: May 22, 2014 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 Cisco Systems, Inc. 11 November 18, 2013 13 North-Bound Distribution of Link-State and TE Information using BGP 14 draft-ietf-idr-ls-distribution-04 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 May 22, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8 82 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 11 83 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 15 84 3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 16 85 3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 18 86 3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 18 87 3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 22 88 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 25 89 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 29 90 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 29 91 3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 29 92 3.7. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 30 93 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 31 94 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 31 95 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 31 96 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 32 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 98 6. Manageability Considerations . . . . . . . . . . . . . . . . 33 99 6.1. Operational Considerations . . . . . . . . . . . . . . . 33 100 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 33 101 6.1.2. Installation and Initial Setup . . . . . . . . . . . 33 102 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 34 103 6.1.4. Requirements on Other Protocols and Functional 104 Components . . . . . . . . . . . . . . . . . . . . . 34 105 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 34 106 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 34 107 6.2. Management Considerations . . . . . . . . . . . . . . . . 34 108 6.2.1. Management Information . . . . . . . . . . . . . . . 34 109 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 34 110 6.2.3. Configuration Management . . . . . . . . . . . . . . 34 111 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 35 112 6.2.5. Performance Management . . . . . . . . . . . . . . . 35 113 6.2.6. Security Management . . . . . . . . . . . . . . . . . 35 114 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 35 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 116 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 11.1. Normative References . . . . . . . . . . . . . . . . . . 38 120 11.2. Informative References . . . . . . . . . . . . . . . . . 39 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 123 1. Introduction 125 The contents of a Link State Database (LSDB) or a Traffic Engineering 126 Database (TED) has the scope of an IGP area. Some applications, such 127 as end-to-end Traffic Engineering (TE), would benefit from visibility 128 outside one area or Autonomous System (AS) in order to make better 129 decisions. 131 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 132 a mechanism for achieving the computation of end-to-end TE paths that 133 cross the visibility of more than one TED or which require CPU- 134 intensive or coordinated computations. The IETF has also defined the 135 ALTO Server [RFC5693] as an entity that generates an abstracted 136 network topology and provides it to network-aware applications. 138 Both a PCE and an ALTO Server need to gather information about the 139 topologies and capabilities of the network in order to be able to 140 fulfill their function. 142 This document describes a mechanism by which Link State and TE 143 information can be collected from networks and shared with external 144 components using the BGP routing protocol [RFC4271]. This is 145 achieved using a new BGP Network Layer Reachability Information 146 (NLRI) encoding format. The mechanism is applicable to physical and 147 virtual links. The mechanism described is subject to policy control. 149 A router maintains one or more databases for storing link-state 150 information about nodes and links in any given area. Link attributes 151 stored in these databases include: local/remote IP addresses, local/ 152 remote interface identifiers, link metric and TE metric, link 153 bandwidth, reservable bandwidth, per CoS class reservation state, 154 preemption and Shared Risk Link Groups (SRLG). The router's BGP 155 process can retrieve topology from these LSDBs and distribute it to a 156 consumer, either directly or via a peer BGP Speaker (typically a 157 dedicated Route Reflector), using the encoding specified in this 158 document. 160 The collection of Link State and TE link state information and its 161 distribution to consumers is shown in the following figure. 163 +-----------+ 164 | Consumer | 165 +-----------+ 166 ^ 167 | 168 +-----------+ 169 | BGP | +-----------+ 170 | Speaker | | Consumer | 171 +-----------+ +-----------+ 172 ^ ^ ^ ^ 173 | | | | 174 +---------------+ | +-------------------+ | 175 | | | | 176 +-----------+ +-----------+ +-----------+ 177 | BGP | | BGP | | BGP | 178 | Speaker | | Speaker | . . . | Speaker | 179 +-----------+ +-----------+ +-----------+ 180 ^ ^ ^ 181 | | | 182 IGP IGP IGP 184 Figure 1: TE Link State info collection 186 A BGP Speaker may apply configurable policy to the information that 187 it distributes. Thus, it may distribute the real physical topology 188 from the LSDB or the TED. Alternatively, it may create an abstracted 189 topology, where virtual, aggregated nodes are connected by virtual 190 paths. Aggregated nodes can be created, for example, out of multiple 191 routers in a POP. Abstracted topology can also be a mix of physical 192 and virtual nodes and physical and virtual links. Furthermore, the 193 BGP Speaker can apply policy to determine when information is updated 194 to the consumer so that there is reduction of information flow form 195 the network to the consumers. Mechanisms through which topologies 196 can be aggregated or virtualized are outside the scope of this 197 document 199 2. Motivation and Applicability 201 This section describes use cases from which the requirements can be 202 derived. 204 2.1. MPLS-TE with PCE 206 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 207 within a "domain" (such as an IGP area) or across multiple domains 208 (such as a multi-area AS, or multiple ASes). 210 o Within a single area, the PCE offers enhanced computational power 211 that may not be available on individual routers, sophisticated 212 policy control and algorithms, and coordination of computation 213 across the whole area. 215 o If a router wants to compute a MPLS-TE path across IGP areas its 216 own TED lacks visibility of the complete topology. That means 217 that the router cannot determine the end-to-end path, and cannot 218 even select the right exit router (Area Border Router - ABR) for 219 an optimal path. This is an issue for large-scale networks that 220 need to segment their core networks into distinct areas, but which 221 still want to take advantage of MPLS-TE. 223 Previous solutions used per-domain path computation [RFC5152]. The 224 source router could only compute the path for the first area because 225 the router only has full topological visibility for the first area 226 along the path, but not for subsequent areas. Per-domain path 227 computation uses a technique called "loose-hop-expansion" [RFC3209], 228 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 229 using the IGP computed shortest path topology for the remainder of 230 the path. This may lead to sub-optimal paths, makes alternate/back- 231 up path computation hard, and might result in no TE path being found 232 when one really does exist. 234 The PCE presents a computation server that may have visibility into 235 more than one IGP area or AS, or may cooperate with other PCEs to 236 perform distributed path computation. The PCE obviously needs access 237 to the TED for the area(s) it serves, but [RFC4655] does not describe 238 how this is achieved. Many implementations make the PCE a passive 239 participant in the IGP so that it can learn the latest state of the 240 network, but this may be sub-optimal when the network is subject to a 241 high degree of churn, or when the PCE is responsible for multiple 242 areas. 244 The following figure shows how a PCE can get its TED information 245 using the mechanism described in this document. 247 +----------+ +---------+ 248 | ----- | | BGP | 249 | | TED |<-+-------------------------->| Speaker | 250 | ----- | TED synchronization | | 251 | | | mechanism: +---------+ 252 | | | BGP with Link-State NLRI 253 | v | 254 | ----- | 255 | | PCE | | 256 | ----- | 257 +----------+ 258 ^ 259 | Request/ 260 | Response 261 v 262 Service +----------+ Signaling +----------+ 263 Request | Head-End | Protocol | Adjacent | 264 -------->| Node |<------------>| Node | 265 +----------+ +----------+ 267 Figure 2: External PCE node using a TED synchronization mechanism 269 The mechanism in this document allows the necessary TED information 270 to be collected from the IGP within the network, filtered according 271 to configurable policy, and distributed to the PCE as necessary. 273 2.2. ALTO Server Network API 275 An ALTO Server [RFC5693] is an entity that generates an abstracted 276 network topology and provides it to network-aware applications over a 277 web service based API. Example applications are p2p clients or 278 trackers, or CDNs. The abstracted network topology comes in the form 279 of two maps: a Network Map that specifies allocation of prefixes to 280 Partition Identifiers (PIDs), and a Cost Map that specifies the cost 281 between PIDs listed in the Network Map. For more details, see 282 [I-D.ietf-alto-protocol]. 284 ALTO abstract network topologies can be auto-generated from the 285 physical topology of the underlying network. The generation would 286 typically be based on policies and rules set by the operator. Both 287 prefix and TE data are required: prefix data is required to generate 288 ALTO Network Maps, TE (topology) data is required to generate ALTO 289 Cost Maps. Prefix data is carried and originated in BGP, TE data is 290 originated and carried in an IGP. The mechanism defined in this 291 document provides a single interface through which an ALTO Server can 292 retrieve all the necessary prefix and network topology data from the 293 underlying network. Note an ALTO Server can use other mechanisms to 294 get network data, for example, peering with multiple IGP and BGP 295 Speakers. 297 The following figure shows how an ALTO Server can get network 298 topology information from the underlying network using the mechanism 299 described in this document. 301 +--------+ 302 | Client |<--+ 303 +--------+ | 304 | ALTO +--------+ BGP with +---------+ 305 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 306 | Client |<--+------------| Server |<----------------| Speaker | 307 +--------+ | | | | | 308 | +--------+ +---------+ 309 +--------+ | 310 | Client |<--+ 311 +--------+ 313 Figure 3: ALTO Server using network topology information 315 3. Carrying Link State Information in BGP 317 This specification contains two parts: definition of a new BGP NLRI 318 that describes links, nodes and prefixes comprising IGP link state 319 information, and definition of a new BGP path attribute (BGP-LS 320 attribute) that carries link, node and prefix properties and 321 attributes, such as the link and prefix metric or auxiliary Router- 322 IDs of nodes, etc. 324 3.1. TLV Format 326 Information in the new Link-State NLRIs and attributes is encoded in 327 Type/Length/Value triplets. The TLV format is shown in Figure 4. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 // Value (variable) // 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 4: TLV format 339 The Length field defines the length of the value portion in octets 340 (thus a TLV with no value portion would have a length of zero). The 341 TLV is not padded to four-octet alignment. Unrecognized types are 342 preserved and propagated. In order to compare NLRIs with unknown 343 TLVs all TLVs MUST be ordered in ascending order. If there are more 344 TLVs of the same type, then the TLVs MUST be ordered in ascending 345 order of the TLV value within the set of TLVs with the same type. 346 All TLVs that are not specified as mandatory are considered optional. 348 3.2. The Link-State NLRI 350 The MP_REACH and MP_UNREACH attributes are BGP's containers for 351 carrying opaque information. Each Link-State NLRI describes either a 352 node, a link or a prefix. 354 All non-VPN link, node and prefix information SHALL be encoded using 355 AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be 356 encoded using AFI 16388 / SAFI 128. 358 In order for two BGP speakers to exchange Link-State NLRI, they MUST 359 use BGP Capabilities Advertisement to ensure that they both are 360 capable of properly processing such NLRI. This is done as specified 361 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 362 an AFI 16388 / SAFI 71 and AFI 16388 / SAFI 128 for the VPN flavor. 364 The format of the Link-State NLRI is shown in the following figure. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | NLRI Type | Total NLRI Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 // Link-State NLRI (variable) // 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 5: Link-State AFI 16388 / SAFI 71 NLRI Format 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | NLRI Type | Total NLRI Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 + Route Distinguisher + 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 // Link-State NLRI (variable) // 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 6: Link-State VPN AFI 16388 / SAFI 128 NLRI Format 394 The 'Total NLRI Length' field contains the cumulative length, in 395 octets, of rest of the NLRI not including the NLRI Type field or 396 itself. For VPN applications it also includes the length of the 397 Route Distinguisher. 399 The 'NLRI Type' field can contain one of the following values: 401 Type = 1: Node NLRI 403 Type = 2: Link NLRI 405 Type = 3: IPv4 Topology Prefix NLRI 407 Type = 4: IPv6 Topology Prefix NLRI 409 The Node NLRI (NLRI Type = 1) is shown in the following figure. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+ 414 | Protocol-ID | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Identifier | 417 | (64 bits) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 // Local Node Descriptors (variable) // 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 7: The Node NLRI format 424 The Link NLRI (NLRI Type = 2) is shown in the following figure. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+ 429 | Protocol-ID | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Identifier | 432 | (64 bits) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 // Local Node Descriptors (variable) // 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 // Remote Node Descriptors (variable) // 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 // Link Descriptors (variable) // 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 8: The Link NLRI format 443 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 444 same format as shown in the following figure. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+ 449 | Protocol-ID | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Identifier | 452 | (64 bits) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 // Local Node Descriptor (variable) // 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 // Prefix Descriptors (variable) // 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 9: The IPv4/IPv6 Topology Prefix NLRI format 461 The 'Protocol-ID' field can contain one of the following values: 463 Protocol-ID = 0: Unknown, The source of NLRI information could not 464 be determined 466 Protocol-ID = 1: IS-IS Level 1, The NLRI information has been 467 sourced by IS-IS Level 1 469 Protocol-ID = 2: IS-IS Level 2, The NLRI information has been 470 sourced by IS-IS Level 2 472 Protocol-ID = 3: OSPF, The NLRI information has been sourced by 473 OSPF 474 Protocol-ID = 4: Direct, The NLRI information has been sourced 475 from local interface state 477 Protocol-ID = 5: Static, The NLRI information has been sourced by 478 static configuration 480 Both OSPF and IS-IS may run multiple routing protocol instances over 481 the same link. See [RFC6822] and [RFC6549]. These instances define 482 independent "routing universes". The 64-Bit 'Identifier' field is 483 used to identify the "routing universe" where the NLRI belongs. The 484 NLRIs representing IGP objects (nodes, links or prefixes) from the 485 same routing universe MUST have the same 'Identifier' value; NLRIs 486 with different 'Identifier' values MUST be considered to be from 487 different routing universes. Table Table 1 lists the 'Identifier' 488 values that are defined as well-known in this draft. 490 +------------+---------------------+ 491 | Identifier | Routing Universe | 492 +------------+---------------------+ 493 | 0 | L3 packet topology | 494 | 1 | L1 optical topology | 495 +------------+---------------------+ 497 Table 1: Well-known Instance Identifiers 499 Each Node Descriptor and Link Descriptor consists of one or more TLVs 500 described in the following sections. 502 3.2.1. Node Descriptors 504 Each link is anchored by a pair of Router-IDs that are used by the 505 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 506 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 507 additional auxiliary Router-IDs, mainly for traffic engineering 508 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 509 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 510 included in the link attribute described in Section Section 3.3.2. 512 It is desirable that the Router-ID assignments inside the Node 513 Descriptor are globally unique. However there may be Router-ID 514 spaces (e.g. ISO) where no global registry exists, or worse, Router- 515 IDs have been allocated following private-IP RFC 1918 [RFC1918] 516 allocation. We use Autonomous System (AS) Number and BGP-LS 517 Identifier in order to disambiguate the Router-IDs, as described in 518 Section 3.2.1.1. 520 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 521 One problem that needs to be addressed is the ability to identify an 522 IGP node globally (by "global", we mean within the BGP-LS database 523 collected by all BGP-LS speakers that talk to each other). This can 524 be expressed through the following two requirements: 526 (A) The same node must not be represented by two keys (otherwise one 527 node will look like two nodes). 529 (B) Two different nodes must not be represented by the same key 530 (otherwise, two nodes will look like one node). 532 We define an "IGP domain" to be the set of nodes (hence, by extension 533 links and prefixes), within which, each node has a unique IGP 534 representation by using the combination of Area-ID, Router-ID, 535 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 536 receive node/link/prefix information from multiple independent "IGP 537 domains" and we need to distinguish between them. Moreover, we can't 538 assume there is always one and only one IGP domain per AS. During 539 IGP transitions it may happen that two redundant IGPs are in place. 541 In section Section 3.2.1.4 a set of sub-TLVs is described, which 542 allows to specify a flexible key for any given Node/Link information 543 such that global uniqueness of the NLRI is ensured. 545 3.2.1.2. Local Node Descriptors 547 The Local Node Descriptors TLV contains Node Descriptors for the node 548 anchoring the local end of the link. This is a mandatory TLV in all 549 three types of NLRIs. The length of this TLV is variable. The value 550 contains one or more Node Descriptor Sub-TLVs defined in 551 Section 3.2.1.4. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type | Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 // Node Descriptor Sub-TLVs (variable) // 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Figure 10: Local Node Descriptors TLV format 565 3.2.1.3. Remote Node Descriptors 567 The Remote Node Descriptors contains Node Descriptors for the node 568 anchoring the remote end of the link. This is a mandatory TLV for 569 link NLRIs. The length of this TLV is variable. The value contains 570 one or more Node Descriptor Sub-TLVs defined in 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 11: Remote Node Descriptors TLV format 584 3.2.1.4. Node Descriptor Sub-TLVs 586 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 587 the following table: 589 +--------------------+-------------------+----------+ 590 | Sub-TLV Code Point | Description | Length | 591 +--------------------+-------------------+----------+ 592 | 512 | Autonomous System | 4 | 593 | 513 | BGP-LS Identifier | 4 | 594 | 514 | Area-ID | 4 | 595 | 515 | IGP Router-ID | Variable | 596 +--------------------+-------------------+----------+ 598 Table 2: Node Descriptor Sub-TLVs 600 The sub-TLV values in Node Descriptor TLVs are defined as follows: 602 Autonomous System: opaque value (32 Bit AS Number) 604 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with 605 ASN, uniquely identifies the BGP-LS domain. The combination of 606 ASN and BGP-LS ID MUST be globally unique. All BGP-LS speakers 607 within an IGP flooding-set (set of IGP nodes within which an LSP/ 608 LSA is flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP 609 domain consists of multiple flooding-sets, then all BGP-LS 610 speakers within the IGP domain SHOULD use the same ASN, BGP-LS ID 611 tuple. The ASN, BGP Router-ID tuple (which is globally unique 612 [RFC6286] ) of one of the BGP-LS speakers within the flooding-set 613 (or IGP domain) may be used for all BGP-LS speakers in that 614 flooding-set (or IGP domain). 616 Area ID: It is used to identify the 32 Bit area to which the NLRI 617 belongs. Area Identifier allows the different NLRIs of the same 618 router to be discriminated. 620 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 621 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 622 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 623 octet ISO node-ID of the "Designated Intermediate System" (DIS) 624 followed by one octet nonzero PSN identifier (7 octet in total). 625 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains 4 octet 626 Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this 627 contains 4 octet Router-ID of the designated router (DR) followed 628 by 4 octet IPv4 address of the DR's interface to the LAN (8 octet 629 in total). Similarly, for an OSPFv3 "Pseudonode", this contains 4 630 octet Router-ID of the DR followed by 4 octet interface identifier 631 of the DR's interface to the LAN (8 octet in total). The TLV size 632 in combination with protocol identifier enables the decoder to 633 determine the type of the node. 635 There can be at most one instance of each sub-TLV type present in 636 any Node Descriptor. The TLV ordering within a Node descriptor 637 MUST be kept in order of increasing numeric value of type. This 638 needs to be done in order to compare NLRIs, even when an 639 implementation encounters an unknown sub-TLV. Using stable 640 sorting an implementation can do binary comparison of NLRIs and 641 hence allow incremental deployment of new key sub-TLVs. 643 3.2.1.5. Multi-Topology ID 645 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 646 Multi-Topology IDs for a link, node or prefix. 648 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 649 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 650 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 651 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 652 SHOULD be set to 0 when originated and ignored on receipt. 654 The format of the MT-ID TLV is shown in the following figure. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type | Length=2*n | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 |R R R R| Multi-Topology ID 1 | .... // 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 // .... |R R R R| Multi-Topology ID n | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 12: Multi-Topology ID TLV format 668 where Type is 263, Length is 2*n and n is the number of MT-IDs 669 carried in the TLV. 671 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 672 Descriptor, or in the BGP-LS attribute of a node NLRI. In Link or 673 Prefix Descriptor, only one MT-ID TLV containing only the MT-ID of 674 the topology where the link or the prefix belongs is allowed. In the 675 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array 676 of MT-IDs of all topologies where the node belongs can be present. 678 3.2.2. Link Descriptors 680 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 681 triplets. The format of each TLV is shown in Section 3.1. The 'Link 682 descriptor' TLVs uniquely identify a link among multiple parallel 683 links between a pair of anchor routers. A link described by the Link 684 descriptor TLVs actually is a "half-link", a unidirectional 685 representation of a logical link. In order to fully describe a 686 single logical link two originating routers advertise a half-link 687 each, i.e. two link NLRIs are advertised for a given point-to-point 688 link. 690 The format and semantics of the 'value' fields in most 'Link 691 Descriptor' TLVs correspond to the format and semantics of value 692 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 693 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 694 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 695 carry data sourced either by IS-IS or OSPF. 697 The following TLVs are valid as Link Descriptors in the Link NLRI: 699 +------------+--------------------+---------------+-----------------+ 700 | TLV Code | Description | IS-IS TLV | Value defined | 701 | Point | | /Sub-TLV | in: | 702 +------------+--------------------+---------------+-----------------+ 703 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 704 | | Identifiers | | | 705 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 706 | | address | | | 707 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 708 | | address | | | 709 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 710 | | address | | | 711 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 712 | | address | | | 713 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 714 | | Identifier | | | 715 +------------+--------------------+---------------+-----------------+ 717 Table 3: Link Descriptor TLVs 719 3.2.3. Prefix Descriptors 721 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 722 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 723 Prefix originated by a Node. The following TLVs are valid as Prefix 724 Descriptors in the IPv4/IPv6 Prefix NLRI: 726 +-----------+--------------------------+------------+---------------+ 727 | TLV Code | Description | Length | Value defined | 728 | Point | | | in: | 729 +-----------+--------------------------+------------+---------------+ 730 | 263 | Multi-Topology | variable | Section | 731 | | Identifier | | 3.2.1.5 | 732 | 264 | OSPF Route Type | 1 | Section | 733 | | | | 3.2.3.1 | 734 | 265 | IP Reachability | variable | Section | 735 | | Information | | 3.2.3.2 | 736 +-----------+--------------------------+------------+---------------+ 738 Table 4: Prefix Descriptor TLVs 740 3.2.3.1. OSPF Route Type 742 OSPF Route Type is an optional TLV that MAY be present in Prefix 743 NLRIs. It is used to identify the OSPF route-type of the prefix. It 744 is used when an OSPF prefix is advertised in the OSPF domain with 745 multiple different route-types. The Route Type TLV allows to 746 discriminate these advertisements. The format of the OSPF Route Type 747 TLV is shown in the following figure. 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Route Type | 755 +-+-+-+-+-+-+-+-+ 757 Figure 13: OSPF Route Type TLV Format 759 where the Type and Length fields of the TLV are defined in Table 4. 760 The OSPF Route Type field values are defined in the OSPF protocol, 761 and can be one of the following: 763 Intra-Area (0x1) 765 Inter-Area (0x2) 767 External 1 (0x3) 769 External 2 (0x4) 771 NSSA 1 (0x5) 773 NSSA 2 (0x6) 775 3.2.3.2. IP Reachability Information 777 The IP Reachability Information is a mandatory TLV that contains one 778 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 779 topology. Its purpose is to glue a particular BGP service NLRI vi 780 virtue of its BGP next-hop to a given Node in the LSDB. A router 781 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 782 The format of the IP Reachability Information TLV is shown in the 783 following figure: 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Type | Length | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Prefix Length | IP Prefix (variable) // 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Figure 14: IP Reachability Information TLV Format 795 The Type and Length fields of the TLV are defined in Table 4. The 796 following two fields determine the address-family reachability 797 information. The 'Prefix Length' field contains the length of the 798 prefix in bits. The 'IP Prefix' field contains the most significant 799 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 800 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 801 24 and 4 octets for prefix length 25 up to 32, etc. 803 3.3. The BGP-LS Attribute 805 This is an optional, non-transitive BGP attribute that is used to 806 carry link, node and prefix parameters and attributes. It is defined 807 as a set of Type/Length/Value (TLV) triplets, described in the 808 following section. This attribute SHOULD only be included with Link- 809 State NLRIs. This attribute MUST be ignored for all other address- 810 families. 812 3.3.1. Node Attribute TLVs 814 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 815 attribute with a node NLRI. The following node attribute TLVs are 816 defined: 818 +-----------+----------------------+------------+-------------------+ 819 | TLV Code | Description | Length | Value defined in: | 820 | Point | | | | 821 +-----------+----------------------+------------+-------------------+ 822 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 823 | | Identifier | | | 824 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 825 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 826 | | Properties | | | 827 | 1026 | Node Name | variable | Section 3.3.1.3 | 828 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 829 | | Identifier | | | 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 BGP-LS 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 TLV | Defined in: | 966 | Point | | /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 group | 22/3 | [RFC5305]/3.1 | 977 | | (color) | | | 978 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 979 | | bandwidth | | | 980 | 1090 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 981 | | bandwidth | | | 982 | 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 983 | 1092 | TE Default Metric | 22/18 | [RFC5305]/3.7 | 984 | 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 985 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 986 | 1095 | Metric | --- | Section 3.3.2.3 | 987 | 1096 | Shared Risk Link | --- | Section 3.3.2.4 | 988 | | Group | | | 989 | 1097 | Opaque link | --- | Section 3.3.2.5 | 990 | | attribute | | | 991 | 1098 | Link Name attribute | --- | Section 3.3.2.6 | 992 +----------+----------------------+---------------+-----------------+ 994 Table 7: Link Attribute TLVs 996 3.3.2.1. IPv4/IPv6 Router-ID 998 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 999 auxiliary Router-IDs that the IGP might be using, e.g., for TE 1000 purposes. All auxiliary Router-IDs of both the local and the remote 1001 node MUST be included in the link attribute of each link NLRI. If 1002 there are more than one auxiliary Router-ID of a given type, then 1003 multiple TLVs are used to encode them. 1005 3.3.2.2. MPLS Protocol Mask TLV 1007 The MPLS Protocol TLV carries a bit mask describing which MPLS 1008 signaling protocols are enabled. The length of this TLV is 1. The 1009 value is a bit array of 8 flags, where each bit represents an MPLS 1010 Protocol capability. 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Type | Length | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 |L|R| Reserved | 1018 +-+-+-+-+-+-+-+-+ 1020 Figure 19: MPLS Protocol TLV 1022 The following bits are defined: 1024 +----------------+----------------------------------+---------------+ 1025 | Bit | Description | Reference | 1026 +----------------+----------------------------------+---------------+ 1027 | 'L' | Label Distribution Protocol | [RFC5036] | 1028 | | (LDP) | | 1029 | 'R' | Extension to RSVP for LSP | [RFC3209] | 1030 | | Tunnels (RSVP-TE) | | 1031 | 'Reserved' | Reserved for future use | | 1032 +----------------+----------------------------------+---------------+ 1034 Table 8: MPLS Protocol Mask TLV Codes 1036 3.3.2.3. Metric TLV 1038 The IGP Metric TLV carries the metric for this link. The length of 1039 this TLV is variable, depending on the metric width of the underlying 1040 protocol. IS-IS small metrics have a length of 1 octet (the two most 1041 significant bits are ignored). OSPF metrics have a length of two 1042 octects. IS-IS wide-metrics have a length of three octets. 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Type | Length | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 // IGP Link Metric (variable length) // 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 Figure 20: Metric TLV format 1054 3.3.2.4. Shared Risk Link Group TLV 1056 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1057 Group information (see Section 2.3, "Shared Risk Link Group 1058 Information", of [RFC4202]). It contains a data structure consisting 1059 of a (variable) list of SRLG values, where each element in the list 1060 has 4 octets, as shown in Figure 21. The length of this TLV is 4 * 1061 (number of SRLG values). 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Type | Length | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Shared Risk Link Group Value | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 // ............ // 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Shared Risk Link Group Value | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 Figure 21: Shared Risk Link Group TLV format 1077 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 1078 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1079 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1080 defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG 1081 information are carried in a single TLV. 1083 3.3.2.5. Opaque Link Attribute TLV 1085 The Opaque link attribute TLV is an envelope that transparently 1086 carries optional link atrribute TLVs advertised by a router. An 1087 originating router shall use this TLV for encoding information 1088 specific to the protocol advertised in the NLRI header Protocol-ID 1089 field or new protocol extensions to the protocol as advertised in the 1090 NLRI header Protocol-ID field for which there is no protocol neutral 1091 representation in the BGP link-state NLRI. 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Type | Length | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 // Opaque link attributes (variable) // 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 Figure 22: Opaque link attribute format 1103 3.3.2.6. Link Name TLV 1105 The Link Name TLV is optional. The value field identifies the 1106 symbolic name of the router link. This symbolic name can be the FQDN 1107 for the link, it can be a subset of the FQDN, or it can be any string 1108 operators want to use for the link. The use of FQDN or a subset of 1109 it is strongly recommended. 1111 The Value field is encoded in 7-bit ASCII. If a user-interface for 1112 configuring or displaying this field permits Unicode characters, that 1113 user-interface is responsible for applying the ToASCII and/or 1114 ToUnicode algorithm as described in [RFC3490] to achieve the correct 1115 format for transmission or display. 1117 How a router derives and injects link names is outside of the scope 1118 of this document. 1120 0 1 2 3 1121 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 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Type | Length | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 // Link Name (variable) // 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 Figure 23: Link Name format 1130 3.3.3. Prefix Attribute TLVs 1132 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1133 of IGP attributes (such as metric, route tags, etc.) that MUST be 1134 reflected into the LINK_STATE attribute. This section describes the 1135 different attributes related to the IPv4/IPv6 prefixes. Prefix 1136 Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 1137 only. The following attributes TLVs are defined: 1139 +-------------+---------------------+--------------+----------------+ 1140 | TLV Code | Description | Length | Reference | 1141 | Point | | | | 1142 +-------------+---------------------+--------------+----------------+ 1143 | 1152 | IGP Flags | 1 | Section | 1144 | | | | 3.3.3.1 | 1145 | 1153 | Route Tag | 4*n | Section | 1146 | | | | 3.3.3.2 | 1147 | 1154 | Extended Tag | 8*n | Section | 1148 | | | | 3.3.3.3 | 1149 | 1155 | Prefix Metric | 4 | Section | 1150 | | | | 3.3.3.4 | 1151 | 1156 | OSPF Forwarding | 4 | Section | 1152 | | Address | | 3.3.3.5 | 1153 | 1157 | Opaque Prefix | variable | Section | 1154 | | Attribute | | 3.3.3.6 | 1155 +-------------+---------------------+--------------+----------------+ 1157 Table 9: Prefix Attribute TLVs 1159 3.3.3.1. IGP Flags TLV 1161 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1162 assigned tothe prefix. The IGP Flags TLV is encoded as follows: 1164 0 1 2 3 1165 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 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Type | Length | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 |D| Reserved | 1170 +-+-+-+-+-+-+-+-+ 1172 Figure 24: IGP Flag TLV format 1174 The value field contains bits defined according to the table below: 1176 +----------+--------------------------+-----------+ 1177 | Bit | Description | Reference | 1178 +----------+--------------------------+-----------+ 1179 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1180 | Reserved | Reserved for future use. | | 1181 +----------+--------------------------+-----------+ 1183 Table 10: IGP Flag Bits Definitions 1185 3.3.3.2. Route Tag 1187 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1188 the prefix and is encoded as follows: 1190 0 1 2 3 1191 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 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Type | Length | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 // Route Tags (one or more) // 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Figure 25: IGP Route TAG TLV format 1200 Length is a multiple of 4. 1202 The value field contains one or more Route Tags as learned in the IGP 1203 topology. 1205 3.3.3.3. Extended Route Tag 1207 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1208 prefix [RFC5130] and is encoded as follows: 1210 0 1 2 3 1211 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 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | Type | Length | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 // Extended Route Tag (one or more) // 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 Figure 26: Extended IGP Route TAG TLV format 1220 Length is a multiple of 8. 1222 The 'Extended Route Tag' field contains one or more Extended Route 1223 Tags as learned in the IGP topology. 1225 3.3.3.4. Prefix Metric TLV 1227 Prefix Metric TLV carries the metric of the prefix as known in the 1228 IGP topology [RFC5305]. The attribute is mandatory and can only 1229 appear once. 1231 0 1 2 3 1232 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 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Type | Length | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Metric | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 Figure 27: Prefix Metric TLV Format 1241 Length is 4. 1243 3.3.3.5. OSPF Forwarding Address TLV 1245 OSPF Forwarding Address TLV [RFC2328] carries the OSPF forwarding 1246 address as known in the original OSPF advertisement. Forwarding 1247 address can be either IPv4 or IPv6. 1249 0 1 2 3 1250 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 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Type | Length | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 // Forwarding Address (variable) // 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 Figure 28: OSPF Forwarding Address TLV Format 1259 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1260 forwarding address. 1262 3.3.3.6. Opaque Prefix Attribute TLV 1264 The Opaque Prefix attribute TLV is an envelope that transparently 1265 carries optional prefix attribute TLVs advertised by a router. An 1266 originating router shall use this TLV for encoding information 1267 specific to the protocol advertised in the NLRI header Protocol-ID 1268 field or new protocol extensions to the protocol as advertised in the 1269 NLRI header Protocol-ID field for which there is no protocol neutral 1270 representation in the BGP link-state NLRI. 1272 The format of the TLV is as follows: 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Type | Length | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 // Opaque Prefix Attributes (variable) // 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Figure 29: Opaque Prefix Attribute TLV Format 1284 Type is as specified in Table 9 and Length is variable. 1286 3.4. BGP Next Hop Information 1288 BGP link-state information for both IPv4 and IPv6 networks can be 1289 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1290 IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1291 SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, 1292 then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. 1293 Usually the next hop will be set to the local end-point address of 1294 the BGP session. The next hop address MUST be encoded as described 1295 in [RFC4760]. The length field of the next hop address will specify 1296 the next hop address-family. If the next hop length is 4, then the 1297 next hop is an IPv4 address; if the next hop length is 16, then it is 1298 a global IPv6 address and if the next hop length is 32, then there is 1299 one global IPv6 address followed by a link-local IPv6 address. The 1300 link-local IPv6 address should be used as described in [RFC2545]. 1301 For VPN SAFI, as per custom, an 8 byte route-distinguisher set to all 1302 zero is prepended to the next hop. 1304 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1305 the NLRI it receives. However, this specification doesn't mandate 1306 any rule regarding the re-write of the BGP Next Hop attribute. 1308 3.5. Inter-AS Links 1310 The main source of TE information is the IGP, which is not active on 1311 inter-AS links. In some cases, the IGP may have information of 1312 inter-AS links ([RFC5392], [RFC5316]). In other cases, an 1313 implementation SHOULD provide a means to inject inter-AS links into 1314 BGP-LS. The exact mechanism used to provision the inter-AS links is 1315 outside the scope of this document 1317 3.6. Router-ID Anchoring Example: ISO Pseudonode 1318 Encoding of a broadcast LAN in IS-IS provides a good example of how 1319 Router-IDs are encoded. Consider Figure 30. This represents a 1320 Broadcast LAN between a pair of routers. The "real" (=non 1321 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1322 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1323 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1324 (Pseudonode1, Node2) are being generated. 1326 The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP 1327 Router-ID TLV of the local node descriptor is 6 octets long 1328 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1329 the remote node descriptor is 7 octets long containing the ISO-ID of 1330 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1331 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1332 192.0.2.1, the IPv4 Router-ID of Node1. 1334 The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP 1335 Router-ID TLV of the local node descriptor is 7 octets long 1336 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1337 Router-ID TLV of the remote node descriptor is 6 octets long 1338 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1339 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1340 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1342 +-----------------+ +-----------------+ +-----------------+ 1343 | Node1 | | Pseudonode1 | | Node2 | 1344 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1345 | 192.0.2.1 | | | | 192.0.2.2 | 1346 +-----------------+ +-----------------+ +-----------------+ 1348 Figure 30: IS-IS Pseudonodes 1350 3.7. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1352 Graceful migration from one IGP to another requires coordinated 1353 operation of both protocols during the migration period. Such a 1354 coordination requires identifying a given physical link in both IGPs. 1355 The IPv4 Router-ID provides that "glue" which is present in the node 1356 descriptors of the OSPF link NLRI and in the link attribute of the 1357 IS-IS link NLRI. 1359 Consider a point-to-point link between two routers, A and B, that 1360 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1361 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1362 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1363 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1364 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1365 in the local and remote node descriptors, respectively. The IS-IS 1366 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1367 the local and remote node descriptors, respectively. In addition, 1368 the BGP-LS attribute of the IS-IS link NLRI contains the the TLV type 1369 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1370 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1371 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1372 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1374 4. Link to Path Aggregation 1376 Distribution of all links available in the global Internet is 1377 certainly possible, however not desirable from a scaling and privacy 1378 point of view. Therefore an implementation may support link to path 1379 aggregation. Rather than advertising all specific links of a domain, 1380 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1381 of nodes. The "aggregate link" represents the aggregated set of link 1382 properties between a pair of non-adjacent nodes. The actual methods 1383 to compute the path properties (of bandwidth, metric) are outside the 1384 scope of this document. The decision whether to advertise all 1385 specific links or aggregated links is an operator's policy choice. 1386 To highlight the varying levels of exposure, the following deployment 1387 examples are discussed. 1389 4.1. Example: No Link Aggregation 1391 Consider Figure 31. Both AS1 and AS2 operators want to protect their 1392 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1393 compute its link-protection LSP to R3 it needs to "see" an alternate 1394 path to R3. Therefore the AS2 operator exposes its topology. All 1395 BGP TE enabled routers in AS1 "see" the full topology of AS and 1396 therefore can compute a backup path. Note that the decision if the 1397 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1398 by the computing router. 1400 AS1 : AS2 1401 : 1402 R1-------R3 1403 | : | \ 1404 | : | R5 1405 | : | / 1406 R2-------R4 1407 : 1408 : 1410 Figure 31: No link aggregation 1412 4.2. Example: ASBR to ASBR Path Aggregation 1413 The brief difference between the "no-link aggregation" example and 1414 this example is that no specific link gets exposed. Consider Figure 1415 32. The only link which gets advertised by AS2 is an "aggregate" 1416 link between R3 and R4. This is enough to tell AS1 that there is a 1417 backup path. However the actual links being used are hidden from the 1418 topology. 1420 AS1 : AS2 1421 : 1422 R1-------R3 1423 | : | 1424 | : | 1425 | : | 1426 R2-------R4 1427 : 1428 : 1430 Figure 32: ASBR link aggregation 1432 4.3. Example: Multi-AS Path Aggregation 1434 Service providers in control of multiple ASes may even decide to not 1435 expose their internal inter-AS links. Consider Figure 33. AS3 is 1436 modeled as a single node which connects to the border routers of the 1437 aggregated domain. 1439 AS1 : AS2 : AS3 1440 : : 1441 R1-------R3----- 1442 | : : \ 1443 | : : vR0 1444 | : : / 1445 R2-------R4----- 1446 : : 1447 : : 1449 Figure 33: Multi-AS aggregation 1451 5. IANA Considerations 1453 This document requests a code point from the registry of Address 1454 Family Numbers. As per early allocation procedure this is AFI 16388. 1456 This document requests a code point from the registry of Subsequent 1457 Address Family Numbers. As per early allocation procedure this is 1458 SAFI 71. 1460 This document requests a code point from the BGP Path Attributes 1461 registry. 1463 This document requests creation of a new registry for node anchor, 1464 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1465 Values 256-65535 will be used for Codepoints. The registry will be 1466 initialized as shown in Table 11. Allocations within the registry 1467 will require documentation of the proposed use of the allocated value 1468 and approval by the Designated Expert assigned by the IESG (see 1469 [RFC5226]). 1471 Note to RFC Editor: this section may be removed on publication as an 1472 RFC. 1474 6. Manageability Considerations 1476 This section is structured as recommended in [RFC5706]. 1478 6.1. Operational Considerations 1480 6.1.1. Operations 1482 Existing BGP operational procedures apply. No new operation 1483 procedures are defined in this document. It is noted that the NLRI 1484 information present in this document purely carries application level 1485 data that has no immediate corresponding forwarding state impact. As 1486 such, any churn in reachability information has different impact than 1487 regular BGP updates which need to change forwarding state for an 1488 entire router. Furthermore it is anticipated that distribution of 1489 this NLRI will be handled by dedicated route-reflectors providing a 1490 level of isolation and fault-containment between different NLRI 1491 types. 1493 6.1.2. Installation and Initial Setup 1495 Configuration parameters defined in Section 6.2.3 SHOULD be 1496 initialized to the following default values: 1498 o The Link-State NLRI capability is turned off for all neighbors. 1500 o The maximum rate at which Link-State NLRIs will be advertised/ 1501 withdrawn from neighbors is set to 200 updates per second. 1503 6.1.3. Migration Path 1505 The proposed extension is only activated between BGP peers after 1506 capability negotiation. Moreover, the extensions can be turned on/ 1507 off an individual peer basis (see Section 6.2.3), so the extension 1508 can be gradually rolled out in the network. 1510 6.1.4. Requirements on Other Protocols and Functional Components 1512 The protocol extension defined in this document does not put new 1513 requirements on other protocols or functional components. 1515 6.1.5. Impact on Network Operation 1517 Frequency of Link-State NLRI updates could interfere with regular BGP 1518 prefix distribution. A network operator MAY use a dedicated Route- 1519 Reflector infrastructure to distribute Link-State NLRIs. 1521 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1522 domain, which can consist of multiple areas within an AS or multiple 1523 ASes. 1525 6.1.6. Verifying Correct Operation 1527 Existing BGP procedures apply. In addition, an implementation SHOULD 1528 allow an operator to: 1530 o List neighbors with whom the Speaker is exchanging Link-State 1531 NLRIs 1533 6.2. Management Considerations 1535 6.2.1. Management Information 1537 6.2.2. Fault Management 1539 TBD. 1541 6.2.3. Configuration Management 1543 An implementation SHOULD allow the operator to specify neighbors to 1544 which Link-State NLRIs will be advertised and from which Link-State 1545 NLRIs will be accepted. 1547 An implementation SHOULD allow the operator to specify the maximum 1548 rate at which Link-State NLRIs will be advertised/withdrawn from 1549 neighbors 1550 An implementation SHOULD allow the operator to specify the maximum 1551 number of Link-State NLRIs stored in router's RIB. 1553 An implementation SHOULD allow the operator to create abstracted 1554 topologies that are advertised to neighbors; Create different 1555 abstractions for different neighbors. 1557 An implementation SHOULD allow the operator to configure a 64-bit 1558 instance ID. 1560 An implementation SHOULD allow the operator to configure a pair of 1561 ASN and BGP-LS identifier per flooding set the node participates in. 1563 6.2.4. Accounting Management 1565 Not Applicable. 1567 6.2.5. Performance Management 1569 An implementation SHOULD provide the following statistics: 1571 o Total number of Link-State NLRI updates sent/received 1573 o Number of Link-State NLRI updates sent/received, per neighbor 1575 o Number of errored received Link-State NLRI updates, per neighbor 1577 o Total number of locally originated Link-State NLRIs 1579 6.2.6. Security Management 1581 An operator SHOULD define ACLs to limit inbound updates as follows: 1583 o Drop all updates from Consumer peers 1585 7. TLV/Sub-TLV Code Points Summary 1587 This section contains the global table of all TLVs/Sub-TLVs defined 1588 in this document. 1590 +---------+----------------------+--------------+-------------------+ 1591 | TLV | Description | IS-IS TLV/ | Value defined in: | 1592 | Code | | Sub-TLV | | 1593 | Point | | | | 1594 +---------+----------------------+--------------+-------------------+ 1595 | 256 | Local Node | --- | Section 3.2.1.2 | 1596 | | Descriptors | | | 1597 | 257 | Remote Node | --- | Section 3.2.1.3 | 1598 | | Descriptors | | | 1599 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1600 | | Identifiers | | | 1601 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1602 | | address | | | 1603 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1604 | | address | | | 1605 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1606 | | address | | | 1607 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1608 | | address | | | 1609 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1610 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1611 | 265 | IP Reachability | --- | Section 3.2.3 | 1612 | | Information | | | 1613 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1614 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1615 | 514 | Area ID | --- | Section 3.2.1.4 | 1616 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1617 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1618 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1619 | | Properties | | | 1620 | 1026 | Node Name | variable | Section 3.3.1.3 | 1621 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1622 | | Identifier | | | 1623 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1624 | | Local Node | | | 1625 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1626 | | Local Node | | | 1627 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1628 | | Remote Node | | | 1629 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1630 | | Remote Node | | | 1631 | 1088 | Administrative group | 22/3 | [RFC5305]/3.1 | 1632 | | (color) | | | 1633 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1634 | | bandwidth | | | 1635 | 1090 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 1636 | | bandwidth | | | 1637 | 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 1638 | 1092 | TE Default Metric | 22/18 | [RFC5305]/3.7 | 1639 | 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 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 the 'Security Considerations' 1663 section of [RFC4271] for a discussion of BGP security. Also refer to 1664 [RFC4272] and [I-D.ietf-karp-routing-tcp-analysis] for analysis of 1665 security issues for BGP. 1667 In the context of the BGP peerings associated with this document, a 1668 BGP Speaker SHOULD NOT accept updates from a Consumer peer. That is, 1669 a participating BGP Speaker, should be aware of the nature of its 1670 relationships for link state relationships and should protect itself 1671 from peers sending updates that either represent erroneous 1672 information feedback loops, or are false input. Such protection can 1673 be achieved by manual configuration of Consumer peers at the BGP 1674 Speaker. 1676 An operator SHOULD employ a mechanism to protect a BGP Speaker 1677 against DDOS attacks from Consumers. The principal attack a consumer 1678 may apply is to attempt to start multiple sessions either 1679 sequentially or simultaneously. Protection can be applied by 1680 imposing rate limits. 1682 Additionally, it may be considered that the export of link state and 1683 TE information as described in this document constitutes a risk to 1684 confidentiality of mission-critical or commercially-sensitive 1685 information about the network. BGP peerings are not automatic and 1686 require configuration, thus it is the responsibility of the network 1687 operator to ensure that only trusted Consumers are configured to 1688 receive such information. 1690 9. Contributors 1692 We would like to thank Robert Varga for the significant contribution 1693 he gave to this document. 1695 10. Acknowledgements 1697 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1698 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1699 Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex 1700 Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, 1701 Vipin Kumar, Naiming Shen, Balaji Rajagopalan and Yakov Rekhter for 1702 their comments. 1704 11. References 1706 11.1. Normative References 1708 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1709 dual environments", RFC 1195, December 1990. 1711 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1712 E. Lear, "Address Allocation for Private Internets", BCP 1713 5, RFC 1918, February 1996. 1715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1716 Requirement Levels", BCP 14, RFC 2119, March 1997. 1718 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1720 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1721 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1722 1999. 1724 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1725 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1726 Tunnels", RFC 3209, December 2001. 1728 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1729 "Internationalizing Domain Names in Applications (IDNA)", 1730 RFC 3490, March 2003. 1732 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1733 Support of Generalized Multi-Protocol Label Switching 1734 (GMPLS)", RFC 4202, October 2005. 1736 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1737 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1739 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 1740 4272, January 2006. 1742 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1743 "Multiprotocol Extensions for BGP-4", RFC 4760, January 1744 2007. 1746 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1747 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1748 4915, June 2007. 1750 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1751 Specification", RFC 5036, October 2007. 1753 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1754 Topology (MT) Routing in Intermediate System to 1755 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1757 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 1758 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1759 February 2008. 1761 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1762 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1763 May 2008. 1765 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1766 Mechanism for IS-IS", RFC 5301, October 2008. 1768 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1769 Engineering", RFC 5305, October 2008. 1771 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1772 of Generalized Multi-Protocol Label Switching (GMPLS)", 1773 RFC 5307, October 2008. 1775 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1776 Engineering in IS-IS", RFC 6119, February 2011. 1778 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1779 Identifier for BGP-4", RFC 6286, June 2011. 1781 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 1782 Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1784 11.2. Informative References 1786 [I-D.ietf-alto-protocol] 1787 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 1788 ietf-alto-protocol-13 (work in progress), September 2012. 1790 [I-D.ietf-karp-routing-tcp-analysis] 1791 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1792 BGP, LDP, PCEP and MSDP Issues According to KARP Design 1793 Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in 1794 progress), April 2013. 1796 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1797 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1799 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1800 Shaffer, "Extensions to OSPF for Advertising Optional 1801 Router Capabilities", RFC 4970, July 2007. 1803 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1804 Extensions for Discovery of Traffic Engineering Node 1805 Capabilities", RFC 5073, December 2007. 1807 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1808 Path Computation Method for Establishing Inter-Domain 1809 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1810 5152, February 2008. 1812 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1813 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1814 Traffic Engineering", RFC 5316, December 2008. 1816 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1817 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1818 Traffic Engineering", RFC 5392, January 2009. 1820 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1821 Optimization (ALTO) Problem Statement", RFC 5693, October 1822 2009. 1824 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1825 Management of New Protocols and Protocol Extensions", RFC 1826 5706, November 2009. 1828 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1829 Instance Extensions", RFC 6549, March 2012. 1831 Authors' Addresses 1832 Hannes Gredler 1833 Juniper Networks, Inc. 1834 1194 N. Mathilda Ave. 1835 Sunnyvale, CA 94089 1836 US 1838 Email: hannes@juniper.net 1840 Jan Medved 1841 Cisco Systems, Inc. 1842 170, West Tasman Drive 1843 San Jose, CA 95134 1844 US 1846 Email: jmedved@cisco.com 1848 Stefano Previdi 1849 Cisco Systems, Inc. 1850 Via Del Serafico, 200 1851 Rome 00142 1852 Italy 1854 Email: sprevidi@cisco.com 1856 Adrian Farrel 1857 Juniper Networks, Inc. 1858 1194 N. Mathilda Ave. 1859 Sunnyvale, CA 94089 1860 US 1862 Email: afarrel@juniper.net 1864 Saikat Ray 1865 Cisco Systems, Inc. 1866 170, West Tasman Drive 1867 San Jose, CA 95134 1868 US 1870 Email: sairay@cisco.com