idnits 2.17.1 draft-raszuk-idr-bgp-auto-discovery-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (May 31, 2016) is 2885 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) == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-10 -- 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 (~~), 2 warnings (==), 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 Bloomberg LP 4 Intended status: Standards Track J. Mitchell, Ed. 5 Expires: December 2, 2016 W. Kumari 6 Google 7 K. Patel 8 Cisco Systems 9 J. Scudder 10 Juniper Networks 11 May 31, 2016 13 BGP Auto Discovery 14 draft-raszuk-idr-bgp-auto-discovery-05 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 http://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 December 2, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Auto discovery mechanism . . . . . . . . . . . . . . . . . . 5 67 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 68 5. Capability Advertisement . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 10.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. History 80 An idea for IBGP Auto Mesh [I-D.raszuk-idr-ibgp-auto-mesh] was 81 originally presented at IETF 57. The concept made use of an IGP 82 (either ISIS or OSPF) for flooding BGP auto discovery information. 83 In this proposal both auto-discovery/bootstrapping and propagation of 84 BGP configuration parameters occur within the BGP4 protocol itself. 86 The IGP based IBGP discovery mechanism presented was well fitted to 87 the native IP switching, in which all nodes in the IGP need to 88 participate in BGP mesh. However, it also came with a number of 89 drawbacks, some of which include the requirement for leaking between 90 area boundaries or possible race conditions between disjoint flooding 91 paths from which the information arrived. 93 The BGP peer auto discovery mechanism described in this document was 94 conceived initially in 2008 as a way to distribute peering session 95 establishment information via BGP for IBGP applications which are 96 only active on the edge of the network. For example, these 97 applications include BGP MPLS IP VPNs [RFC4364], rt-constrain 98 [RFC4684], flow-spec [RFC5575], or Multicast VPNs [RFC6513]. However 99 the idea was not documented for the community to discuss further at 100 that time. 102 In 2011, another solution for BGP peer discovery that targeted EBGP 103 peer discovery for Internet Exchange Point (IXP) participants was 104 described in [I-D.wkumari-idr-socialite]. This idea was useful as a 105 potential alternative solution for operators who wished to maintain 106 individual peering sessions with other IXP participants, rather than 107 receiving information through route-servers operated by the IXP 108 operator without the associated administrative burden of configuring 109 and maintaining sessions with all the other participants. This draft 110 distributed the participant sessions information utilizing a BGP 111 capability code [RFC5492] that was ill-suited for updating the 112 information after initial session establishment. 114 This draft represents an attempt by the authors of both drafts to 115 provide a solution that can be used in multiple IBGP or EBGP 116 applications when the operator desires to automatically collect and 117 distribute basic BGP session establishment information from a 118 centralized BGP speaker. 120 2. Introduction 122 The base BGP-4 specification [RFC4271] utilizes TCP for session 123 establishment between peers, which requires prior knowledge of the 124 endpoint's address to which a BGP session should be targeted. This 125 endpoint in most deployments is configured manually by the operator 126 at each end of pair of network elements. In numerous applications, 127 the list of all valid endpoints may be available centrally; however, 128 the task of configuring or updating all of the network elements that 129 require this information becomes a much larger task. 131 The most typical application of this in most networks is the 132 establishment of a full mesh of IBGP routers to distribute standard 133 IPv4 and IPv6 unicast routing information, such as the Internet route 134 table, within an Autonomous System (AS). This was one of the reasons 135 that lead to the introduction of BGP Route Reflection [RFC4456]. The 136 most common benefits/drawbacks associated with route reflection are 137 listed below: 139 o Configuration ease when adding or deleting new IBGP peers 141 o Reduction number of TCP sessions to be handled by ASBRs/PEs 142 o Information reduction - best path propagation only 144 o Limitation for new applications that require more than best path 145 propagation 147 o Route instabilities caused by information reduction (ex: 148 oscillations) etc. ... 150 Another application which requires prior knowledge of a large number 151 of BGP endpoints is at Internet Exchange Points (IXP). These 152 networks are specifically built and operated as locations for 153 different networks to peer and exchange traffic. Multilateral 154 Interconnection at an IXP 155 [I-D.ietf-grow-ix-bgp-route-server-operations] is utilized to avoid 156 having each participant at the IXP having to contact all of the other 157 participants to enter into peering relationships, utilizing a Route 158 Server (RS). Some of the reasons why participants peer with route- 159 servers at IXPs include: 161 o reducing the administrative burden of arranging and configuring 162 BGP sessions with all the other participants 164 o not wanting (or being able) to carry views from all the 165 participants 167 o relying on the IXP operator to implement routing policy decisions 168 (see [I-D.ietf-idr-ix-bgp-route-server]) 170 This document describes an alternate solution for BGP peering session 171 endpoint information discovery. This alternate solution reduces the 172 administrative burden of configuring and maintaining BGP sessions in 173 both IBGP applications (such as the full or partial mesh) and EBGP 174 applications (such as at an IXP) as described above. This document 175 does not address the other reasons why operators may choose to take 176 alternative approaches that still require manual configuration or 177 relying other devices for routing information distribution; however, 178 auto-discovery and manual configuration are not mutually exclusive, 179 and it is expected that some network elements will utilize both 180 approaches. 182 In many cases existing route reflectors (in the IBGP use case) or 183 route-servers (in the IXP) case may be utilized for the bootstrapping 184 discovery mechanism in this document. This has several advantages: 186 o Re-use of already deployed devices for an add on and incremental 187 automated BGP peer discovery 189 o Current place and operation in the network is optimal for session 190 establishment for the relevant subset of clients that need the 191 information. 193 o A verification only mode to analyze and generate a warning only 194 message when manual IBGP peering configuration mistakes are 195 detected. 197 3. Auto discovery mechanism 199 The amount of discovery information distributed via this mechanism is 200 likely to be orders of magnitude less than the amount of underlying 201 prefix (or other information) distributed today by existing route 202 reflectors or route servers, so scalability for this mechanism should 203 not be a concern. 205 This mechanism is designed to work on a per AFI/SAFI basis. For 206 example, a currently deployed route reflector, providing route 207 reflection for IPv4 unicast routes could continue in that function 208 and at the same time provide a BGP peer discovery functionality for 209 that or other address families. That could have a very positive 210 effect for the deployment of any of the new address families as core 211 RRs would not need to be upgraded to support new address families yet 212 could still serve as information brokers for them. 214 In order to propagate information describing their BGP active 215 configuration (activated AFI/SAFIs) we propose to define a new 216 address family with the NLRI format of . 218 The new address family will inherit current BGP update & msg formats 219 as well as all necessary attributes used for normal and loop free BGP 220 route distribution. 222 The Group Identifier Group_ID is a four octet value, and Router_ID is 223 a four octet value [RFC6286]. 225 The new type code for the new BGP Peer Discovery AFI/SAFI will be 226 TBD1. 228 The role of the Group_ID is to allow scoped group creation in the 229 same ASN/AFI/SAFI tuple. If not set by the operator, implying all 230 peers will be in the same group, this value will be all zeros. 232 The way to group mesh interconnectivity is left to the operator. The 233 Group_ID could be used for instance to group sub-AS or RR clients (if 234 the RR is not doing client to client reflection), or for tying sets 235 of EBGP peers to specific policy. A similar model takes place today 236 for interconnecting confederation Sub-ASes as described in [RFC5065]. 238 A new BGP Peer Discovery Attribute is defined to carry information 239 about all activated and flagged for automatic provisioning AFI/SAFIs 240 by a given BGP speaker. The format of the new BGP Peer Discovery 241 Attribute is defined below in Figure 1: 243 +--------------------------------------------------+ 244 | Attr. Flags (1 octet) | Attr. Type Code (1 octet)| 245 +--------------------------------------------------+ 246 | Attribute Length (2 octets) | 247 +--------------------------------------------------+ 248 | AFI/SAFI Descriptors w Peering Addresses 1 (var) | 249 +--------------------------------------------------+ 250 | ... | 251 +--------------------------------------------------+ 252 | AFI/SAFI Descriptors w Peering Addresses N (var) | 253 +--------------------------------------------------+ 255 Figure 1: BGP Peer Discovery Attribute 257 The attribute flags and type code fields are detailed in Figure 2: 259 0 1 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |1|0|0|1|0|0|0|0| TBD | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: Flags & Type Code Fields 267 o Bit 0 - Optional attribute (value 1) 269 o Bit 1 - Non transitive attribute (value 0) 271 o Bit 2 - Partial bit (value 0 for optional non transitive 272 attributes) 274 o Bit 3 - Extended length of two octets (value 1) 276 o Bit 4-7 - Unused (value all zeros) 278 o Type code - Attribute type code TBD2 280 Each BGP Peer Discovery Attribute contains one or more of the AFI/ 281 SAFI Descriptors as shown in Figure 3: 283 +--------------------------------------------------+ 284 |O|F|I| Reserved | 285 +--------------------------------------------------+ 286 | Peer Autonomous System (4 octets) | 287 +--------------------------------------------------+ 288 | Peering AFI | AFI/SAFI Descriptor (3 octets) | 289 +--------------------------------------------------+ 290 | Identifier (4 octets) | 291 +--------------------------------------------------+ 292 | Peering Address (variable length based on AFI) | 293 +--------------------------------------------------+ 295 Figure 3: AFI/SAFI Descriptor 297 AFI/SAFI Descriptor Flags (1 octet): 299 o O bit - Route originator or EBGP speaker (Yes - 1, No - 0) 301 o F bit - Force new peering. Default not set - 0, set - 1. 303 o I bit - Informational only (Do not attempt to establish a BGP 304 connection) 306 Peer Autonomous System Number: 308 o This is the neighbor's BGP Autonomous System Number (ASN), as 309 described in [RFC6793], that should be expected for peering, iBGP 310 if it matches the local router ASN, eBGP otherwise. 312 Identifier: 314 o This field is set to 0. If a non-zero value is set then the peer 315 connection should be viewed as a tuple of . 316 Also at the same time the peer connection should be viewed as 317 and a separate connection should be 318 initiated if the peer connection is not yet established. 320 Peering Address: 322 o Depending on the value of Peering AFI peering address on which BGP 323 speaker is expecting to receive BGP session OPEN messages. 325 The special value of AFI/SAFI Descriptor can be all zeros. That will 326 indicate that the information contained in the Group_id applies to 327 all AFI/SAFIs given receiver supports. In those cases BGP OPEN msg 328 will negotiate the subset of AFI/SAFIs to be established between 329 given BGP peers. 331 It is expected that when Router_ID is changed on the BGP speaker 332 sessions are restarted and therefore NLRI received with the former 333 Router_ID withdrawn. When sessions restart, the new Router_ID will 334 be sent in the NLRI corresponding to the BGP speaker with the 335 reconfigured Router_ID. It is highly advised to change Router_ID 336 only when critical as the impact to BGP is for any AFI/SAFI sever. 337 An implementation may force the user to configure BGP Router_ID 338 explicitly, before activating the new BGP Peer Discovery AFI/SAFI. 340 From the RR perspective as each BGP speaker can have only one 341 Router_ID value, there would be only a single BGP Peer Discovery NLRI 342 originated by one. It was a conscious design decision not to create 343 a new BGP attribute for the reflector and require route reflector to 344 build an aggregate list of AFI/SAFI descriptors common to given set 345 of BGP Peer Discovery NLRIs in such a new attribute. We prefer to 346 allow RR to remain simple with no additional code changes required 347 for the price of no update packing possibility when it handles BGP 348 Peer Discovery NLRIs in an atomic way. 350 Implementations MAY support local configuration of all possible 351 remote peering address ranges, autonomous system numbers or other 352 filters expected to be received via BGP Peer Discovery, or on a per 353 group basis. Implementations SHOULD allow operators to group 354 specific auto-discovered peers with specific groups based on 355 Group_ID. 357 On the receive side, a persistent cache SHOULD be maintained by BGP 358 with all received information about other BGP speakers announcing 359 their BGP Peer Discovery information in a given Group's scope. 361 BGP Peer Discovery implementation should allow for per address 362 family, subsequent address family and Group_ID disjoint topologies 363 granularity. 365 When multiple AFI/SAFI pairs match on any two BGP speakers and value 366 of the Identifier passed on AFI/SAFI Descriptor field is set to all 367 zeros only one BGP session should be attempted. Regular BGP 368 capabilities will be used to negotiate given AFI/SAFI mutual set. 369 AFI/SAFI granularity is required to allow for disjoint topologies of 370 different information being distributed by BGP. 372 BGP speakers "O" flag eligible may establish session with any other 373 BGP speaker if passing all peering criteria for a given AFI/SAFI. 375 BGP speakers "O" flag not eligible (ex: P routers) should not 376 establish IBGP peering to any other "O" flag not eligible BGP 377 speakers. 379 When peering address changes for an existing AFI/SAFI and new BGP 380 update is received with the new peering address old peering should 381 remain intact when "F" flag is not set (default = 0). When session 382 is cleared manually or goes down for any other reason, the new 383 peering address should be used. 385 When "F" flag is set new peering address should be used immediately 386 and current BGP session to the peer restarted for given AFI/SAFI. 388 4. Deployment Considerations 390 All implementations SHOULD still allow manual neighbor establishments 391 which in fact could be complimentary and co-existing to the BGP Peer 392 Auto Discovery neighbors. 394 In addition BGP Peer Auto Discovery exchange can be enabled just for 395 informational purposes while provisioning would remain manual before 396 operational teams get familiar with new capability and verify it's 397 mechanics. 399 Within each Group_ID upon which auto-discovery is enabled, it is 400 expected that neighbors will form sessions with all peers received 401 within the group. This allows the building of full-mesh or partial- 402 mesh topologies of peers for iBGP by varying the Group_ID field. 404 Incremental deployment with enabling just a few routers to advertise 405 BGP Peer Discovery AF while maintaining manual configuration based 406 peering with the rest of the network is supported. 408 Another key aspect of today's BGP deployment, other then peer to peer 409 filtering push via ORF [RFC5292], is outbound customization of BGP 410 information to be distributed among various peers. The most common 411 tools for such customization could be peer templates, peer groups or 412 any other similar local configuration grouping. Individual members 413 of such groups can still be added to them manually, and BGP auto- 414 discovery peers can be grouped to such groups using the Group_ID. 415 The Peer Discovery implementation supports the ability to specify 416 peer ranges which could automatically achieve addition or deletion of 417 BGP peers to such groups. This can save a lot of manual 418 configuration and customization for outbound policies shared by 419 multiple peers. Individual session customization would be still 420 possible by manual provisioning. 422 5. Capability Advertisement 424 A BGP speaker that wishes to exchange BGP Peer Discovery Information 425 must use the the BGP Multiprotocol Extensions Capability Code as 426 defined in [RFC4760], to advertise the corresponding (AFI, SAFI) 427 pair. 429 6. IANA Considerations 431 This document defines a new BGP Auto Discovery SAFI type code TBD1 432 which will be used to carry local BGP peering configuration data. 433 That value will need to be assigned by IANA from BGP SAFI Type Code 434 space. 436 This document defines a new NLRI format, called BGP Auto Discovery 437 NLRI, to be carried in BGP Auto Discovery SAFI using BGP 438 multiprotocol extensions. This document defines a new BGP optional 439 transitive attribute, called BGP Peer Discovery Attribute. A new 440 attribute type code TBD2 is to be assigned by IANA from the BGP path 441 attribute Type Code space. 443 This document defines a new BGP Capability Type code (TBD3) to be 444 allocated by IANA. 446 Once TBD1, TBD2, and TBD3 values are allocated please replace them in 447 the above text. 449 7. Security Considerations 451 This document allows for local configuration of BGP authentication 452 mechanisms such as BGP-MD5 [RFC2385] or TCP-AO [RFC5925] and these 453 are highly recommended for deployment on the BGP peer auto-discovery 454 neighbor sessions. Similar authentication could be configured on a 455 per peer or peer-group basis based on the auto-discovery information 456 received before session establishment, however no exchange of 457 authentication information occurs within the protocol itself. 458 Operators SHOULD NOT use peer auto-discovery with untrusted peers as 459 attacks on implementation scalability could be triggered by 460 overwhelming the router with a larger number of auto-discovery peers 461 then can be supported. Operators should also use caution on what 462 addresses and AFI/SAFI combinations they want to allow reception of 463 auto-discovery information for. 465 8. Contributors 467 The BGP auto-discovery idea contained in this document was originally 468 developed by Pedro Roque Margues and Robert Raszuk in 2008 to cover 469 the IBGP full mesh use case however it was not published at that 470 time. 472 9. Acknowledgments 474 TBD 476 10. References 478 10.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 486 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 487 DOI 10.17487/RFC4271, January 2006, 488 . 490 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 491 Autonomous System (AS) Number Space", RFC 6793, 492 DOI 10.17487/RFC6793, December 2012, 493 . 495 10.2. Informative References 497 [I-D.ietf-grow-ix-bgp-route-server-operations] 498 Hilliard, N., Jasinska, E., Raszuk, R., and N. Bakker, 499 "Internet Exchange BGP Route Server Operations", draft- 500 ietf-grow-ix-bgp-route-server-operations-05 (work in 501 progress), June 2015. 503 [I-D.ietf-idr-ix-bgp-route-server] 504 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 505 "Internet Exchange BGP Route Server", draft-ietf-idr-ix- 506 bgp-route-server-10 (work in progress), April 2016. 508 [I-D.raszuk-idr-ibgp-auto-mesh] 509 Raszuk, R., "IBGP Auto Mesh", draft-raszuk-idr-ibgp-auto- 510 mesh-00 (work in progress), June 2003. 512 [I-D.wkumari-idr-socialite] 513 Kumari, W., Patel, K., and J. Scudder, "Automagic peering 514 at IXPs.", draft-wkumari-idr-socialite-02 (work in 515 progress), October 2012. 517 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 518 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 519 1998, . 521 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 522 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 523 2006, . 525 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 526 Reflection: An Alternative to Full Mesh Internal BGP 527 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 528 . 530 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 531 R., Patel, K., and J. Guichard, "Constrained Route 532 Distribution for Border Gateway Protocol/MultiProtocol 533 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 534 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 535 November 2006, . 537 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 538 "Multiprotocol Extensions for BGP-4", RFC 4760, 539 DOI 10.17487/RFC4760, January 2007, 540 . 542 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 543 System Confederations for BGP", RFC 5065, 544 DOI 10.17487/RFC5065, August 2007, 545 . 547 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 548 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 549 August 2008, . 551 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 552 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 553 2009, . 555 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 556 and D. McPherson, "Dissemination of Flow Specification 557 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 558 . 560 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 561 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 562 June 2010, . 564 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 565 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 566 June 2011, . 568 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 569 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 570 2012, . 572 Authors' Addresses 574 Robert Raszuk (editor) 575 Bloomberg LP 576 731 Lexington Ave 577 New York City, NY 10022 578 USA 580 Email: robert@raszuk.net 582 Jon Mitchell (editor) 583 Google 584 1600 Amphitheatre Parkway 585 Mountain View, CA 94043 586 US 588 Email: jrmitche@puck.nether.net 590 Warren Kumari 591 Google 592 1600 Amphitheatre Parkway 593 Mountain View, CA 94043 594 US 596 Email: warren@kumari.net 598 Keyur Patel 599 Cisco Systems 600 170 West Tasman Dr. 601 San Jose, CA 95135 602 US 604 Email: keyupate@cisco.com 605 John Scudder 606 Juniper Networks 607 1194 N. Mathilda Ave 608 Sunnyvale CA 609 USA 611 Email: jgs@juniper.net