idnits 2.17.1 draft-wang-idr-rd-orf-02.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 11 instances of too long lines in the document, the longest one being 1 character 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 (July 28, 2020) is 1369 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 (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-09 Summary: 1 error (**), 0 flaws (~~), 2 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: January 29, 2021 S. Zhuang 6 J. Dong 7 H. Wang 8 Huawei Technologies 9 July 28, 2020 11 Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4 12 draft-wang-idr-rd-orf-02 14 Abstract 16 This draft defines a new Outbound Route Filter (ORF) type, called the 17 Route Distinguisher ORF (RD-ORF). RD-ORF is applicable when the 18 routers do not exchange VPN routing information directly (e.g. 19 routers in single-domain connect via Route Reflector, or routers in 20 Option B/Option C cross-domain scenario). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 29, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. RD-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Application in single-domain scenario . . . . . . . . . . . . 6 61 6. Applications in cross-domain scenarios . . . . . . . . . . . 8 62 6.1. Application in Option B cross-domain scenario . . . . . . 8 63 6.2. Application in Option C cross-domain scenario . . . . . . 11 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 69 1. Introduction 71 With the rapid growth of network scale, Route Reflector is introduced 72 in order to reduce the network complexity. Routers in the same 73 Autonomous System only need to establish iBGP session with RR to 74 transmit routes. 76 In VPN scenario shown in Figure 1, PE1 - PE4 establish IBGP sessions 77 with RR to ensure the routes can be transmitted within AS100, where 78 PE1 and PE3 maintain VRFs of VPN1 and VPN2, PE2 maintains VPN1's VRF 79 and PE4 maintains VPN2's VRF. RR don not maintain any VRFs. 81 +----------------------------------------------+ 82 | | 83 | | 84 | +---------+ +---------+ | 85 | | PE1 | | PE4 | | 86 | +---------+ +---------+ | 87 | VPN1 \ / VPN2 | 88 | VPN2 \+---------+ / | 89 | | | | 90 | | RR | | 91 | | | | 92 | +---------+ \ | 93 | / \ | 94 | +---------+/ +---------+ | 95 | | PE2 | | PE3 | | 96 | +---------+ +---------+ | 97 | VPN1 VPN1 | 98 | AS 100 VPN2 | 99 +----------------------------------------------+ 101 Figure 1: Single-domain scenario 103 When the VRF of VPN1 in PE2 overflows, due to PE2 and other PEs are 104 not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the 105 problem on PE2 cannot be known. 107 Now, there are two solutions can be used to alleviate this problem: 109 o Route Target Constraint (RTC) as defined in [RFC4684] 111 o Address Prefix ORF as defined in [RFC5292] 113 However, RTC can only specify the VPN routes it want, it cannot 114 control the route limit within one specific VRF. Using Address 115 Prefix ORF to filter VPN routes need to pre-configuration, but it is 116 impossible to know which device may overflow in advance. 118 This draft defines a new ORF-type, called the Route Distinguisher ORF 119 (RD-ORF). Based on RD-ORF, VPN routes of a VPN can be controlled 120 based on source RD and originator. This mechanism is event-driven 121 and does not need to be pre-configured. When a VRF of a router 122 overflows, the router will find out the main source address and RD of 123 VPN routes in this VRF, and send a RD-ORF to its BGP peer that carrys 124 the RD and the source address. If a BGP speaker receives a RD-ORF 125 from its BGP peer, it will filter the VPN routes it tends to send 126 according to the RD-ORF entry. 128 RD-ORF is applicable when the routers do not exchange VPN routing 129 information directly (e.g. routers in single-domain connect via Route 130 Reflector, or routers in Option B/Option C cross-domain scenario). 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119] . 138 3. Terminology 140 The following terms are defined in this draft: 142 o RD: Route Distinguisher, defined in [RFC4364] 144 o ORF: Outbound Route Filter, defined in [RFC5291] 146 o AFI: Address Family Identifier, defined in [RFC4760] 148 o SAFI: Subsequent Address Family Identifier, defined in [RFC4760] 150 o EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] 152 o RR: Router Reflector, provides a simple solution to the problem of 153 IBGP full mesh connection in large-scale IBGP implementation. 155 o VRF: Virtual Routing Forwarding, a virtual routing table based on 156 VPN instance. 158 4. RD-ORF Encoding 160 In this draft, we defined a new ORF type called Route Distinguisher 161 Outbound Route Filter (RD-ORF). The ORF entries are carried in the 162 BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE- 163 REFRESH message can carry one or more ORF entries, and MUST be 164 regenerated when it is tended to be sent to other BGP peers. The 165 ROUTE-REFRESH message which carries ORF entries contains the 166 following fields: 168 o AFI (2 octets) 170 o SAFI (1 octet) 172 o When-to-refresh (1 octet): the value is IMMEDIATE or DEFER 174 o ORF Type (1 octet) 175 o Length of ORF entries (2 octets) 177 A RD-ORF entry contains a common part and type-specific part. The 178 common part is encoded as follows: 180 o Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL 182 o Match (1 bit): the value is PERMIT or DENY 184 o Reserved (5 bits) 186 RD-ORF also contains type-specific part. The encoding of the type- 187 specific part is shown in Figure 2. 189 +-----------------------------------------+ 190 | | 191 | Sequence (4 octets) | 192 | | 193 +-----------------------------------------+ 194 | | 195 | Route Distinguisher (8 octets) | 196 | | 197 +-----------------------------------------+ 198 | | 199 |Source Address sub-TLV (4,6 or 16 octets)| 200 | | 201 +-----------------------------------------+ 203 Figure 2: RD-ORF type-specific encoding 205 o Sequence: identifying the order in which RD-ORF is generated 207 o Route Distinguisher: distinguish the different user routes. The 208 RD-ORF filters the VPN routes it tends to send based on Route 209 Distinguisher. 211 o Source Address sub-TLV: the source address is TLV format, which 212 contains the following sub-TLVs: 214 * For L3 EVPN case, Gateway IP Address in EVPN RT-5 (IP Prefix 215 Advertisement Route) can be used as source address. 217 Type = 1, Length = 4 octets, value = IPv4 Gateway IP 218 Address. 220 Type = 2, Length = 16 octets, value = IPv6 Gateway IP 221 Address. 223 * For L2 EVPN case, the source address can be extracted from EVPN 224 Router's MAC Extended Community (as defined in Section 8.1 of 225 [I-D.ietf-bess-evpn-inter-subnet-forwarding]). 227 Type = 3. Length = 6 octets, value = the value field of 228 EVPN Router's MAC Extended Community. 230 * For MPLS VPN case, the source address can be extracted from the 231 Route Origin Community in BGP (as defined in Section 5 of 232 [RFC4360]). 234 Type = 4, Length = 6 octets, value = the value field of 235 Route Origin Community. 237 Note that if the Action component of an ORF entry specifies REMOVE- 238 ALL, the ORF entry does not include the type-specific part. 240 When the BGP ROUTE-REFRESH message carries RD-ORF entries, it must be 241 set as follows: 243 o The ORF-Type MUST be set to RD-ORF. 245 o The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). 247 o If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS- 248 labeled VPN address. 250 o If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. 252 o The Match field MUST be equal to DENY. 254 5. Application in single-domain scenario 256 In scenario shown in Figure 1, When the VRF of VPN1 in PE1 overflows, 257 it will find out the main source of VPN routes in this VRF, assuming 258 it is PE3. Then, PE1 will extract PE3's host address and source RD 259 from BGP UPDATE message and generate a BGP ROUTE-REFRESH message 260 contains a RD-ORF entry, and send it to RR. The entry consists of 261 the following fields: 263 o AFI is set to IPv4 , IPv6 or L2 VPN 265 o SAFI is set to "MPLS-labeled VPN address" or "BGP EVPN" 267 o When-to-refresh is set to IMMEDIATE 269 o ORF Type is set to RD-ORF 270 o Length of ORF entries depends on the type of Source Address sub- 271 TLV (21, 23 or 33 octets) 273 o Action is set to ADD 275 o Match is set to DENY 277 o Sequence is set to 1 279 o Route Distinguisher is set to RD1 281 o Source Address sub-TLV is set to PE3's host address 283 It noted that for a RD, the sequence of the first RD-ORF is equal to 284 1. When a PE needs to send a second RD-ORF entry associated with the 285 same RD, the RD-ORF sequence SHOULD increment. 287 When RR receives the ROUTE-REFRESH message, it checks to find 289 whether it received the latest entry or not. If not, RR will discard 290 the entry; otherwise, RR will add the RD-ORF entry into its Adj-RIB- 291 out, and regenerate a BGP ROUTE-REFRESH message to send this RD-ORF 292 entry to PE3. 294 After receiving this ROUTE-REFRESH message that carries a RD-ORF 295 entry, PE3 will repeat the above process to check if it receives the 296 latest entry. If not, PE3 will discard it; otherwise, PE3 will add 297 the RD-ORF entry into its Adj-RIB-out. 299 Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 300 will check its Adj-RIB-out and find the RD-ORF entry prevent it from 301 sending VPN route which carries RD1 to RR. Then, PE3 will stop 302 sending that VPN route. 304 When the VRF of VPN1 in PE1 no longer overflows, it will send RR a 305 BGP ROUTE-REFRESH message encoded as following: 307 o AFI is set to IPv4 , IPv6 or L2 VPN 309 o SAFI is set to "MPLS-labeled VPN address" or "BGP EVPN" 311 o When-to-refresh is set to IMMEDIATE 313 o ORF Type is set to RD-ORF 315 o Length of ORF entries depends on the type of Source Address sub- 316 TLV (21, 23 or 33 octets) 318 o Action is set to REMOVE 320 o Match is set to DENY 322 o Sequence is set to 2 324 o Route Distinguisher is set to RD1 326 o Source Address sub-TLV is set to PE3's host address 328 After receiving the BGP ROUTE-REFRESH message, RR will check whether 329 it receives the latest entry. If not, RR will discard it; otherwise, 330 RR will remove the associated RD-ORF entry from its Adj-RIB-out, and 331 regenerate a BGP ROUTE-REFRESH message to send this RD-ORF entry to 332 PE3. 334 After receiving this ROUTE-REFRESH message that carries a RD-ORF 335 entry, PE3 will repeat the above process to check if it receives the 336 latest entry. If not, PE3 will discard it; otherwise, PE3 will 337 remove the associated RD-ORF entry from its Adj-RIB-out. 339 Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 340 will check its Adj-RIB-out and find there is no filter associated 341 with RD1. Then, it will send that VPN route. 343 6. Applications in cross-domain scenarios 345 6.1. Application in Option B cross-domain scenario 347 The Option B cross-domain scenario is shown in Figure 3: 349 +--------------------------+ +--------------------------+ 350 | | | | 351 | | | | 352 | +---------+ | | +---------+ | 353 | | PE1 | | | | PE3 | | 354 | +---------+ | | +---------+ | 355 | VPN1 \ | | / VPN1 | 356 | VPN2 \+---------+ EBGP +---------+/ VPN2 | 357 | | | | | | 358 | | ASBR1 |-----------| ASBR2 | | 359 | | | | | | 360 | +---------+ +---------+ | 361 | / | | \ | 362 | +---------+/ | | \+---------+ | 363 | | PE2 | | | | PE4 | | 364 | +---------+ | | +---------+ | 365 | VPN1 | | VPN2 | 366 | AS1 | | AS2 | 367 +--------------------------+ +--------------------------+ 369 Figure 3: The Option B cross-domain scenario 371 In this scenario, PE1 - PE4 are responsible for maintaining VPN 372 routing information in AS1 and AS2. There is a direct link between 373 ASBR1 and ASBR2 via EBGP. In AS1, PE1 and PE2 establish IBGP 374 sessions with ASBR1 to ensure the routes can be transmitted in AS1. 375 In AS2, PE3 and PE4 establish IBGP session with ASBR2. 377 Due to the maintenance of VPN routes is only done by PEs. ASBRs 378 cannot know whether the PEs' ability to handle VPN routes has reached 379 the upper limit or not, so it needs the RD-ORF to control the number 380 of routes. 382 Assume that PE1 - PE4 can transmit VPN routes through the network 383 architecture shown in Figure 3. When the VRF of VPN1 in PE1 384 overflows, it will check and find out the main source of VPN routes 385 in this VRF is PE3. Then, PE1 will extract PE3's host address and 386 source RD from BGP UPDATE message and generate a BGP ROUTE-REFRESH 387 message contains a RD-ORF entry, and send it to ASBR1. The entry 388 consists of the following fields: 390 o AFI is set to IPv4 , IPv6 or L2 VPN 392 o SAFI is set to "MPLS-labeled VPN address" or "BGP EVPN" 394 o When-to-refresh is set to IMMEDIATE 396 o ORF Type is set to RD-ORF 397 o Length of ORF entries depends on the type of Source Address sub- 398 TLV (21, 23 or 33 octets) 400 o Action is set to ADD 402 o Match is set to DENY 404 o Sequence is set to 1 406 o Route Distinguisher is set to RD1 408 o Source Address sub-TLV is set to PE3's host address 410 When ASBR1 receives the ROUTE-REFRESH message, it checks the to determine whether it receives the latest RD-ORF entry. If 413 not, ASBR1 will discard the entry; Otherwise, ASBR1 will add the RD- 414 ORF entry into its Adj-RIB-out and regenerate a ROUTE-REFRESH message 415 carries the RD-ORF entry to send it to ASBR2. 417 After receiving the RD-ORF entry, ASBR2 will repeat the above process 418 to check if it receives the latest entry. If not, ASBR2 will discard 419 it; otherwise, ASBR2 will add the RD-ORF entry into its Adj-RIB-out 420 and send the entry to PE3. PE3 will check it and add the associated 421 entry into its Adj-RIB-out. 423 Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 424 will check its Adj-RIB-out and find the RD-ORF entry prevent it from 425 sending VPN route which carries RD1 to ASBR2. Then, it will stop 426 sending that VPN route. 428 If PE1 can re-receive the route entries, it will send a ROUTE-REFRESH 429 message to ASBR1, carrying a RD-ORF entry consists of the following 430 fields: 432 o AFI is set to IPv4 , IPv6 or L2 VPN 434 o SAFI is set to "MPLS-labeled VPN address" or "BGP EVPN" 436 o When-to-refresh is set to IMMEDIATE 438 o ORF Type is set to RD-ORF 440 o Length of ORF entries depends on the type of Source Address sub- 441 TLV (21, 23 or 33 octets) 443 o Action is set to REMOVE 444 o Match is set to DENY 446 o Sequence is set to 2 448 o Route Distinguisher is set to RD1 450 o Source Address sub-TLV is set to PE3's host address 452 When ASBR1 receives the ROUTE-REFRESH message, it checks the to determine whether it receives the latest RD-ORF entry. If 455 not, ASBR1 will discard the entry; otherwise, ASBR1 will remove the 456 associated RD-ORF entry from its Adj-RIB-out and regenerate a ROUTE- 457 REFRESH message carries the RD-ORF entry to send it to ASBR2. 459 After receiving the RD-ORF entry, ASBR2 will repeat the above 460 process. ASBR2 will repeat the above process to check if it receives 461 the latest entry. If not, ASBR2 will discard it; otherwise, ASBR2 462 will remove the associated RD-ORF entry from its Adj-RIB-out and send 463 the entry to PE3. PE3 will check it and remove the associated entry 464 from its Adj-RIB-out. 466 Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 467 will check its Adj-RIB-out and find there is no filter associated 468 with RD1. Then, it will send that VPN route. 470 6.2. Application in Option C cross-domain scenario 472 The Option C cross-domain scenario is shown in Figure 4: 474 +--------------------------+ +--------------------------+ 475 | | | | 476 | +---------+ | MP-EBGP | +---------+ | 477 | | RR1 |-------+-------------+-------| RR2 | | 478 | +---------+ | | +---------+ | 479 | / \ | | / \ | 480 | / \ | | / \ | 481 | / +---------+ +---------+ \ | 482 | +---------+ | | | | +---------+ | 483 | | PE1 | | ASBR1 | | ASBR2 | | PE2 | | 484 | +---------+ | | | | +---------+ | 485 | VPN1 +---------+ +---------+ VPN1 | 486 | VPN2 | | VPN2 | 487 | AS1 | | AS2 | 488 +--------------------------+ +--------------------------+ 490 Figure 4: The Option C cross-domain scenario 492 In this scenario, PE1 and PE2 are responsible for maintaining VPN 493 routing information in AS1 and AS2. In order to reduce the 494 complexity that full-mesh brings to the network, RR1 and RR2 495 establish MP-EBGP session to transmit labeled routes. In AS1, PE1 496 and ASBR1 establish IBGP session with RR1 to ensure the routes can be 497 transmitted in AS1. In AS2, PE2 and ASBR2 establish IBGP session 498 with RR2. 500 Due to the maintenance of VPN routes is only done by PEs. RRs cannot 501 know whether the PEs' ability to handle VPN routes has reached the 502 upper limit or not, so it needs the RD-ORF to control the number of 503 routes. 505 The operating mechanism of RD-ORF is similar to the description in 506 Section 6.1. 508 7. Security Considerations 510 A BGP speaker will maintain the RD-ORF entries in Adj-RIB-out, this 511 behavior consumes its memory and compute resources. To avoid the 512 excessive consumption of resources, [RFC5291] specifies that a BGP 513 speaker can only accept ORF entries transmitted by its interested 514 peers. 516 8. IANA Considerations 518 This document defines a new Outbound Route Filter type - Route 519 Distinguisher Outbound Route Filter (RD-ORF). The code point is from 520 the "BGP Outbound Route Filtering (ORF) Types". It is recommended to 521 set the code point of RD-ORF to 66. 523 IANA is requested to allocate one code point for Source Address sub- 524 TLV for RD-ORF. 526 This document defines the following new RD-ORF sub-TLV types, which 527 should be reflected in the Source Address sub-TLV for RD-ORF Code 528 Point registry: 530 +----+------------------------------------------------------------------+ 531 |Type| Description | 532 +----+------------------------------------------------------------------+ 533 | 1 | IPv4 L3EVPN Source Address TLV | 534 +----+------------------------------------------------------------------+ 535 | 2 | IPv6 L3EVPN Source Address TLV | 536 +----+------------------------------------------------------------------+ 537 | 3 | L2EVPN Source Address TLV | 538 +----+------------------------------------------------------------------+ 539 | 4 | MPLS VPN Source Address TLV | 540 +----+------------------------------------------------------------------+ 542 9. Normative References 544 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 545 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 546 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 547 ietf-bess-evpn-inter-subnet-forwarding-09 (work in 548 progress), June 2020. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 556 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 557 February 2006, . 559 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 560 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 561 2006, . 563 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 564 R., Patel, K., and J. Guichard, "Constrained Route 565 Distribution for Border Gateway Protocol/MultiProtocol 566 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 567 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 568 November 2006, . 570 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 571 "Multiprotocol Extensions for BGP-4", RFC 4760, 572 DOI 10.17487/RFC4760, January 2007, 573 . 575 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 576 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 577 August 2008, . 579 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 580 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 581 August 2008, . 583 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 584 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 585 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 586 2015, . 588 Authors' Addresses 590 Wei Wang 591 China Telecom 592 Beiqijia Town, Changping District 593 Beijing, Beijing 102209 594 China 596 Email: wangw36@chinatelecom.cn 598 Aijun Wang 599 China Telecom 600 Beiqijia Town, Changping District 601 Beijing, Beijing 102209 602 China 604 Email: wangaj3@chinatelecom.cn 606 Shunwan Zhuang 607 Huawei Technologies 608 Huawei Building, No.156 Beiqing Rd. 609 Beijing, Beijing 100095 610 China 612 Email: zhuangshunwan@huawei.com 614 Jie Dong 615 Huawei Technologies 616 Huawei Building, No.156 Beiqing Rd. 617 Beijing, Beijing 100095 618 China 620 Email: jie.dong@huawei.com 621 Haibo Wang 622 Huawei Technologies 623 Huawei Building, No.156 Beiqing Rd. 624 Beijing, Beijing 100095 625 China 627 Email: rainsword.wang@huawei.com