idnits 2.17.1 draft-ietf-idr-ls-distribution-00.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 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 (September 19, 2012) is 4236 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 (~~), 6 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: March 21, 2013 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 September 19, 2012 11 North-Bound Distribution of Link-State and TE Information using BGP 12 draft-ietf-idr-ls-distribution-00 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 March 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 5 74 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6 76 3. Carrying Link State Information in BGP . . . . . . . . . . . . 7 77 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.2. The Link State NLRI . . . . . . . . . . . . . . . . . . . 8 79 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . . 10 80 3.2.1.1. Local Node Descriptors . . . . . . . . . . . . . . 11 81 3.2.1.2. Remote Node Descriptors . . . . . . . . . . . . . 11 82 3.2.1.3. Node Descriptor Sub-TLVs . . . . . . . . . . . . . 12 83 3.2.1.4. Router-ID Anchoring Example: ISO Pseudonode . . . 12 84 3.2.1.5. Router-ID Anchoring Example: OSPFv2 to IS-IS 85 Migration . . . . . . . . . . . . . . . . . . . . 13 86 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . . 13 87 3.2.2.1. Multi Topology ID TLV . . . . . . . . . . . . . . 14 88 3.3. The LINK_STATE Attribute . . . . . . . . . . . . . . . . . 14 89 3.3.1. Link Attribute TLVs . . . . . . . . . . . . . . . . . 14 90 3.3.1.1. MPLS Protocol Mask TLV . . . . . . . . . . . . . . 15 91 3.3.1.2. Metric TLV . . . . . . . . . . . . . . . . . . . . 16 92 3.3.1.3. Shared Risk Link Group TLV . . . . . . . . . . . . 16 93 3.3.1.4. OSPF Specific Link Attribute TLV . . . . . . . . . 17 94 3.3.1.5. IS-IS specific link attribute TLV . . . . . . . . 17 95 3.3.1.6. Link Area TLV . . . . . . . . . . . . . . . . . . 18 96 3.3.2. Node Attribute TLVs . . . . . . . . . . . . . . . . . 18 97 3.3.2.1. Multi Topology Node TLV . . . . . . . . . . . . . 18 98 3.3.2.2. Node Flag Bits TLV . . . . . . . . . . . . . . . . 19 99 3.3.2.3. OSPF Specific Node Properties TLV . . . . . . . . 19 100 3.3.2.4. IS-IS Specific Node Properties TLV . . . . . . . . 20 101 3.3.2.5. Area Node TLV . . . . . . . . . . . . . . . . . . 20 102 3.4. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . . 21 103 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . . 21 104 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . . 21 105 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . . 22 106 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . . 22 107 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 108 6. Manageability Considerations . . . . . . . . . . . . . . . . . 23 109 6.1. Operational Considerations . . . . . . . . . . . . . . . . 23 110 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . . 23 111 6.1.2. Installation and Initial Setup . . . . . . . . . . . . 23 112 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . . 23 113 6.1.4. Requirements on Other Protocols and Functional 114 Components . . . . . . . . . . . . . . . . . . . . . . 24 115 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 24 116 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 24 117 6.2. Management Considerations . . . . . . . . . . . . . . . . 24 118 6.2.1. Management Information . . . . . . . . . . . . . . . . 24 119 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . . 24 120 6.2.3. Configuration Management . . . . . . . . . . . . . . . 24 121 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 24 122 6.2.5. Performance Management . . . . . . . . . . . . . . . . 25 123 6.2.6. Security Management . . . . . . . . . . . . . . . . . 25 124 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 125 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 126 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 127 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 128 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 130 1. Introduction 132 The contents of a Link State Database (LSDB) or a Traffic Engineering 133 Database (TED) has the scope of an IGP area. Some applications, such 134 as end-to-end Traffic Engineering (TE), would benefit from visibility 135 outside one area or Autonomous System (AS) in order to make better 136 decisions. 138 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 139 a mechanism for achieving the computation of end-to-end TE paths that 140 cross the visibility of more than one TED or which require CPU- 141 intensive or coordinated computations. The IETF has also defined the 142 ALTO Server [RFC5693] as an entity that generates an abstracted 143 network topology and provides it to network-aware applications. 145 Both a PCE and an ALTO Server need to gather information about the 146 topologies and capabilities of the network in order to be able to 147 fulfill their function 149 This document describes a mechanism by which Link State and TE 150 information can be collected from networks and shared with external 151 components using the BGP routing protocol [RFC4271]. This is 152 achieved using a new BGP Network Layer Reachability Information 153 (NLRI) encoding format. The mechanism is applicable to physical and 154 virtual links. The mechanism described is subject to policy control. 156 A router maintains one or more databases for storing link-state 157 information about nodes and links in any given area. Link attributes 158 stored in these databases include: local/remote IP addresses, local/ 159 remote interface identifiers, link metric and TE metric, link 160 bandwidth, reservable bandwidth, per CoS class reservation state, 161 preemption and Shared Risk Link Groups (SRLG). The router's BGP 162 process can retrieve topology from these LSDBs and distribute it to a 163 consumer, either directly or via a peer BGP Speaker (typically a 164 dedicated Route Reflector), using the encoding specified in this 165 document. 167 The collection of Link State and TE link state information and its 168 distribution to consumers is shown in the following figure. 170 +-----------+ 171 | Consumer | 172 +-----------+ 173 ^ 174 | 175 +-----------+ 176 | BGP | +-----------+ 177 | Speaker | | Consumer | 178 +-----------+ +-----------+ 179 ^ ^ ^ ^ 180 | | | | 181 +---------------+ | +-------------------+ | 182 | | | | 183 +-----------+ +-----------+ +-----------+ 184 | BGP | | BGP | | BGP | 185 | Speaker | | Speaker | . . . | Speaker | 186 +-----------+ +-----------+ +-----------+ 187 ^ ^ ^ 188 | | | 189 IGP IGP IGP 191 Figure 1: TE Link State info collection 193 A BGP Speaker may apply configurable policy to the information that 194 it distributes. Thus, it may distribute the real physical topology 195 from the LSDB or the TED. Alternatively, it may create an abstracted 196 topology, where virtual, aggregated nodes are connected by virtual 197 paths. Aggregated nodes can be created, for example, out of multiple 198 routers in a POP. Abstracted topology can also be a mix of physical 199 and virtual nodes and physical and virtual links. Furthermore, the 200 BGP Speaker can apply policy to determine when information is updated 201 to the consumer so that there is reduction of information flow form 202 the network to the consumers. Mechanisms through which topologies 203 can be aggregated or virtualized are outside the scope of this 204 document 206 2. Motivation and Applicability 208 This section describes uses cases from which the requirements can be 209 derived. 211 2.1. MPLS-TE with PCE 213 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 214 within a "domain" (such as an IGP area) or across multiple domains 215 (such as a multi-area AS, or multiple ASes). 217 o Within a single area, the PCE offers enhanced computational power 218 that may not be available on individual routers, sophisticated 219 policy control and algorithms, and coordination of computation 220 across the whole area. 222 o If a router wants to compute a MPLS-TE path across IGP areas its 223 own TED lacks visibility of the complete topology. That means 224 that the router cannot determine the end-to-end path, and cannot 225 even select the right exit router (Area Border Router - ABR) for 226 an optimal path. This is an issue for large-scale networks that 227 need to segment their core networks into distinct areas, but which 228 still want to take advantage of MPLS-TE. 230 Previous solutions used per-domain path computation [RFC5152]. The 231 source router could only compute the path for the first area because 232 the router only has full topological visibility for the first area 233 along the path, but not for subsequent areas. Per-domain path 234 computation uses a technique called "loose-hop-expansion" [RFC3209], 235 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 236 using the IGP computed shortest path topology for the remainder of 237 the path. This may lead to sub-optimal paths, makes alternate/back- 238 up path computation hard, and might result in no TE path being found 239 when one really does exist. 241 The PCE presents a computation server that may have visibility into 242 more than one IGP area or AS, or may cooperate with other PCEs to 243 perform distributed path computation. The PCE obviously needs access 244 to the TED for the area(s) it serves, but [RFC4655] does not describe 245 how this is achieved. Many implementations make the PCE a passive 246 participant in the IGP so that it can learn the latest state of the 247 network, but this may be sub-optimal when the network is subject to a 248 high degree of churn, or when the PCE is responsible for multiple 249 areas. 251 The following figure shows how a PCE can get its TED information 252 using the mechanism described in this document. 254 +----------+ +---------+ 255 | ----- | | BGP | 256 | | TED |<-+-------------------------->| Speaker | 257 | ----- | TED synchronization | | 258 | | | mechanism: +---------+ 259 | | | BGP with Link-State NLRI 260 | v | 261 | ----- | 262 | | PCE | | 263 | ----- | 264 +----------+ 265 ^ 266 | Request/ 267 | Response 268 v 269 Service +----------+ Signaling +----------+ 270 Request | Head-End | Protocol | Adjacent | 271 -------->| Node |<------------>| Node | 272 +----------+ +----------+ 274 Figure 2: External PCE node using a TED synchronization mechanism 276 The mechanism in this document allows the necessary TED information 277 to be collected from the IGP within the network, filtered according 278 to configurable policy, and distributed to the PCE as necessary. 280 2.2. ALTO Server Network API 282 An ALTO Server [RFC5693] is an entity that generates an abstracted 283 network topology and provides it to network-aware applications over a 284 web service based API. Example applications are p2p clients or 285 trackers, or CDNs. The abstracted network topology comes in the form 286 of two maps: a Network Map that specifies allocation of prefixes to 287 PIDs, and a Cost Map that specifies the cost between PIDs listed in 288 the Network Map. For more details, see [I-D.ietf-alto-protocol]. 290 ALTO abstract network topologies can be auto-generated from the 291 physical topology of the underlying network. The generation would 292 typically be based on policies and rules set by the operator. Both 293 prefix and TE data are required: prefix data is required to generate 294 ALTO Network Maps, TE (topology) data is required to generate ALTO 295 Cost Maps. Prefix data is carried and originated in BGP, TE data is 296 originated and carried in an IGP. The mechanism defined in this 297 document provides a single interface through which an ALTO Server can 298 retrieve all the necessary prefix and network topology data from the 299 underlying network. Note an ALTO Server can use other mechanisms to 300 get network data, for example, peering with multiple IGP and BGP 301 Speakers. 303 The following figure shows how an ALTO Server can get network 304 topology information from the underlying network using the mechanism 305 described in this document. 307 +--------+ 308 | Client |<--+ 309 +--------+ | 310 | ALTO +--------+ BGP with +---------+ 311 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 312 | Client |<--+------------| Server |<----------------| Speaker | 313 +--------+ | | | | | 314 | +--------+ +---------+ 315 +--------+ | 316 | Client |<--+ 317 +--------+ 319 Figure 3: ALTO Server using network topology information 321 3. Carrying Link State Information in BGP 323 Two parts: a new BGP NLRI that describes links and nodes comprising 324 IGP link state information, and a new BGP path attribute that carries 325 link and node properties and attributes, such as the link metric or 326 node properties. 328 3.1. TLV Format 330 Information in the new link state NLRIs and attributes is encoded in 331 Type/Length/Value triplets. The TLV format is shown in Figure 4. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | Value (variable) | 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4: TLV format 345 The Length field defines the length of the value portion in octets 346 (thus a TLV with no value portion would have a length of zero). The 347 TLV is not padded to four-octet alignment; Unrecognized types are 348 ignored. 350 3.2. The Link State NLRI 352 The MP_REACH and MP_UNREACH attributes are BGP's containers for 353 carrying opaque information. Each Link State NLRI describes either a 354 single node or link. 356 All link and node information SHALL be encoded using a TBD AFI / SAFI 357 1 or SAFI 128 header into those attributes. SAFI 1 SHALL be used for 358 Internet routing (Public) and SAFI 128 SHALL be used for VPN routing 359 (Private) applications. 361 In order for two BGP speakers to exchange Link-State NLRI, they MUST 362 use BGP Capabilities Advertisement to ensure that they both are 363 capable of properly processing such NLRI. This is done as specified 364 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 365 an AFI of TBD and an SAFI of 1 or 128. 367 The format of the Link State NLRI is shown in the following figure. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | NLRI Type | Total NLRI Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 | Link-State NLRI (variable) | 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 5: Link State SAFI 1 NLRI Format 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 + Route Distinguisher + 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 | Link-State NLRI (variable) | 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 6: Link State SAFI 128 NLRI Format 397 The 'Total NLRI Length' field contains the cumulative length of all 398 the TLVs in the NLRI. For VPN applications it also includes the 399 length of the Route Distinguisher. 401 The 'NLRI Type' field can contain one of the following values: 403 Type = 1: Link NLRI, contains link descriptors and link attributes 405 Type = 2: Node NLRI, contains node attributes 407 The Link NLRI (NLRI Type = 1) is shown in the following figure. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Protocol-ID | Reserved | Instance Identifier | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Local Node Descriptors (variable) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Remote Node Descriptors (variable) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Link Descriptors (variable) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 7: The Link NLRI format 423 The Node NLRI (NLRI Type = 2) is shown in the following figure. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Protocol-ID | Reserved | Instance Identifier | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Local Node Descriptors (variable) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 8: The Node NLRI format 435 The 'Protocol-ID' field can contain one of the following values: 437 Type = 0: Unknown, The source of NLRI information could not be 438 determined 440 Type = 1: IS-IS Level 1, The NLRI information has been sourced by 441 IS-IS Level 1 443 Type = 2: IS-IS Level 2, The NLRI information has been sourced by 444 IS-IS Level 2 446 Type = 3: OSPF, The NLRI information has been sourced by OSPF 448 Type = 4: Direct, The NLRI information has been sourced from local 449 interface state 451 Type = 5: Static, The NLRI information has been sourced by static 452 configuration 454 Both OSPF and IS-IS may run multiple routing protocol instances over 455 the same link. See [I-D.ietf-isis-mi] and [RFC6549]. The 'Instance 456 Identifier' field identifies the protocol instance. 458 Each Node Descriptor and Link Descriptor consists of one or more TLVs 459 described in the following sections. The sender of an UPDATE message 460 MUST order the TLVs within a Node Descriptor or a Link Descriptor in 461 ascending order of TLV type." 463 3.2.1. Node Descriptors 465 Each link gets anchored by at least a pair of router-IDs. Since 466 there are many Router-IDs formats (32 Bit IPv4 router-ID, 56 Bit ISO 467 Node-ID and 128 Bit IPv6 router-ID) a link may be anchored by more 468 than one Router-ID pair. The set of Local and Remote Node 469 Descriptors describe which Protocols Router-IDs will be following to 470 "anchor" the link described by the "Link attribute TLVs". There must 471 be at least one "like" router-ID pair of a Local Node Descriptors and 472 a Remote Node Descriptors per-protocol. If a peer sends an illegal 473 combination in this respect, then this is handled as an NLRI error, 474 described in [RFC4760]. 476 It is desirable that the Router-ID assignments inside the Node anchor 477 are globally unique. However there may be router-ID spaces (e.g. 478 ISO) where not even a global registry exists, or worse, Router-IDs 479 have been allocated following private-IP RFC 1918 [RFC1918] 480 allocation. In order to disambiguate the Router-IDs the local and 481 remote Autonomous System number TLVs of the anchor nodes may be 482 included in the NLRI. If the anchor node's AS is a member of an AS 483 Confederation ([RFC5065]), then the Autonomous System number TLVs 484 contains the confederations' AS Confederation Identifier and the 485 Member-AS TLV is included in the NLRI. The Local and Remote 486 Autonomous System TLVs are 4 octets wide as described in [RFC4893]. 487 2-octet AS Numbers SHALL be expanded to 4-octet AS Numbers by zeroing 488 the two MSB octets. 490 3.2.1.1. Local Node Descriptors 492 The Local Node Descriptors TLV (Type 256) contains Node Descriptors 493 for the node anchoring the local end of the link. The length of this 494 TLV is variable. The value contains one or more Node Descriptor Sub- 495 TLVs defined in Section 3.2.1.3. 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type | Length | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | 503 | Node Descriptor Sub-TLVs (variable) | 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 9: Local Node Descriptors TLV format 509 3.2.1.2. Remote Node Descriptors 511 The Remote Node Descriptors TLV (Type 257) contains Node Descriptors 512 for the node anchoring the remote end of the link. The length of 513 this TLV is variable. The value contains one or more Node Descriptor 514 Sub-TLVs defined in Section 3.2.1.3. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | | 522 | Node Descriptor Sub-TLVs (variable) | 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 10: Remote Node Descriptors TLV format 528 3.2.1.3. Node Descriptor Sub-TLVs 530 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 531 the following table: 533 +------+-------------------+--------+ 534 | Type | Description | Length | 535 +------+-------------------+--------+ 536 | 258 | Autonomous System | 4 | 537 | 259 | Member-AS | 4 | 538 | 260 | IPv4 Router-ID | 5 | 539 | 261 | IPv6 Router-ID | 17 | 540 | 262 | ISO Node-ID | 7 | 541 +------+-------------------+--------+ 543 Table 1: Node Descriptor Sub-TLVs 545 The TLV values in Node Descriptor Sub-TLVs are defined as follows: 547 Autonomous System: opaque value (32 Bit AS ID) 549 Member-AS: opaque value (32 Bit AS ID); only included if the node is 550 in an AS confederation. 552 IPv4 Router ID: opaque value (can be an IPv4 address or an 32 Bit 553 router ID) followed by a LAN-ID octet in case LAN "Pseudonode" 554 information gets advertised. The PSN octet must be zero for non- 555 LAN "Pseudonodes". 557 IPv6 Router ID: opaque value (can be an IPv6 address or 128 Bit 558 router ID) followed by a LAN-ID octet in case LAN "Pseudonode" 559 information gets advertised. The PSN octet must be zero for non- 560 LAN "Pseudonodes". 562 ISO Node ID: ISO node-ID (6 octets ISO system-ID) followed by a PSN 563 octet in case LAN "Pseudonode" information gets advertised. The 564 PSN octet must be zero for non-LAN "Pseudonodes". 566 3.2.1.4. Router-ID Anchoring Example: ISO Pseudonode 568 IS-IS Pseudonodes are a good example for the variable Router-ID 569 anchoring. Consider Figure 11. This represents a Broadcast LAN 570 between a pair of routers. The "real" (=non pseudonode) routers have 571 both an IPv4 Router-ID and IS-IS Node-ID. The pseudonode does not 572 have an IPv4 Router-ID. Two unidirectional links (Node1, Pseudonode 573 1) and (Pseudonode 1, Node 2) are being generated. 575 The NRLI for (Node1, Pseudonode1) encodes local IPv4 router-ID, local 576 ISO node-ID and remote ISO node-id) 578 The NLRI for (Pseudonode1, Node2) encodes a local ISO node-ID, remote 579 IPv4 router-ID and remote ISO node-id. 581 +-----------------+ +-----------------+ +-----------------+ 582 | Node1 | | Pseudonode 1 | | Node2 | 583 |1921.6800.1001.00|--->|1921.6800.1001.02|--->|1921.6800.1002.00| 584 | 192.168.1.1 | | | | 192.168.1.2 | 585 +-----------------+ +-----------------+ +-----------------+ 587 Figure 11: IS-IS Pseudonodes 589 3.2.1.5. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 591 Migrating gracefully from one IGP to another requires congruent 592 operation of both routing protocols during the migration period. The 593 target protocol (IS-IS) supports more router-ID spaces than the 594 source (OSPFv2) protocol. When advertising a point-to-point link 595 between an OSPFv2-only router and an OSPFv2 and IS-IS enabled router 596 the following link information may be generated. Note that the IS-IS 597 router also supports the IPv6 traffic engineering extensions RFC 6119 598 [RFC6119] for IS-IS. 600 The NRLI encodes local IPv4 router-id, remote IPv4 router-id, remote 601 ISO node-id and remote IPv6 node-id. 603 3.2.2. Link Descriptors 605 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 606 triplets. The format of each TLV is shown in Section 3.1. The 'Link 607 descriptor' TLVs uniquely identify a link between a pair of anchor 608 Routers. A link described by the Link descriptor TLVs actually is a 609 "half-link", a unidirectional representation of a logical link. In 610 order to fully describe a single logical link two originating routers 611 need to advertise a half-link each, i.e. two link NLRIs will be 612 advertised. 614 The format and semantics of the 'value' fields in most 'Link 615 Descriptor' TLVs correspond to the format and semantics of value 616 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 617 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 618 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 619 carry data sourced either by IS-IS or OSPF. 621 The following link descriptor TLVs are valid in the Link NLRI: 623 +--------+--------------------+-----------------+-------------------+ 624 | Type | Description | IS-IS TLV/Sub- | Value defined in: | 625 | | | TLV | | 626 +--------+--------------------+-----------------+-------------------+ 627 | 263 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 628 | | Identifiers | | | 629 | 264 | IPv4 interface | 22/6 | [RFC5305]/3.2 | 630 | | address | | | 631 | 265 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | 632 | | address | | | 633 | 266 | IPv6 interface | 22/12 | [RFC6119]/4.2 | 634 | | address | | | 635 | 267 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | 636 | | address | | | 637 | 268 | Multi Topology ID | --- | Section 3.2.2.1 | 638 +--------+--------------------+-----------------+-------------------+ 640 Table 2: Link Descriptor TLVs 642 3.2.2.1. Multi Topology ID TLV 644 The Multi Topology ID TLV (Type 268) carries the Multi Topology ID 645 for this link. The semantics of the Multi Topology ID are defined in 646 RFC5120, Section 7.2 [RFC5120], and the OSPF Multi Topology ID), 647 defined in RFC4915, Section 3.7 [RFC4915]. If the value in the Multi 648 Topology ID TLV is derived from OSPF, then the upper 9 bits of the 649 Multi Topology ID are set to 0. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |R R R R| Multi Topology ID | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Figure 12: Multi Topology ID TLV format 661 3.3. The LINK_STATE Attribute 663 This is an optional non-transitive BGP attribute that is used to 664 carry link and node link-state parameters and attributes. It is 665 defined as a set of Type/Length/Value (TLV) triplets, described in 666 the following section. This attribute SHOULD only be included with 667 Link State NLRIs. This attribute MUST be ignored for all other NLRI 668 types. 670 3.3.1. Link Attribute TLVs 671 Each 'Link Attribute' is a Type/Length/Value (TLV) triplet formatted 672 as defined in Section 3.1. The format and semantics of the 'value' 673 fields in some 'Link Attribute' TLVs correspond to the format and 674 semantics of value fields in IS-IS Extended IS Reachability sub-TLVs, 675 defined in [RFC5305] and [RFC5307]. Other 'Link Attribute' TLVs are 676 defined in this document. Although the encodings for 'Link 677 Attribute' TLVs were originally defined for IS-IS, the TLVs can carry 678 data sourced either by IS-IS or OSPF. 680 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 681 attribute: 683 +------+----------------------+-----------------+-------------------+ 684 | Type | Description | IS-IS TLV/Sub- | Defined in: | 685 | | | TLV | | 686 +------+----------------------+-----------------+-------------------+ 687 | 269 | Administrative group | 22/3 | [RFC5305]/3.1 | 688 | | (color) | | | 689 | 270 | Maximum link | 22/9 | [RFC5305]/3.3 | 690 | | bandwidth | | | 691 | 271 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 692 | | bandwidth | | | 693 | 272 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 694 | 273 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 695 | 274 | MPLS Protocol Mask | --- | Section 3.3.1.1 | 696 | 275 | Metric | --- | Section 3.3.1.2 | 697 | 276 | Shared Risk Link | --- | Section 3.3.1.3 | 698 | | Group | | | 699 | 277 | OSPF specific link | --- | Section 3.3.1.4 | 700 | | attribute | | | 701 | 278 | IS-IS Specific Link | --- | Section 3.3.1.5 | 702 | | Attribute | | | 703 | 279 | Area ID | --- | Section 3.3.1.6 | 704 +------+----------------------+-----------------+-------------------+ 706 Table 3: Link Attribute TLVs 708 3.3.1.1. MPLS Protocol Mask TLV 710 The MPLS Protocol TLV (Type 274) carries a bit mask describing which 711 MPLS signaling protocols are enabled. The length of this TLV is 1. 712 The value is a bit array of 8 flags, where each bit represents an 713 MPLS Protocol capability. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 |L R | 721 +-+-+-+-+-+-+-+-+ 723 Figure 13: MPLS Protocol TLV 725 The following bits are defined: 727 +-----+---------------------------------------------+-----------+ 728 | Bit | Description | Reference | 729 +-----+---------------------------------------------+-----------+ 730 | 0 | Label Distribution Protocol (LDP) | [RFC5036] | 731 | 1 | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | 732 | 2-7 | Reserved for future use | | 733 +-----+---------------------------------------------+-----------+ 735 Table 4: MPLS Protocol Mask TLV Codes 737 3.3.1.2. Metric TLV 739 The IGP Metric TLV (Type 275) carries the metric for this link. The 740 length of this TLV is 3. If the length of the metric from which the 741 IGP Metric value is derived is less than 3 (e.g. for OSPF link 742 metrics or non-wide IS-IS metric), then the upper bits of the TLV are 743 set to 0. 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Type | Length | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | IGP Link Metric | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Figure 14: Metric TLV format 755 3.3.1.3. Shared Risk Link Group TLV 757 The Shared Risk Link Group (SRLG) TLV (Type 276) carries the Shared 758 Risk Link Group information (see Section 2.3, "Shared Risk Link Group 759 Information", of [RFC4202]). It contains a data structure consisting 760 of a (variable) list of SRLG values, where each element in the list 761 has 4 octets, as shown in Figure 15. The length of this TLV is 4 * 762 (number of SRLG values). 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Type | Length | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Shared Risk Link Group Value | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | ............ | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Shared Risk Link Group Value | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Figure 15: Shared Risk Link Group TLV format 778 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 779 information is carried in two different TLVs: the IPv4 (SRLG) TLV 780 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 781 defined in [RFC6119]. Since the Link State NLRI uses variable 782 Router-ID anchoring, both IPv4 and IPv6 SRLG information can be 783 carried in a single TLV. 785 3.3.1.4. OSPF Specific Link Attribute TLV 787 The OSPF specific link attribute TLV (Type 277) is an envelope that 788 transparently carries optional link properties TLVs advertised by an 789 OSPF router. The value field contains one or more optional OSPF link 790 attribute TLVs. An originating router shall use this TLV for 791 encoding information specific to the OSPF protocol or new OSPF 792 extensions for which there is no protocol neutral representation in 793 the BGP link-state NLRI. 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type | Length | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | | 801 | OSPF specific link attributes (variable) | 802 | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 16: OSPF specific link attribute format 807 3.3.1.5. IS-IS specific link attribute TLV 809 The IS-IS specific link attribute TLV (Type 278) is an envelope that 810 transparently carries optional link properties TLVs advertised by an 811 IS-IS router. The value field contains one or more optional IS-IS 812 link attribute TLVs. An originating router shall use this TLV for 813 encoding information specific to the IS-IS protocol or new IS-IS 814 extensions for which there is no protocol neutral representation in 815 the BGP link-state NLRI. 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Type | Length | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 | IS-IS specific link attributes (variable) | 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Figure 17: IS-IS specific link attribute format 829 3.3.1.6. Link Area TLV 831 The Area TLV (Type 279) carries the Area ID which is assigned on this 832 link. If a link is present in more than one Area then several 833 occurrences of this TLV may be generated. Since only the OSPF 834 protocol carries the notion of link specific areas, the Area ID has a 835 fixed length of 4 octets. 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Type | Length | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Area ID | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 Figure 18: Link Area TLV format 847 3.3.2. Node Attribute TLVs 849 The following node attribute TLVs are defined: 851 +------+--------------------------------+----------+ 852 | Type | Description | Length | 853 +------+--------------------------------+----------+ 854 | 280 | Multi Topology | 2 | 855 | 281 | Node Flag Bits | 1 | 856 | 282 | OSPF Specific Node Properties | variable | 857 | 283 | IS-IS Specific Node Properties | variable | 858 | 284 | Node Area ID | variable | 859 +------+--------------------------------+----------+ 861 Table 5: Node Attribute TLVs 863 3.3.2.1. Multi Topology Node TLV 865 The Multi Topology TLV (Type 280) carries the Multi Topology ID and 866 topology specific flags for this node. The format and semantics of 867 the 'value' field in the Multi Topology TLV is defined in RFC5120, 868 Section 7.1 [RFC5120]. If the value in the Multi Topology TLV is 869 derived from OSPF, then the upper 9 bits of the Multi Topology ID and 870 the 'O' and 'A' bits are set to 0. 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Type | Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 |O A R R| Multi Topology ID | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Figure 19: Multi Topology Node TLV format 882 3.3.2.2. Node Flag Bits TLV 884 The Node Flag Bits TLV (Type 281) carries a bit mask describing node 885 attributes. The value is a bit array of 8 flags, where each bit 886 represents an MPLS Protocol capability. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Type | Length | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Flags | 894 +-+-+-+-+-+-+-+-+ 896 Figure 20: Node Flag Bits TLV format 898 The bits are defined as follows: 900 +-----+--------------+-----------+ 901 | Bit | Description | Reference | 902 +-----+--------------+-----------+ 903 | 0 | Overload Bit | [RFC1195] | 904 | 1 | Attached Bit | [RFC1195] | 905 | 2 | External Bit | [RFC2328] | 906 | 3 | ABR Bit | [RFC2328] | 907 +-----+--------------+-----------+ 909 Table 6: Node Flag Bits Definitions 911 3.3.2.3. OSPF Specific Node Properties TLV 913 The OSPF Specific Node Properties TLV (Type 282) is an envelope that 914 transparently carries optional node properties TLVs advertised by an 915 OSPF router. The value field contains one or more optional OSPF node 916 property TLVs, such as the OSPF Router Informational Capabilities TLV 917 defined in [RFC4970], or the OSPF TE Node Capability Descriptor TLV 918 described in [RFC5073]. An originating router shall use this TLV for 919 encoding information specific to the OSPF protocol or new OSPF 920 extensions for which there is no protocol neutral representation in 921 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 | OSPF specific node properties (variable) | 930 | | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Figure 21: OSPF specific Node property format 935 3.3.2.4. IS-IS Specific Node Properties TLV 937 The IS-IS Router Specific Node Properties TLV (Type 283) is an 938 envelope that transparently carries optional node specific TLVs 939 advertised by an IS-IS router. The value field contains one or more 940 optional IS-IS node property TLVs, such as the IS-IS TE Node 941 Capability Descriptor TLV described in [RFC5073]. An originating 942 router shall use this TLV for encoding information specific to the 943 IS-IS protocol or new IS-IS extensions for which there is no protocol 944 neutral representation in the BGP link-state NLRI. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Type | Length | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | | 952 | IS-IS specific node properties (variable) | 953 | | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Figure 22: IS-IS specific Node property format 958 3.3.2.5. Area Node TLV 960 The Area TLV (Type 284) carries the Area ID which is assigned to this 961 node. If a node is present in more than one Area then several 962 occurrences of this TLV may be generated. Since only the IS-IS 963 protocol carries the notion of per-node areas, the Area ID has a 964 variable length of 1 to 20 octets. 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Type | Length | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | | 972 | Area ID (variable) | 973 | | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 Figure 23: Area Node TLV format 978 3.4. Inter-AS Links 980 The main source of TE information is the IGP, which is not active on 981 inter-AS links. In order to inject a non-IGP enabled link into the 982 BGP link-state RIB an implementation must support configuration of 983 static links. 985 4. Link to Path Aggregation 987 Distribution of all links available in the global Internet is 988 certainly possible, however not desirable from a scaling and privacy 989 point of view. Therefore an implementation may support link to path 990 aggregation. Rather than advertising all specific links of a domain, 991 an ASBR may advertise an "aggregate link" between a non-adjacent pair 992 of nodes. The "aggregate link" represents the aggregated set of link 993 properties between a pair of non-adjacent nodes. The actual methods 994 to compute the path properties (of bandwidth, metric) are outside the 995 scope of this document. The decision whether to advertise all 996 specific links or aggregated links is an operator's policy choice. 997 To highlight the varying levels of exposure, the following deployment 998 examples shall be discussed. 1000 4.1. Example: No Link Aggregation 1002 Consider Figure 24. Both AS1 and AS2 operators want to protect their 1003 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1004 compute its link-protection LSP to R3 it needs to "see" an alternate 1005 path to R3. Therefore the AS2 operator exposes its topology. All BGP 1006 TE enabled routers in AS1 "see" the full topology of AS and therefore 1007 can compute a backup path. Note that the decision if the direct link 1008 between {R3, R4} or the {R4, R5, R3) path is used is made by the 1009 computing router. 1011 AS1 : AS2 1012 : 1013 R1-------R3 1014 | : | \ 1015 | : | R5 1016 | : | / 1017 R2-------R4 1018 : 1019 : 1021 Figure 24: no-link-aggregation 1023 4.2. Example: ASBR to ASBR Path Aggregation 1025 The brief difference between the "no-link aggregation" example and 1026 this example is that no specific link gets exposed. Consider Figure 1027 25. The only link which gets advertised by AS2 is an "aggregate" link 1028 between R3 and R4. This is enough to tell AS1 that there is a backup 1029 path. However the actual links being used are hidden from the 1030 topology. 1032 AS1 : AS2 1033 : 1034 R1-------R3 1035 | : | 1036 | : | 1037 | : | 1038 R2-------R4 1039 : 1040 : 1042 Figure 25: asbr-link-aggregation 1044 4.3. Example: Multi-AS Path Aggregation 1046 Service providers in control of multiple ASes may even decide to not 1047 expose their internal inter-AS links. Consider Figure 26. Rather 1048 than exposing all specific R3 to R6 links, AS3 is modeled as a single 1049 node which connects to the border routers of the aggregated domain. 1051 AS1 : AS2 : AS3 1052 : : 1053 R1-------R3----- 1054 | : : \ 1055 | : : vR0 1056 | : : / 1057 R2-------R4----- 1058 : : 1059 : : 1061 Figure 26: multi-as-aggregation 1063 5. IANA Considerations 1064 This document requests a code point from the registry of Address 1065 Family Numbers. 1067 This document requests a code point from the BGP Path Attributes 1068 registry. 1070 This document requests creation of a new registry for node anchor, 1071 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1072 Values 256-65535 will be used for Codepoints. The registry will be 1073 initialized as shown in Table 2 and Table 3. Allocations within the 1074 registry will require documentation of the proposed use of the 1075 allocated value and approval by the Designated Expert assigned by the 1076 IESG (see [RFC5226]). 1078 Note to RFC Editor: this section may be removed on publication as an 1079 RFC. 1081 6. Manageability Considerations 1083 This section is structured as recommended in [RFC5706]. 1085 6.1. Operational Considerations 1087 6.1.1. Operations 1089 Existing BGP operation procedures apply. No new operation procedures 1090 are defined in this document. It shall be noted that the NLRI 1091 information present in this document purely carries application level 1092 data that have no immediate corresponding forwarding state impact. 1093 As such, any churn in reachability information has different impact 1094 than regular BGP update which needs to chaange forwarding state for 1095 an entire router. Furthermore it is anticipated that distribution of 1096 this NLRI will be handled by dedicated route-reflectors providing a 1097 level of isolation and fault-containment between different NLRI 1098 types. 1100 6.1.2. Installation and Initial Setup 1102 Configuration parameters defined in Section 6.2.3 SHOULD be 1103 initialized to the following default values: 1105 o The Link-State NLRI capability is turned off for all neighbors. 1107 o The maximum rate at which Link State NLRIs will be advertised/ 1108 withdrawn from neighbors is set to 200 updates per second. 1110 6.1.3. Migration Path 1112 The proposed extension is only activated between BGP peers after 1113 capability negotiation. Moreover, the extensions can be turned on/ 1114 off an individual peer basis (see Section 6.2.3), so the extension 1115 can be gradually rolled out in the network. 1117 6.1.4. Requirements on Other Protocols and Functional Components 1119 The protocol extension defined in this document does not put new 1120 requirements on other protocols or functional components. 1122 6.1.5. Impact on Network Operation 1124 Frequency of Link-State NLRI updates could interfere with regular BGP 1125 prefix distribution. A network operator MAY use a dedicated Route- 1126 Reflector infrastructure to distribute Link-State NLRIs. 1128 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1129 domain, which can consist of multiple areas within an AS or multiple 1130 ASes. 1132 6.1.6. Verifying Correct Operation 1134 Existing BGP procedures apply. In addition, an implementation SHOULD 1135 allow an operator to: 1137 o List neighbors with whom the Speaker is exchanging Link-State 1138 NLRIs 1140 6.2. Management Considerations 1142 6.2.1. Management Information 1144 6.2.2. Fault Management 1146 TBD. 1148 6.2.3. Configuration Management 1150 An implementation SHOULD allow the operator to specify neighbors to 1151 which Link-State NLRIs will be advertised and from which Link-State 1152 NLRIs will be accepted. 1154 An implementation SHOULD allow the operator to specify the maximum 1155 rate at which Link State NLRIs will be advertised/withdrawn from 1156 neighbors 1158 An implementation SHOULD allow the operator to specify the maximum 1159 rate at which Link State NLRIs will be accepted from neighbors 1161 An implementation SHOULD allow the operator to specify the maximum 1162 number of Link State NLRIs stored in router's RIB. 1164 An implementation SHOULD allow the operator to create abstracted 1165 topologies that are advertised to neighbors; Create different 1166 abstractions for different neighbors. 1168 6.2.4. Accounting Management 1169 Not Applicable. 1171 6.2.5. Performance Management 1173 An implementation SHOULD provide the following statistics: 1175 o Total number of Link-State NLRI updates sent/received 1177 o Number of Link-State NLRI updates sent/received, per neighbor 1179 o Number of errored received Link-State NLRI updates, per neighbor 1181 o Total number of locally originated Link-State NLRIs 1183 6.2.6. Security Management 1185 An operator SHOULD define ACLs to limit inbound updates as follows: 1187 o Drop all updates from Consumer peers 1189 7. Security Considerations 1191 Procedures and protocol extensions defined in this document do not 1192 affect the BGP security model. 1194 A BGP Speaker SHOULD NOT accept updates from a Consumer peer. 1196 An operator SHOULD employ a mechanism to protect a BGP Speaker 1197 against DDOS attacks from Consumers. 1199 8. Acknowledgements 1201 We would like to thank Nischal Sheth for contributions to this 1202 document. 1204 We would like to thank Alia Atlas, David Ward, Derek Yeung, Murtuza 1205 Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Ginsberg, Liem 1206 Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex Fernando, 1207 Richard Woundy, Robert Varga, Saikat Ray, Steven Luong, Tamas Mondal, 1208 Waqas Alam, and Yakov Rekhter for their comments. 1210 9. References 1212 9.1. Normative References 1214 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1215 dual environments", RFC 1195, December 1990. 1217 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1218 E. Lear, "Address Allocation for Private Internets", BCP 1219 5, RFC 1918, February 1996. 1221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1222 Requirement Levels", BCP 14, RFC 2119, March 1997. 1224 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1226 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1227 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1228 Tunnels", RFC 3209, December 2001. 1230 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1231 Support of Generalized Multi-Protocol Label Switching 1232 (GMPLS)", RFC 4202, October 2005. 1234 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1235 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1237 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1238 "Multiprotocol Extensions for BGP-4", RFC 4760, January 1239 2007. 1241 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1242 Number Space", RFC 4893, May 2007. 1244 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1245 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1246 4915, June 2007. 1248 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1249 Specification", RFC 5036, October 2007. 1251 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 1252 System Confederations for BGP", RFC 5065, August 2007. 1254 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1255 Topology (MT) Routing in Intermediate System to 1256 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1258 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1259 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1260 May 2008. 1262 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1263 Engineering", RFC 5305, October 2008. 1265 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1266 of Generalized Multi-Protocol Label Switching (GMPLS)", 1267 RFC 5307, October 2008. 1269 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1270 Engineering in IS-IS", RFC 6119, February 2011. 1272 9.2. Informative References 1274 [I-D.ietf-alto-protocol] 1275 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1276 Internet-Draft draft-ietf-alto-protocol-11, March 2012. 1278 [I-D.ietf-isis-mi] 1279 Roy, A., Ward, D., Ginsberg, L., Shand, M., and S. 1280 Previdi, "IS-IS Multi-Instance", Internet-Draft draft- 1281 ietf-isis-mi-06, February 2012. 1283 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1284 Computation Element (PCE)-Based Architecture", RFC 4655, 1285 August 2006. 1287 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1288 Shaffer, "Extensions to OSPF for Advertising Optional 1289 Router Capabilities", RFC 4970, July 2007. 1291 [RFC5073] Vasseur, J.P. and J.L. Le Roux, "IGP Routing Protocol 1292 Extensions for Discovery of Traffic Engineering Node 1293 Capabilities", RFC 5073, December 2007. 1295 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1296 Path Computation Method for Establishing Inter-Domain 1297 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 1298 5152, February 2008. 1300 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1301 Optimization (ALTO) Problem Statement", RFC 5693, October 1302 2009. 1304 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1305 Management of New Protocols and Protocol Extensions", RFC 1306 5706, November 2009. 1308 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1309 Instance Extensions", RFC 6549, March 2012. 1311 Authors' Addresses 1313 Hannes Gredler 1314 Juniper Networks, Inc. 1315 1194 N. Mathilda Ave. 1316 Sunnyvale, CA 94089 1317 US 1319 Email: hannes@juniper.net 1320 Jan Medved 1321 Cisco Systems, Inc. 1322 170, West Tasman Drive 1323 San Jose, CA 95134 1324 US 1326 Email: jmedved@cisco.com 1328 Stefano Previdi 1329 Cisco Systems, Inc. 1330 Via Del Serafico, 200 1331 Roma 00142 1332 Italy 1334 Email: sprevidi@cisco.com 1336 Adrian Farrel 1337 Juniper Networks, Inc. 1338 1194 N. Mathilda Ave. 1339 Sunnyvale, CA 94089 1340 US 1342 Email: afarrel@juniper.net