idnits 2.17.1 draft-wang-idr-rd-orf-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2020) is 1247 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) == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 540, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-11 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group W. Wang 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: May 27, 2021 H. Wang 6 Huawei Technologies 7 G. Mishra 8 Verizon Inc. 9 S. Zhuang 10 J. Dong 11 Huawei Technologies 12 November 23, 2020 14 Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4 15 draft-wang-idr-rd-orf-05 17 Abstract 19 This draft defines a new Outbound Route Filter (ORF) type, called the 20 Route Distinguisher ORF (RD-ORF). RD-ORF is applicable when the 21 routers do not exchange VPN routing information directly (e.g. 22 routers in single-domain connect via Route Reflector, or routers in 23 Option B/Option AB/Option C cross-domain scenario). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 27, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. RD-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Application in single-domain scenario . . . . . . . . . . . . 6 64 5.1. Addition of RD-ORF entries . . . . . . . . . . . . . . . 6 65 5.1.1. Operation process of RD-ORF mechanism on source PE . 7 66 5.1.2. Operation process of RD-ORF mechanism on RR . . . . . 8 67 5.1.3. Operation process of RD-ORF mechanism on target PE . 9 68 5.2. Withdraw of RD-ORF entries . . . . . . . . . . . . . . . 9 69 6. Applications in cross-domain scenarios . . . . . . . . . . . 9 70 6.1. Application in Option B/Option AB cross-domain scenario . 9 71 6.2. Application in Option C cross-domain scenario . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 With the rapid growth of network scale, Route Reflector is introduced 81 in order to reduce the network complexity. Routers in the same 82 Autonomous System only need to establish iBGP session with RR to 83 transmit routes. 85 In VPN scenario shown in Figure 1, PE1 - PE4 establish IBGP sessions 86 with RR to ensure the routes can be transmitted within AS100, where 87 PE1 and PE3 maintain VRFs of VPN1 and VPN2, PE2 maintains VPN1's VRF 88 and PE4 maintains VPN2's VRF. RR don not maintain any VRFs. 90 +----------------------------------------------+ 91 | | 92 | | 93 | +---------+ +---------+ | 94 | | PE1 | | PE4 | | 95 | +---------+ +---------+ | 96 | VPN1(RD1) \ / VPN2(RD2) | 97 | VPN2(RD2) \+---------+ / | 98 | | | | 99 | | RR | | 100 | | | | 101 | +---------+ \ | 102 | / \ | 103 | +---------+/ +---------+ | 104 | | PE2 | | PE3 | | 105 | +---------+ +---------+ | 106 | VPN1(RD1) VPN1(RD1) | 107 | AS 100 VPN2(RD2) | 108 +----------------------------------------------+ 110 Figure 1: Single-domain scenario 112 When the VRF of VPN1 in PE1 overflows, due to PE1 and other PEs are 113 not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the 114 problem on PE2 cannot be known. 116 Now, there are several solutions can be used to alleviate this 117 problem: 119 o Route Target Constraint (RTC) as defined in [RFC4684] 121 o Address Prefix ORF as defined in [RFC5292] 123 o PE-CE edge peer Maximum Prefix 125 o Configure the Maximum Prefix for each VRF on edge nodes 127 However, there are limitations to existing solutions: 129 1) Route Target Constraint 131 RTC can only filter the VPN routes from the uninterested VRFs, if the 132 "trashing routes" come from the interested VRF, filter on RTs will 133 erase all prefixes from this VRF. 135 2) Address Prefix ORF 136 Using Address Prefix ORF to filter VPN routes need to pre- 137 configuration, but it is impossible to know which prefix may cause 138 overflow in advance. 140 3) PE-CE edge peer Maximum Prefix 142 This mechanism can only protect the edge between PE-CE, it can't be 143 deployed within PE that peered via RR. Depending solely on the edge 144 protection is dangerous, because if only one of the edge points being 145 comprised/error-configured/attacked, then all of PEs within domain 146 are under risk. 148 4) Configure the Maximum Prefix for each VRF on edge nodes 150 When a VRF overflows, it stops the import of routes and log the extra 151 VPN routes into its RIB. However, PEs should parse the BGP updates. 152 These processes will cost CPU cycles and further burden the 153 overflowing PE. 155 This draft defines a new ORF-type, called the Route Distinguisher ORF 156 (RD-ORF). Using RD-ORF mechanism, VPN routes of a VPN can be 157 controlled based on source RD. This mechanism is event-driven and 158 does not need to be pre-configured. When a VRF of a router 159 overflows, the router will find out the main source RD of VPN routes 160 in this VRF, and send a RD-ORF to its BGP peer that carrys the RD. 161 If a BGP speaker receives a RD-ORF from its BGP peer, it will filter 162 the VPN routes it tends to send according to the RD-ORF entry. 164 RD-ORF is applicable when the routers do not exchange VPN routing 165 information directly (e.g. routers in single-domain connect via Route 166 Reflector, or routers in Option B/Option AB/Option C cross-domain 167 scenario). 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119] . 175 3. Terminology 177 The following terms are defined in this draft: 179 o RD: Route Distinguisher, defined in [RFC4364] 181 o ORF: Outbound Route Filter, defined in [RFC5291] 183 o AFI: Address Family Identifier, defined in [RFC4760] 184 o SAFI: Subsequent Address Family Identifier, defined in [RFC4760] 186 o EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] 188 o RR: Router Reflector, provides a simple solution to the problem of 189 IBGP full mesh connection in large-scale IBGP implementation. 191 o VRF: Virtual Routing Forwarding, a virtual routing table based on 192 VPN instance. 194 4. RD-ORF Encoding 196 In this draft, we defined a new ORF type called Route Distinguisher 197 Outbound Route Filter (RD-ORF). The ORF entries are carried in the 198 BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE- 199 REFRESH message can carry one or more ORF entries, and MUST be 200 regenerated when it is tended to be sent to other BGP peers. The 201 ROUTE-REFRESH message which carries ORF entries contains the 202 following fields: 204 o AFI (2 octets) 206 o SAFI (1 octet) 208 o When-to-refresh (1 octet): the value is IMMEDIATE or DEFER 210 o ORF Type (1 octet) 212 o Length of ORF entries (2 octets) 214 A RD-ORF entry contains a common part and type-specific part. The 215 common part is encoded as follows: 217 o Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL 219 o Match (1 bit): the value is PERMIT or DENY 221 o Reserved (5 bits) 223 RD-ORF also contains type-specific part. The encoding of the type- 224 specific part is shown in Figure 2. 226 +-----------------------------------------+ 227 | | 228 | Sequence (4 octets) | 229 | | 230 +-----------------------------------------+ 231 | | 232 | Route Distinguisher (8 octets) | 233 | | 234 +-----------------------------------------+ 236 Figure 2: RD-ORF type-specific encoding 238 o Sequence: identifying the order in which RD-ORF is generated 240 o Route Distinguisher: distinguish the different user routes. The 241 RD-ORF filters the VPN routes it tends to send based on Route 242 Distinguisher. 244 Note that if the Action component of an ORF entry specifies REMOVE- 245 ALL, the ORF entry does not include the type-specific part. 247 When the BGP ROUTE-REFRESH message carries RD-ORF entries, it must be 248 set as follows: 250 o The ORF-Type MUST be set to RD-ORF. 252 o The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). 254 o If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS- 255 labeled VPN address. 257 o If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. 259 o The Match field MUST be equal to DENY. 261 5. Application in single-domain scenario 263 5.1. Addition of RD-ORF entries 265 The operation of RD-ORF mechanism on each device is independent, each 266 of them makes a local judgement to determine whether it needs to send 267 RD-ORF to its peers. 269 In general, every VRF on PE is configured a Maximum Prefix, the 270 trigger of RD-ORF mechanism can be set as the number of VPN routes in 271 VRF reach 80% of the Maximum Prefix. For RR, it doesn't have VRF and 272 the machanism can be triggered by other conditions, such as the RR's 273 memory/CPU utilization reaches 80%. 275 When the RD-ORF mechanism is triggered, the device must send an alarm 276 information to network operators. 278 5.1.1. Operation process of RD-ORF mechanism on source PE 280 In scenario shown in Figure 1, when the VRF of VPN1 in PE1 overflows, 281 PE1 will do analysis and calculation locally to find out the main 282 source of VPN routes in this VRF, assuming it is PE3. Then, PE1 will 283 resolve the corresponding RD of VPN routes from BGP UPDATE message, 284 and generate a BGP ROUTE-REFRESH message contains a RD-ORF entry, and 285 send it to RR. The message contains the following fields: 287 o AFI is set to IPv4 , IPv6 or L2 VPN 289 o SAFI is set to "MPLS-labeled VPN address" or "BGP EVPN" 291 o When-to-refresh is set to IMMEDIATE 293 o ORF Type is set to RD-ORF 295 o Length of ORF entries depends on the type of Source Address sub- 296 TLV (21, 23 or 33 octets) 298 o Action is set to ADD 300 o Match is set to DENY 302 o Sequence is set to 1 304 o Route Distinguisher is set to RD1 306 It noted that the Sequence can uniquely identifies an RD-ORF entry. 307 All VRFs share the sequence field, and the corresponding sequence of 308 RD-ORF sent by each VRF will be recorded on the device. 310 Sometimes, several VRFs in a PE may import VPN routes carries the 311 same RT, as shown in Figure 3. 313 +-----------------------------------------------+ 314 | +--------+ | 315 | | RR | | 316 | +--------+ | 317 | | | 318 | | | 319 | | | 320 | | | 321 | | | 322 | +--------+ VRF1 RT-import: RT1 RT3(RD3) | 323 | | PE | VRF2 RT-import: RT2 RT3(RD3) | 324 | +--------+ VRF3 RT-import: RT3(RD3) | 325 | VRF4 RT-import: RT4 | 326 | | 327 | AS 100 | 328 +-----------------------------------------------+ 330 Figure 3: The scenario of several VRFs in a PE import VPN routes carries the same RT 332 In this scenario, VRF1, VRF2 and VRF3 import VPN routes carries RT3, 333 which contains RD3. VRF1, VRF2 and VRF3 have different maximum 334 prefix. When the VPN routes carrying RT3 cause the overflow of VRF3, 335 PE will send a BGP ROUTE-REFRESH message containing a RD-ORF entry to 336 RR, which Route Distinguisher field is equal to RD3. RR will stop 337 sending associated VPN routes to PE. However, this will cause VRF1 338 to fail to receive VPN routes containing RD3. 340 The local determination of the PE can be used to inhibit the PE from 341 sending RD-ORF entries. When the resources of the device are not 342 exhausted, only prevent the overflowed VRF from importing related VPN 343 routes without sending RD-ORF, unless all the VRFs that import the RD 344 overflow. 346 5.1.2. Operation process of RD-ORF mechanism on RR 348 When RR receives the ROUTE-REFRESH message, it checks to find whether it received the 350 latest entry or not. If not, RR will discard the entry; otherwise, 351 RR will add the RD-ORF entry into its Adj-RIB-out. 353 Before sending a VPN route toward PE1, RR will check its Adj-RIB-out 354 and find there is a filter associated with RD1. Then, RR will stop 355 sending that VPN route to PE1. 357 If the processing capacity of RR reaches the limit (e.g. RR's 358 memory/CPU utilization reaches 80%), RR will find out the peer that 359 sends the most routing entries to it, assuming it is PE3. Then, RR 360 will generate a BGP ROUTE-REFRESH message contains a RD-ORF entry 361 based on the result of calculation, and send it to PE3. 363 5.1.3. Operation process of RD-ORF mechanism on target PE 365 After receiving the ROUTE-REFRESH message that carries a RD-ORF 366 entry, PE3 will check if it receives the latest entry. If not, PE3 367 will discard it; otherwise, PE3 will add the RD-ORF entry into its 368 Adj-RIB-out. 370 Before sending a VPN route toward RR, PE3 will check its Adj-RIB-out 371 and find the RD-ORF entry prevent it from sending VPN route which 372 carries RD1 to RR. Then, PE3 will stop sending that VPN route. 374 The BGP Maximum Prefix Features can be configured to protect PE-CE 375 peering at the edge. Therefore, in general, CEs will not cause the 376 overflow of PEs. If the boundary protection measures fail and cause 377 the overflow, the PE can calculate and find the CEs in corresponding 378 VRF, and break down the associated BGP sessions. 380 5.2. Withdraw of RD-ORF entries 382 When the RD-ORF mechanism is triggered, the alarm information will be 383 generated and sent to the network operators. Operators should 384 manually configure the network to resume normal operation. Due to 385 devices can record the RD-ORF entries sent by each VRF, operators can 386 find the entries needs to be withdrawn, and trigger the withdraw 387 process as described in [RFC5291] manually. After returning to 388 normal, the device sends withdraw ORF entries to its peers who have 389 previously received ORF entries. 391 6. Applications in cross-domain scenarios 393 6.1. Application in Option B/Option AB cross-domain scenario 395 The Option B/Option AB cross-domain scenario is shown in Figure 4: 397 +--------------------------+ +--------------------------+ 398 | | | | 399 | | | | 400 | +---------+ | | +---------+ | 401 | | PE1 | | | | PE3 | | 402 | +---------+ | | +---------+ | 403 | VPN1(RD1) \ | | / VPN1(RD1) | 404 | VPN2(RD2) \+---------+ EBGP +---------+/ VPN2(RD2) | 405 | | | | | | 406 | | ASBR1 |-----------| ASBR2 | | 407 | | | | | | 408 | +---------+ +---------+ | 409 | / | | \ | 410 | +---------+/ | | \+---------+ | 411 | | PE2 | | | | PE4 | | 412 | +---------+ | | +---------+ | 413 | VPN1(RD1) | | VPN2(RD2) | 414 | AS1 | | AS2 | 415 +--------------------------+ +--------------------------+ 417 Figure 4: The Option B/Option AB cross-domain scenario 419 In Option B cross-domain scenario, PE1 - PE4 are responsible for 420 maintaining VPN routing information in AS1 and AS2. There is a 421 direct link between ASBR1 and ASBR2 via EBGP. In AS1, PE1 and PE2 422 establish IBGP sessions with ASBR1 to ensure the routes can be 423 transmitted in AS1. In AS2, PE3 and PE4 establish IBGP session with 424 ASBR2. 426 Due to the maintenance of VPN routes is only done by PEs. ASBRs 427 cannot know whether the PEs' ability to handle VPN routes has reached 428 the upper limit or not, so it needs the RD-ORF to control the number 429 of routes. 431 Assume that PE1 - PE4 can transmit VPN routes through the network 432 architecture shown in Figure 4. When the VRF of VPN1 in PE1 433 overflows, the RD-ORF mechanism will be implemented as follows: 435 1) PE1 will check and find out the main source of VPN routes in this 436 VRF is PE3. Then, PE1 will resolve the corresponding RD from BGP 437 UPDATE message, and generate a BGP ROUTE-REFRESH message contains an 438 RD-ORF entry, and send it to ASBR1. 440 2) When ASBR1 receives the ROUTE-REFRESH message, it checks whether 441 it receives the latest RD-ORF entry. If not, ASBR1 will discard the 442 entry; Otherwise, ASBR1 will add the RD-ORF entry into its Adj-RIB- 443 out. 445 Before sending a VPN route toward PE1, RR will check its Adj-RIB-out 446 and find there is a filter associated with RD1. Then, ASBR1 will 447 stop sending that VPN route. 449 Besides, ASBR1 will locally determine if it needs to send an RD-ORF 450 entry to ASBR2. The judgment criteria refers to Section 5.1.2. 452 3) If ASBR2/PE3 receives the RD-ORF entry, it will repeat the above 453 process. 455 When the RD-ORF mechanism is triggered, network operators need to 456 manually configure the network to return to resume normal operation. 457 The withdraw of RD-ORF entries refers to Section 5.2. 459 In Option AB cross-domain scenario, ASBRs maintain a VRF for a VPN. 460 However, due to VPN routes in all VRFs use the same BGP session, 461 ASBRs cannot prevent the overflow of a certain VRF by breaking down a 462 BGP session. The operation process of RD-ORF is similar to that in 463 Option B scenario. 465 6.2. Application in Option C cross-domain scenario 467 The Option C cross-domain scenario is shown in Figure 5: 469 MP-EBGP 470 +----------------------------------------+ 471 | | 472 +------------+------------+ +------------+------------+ 473 | +----+----+ | | +----+----+ | 474 | | | | | | | | 475 | +----+ RR1 +----+ | | +----+ RR2 +----+ | 476 | | | | | | | | | | | | 477 | | +---------+ | | | | +---------+ | | 478 | | | | | | | | 479 | |IBGP IBGP| | | |IBGP IBGP| | 480 | | | | | | | | 481 +-+--+----+ +----+--+-+ +-+--+----+ +----+--+-+ 482 | | | | | | | | 483 | PE1 | | ASBR1 |----------| ASBR2 | | PE2 | 484 | | | | | | | | 485 +-+-------+ AS1 +-------+-+ +-+-------+ AS2 +-------+-+ 486 +-------------------------+ +-------------------------+ 488 Figure 5: The Option C cross-domain scenario 490 In this scenario, PE1 and PE2 are responsible for maintaining VPN 491 routing information in AS1 and AS2. In order to reduce the 492 complexity that full-mesh brings to the network, RR1 and RR2 493 establish MP-EBGP session to transmit labeled routes. In AS1, PE1 494 and ASBR1 establish IBGP session with RR1 to ensure the routes can be 495 transmitted in AS1. In AS2, PE2 and ASBR2 establish IBGP session 496 with RR2. 498 Due to the maintenance of VPN routes is only done by PEs. RRs cannot 499 know whether the PEs' ability to handle VPN routes has reached the 500 upper limit or not, so it needs the RD-ORF to control the number of 501 routes. 503 The operating mechanism of RD-ORF is similar to the description in 504 Section 6.1. 506 7. Security Considerations 508 A BGP speaker will maintain the RD-ORF entries in Adj-RIB-out, this 509 behavior consumes its memory and compute resources. To avoid the 510 excessive consumption of resources, [RFC5291] specifies that a BGP 511 speaker can only accept ORF entries transmitted by its interested 512 peers. 514 8. IANA Considerations 516 This document defines a new Outbound Route Filter type - Route 517 Distinguisher Outbound Route Filter (RD-ORF). The code point is from 518 the "BGP Outbound Route Filtering (ORF) Types". It is recommended to 519 set the code point of RD-ORF to 66. 521 9. Acknowledgement 523 Thanks Robert Raszuk, Jim Uttaro, Jakob Heitz, Jeff Tantsura, Rajiv 524 Asati, John E Drake and Gert Doering for their valuable comments on 525 this draft. 527 10. Normative References 529 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 530 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 531 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 532 ietf-bess-evpn-inter-subnet-forwarding-11 (work in 533 progress), October 2020. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, 537 DOI 10.17487/RFC2119, March 1997, 538 . 540 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 541 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 542 February 2006, . 544 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 545 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 546 2006, . 548 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 549 R., Patel, K., and J. Guichard, "Constrained Route 550 Distribution for Border Gateway Protocol/MultiProtocol 551 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 552 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 553 November 2006, . 555 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 556 "Multiprotocol Extensions for BGP-4", RFC 4760, 557 DOI 10.17487/RFC4760, January 2007, 558 . 560 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 561 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 562 August 2008, . 564 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 565 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 566 August 2008, . 568 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 569 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 570 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 571 2015, . 573 Authors' Addresses 575 Wei Wang 576 China Telecom 577 Beiqijia Town, Changping District 578 Beijing, Beijing 102209 579 China 581 Email: wangw36@chinatelecom.cn 582 Aijun Wang 583 China Telecom 584 Beiqijia Town, Changping District 585 Beijing, Beijing 102209 586 China 588 Email: wangaj3@chinatelecom.cn 590 Haibo Wang 591 Huawei Technologies 592 Huawei Building, No.156 Beiqing Rd. 593 Beijing, Beijing 100095 594 China 596 Email: rainsword.wang@huawei.com 598 Gyan S. Mishra 599 Verizon Inc. 600 13101 Columbia Pike 601 Silver Spring MD 20904 602 United States of America 604 Phone: 301 502-1347 605 Email: gyan.s.mishra@verizon.com 607 Shunwan Zhuang 608 Huawei Technologies 609 Huawei Building, No.156 Beiqing Rd. 610 Beijing, Beijing 100095 611 China 613 Email: zhuangshunwan@huawei.com 615 Jie Dong 616 Huawei Technologies 617 Huawei Building, No.156 Beiqing Rd. 618 Beijing, Beijing 100095 619 China 621 Email: jie.dong@huawei.com