idnits 2.17.1 draft-gredler-idr-ls-distribution-02.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 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 15, 2012) is 4300 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 4893 (Obsoleted by RFC 6793) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-11 == Outdated reference: A later version (-08) exists of draft-ietf-isis-mi-06 -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: January 16, 2013 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 July 15, 2012 11 North-Bound Distribution of Link-State and TE Information using BGP 12 draft-gredler-idr-ls-distribution-02 14 Abstract 16 In a number of environments, a component external to a network is 17 called upon to perform computations based on the network topology and 18 current state of the connections within the network, including 19 traffic engineering information. This is information typically 20 distributed by IGP routing protocols within the network 22 This document describes a mechanism by which links state and traffic 23 engineering information can be collected from networks and shared 24 with external components using the BGP routing protocol. This is 25 achieved using a new BGP Network Layer Reachability Information 26 (NLRI) encoding format. The mechanism is applicable to physical and 27 virtual links. The mechanism described is subject to policy control. 29 Applications of this technique include Application Layer Traffic 30 Optimization (ALTO) servers, and Path Computation Elements (PCEs). 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119] 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 16, 2013. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 5 74 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 76 3. Carrying Link State Information in BGP . . . . . . . . . . . . 8 77 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. The Link State NLRI . . . . . . . . . . . . . . . . . . . 9 79 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . . 11 80 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . . 14 81 3.3. The LINK_STATE Attribute . . . . . . . . . . . . . . . . . 15 82 3.3.1. Link Attribute TLVs . . . . . . . . . . . . . . . . . 15 83 3.3.2. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19 84 3.4. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . . 22 85 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . . 22 86 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . . 23 87 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . . 23 88 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . . 24 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 6. Manageability Considerations . . . . . . . . . . . . . . . . . 25 91 6.1. Operational Considerations . . . . . . . . . . . . . . . . 25 92 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . . 25 93 6.1.2. Installation and Initial Setup . . . . . . . . . . . . 25 94 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . . 25 95 6.1.4. Requirements on Other Protocols and Functional 96 Components . . . . . . . . . . . . . . . . . . . . . . 25 97 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 26 98 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 26 99 6.2. Management Considerations . . . . . . . . . . . . . . . . 26 100 6.2.1. Management Information . . . . . . . . . . . . . . . . 26 101 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . . 26 102 6.2.3. Configuration Management . . . . . . . . . . . . . . . 26 103 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 27 104 6.2.5. Performance Management . . . . . . . . . . . . . . . . 27 105 6.2.6. Security Management . . . . . . . . . . . . . . . . . 27 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 109 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 110 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 113 1. Introduction 115 The contents of a Link State Database (LSDB) or a Traffic Engineering 116 Database (TED) has the scope of an IGP area. Some applications, such 117 as end-to-end Traffic Engineering (TE), would benefit from visibility 118 outside one area or Autonomous System (AS) in order to make better 119 decisions. 121 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 122 a mechanism for achieving the computation of end-to-end TE paths that 123 cross the visibility of more than one TED or which require CPU- 124 intensive or coordinated computations. The IETF has also defined the 125 ALTO Server [RFC5693] as an entity that generates an abstracted 126 network topology and provides it to network-aware applications. 128 Both a PCE and an ALTO Server need to gather information about the 129 topologies and capabilities of the network in order to be able to 130 fulfill their function 132 This document describes a mechanism by which Link State and TE 133 information can be collected from networks and shared with external 134 components using the BGP routing protocol [RFC4271]. This is 135 achieved using a new BGP Network Layer Reachability Information 136 (NLRI) encoding format. The mechanism is applicable to physical and 137 virtual links. The mechanism described is subject to policy control. 139 A router maintains one or more databases for storing link-state 140 information about nodes and links in any given area. Link attributes 141 stored in these databases include: local/remote IP addresses, local/ 142 remote interface identifiers, link metric and TE metric, link 143 bandwidth, reservable bandwidth, per CoS class reservation state, 144 preemption and Shared Risk Link Groups (SRLG). The router's BGP 145 process can retrieve topology from these LSDBs and distribute it to a 146 consumer, either directly or via a peer BGP Speaker (typically a 147 dedicated Route Reflector), using the encoding specified in this 148 document. 150 The collection of Link State and TE link state information and its 151 distribution to consumers is shown in the following figure. 153 +-----------+ 154 | Consumer | 155 +-----------+ 156 ^ 157 | 158 +-----------+ 159 | BGP | +-----------+ 160 | Speaker | | Consumer | 161 +-----------+ +-----------+ 162 ^ ^ ^ ^ 163 | | | | 164 +---------------+ | +-------------------+ | 165 | | | | 166 +-----------+ +-----------+ +-----------+ 167 | BGP | | BGP | | BGP | 168 | Speaker | | Speaker | . . . | Speaker | 169 +-----------+ +-----------+ +-----------+ 170 ^ ^ ^ 171 | | | 172 IGP IGP IGP 174 Figure 1: TE Link State info collection 176 A BGP Speaker may apply configurable policy to the information that 177 it distributes. Thus, it may distribute the real physical topology 178 from the LSDB or the TED. Alternatively, it may create an abstracted 179 topology, where virtual, aggregated nodes are connected by virtual 180 paths. Aggregated nodes can be created, for example, out of multiple 181 routers in a POP. Abstracted topology can also be a mix of physical 182 and virtual nodes and physical and virtual links. Furthermore, the 183 BGP Speaker can apply policy to determine when information is updated 184 to the consumer so that there is reduction of information flow form 185 the network to the consumers. Mechanisms through which topologies 186 can be aggregated or virtualized are outside the scope of this 187 document 189 2. Motivation and Applicability 191 This section describes uses cases from which the requirements can be 192 derived. 194 2.1. MPLS-TE with PCE 196 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 197 within a "domain" (such as an IGP area) or across multiple domains 198 (such as a multi-area AS, or multiple ASes). 200 o Within a single area, the PCE offers enhanced computational power 201 that may not be available on individual routers, sophisticated 202 policy control and algorithms, and coordination of computation 203 across the whole area. 205 o If a router wants to compute a MPLS-TE path across IGP areas its 206 own TED lacks visibility of the complete topology. That means 207 that the router cannot determine the end-to-end path, and cannot 208 even select the right exit router (Area Border Router - ABR) for 209 an optimal path. This is an issue for large-scale networks that 210 need to segment their core networks into distinct areas, but which 211 still want to take advantage of MPLS-TE. 213 Previous solutions used per-domain path computation [RFC5152]. The 214 source router could only compute the path for the first area because 215 the router only has full topological visibility for the first area 216 along the path, but not for subsequent areas. Per-domain path 217 computation uses a technique called "loose-hop-expansion" [RFC3209], 218 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 219 using the IGP computed shortest path topology for the remainder of 220 the path. This may lead to sub-optimal paths, makes alternate/ 221 back-up path computation hard, and might result in no TE path being 222 found when one really does exist. 224 The PCE presents a computation server that may have visibility into 225 more than one IGP area or AS, or may cooperate with other PCEs to 226 perform distributed path computation. The PCE obviously needs access 227 to the TED for the area(s) it serves, but [RFC4655] does not describe 228 how this is achieved. Many implementations make the PCE a passive 229 participant in the IGP so that it can learn the latest state of the 230 network, but this may be sub-optimal when the network is subject to a 231 high degree of churn, or when the PCE is responsible for multiple 232 areas. 234 The following figure shows how a PCE can get its TED information 235 using the mechanism described in this document. 237 +----------+ +---------+ 238 | ----- | | BGP | 239 | | TED |<-+-------------------------->| Speaker | 240 | ----- | TED synchronization | | 241 | | | mechanism: +---------+ 242 | | | BGP with Link-State NLRI 243 | v | 244 | ----- | 245 | | PCE | | 246 | ----- | 247 +----------+ 248 ^ 249 | Request/ 250 | Response 251 v 252 Service +----------+ Signaling +----------+ 253 Request | Head-End | Protocol | Adjacent | 254 -------->| Node |<------------>| Node | 255 +----------+ +----------+ 257 Figure 2: External PCE node using a TED synchronization mechanism 259 The mechanism in this document allows the necessary TED information 260 to be collected from the IGP within the network, filtered according 261 to configurable policy, and distributed to the PCE as necessary. 263 2.2. ALTO Server Network API 265 An ALTO Server [RFC5693] is an entity that generates an abstracted 266 network topology and provides it to network-aware applications over a 267 web service based API. Example applications are p2p clients or 268 trackers, or CDNs. The abstracted network topology comes in the form 269 of two maps: a Network Map that specifies allocation of prefixes to 270 PIDs, and a Cost Map that specifies the cost between PIDs listed in 271 the Network Map. For more details, see [I-D.ietf-alto-protocol]. 273 ALTO abstract network topologies can be auto-generated from the 274 physical topology of the underlying network. The generation would 275 typically be based on policies and rules set by the operator. Both 276 prefix and TE data are required: prefix data is required to generate 277 ALTO Network Maps, TE (topology) data is required to generate ALTO 278 Cost Maps. Prefix data is carried and originated in BGP, TE data is 279 originated and carried in an IGP. The mechanism defined in this 280 document provides a single interface through which an ALTO Server can 281 retrieve all the necessary prefix and network topology data from the 282 underlying network. Note an ALTO Server can use other mechanisms to 283 get network data, for example, peering with multiple IGP and BGP 284 Speakers. 286 The following figure shows how an ALTO Server can get network 287 topology information from the underlying network using the mechanism 288 described in this document. 290 +--------+ 291 | Client |<--+ 292 +--------+ | 293 | ALTO +--------+ BGP with +---------+ 294 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 295 | Client |<--+------------| Server |<----------------| Speaker | 296 +--------+ | | | | | 297 | +--------+ +---------+ 298 +--------+ | 299 | Client |<--+ 300 +--------+ 302 Figure 3: ALTO Server using network topology information 304 3. Carrying Link State Information in BGP 306 Two parts: a new BGP NLRI that describes links and nodes comprising 307 IGP link state information, and a new BGP path attribute that carries 308 link and node properties and attributes, such as the link metric or 309 node properties. 311 3.1. TLV Format 313 Information in the new link state NLRIs and attributes is encoded in 314 Type/Length/Value triplets. The TLV format is shown in Figure 4. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Type | Length | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | Value (variable) | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 4: TLV format 328 The Length field defines the length of the value portion in octets 329 (thus a TLV with no value portion would have a length of zero). The 330 TLV is not padded to four-octet alignment; Unrecognized types are 331 ignored. 333 3.2. The Link State NLRI 335 The MP_REACH and MP_UNREACH attributes are BGP's containers for 336 carrying opaque information. Each Link State NLRI describes either a 337 single node or link. 339 All link and node information SHALL be encoded using a TBD AFI / SAFI 340 1 or SAFI 128 header into those attributes. SAFI 1 SHALL be used for 341 Internet routing (Public) and SAFI 128 SHALL be used for VPN routing 342 (Private) applications. 344 In order for two BGP speakers to exchange Link-State NLRI, they MUST 345 use BGP Capabilities Advertisement to ensure that they both are 346 capable of properly processing such NLRI. This is done as specified 347 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 348 an AFI of TBD and an SAFI of 1 or 128. 350 The format of the Link State NLRI is shown in the following figure. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | NLRI Type | Total NLRI Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 | Link-State NLRI (variable) | 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 5: Link State SAFI 1 NLRI Format 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | NLRI Type | Total NLRI Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 + Route Distinguisher + 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 | Link-State NLRI (variable) | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 6: Link State SAFI 128 NLRI Format 380 The 'Total NLRI Length' field contains the cumulative length of all 381 the TLVs in the NLRI. For VPN applications it also includes the 382 length of the Route Distinguisher. 384 The 'NLRI Type' field can contain one of the following values: 386 Type = 1: Link NLRI, contains link descriptors and link attributes 388 Type = 2: Node NLRI, contains node attributes 390 The Link NLRI (NLRI Type = 1) is shown in the following figure. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Protocol-ID | Reserved | Instance Identifier | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Local Node Descriptors (variable) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Remote Node Descriptors (variable) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Link Descriptors (variable) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 7: The Link NLRI format 406 The Node NLRI (NLRI Type = 2) is shown in the following figure. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Protocol-ID | Reserved | Instance Identifier | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Local Node Descriptors (variable) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 8: The Node NLRI format 418 The 'Protocol-ID' field can contain one of the following values: 420 Type = 0: Unknown, The source of NLRI information could not be 421 determined 423 Type = 1: IS-IS Level 1, The NLRI information has been sourced by 424 IS-IS Level 1 425 Type = 2: IS-IS Level 2, The NLRI information has been sourced by 426 IS-IS Level 2 428 Type = 3: OSPF, The NLRI information has been sourced by OSPF 430 Type = 4: Direct, The NLRI information has been sourced from local 431 interface state 433 Type = 5: Static, The NLRI information has been sourced by static 434 configuration 436 Both OSPF and IS-IS may run multiple routing protocol instances over 437 the same link. See [I-D.ietf-isis-mi] and [RFC6549]. The 'Instance 438 Identifier' field identifies the protocol instance. 440 Each Node Descriptor and Link Descriptor consists of one or more TLVs 441 described in the following sections. The sender of an UPDATE message 442 MUST order the TLVs within a Node Descriptor or a Link Descriptor in 443 ascending order of TLV type." 445 3.2.1. Node Descriptors 447 Each link gets anchored by at least a pair of router-IDs. Since 448 there are many Router-IDs formats (32 Bit IPv4 router-ID, 56 Bit ISO 449 Node-ID and 128 Bit IPv6 router-ID) a link may be anchored by more 450 than one Router-ID pair. The set of Local and Remote Node 451 Descriptors describe which Protocols Router-IDs will be following to 452 "anchor" the link described by the "Link attribute TLVs". There must 453 be at least one "like" router-ID pair of a Local Node Descriptors and 454 a Remote Node Descriptors per-protocol. If a peer sends an illegal 455 combination in this respect, then this is handled as an NLRI error, 456 described in [RFC4760]. 458 It is desirable that the Router-ID assignments inside the Node anchor 459 are globally unique. However there may be router-ID spaces (e.g. 460 ISO) where not even a global registry exists, or worse, Router-IDs 461 have been allocated following private-IP RFC 1918 [RFC1918] 462 allocation. In order to disambiguate the Router-IDs the local and 463 remote Autonomous System number TLVs of the anchor nodes may be 464 included in the NLRI. If the anchor node's AS is a member of an AS 465 Confederation ([RFC5065]), then the Autonomous System number TLVs 466 contains the confederations' AS Confederation Identifier and the 467 Member-AS TLV is included in the NLRI. The Local and Remote 468 Autonomous System TLVs are 4 octets wide as described in [RFC4893]. 469 2-octet AS Numbers SHALL be expanded to 4-octet AS Numbers by zeroing 470 the two MSB octets. 472 3.2.1.1. Local Node Descriptors 474 The Local Node Descriptors TLV (Type 256) contains Node Descriptors 475 for the node anchoring the local end of the link. The length of this 476 TLV is variable. The value contains one or more Node Descriptor Sub- 477 TLVs defined in Section 3.2.1.3. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 | Node Descriptor Sub-TLVs (variable) | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Figure 9: Local Node Descriptors TLV format 491 3.2.1.2. Remote Node Descriptors 493 The Remote Node Descriptors TLV (Type 257) contains Node Descriptors 494 for the node anchoring the remote end of the link. The length of 495 this TLV is variable. The value contains one or more Node Descriptor 496 Sub-TLVs defined in Section 3.2.1.3. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 | Node Descriptor Sub-TLVs (variable) | 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 10: Remote Node Descriptors TLV format 510 3.2.1.3. Node Descriptor Sub-TLVs 512 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 513 the following table: 515 +------+-------------------+--------+ 516 | Type | Description | Length | 517 +------+-------------------+--------+ 518 | 258 | Autonomous System | 4 | 519 | 259 | Member-AS | 4 | 520 | 260 | IPv4 Router-ID | 5 | 521 | 261 | IPv6 Router-ID | 17 | 522 | 262 | ISO Node-ID | 7 | 523 +------+-------------------+--------+ 525 Table 1: Node Descriptor Sub-TLVs 527 The TLV values in Node Descriptor Sub-TLVs are defined as follows: 529 Autonomous System: opaque value (32 Bit AS ID) 531 Member-AS: opaque value (32 Bit AS ID); only included if the node is 532 in an AS confederation. 534 IPv4 Router ID: opaque value (can be an IPv4 address or an 32 Bit 535 router ID) followed by a LAN-ID octet in case LAN "Pseudonode" 536 information gets advertised. The PSN octet must be zero for non- 537 LAN "Pseudonodes". 539 IPv6 Router ID: opaque value (can be an IPv6 address or 128 Bit 540 router ID) followed by a LAN-ID octet in case LAN "Pseudonode" 541 information gets advertised. The PSN octet must be zero for non- 542 LAN "Pseudonodes". 544 ISO Node ID: ISO node-ID (6 octets ISO system-ID) followed by a PSN 545 octet in case LAN "Pseudonode" information gets advertised. The 546 PSN octet must be zero for non-LAN "Pseudonodes". 548 3.2.1.4. Router-ID Anchoring Example: ISO Pseudonode 550 IS-IS Pseudonodes are a good example for the variable Router-ID 551 anchoring. Consider Figure 11. This represents a Broadcast LAN 552 between a pair of routers. The "real" (=non pseudonode) routers have 553 both an IPv4 Router-ID and IS-IS Node-ID. The pseudonode does not 554 have an IPv4 Router-ID. Two unidirectional links (Node1, Pseudonode 555 1) and (Pseudonode 1, Node 2) are being generated. 557 The NRLI for (Node1, Pseudonode1) encodes local IPv4 router-ID, local 558 ISO node-ID and remote ISO node-id) 560 The NLRI for (Pseudonode1, Node2) encodes a local ISO node-ID, remote 561 IPv4 router-ID and remote ISO node-id. 563 +-----------------+ +-----------------+ +-----------------+ 564 | Node1 | | Pseudonode 1 | | Node2 | 565 |1921.6800.1001.00|--->|1921.6800.1001.02|--->|1921.6800.1002.00| 566 | 192.168.1.1 | | | | 192.168.1.2 | 567 +-----------------+ +-----------------+ +-----------------+ 569 Figure 11: IS-IS Pseudonodes 571 3.2.1.5. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 573 Migrating gracefully from one IGP to another requires congruent 574 operation of both routing protocols during the migration period. The 575 target protocol (IS-IS) supports more router-ID spaces than the 576 source (OSPFv2) protocol. When advertising a point-to-point link 577 between an OSPFv2-only router and an OSPFv2 and IS-IS enabled router 578 the following link information may be generated. Note that the IS-IS 579 router also supports the IPv6 traffic engineering extensions RFC 6119 580 [RFC6119] for IS-IS. 582 The NRLI encodes local IPv4 router-id, remote IPv4 router-id, remote 583 ISO node-id and remote IPv6 node-id. 585 3.2.2. Link Descriptors 587 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 588 triplets. The format of each TLV is shown in Section 3.1. The 'Link 589 descriptor' TLVs uniquely identify a link between a pair of anchor 590 Routers. A link described by the Link descriptor TLVs actually is a 591 "half-link", a unidirectional representation of a logical link. In 592 order to fully describe a single logical link two originating routers 593 need to advertise a half-link each, i.e. two link NLRIs will be 594 advertised. 596 The format and semantics of the 'value' fields in most 'Link 597 Descriptor' TLVs correspond to the format and semantics of value 598 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 599 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 600 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 601 carry data sourced either by IS-IS or OSPF. 603 The following link descriptor TLVs are valid in the Link NLRI: 605 +------+------------------------+-----------------+-----------------+ 606 | Type | Description | IS-IS | Value defined | 607 | | | TLV/Sub-TLV | in: | 608 +------+------------------------+-----------------+-----------------+ 609 | 263 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 610 | | Identifiers | | | 611 | 264 | IPv4 interface address | 22/6 | [RFC5305]/3.2 | 612 | 265 | IPv4 neighbor address | 22/8 | [RFC5305]/3.3 | 613 | 266 | IPv6 interface address | 22/12 | [RFC6119]/4.2 | 614 | 267 | IPv6 neighbor address | 22/13 | [RFC6119]/4.3 | 615 | 268 | Multi Topology ID | --- | Section 3.2.2.1 | 616 +------+------------------------+-----------------+-----------------+ 618 Table 2: Link Descriptor TLVs 620 3.2.2.1. Multi Topology ID TLV 622 The Multi Topology ID TLV (Type 268) carries the Multi Topology ID 623 for this link. The semantics of the Multi Topology ID are defined in 624 RFC5120, Section 7.2 [RFC5120], and the OSPF Multi Topology ID), 625 defined in RFC4915, Section 3.7 [RFC4915]. If the value in the Multi 626 Topology ID TLV is derived from OSPF, then the upper 9 bits of the 627 Multi Topology ID are set to 0. 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Type | Length | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |R R R R| Multi Topology ID | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 12: Multi Topology ID TLV format 639 3.3. The LINK_STATE Attribute 641 This is an optional non-transitive BGP attribute that is used to 642 carry link and node link-state parameters and attributes. It is 643 defined as a set of Type/Length/Value (TLV) triplets, described in 644 the following section. This attribute SHOULD only be included with 645 Link State NLRIs. This attribute MUST be ignored for all other NLRI 646 types. 648 3.3.1. Link Attribute TLVs 650 Each 'Link Attribute' is a Type/Length/Value (TLV) triplet formatted 651 as defined in Section 3.1. The format and semantics of the 'value' 652 fields in some 'Link Attribute' TLVs correspond to the format and 653 semantics of value fields in IS-IS Extended IS Reachability sub-TLVs, 654 defined in [RFC5305] and [RFC5307]. Other 'Link Attribute' TLVs are 655 defined in this document. Although the encodings for 'Link 656 Attribute' TLVs were originally defined for IS-IS, the TLVs can carry 657 data sourced either by IS-IS or OSPF. 659 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 660 attribute: 662 +------+-------------------------+----------------+-----------------+ 663 | Type | Description | IS-IS | Defined in: | 664 | | | TLV/Sub-TLV | | 665 +------+-------------------------+----------------+-----------------+ 666 | 269 | Administrative group | 22/3 | [RFC5305]/3.1 | 667 | | (color) | | | 668 | 270 | Maximum link bandwidth | 22/9 | [RFC5305]/3.3 | 669 | 271 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 670 | | bandwidth | | | 671 | 272 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 672 | 273 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 673 | 274 | MPLS Protocol Mask | --- | Section 3.3.1.1 | 674 | 275 | Metric | --- | Section 3.3.1.2 | 675 | 276 | Shared Risk Link Group | --- | Section 3.3.1.3 | 676 | 277 | OSPF specific link | --- | Section 3.3.1.4 | 677 | | attribute | | | 678 | 278 | IS-IS Specific Link | --- | Section 3.3.1.5 | 679 | | Attribute | | | 680 | 279 | Area ID | --- | Section 3.3.1.6 | 681 +------+-------------------------+----------------+-----------------+ 683 Table 3: Link Attribute TLVs 685 3.3.1.1. MPLS Protocol Mask TLV 687 The MPLS Protocol TLV (Type 274) carries a bit mask describing which 688 MPLS signaling protocols are enabled. The length of this TLV is 1. 689 The value is a bit array of 8 flags, where each bit represents an 690 MPLS Protocol capability. 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Type | Length | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |L R | 698 +-+-+-+-+-+-+-+-+ 700 Figure 13: MPLS Protocol TLV 702 The following bits are defined: 704 +-----+---------------------------------------------+-----------+ 705 | Bit | Description | Reference | 706 +-----+---------------------------------------------+-----------+ 707 | 0 | Label Distribution Protocol (LDP) | [RFC5036] | 708 | 1 | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | 709 | 2-7 | Reserved for future use | | 710 +-----+---------------------------------------------+-----------+ 712 Table 4: MPLS Protocol Mask TLV Codes 714 3.3.1.2. Metric TLV 716 The IGP Metric TLV (Type 275) carries the metric for this link. The 717 length of this TLV is 3. If the length of the metric from which the 718 IGP Metric value is derived is less than 3 (e.g. for OSPF link 719 metrics or non-wide IS-IS metric), then the upper bits of the TLV are 720 set to 0. 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Type | Length | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | IGP Link Metric | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Figure 14: Metric TLV format 732 3.3.1.3. Shared Risk Link Group TLV 734 The Shared Risk Link Group (SRLG) TLV (Type 276) carries the Shared 735 Risk Link Group information (see Section 2.3, "Shared Risk Link Group 736 Information", of [RFC4202]). It contains a data structure consisting 737 of a (variable) list of SRLG values, where each element in the list 738 has 4 octets, as shown in Figure 15. The length of this TLV is 4 * 739 (number of SRLG values). 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Type | Length | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Shared Risk Link Group Value | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | ............ | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Shared Risk Link Group Value | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Figure 15: Shared Risk Link Group TLV format 755 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 756 information is carried in two different TLVs: the IPv4 (SRLG) TLV 757 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 758 defined in [RFC6119]. Since the Link State NLRI uses variable 759 Router-ID anchoring, both IPv4 and IPv6 SRLG information can be 760 carried in a single TLV. 762 3.3.1.4. OSPF Specific Link Attribute TLV 764 The OSPF specific link attribute TLV (Type 277) is an envelope that 765 transparently carries optional link properties TLVs advertised by an 766 OSPF router. The value field contains one or more optional OSPF link 767 attribute TLVs. An originating router shall use this TLV for 768 encoding information specific to the OSPF protocol or new OSPF 769 extensions for which there is no protocol neutral representation in 770 the BGP link-state NLRI. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Type | Length | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | 778 | OSPF specific link attributes (variable) | 779 | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Figure 16: OSPF specific link attribute format 784 3.3.1.5. IS-IS specific link attribute TLV 786 The IS-IS specific link attribute TLV (Type 278) is an envelope that 787 transparently carries optional link properties TLVs advertised by an 788 IS-IS router. The value field contains one or more optional IS-IS 789 link attribute TLVs. An originating router shall use this TLV for 790 encoding information specific to the IS-IS protocol or new IS-IS 791 extensions for which there is no protocol neutral representation in 792 the BGP link-state NLRI. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Length | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | 800 | IS-IS specific link attributes (variable) | 801 | | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 17: IS-IS specific link attribute format 806 3.3.1.6. Link Area TLV 808 The Area TLV (Type 279) carries the Area ID which is assigned on this 809 link. If a link is present in more than one Area then several 810 occurrences of this TLV may be generated. Since only the OSPF 811 protocol carries the notion of link specific areas, the Area ID has a 812 fixed length of 4 octets. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Type | Length | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Area ID | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Figure 18: Link Area TLV format 824 3.3.2. Node Attribute TLVs 826 The following node attribute TLVs are defined: 828 +------+--------------------------------+----------+ 829 | Type | Description | Length | 830 +------+--------------------------------+----------+ 831 | 280 | Multi Topology | 2 | 832 | 281 | Node Flag Bits | 1 | 833 | 282 | OSPF Specific Node Properties | variable | 834 | 283 | IS-IS Specific Node Properties | variable | 835 | 284 | Node Area ID | variable | 836 +------+--------------------------------+----------+ 838 Table 5: Node Attribute TLVs 840 3.3.2.1. Multi Topology Node TLV 842 The Multi Topology TLV (Type 280) carries the Multi Topology ID and 843 topology specific flags for this node. The format and semantics of 844 the 'value' field in the Multi Topology TLV is defined in RFC5120, 845 Section 7.1 [RFC5120]. If the value in the Multi Topology TLV is 846 derived from OSPF, then the upper 9 bits of the Multi Topology ID and 847 the 'O' and 'A' bits are set to 0. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Type | Length | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 |O A R R| Multi Topology ID | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Figure 19: Multi Topology Node TLV format 859 3.3.2.2. Node Flag Bits TLV 861 The Node Flag Bits TLV (Type 281) carries a bit mask describing node 862 attributes. The value is a bit array of 8 flags, where each bit 863 represents an MPLS Protocol capability. 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Type | Length | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Flags | 871 +-+-+-+-+-+-+-+-+ 873 Figure 20: Node Flag Bits TLV format 875 The bits are defined as follows: 877 +-----+--------------+-----------+ 878 | Bit | Description | Reference | 879 +-----+--------------+-----------+ 880 | 0 | Overload Bit | [RFC1195] | 881 | 1 | Attached Bit | [RFC1195] | 882 | 2 | External Bit | [RFC2328] | 883 | 3 | ABR Bit | [RFC2328] | 884 +-----+--------------+-----------+ 886 Table 6: Node Flag Bits Definitions 888 3.3.2.3. OSPF Specific Node Properties TLV 890 The OSPF Specific Node Properties TLV (Type 282) is an envelope that 891 transparently carries optional node properties TLVs advertised by an 892 OSPF router. The value field contains one or more optional OSPF node 893 property TLVs, such as the OSPF Router Informational Capabilities TLV 894 defined in [RFC4970], or the OSPF TE Node Capability Descriptor TLV 895 described in [RFC5073]. An originating router shall use this TLV for 896 encoding information specific to the OSPF protocol or new OSPF 897 extensions for which there is no protocol neutral representation in 898 the BGP link-state NLRI. 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type | Length | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | | 906 | OSPF specific node properties (variable) | 907 | | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Figure 21: OSPF specific Node property format 912 3.3.2.4. IS-IS Specific Node Properties TLV 914 The IS-IS Router Specific Node Properties TLV (Type 283) is an 915 envelope that transparently carries optional node specific TLVs 916 advertised by an IS-IS router. The value field contains one or more 917 optional IS-IS node property TLVs, such as the IS-IS TE Node 918 Capability Descriptor TLV described in [RFC5073]. An originating 919 router shall use this TLV for encoding information specific to the 920 IS-IS protocol or new IS-IS extensions for which there is no protocol 921 neutral representation in the BGP link-state NLRI. 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type | Length | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | | 929 | IS-IS specific node properties (variable) | 930 | | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Figure 22: IS-IS specific Node property format 935 3.3.2.5. Area Node TLV 937 The Area TLV (Type 284) carries the Area ID which is assigned to this 938 node. If a node is present in more than one Area then several 939 occurrences of this TLV may be generated. Since only the IS-IS 940 protocol carries the notion of per-node areas, the Area ID has a 941 variable length of 1 to 20 octets. 943 0 1 2 3 944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Length | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | | 949 | Area ID (variable) | 950 | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Figure 23: Area Node TLV format 955 3.4. Inter-AS Links 957 The main source of TE information is the IGP, which is not active on 958 inter-AS links. In order to inject a non-IGP enabled link into the 959 BGP link-state RIB an implementation must support configuration of 960 static links. 962 4. Link to Path Aggregation 964 Distribution of all links available in the global Internet is 965 certainly possible, however not desirable from a scaling and privacy 966 point of view. Therefore an implementation may support link to path 967 aggregation. Rather than advertising all specific links of a domain, 968 an ASBR may advertise an "aggregate link" between a non-adjacent pair 969 of nodes. The "aggregate link" represents the aggregated set of link 970 properties between a pair of non-adjacent nodes. The actual methods 971 to compute the path properties (of bandwidth, metric) are outside the 972 scope of this document. The decision whether to advertise all 973 specific links or aggregated links is an operator's policy choice. 974 To highlight the varying levels of exposure, the following deployment 975 examples shall be discussed. 977 4.1. Example: No Link Aggregation 979 Consider Figure 24. Both AS1 and AS2 operators want to protect their 980 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 981 compute its link-protection LSP to R3 it needs to "see" an alternate 982 path to R3. Therefore the AS2 operator exposes its topology. All 983 BGP TE enabled routers in AS1 "see" the full topology of AS and 984 therefore can compute a backup path. Note that the decision if the 985 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 986 by the computing router. 988 AS1 : AS2 989 : 990 R1-------R3 991 | : | \ 992 | : | R5 993 | : | / 994 R2-------R4 995 : 996 : 998 Figure 24: no-link-aggregation 1000 4.2. Example: ASBR to ASBR Path Aggregation 1002 The brief difference between the "no-link aggregation" example and 1003 this example is that no specific link gets exposed. Consider 1004 Figure 25. The only link which gets advertised by AS2 is an 1005 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1006 there is a backup path. However the actual links being used are 1007 hidden from the topology. 1009 AS1 : AS2 1010 : 1011 R1-------R3 1012 | : | 1013 | : | 1014 | : | 1015 R2-------R4 1016 : 1017 : 1019 Figure 25: asbr-link-aggregation 1021 4.3. Example: Multi-AS Path Aggregation 1023 Service providers in control of multiple ASes may even decide to not 1024 expose their internal inter-AS links. Consider Figure 26. Rather 1025 than exposing all specific R3 to R6 links, AS3 is modeled as a single 1026 node which connects to the border routers of the aggregated domain. 1028 AS1 : AS2 : AS3 1029 : : 1030 R1-------R3----- 1031 | : : \ 1032 | : : vR0 1033 | : : / 1034 R2-------R4----- 1035 : : 1036 : : 1038 Figure 26: multi-as-aggregation 1040 5. IANA Considerations 1042 This document requests a code point from the registry of Address 1043 Family Numbers. 1045 This document requests a code point from the BGP Path Attributes 1046 registry. 1048 This document requests creation of a new registry for node anchor, 1049 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1050 Values 256-65535 will be used for Codepoints. The registry will be 1051 initialized as shown in Table 2 and Table 3. Allocations within the 1052 registry will require documentation of the proposed use of the 1053 allocated value and approval by the Designated Expert assigned by the 1054 IESG (see [RFC5226]). 1056 Note to RFC Editor: this section may be removed on publication as an 1057 RFC. 1059 6. Manageability Considerations 1061 This section is structured as recommended in [RFC5706]. 1063 6.1. Operational Considerations 1065 6.1.1. Operations 1067 Existing BGP operation procedures apply. No new operation procedures 1068 are defined in this document. It shall be noted that the NLRI 1069 information present in this document purely carries application level 1070 data that have no immediate corresponding forwarding state impact. 1071 As such, any churn in reachability information has different impact 1072 than regular BGP update which needs to chaange forwarding state for 1073 an entire router. Furthermore it is anticipated that distribution of 1074 this NLRI will be handled by dedicated route-reflectors providing a 1075 level of isolation and fault-containment between different NLRI 1076 types. 1078 6.1.2. Installation and Initial Setup 1080 Configuration parameters defined in Section 6.2.3 SHOULD be 1081 initialized to the following default values: 1083 o The Link-State NLRI capability is turned off for all neighbors. 1085 o The maximum rate at which Link State NLRIs will be advertised/ 1086 withdrawn from neighbors is set to 200 updates per second. 1088 6.1.3. Migration Path 1090 The proposed extension is only activated between BGP peers after 1091 capability negotiation. Moreover, the extensions can be turned on/ 1092 off an individual peer basis (see Section 6.2.3), so the extension 1093 can be gradually rolled out in the network. 1095 6.1.4. Requirements on Other Protocols and Functional Components 1097 The protocol extension defined in this document does not put new 1098 requirements on other protocols or functional components. 1100 6.1.5. Impact on Network Operation 1102 Frequency of Link-State NLRI updates could interfere with regular BGP 1103 prefix distribution. A network operator MAY use a dedicated Route- 1104 Reflector infrastructure to distribute Link-State NLRIs. 1106 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1107 domain, which can consist of multiple areas within an AS or multiple 1108 ASes. 1110 6.1.6. Verifying Correct Operation 1112 Existing BGP procedures apply. In addition, an implementation SHOULD 1113 allow an operator to: 1115 o List neighbors with whom the Speaker is exchanging Link-State 1116 NLRIs 1118 6.2. Management Considerations 1120 6.2.1. Management Information 1122 6.2.2. Fault Management 1124 TBD. 1126 6.2.3. Configuration Management 1128 An implementation SHOULD allow the operator to specify neighbors to 1129 which Link-State NLRIs will be advertised and from which Link-State 1130 NLRIs will be accepted. 1132 An implementation SHOULD allow the operator to specify the maximum 1133 rate at which Link State NLRIs will be advertised/withdrawn from 1134 neighbors 1136 An implementation SHOULD allow the operator to specify the maximum 1137 rate at which Link State NLRIs will be accepted from neighbors 1139 An implementation SHOULD allow the operator to specify the maximum 1140 number of Link State NLRIs stored in router's RIB. 1142 An implementation SHOULD allow the operator to create abstracted 1143 topologies that are advertised to neighbors; Create different 1144 abstractions for different neighbors. 1146 6.2.4. Accounting Management 1148 Not Applicable. 1150 6.2.5. Performance Management 1152 An implementation SHOULD provide the following statistics: 1154 o Total number of Link-State NLRI updates sent/received 1156 o Number of Link-State NLRI updates sent/received, per neighbor 1158 o Number of errored received Link-State NLRI updates, per neighbor 1160 o Total number of locally originated Link-State NLRIs 1162 6.2.6. Security Management 1164 An operator SHOULD define ACLs to limit inbound updates as follows: 1166 o Drop all updates from Consumer peers 1168 7. Security Considerations 1170 Procedures and protocol extensions defined in this document do not 1171 affect the BGP security model. 1173 A BGP Speaker SHOULD NOT accept updates from a Consumer peer. 1175 An operator SHOULD employ a mechanism to protect a BGP Speaker 1176 against DDOS attacks from Consumers. 1178 8. Acknowledgements 1180 We would like to thank Nischal Sheth for contributions to this 1181 document. 1183 We would like to thank Alia Atlas, David Ward, Derek Yeung, Murtuza 1184 Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Ginsberg, Liem 1185 Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex Fernando, 1186 Richard Woundy, Robert Varga, Saikat Ray, Steven Luong, Tamas Mondal, 1187 Waqas Alam, and Yakov Rekhter for their comments. 1189 9. References 1190 9.1. Normative References 1192 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1193 dual environments", RFC 1195, December 1990. 1195 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1196 E. Lear, "Address Allocation for Private Internets", 1197 BCP 5, RFC 1918, February 1996. 1199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1200 Requirement Levels", BCP 14, RFC 2119, March 1997. 1202 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1204 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1205 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1206 Tunnels", RFC 3209, December 2001. 1208 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1209 Support of Generalized Multi-Protocol Label Switching 1210 (GMPLS)", RFC 4202, October 2005. 1212 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1213 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1215 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1216 "Multiprotocol Extensions for BGP-4", RFC 4760, 1217 January 2007. 1219 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1220 Number Space", RFC 4893, May 2007. 1222 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1223 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1224 RFC 4915, June 2007. 1226 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1227 Specification", RFC 5036, October 2007. 1229 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 1230 System Confederations for BGP", RFC 5065, August 2007. 1232 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1233 Topology (MT) Routing in Intermediate System to 1234 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1236 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1237 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1238 May 2008. 1240 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1241 Engineering", RFC 5305, October 2008. 1243 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1244 of Generalized Multi-Protocol Label Switching (GMPLS)", 1245 RFC 5307, October 2008. 1247 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1248 Engineering in IS-IS", RFC 6119, February 2011. 1250 9.2. Informative References 1252 [I-D.ietf-alto-protocol] 1253 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1254 draft-ietf-alto-protocol-11 (work in progress), 1255 March 2012. 1257 [I-D.ietf-isis-mi] 1258 Roy, A., Ward, D., Ginsberg, L., Shand, M., and S. 1259 Previdi, "IS-IS Multi-Instance", draft-ietf-isis-mi-06 1260 (work in progress), February 2012. 1262 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1263 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1265 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1266 Shaffer, "Extensions to OSPF for Advertising Optional 1267 Router Capabilities", RFC 4970, July 2007. 1269 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1270 Extensions for Discovery of Traffic Engineering Node 1271 Capabilities", RFC 5073, December 2007. 1273 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1274 Path Computation Method for Establishing Inter-Domain 1275 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1276 RFC 5152, February 2008. 1278 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1279 Optimization (ALTO) Problem Statement", RFC 5693, 1280 October 2009. 1282 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1283 Management of New Protocols and Protocol Extensions", 1284 RFC 5706, November 2009. 1286 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1287 Instance Extensions", RFC 6549, March 2012. 1289 Authors' Addresses 1291 Hannes Gredler 1292 Juniper Networks, Inc. 1293 1194 N. Mathilda Ave. 1294 Sunnyvale, CA 94089 1295 US 1297 Email: hannes@juniper.net 1299 Jan Medved 1300 Cisco Systems, Inc. 1301 170, West Tasman Drive 1302 San Jose, CA 95134 1303 US 1305 Email: jmedved@cisco.com 1307 Stefano Previdi 1308 Cisco Systems, Inc. 1309 Via Del Serafico, 200 1310 Roma 00142 1311 Italy 1313 Email: sprevidi@cisco.com 1315 Adrian Farrel 1316 Juniper Networks, Inc. 1317 1194 N. Mathilda Ave. 1318 Sunnyvale, CA 94089 1319 US 1321 Email: afarrel@juniper.net