idnits 2.17.1 draft-ietf-idr-ls-distribution-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4197 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-13 -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: April 25, 2013 S. Previdi 6 Cisco Systems, Inc. 7 A. Farrel 8 Juniper Networks, Inc. 9 S. Ray 10 Cisco Systems, Inc. 11 October 22, 2012 13 North-Bound Distribution of Link-State and TE Information using BGP 14 draft-ietf-idr-ls-distribution-01 16 Abstract 18 In a number of environments, a component external to a network is 19 called upon to perform computations based on the network topology and 20 current state of the connections within the network, including 21 traffic engineering information. This is information typically 22 distributed by IGP routing protocols within the network 24 This document describes a mechanism by which links state and traffic 25 engineering information can be collected from networks and shared 26 with external components using the BGP routing protocol. This is 27 achieved using a new BGP Network Layer Reachability Information 28 (NLRI) encoding format. The mechanism is applicable to physical and 29 virtual links. The mechanism described is subject to policy control. 31 Applications of this technique include Application Layer Traffic 32 Optimization (ALTO) servers, and Path Computation Elements (PCEs). 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 25, 2013. 57 Copyright Notice 59 Copyright (c) 2012 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Motivation and Applicability . . . . . . . . . . . . . . . . . 5 76 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . . 5 77 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 78 3. Carrying Link State Information in BGP . . . . . . . . . . . . 8 79 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.2. The Link State NLRI . . . . . . . . . . . . . . . . . . . 9 81 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . . 11 82 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . . 15 83 3.2.3. The Prefix NLRI . . . . . . . . . . . . . . . . . . . 16 84 3.3. The LINK_STATE Attribute . . . . . . . . . . . . . . . . . 16 85 3.3.1. Link Attribute TLVs . . . . . . . . . . . . . . . . . 16 86 3.3.2. Node Attribute TLVs . . . . . . . . . . . . . . . . . 20 87 3.3.3. Prefix Attributes TLVs . . . . . . . . . . . . . . . . 23 88 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . . 27 89 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . . 27 90 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . . 27 91 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . . 27 92 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . . 28 93 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . . 28 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 95 6. Manageability Considerations . . . . . . . . . . . . . . . . . 29 96 6.1. Operational Considerations . . . . . . . . . . . . . . . . 29 97 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . . 29 98 6.1.2. Installation and Initial Setup . . . . . . . . . . . . 30 99 6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . . 30 100 6.1.4. Requirements on Other Protocols and Functional 101 Components . . . . . . . . . . . . . . . . . . . . . . 30 102 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 30 103 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 30 104 6.2. Management Considerations . . . . . . . . . . . . . . . . 31 105 6.2.1. Management Information . . . . . . . . . . . . . . . . 31 106 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . . 31 107 6.2.3. Configuration Management . . . . . . . . . . . . . . . 31 108 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 31 109 6.2.5. Performance Management . . . . . . . . . . . . . . . . 31 110 6.2.6. Security Management . . . . . . . . . . . . . . . . . 32 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 112 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 118 1. Introduction 120 The contents of a Link State Database (LSDB) or a Traffic Engineering 121 Database (TED) has the scope of an IGP area. Some applications, such 122 as end-to-end Traffic Engineering (TE), would benefit from visibility 123 outside one area or Autonomous System (AS) in order to make better 124 decisions. 126 The IETF has defined the Path Computation Element (PCE) [RFC4655] as 127 a mechanism for achieving the computation of end-to-end TE paths that 128 cross the visibility of more than one TED or which require CPU- 129 intensive or coordinated computations. The IETF has also defined the 130 ALTO Server [RFC5693] as an entity that generates an abstracted 131 network topology and provides it to network-aware applications. 133 Both a PCE and an ALTO Server need to gather information about the 134 topologies and capabilities of the network in order to be able to 135 fulfill their function 137 This document describes a mechanism by which Link State and TE 138 information can be collected from networks and shared with external 139 components using the BGP routing protocol [RFC4271]. This is 140 achieved using a new BGP Network Layer Reachability Information 141 (NLRI) encoding format. The mechanism is applicable to physical and 142 virtual links. The mechanism described is subject to policy control. 144 A router maintains one or more databases for storing link-state 145 information about nodes and links in any given area. Link attributes 146 stored in these databases include: local/remote IP addresses, local/ 147 remote interface identifiers, link metric and TE metric, link 148 bandwidth, reservable bandwidth, per CoS class reservation state, 149 preemption and Shared Risk Link Groups (SRLG). The router's BGP 150 process can retrieve topology from these LSDBs and distribute it to a 151 consumer, either directly or via a peer BGP Speaker (typically a 152 dedicated Route Reflector), using the encoding specified in this 153 document. 155 The collection of Link State and TE link state information and its 156 distribution to consumers is shown in the following figure. 158 +-----------+ 159 | Consumer | 160 +-----------+ 161 ^ 162 | 163 +-----------+ 164 | BGP | +-----------+ 165 | Speaker | | Consumer | 166 +-----------+ +-----------+ 167 ^ ^ ^ ^ 168 | | | | 169 +---------------+ | +-------------------+ | 170 | | | | 171 +-----------+ +-----------+ +-----------+ 172 | BGP | | BGP | | BGP | 173 | Speaker | | Speaker | . . . | Speaker | 174 +-----------+ +-----------+ +-----------+ 175 ^ ^ ^ 176 | | | 177 IGP IGP IGP 179 Figure 1: TE Link State info collection 181 A BGP Speaker may apply configurable policy to the information that 182 it distributes. Thus, it may distribute the real physical topology 183 from the LSDB or the TED. Alternatively, it may create an abstracted 184 topology, where virtual, aggregated nodes are connected by virtual 185 paths. Aggregated nodes can be created, for example, out of multiple 186 routers in a POP. Abstracted topology can also be a mix of physical 187 and virtual nodes and physical and virtual links. Furthermore, the 188 BGP Speaker can apply policy to determine when information is updated 189 to the consumer so that there is reduction of information flow form 190 the network to the consumers. Mechanisms through which topologies 191 can be aggregated or virtualized are outside the scope of this 192 document 194 2. Motivation and Applicability 196 This section describes uses cases from which the requirements can be 197 derived. 199 2.1. MPLS-TE with PCE 201 As described in [RFC4655] a PCE can be used to compute MPLS-TE paths 202 within a "domain" (such as an IGP area) or across multiple domains 203 (such as a multi-area AS, or multiple ASes). 205 o Within a single area, the PCE offers enhanced computational power 206 that may not be available on individual routers, sophisticated 207 policy control and algorithms, and coordination of computation 208 across the whole area. 210 o If a router wants to compute a MPLS-TE path across IGP areas its 211 own TED lacks visibility of the complete topology. That means 212 that the router cannot determine the end-to-end path, and cannot 213 even select the right exit router (Area Border Router - ABR) for 214 an optimal path. This is an issue for large-scale networks that 215 need to segment their core networks into distinct areas, but which 216 still want to take advantage of MPLS-TE. 218 Previous solutions used per-domain path computation [RFC5152]. The 219 source router could only compute the path for the first area because 220 the router only has full topological visibility for the first area 221 along the path, but not for subsequent areas. Per-domain path 222 computation uses a technique called "loose-hop-expansion" [RFC3209], 223 and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) 224 using the IGP computed shortest path topology for the remainder of 225 the path. This may lead to sub-optimal paths, makes alternate/ 226 back-up path computation hard, and might result in no TE path being 227 found when one really does exist. 229 The PCE presents a computation server that may have visibility into 230 more than one IGP area or AS, or may cooperate with other PCEs to 231 perform distributed path computation. The PCE obviously needs access 232 to the TED for the area(s) it serves, but [RFC4655] does not describe 233 how this is achieved. Many implementations make the PCE a passive 234 participant in the IGP so that it can learn the latest state of the 235 network, but this may be sub-optimal when the network is subject to a 236 high degree of churn, or when the PCE is responsible for multiple 237 areas. 239 The following figure shows how a PCE can get its TED information 240 using the mechanism described in this document. 242 +----------+ +---------+ 243 | ----- | | BGP | 244 | | TED |<-+-------------------------->| Speaker | 245 | ----- | TED synchronization | | 246 | | | mechanism: +---------+ 247 | | | BGP with Link-State NLRI 248 | v | 249 | ----- | 250 | | PCE | | 251 | ----- | 252 +----------+ 253 ^ 254 | Request/ 255 | Response 256 v 257 Service +----------+ Signaling +----------+ 258 Request | Head-End | Protocol | Adjacent | 259 -------->| Node |<------------>| Node | 260 +----------+ +----------+ 262 Figure 2: External PCE node using a TED synchronization mechanism 264 The mechanism in this document allows the necessary TED information 265 to be collected from the IGP within the network, filtered according 266 to configurable policy, and distributed to the PCE as necessary. 268 2.2. ALTO Server Network API 270 An ALTO Server [RFC5693] is an entity that generates an abstracted 271 network topology and provides it to network-aware applications over a 272 web service based API. Example applications are p2p clients or 273 trackers, or CDNs. The abstracted network topology comes in the form 274 of two maps: a Network Map that specifies allocation of prefixes to 275 PIDs, and a Cost Map that specifies the cost between PIDs listed in 276 the Network Map. For more details, see [I-D.ietf-alto-protocol]. 278 ALTO abstract network topologies can be auto-generated from the 279 physical topology of the underlying network. The generation would 280 typically be based on policies and rules set by the operator. Both 281 prefix and TE data are required: prefix data is required to generate 282 ALTO Network Maps, TE (topology) data is required to generate ALTO 283 Cost Maps. Prefix data is carried and originated in BGP, TE data is 284 originated and carried in an IGP. The mechanism defined in this 285 document provides a single interface through which an ALTO Server can 286 retrieve all the necessary prefix and network topology data from the 287 underlying network. Note an ALTO Server can use other mechanisms to 288 get network data, for example, peering with multiple IGP and BGP 289 Speakers. 291 The following figure shows how an ALTO Server can get network 292 topology information from the underlying network using the mechanism 293 described in this document. 295 +--------+ 296 | Client |<--+ 297 +--------+ | 298 | ALTO +--------+ BGP with +---------+ 299 +--------+ | Protocol | ALTO | Link-State NLRI | BGP | 300 | Client |<--+------------| Server |<----------------| Speaker | 301 +--------+ | | | | | 302 | +--------+ +---------+ 303 +--------+ | 304 | Client |<--+ 305 +--------+ 307 Figure 3: ALTO Server using network topology information 309 3. Carrying Link State Information in BGP 311 Two parts: a new BGP NLRI that describes links and nodes comprising 312 IGP link state information, and a new BGP path attribute that carries 313 link and node properties and attributes, such as the link metric or 314 node properties. 316 3.1. TLV Format 318 Information in the new link state NLRIs and attributes is encoded in 319 Type/Length/Value triplets. The TLV format is shown in Figure 4. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 | Value (variable) | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 4: TLV format 333 The Length field defines the length of the value portion in octets 334 (thus a TLV with no value portion would have a length of zero). The 335 TLV is not padded to four-octet alignment; Unrecognized types are 336 ignored. 338 3.2. The Link State NLRI 340 The MP_REACH and MP_UNREACH attributes are BGP's containers for 341 carrying opaque information. Each Link State NLRI describes either a 342 single node or link. 344 All link, node and prefix information SHALL be encoded using a TBD 345 AFI / TBD SAFI header into those attributes. 347 In order for two BGP speakers to exchange Link-State NLRI, they MUST 348 use BGP Capabilities Advertisement to ensure that they both are 349 capable of properly processing such NLRI. This is done as specified 350 in [RFC4760], by using capability code 1 (multi-protocol BGP), with 351 an AFI/SAFI TBD. 353 The format of the Link State NLRI is shown in the following figure. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | NLRI Type | Total NLRI Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 | Link-State NLRI (variable) | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 5: Link State SAFI 1 NLRI Format 367 0 1 2 3 368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | NLRI Type | Total NLRI Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 + Route Distinguisher + 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 | Link-State NLRI (variable) | 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 6: Link State SAFI 128 NLRI Format 383 The 'Total NLRI Length' field contains the cumulative length of all 384 the TLVs in the NLRI. For VPN applications it also includes the 385 length of the Route Distinguisher. 387 The 'NLRI Type' field can contain one of the following values: 389 Type = 1: Link NLRI, contains link descriptors and link attributes 391 Type = 2: Node NLRI, contains node attributes 393 Type = 3: IPv4 Topology Prefix NLRI 395 Type = 4: IPv6 Topology Prefix NLRI 397 The Link NLRI (NLRI Type = 1) is shown in the following figure. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Protocol-ID | Reserved | Instance Identifier | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Local Node Descriptors (variable) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Remote Node Descriptors (variable) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Link Descriptors (variable) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 7: The Link NLRI format 413 The Node NLRI (NLRI Type = 2) is shown in the following figure. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Protocol-ID | Reserved | Instance Identifier | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Local Node Descriptors (variable) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 8: The Node NLRI format 425 The IPv4 and IPv6 Prefix NLRIs (NLRI Type = 3 and Type = 4) use the 426 same format as shown in the following figure. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Protocol-ID | Reserved | Instance Identifier | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Node Descriptor | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Prefix NLRI (variable) | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 9: The IPv4/IPv6 Topology Prefix NLRI format 440 The 'Protocol-ID' field can contain one of the following values: 442 Protocol-ID = 0: Unknown, The source of NLRI information could not 443 be determined 445 Protocol-ID: IS-IS Level 1, The NLRI information has been sourced 446 by IS-IS Level 1 448 Protocol-ID: IS-IS Level 2, The NLRI information has been sourced 449 by IS-IS Level 2 451 Protocol-ID = 3: OSPF, The NLRI information has been sourced by 452 OSPF 454 Protocol-ID = 4: Direct, The NLRI information has been sourced 455 from local interface state 457 Protocol-ID = 5: Static, The NLRI information has been sourced by 458 static configuration 460 Both OSPF and IS-IS may run multiple routing protocol instances over 461 the same link. See [I-D.ietf-isis-mi] and [RFC6549]. The 'Instance 462 Identifier' field identifies the protocol instance. 464 Each Node Descriptor and Link Descriptor consists of one or more TLVs 465 described in the following sections. The sender of an UPDATE message 466 MUST order the TLVs within a Node Descriptor or a Link Descriptor in 467 ascending order of TLV type." 469 3.2.1. Node Descriptors 471 Each link gets anchored by at least a pair of router-IDs. Since 472 there are many Router-IDs formats (32 Bit IPv4 router-ID, 56 Bit ISO 473 Node-ID and 128 Bit IPv6 router-ID) a link may be anchored by more 474 than one Router-ID pair. The set of Local and Remote Node 475 Descriptors describe which Protocols Router-IDs will be following to 476 "anchor" the link described by the "Link attribute TLVs". There must 477 be at least one "like" router-ID pair of a Local Node Descriptors and 478 a Remote Node Descriptors per-protocol. If a peer sends an illegal 479 combination in this respect, then this is handled as an NLRI error, 480 described in [RFC4760]. 482 It is desirable that the Router-ID assignments inside the Node anchor 483 are globally unique. However there may be router-ID spaces (e.g. 484 ISO) where not even a global registry exists, or worse, Router-IDs 485 have been allocated following private-IP RFC 1918 [RFC1918] 486 allocation. In order to disambiguate the Router-IDs the local and 487 remote Autonomous System number TLVs of the anchor nodes MUST be 488 included in the NLRI. If the anchor node's AS is a member of an AS 489 Confederation ([RFC5065]), then the Autonomous System number TLV 490 contains the confederations' AS Confederation Identifier and the 491 Member-AS TLV is included in the NLRI. The Local and Remote 492 Autonomous System TLVs are 4 octets wide as described in [RFC4893]. 493 2-octet AS Numbers SHALL be expanded to 4-octet AS Numbers by zeroing 494 the two MSB octets. 496 3.2.1.1. Local Node Descriptors 498 The Local Node Descriptors TLV (Type 256) contains Node Descriptors 499 for the node anchoring the local end of the link. The length of this 500 TLV is variable. The value contains one or more Node Descriptor Sub- 501 TLVs defined in Section 3.2.1.3. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 | Node Descriptor Sub-TLVs (variable) | 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 10: Local Node Descriptors TLV format 515 3.2.1.2. Remote Node Descriptors 517 The Remote Node Descriptors TLV (Type 257) contains Node Descriptors 518 for the node anchoring the remote end of the link. The length of 519 this TLV is variable. The value contains one or more Node Descriptor 520 Sub-TLVs defined in Section 3.2.1.3. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 | Node Descriptor Sub-TLVs (variable) | 529 | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 11: Remote Node Descriptors TLV format 534 3.2.1.3. Node Descriptor Sub-TLVs 536 The Node Descriptor Sub-TLV type codepoints and lengths are listed in 537 the following table: 539 +------+-------------------+--------+ 540 | Type | Description | Length | 541 +------+-------------------+--------+ 542 | 258 | Autonomous System | 4 | 543 | 259 | Member-AS | 4 | 544 | 260 | ISO Node-ID | 7 | 545 | 261 | IPv4 Router-ID | 5 | 546 | 262 | IPv4 Router-ID | 17 | 547 +------+-------------------+--------+ 549 Table 1: Node Descriptor Sub-TLVs 551 The TLV values in Node Descriptor Sub-TLVs are defined as follows: 553 Autonomous System: opaque value (32 Bit AS ID) 555 Member-AS: opaque value (32 Bit AS ID); only included if the node is 556 in an AS confederation. 558 IPv4 Router ID: opaque value (can be an IPv4 address or an 32 Bit 559 router ID). 561 IPv6 Router ID: opaque value (can be an IPv6 address or 128 Bit 562 router ID). 564 ISO Node ID: ISO node-ID (6 octets ISO system-ID) followed by a PSN 565 octet in case LAN "Pseudonode" information gets advertised. The 566 PSN octet must be zero for non-LAN "Pseudonodes". 568 There can be at most one instance of each TLV type present in any 569 Node Descriptor. The TLV ordering within a Node descriptor MUST 570 be kept in order of increasing numeric value of type. TLVs 258 571 and 259 specify administrative context in which TLVs 260-262 are 572 to be evaluated. The first TLV from range 260-262 is to be 573 interpreted as the primary node identifier, e.g. it acts as the 574 unique key by which the node can be referenced within its 575 administrative contexts. Any further TLVs are to be treated as 576 secondary identifiers, which may be used for cross-reference, but 577 are to be treated as if they are object attributes. 579 3.2.1.4. Router-ID Anchoring Example: ISO Pseudonode 581 IS-IS Pseudonodes are a good example for the variable Router-ID 582 anchoring. Consider Figure 12. This represents a Broadcast LAN 583 between a pair of routers. The "real" (=non pseudonode) routers have 584 both an IPv4 Router-ID and IS-IS Node-ID. The pseudonode does not 585 have an IPv4 Router-ID. Two unidirectional links (Node1, Pseudonode 586 1) and (Pseudonode 1, Node 2) are being generated. 588 The NRLI for (Node1, Pseudonode1) encodes local IPv4 router-ID, local 589 ISO node-ID and remote ISO node-id) 591 The NLRI for (Pseudonode1, Node2) encodes a local ISO node-ID and 592 remote ISO node-id. 594 +-----------------+ +-----------------+ +-----------------+ 595 | Node1 | | Pseudonode 1 | | Node2 | 596 |1920.0000.2001.00|--->|1921.6800.1001.02|--->|1920.0000.2002.00| 597 | 192.0.2.1 | | | | 192.0.2.2 | 598 +-----------------+ +-----------------+ +-----------------+ 600 Figure 12: IS-IS Pseudonodes 602 3.2.1.5. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 604 Migrating gracefully from one IGP to another requires congruent 605 operation of both routing protocols during the migration period. The 606 target protocol (IS-IS) supports more router-ID spaces than the 607 source (OSPFv2) protocol. When advertising a point-to-point link 608 between an OSPFv2-only router and an OSPFv2 and IS-IS enabled router 609 the following link information may be generated. Note that the IS-IS 610 router also supports the IPv6 traffic engineering extensions RFC 6119 611 [RFC6119] for IS-IS. 613 The NRLI encodes local IPv4 router-id, remote IPv4 router-id, remote 614 ISO node-id and remote IPv6 node-id. 616 3.2.2. Link Descriptors 618 The 'Link Descriptor' field is a set of Type/Length/Value (TLV) 619 triplets. The format of each TLV is shown in Section 3.1. The 'Link 620 descriptor' TLVs uniquely identify a link between a pair of anchor 621 Routers. A link described by the Link descriptor TLVs actually is a 622 "half-link", a unidirectional representation of a logical link. In 623 order to fully describe a single logical link two originating routers 624 need to advertise a half-link each, i.e. two link NLRIs will be 625 advertised. 627 The format and semantics of the 'value' fields in most 'Link 628 Descriptor' TLVs correspond to the format and semantics of value 629 fields in IS-IS Extended IS Reachability sub-TLVs, defined in 630 [RFC5305], [RFC5307] and [RFC6119]. Although the encodings for 'Link 631 Descriptor' TLVs were originally defined for IS-IS, the TLVs can 632 carry data sourced either by IS-IS or OSPF. 634 The following link descriptor TLVs are valid in the Link NLRI: 636 +------+------------------------+-----------------+-----------------+ 637 | Type | Description | IS-IS | Value defined | 638 | | | TLV/Sub-TLV | in: | 639 +------+------------------------+-----------------+-----------------+ 640 | 263 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | 641 | | Identifiers | | | 642 | 264 | IPv4 interface address | 22/6 | [RFC5305]/3.2 | 643 | 265 | IPv4 neighbor address | 22/8 | [RFC5305]/3.3 | 644 | 266 | IPv6 interface address | 22/12 | [RFC6119]/4.2 | 645 | 267 | IPv6 neighbor address | 22/13 | [RFC6119]/4.3 | 646 | 268 | Multi Topology ID | --- | Section 3.2.2.1 | 647 +------+------------------------+-----------------+-----------------+ 649 Table 2: Link Descriptor TLVs 651 3.2.2.1. Multi Topology ID TLV 653 The Multi Topology ID TLV (Type 268) carries the Multi Topology ID 654 for this link. The semantics of the Multi Topology ID are defined in 655 RFC5120, Section 7.2 [RFC5120], and the OSPF Multi Topology ID), 656 defined in RFC4915, Section 3.7 [RFC4915]. If the value in the Multi 657 Topology ID TLV is derived from OSPF, then the upper 9 bits of the 658 Multi Topology ID are set to 0. 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Type | Length | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |R R R R| Multi Topology ID | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 13: Multi Topology ID TLV format 670 3.2.3. The Prefix NLRI 672 The Prefix NLRI is a variable length field that contains an IP 673 address prefix (IPv4 or IPv6) originally advertised in the IGP 674 topology. The distinction between IPv4 and IPv6 prefixes is given by 675 the NLRI Type filed in the Link State NLRI. Reachability information 676 is encoded as one or more 2-tuples of the form , 677 whose fields are described below: 679 +---------------------------+ 680 | Length (1 octet) | 681 +---------------------------+ 682 | Prefix (variable) | 683 +---------------------------+ 685 Figure 14: Prefix NLRI format 687 3.3. The LINK_STATE Attribute 689 This is an optional, transitive BGP attribute that is used to carry 690 link, node and prefix parameters and attributes. It is defined as a 691 set of Type/Length/Value (TLV) triplets, described in the following 692 section. This attribute SHOULD only be included with Link State 693 NLRIs. This attribute MUST be ignored for all other NLRIs. 695 3.3.1. Link Attribute TLVs 697 Each 'Link Attribute' is a Type/Length/Value (TLV) triplet formatted 698 as defined in Section 3.1. The format and semantics of the 'value' 699 fields in some 'Link Attribute' TLVs correspond to the format and 700 semantics of value fields in IS-IS Extended IS Reachability sub-TLVs, 701 defined in [RFC5305] and [RFC5307]. Other 'Link Attribute' TLVs are 702 defined in this document. Although the encodings for 'Link 703 Attribute' TLVs were originally defined for IS-IS, the TLVs can carry 704 data sourced either by IS-IS or OSPF. 706 The following 'Link Attribute' TLVs are are valid in the LINK_STATE 707 attribute: 709 +------+-------------------------+----------------+-----------------+ 710 | Type | Description | IS-IS | Defined in: | 711 | | | TLV/Sub-TLV | | 712 +------+-------------------------+----------------+-----------------+ 713 | 269 | Administrative group | 22/3 | [RFC5305]/3.1 | 714 | | (color) | | | 715 | 270 | Maximum link bandwidth | 22/9 | [RFC5305]/3.3 | 716 | 271 | Max. reservable link | 22/10 | [RFC5305]/3.5 | 717 | | bandwidth | | | 718 | 272 | Unreserved bandwidth | 22/11 | [RFC5305]/3.6 | 719 | 273 | Link Protection Type | 22/20 | [RFC5307]/1.2 | 720 | 274 | MPLS Protocol Mask | --- | Section 3.3.1.1 | 721 | 275 | Metric | --- | Section 3.3.1.2 | 722 | 276 | Shared Risk Link Group | --- | Section 3.3.1.3 | 723 | 277 | OSPF specific link | --- | Section 3.3.1.4 | 724 | | attribute | | | 725 | 278 | IS-IS Specific Link | --- | Section 3.3.1.5 | 726 | | Attribute | | | 727 | 279 | Area ID | --- | Section 3.3.1.6 | 728 +------+-------------------------+----------------+-----------------+ 730 Table 3: Link Attribute TLVs 732 3.3.1.1. MPLS Protocol Mask TLV 734 The MPLS Protocol TLV (Type 274) carries a bit mask describing which 735 MPLS signaling protocols are enabled. The length of this TLV is 1. 736 The value is a bit array of 8 flags, where each bit represents an 737 MPLS Protocol capability. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type | Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 |L R | 745 +-+-+-+-+-+-+-+-+ 747 Figure 15: MPLS Protocol TLV 749 The following bits are defined: 751 +-----+---------------------------------------------+-----------+ 752 | Bit | Description | Reference | 753 +-----+---------------------------------------------+-----------+ 754 | 0 | Label Distribution Protocol (LDP) | [RFC5036] | 755 | 1 | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | 756 | 2-7 | Reserved for future use | | 757 +-----+---------------------------------------------+-----------+ 759 Table 4: MPLS Protocol Mask TLV Codes 761 3.3.1.2. Metric TLV 763 The IGP Metric TLV (Type 275) carries the metric for this link. The 764 length of this TLV is 3. If the length of the metric from which the 765 IGP Metric value is derived is less than 3 (e.g. for OSPF link 766 metrics or non-wide IS-IS metric), then the upper bits of the TLV are 767 set to 0. 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type | Length | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | IGP Link Metric | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 Figure 16: Metric TLV format 779 3.3.1.3. Shared Risk Link Group TLV 781 The Shared Risk Link Group (SRLG) TLV (Type 276) carries the Shared 782 Risk Link Group information (see Section 2.3, "Shared Risk Link Group 783 Information", of [RFC4202]). It contains a data structure consisting 784 of a (variable) list of SRLG values, where each element in the list 785 has 4 octets, as shown in Figure 17. The length of this TLV is 4 * 786 (number of SRLG values). 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type | Length | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Shared Risk Link Group Value | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | ............ | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Shared Risk Link Group Value | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Figure 17: Shared Risk Link Group TLV format 802 Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG 803 information is carried in two different TLVs: the IPv4 (SRLG) TLV 804 (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) 805 defined in [RFC6119]. Since the Link State NLRI uses variable 806 Router-ID anchoring, both IPv4 and IPv6 SRLG information can be 807 carried in a single TLV. 809 3.3.1.4. OSPF Specific Link Attribute TLV 811 The OSPF specific link attribute TLV (Type 277) is an envelope that 812 transparently carries optional link properties TLVs advertised by an 813 OSPF router. The value field contains one or more optional OSPF link 814 attribute TLVs. An originating router shall use this TLV for 815 encoding information specific to the OSPF protocol or new OSPF 816 extensions for which there is no protocol neutral representation in 817 the BGP link-state NLRI. 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Type | Length | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | | 825 | OSPF specific link attributes (variable) | 826 | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Figure 18: OSPF specific link attribute format 831 3.3.1.5. IS-IS specific link attribute TLV 833 The IS-IS specific link attribute TLV (Type 278) is an envelope that 834 transparently carries optional link properties TLVs advertised by an 835 IS-IS router. The value field contains one or more optional IS-IS 836 link attribute TLVs. An originating router shall use this TLV for 837 encoding information specific to the IS-IS protocol or new IS-IS 838 extensions for which there is no protocol neutral representation in 839 the BGP link-state NLRI. 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type | Length | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | | 847 | IS-IS specific link attributes (variable) | 848 | | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Figure 19: IS-IS specific link attribute format 853 3.3.1.6. Link Area TLV 855 The Area TLV (Type 279) carries the Area ID which is assigned on this 856 link. If a link is present in more than one Area then several 857 occurrences of this TLV may be generated. Since only the OSPF 858 protocol carries the notion of link specific areas, the Area ID has a 859 fixed length of 4 octets. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Type | Length | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Area ID | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Figure 20: Link Area TLV format 871 3.3.2. Node Attribute TLVs 873 The following node attribute TLVs are defined: 875 +------+--------------------------------+----------+ 876 | Type | Description | Length | 877 +------+--------------------------------+----------+ 878 | 280 | Multi Topology | 2 | 879 | 281 | Node Flag Bits | 1 | 880 | 282 | OSPF Specific Node Properties | variable | 881 | 283 | IS-IS Specific Node Properties | variable | 882 | 284 | Node Area ID | variable | 883 +------+--------------------------------+----------+ 885 Table 5: Node Attribute TLVs 887 3.3.2.1. Multi Topology Node TLV 889 The Multi Topology TLV (Type 280) carries the Multi Topology ID and 890 topology specific flags for this node. The format and semantics of 891 the 'value' field in the Multi Topology TLV is defined in RFC5120, 892 Section 7.1 [RFC5120]. If the value in the Multi Topology TLV is 893 derived from OSPF, then the upper 9 bits of the Multi Topology ID and 894 the 'O' and 'A' bits are set to 0. 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Type | Length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 |O A R R| Multi Topology ID | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 Figure 21: Multi Topology Node TLV format 906 3.3.2.2. Node Flag Bits TLV 908 The Node Flag Bits TLV (Type 281) carries a bit mask describing node 909 attributes. The value is a bit array of 8 flags, where each bit 910 represents a node capability. 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Type | Length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Flags | 918 +-+-+-+-+-+-+-+-+ 920 Figure 22: Node Flag Bits TLV format 922 The bits are defined as follows: 924 +-----+--------------+-----------+ 925 | Bit | Description | Reference | 926 +-----+--------------+-----------+ 927 | 0 | Overload Bit | [RFC1195] | 928 | 1 | Attached Bit | [RFC1195] | 929 | 2 | External Bit | [RFC2328] | 930 | 3 | ABR Bit | [RFC2328] | 931 +-----+--------------+-----------+ 933 Table 6: Node Flag Bits Definitions 935 3.3.2.3. OSPF Specific Node Properties TLV 937 The OSPF Specific Node Properties TLV (Type 282) is an envelope that 938 transparently carries optional node properties TLVs advertised by an 939 OSPF router. The value field contains one or more optional OSPF node 940 property TLVs, such as the OSPF Router Informational Capabilities TLV 941 defined in [RFC4970], or the OSPF TE Node Capability Descriptor TLV 942 described in [RFC5073]. An originating router shall use this TLV for 943 encoding information specific to the OSPF protocol or new OSPF 944 extensions for which there is no protocol neutral representation in 945 the BGP link-state NLRI. 947 0 1 2 3 948 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 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Type | Length | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | | 953 | OSPF specific node properties (variable) | 954 | | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Figure 23: OSPF specific Node property format 959 3.3.2.4. IS-IS Specific Node Properties TLV 961 The IS-IS Router Specific Node Properties TLV (Type 283) is an 962 envelope that transparently carries optional node specific TLVs 963 advertised by an IS-IS router. The value field contains one or more 964 optional IS-IS node property TLVs, such as the IS-IS TE Node 965 Capability Descriptor TLV described in [RFC5073]. An originating 966 router shall use this TLV for encoding information specific to the 967 IS-IS protocol or new IS-IS extensions for which there is no protocol 968 neutral representation in the BGP link-state NLRI. 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Type | Length | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | | 976 | IS-IS specific node properties (variable) | 977 | | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 Figure 24: IS-IS specific Node property format 982 3.3.2.5. Area Node TLV 984 The Area TLV (Type 284) carries the Area ID which is assigned to this 985 node. If a node is present in more than one Area then several 986 occurrences of this TLV may be generated. Since only the IS-IS 987 protocol carries the notion of per-node areas, the Area ID has a 988 variable length of 1 to 20 octets. 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Type | Length | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | | 996 | Area ID (variable) | 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Figure 25: Area Node TLV format 1002 3.3.3. Prefix Attributes TLVs 1004 Prefixes are learned from the IGP topology (ISIS or OSPF) with a set 1005 of IGP attributes (such as metric, route tags, route type, etc.) that 1006 MUST be reflected into the LINK_STATE attribute. This section 1007 describes the different attributes related to the IPv4/IPv6 prefixes. 1008 Prefix Attributes TLVs SHOULD be used when advertising NLRI types 3 1009 and 4 only. The following attributes TLVs are defined: 1011 +------+-------------------------+--------+-----------+ 1012 | Type | Description | Length | Reference | 1013 +------+-------------------------+--------+-----------+ 1014 | 285 | IGP Flags | 4 | | 1015 | 286 | Route Tag | 4 | [RFC5130] | 1016 | 287 | Extended Tag | 8 | [RFC5130] | 1017 | 288 | Metric | 4 | [RFC5305] | 1018 | 289 | OSPF Forwarding Address | 4 | [RFC2328] | 1019 +------+-------------------------+--------+-----------+ 1021 Table 7: Prefix Attribute TLVs 1023 3.3.3.1. IGP Flags TLV 1025 IGP Flags TLV contains ISIS and OSPF flags and bits originally 1026 assigned to the prefix. The IGP Flags TLV is encoded as follows: 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Type | Length | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | IGP Flags | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 Figure 26: IGP Flag TLV format 1038 where: 1040 Type is 285 1042 Length is 4 1044 The following bits are defined according to the table here below: 1046 +------+------------------+-----------+ 1047 | Bit | Description | Reference | 1048 +------+------------------+-----------+ 1049 | 0 | ISIS Up/Down Bit | [RFC5305] | 1050 | 1-3 | OSPF Route Type | [RFC2328] | 1051 | 4-15 | RESERVED | | 1052 +------+------------------+-----------+ 1054 Table 8: IGP Flag Bits Definitions 1056 OSPF Route Type can be either: Intra-Area (0x1), Inter-Area (0x2), 1057 External 1 (0x3), External 2 (0x4), NSSA (0x5) and is encoded in a 3 1058 bits number. For prefixes learned from IS-IS, this field MUST to be 1059 set to 0x0 on transmission. 1061 3.3.3.2. Route Tag 1063 Route Tag TLV carries the original IGP TAG (ISIS or OSPF) of the 1064 prefix and is encoded as follows: 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type | Length | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Route Tag | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Figure 27: IGP Route TAG TLV format 1076 where: 1078 Type is 286 1080 Length is 4 1082 Route Tag contains the original tags as learned in the IGP topology. 1084 3.3.3.3. Extended Route Tag 1086 Extended Route Tag TLV carries the ISIS Extended Route TAG of the 1087 prefix and is encoded as follows: 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Type | Length | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Extended Route Tag | 1095 | | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 Figure 28: Extended IGP Route TAG TLV format 1100 where: 1102 Type is 287 1104 Length is 8 1106 Extended Route Tag contains the original ISIS Extended Tag as learned 1107 in the IGP topology. 1109 3.3.3.4. Prefix Metric TLV 1111 Prefix Metric TLV carries the metric of the prefix as known in the 1112 IGP topology. The attribute is mandatory and can only appear once. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Type | Length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Metric | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 29: Prefix Metric TLV Format 1124 where: 1126 Type is 288 1128 Length is 4 1130 3.3.3.5. OSPF Forwarding Address TLV 1132 OSPF Forwarding Address TLV carries the OSPF forwarding address as 1133 known in the original OSPF advertisement. Forwarding address can be 1134 either IPv4 or IPv6. 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Type | Length | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Forwarding Address (variable) | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Figure 30: OSPF Forwarding Address TLV Format 1146 where: 1148 Type is 289 1150 Length is 4 for an IPv4 forwarding address an 16 for an IPv6 1151 forwarding address 1153 3.4. BGP Next Hop Information 1155 BGP link-state information for both IPv4 and IPv6 networks can be 1156 carried over either an IPv4 BGP session, or an IPv6 BGP session. If 1157 IPv4 BGP session is used, then the next hop in the MP_REACH_NLRI 1158 SHOULD be an IPv4 address. Similarly, if IPv6 BGP session is used, 1159 then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 address. 1160 Usually the next hop will be set to the local end-point address of 1161 the BGP session. The next hop address MUST be encoded as described 1162 in [RFC4760]. The length field of the next hop address will specify 1163 the next hop address-family. If the next hop length is 4, then the 1164 next hop is an IPv4 address; if the next hop length is 16, then it is 1165 a global IPv6 address and if the next hop length is 32, then there is 1166 one global IPv6 address followed by a link-local IPv6 address. The 1167 link-local IPv6 address should be used as described in [RFC2545]. 1169 3.5. Inter-AS Links 1171 The main source of TE information is the IGP, which is not active on 1172 inter-AS links. In order to inject a non-IGP enabled link into the 1173 BGP link-state RIB an implementation must support configuration of 1174 static links. 1176 4. Link to Path Aggregation 1178 Distribution of all links available in the global Internet is 1179 certainly possible, however not desirable from a scaling and privacy 1180 point of view. Therefore an implementation may support link to path 1181 aggregation. Rather than advertising all specific links of a domain, 1182 an ASBR may advertise an "aggregate link" between a non-adjacent pair 1183 of nodes. The "aggregate link" represents the aggregated set of link 1184 properties between a pair of non-adjacent nodes. The actual methods 1185 to compute the path properties (of bandwidth, metric) are outside the 1186 scope of this document. The decision whether to advertise all 1187 specific links or aggregated links is an operator's policy choice. 1188 To highlight the varying levels of exposure, the following deployment 1189 examples shall be discussed. 1191 4.1. Example: No Link Aggregation 1193 Consider Figure 31. Both AS1 and AS2 operators want to protect their 1194 inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to 1195 compute its link-protection LSP to R3 it needs to "see" an alternate 1196 path to R3. Therefore the AS2 operator exposes its topology. All 1197 BGP TE enabled routers in AS1 "see" the full topology of AS and 1198 therefore can compute a backup path. Note that the decision if the 1199 direct link between {R3, R4} or the {R4, R5, R3) path is used is made 1200 by the computing router. 1202 AS1 : AS2 1203 : 1204 R1-------R3 1205 | : | \ 1206 | : | R5 1207 | : | / 1208 R2-------R4 1209 : 1210 : 1212 Figure 31: no-link-aggregation 1214 4.2. Example: ASBR to ASBR Path Aggregation 1216 The brief difference between the "no-link aggregation" example and 1217 this example is that no specific link gets exposed. Consider 1218 Figure 32. The only link which gets advertised by AS2 is an 1219 "aggregate" link between R3 and R4. This is enough to tell AS1 that 1220 there is a backup path. However the actual links being used are 1221 hidden from the topology. 1223 AS1 : AS2 1224 : 1225 R1-------R3 1226 | : | 1227 | : | 1228 | : | 1229 R2-------R4 1230 : 1231 : 1233 Figure 32: asbr-link-aggregation 1235 4.3. Example: Multi-AS Path Aggregation 1237 Service providers in control of multiple ASes may even decide to not 1238 expose their internal inter-AS links. Consider Figure 33. Rather 1239 than exposing all specific R3 to R6 links, AS3 is modeled as a single 1240 node which connects to the border routers of the aggregated domain. 1242 AS1 : AS2 : AS3 1243 : : 1244 R1-------R3----- 1245 | : : \ 1246 | : : vR0 1247 | : : / 1248 R2-------R4----- 1249 : : 1250 : : 1252 Figure 33: multi-as-aggregation 1254 5. IANA Considerations 1256 This document requests a code point from the registry of Address 1257 Family Numbers. 1259 This document requests a code point from the BGP Path Attributes 1260 registry. 1262 This document requests creation of a new registry for node anchor, 1263 link descriptor and link attribute TLVs. Values 0-255 are reserved. 1264 Values 256-65535 will be used for Codepoints. The registry will be 1265 initialized as shown in Table 2 and Table 3. Allocations within the 1266 registry will require documentation of the proposed use of the 1267 allocated value and approval by the Designated Expert assigned by the 1268 IESG (see [RFC5226]). 1270 Note to RFC Editor: this section may be removed on publication as an 1271 RFC. 1273 6. Manageability Considerations 1275 This section is structured as recommended in [RFC5706]. 1277 6.1. Operational Considerations 1279 6.1.1. Operations 1281 Existing BGP operation procedures apply. No new operation procedures 1282 are defined in this document. It shall be noted that the NLRI 1283 information present in this document purely carries application level 1284 data that have no immediate corresponding forwarding state impact. 1285 As such, any churn in reachability information has different impact 1286 than regular BGP update which needs to chaange forwarding state for 1287 an entire router. Furthermore it is anticipated that distribution of 1288 this NLRI will be handled by dedicated route-reflectors providing a 1289 level of isolation and fault-containment between different NLRI 1290 types. 1292 6.1.2. Installation and Initial Setup 1294 Configuration parameters defined in Section 6.2.3 SHOULD be 1295 initialized to the following default values: 1297 o The Link-State NLRI capability is turned off for all neighbors. 1299 o The maximum rate at which Link State NLRIs will be advertised/ 1300 withdrawn from neighbors is set to 200 updates per second. 1302 6.1.3. Migration Path 1304 The proposed extension is only activated between BGP peers after 1305 capability negotiation. Moreover, the extensions can be turned on/ 1306 off an individual peer basis (see Section 6.2.3), so the extension 1307 can be gradually rolled out in the network. 1309 6.1.4. Requirements on Other Protocols and Functional Components 1311 The protocol extension defined in this document does not put new 1312 requirements on other protocols or functional components. 1314 6.1.5. Impact on Network Operation 1316 Frequency of Link-State NLRI updates could interfere with regular BGP 1317 prefix distribution. A network operator MAY use a dedicated Route- 1318 Reflector infrastructure to distribute Link-State NLRIs. 1320 Distribution of Link-State NLRIs SHOULD be limited to a single admin 1321 domain, which can consist of multiple areas within an AS or multiple 1322 ASes. 1324 6.1.6. Verifying Correct Operation 1326 Existing BGP procedures apply. In addition, an implementation SHOULD 1327 allow an operator to: 1329 o List neighbors with whom the Speaker is exchanging Link-State 1330 NLRIs 1332 6.2. Management Considerations 1334 6.2.1. Management Information 1336 6.2.2. Fault Management 1338 TBD. 1340 6.2.3. Configuration Management 1342 An implementation SHOULD allow the operator to specify neighbors to 1343 which Link-State NLRIs will be advertised and from which Link-State 1344 NLRIs will be accepted. 1346 An implementation SHOULD allow the operator to specify the maximum 1347 rate at which Link State NLRIs will be advertised/withdrawn from 1348 neighbors 1350 An implementation SHOULD allow the operator to specify the maximum 1351 rate at which Link State NLRIs will be accepted from neighbors 1353 An implementation SHOULD allow the operator to specify the maximum 1354 number of Link State NLRIs stored in router's RIB. 1356 An implementation SHOULD allow the operator to create abstracted 1357 topologies that are advertised to neighbors; Create different 1358 abstractions for different neighbors. 1360 6.2.4. Accounting Management 1362 Not Applicable. 1364 6.2.5. Performance Management 1366 An implementation SHOULD provide the following statistics: 1368 o Total number of Link-State NLRI updates sent/received 1370 o Number of Link-State NLRI updates sent/received, per neighbor 1372 o Number of errored received Link-State NLRI updates, per neighbor 1374 o Total number of locally originated Link-State NLRIs 1376 6.2.6. Security Management 1378 An operator SHOULD define ACLs to limit inbound updates as follows: 1380 o Drop all updates from Consumer peers 1382 7. Security Considerations 1384 Procedures and protocol extensions defined in this document do not 1385 affect the BGP security model. 1387 A BGP Speaker SHOULD NOT accept updates from a Consumer peer. 1389 An operator SHOULD employ a mechanism to protect a BGP Speaker 1390 against DDOS attacks from Consumers. 1392 8. Acknowledgements 1394 We would like to thank Nischal Sheth, Alia Atlas, Robert Varga, David 1395 Ward, Derek Yeung, Murtuza Lightwala, John Scudder, Kaliraj 1396 Vairavakkalai, Les Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike 1397 Shand, Peter Psenak, Rex Fernando, Richard Woundy, Saikat Ray, Steven 1398 Luong, Tamas Mondal, Waqas Alam, and Yakov Rekhter for their 1399 comments. 1401 9. References 1403 9.1. Normative References 1405 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1406 dual environments", RFC 1195, December 1990. 1408 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1409 E. Lear, "Address Allocation for Private Internets", 1410 BCP 5, RFC 1918, February 1996. 1412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1413 Requirement Levels", BCP 14, RFC 2119, March 1997. 1415 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1417 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 1418 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 1419 March 1999. 1421 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1422 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1423 Tunnels", RFC 3209, December 2001. 1425 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 1426 Support of Generalized Multi-Protocol Label Switching 1427 (GMPLS)", RFC 4202, October 2005. 1429 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1430 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1432 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1433 "Multiprotocol Extensions for BGP-4", RFC 4760, 1434 January 2007. 1436 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 1437 Number Space", RFC 4893, May 2007. 1439 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1440 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1441 RFC 4915, June 2007. 1443 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1444 Specification", RFC 5036, October 2007. 1446 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 1447 System Confederations for BGP", RFC 5065, August 2007. 1449 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1450 Topology (MT) Routing in Intermediate System to 1451 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1453 [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control 1454 Mechanism in IS-IS Using Administrative Tags", RFC 5130, 1455 February 2008. 1457 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1458 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1459 May 2008. 1461 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1462 Engineering", RFC 5305, October 2008. 1464 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1465 of Generalized Multi-Protocol Label Switching (GMPLS)", 1466 RFC 5307, October 2008. 1468 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1469 Engineering in IS-IS", RFC 6119, February 2011. 1471 9.2. Informative References 1473 [I-D.ietf-alto-protocol] 1474 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1475 draft-ietf-alto-protocol-13 (work in progress), 1476 September 2012. 1478 [I-D.ietf-isis-mi] 1479 Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. 1480 Ward, "IS-IS Multi-Instance", draft-ietf-isis-mi-08 (work 1481 in progress), October 2012. 1483 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1484 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1486 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1487 Shaffer, "Extensions to OSPF for Advertising Optional 1488 Router Capabilities", RFC 4970, July 2007. 1490 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 1491 Extensions for Discovery of Traffic Engineering Node 1492 Capabilities", RFC 5073, December 2007. 1494 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1495 Path Computation Method for Establishing Inter-Domain 1496 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1497 RFC 5152, February 2008. 1499 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1500 Optimization (ALTO) Problem Statement", RFC 5693, 1501 October 2009. 1503 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1504 Management of New Protocols and Protocol Extensions", 1505 RFC 5706, November 2009. 1507 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1508 Instance Extensions", RFC 6549, March 2012. 1510 Authors' Addresses 1512 Hannes Gredler 1513 Juniper Networks, Inc. 1514 1194 N. Mathilda Ave. 1515 Sunnyvale, CA 94089 1516 US 1518 Email: hannes@juniper.net 1520 Jan Medved 1521 Cisco Systems, Inc. 1522 170, West Tasman Drive 1523 San Jose, CA 95134 1524 US 1526 Email: jmedved@cisco.com 1528 Stefano Previdi 1529 Cisco Systems, Inc. 1530 Via Del Serafico, 200 1531 Rome 00142 1532 Italy 1534 Email: sprevidi@cisco.com 1536 Adrian Farrel 1537 Juniper Networks, Inc. 1538 1194 N. Mathilda Ave. 1539 Sunnyvale, CA 94089 1540 US 1542 Email: afarrel@juniper.net 1544 Saikat Ray 1545 Cisco Systems, Inc. 1546 170, West Tasman Drive 1547 San Jose, CA 95134 1548 US 1550 Email: sairay@cisco.com