idnits 2.17.1 draft-raszuk-idr-bgp-auto-discovery-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 April 2022) is 727 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 informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Raszuk, Ed. 3 Internet-Draft Individual 4 Intended status: Standards Track J. Mitchell, Ed. 5 Expires: 31 October 2022 W. Kumari 6 Google 7 K. Patel 8 Arrcus 9 J. Scudder 10 Juniper Networks 11 29 April 2022 13 BGP Auto Discovery 14 draft-raszuk-idr-bgp-auto-discovery-08 16 Abstract 18 This document describes a method for automating portions of a 19 router's BGP configuration via discovery of BGP peers with which to 20 establish further sessions from an initial "bootstrap" router. This 21 method can apply for establishment of either Internal or External BGP 22 peering sessions. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 31 October 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Auto discovery mechanism . . . . . . . . . . . . . . . . . . 5 66 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 67 5. Capability Advertisement . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. History 79 An idea for IBGP Auto Mesh [I-D.raszuk-idr-ibgp-auto-mesh] was 80 originally presented at IETF 57. The concept made use of an IGP 81 (either ISIS or OSPF) for flooding BGP auto discovery information. 82 In this proposal both auto-discovery/bootstrapping and propagation of 83 BGP configuration parameters occur within the BGP4 protocol itself. 85 The IGP based IBGP discovery mechanism presented was well fitted to 86 the native IP switching, in which all nodes in the IGP need to 87 participate in BGP mesh. However, it also came with a number of 88 drawbacks, some of which include the requirement for leaking between 89 area boundaries or possible race conditions between disjoint flooding 90 paths from which the information arrived. 92 The BGP peer auto discovery mechanism described in this document was 93 conceived initially in 2008 as a way to distribute peering session 94 establishment information via BGP for IBGP applications which are 95 only active on the edge of the network. For example, these 96 applications include BGP MPLS IP VPNs [RFC4364], rt-constrain 97 [RFC4684], flow-spec [RFC5575], or Multicast VPNs [RFC6513]. However 98 the idea was not documented for the community to discuss further at 99 that time. 101 In 2011, another solution for BGP peer discovery that targeted EBGP 102 peer discovery for Internet Exchange Point (IXP) participants was 103 described in [I-D.wkumari-idr-socialite]. This idea was useful as a 104 potential alternative solution for operators who wished to maintain 105 individual peering sessions with other IXP participants, rather than 106 receiving information through route-servers operated by the IXP 107 operator without the associated administrative burden of configuring 108 and maintaining sessions with all the other participants. This draft 109 distributed the participant sessions information utilizing a BGP 110 capability code [RFC5492] that was ill-suited for updating the 111 information after initial session establishment. 113 This draft represents an attempt by the authors of both drafts to 114 provide a solution that can be used in multiple IBGP or EBGP 115 applications when the operator desires to automatically collect and 116 distribute basic BGP session establishment information from a 117 centralized BGP speaker. 119 2. Introduction 121 The base BGP-4 specification [RFC4271] utilizes TCP for session 122 establishment between peers, which requires prior knowledge of the 123 endpoint's address to which a BGP session should be targeted. This 124 endpoint in most deployments is configured manually by the operator 125 at each end of pair of network elements. In numerous applications, 126 the list of all valid endpoints may be available centrally; however, 127 the task of configuring or updating all of the network elements that 128 require this information becomes a much larger task. 130 The most typical application of this in most networks is the 131 establishment of a full mesh of IBGP routers to distribute standard 132 IPv4 and IPv6 unicast routing information, such as the Internet route 133 table, within an Autonomous System (AS). This was one of the reasons 134 that lead to the introduction of BGP Route Reflection [RFC4456]. The 135 most common benefits/drawbacks associated with route reflection are 136 listed below: 138 * Configuration ease when adding or deleting new IBGP peers 140 * Reduction number of TCP sessions to be handled by ASBRs/PEs 142 * Information reduction - best path propagation only 143 * Limitation for new applications that require more than best path 144 propagation 146 * Route instabilities caused by information reduction (ex: 147 oscillations) etc. ... 149 Another application which requires prior knowledge of a large number 150 of BGP endpoints is at Internet Exchange Points (IXP). These 151 networks are specifically built and operated as locations for 152 different networks to peer and exchange traffic. Multilateral 153 Interconnection at an IXP 154 [I-D.ietf-grow-ix-bgp-route-server-operations] is utilized to avoid 155 having each participant at the IXP having to contact all of the other 156 participants to enter into peering relationships, utilizing a Route 157 Server (RS). Some of the reasons why participants peer with route- 158 servers at IXPs include: 160 * reducing the administrative burden of arranging and configuring 161 BGP sessions with all the other participants 163 * not wanting (or being able) to carry views from all the 164 participants 166 * relying on the IXP operator to implement routing policy decisions 167 (see [I-D.ietf-idr-ix-bgp-route-server]) 169 This document describes an alternate solution for BGP peering session 170 endpoint information discovery. This alternate solution reduces the 171 administrative burden of configuring and maintaining BGP sessions in 172 both IBGP applications (such as the full or partial mesh) and EBGP 173 applications (such as at an IXP) as described above. This document 174 does not address the other reasons why operators may choose to take 175 alternative approaches that still require manual configuration or 176 relying other devices for routing information distribution; however, 177 auto-discovery and manual configuration are not mutually exclusive, 178 and it is expected that some network elements will utilize both 179 approaches. 181 In many cases existing route reflectors (in the IBGP use case) or 182 route-servers (in the IXP) case may be utilized for the bootstrapping 183 discovery mechanism in this document. This has several advantages: 185 * Re-use of already deployed devices for an add on and incremental 186 automated BGP peer discovery 188 * Current place and operation in the network is optimal for session 189 establishment for the relevant subset of clients that need the 190 information. 192 * A verification only mode to analyze and generate a warning only 193 message when manual IBGP peering configuration mistakes are 194 detected. 196 3. Auto discovery mechanism 198 The amount of discovery information distributed via this mechanism is 199 likely to be orders of magnitude less than the amount of underlying 200 prefix (or other information) distributed today by existing route 201 reflectors or route servers, so scalability for this mechanism should 202 not be a concern. 204 This mechanism is designed to work on a per AFI/SAFI basis. For 205 example, a currently deployed route reflector, providing route 206 reflection for IPv4 unicast routes could continue in that function 207 and at the same time provide a BGP peer discovery functionality for 208 that or other address families. That could have a very positive 209 effect for the deployment of any of the new address families as core 210 RRs would not need to be upgraded to support new address families yet 211 could still serve as information brokers for them. 213 In order to propagate information describing their BGP active 214 configuration (activated AFI/SAFIs) we propose to define a new 215 address family with the NLRI format of . 217 The new address family will inherit current BGP update & msg formats 218 as well as all necessary attributes used for normal and loop free BGP 219 route distribution. 221 The Group Identifier Group_ID is a four octet value, and Router_ID is 222 a four octet value [RFC6286]. 224 The new type code for the new BGP Peer Discovery AFI/SAFI will be 225 TBD1. 227 The role of the Group_ID is to allow scoped group creation in the 228 same ASN/AFI/SAFI tuple. If not set by the operator, implying all 229 peers will be in the same group, this value will be all zeros. 231 The way to group mesh interconnectivity is left to the operator. The 232 Group_ID could be used for instance to group sub-AS or RR clients (if 233 the RR is not doing client to client reflection), or for tying sets 234 of EBGP peers to specific policy. A similar model takes place today 235 for interconnecting confederation Sub-ASes as described in [RFC5065]. 237 A new BGP Peer Discovery Attribute is defined to carry information 238 about all activated and flagged for automatic provisioning AFI/SAFIs 239 by a given BGP speaker. The format of the new BGP Peer Discovery 240 Attribute is defined below in Figure 1: 242 +--------------------------------------------------+ 243 | Attr. Flags (1 octet) | Attr. Type Code (1 octet)| 244 +--------------------------------------------------+ 245 | Attribute Length (2 octets) | 246 +--------------------------------------------------+ 247 | AFI/SAFI Descriptors w Peering Addresses 1 (var) | 248 +--------------------------------------------------+ 249 | ... | 250 +--------------------------------------------------+ 251 | AFI/SAFI Descriptors w Peering Addresses N (var) | 252 +--------------------------------------------------+ 254 Figure 1: BGP Peer Discovery Attribute 256 The attribute flags and type code fields are detailed in Figure 2: 258 0 1 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |1|0|0|1|0|0|0|0| TBD | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 2: Flags & Type Code Fields 266 * Bit 0 - Optional attribute (value 1) 268 * Bit 1 - Non transitive attribute (value 0) 270 * Bit 2 - Partial bit (value 0 for optional non transitive 271 attributes) 273 * Bit 3 - Extended length of two octets (value 1) 275 * Bit 4-7 - Unused (value all zeros) 277 * Type code - Attribute type code TBD2 279 Each BGP Peer Discovery Attribute contains one or more of the AFI/ 280 SAFI Descriptors as shown in Figure 3: 282 +--------------------------------------------------+ 283 |O|F|I| Reserved | 284 +--------------------------------------------------+ 285 | Peer Autonomous System (4 octets) | 286 +--------------------------------------------------+ 287 | Peering AFI | AFI/SAFI Descriptor (3 octets) | 288 +--------------------------------------------------+ 289 | Identifier (4 octets) | 290 +--------------------------------------------------+ 291 | Peering Address (variable length based on AFI) | 292 +--------------------------------------------------+ 294 Figure 3: AFI/SAFI Descriptor 296 AFI/SAFI Descriptor Flags (1 octet): 298 * O bit - Route originator or EBGP speaker (Yes - 1, No - 0) 300 * F bit - Force new peering. Default not set - 0, set - 1. 302 * I bit - Informational only (Do not attempt to establish a BGP 303 connection) 305 Peer Autonomous System Number: 307 * This is the neighbor's BGP Autonomous System Number (ASN), as 308 described in [RFC6793], that should be expected for peering, iBGP 309 if it matches the local router ASN, eBGP otherwise. 311 Identifier: 313 * This field is set to 0. If a non-zero value is set then the peer 314 connection should be viewed as a tuple of . 315 Also at the same time the peer connection should be viewed as 316 and a separate connection should be 317 initiated if the peer connection is not yet established. 319 Peering Address: 321 * Depending on the value of Peering AFI peering address on which BGP 322 speaker is expecting to receive BGP session OPEN messages. 324 The special value of AFI/SAFI Descriptor can be all zeros. That will 325 indicate that the information contained in the Group_id applies to 326 all AFI/SAFIs given receiver supports. In those cases BGP OPEN msg 327 will negotiate the subset of AFI/SAFIs to be established between 328 given BGP peers. 330 It is expected that when Router_ID is changed on the BGP speaker 331 sessions are restarted and therefore NLRI received with the former 332 Router_ID withdrawn. When sessions restart, the new Router_ID will 333 be sent in the NLRI corresponding to the BGP speaker with the 334 reconfigured Router_ID. It is highly advised to change Router_ID 335 only when critical as the impact to BGP is for any AFI/SAFI sever. 336 An implementation may force the user to configure BGP Router_ID 337 explicitly, before activating the new BGP Peer Discovery AFI/SAFI. 339 From the RR perspective as each BGP speaker can have only one 340 Router_ID value, there would be only a single BGP Peer Discovery NLRI 341 originated by one. It was a conscious design decision not to create 342 a new BGP attribute for the reflector and require route reflector to 343 build an aggregate list of AFI/SAFI descriptors common to given set 344 of BGP Peer Discovery NLRIs in such a new attribute. We prefer to 345 allow RR to remain simple with no additional code changes required 346 for the price of no update packing possibility when it handles BGP 347 Peer Discovery NLRIs in an atomic way. 349 Implementations MAY support local configuration of all possible 350 remote peering address ranges, autonomous system numbers or other 351 filters expected to be received via BGP Peer Discovery, or on a per 352 group basis. Implementations SHOULD allow operators to group 353 specific auto-discovered peers with specific groups based on 354 Group_ID. 356 On the receive side, a persistent cache SHOULD be maintained by BGP 357 with all received information about other BGP speakers announcing 358 their BGP Peer Discovery information in a given Group's scope. 360 BGP Peer Discovery implementation should allow for per address 361 family, subsequent address family and Group_ID disjoint topologies 362 granularity. 364 When multiple AFI/SAFI pairs match on any two BGP speakers and value 365 of the Identifier passed on AFI/SAFI Descriptor field is set to all 366 zeros only one BGP session should be attempted. Regular BGP 367 capabilities will be used to negotiate given AFI/SAFI mutual set. 368 AFI/SAFI granularity is required to allow for disjoint topologies of 369 different information being distributed by BGP. 371 BGP speakers "O" flag eligible may establish session with any other 372 BGP speaker if passing all peering criteria for a given AFI/SAFI. 374 BGP speakers "O" flag not eligible (ex: P routers) should not 375 establish IBGP peering to any other "O" flag not eligible BGP 376 speakers. 378 When peering address changes for an existing AFI/SAFI and new BGP 379 update is received with the new peering address old peering should 380 remain intact when "F" flag is not set (default = 0). When session 381 is cleared manually or goes down for any other reason, the new 382 peering address should be used. 384 When "F" flag is set new peering address should be used immediately 385 and current BGP session to the peer restarted for given AFI/SAFI. 387 4. Deployment Considerations 389 All implementations SHOULD still allow manual neighbor establishments 390 which in fact could be complimentary and co-existing to the BGP Peer 391 Auto Discovery neighbors. 393 In addition BGP Peer Auto Discovery exchange can be enabled just for 394 informational purposes while provisioning would remain manual before 395 operational teams get familiar with new capability and verify it's 396 mechanics. 398 Within each Group_ID upon which auto-discovery is enabled, it is 399 expected that neighbors will form sessions with all peers received 400 within the group. This allows the building of full-mesh or partial- 401 mesh topologies of peers for iBGP by varying the Group_ID field. 403 Incremental deployment with enabling just a few routers to advertise 404 BGP Peer Discovery AF while maintaining manual configuration based 405 peering with the rest of the network is supported. 407 Another key aspect of today's BGP deployment, other then peer to peer 408 filtering push via ORF [RFC5292], is outbound customization of BGP 409 information to be distributed among various peers. The most common 410 tools for such customization could be peer templates, peer groups or 411 any other similar local configuration grouping. Individual members 412 of such groups can still be added to them manually, and BGP auto- 413 discovery peers can be grouped to such groups using the Group_ID. 414 The Peer Discovery implementation supports the ability to specify 415 peer ranges which could automatically achieve addition or deletion of 416 BGP peers to such groups. This can save a lot of manual 417 configuration and customization for outbound policies shared by 418 multiple peers. Individual session customization would be still 419 possible by manual provisioning. 421 5. Capability Advertisement 423 A BGP speaker that wishes to exchange BGP Peer Discovery Information 424 must use the the BGP Multiprotocol Extensions Capability Code as 425 defined in [RFC4760], to advertise the corresponding (AFI, SAFI) 426 pair. 428 6. IANA Considerations 430 This document defines a new BGP Auto Discovery SAFI type code TBD1 431 which will be used to carry local BGP peering configuration data. 432 That value will need to be assigned by IANA from BGP SAFI Type Code 433 space. 435 This document defines a new NLRI format, called BGP Auto Discovery 436 NLRI, to be carried in BGP Auto Discovery SAFI using BGP 437 multiprotocol extensions. This document defines a new BGP optional 438 transitive attribute, called BGP Peer Discovery Attribute. A new 439 attribute type code TBD2 is to be assigned by IANA from the BGP path 440 attribute Type Code space. 442 This document defines a new BGP Capability Type code (TBD3) to be 443 allocated by IANA. 445 Once TBD1, TBD2, and TBD3 values are allocated please replace them in 446 the above text. 448 7. Security Considerations 450 This document allows for local configuration of BGP authentication 451 mechanisms such as BGP-MD5 [RFC2385] or TCP-AO [RFC5925] and these 452 are highly recommended for deployment on the BGP peer auto-discovery 453 neighbor sessions. Similar authentication could be configured on a 454 per peer or peer-group basis based on the auto-discovery information 455 received before session establishment, however no exchange of 456 authentication information occurs within the protocol itself. 457 Operators SHOULD NOT use peer auto-discovery with untrusted peers as 458 attacks on implementation scalability could be triggered by 459 overwhelming the router with a larger number of auto-discovery peers 460 then can be supported. Operators should also use caution on what 461 addresses and AFI/SAFI combinations they want to allow reception of 462 auto-discovery information for. 464 8. Contributors 466 The BGP auto-discovery idea contained in this document was originally 467 developed by Pedro Roque Margues and Robert Raszuk in 2008 to cover 468 the IBGP full mesh use case however it was not published at that 469 time. 471 9. Acknowledgments 473 TBD 475 10. References 477 10.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 485 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 486 DOI 10.17487/RFC4271, January 2006, 487 . 489 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 490 Autonomous System (AS) Number Space", RFC 6793, 491 DOI 10.17487/RFC6793, December 2012, 492 . 494 10.2. Informative References 496 [I-D.ietf-grow-ix-bgp-route-server-operations] 497 Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker, 498 "Internet Exchange BGP Route Server Operations", Work in 499 Progress, Internet-Draft, draft-ietf-grow-ix-bgp-route- 500 server-operations-05, 8 June 2015, 501 . 504 [I-D.ietf-idr-ix-bgp-route-server] 505 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 506 "Internet Exchange BGP Route Server", Work in Progress, 507 Internet-Draft, draft-ietf-idr-ix-bgp-route-server-12, 30 508 June 2016, . 511 [I-D.raszuk-idr-ibgp-auto-mesh] 512 Raszuk, R., "IBGP Auto Mesh", Work in Progress, Internet- 513 Draft, draft-raszuk-idr-ibgp-auto-mesh-00, 24 June 2003, 514 . 517 [I-D.wkumari-idr-socialite] 518 Kumari, W., Patel, K., and J. Scudder, "Automagic peering 519 at IXPs.", Work in Progress, Internet-Draft, draft- 520 wkumari-idr-socialite-02, 18 October 2012, 521 . 524 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 525 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 526 1998, . 528 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 529 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 530 2006, . 532 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 533 Reflection: An Alternative to Full Mesh Internal BGP 534 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 535 . 537 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 538 R., Patel, K., and J. Guichard, "Constrained Route 539 Distribution for Border Gateway Protocol/MultiProtocol 540 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 541 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 542 November 2006, . 544 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 545 "Multiprotocol Extensions for BGP-4", RFC 4760, 546 DOI 10.17487/RFC4760, January 2007, 547 . 549 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 550 System Confederations for BGP", RFC 5065, 551 DOI 10.17487/RFC5065, August 2007, 552 . 554 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 555 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 556 August 2008, . 558 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 559 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 560 2009, . 562 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 563 and D. McPherson, "Dissemination of Flow Specification 564 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 565 . 567 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 568 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 569 June 2010, . 571 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 572 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 573 June 2011, . 575 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 576 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 577 2012, . 579 Authors' Addresses 581 Robert Raszuk (editor) 582 Individual 583 Email: robert@raszuk.net 585 Jon Mitchell (editor) 586 Google 587 1600 Amphitheatre Parkway 588 Mountain View, CA 94043 589 United States of America 590 Email: jrmitche@puck.nether.net 592 Warren Kumari 593 Google 594 1600 Amphitheatre Parkway 595 Mountain View, CA, 94043 596 United States of America 597 Email: warren@kumari.net 599 Keyur Patel 600 Arrcus 601 United States of America 602 Email: keyur@arrcus.com 603 John Scudder 604 Juniper Networks 605 1194 N. Mathilda Ave 606 Sunnyvale, CA 607 United States of America 608 Email: jgs@juniper.net