idnits 2.17.1 draft-ietf-idr-ls-distribution-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 11 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 (May 21, 2014) is 3628 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) == Unused Reference: 'I-D.ietf-alto-protocol' is defined on line 1751, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6822 (Obsoleted by RFC 8202) -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 3 errors (**), 0 flaws (~~), 4 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 20, 2014 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 Cisco Systems, Inc. 11 May 21, 2014 13 North-Bound Distribution of Link-State and TE Information using BGP 14 draft-ietf-idr-ls-distribution-05 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 20, 2014. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 5 76 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . . 5 77 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6 78 3. Carrying Link State Information in BGP . . . . . . . . . . . . 7 79 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8 81 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . . 11 82 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers . . . 11 83 3.2.1.2. Local Node Descriptors . . . . . . . . . . . . . . 12 84 3.2.1.3. Remote Node Descriptors . . . . . . . . . . . . . 12 85 3.2.1.4. Node Descriptor Sub-TLVs . . . . . . . . . . . . . 13 86 3.2.1.5. Multi-Topology ID . . . . . . . . . . . . . . . . 14 87 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . . 15 88 3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . . 16 89 3.2.3.1. OSPF Route Type . . . . . . . . . . . . . . . . . 16 90 3.2.3.2. IP Reachability Information . . . . . . . . . . . 17 91 3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . . 17 92 3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 17 93 3.3.1.1. Node Flag Bits TLV . . . . . . . . . . . . . . . . 18 94 3.3.1.2. IS-IS Area Identifier TLV . . . . . . . . . . . . 18 95 3.3.1.3. Node Name TLV . . . . . . . . . . . . . . . . . . 19 96 3.3.1.4. Local IPv4/IPv6 Router-ID . . . . . . . . . . . . 19 97 3.3.1.5. Opaque Node Attribute TLV . . . . . . . . . . . . 19 98 3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 20 99 3.3.2.1. IPv4/IPv6 Router-ID . . . . . . . . . . . . . . . 21 100 3.3.2.2. MPLS Protocol Mask TLV . . . . . . . . . . . . . . 21 101 3.3.2.3. TE Default Metric TLV . . . . . . . . . . . . . . 22 102 3.3.2.4. IGP Metric TLV . . . . . . . . . . . . . . . . . . 22 103 3.3.2.5. Shared Risk Link Group TLV . . . . . . . . . . . . 22 104 3.3.2.6. Opaque Link Attribute TLV . . . . . . . . . . . . 23 105 3.3.2.7. Link Name TLV . . . . . . . . . . . . . . . . . . 23 106 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 24 107 3.3.3.1. IGP Flags TLV . . . . . . . . . . . . . . . . . . 24 108 3.3.3.2. Route Tag . . . . . . . . . . . . . . . . . . . . 25 109 3.3.3.3. Extended Route Tag . . . . . . . . . . . . . . . . 25 110 3.3.3.4. Prefix Metric TLV . . . . . . . . . . . . . . . . 26 111 3.3.3.5. OSPF Forwarding Address TLV . . . . . . . . . . . 26 112 3.3.3.6. Opaque Prefix Attribute TLV . . . . . . . . . . . 26 113 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . . 27 114 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . . 27 115 3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 27 116 3.7. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . . 28 117 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . . 28 118 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . . 29 119 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . . 29 120 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . . 29 121 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 122 6. Manageability Considerations . . . . . . . . . . . . . . . . . 30 123 6.1. Operational Considerations . . . . . . . . . . . . . . . . 30 124 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . . 30 125 6.1.2. Installation and Initial Setup . . . . . . . . . . . . 30 126 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . . 31 127 6.1.4. Requirements on Other Protocols and Functional Component 31 128 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 31 129 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 31 130 6.2. Management Considerations . . . . . . . . . . . . . . . . 31 131 6.2.1. Management Information . . . . . . . . . . . . . . . . 31 132 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . . 31 133 6.2.3. Configuration Management . . . . . . . . . . . . . . . 31 134 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 32 135 6.2.5. Performance Management . . . . . . . . . . . . . . . . 32 136 6.2.6. Security Management . . . . . . . . . . . . . . . . . 32 137 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 32 138 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 139 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 140 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 141 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 142 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 143 11.2. Informative References . . . . . . . . . . . . . . . . . 36 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 146 1. Introduction 148 The contents of a Link State Database (LSDB) or a Traffic Engineering 149 Database (TED) has the scope of an IGP area. Some applications, such 150 as end-to-end Traffic Engineering (TE), would benefit from visibility 151 outside one area or Autonomous System (AS) in order to make better 152 decisions. 154 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 155 a mechanism for achieving the computation of end-to-end TE paths that 156 cross the visibility of more than one TED or which require CPU- 157 intensive or coordinated computations. The IETF has also defined the 158 ALTO Server [RFC5693] as an entity that generates an abstracted 159 network topology and provides it to network-aware applications. 161 Both a PCE and an ALTO Server need to gather information about the 162 topologies and capabilities of the network in order to be able to 163 fulfill their function. 165 This document describes a mechanism by which Link State and TE 166 information can be collected from networks and shared with external 167 components using the BGP routing protocol [RFC4271]. This is 168 achieved using a new BGP Network Layer Reachability Information 169 (NLRI) encoding format. The mechanism is applicable to physical and 170 virtual links. The mechanism described is subject to policy control. 172 A router maintains one or more databases for storing link-state 173 information about nodes and links in any given area. Link attributes 174 stored in these databases include: local/remote IP addresses, local/ 175 remote interface identifiers, link metric and TE metric, link 176 bandwidth, reservable bandwidth, per CoS class reservation state, 177 preemption and Shared Risk Link Groups (SRLG). The router's BGP 178 process can retrieve topology from these LSDBs and distribute it to a 179 consumer, either directly or via a peer BGP Speaker (typically a 180 dedicated Route Reflector), using the encoding specified in this 181 document. 183 The collection of Link State and TE link state information and its 184 distribution to consumers is shown in the following figure. 186 +-----------+ 187 | Consumer | 188 +-----------+ 189 ^ 190 | 191 +-----------+ 192 | BGP | +-----------+ 193 | Speaker | | Consumer | 194 +-----------+ +-----------+ 195 ^ ^ ^ ^ 196 | | | | 197 +---------------+ | +-------------------+ | 198 | | | | 199 +-----------+ +-----------+ +-----------+ 200 | BGP | | BGP | | BGP | 201 | Speaker | | Speaker | . . . | Speaker | 202 +-----------+ +-----------+ +-----------+ 203 ^ ^ ^ 204 | | | 205 IGP IGP IGP 207 A BGP Speaker may apply configurable policy to the information that 208 it distributes. Thus, it may distribute the real physical topology 209 from the LSDB or the TED. Alternatively, it may create an abstracted 210 topology, where virtual, aggregated nodes are connected by virtual 211 paths. Aggregated nodes can be created, for example, out of multiple 212 routers in a POP. Abstracted topology can also be a mix of physical 213 and virtual nodes and physical and virtual links. Furthermore, the 214 BGP Speaker can apply policy to determine when information is updated 215 to the consumer so that there is reduction of information flow form 216 the network to the consumers. Mechanisms through which topologies 217 can be aggregated or virtualized are outside the scope of this 218 document 220 2. Motivation and Applicability 222 This section describes use cases from which the requirements can be 223 derived. 225 2.1. MPLS-TE with PCE 227 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 228 within a "domain" (such as an IGP area) or across multiple domains 229 (such as a multi-area AS, or multiple ASes). 231 o Within a single area, the PCE offers enhanced computational power 232 that may not be available on individual routers, sophisticated 233 policy control and algorithms, and coordination of computation 234 across the whole area. 236 o If a router wants to compute a MPLS-TE path across IGP areas its 237 own TED lacks visibility of the complete topology. That means 238 that the router cannot determine the end-to-end path, and cannot 239 even select the right exit router (Area Border Router - ABR) for 240 an optimal path. This is an issue for large-scale networks that 241 need to segment their core networks into distinct areas, but which 242 still want to take advantage of MPLS-TE. 244 Previous solutions used per-domain path computation [RFC5152]. The 245 source router could only compute the path for the first area because 246 the router only has full topological visibility for the first area 247 along the path, but not for subsequent areas. Per-domain path 248 computation uses a technique called "loose-hop-expansion" [RFC3209], 249 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 250 using the IGP computed shortest path topology for the remainder of 251 the path. This may lead to sub-optimal paths, makes alternate/back- 252 up path computation hard, and might result in no TE path being found 253 when one really does exist. 255 The PCE presents a computation server that may have visibility into 256 more than one IGP area or AS, or may cooperate with other PCEs to 257 perform distributed path computation. The PCE obviously needs access 258 to the TED for the area(s) it serves, but [RFC4655] does not describe 259 how this is achieved. Many implementations make the PCE a passive 260 participant in the IGP so that it can learn the latest state of the 261 network, but this may be sub-optimal when the network is subject to a 262 high degree of churn, or when the PCE is responsible for multiple 263 areas. 265 The following figure shows how a PCE can get its TED information 266 using the mechanism described in this document. 268 +----------+ +---------+ 269 | ----- | | BGP | 270 | | TED |<-+-------------------------->| Speaker | 271 | ----- | TED synchronization | | 272 | | | mechanism: +---------+ 273 | | | BGP with Link-State NLRI 274 | v | 275 | ----- | 276 | | PCE | | 277 | ----- | 278 +----------+ 279 ^ 280 | Request/ 281 | Response 282 v 283 Service +----------+ Signaling +----------+ 284 Request | Head-End | Protocol | Adjacent | 285 -------->| Node |<------------>| Node | 286 +----------+ +----------+ 288 The mechanism in this document allows the necessary TED information 289 to be collected from the IGP within the network, filtered according 290 to configurable policy, and distributed to the PCE as necessary. 292 2.2. ALTO Server Network API 294 An ALTO Server [RFC5693] is an entity that generates an abstracted 295 network topology and provides it to network-aware applications over a 296 web service based API. Example applications are p2p clients or 297 trackers, or CDNs. The abstracted network topology comes in the form 298 of two maps: a Network Map that specifies allocation of prefixes to 299 Partition Identifiers (PIDs), and a Cost Map that specifies the cost 300 between PIDs listed in the Network Map. For more details, see [I-D 301 .ietf-alto-protocol]. 303 ALTO abstract network topologies can be auto-generated from the 304 physical topology of the underlying network. The generation would 305 typically be based on policies and rules set by the operator. Both 306 prefix and TE data are required: prefix data is required to generate 307 ALTO Network Maps, TE (topology) data is required to generate ALTO 308 Cost Maps. Prefix data is carried and originated in BGP, TE data is 309 originated and carried in an IGP. The mechanism defined in this 310 document provides a single interface through which an ALTO Server can 311 retrieve all the necessary prefix and network topology data from the 312 underlying network. Note an ALTO Server can use other mechanisms to 313 get network data, for example, peering with multiple IGP and BGP 314 Speakers. 316 The following figure shows how an ALTO Server can get network 317 topology information from the underlying network using the mechanism 318 described in this document. 320 +--------+ 321 | Client |<--+ 322 +--------+ | 323 | ALTO +--------+ BGP with +---------+ 324 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 325 | Client |<--+------------| Server |<----------------| Speaker | 326 +--------+ | | | | | 327 | +--------+ +---------+ 328 +--------+ | 329 | Client |<--+ 330 +--------+ 332 3. Carrying Link State Information in BGP 334 This specification contains two parts: definition of a new BGP NLRI 335 that describes links, nodes and prefixes comprising IGP link state 336 information, and definition of a new BGP path attribute (BGP-LS 337 attribute) that carries link, node and prefix properties and 338 attributes, such as the link and prefix metric or auxiliary Router- 339 IDs of nodes, etc. 341 3.1. TLV Format 343 Information in the new Link-State NLRIs and attributes is encoded in 344 Type/Length/Value triplets. The TLV format is shown in Figure 4. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 // Value (variable) // 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 The Length field defines the length of the value portion in octets 355 (thus a TLV with no value portion would have a length of zero). The 356 TLV is not padded to four-octet alignment. Unrecognized types are 357 preserved and propagated. In order to compare NLRIs with unknown 358 TLVs all TLVs MUST be ordered in ascending order. If there are more 359 TLVs of the same type, then the TLVs MUST be ordered in ascending 360 order of the TLV value within the set of TLVs with the same type. 361 All TLVs that are not specified as mandatory are considered optional. 363 3.2. The Link-State NLRI 365 The MP_REACH and MP_UNREACH attributes are BGP's containers for 366 carrying opaque information. Each Link-State NLRI describes either a 367 node, a link or a prefix. 369 All non-VPN link, node and prefix information SHALL be encoded using 370 AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be 371 encoded using AFI 16388 / SAFI 128. 373 In order for two BGP speakers to exchange Link-State NLRI, they MUST 374 use BGP Capabilities Advertisement to ensure that they both are 375 capable of properly processing such NLRI. This is done as specified 376 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 377 an AFI 16388 / SAFI 71 and AFI 16388 / SAFI 128 for the VPN flavor. 379 The format of the Link-State NLRI is shown in the following figure. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | NLRI Type | Total NLRI Length | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 // Link-State NLRI (variable) // 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | NLRI Type | Total NLRI Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 + Route Distinguisher + 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 // Link-State NLRI (variable) // 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 The 'Total NLRI Length' field contains the cumulative length, in 405 octets, of rest of the NLRI not including the NLRI Type field or 406 itself. For VPN applications it also includes the length of the 407 Route Distinguisher. 409 The 'NLRI Type' field can contain one of the following values: 411 Type = 1: Node NLRI 413 Type = 2: Link NLRI 415 Type = 3: IPv4 Topology Prefix NLRI 417 Type = 4: IPv6 Topology Prefix NLRI 419 The Node NLRI (NLRI Type = 1) is shown in the following figure. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+ 424 | Protocol-ID | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Identifier | 427 | (64 bits) | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 // Local Node Descriptors (variable) // 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 The Link NLRI (NLRI Type = 2) is shown in the following figure. 434 0 1 2 3 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 436 +-+-+-+-+-+-+-+-+ 437 | Protocol-ID | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Identifier | 440 | (64 bits) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 // Local Node Descriptors (variable) // 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 // Remote Node Descriptors (variable) // 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 // Link Descriptors (variable) // 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 450 same format as shown in the following figure. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+ 455 | Protocol-ID | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Identifier | 458 | (64 bits) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 // Local Node Descriptor (variable) // 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 // Prefix Descriptors (variable) // 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 The 'Protocol-ID' field can contain one of the following values: 467 Protocol-ID = 0: Unknown, The source of NLRI information could not 468 be determined 470 Protocol-ID = 1: IS-IS Level 1, The NLRI information has been 471 sourced by IS-IS Level 1 473 Protocol-ID = 2: IS-IS Level 2, The NLRI information has been 474 sourced by IS-IS Level 2 476 Protocol-ID = 3: OSPF, The NLRI information has been sourced by 477 OSPF 479 Protocol-ID = 4: Direct, The NLRI information has been sourced 480 from local interface state 482 Protocol-ID = 5: Static, The NLRI information has been sourced by 483 static configuration 485 Both OSPF and IS-IS may run multiple routing protocol instances over 486 the same link. See [RFC6822] and [RFC6549]. These instances define 487 independent "routing universes". The 64-Bit 'Identifier' field is 488 used to identify the "routing universe" where the NLRI belongs. The 489 NLRIs representing IGP objects (nodes, links or prefixes) from the 490 same routing universe MUST have the same 'Identifier' value; NLRIs 491 with different 'Identifier' values MUST be considered to be from 492 different routing universes. Table Table 1 lists the 'Identifier' 493 values that are defined as well-known in this draft. 495 +------------+---------------------+ 496 | Identifier | Routing Universe | 497 +------------+---------------------+ 498 | 0 | L3 packet topology | 499 | 1 | L1 optical topology | 500 +------------+---------------------+ 502 Each Node Descriptor and Link Descriptor consists of one or more TLVs 503 described in the following sections. 505 3.2.1. Node Descriptors 507 Each link is anchored by a pair of Router-IDs that are used by the 508 underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit 509 Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more 510 additional auxiliary Router-IDs, mainly for traffic engineering 511 purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE 512 Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be 513 included in the link attribute described in Section Section 3.3.2. 515 It is desirable that the Router-ID assignments inside the Node 516 Descriptor are globally unique. However there may be Router-ID 517 spaces (e.g. ISO) where no global registry exists, or worse, Router- 518 IDs have been allocated following private-IP RFC 1918 [RFC1918] 519 allocation. We use Autonomous System (AS) Number and BGP-LS 520 Identifier in order to disambiguate the Router-IDs, as described in 521 Section 3.2.1.1. 523 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 525 One problem that needs to be addressed is the ability to identify an 526 IGP node globally (by "global", we mean within the BGP-LS database 527 collected by all BGP-LS speakers that talk to each other). This can 528 be expressed through the following two requirements: 530 (A) The same node must not be represented by two keys (otherwise one 531 node will look like two nodes). 533 (B) Two different nodes must not be represented by the same key 534 (otherwise, two nodes will look like one node). 536 We define an "IGP domain" to be the set of nodes (hence, by extension 537 links and prefixes), within which, each node has a unique IGP 538 representation by using the combination of Area-ID, Router-ID, 539 Protocol, Topology-ID, and Instance ID. The problem is that BGP may 540 receive node/link/prefix information from multiple independent "IGP 541 domains" and we need to distinguish between them. Moreover, we can't 542 assume there is always one and only one IGP domain per AS. During IGP 543 transitions it may happen that two redundant IGPs are in place. 545 In section Section 3.2.1.4 a set of sub-TLVs is described, which 546 allows to specify a flexible key for any given Node/Link information 547 such that global uniqueness of the NLRI is ensured. 549 3.2.1.2. Local Node Descriptors 551 The Local Node Descriptors TLV contains Node Descriptors for the node 552 anchoring the local end of the link. This is a mandatory TLV in all 553 three types of NLRIs. The length of this TLV is variable. The value 554 contains one or more Node Descriptor Sub-TLVs defined in Section 555 3.2.1.4. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type | Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 // Node Descriptor Sub-TLVs (variable) // 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 The sub-TLV values in Node Descriptor TLVs are defined as follows: 600 Autonomous System: opaque value (32 Bit AS Number) 602 BGP-LS Identifier: opaque value (32 Bit ID). In conjunction with ASN, 603 uniquely identifies the BGP-LS domain. The combination of ASN and 604 BGP-LS ID MUST be globally unique. All BGP-LS speakers within an 605 IGP flooding-set (set of IGP nodes within which an LSP/LSA is 606 flooded) MUST use the same ASN, BGP-LS ID tuple. If an IGP domain 607 consists of multiple flooding-sets, then all BGP-LS speakers 608 within the IGP domain SHOULD use the same ASN, BGP-LS ID tuple. 609 The ASN, BGP Router-ID tuple (which is globally unique [RFC6286] ) 610 of one of the BGP-LS speakers within the flooding-set (or IGP 611 domain) may be used for all BGP-LS speakers in that flooding-set 612 (or IGP domain). 614 Area ID: It is used to identify the 32 Bit area to which the NLRI 615 belongs. Area Identifier allows the different NLRIs of the same 616 router to be discriminated. 618 IGP Router ID: opaque value. This is a mandatory TLV. For an IS-IS 619 non-Pseudonode, this contains 6 octet ISO node-ID (ISO system-ID). 620 For an IS-IS Pseudonode corresponding to a LAN, this contains 6 621 octet ISO node-ID of the "Designated Intermediate System" (DIS) 622 followed by one octet nonzero PSN identifier (7 octet in total). 623 For an OSPFv2 or OSPFv3 non-"Pseudonode", this contains 4 octet 624 Router-ID. For an OSPFv2 "Pseudonode" representing a LAN, this 625 contains 4 octet Router-ID of the designated router (DR) followed 626 by 4 octet IPv4 address of the DR's interface to the LAN (8 octet 627 in total). Similarly, for an OSPFv3 "Pseudonode", this contains 4 628 octet Router-ID of the DR followed by 4 octet interface identifier 629 of the DR's interface to the LAN (8 octet in total). The TLV size 630 in combination with protocol identifier enables the decoder to 631 determine the type of the node. 633 There can be at most one instance of each sub-TLV type present in 634 any Node Descriptor. The TLV ordering within a Node descriptor 635 MUST be kept in order of increasing numeric value of type. This 636 needs to be done in order to compare NLRIs, even when an 637 implementation encounters an unknown sub-TLV. Using stable sorting 638 an implementation can do binary comparison of NLRIs and hence 639 allow incremental deployment of new key sub-TLVs. 641 3.2.1.5. Multi-Topology ID 643 The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF 644 Multi-Topology IDs for a link, node or prefix. 646 Semantics of the IS-IS MT-ID are defined in RFC5120, Section 7.2 647 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC4915, 648 Section 3.7 [RFC4915]. If the value in the MT-ID TLV is derived from 649 OSPF, then the upper 9 bits MUST be set to 0. Bits R are reserved, 650 SHOULD be set to 0 when originated and ignored on receipt. 652 The format of the MT-ID TLV is shown in the following figure. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length=2*n | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |R R R R| Multi-Topology ID 1 | .... // 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 // .... |R R R R| Multi-Topology ID n | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 where Type is 263, Length is 2*n and n is the number of MT-IDs 665 carried in the TLV. 667 The MT-ID TLV MAY be present in a Link Descriptor, a Prefix 668 Descriptor, or in the BGP-LS attribute of a node NLRI. In Link or 669 Prefix Descriptor, only one MT-ID TLV containing only the MT-ID of 670 the topology where the link or the prefix belongs is allowed. In the 671 BGP-LS attribute of a node NLRI, one MT-ID TLV containing the array 672 of MT-IDs of all topologies where the node belongs can be present. 674 3.2.2. Link Descriptors 676 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 677 triplets. The format of each TLV is shown in Section 3.1. The 'Link 678 descriptor' TLVs uniquely identify a link among multiple parallel 679 links between a pair of anchor routers. A link described by the Link 680 descriptor TLVs actually is a "half-link", a unidirectional 681 representation of a logical link. In order to fully describe a 682 single logical link two originating routers advertise a half-link 683 each, i.e. two link NLRIs are advertised for a given point-to-point 684 link. 686 The format and semantics of the 'value' fields in most 'Link 687 Descriptor' TLVs correspond to the format and semantics of value 688 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 689 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 690 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 691 carry data sourced either by IS-IS or OSPF. 693 The following TLVs are valid as Link Descriptors in the Link NLRI: 695 +------------+--------------------+---------------+-----------------+ 696 | TLV Code | Description | IS-IS TLV | Value defined | 697 | Point | | /Sub-TLV | in: | 698 +------------+--------------------+---------------+-----------------+ 699 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 700 | | Identifiers | | | 701 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 702 | | address | | | 703 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 704 | | address | | | 705 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 706 | | address | | | 707 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 708 | | address | | | 709 | 263 | Multi-Topology | --- | Section 3.2.1.5 | 710 | | Identifier | | | 711 +------------+--------------------+---------------+-----------------+ 713 The information about a link present in the LSA/LSP originated by the 714 local node of the link determines the set of TLVs in the Link 715 Descriptor of the link. 717 If interface and neighbor addresses, either IPv4 or IPv6, are 718 present, then the IP address TLVs are included in the link 719 descriptor, but not the link local/remote Identifier TLV. The link 720 local/remote identifiers MAY be included in the link attribute. 722 If interface and neighbor addresses are not present and the link 723 local/remote identifiers are present, then the link local/remote 724 Identifier TLV is included in link descriptor. 726 The Multi-Topology Identifier TLV is included in link descriptor 727 if that information is present. 729 3.2.3. Prefix Descriptors 731 The 'Prefix Descriptor' field is a set of Type/Length/Value (TLV) 732 triplets. 'Prefix Descriptor' TLVs uniquely identify an IPv4 or IPv6 733 Prefix originated by a Node. The following TLVs are valid as Prefix 734 Descriptors in the IPv4/IPv6 Prefix NLRI: 736 +-----------+--------------------------+------------+---------------+ 737 | TLV Code | Description | Length | Value defined | 738 | Point | | | in: | 739 +-----------+--------------------------+------------+---------------+ 740 | 263 | Multi-Topology | variable | Section | 741 | | Identifier | | 3.2.1.5 | 742 | 264 | OSPF Route Type | 1 | Section | 743 | | | | 3.2.3.1 | 744 | 265 | IP Reachability | variable | Section | 745 | | Information | | 3.2.3.2 | 746 +-----------+--------------------------+------------+---------------+ 748 3.2.3.1. OSPF Route Type 750 OSPF Route Type is an optional TLV that MAY be present in Prefix 751 NLRIs. It is used to identify the OSPF route-type of the prefix. It 752 is used when an OSPF prefix is advertised in the OSPF domain with 753 multiple different route-types. The Route Type TLV allows to 754 discriminate these advertisements. The format of the OSPF Route Type 755 TLV is shown in the following figure. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Route Type | 763 +-+-+-+-+-+-+-+-+ 765 where the Type and Length fields of the TLV are defined in Table 4. 766 The OSPF Route Type field values are defined in the OSPF protocol, 767 and can be one of the following: 769 Intra-Area (0x1) 771 Inter-Area (0x2) 772 External 1 (0x3) 774 External 2 (0x4) 776 NSSA 1 (0x5) 778 NSSA 2 (0x6) 780 3.2.3.2. IP Reachability Information 782 The IP Reachability Information is a mandatory TLV that contains one 783 IP address prefix (IPv4 or IPv6) originally advertised in the IGP 784 topology. Its purpose is to glue a particular BGP service NLRI vi 785 virtue of its BGP next-hop to a given Node in the LSDB. A router 786 SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. 787 The format of the IP Reachability Information TLV is shown in the 788 following figure: 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Type | Length | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Prefix Length | IP Prefix (variable) // 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 The Type and Length fields of the TLV are defined in Table 4. The 799 following two fields determine the address-family reachability 800 information. The 'Prefix Length' field contains the length of the 801 prefix in bits. The 'IP Prefix' field contains the most significant 802 octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 803 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 804 24 and 4 octets for prefix length 25 up to 32, etc. 806 3.3. The BGP-LS Attribute 808 This is an optional, non-transitive BGP attribute that is used to 809 carry link, node and prefix parameters and attributes. It is defined 810 as a set of Type/Length/Value (TLV) triplets, described in the 811 following section. This attribute SHOULD only be included with Link- 812 State NLRIs. This attribute MUST be ignored for all other address- 813 families. 815 3.3.1. Node Attribute TLVs 817 Node attribute TLVs are the TLVs that may be encoded in the BGP-LS 818 attribute with a node NLRI. The following node attribute TLVs are 819 defined: 821 +-----------+----------------------+------------+-------------------+ 822 | TLV Code | Description | Length | Value defined in: | 823 | Point | | | | 824 +-----------+----------------------+------------+-------------------+ 825 | 263 | Multi-Topology | variable | Section 3.2.1.5 | 826 | | Identifier | | | 827 | 1024 | Node Flag Bits | 1 | Section 3.3.1.1 | 828 | 1025 | Opaque Node | variable | Section 3.3.1.5 | 829 | | Properties | | | 830 | 1026 | Node Name | variable | Section 3.3.1.3 | 831 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 832 | | Identifier | | | 833 | 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | 834 | | Local Node | | | 835 | 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | 836 | | Local Node | | | 837 +-----------+----------------------+------------+-------------------+ 839 3.3.1.1. Node Flag Bits TLV 841 The Node Flag Bits TLV carries a bit mask describing node attributes. 842 The value is a variable length bit array of flags, where each bit 843 represents a node capability. 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Type | Length | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 |O|T|E|A| Reserved| 851 +-+-+-+-+-+-+-+-+-+ 853 The bits are defined as follows: 855 +----------+-------------------------+-----------+ 856 | Bit | Description | Reference | 857 +----------+-------------------------+-----------+ 858 | 'O' | Overload Bit | [RFC1195] | 859 | 'T' | Attached Bit | [RFC1195] | 860 | 'E' | External Bit | [RFC2328] | 861 | 'A' | ABR Bit | [RFC2328] | 862 | Reserved | Reserved for future use | | 863 +----------+-------------------------+-----------+ 865 3.3.1.2. IS-IS Area Identifier TLV 867 An IS-IS node can be part of one or more IS-IS areas. Each of these 868 area addresses is carried in the IS-IS Area Identifier TLV. If more 869 than one Area Addresses are present, multiple TLVs are used to encode 870 them. The IS-IS Area Identifier TLV may be present in the BGP-LS 871 attribute only with the Link-State Node NLRI. 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Type | Length | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 // Area Identifier (variable) // 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 3.3.1.3. Node Name TLV 883 The Node Name TLV is optional. Its structure and encoding has been 884 borrowed from [RFC5301]. The value field identifies the symbolic 885 name of the router node. This symbolic name can be the FQDN for the 886 router, it can be a subset of the FQDN, or it can be any string 887 operators want to use for the router. The use of FQDN or a subset of 888 it is strongly recommended. 890 The Value field is encoded in 7-bit ASCII. If a user-interface for 891 configuring or displaying this field permits Unicode characters, that 892 user-interface is responsible for applying the ToASCII and/or 893 ToUnicode algorithm as described in [RFC5890] to achieve the correct 894 format for transmission or display. 896 Altough [RFC5301] is a IS-IS specific extension, usage of the Node 897 Name TLV is possible for all protocols. How a router derives and 898 injects node names for e.g. OSPF nodes, is outside of the scope of 899 this document. 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Type | Length | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 // Node Name (variable) // 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 3.3.1.4. Local IPv4/IPv6 Router-ID 911 The local IPv4/IPv6 Router-ID TLVs are used to describe auxiliary 912 Router-IDs that the IGP might be using, e.g., for TE and migration 913 purposes like correlating a Node-ID between different protocols. If 914 there is more than one auxiliary Router-ID of a given type, then each 915 one is encoded in its own TLV. 917 3.3.1.5. Opaque Node Attribute TLV 918 The Opaque Node attribute TLV is an envelope that transparently 919 carries optional node attribute TLVs advertised by a router. An 920 originating router shall use this TLV for encoding information 921 specific to the protocol advertised in the NLRI header Protocol-ID 922 field or new protocol extensions to the protocol as advertised in the 923 NLRI header Protocol-ID field for which there is no protocol neutral 924 representation in the BGP link-state NLRI. A router for example 925 could use this extension in order to advertise the native protocols 926 node attribute TLVs, such as the OSPF Router Informational 927 Capabilities TLV defined in [RFC4970], or the IGP TE Node Capability 928 Descriptor TLV described in [RFC5073]. 930 0 1 2 3 931 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Type | Length | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 // Opaque node attributes (variable) // 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 3.3.2. Link Attribute TLVs 940 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 941 attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ 942 Value (TLV) triplet formatted as defined in Section 3.1. The format 943 and semantics of the 'value' fields in some 'Link Attribute' TLVs 944 correspond to the format and semantics of value fields in IS-IS 945 Extended IS Reachability sub-TLVs, defined in [RFC5305] and 946 [RFC5307]. Other 'Link Attribute' TLVs are defined in this document. 947 Although the encodings for 'Link Attribute' TLVs were originally 948 defined for IS-IS, the TLVs can carry data sourced either by IS-IS or 949 OSPF. 951 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 952 attribute: 954 +----------+----------------------+---------------+-----------------+ 955 | TLV Code | Description | IS-IS TLV | Defined in: | 956 | Point | | /Sub-TLV | | 957 +----------+----------------------+---------------+-----------------+ 958 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 959 | | Local Node | | | 960 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 961 | | Local Node | | | 962 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 963 | | Remote Node | | | 964 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 965 | | Remote Node | | | 966 | 1032 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 967 | | Identifiers | | | 968 | 1088 | Administrative group | 22/3 | [RFC5305]/3.1 | 969 | | (color) | | | 970 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 971 | | bandwidth | | | 972 | 1090 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 973 | | bandwidth | | | 974 | 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 975 | 1092 | TE Default Metric | 22/18 | Section | 976 | | | | 3.3.2.3/ | 977 | 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 978 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 979 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 980 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 981 | | Group | | | 982 | 1097 | Opaque link | --- | Section 3.3.2.6 | 983 | | attribute | | | 984 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 985 +----------+----------------------+---------------+-----------------+ 987 3.3.2.1. IPv4/IPv6 Router-ID 989 The local/remote IPv4/IPv6 Router-ID TLVs are used to describe 990 auxiliary Router-IDs that the IGP might be using, e.g., for TE 991 purposes. All auxiliary Router-IDs of both the local and the remote 992 node MUST be included in the link attribute of each link NLRI. If 993 there are more than one auxiliary Router-ID of a given type, then 994 multiple TLVs are used to encode them. 996 3.3.2.2. MPLS Protocol Mask TLV 998 The MPLS Protocol TLV carries a bit mask describing which MPLS 999 signaling protocols are enabled. The length of this TLV is 1. The 1000 value is a bit array of 8 flags, where each bit represents an MPLS 1001 Protocol capability. 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Type | Length | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |L|R| Reserved | 1009 +-+-+-+-+-+-+-+-+ 1011 The following bits are defined: 1013 +----------------+----------------------------------+---------------+ 1014 | Bit | Description | Reference | 1015 +----------------+----------------------------------+---------------+ 1016 | 'L' | Label Distribution Protocol | [RFC5036] | 1017 | | (LDP) | | 1018 | 'R' | Extension to RSVP for LSP | [RFC3209] | 1019 | | Tunnels (RSVP-TE) | | 1020 | 'Reserved' | Reserved for future use | | 1021 +----------------+----------------------------------+---------------+ 1023 3.3.2.3. TE Default Metric TLV 1025 The TE Default Metric TLV carries the TE-metric for this link. The 1026 length of this TLV is fixed at 4 octets. If a source protocol (e.g. 1027 IS-IS) does not support a Metric width of 32 bits then the high order 1028 octet MUST be set to zero. 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Type | Length | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | TE Default Link Metric | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 3.3.2.4. IGP Metric TLV 1040 The IGP Metric TLV carries the metric for this link. The length of 1041 this TLV is variable, depending on the metric width of the underlying 1042 protocol. IS-IS small metrics have a length of 1 octet (the two most 1043 significant bits are ignored). OSPF metrics have a length of two 1044 octects. IS-IS wide-metrics have a length of three octets. 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Type | Length | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 // IGP Link Metric (variable length) // 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 3.3.2.5. Shared Risk Link Group TLV 1055 The Shared Risk Link Group (SRLG) TLV carries the Shared Risk Link 1056 Group information (see Section 2.3, "Shared Risk Link Group 1057 Information", of [RFC4202]). It contains a data structure consisting 1058 of a (variable) list of SRLG values, where each element in the list 1059 has 4 octets, as shown in Figure 22. The length of this TLV is 4 * 1060 (number of SRLG values). 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type | Length | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Shared Risk Link Group Value | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 // ............ // 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Shared Risk Link Group Value | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 1075 information is carried in two different TLVs: the IPv4 (SRLG) TLV 1076 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 1077 defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG 1078 information are carried in a single TLV. 1080 3.3.2.6. Opaque Link Attribute TLV 1082 The Opaque link attribute TLV is an envelope that transparently 1083 carries optional link atrribute TLVs advertised by a router. An 1084 originating router shall use this TLV for encoding information 1085 specific to the protocol advertised in the NLRI header Protocol-ID 1086 field or new protocol extensions to the protocol as advertised in the 1087 NLRI header Protocol-ID field for which there is no protocol neutral 1088 representation in the BGP link-state NLRI. 1090 0 1 2 3 1091 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Type | Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 // Opaque link attributes (variable) // 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 3.3.2.7. Link Name TLV 1100 The Link Name TLV is optional. The value field identifies the 1101 symbolic name of the router link. This symbolic name can be the FQDN 1102 for the link, it can be a subset of the FQDN, or it can be any string 1103 operators want to use for the link. The use of FQDN or a subset of 1104 it is strongly recommended. 1106 The Value field is encoded in 7-bit ASCII. If a user-interface for 1107 configuring or displaying this field permits Unicode characters, that 1108 user-interface is responsible for applying the ToASCII and/or 1109 ToUnicode algorithm as described in [RFC5890] to achieve the correct 1110 format for transmission or display. 1112 How a router derives and injects link names is outside of the scope 1113 of this document. 1115 0 1 2 3 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Type | Length | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 // Link Name (variable) // 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 3.3.3. Prefix Attribute TLVs 1125 Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set 1126 of IGP attributes (such as metric, route tags, etc.) that MUST be 1127 reflected into the LINK_STATE attribute. This section describes the 1128 different attributes related to the IPv4/IPv6 prefixes. Prefix 1129 Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 1130 only. The following attributes TLVs are defined: 1132 +-------------+---------------------+--------------+----------------+ 1133 | TLV Code | Description | Length | Reference | 1134 | Point | | | | 1135 +-------------+---------------------+--------------+----------------+ 1136 | 1152 | IGP Flags | 1 | Section | 1137 | | | | 3.3.3.1 | 1138 | 1153 | Route Tag | 4*n | Section | 1139 | | | | 3.3.3.2 | 1140 | 1154 | Extended Tag | 8*n | Section | 1141 | | | | 3.3.3.3 | 1142 | 1155 | Prefix Metric | 4 | Section | 1143 | | | | 3.3.3.4 | 1144 | 1156 | OSPF Forwarding | 4 | Section | 1145 | | Address | | 3.3.3.5 | 1146 | 1157 | Opaque Prefix | variable | Section | 1147 | | Attribute | | 3.3.3.6 | 1148 +-------------+---------------------+--------------+----------------+ 1150 3.3.3.1. IGP Flags TLV 1152 IGP Flags TLV contains IS-IS and OSPF flags and bits originally 1153 assigned tothe prefix. The IGP Flags TLV is encoded as follows: 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Type | Length | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 |D| Reserved | 1161 +-+-+-+-+-+-+-+-+ 1163 The value field contains bits defined according to the table below: 1165 +----------+--------------------------+-----------+ 1166 | Bit | Description | Reference | 1167 +----------+--------------------------+-----------+ 1168 | 'D' | IS-IS Up/Down Bit | [RFC5305] | 1169 | Reserved | Reserved for future use. | | 1170 +----------+--------------------------+-----------+ 1172 3.3.3.2. Route Tag 1174 Route Tag TLV carries original IGP TAGs (IS-IS [RFC5130] or OSPF) of 1175 the prefix and is encoded as follows: 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Type | Length | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 // Route Tags (one or more) // 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 Length is a multiple of 4. 1187 The value field contains one or more Route Tags as learned in the IGP 1188 topology. 1190 3.3.3.3. Extended Route Tag 1192 Extended Route Tag TLV carries IS-IS Extended Route TAGs of the 1193 prefix [RFC5130] and is encoded as follows: 1195 0 1 2 3 1196 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 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Type | Length | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 // Extended Route Tag (one or more) // 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 Length is a multiple of 8. 1205 The 'Extended Route Tag' field contains one or more Extended Route 1206 Tags as learned in the IGP topology. 1208 3.3.3.4. Prefix Metric TLV 1210 Prefix Metric TLV carries the metric of the prefix as known in the 1211 IGP topology [RFC5305]. The attribute is mandatory and can only 1212 appear once. 1214 0 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Type | Length | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Metric | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 Length is 4. 1224 3.3.3.5. OSPF Forwarding Address TLV 1226 OSPF Forwarding Address TLV [RFC2328] carries the OSPF forwarding 1227 address as known in the original OSPF advertisement. Forwarding 1228 address can be either IPv4 or IPv6. 1230 0 1 2 3 1231 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 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Type | Length | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 // Forwarding Address (variable) // 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1239 forwarding address. 1241 3.3.3.6. Opaque Prefix Attribute TLV 1243 The Opaque Prefix attribute TLV is an envelope that transparently 1244 carries optional prefix attribute TLVs advertised by a router. An 1245 originating router shall use this TLV for encoding information 1246 specific to the protocol advertised in the NLRI header Protocol-ID 1247 field or new protocol extensions to the protocol as advertised in the 1248 NLRI header Protocol-ID field for which there is no protocol neutral 1249 representation in the BGP link-state NLRI. 1251 The format of the TLV is as follows: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Type | Length | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 // Opaque Prefix Attributes (variable) // 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Type is as specified in Table 9 and Length is variable. 1262 3.4. BGP Next Hop Information 1264 BGP link-state information for both IPv4 and IPv6 networks can be 1265 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1266 IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1267 SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, 1268 then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. 1269 Usually the next hop will be set to the local end-point address of 1270 the BGP session. The next hop address MUST be encoded as described 1271 in [RFC4760]. The length field of the next hop address will specify 1272 the next hop address-family. If the next hop length is 4, then the 1273 next hop is an IPv4 address; if the next hop length is 16, then it is 1274 a global IPv6 address and if the next hop length is 32, then there is 1275 one global IPv6 address followed by a link-local IPv6 address. The 1276 link-local IPv6 address should be used as described in [RFC2545]. 1277 For VPN SAFI, as per custom, an 8 byte route-distinguisher set to all 1278 zero is prepended to the next hop. 1280 The BGP Next Hop attribute is used by each BGP-LS speaker to validate 1281 the NLRI it receives. However, this specification doesn't mandate 1282 any rule regarding the re-write of the BGP Next Hop attribute. 1284 3.5. Inter-AS Links 1286 The main source of TE information is the IGP, which is not active on 1287 inter-AS links. In some cases, the IGP may have information of 1288 inter-AS links ([RFC5392], [RFC5316]). In other cases, an 1289 implementation SHOULD provide a means to inject inter-AS links into 1290 BGP-LS. The exact mechanism used to provision the inter-AS links is 1291 outside the scope of this document 1293 3.6. Router-ID Anchoring Example: ISO Pseudonode 1295 Encoding of a broadcast LAN in IS-IS provides a good example of how 1296 Router-IDs are encoded. Consider Figure 31. This represents a 1297 Broadcast LAN between a pair of routers. The "real" (=non 1298 pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. 1299 The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for 1300 the LAN. Two unidirectional links (Node1, Pseudonode 1) and 1301 (Pseudonode1, Node2) are being generated. 1303 The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP 1304 Router-ID TLV of the local node descriptor is 6 octets long 1305 containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of 1306 the remote node descriptor is 7 octets long containing the ISO-ID of 1307 Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link 1308 contains one local IPv4 Router-ID TLV (TLV type 1028) containing 1309 192.0.2.1, the IPv4 Router-ID of Node1. 1311 The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP 1312 Router-ID TLV of the local node descriptor is 7 octets long 1313 containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP 1314 Router-ID TLV of the remote node descriptor is 6 octets long 1315 containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of 1316 this link contains one remote IPv4 Router-ID TLV (TLV type 1030) 1317 containing 192.0.2.2, the IPv4 Router-ID of Node2. 1319 +-----------------+ +-----------------+ +-----------------+ 1320 | Node1 | | Pseudonode1 | | Node2 | 1321 |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| 1322 | 192.0.2.1 | | | | 192.0.2.2 | 1323 +-----------------+ +-----------------+ +-----------------+ 1325 3.7. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 1327 Graceful migration from one IGP to another requires coordinated 1328 operation of both protocols during the migration period. Such a 1329 coordination requires identifying a given physical link in both IGPs. 1330 The IPv4 Router-ID provides that "glue" which is present in the node 1331 descriptors of the OSPF link NLRI and in the link attribute of the 1332 IS-IS link NLRI. 1334 Consider a point-to-point link between two routers, A and B, that 1335 initially were OSPFv2-only routers and then IS-IS is enabled on them. 1336 Node A has IPv4 Router-ID and ISO-ID; node B has IPv4 Router-ID, IPv6 1337 Router-ID and ISO-ID. Each protocol generates one link NLRI for the 1338 link (A, B), both of which are carried by BGP-LS. The OSPFv2 link 1339 NLRI for the link is encoded with the IPv4 Router-ID of nodes A and B 1340 in the local and remote node descriptors, respectively. The IS-IS 1341 link NLRI for the link is encoded with the ISO-ID of nodes A and B in 1342 the local and remote node descriptors, respectively. In addition, 1343 the BGP-LS attribute of the IS-IS link NLRI contains the the TLV type 1344 1028 containing the IPv4 Router-ID of node A; TLV type 1030 1345 containing the IPv4 Router-ID of node B and TLV type 1031 containing 1346 the IPv6 Router-ID of node B. In this case, by using IPv4 Router-ID, 1347 the link (A, B) can be identified in both IS-IS and OSPF protocol. 1349 4. Link to Path Aggregation 1351 Distribution of all links available in the global Internet is 1352 certainly possible, however not desirable from a scaling and privacy 1353 point of view. Therefore an implementation may support link to path 1354 aggregation. Rather than advertising all specific links of a domain, 1355 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1356 of nodes. The "aggregate link" represents the aggregated set of link 1357 properties between a pair of non-adjacent nodes. The actual methods 1358 to compute the path properties (of bandwidth, metric) are outside the 1359 scope of this document. The decision whether to advertise all 1360 specific links or aggregated links is an operator's policy choice. 1361 To highlight the varying levels of exposure, the following deployment 1362 examples are discussed. 1364 4.1. Example: No Link Aggregation 1366 Consider Figure 32. Both AS1 and AS2 operators want to protect their 1367 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1368 compute its link-protection LSP to R3 it needs to "see" an alternate 1369 path to R3. Therefore the AS2 operator exposes its topology. All BGP 1370 TE enabled routers in AS1 "see" the full topology of AS and therefore 1371 can compute a backup path. Note that the decision if the direct link 1372 between {R3, R4} or the {R4, R5, R3) path is used is made by the 1373 computing router. 1375 AS1 : AS2 1376 : 1377 R1-------R3 1378 | : | \ 1379 | : | R5 1380 | : | / 1381 R2-------R4 1382 : 1383 : 1385 4.2. Example: ASBR to ASBR Path Aggregation 1387 The brief difference between the "no-link aggregation" example and 1388 this example is that no specific link gets exposed. Consider Figure 1389 33. The only link which gets advertised by AS2 is an "aggregate" link 1390 between R3 and R4. This is enough to tell AS1 that there is a backup 1391 path. However the actual links being used are hidden from the 1392 topology. 1394 AS1 : AS2 1395 : 1396 R1-------R3 1397 | : | 1398 | : | 1399 | : | 1400 R2-------R4 1401 : 1402 : 1404 4.3. Example: Multi-AS Path Aggregation 1406 Service providers in control of multiple ASes may even decide to not 1407 expose their internal inter-AS links. Consider Figure 34. AS3 is 1408 modeled as a single node which connects to the border routers of the 1409 aggregated domain. 1411 AS1 : AS2 : AS3 1412 : : 1413 R1-------R3----- 1414 | : : \ 1415 | : : vR0 1416 | : : / 1417 R2-------R4----- 1418 : : 1419 : : 1421 5. IANA Considerations 1423 This document requests a code point from the registry of Address 1424 Family Numbers. As per early allocation procedure this is AFI 16388. 1426 This document requests a code point from the registry of Subsequent 1427 Address Family Numbers. As per early allocation procedure this is 1428 SAFI 71. 1430 This document requests a code point from the BGP Path Attributes 1431 registry. 1433 This document requests creation of a new registry for node anchor, 1434 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1435 Values 256-65535 will be used for Codepoints. The registry will be 1436 initialized as shown in Table 11. Allocations within the registry 1437 will require documentation of the proposed use of the allocated value 1438 and approval by the Designated Expert assigned by the IESG (see 1439 [RFC5226]). 1441 Note to RFC Editor: this section may be removed on publication as an 1442 RFC. 1444 6. Manageability Considerations 1446 This section is structured as recommended in [RFC5706]. 1448 6.1. Operational Considerations 1450 6.1.1. Operations 1452 Existing BGP operational procedures apply. No new operation 1453 procedures are defined in this document. It is noted that the NLRI 1454 information present in this document purely carries application level 1455 data that has no immediate corresponding forwarding state impact. As 1456 such, any churn in reachability information has different impact than 1457 regular BGP updates which need to change forwarding state for an 1458 entire router. Furthermore it is anticipated that distribution of 1459 this NLRI will be handled by dedicated route-reflectors providing a 1460 level of isolation and fault-containment between different NLRI 1461 types. 1463 6.1.2. Installation and Initial Setup 1464 Configuration parameters defined in Section 6.2.3 SHOULD be 1465 initialized to the following default values: 1467 o The Link-State NLRI capability is turned off for all neighbors. 1469 o The maximum rate at which Link-State NLRIs will be advertised/ 1470 withdrawn from neighbors is set to 200 updates per second. 1472 6.1.3. Migration Path 1474 The proposed extension is only activated between BGP peers after 1475 capability negotiation. Moreover, the extensions can be turned on/ 1476 off an individual peer basis (see Section 6.2.3), so the extension 1477 can be gradually rolled out in the network. 1479 6.1.4. Requirements on Other Protocols and Functional Components 1481 The protocol extension defined in this document does not put new 1482 requirements on other protocols or functional components. 1484 6.1.5. Impact on Network Operation 1486 Frequency of Link-State NLRI updates could interfere with regular BGP 1487 prefix distribution. A network operator MAY use a dedicated Route- 1488 Reflector infrastructure to distribute Link-State NLRIs. 1490 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1491 domain, which can consist of multiple areas within an AS or multiple 1492 ASes. 1494 6.1.6. Verifying Correct Operation 1496 Existing BGP procedures apply. In addition, an implementation SHOULD 1497 allow an operator to: 1499 o List neighbors with whom the Speaker is exchanging Link-State 1500 NLRIs 1502 6.2. Management Considerations 1504 6.2.1. Management Information 1506 6.2.2. Fault Management 1508 TBD. 1510 6.2.3. Configuration Management 1512 An implementation SHOULD allow the operator to specify neighbors to 1513 which Link-State NLRIs will be advertised and from which Link-State 1514 NLRIs will be accepted. 1516 An implementation SHOULD allow the operator to specify the maximum 1517 rate at which Link-State NLRIs will be advertised/withdrawn from 1518 neighbors 1520 An implementation SHOULD allow the operator to specify the maximum 1521 number of Link-State NLRIs stored in router's RIB. 1523 An implementation SHOULD allow the operator to create abstracted 1524 topologies that are advertised to neighbors; Create different 1525 abstractions for different neighbors. 1527 An implementation SHOULD allow the operator to configure a 64-bit 1528 instance ID. 1530 An implementation SHOULD allow the operator to configure a pair of 1531 ASN and BGP-LS identifier per flooding set the node participates in. 1533 6.2.4. Accounting Management 1535 Not Applicable. 1537 6.2.5. Performance Management 1539 An implementation SHOULD provide the following statistics: 1541 o Total number of Link-State NLRI updates sent/received 1543 o Number of Link-State NLRI updates sent/received, per neighbor 1545 o Number of errored received Link-State NLRI updates, per neighbor 1547 o Total number of locally originated Link-State NLRIs 1549 6.2.6. Security Management 1551 An operator SHOULD define ACLs to limit inbound updates as follows: 1553 o Drop all updates from Consumer peers 1555 7. TLV/Sub-TLV Code Points Summary 1557 This section contains the global table of all TLVs/Sub-TLVs defined 1558 in this document. 1560 +---------+----------------------+--------------+-------------------+ 1561 | TLV | Description | IS-IS TLV/ | Value defined in: | 1562 | Code | | Sub-TLV | | 1563 | Point | | | | 1564 +---------+----------------------+--------------+-------------------+ 1565 | 256 | Local Node | --- | Section 3.2.1.2 | 1566 | | Descriptors | | | 1567 | 257 | Remote Node | --- | Section 3.2.1.3 | 1568 | | Descriptors | | | 1569 | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1570 | | Identifiers | | | 1571 | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 1572 | | address | | | 1573 | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 1574 | | address | | | 1575 | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 1576 | | address | | | 1577 | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 1578 | | address | | | 1579 | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | 1580 | 264 | OSPF Route Type | --- | Section 3.2.3 | 1581 | 265 | IP Reachability | --- | Section 3.2.3 | 1582 | | Information | | | 1583 | 512 | Autonomous System | --- | Section 3.2.1.4 | 1584 | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | 1585 | 514 | Area ID | --- | Section 3.2.1.4 | 1586 | 515 | IGP Router-ID | --- | Section 3.2.1.4 | 1587 | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | 1588 | 1025 | Opaque Node | --- | Section 3.3.1.5 | 1589 | | Properties | | | 1590 | 1026 | Node Name | variable | Section 3.3.1.3 | 1591 | 1027 | IS-IS Area | variable | Section 3.3.1.2 | 1592 | | Identifier | | | 1593 | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1594 | | Local Node | | | 1595 | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1596 | | Local Node | | | 1597 | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | 1598 | | Remote Node | | | 1599 | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | 1600 | | Remote Node | | | 1601 | 1032 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 1602 | | Identifiers | | | 1603 | 1088 | Administrative group | 22/3 | [RFC5305]/3.1 | 1604 | | (color) | | | 1605 | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | 1606 | | bandwidth | | | 1607 | 1090 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 1608 | | bandwidth | | | 1609 | 1091 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 1610 | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | 1611 | 1093 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 1612 | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | 1613 | 1095 | IGP Metric | --- | Section 3.3.2.4 | 1614 | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | 1615 | | Group | | | 1616 | 1097 | Opaque link | --- | Section 3.3.2.6 | 1617 | | attribute | | | 1618 | 1098 | Link Name attribute | --- | Section 3.3.2.7 | 1619 | 1152 | IGP Flags | --- | Section 3.3.3.1 | 1620 | 1153 | Route Tag | --- | [RFC5130] | 1621 | 1154 | Extended Tag | --- | [RFC5130] | 1622 | 1155 | Prefix Metric | --- | [RFC5305] | 1623 | 1156 | OSPF Forwarding | --- | [RFC2328] | 1624 | | Address | | | 1625 | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | 1626 | | Attribute | | | 1627 +---------+----------------------+--------------+-------------------+ 1629 8. Security Considerations 1631 Procedures and protocol extensions defined in this document do not 1632 affect the BGP security model. See the 'Security Considerations' 1633 section of [RFC4271] for a discussion of BGP security. Also refer to 1634 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 1636 In the context of the BGP peerings associated with this document, a 1637 BGP Speaker SHOULD NOT accept updates from a Consumer peer. That is, 1638 a participating BGP Speaker, should be aware of the nature of its 1639 relationships for link state relationships and should protect itself 1640 from peers sending updates that either represent erroneous 1641 information feedback loops, or are false input. Such protection can 1642 be achieved by manual configuration of Consumer peers at the BGP 1643 Speaker. 1645 An operator SHOULD employ a mechanism to protect a BGP Speaker 1646 against DDOS attacks from Consumers. The principal attack a consumer 1647 may apply is to attempt to start multiple sessions either 1648 sequentially or simultaneously. Protection can be applied by 1649 imposing rate limits. 1651 Additionally, it may be considered that the export of link state and 1652 TE information as described in this document constitutes a risk to 1653 confidentiality of mission-critical or commercially-sensitive 1654 information about the network. BGP peerings are not automatic and 1655 require configuration, thus it is the responsibility of the network 1656 operator to ensure that only trusted Consumers are configured to 1657 receive such information. 1659 9. Contributors 1661 We would like to thank Robert Varga for the significant contribution 1662 he gave to this document. 1664 10. Acknowledgements 1665 We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek 1666 Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les 1667 Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex 1668 Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, 1669 Vipin Kumar, Naiming Shen, Balaji Rajagopalan and Yakov Rekhter for 1670 their comments. 1672 11. References 1674 11.1. Normative References 1676 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1677 dual environments", RFC 1195, December 1990. 1679 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 1680 E. Lear, "Address Allocation for Private Internets", BCP 1681 5, RFC 1918, February 1996. 1683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1684 Requirement Levels", BCP 14, RFC 2119, March 1997. 1686 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1688 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1689 Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1690 1999. 1692 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 1693 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1694 Tunnels", RFC 3209, December 2001. 1696 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1697 Support of Generalized Multi-Protocol Label Switching 1698 (GMPLS)", RFC 4202, October 2005. 1700 [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway 1701 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1703 [RFC4760] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 1704 "Multiprotocol Extensions for BGP-4", RFC 4760, January 1705 2007. 1707 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L. and P. 1708 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1709 4915, June 2007. 1711 [RFC5036] Andersson, L., Minei, I. and B. Thomas, "LDP 1712 Specification", RFC 5036, October 2007. 1714 [RFC5120] Przygienda, T., Shen, N. and N. Sheth, "M-ISIS: Multi 1715 Topology (MT) Routing in Intermediate System to 1716 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1718 [RFC5130] Previdi, S., Shand, M. and C. Martin, "A Policy Control 1719 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1720 February 2008. 1722 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1723 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1724 May 2008. 1726 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 1727 Mechanism for IS-IS", RFC 5301, October 2008. 1729 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1730 Engineering", RFC 5305, October 2008. 1732 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1733 of Generalized Multi-Protocol Label Switching (GMPLS)", 1734 RFC 5307, October 2008. 1736 [RFC5890] Klensin, J., "Internationalized Domain Names for 1737 Applications (IDNA): Definitions and Document Framework", 1738 RFC 5890, August 2010. 1740 [RFC6119] Harrison, J., Berger, J. and M. Bartlett, "IPv6 Traffic 1741 Engineering in IS-IS", RFC 6119, February 2011. 1743 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1744 Identifier for BGP-4", RFC 6286, June 2011. 1746 [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A. and D. Ward, 1747 "IS-IS Multi-Instance", RFC 6822, December 2012. 1749 11.2. Informative References 1751 [I-D.ietf-alto-protocol] 1752 Alimi, R., Penno, R. and Y. Yang, "ALTO Protocol", 1753 Internet-Draft draft-ietf-alto-protocol-27, March 2014. 1755 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 1756 4272, January 2006. 1758 [RFC4655] Farrel, A., Vasseur, J.-P. and J. Ash, "A Path Computation 1759 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1761 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R. and S. 1762 Shaffer, "Extensions to OSPF for Advertising Optional 1763 Router Capabilities", RFC 4970, July 2007. 1765 [RFC5073] Vasseur, J.P. and J.L. Le Roux, "IGP Routing Protocol 1766 Extensions for Discovery of Traffic Engineering Node 1767 Capabilities", RFC 5073, December 2007. 1769 [RFC5152] Vasseur, JP., Ayyangar, A. and R. Zhang, "A Per-Domain 1770 Path Computation Method for Establishing Inter-Domain 1771 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1772 5152, February 2008. 1774 [RFC5316] Chen, M., Zhang, R. and X. Duan, "ISIS Extensions in 1775 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1776 Traffic Engineering", RFC 5316, December 2008. 1778 [RFC5392] Chen, M., Zhang, R. and X. Duan, "OSPF Extensions in 1779 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1780 Traffic Engineering", RFC 5392, January 2009. 1782 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1783 Optimization (ALTO) Problem Statement", RFC 5693, October 1784 2009. 1786 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1787 Management of New Protocols and Protocol Extensions", RFC 1788 5706, November 2009. 1790 [RFC6549] Lindem, A., Roy, A. and S. Mirtorabi, "OSPFv2 Multi- 1791 Instance Extensions", RFC 6549, March 2012. 1793 [RFC6952] Jethanandani, M., Patel, K. and L. Zheng, "Analysis of 1794 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1795 and Authentication for Routing Protocols (KARP) Design 1796 Guide", RFC 6952, May 2013. 1798 Authors' Addresses 1800 Hannes Gredler 1801 Juniper Networks, Inc. 1802 1194 N. Mathilda Ave. 1803 Sunnyvale, CA 94089 1804 US 1806 Email: hannes@juniper.net 1808 Jan Medved 1809 Cisco Systems, Inc. 1810 170, West Tasman Drive 1811 San Jose, CA 95134 1812 US 1814 Email: jmedved@cisco.com 1815 Stefano Previdi 1816 Cisco Systems, Inc. 1817 Via Del Serafico, 200 1818 Rome, 00142 1819 Italy 1821 Email: sprevidi@cisco.com 1823 Adrian Farrel 1824 Juniper Networks, Inc. 1825 1194 N. Mathilda Ave. 1826 Sunnyvale, CA 94089 1827 US 1829 Email: afarrel@juniper.net 1831 Saikat Ray 1832 Cisco Systems, Inc. 1833 170, West Tasman Drive 1834 San Jose, CA 95134 1835 US 1837 Email: sairay@cisco.com