idnits 2.17.1 draft-wang-idr-rd-orf-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 : ---------------------------------------------------------------------------- ** There are 66 instances of too long lines in the document, the longest one being 3 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 (September 30, 2021) is 939 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 500, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-wang-idr-vpn-routes-control-analysis (ref. 'I-D.wang-idr-vpn-routes-control-analysis') Summary: 2 errors (**), 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: April 3, 2022 H. Wang 6 Huawei Technologies 7 G. Mishra 8 Verizon Inc. 9 S. Zhuang 10 J. Dong 11 Huawei Technologies 12 September 30, 2021 14 Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4 15 draft-wang-idr-rd-orf-08 17 Abstract 19 This draft defines a new Outbound Route Filter (ORF) type, called the 20 Route Distinguisher ORF (RD-ORF). The described RD-ORF mechanism is 21 applicable when the VPN routes from different VRFs are exchanged via 22 one shared BGP session(e.g. routers in a single-domain connect via 23 Route Reflector). 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 April 3, 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Operation process of RD-ORF mechanism on sender . . . . . . . 4 63 4.1. Intra-domain Scenarios and Solutions . . . . . . . . . . 4 64 4.1.1. Scenario-1 and Solution (Unique RD, One RT) . . . . . 5 65 4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) . . 6 66 4.1.3. Scenario-2 and Solution (Universal RD) . . . . . . . 7 67 5. Operation process of RD-ORF mechanism on receiver . . . . . . 8 68 6. Withdraw of RD-ORF entries . . . . . . . . . . . . . . . . . 8 69 7. RD-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Source PE TLV . . . . . . . . . . . . . . . . . . . . . . 10 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 74 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 [I-D.wang-idr-vpn-routes-control-analysis] analysis the scenarios and 80 necessaries for VPN routes control in the shared BGP session. This 81 draft analizes the existing solutions and their limitations for these 82 scenarios, proposes the new RD-ORF solution to meet the requirements 83 that described in section 8 of 84 [I-D.wang-idr-vpn-routes-control-analysis]. 86 Now, there are several solutions can be used to alleviate these 87 problem: 89 o Route Target Constraint (RTC) as defined in [RFC4684] 91 o Address Prefix ORF as defined in [RFC5292] 93 o PE-CE edge peer Maximum Prefix 95 o Configure the Maximum Prefix for each VRF on edge nodes 96 However, there are limitations to existing solutions: 98 1) Route Target Constraint 100 RTC can only filter the VPN routes from the uninterested VRFs, if the 101 "trashing routes" come from the interested VRF, filter on RTs will 102 erase all prefixes from this VRF. 104 2) Address Prefix ORF 106 Using Address Prefix ORF to filter VPN routes need to pre- 107 configuration, but it is impossible to know which prefix may cause 108 overflow in advance. 110 3) PE-CE edge peer Maximum Prefix 112 This mechanism can only protect the edge between PE-CE, it can't be 113 deployed within PE that peered via RR. Depending solely on the edge 114 protection is dangerous, because if only one of the edge points being 115 comprised/error-configured/attacked, then all of PEs within domain 116 are under risk. 118 4) Configure the Maximum Prefix for each VRF on edge nodes 120 When a VRF overflows, it stops the import of routes and log the extra 121 VPN routes into its RIB. However, PEs still need to parse the BGP 122 updates. These processes will cost CPU cycles and further burden the 123 overflowing PE. 125 This draft defines a new ORF-type, called the Route Distinguisher ORF 126 (RD-ORF). Using RD-ORF mechanism, VPN routes can be controlled based 127 on RD. This mechanism is event-driven and does not need to be pre- 128 configured. When a VRF of a router overflows, the router will find 129 out the RD of excessive VPN routes in this VRF, and send a RD-ORF to 130 its BGP peer that carrys the RD. If a BGP speaker receives a RD-ORF 131 entry from its BGP peer, it will filter the VPN routes it tends to 132 send according to the entry. 134 RD-ORF is applicable when the VPN routes from different VRFs are 135 exchanged via one shared BGP session. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] . 143 3. Terminology 145 The following terms are defined in this draft: 147 o RD: Route Distinguisher, defined in [RFC4364] 149 o ORF: Outbound Route Filter, defined in [RFC5291] 151 o AFI: Address Family Identifier, defined in [RFC4760] 153 o SAFI: Subsequent Address Family Identifier, defined in [RFC4760] 155 o EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] 157 o RR: Router Reflector, provides a simple solution to the problem of 158 IBGP full mesh connection in large-scale IBGP implementation. 160 o VRF: Virtual Routing Forwarding, a virtual routing table based on 161 VPN instance. 163 4. Operation process of RD-ORF mechanism on sender 165 The operation of RD-ORF mechanism on each device is independent, each 166 of them makes a local judgement to determine whether it needs to send 167 RD-ORF to its peers. 169 When the RD-ORF mechanism is triggered, the device must send an alarm 170 information to network operators. 172 4.1. Intra-domain Scenarios and Solutions 174 For intra-AS VPN deployment, there are three scenarios: 176 o RD is allocated per VPN/per PE, each VRF only import one RT(see 177 Section 4.1). 179 o RD is allocated per VPN/per PE. Multiple RTs are associated with 180 such VPN routes, and be imported into different VRFs in other 181 devices(see Section 4.2). 183 o RD is allocated per VPN, each VRF imports one/multiple RTs(see 184 Section 4.3). 186 The following sections will describe solutions to the above scenarios 187 in detail. 189 4.1.1. Scenario-1 and Solution (Unique RD, One RT) 191 In this scenario, RD is allocated per VPN or per PE, each VRF only 192 import one RT. We assume the network topology is shown in Figure 1. 194 +------------------------------------------------------------------------+ 195 | | 196 | | 197 | +-------+ +-------+ | 198 | | PE1 +----------------+ +-----------------+ PE4 | | 199 | +-------+ | | +-------+ | 200 | VPN1(RD11,RT1) | | VPN2(RD12,RT2) | 201 | VPN2(RD12,RT2) | | | 202 | +-+----+-+ | 203 | | RR | | 204 | +-+----+-+ | 205 | | | | 206 | | | | 207 | +-------+ | | +-------+ | 208 | | PE2 +----------------+ +-----------------+ PE3 | | 209 | +-------+ +-------+ | 210 | VPN1(RD21,RT1) VPN1(RD31,RT1) | 211 | VPN2(RD22,RT2,RT1) VPN2(RD32,RT2) | 212 | | 213 | AS 100 | 214 | | 215 +------------------------------------------------------------------------+ 216 Figure 1 Network Topology of Scenario-1 218 When PE3 sends excessive VPN routes with RT1, while both PE1 and PE2 219 import VPN routes with RT1, the process of excessive VPN routes will 220 influence performance of VRFs on PEs. PEs and RR should have some 221 mechanisms to identify and control the advertisement of excessive VPN 222 routes. 224 On PE1, each VRF has a set threshold, we assume it is 80% of Maximum 225 Prefix of VRF. When the number of VPN1 VRF routing entries reaches 226 the threshold, PE1 will start monitoring the RD carried by the 227 received VPN routing entries. Once the number of VPN routing entries 228 exceed the prefix limit, PE1 will calculate the RD and its source PE 229 received the most times during this period, the result is RD31 from 230 PE3, which is associated with RT1. Then, PE1 will locally discards 231 the VPN routes carry RD31 which come from PE3 in VRF1. 233 Due to there is no other VRFs on it to import the VPN routes with 234 RT1. after local processing, PE1 will generate a BGP ROUTE-REFRESH 235 message contains a RD-ORF entry, and send to RR. RR will withdraw 236 and stop to advertise such excessive VPN routes to PE1. 238 On PE2, the local processing is the same as PE1. Due to there has 239 other VRF on it to import the VPN routes with RT1, PE2 triggers the 240 RD-ORF message to RR(RD field is set to RD31) only when all the VRFs 241 that import RT1 are overflowed. 243 4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) 245 In this scenario, RD is allocated per VPN or per PE. Multiple RTs 246 are associated with such VPN routes, and be imported into different 247 VRFs in other devices. We assume the network topology is shown in 248 Figure 2. 250 +------------------------------------------------------------------------+ 251 | | 252 | | 253 | +-------+ +-------+ | 254 | | PE1 +----------------+ +-----------------+ PE4 | | 255 | +-------+ | | +-------+ | 256 | VPN1(RD11,RT1) | | VPN2(RD12,RT2) | 257 | VPN2(RD12,RT2) | | | 258 | +-+----+-+ | 259 | | RR | | 260 | +-+----+-+ | 261 | | | | 262 | | | | 263 | +-------+ | | +-------+ | 264 | | PE2 +----------------+ +-----------------+ PE3 | | 265 | +-------+ +-------+ | 266 | VPN1(RD21,RT1) VPN1(RD31,RT1,RT2) | 267 | VPN2(RD32,RT2) | 268 | | 269 | AS 100 | 270 | | 271 +------------------------------------------------------------------------+ 272 Figure 2 Network Topology of Scenario-2 274 When PE3 sends excessive VPN routes with RT1 and RT2, while both PE1 275 and PE2 import VPN routes with RT1, and PE1 also imports VPN routes 276 with RT2, the process of excessive VPN routes will influence 277 performance of VRF on PEs. PEs and RR should have some mechanisms to 278 identify and control the advertisement of excessive VPN routes. 280 In this senario, both VRF1 and VRF2 import VPN route carries RT2, 281 which contains RD31. 283 On PE1, if it overflows, it will know that the RD of excessive VPN 284 routes is RD31 during the local processing, which come from PE3 and 285 associated with RT1 and RT2. There are different VRFs on PE1 import 286 the VPN routes respectively with RT1 and RT2. If PE1 trigger the RD- 287 ORF message when VRF1 overflows, it cannot receive the VPN routes 288 with RT2 from PE3. The local determination of the PE can be used to 289 inhibit the PE from sending RD-ORF entries. PE1 will not trigger the 290 RD-ORF message until all VPNs that import VPN routes with RD31 are 291 overflowed. When RD-ORF mechanisms is triggered, PE1 will discard 292 the overflowed VPN routes locally and send RD-ORF entry to RR, and RR 293 withdraws and stops to advertise such excessive VPN routes to PE1. 295 On PE2, due to there is only one VRF imports VPN routes with RT1. If 296 it overflows, it will trigger RD-ORF(RD31) mechanisms. RR will 297 withdraw and stop to advertise such excessive VPN routes to PE2. 299 4.1.3. Scenario-2 and Solution (Universal RD) 301 In this scenario, RD is allocated per VPN. One/Multiple RTs are 302 associated with such VPN routes, and be imported into different VRFs 303 in other devices. We assume the network topology is shown in 304 Figure 3. 306 +------------------------------------------------------------------------+ 307 | | 308 | | 309 | +-------+ +-------+ | 310 | | PE1 +----------------+ +-----------------+ PE4 | | 311 | +-------+ | | +-------+ | 312 | VPN1(RD1,RT1) | | VPN2(RD12,RT2) | 313 | VPN2(RD12,RT2) | | | 314 | +-+----+-+ | 315 | | RR | | 316 | +-+----+-+ | 317 | | | | 318 | | | | 319 | +-------+ | | +-------+ | 320 | | PE2 +----------------+ +-----------------+ PE3 | | 321 | +-------+ +-------+ | 322 | VPN1(RD1,RT1) VPN1(RD1,RT1,RT2) | 323 | VPN2(RD32,RT2) | 324 | | 325 | AS 100 | 326 | | 327 +------------------------------------------------------------------------+ 328 Figure 3 Network Topology of Scenario-3 330 When PE3 sends excessive VPN routes with RD1 and attached RT1 and 331 RT2, while both PE1 and PE2 import VPN routes with RT1, the process 332 of excessive VPN routes will influence performance of VRF on PEs. 334 PEs and RR should have some mechanisms to identify and control the 335 advertisement of excessive VPN routes. 337 Based on previous principle, when PE2 overflows and PE1 not. PE2 338 triggers the RD-ORF message(RD1, comes from PE3). RR will withdraw 339 and stop to advertise such excessive VPN routes to PE2. The 340 communication between PE2 and PE1 for VPN1 will not be influenced. 342 5. Operation process of RD-ORF mechanism on receiver 344 The receiver of RD-ORF entries may be a RR or PE. As it receives the 345 RD-ORF entries, it will checks to find if it already existed in its ORF-Policy table. 347 If not, the receiver will add the RD-ORF entries into its ORF-Policy 348 table; otherwise, the receiver will discard it. Before the receiver 349 send a VPN route, it will check its ORF-Policy table whether there is 350 a related RD-ORF entry or not. If not, the receiver will send this 351 VPN route; otherwise, the receiver will stop sending that VPN route 352 to its peer. 354 6. Withdraw of RD-ORF entries 356 When the RD-ORF mechanism is triggered, the alarm information will be 357 generated and sent to the network operators. Operators should 358 manually configure the network to resume normal operation. Due to 359 devices can record the RD-ORF entries sent by each VRF, operators can 360 find the entries needs to be withdrawn, and trigger the withdraw 361 process as described in [RFC5291] manually. After returning to 362 normal, the device sends withdraw ORF entries to its peers who have 363 previously received ORF entries. 365 7. RD-ORF Encoding 367 In this section, we defined a new ORF type called Route Distinguisher 368 Outbound Route Filter (RD-ORF). The ORF entries are carried in the 369 BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE- 370 REFRESH message can carry one or more ORF entries. The ROUTE-REFRESH 371 message which carries ORF entries contains the following fields: 373 o AFI (2 octets) 375 o SAFI (1 octet) 377 o When-to-refresh (1 octet): the value is IMMEDIATE or DEFER 379 o ORF Type (1 octet) 381 o Length of ORF entries (2 octets) 382 A RD-ORF entry contains a common part and type-specific part. The 383 common part is encoded as follows: 385 o Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL 387 o Match (1 bit): the value is PERMIT or DENY 389 o Reserved (5 bits) 391 RD-ORF also contains type-specific part. The encoding of the type- 392 specific part is shown in Figure 4. 394 +-----------------------------------------+ 395 | | 396 | Sequence (4 octets) | 397 | | 398 +-----------------------------------------+ 399 | | 400 | Route Distinguisher (8 octets) | 401 | | 402 +-----------------------------------------+ 403 | | 404 | Optional TLVs (variable) | 405 | | 406 +-----------------------------------------+ 408 Figure 4: RD-ORF type-specific encoding 410 o Sequence: identifying the order in which RD-ORF is generated 412 o Route Distinguisher: distinguish the different user routes. The 413 RD-ORF filters the VPN routes it tends to send based on Route 414 Distinguisher. 416 o Optional TLVs: carry the potential additional information to give 417 the extensibility of the RD-ORF mechanism. 419 Note that if the Action component of an ORF entry specifies REMOVE- 420 ALL, the ORF entry does not include the type-specific part. The 421 Sequence can uniquely identifies an RD-ORF entry. All VRFs share the 422 sequence field, and the corresponding sequence of RD-ORF sent by each 423 VRF will be recorded on the device. 425 When the BGP ROUTE-REFRESH message carries RD-ORF entries, it must be 426 set as follows: 428 o The ORF-Type MUST be set to RD-ORF. 430 o The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). 432 o If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS- 433 labeled VPN address. 435 o If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. 437 o The Match field MUST be equal to DENY. 439 7.1. Source PE TLV 441 Source PE TLV is defined to identify the source of the VPN routes. 442 Using source PE and RD to filter VPN routes together can achieve more 443 refined route control. The source PE TLV contains the following 444 types: 446 o In single-domain or Option C cross-domain scenario, NEXT_HOP 447 attribute is fixed during routing transmission, so it can be used 448 as source address. 450 Type = 1, Length = 4 octets, value = NEXT_HOP. 452 Type = 2, Length = 16 octets, value = NEXT_HOP. 454 o In Option B or Option AB cross-domain scenario, NEXT_HOP attribute 455 may be changed by ASBRs and cannot be used as the source address. 456 The originator can be traced by the Route Origin Community in BGP 457 (as defined in Section 5 of [RFC4360]). 459 Type = 3, Length = 6 octets, value = the value field of Route 460 Origin Community. 462 8. Security Considerations 464 A BGP speaker will maintain the RD-ORF entries in an ORF-Policy 465 table, this behavior consumes its memory and compute resources. To 466 avoid the excessive consumption of resources, [RFC5291] specifies 467 that a BGP speaker can only accept ORF entries transmitted by its 468 interested peers. 470 9. IANA Considerations 472 This document defines a new Outbound Route Filter type - Route 473 Distinguisher Outbound Route Filter (RD-ORF). The code point is from 474 the "BGP Outbound Route Filtering (ORF) Types". It is recommended to 475 set the code point of RD-ORF to 66. 477 This document also define a RD-ORF TLV type under "Border Gateway 478 Protocol (BGP) Parameters", three TLV types are defined: 480 +===========================+======+===========================+ 481 | Registry | Type | Meaning | 482 +===========================+======+===========================+ 483 |IPv4 Source PE TLV | 1 |IPv4 address for source PE.| 484 +---------------------------+------+---------------------------+ 485 |IPv6 Source PE TLV | 2 |IPv6 address for source PE.| 486 +---------------------------+------+---------------------------+ 487 |ROC Source PE TLV | |Route Origin Community for | 488 | | 3 |Source PE. | 489 +---------------------------+------+---------------------------+ 490 Figure 5: IANA Allocation for newly defined TLVs 492 10. Acknowledgement 494 Thanks Robert Raszuk, Jim Uttaro, Jakob Heitz, Jeff Tantsura, Rajiv 495 Asati, John E Drake, Gert Doering, Shuanglong Chen, Enke Chen and 496 Srihari Sangli for their valuable comments on this draft. 498 11. Normative References 500 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 501 Sajassi, A., Salam, S., Thoria, S., Drake, J. E., and J. 502 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 503 ietf-bess-evpn-inter-subnet-forwarding-15 (work in 504 progress), July 2021. 506 [I-D.wang-idr-vpn-routes-control-analysis] 507 Wang, A., Wang, W., Mishra, G. S., Wang, H., Zhuang, S., 508 and J. Dong, "Analysis of VPN Routes Control in Shared BGP 509 Session", draft-wang-idr-vpn-routes-control-analysis-04 510 (work in progress), September 2021. 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 518 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 519 February 2006, . 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 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 526 R., Patel, K., and J. Guichard, "Constrained Route 527 Distribution for Border Gateway Protocol/MultiProtocol 528 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 529 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 530 November 2006, . 532 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 533 "Multiprotocol Extensions for BGP-4", RFC 4760, 534 DOI 10.17487/RFC4760, January 2007, 535 . 537 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 538 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 539 August 2008, . 541 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 542 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 543 August 2008, . 545 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 546 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 547 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 548 2015, . 550 Authors' Addresses 552 Wei Wang 553 China Telecom 554 Beiqijia Town, Changping District 555 Beijing, Beijing 102209 556 China 558 Email: weiwang94@foxmail.com 560 Aijun Wang 561 China Telecom 562 Beiqijia Town, Changping District 563 Beijing, Beijing 102209 564 China 566 Email: wangaj3@chinatelecom.cn 567 Haibo Wang 568 Huawei Technologies 569 Huawei Building, No.156 Beiqing Rd. 570 Beijing, Beijing 100095 571 China 573 Email: rainsword.wang@huawei.com 575 Gyan S. Mishra 576 Verizon Inc. 577 13101 Columbia Pike 578 Silver Spring MD 20904 579 United States of America 581 Phone: 301 502-1347 582 Email: gyan.s.mishra@verizon.com 584 Shunwan Zhuang 585 Huawei Technologies 586 Huawei Building, No.156 Beiqing Rd. 587 Beijing, Beijing 100095 588 China 590 Email: zhuangshunwan@huawei.com 592 Jie Dong 593 Huawei Technologies 594 Huawei Building, No.156 Beiqing Rd. 595 Beijing, Beijing 100095 596 China 598 Email: jie.dong@huawei.com