BESS WG Y. Wang Internet-Draft ZTE Corporation Intended status: Standards Track 20 November 2021 Expires: 24 May 2022 Smooth Evolution of Existing EVPN IRB Network draft-wang-bess-evpn-irb-smooth-evolution-00 Abstract EVPN IRB has been deployed following [RFC9135]'s early draft for a long time. This draft discusses how can these existing deployments smoothly evolved into an IP-aliasing ([I-D.sajassi-bess-evpn-ip-aliasing]) enhanced EVPN symmetric IRB scenario, especially when two of an IP-VRF's BDs (whose IRB interfaces are attached to the same IP-VRF) have been attched to a common ES before that network evolution. In such case, when these two BDs are evolved into IP-aliasing enhanced EVPN symmetric IRB as per [I-D.sajassi-bess-evpn-ip-aliasing] or distributed Bump-in-the- wire as per [I-D.wang-bess-evpn-distributed-bump-in-the-wire], the IP A-D per EVI routes of these two BDs may conflict with each other in the context of the IP-VRF instance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 May 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Wang Expires 24 May 2022 [Page 1] Internet-Draft EVPN IRB Evolution November 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Muti-IRB Use Case vs Mono-IRB Use Case . . . . . . . . . 5 2.2. Problem with IP-aliasing-enabled Multi-IRB Use Case . . . 6 2.2.1. When IP-aliasing is enabled for a multi-IRB Use Case . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. When an IP-aliasing-enabled mono-IRB evolves into multi-IRB . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. When distributed Bump-in-the-wire is enabled for a multi-IRB use case . . . . . . . . . . . . . . . . . 7 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Determining the Aliasing Pathes for RT-2R . . . . . . . . 8 3.2. ACI-specific Overlay Index Extended Community . . . . . . 9 3.3. ARP/ND Synching and IP Aliasing . . . . . . . . . . . . . 9 3.3.1. Constructing MAC/IP Advertisement Route . . . . . . . 9 3.3.2. Constructing IP A-D per EVI Route . . . . . . . . . . 10 3.4. Secenario-Specific Procedures . . . . . . . . . . . . . . 10 3.4.1. EVPN-IRB Specific Procedures . . . . . . . . . . . . 10 3.4.2. Bump-in-the-wire Specific Procedures . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction In Section 3.1 of [I-D.sajassi-bess-evpn-ip-aliasing], the IP A-D per EVI routes are defined in order to provide the IP aliasing capabilities for EVPN symmetric IRB. In Section 2.1 we discussed the multi-IRB use case and why the original IP A-D per EVI routes can not be used when we want the overlay network of that use case to be smoothly evoluted to an IP-aliasing-enhanced EVPN symmetric IRB network. Then we discussed how the smooth evolution can be provided using the SOI-specific ethernet auto-discovery mode of Wang Expires 24 May 2022 [Page 2] Internet-Draft EVPN IRB Evolution November 2021 [I-D.wang-bess-evpn-distributed-bump-in-the-wire]. This draft improves the network evolution of a style of overlay network with EVPN IRB deployments, where two BDs behind different IRB interfaces of the same IP-VRF have been attched to a common ES before that network evolution. This style of EVPN IRB use case are called as multi-IRB use case in this draft. That overlay network is a existing symmetric EVPN IRB service. Before the evolution, it will be a normal symmetric EVPN IRB per [RFC9135], But after the evolution, it should be assigned with the IP aliasing capabilities as per [I-D.sajassi-bess-evpn-ip-aliasing]. But the IP A-D per EVI route of [I-D.sajassi-bess-evpn-ip-aliasing] can't satisfy the network management requirements of smooth resolution. This draft discribes a smooth evolution mechanism using the SOI-specific ethernet auto-discovery mode of [I-D.wang-bess-evpn-distributed-bump-in-the-wire]. 1.1. Terminology and Acronyms Most of the acronyms and terms used in this documents comes from [RFC7432], [I-D.wang-bess-evpn-arp-nd-synch-without-irb] and [I-D.sajassi-bess-evpn-ip-aliasing] except for the following: * VRF AC - An Attachment Circuit (AC) that attaches a CE to an IP-VRF but is not an IRB interface. * VRF Interface - An IRB interface or a VRF-AC or an IRC interface. Note that a VRF interface will be bound to the routing space of an IP-VRF. * L3 EVI - An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN which contains VRF ACs and maybe contains IRB interfaces or IRC interfaces. * Ethernet A-D per EVI - An Ethernet Auto-Discovery route per EVI whose EVI is an MAC-VRF as per [RFC7432] and [RFC9135]. The route-targets of an Ethernet A-D per EVI route are determined by the MAC-VRF for which they are advertised. * IP A-D per EVI - An ethernet Auto-Discovery route per EVI whose EVI is an IP-VRF. Note that the Ethernet Tag ID of an IP A-D per EVI route MUST be zero as per [I-D.sajassi-bess-evpn-ip-aliasing]. * IP A-D per ES - Ethernet Auto-Discovery route per ES, and the EVI for one of its route targets is an IP-VRF. * RMAC - Router's MAC, which is signaled in the Router's MAC Wang Expires 24 May 2022 [Page 3] Internet-Draft EVPN IRB Evolution November 2021 extended community. * ESI Overlay Index - ESI as overlay index. * ET-ID - Ethernet Tag ID, it is also called ETI for short in this document. * RT-2R - When a MAC/IP Advertisement Route whose ESI is not zero is used for IP-VRF forwarding, it is called as a RT-2R in this draft. When it is used for MAC-VRF forwarding, it is not called as a RT-2R in this draft. * ETI-Agnostic BD - A Broadcast Domain (BD) whose data packets can be received along with any Ethernet Tag ID (ETI). Note that a broadcast domain of an L2 EVI of VLAN-aware bundle service interface is a good example of an ETI-Specific BD. * ETI-Specific BD - A Broadcast Domain (BD) whose data packets are expected to be received along with a normalized Ethernet Tag ID (ETI). Note that a broadcast domain of an L2 EVI of VLAN-bundle or VLAN-based service interface is a good example of an ETI-Agnostic BD. * BDI-Specific EADR - When the uses BDI-Specific Ethernet Auto-discovery mode, the only Ethernet A-D per EVI route of that is called as a BDI-Specific EADR in this draft. When the AC-type is N:1 mapping, and only a single Ethernet A-D per EVI route is advertised for that , we say that the uses BDI-Specific Ethernet Auto- discovery mode, and that Ethernet A-D per EVI route is called as a BDI-Specific EADR (Ethernet A-D per EVI Route) in this draft. * SOI-Specific EADR - When the uses SOI-specific ethernet auto-discovery mode, the Ethernet A-D per EVI routes of that are called as SOI-Specific EADRs in this draft. When the AC-type is N:1 mapping, and individual Ethernet A-D per EVI routes are advertised per each VLAN of that , we say that the uses SOI-Specific Ethernet Auto-discovery mode, and each of such Ethernet A-D per EVI route is called as a SOI-Specific EADR (Ethernet A-D per EVI Route) in this draft. 2. Problem Statement Wang Expires 24 May 2022 [Page 4] Internet-Draft EVPN IRB Evolution November 2021 2.1. Muti-IRB Use Case vs Mono-IRB Use Case The detailed explanation of this network's physical links are described in Appendix A of [I-D.wang-bess-evpn-ether-tag-id-usage]. But the network's EVCs (Ethernet Virtual Connections, which are typically established per basis) is illustrated in the following sections per each Service Interface. The BD-10 here is the VPNx of Appendix A of [I-D.wang-bess-evpn-ether-tag-id-usage], and the BD-20 is the VPNy of Appendix A of [I-D.wang-bess-evpn-ether-tag-id-usage]. PNEC1 PE1 +------------+ +----------------+ EAD_PE1_20 | | | __(BD-20) | ------------> | H4 " | P1 | / \ IRB21 | | | #================ (IP-VRF) +-----------------+ | N1______" | ESI21 | \__ / IRB11 | | | 10.2 " | + | (BD-10) | | PE3 | " | | +----------------+ +---+----+ | " | | | | | " | | |(IP-VRF)+-+H3 | " | | PE2 | | | N2______" | | +----------------+ EAD_PE2_10 +---+----+ | 20.2 " | + | __(BD-10) | ------------> | | " | ESI21 | / \ IRB12 | | | #================ (IP-VRF) +-----------------+ | " | P2 | \__ / IRB22 | | | | (BD-20) | +------------+ +----------------+ Figure 1: Ethernet A-D per EVI of Multi-IRB BD-10 and BD-20 are both BDs (broadcast domains) whose IRB interfaces are attached to the same IP-VRF. The anycast IP address of IRB11 and IRB12 is 10.9, and the anycast IP address of IRB21 and IRB22 is 20.9. BD-10 and BD-20 are integrated into the same IP-VRF by IRB11, IRB12, IRB21 and IRB22. As a result of that, N1, IRB11 and IRB12 are of subnet SN1, and N2, IRB21 and IRB22 are of subnet SN2. Multi-IRB Use Case - Above network are called as a multi-IRB use case for in this draft. Because two IRB interfaces of ES21's BDs (which are both attached to ESI21) have been attched to a common IP-VRF. Mono-IRB Use Case - Now imagine that the BD-20 of above network Wang Expires 24 May 2022 [Page 5] Internet-Draft EVPN IRB Evolution November 2021 has not been deployed, so there is only one of ESI21's BDs in the IP-VRF's context. In such case, we can say that this is a mono-IRB use case for . Note that when an IP-aliasing-enabled mono-IRB use case for is evolved into a multi-IRB use case for , there may be some issues to be deal with. that's why Note that IRB11 and IRB12 are IRB interfaces of BD-10 where BD-10 is a Broadcast Domain of VLAN-based Service Interface. IRB21 and IRB22 are IRB interfaces of BD-20 where BD-20 is also a Broadcast Domain of VLAN-based Service Interface. 2.2. Problem with IP-aliasing-enabled Multi-IRB Use Case 2.2.1. When IP-aliasing is enabled for a multi-IRB Use Case PNEC1 PE1 +------------+ +----------------+ IPAD_PE1_20 | | | __(BD-20) | ------------> | H4 " | P1 | / \ IRB21 | | | #================ (IP-VRF) +-----------------+ | N1______" | ESI21 | \__ / IRB11 | | | 10.2 " | + | (BD-10) | | PE3 | " | | +----------------+ +---+----+ | " | | | | | " | | |(IP-VRF)+-+H3 | " | | PE2 | | | N2______" | | +----------------+ IPAD_PE2_10 +---+----+ | 20.2 " | + | __(BD-10) | ------------> | | " | ESI21 | / \ IRB12 | | | #================ (IP-VRF) +-----------------+ | " | P2 | \__ / IRB22 | | | | (BD-20) | +------------+ +----------------+ Figure 2: IP-aliasing Enabled Multi-IRB Use Case As an existing network, the attachment circuits are not configured with any virtual ESes. Now this network want to be enhanced with IP- aliasing features of [I-D.sajassi-bess-evpn-ip-aliasing]. According to [I-D.sajassi-bess-evpn-ip-aliasing], the IP A-D per EVI routes R1_110, R1_120, R1_210, R1_220 for P1.1, P1.2, P2.1 and P2.2 will all have zero Ethernet Tag IDs. Wang Expires 24 May 2022 [Page 6] Internet-Draft EVPN IRB Evolution November 2021 When PE3 receives R1_110 and R1_120, it will pick up only one of them to be installed to the data plane. We assume that the R1_120 is picked out. When PE3 receives R1_210 and R1_220, it will pick up only one of them to be installed to the data plane. We assume that the R1_220 is picked out. Although PE1 will advertise a RT-2 Route R2_N1 (whose ESI is ESI21, IP is 10.2) to PE3, When H3 send data packet DP_H3_N1 to N1 after P1.1 fails, PE3 may still send DP_H3_N1 to PE1 because that PE3 will load-balance traffics just fllowing R1_120 and R1_220. That's a problem that will cause packet-drop or traffic-bypassing. The solution for this problem is decribed in Section 3.4.1. 2.2.2. When an IP-aliasing-enabled mono-IRB evolves into multi-IRB Before IP-aliasing is enabled, it is safe for a mono-IRB use case to evolve into a multi-IRB use case. But after IP-aliasing is enabled, it may be dangerous for a mono-IRB use case to evolve into a multi- IRB use case, if not all L2 ACs are configured as separated virtual ESIs before that evolution. Because the RT-1 per EVI confliction which is described in the above section. When it is still a mono-IRB use case, there is no motivation for it to be deployed with all its L2 ACs being previously configured as separated vESIs. Because that virtual ESIs are not so efficient in the following aspects: * Increased RT-4 routes. * Mass-withdraw capability is disabled. * Service Carving is complicated * ES management and configuration are complicated. Because of these reasons, per-AC virtual ESIs is not widely used in normal mono-IRB use case or normal multi-IRB use case as per Section 5 of [RFC9135]. 2.2.3. When distributed Bump-in-the-wire is enabled for a multi-IRB use case When distributed Bump-in-the-wire is enabled for a multi-IRB use case, the similar problem will occur with that multi-IRB use case. This is discussed in Section 2.2 of [I-D.wang-bess-evpn-distributed-bump-in-the-wire]. Wang Expires 24 May 2022 [Page 7] Internet-Draft EVPN IRB Evolution November 2021 3. Solutions Note that the PEs follow [I-D.wang-bess-evpn-arp-nd-synch-without-irb] to achieve the ESI load balance except for the following explicit discription. 3.1. Determining the Aliasing Pathes for RT-2R When PE3 forward a data packet DP_2021 according to an RT-2R route RT2R_2021 whose SOI extended community is not absent, If the SOI of RT2R_2021 is a non-reserved ET-ID, DP_2021 should not be forwarded according to an ethernet A-D per EVI route IPAD_2021, unless the ET- ID of IPAD_2021 are the same as the SOI of RT2R_2021, and the ESI of IPAD_2021 are the same as the ESI of RT2R_2021. Note that in [I-D.sajassi-bess-evpn-ip-aliasing] the IP A-D per EVI route carries a "Router's MAC" extended community in case the RMAC is not the same among different PEs. In these cases, the inner destination MAC of the corresponding data packets from PE3 to PE1/PE2 must use the RMAC in IP A-D per EVI route instead, even if there is a RMAC in RT-2R route. When selecting corresponding IP A-D per EVI routes for a RT-2R route, the SOI Extended Community (if it exists) of the RT-2R route MUST be used. * Using SOI to select SOI-Specific EADRs - In this case, the IP A-D per EVI routes corresponding to that RT-2R route should be selected in the context of the IP-VRF. There may be multiple Ethernet A-D per EVI routes which all can match the RT-2R's ESI. In such case, The Ethernet A-D per EVI routes whose ET-ID are the same as the RT-2R's SOI should be selected. Note that when the RT-2R's SOI is Y, the ET-IDs of the selected Ethernet A-D per EVI routes (of that RT-2R) should be all Y. Note that when the RT-2R's ET-ID is not 0, and an SOI is advertised along with the RT-2R, the IP A-D per EVI routes of that RT-2R should be selected according to the , not according to the . Note that In EVPN IRB use case, the non-zero ET-ID of a RT-2R (when it is used in IP-VRF context) is not used to select the corresponding IP A-D per EVI routes (whose ET-ID will always be zero according to Section 2.1 of [I-D.sajassi-bess-evpn-ip-aliasing]) of that RT-2R route. Wang Expires 24 May 2022 [Page 8] Internet-Draft EVPN IRB Evolution November 2021 3.2. ACI-specific Overlay Index Extended Community A new EVPN BGP Extended Community called Supplementary Overlay Index is introduced [I-D.wang-bess-evpn-distributed-bump-in-the-wire]. This new extended community is used together with ACI-specific ethernet auto-discovery specified in [I-D.wang-bess-evpn-distributed-bump-in-the-wire]. In this draft it is used to make a deployed multi-IRB to be smoothly evoluted to ip-aliasing features. 3.3. ARP/ND Synching and IP Aliasing 3.3.1. Constructing MAC/IP Advertisement Route This draft introduces a new usage/construction of MAC/IP Advertisement route to enable Aliasing for IP addresses in symmetric EVPN IRB use-cases. The usage/construction of this route remains similar to that described in [I-D.sajassi-bess-evpn-ip-aliasing] with a few notable exceptions as below. * The Ethernet Tag ID should be set to 0 according to [I-D.sajassi-bess-evpn-ip-aliasing]. * The value of SOI Extended Communinty should be set to the SOI of the L2 AC over which the ARP entry of the RT-2R is learnt. Note that when the SOI Extended Communinty is carried along with a RT-2R route, the will be used to select IP A-D per EVI routes by PE3, and the selected IP A-D per EVI routes are used to determine the aliasing pathes of this RT-2 route. But if the SOI Extended Communinty is absent, the aliasing pathes of this RT-2R route will be determined by as per [I-D.sajassi-bess-evpn-ip-aliasing]. * In EVPN IRB, The ESI SHOULD be set to the ESI of the L2 AC from which the ARP entry is snooped as per [I-D.sajassi-bess-evpn-ip-aliasing]. Note that on PE3, the is only used to load balance traffics. * The RMAC Extended Community attribute SHOULD be carried in VXLAN EVPN. This follows [RFC9135]. Wang Expires 24 May 2022 [Page 9] Internet-Draft EVPN IRB Evolution November 2021 3.3.2. Constructing IP A-D per EVI Route The usage/construction of this route is similar to the IP A-D per EVI route described in [I-D.sajassi-bess-evpn-ip-aliasing] with a few notable exceptions as below. * The Ethernet Tag ID (ET-ID) should be set to the SOI of the L2 AC for which it is advertised. Note that the normal Ethernet A-D per EVI routes for BDs are not influenced. And the SOI Extended Community will be advertised along with the RT-2R routes which are learnt over that L2 AC. 3.4. Secenario-Specific Procedures 3.4.1. EVPN-IRB Specific Procedures PE1 may advertise two Ethernet A-D per EVI routes for subinterface P1.1, one (say R1_110b) is for BD-10 (which is of VLAN-based service interface), the other (that R1_110) is for IP-VRF. The Ethernet Tag ID of R1_110b is zero per [RFC7432], but the Ethernet Tag ID of R1_110 is set to the VLANs of P1.1 according to this draft. When PE1 advertise a RT-2R Route for a host (10.0.0.2) behind BD-10, the Ethernet Tag ID of that RT-2R Route is determined by the out- interface (P1.1) of the MAC of that host's ARP entry. If the MAC is learnt from an ETI-specific BD, the ET-ID of the RT-2R route should be set to the BD-ID is that ETI-Specific BD. But the ET-ID of the RT-2R route is not used to select the corresponding IP A-D per EVI routes. Note that R1_110b will not be imported into the IP-VRF. 3.4.2. Bump-in-the-wire Specific Procedures It is discussed in Section 3.2 of [I-D.wang-bess-evpn-distributed-bump-in-the-wire]. 4. IANA Considerations TBD. 5. Security Considerations TBD. 6. References Wang Expires 24 May 2022 [Page 10] Internet-Draft EVPN IRB Evolution November 2021 6.1. Normative References [I-D.sajassi-bess-evpn-ip-aliasing] Sajassi, A., Badoni, G., Warade, P., Pasupula, S., Drake, J., and J. Rabadan, "EVPN Support for L3 Fast Convergence and Aliasing/Backup Path", Work in Progress, Internet- Draft, draft-sajassi-bess-evpn-ip-aliasing-03, 25 October 2021, . [I-D.wang-bess-evpn-distributed-bump-in-the-wire] Wang, Y. and Q. Niu, "Distributed Bump-in-the-wire Use Case", Work in Progress, Internet-Draft, draft-wang-bess- evpn-distributed-bump-in-the-wire-01, 24 October 2021, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, . [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, . [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, . 6.2. Informative References [I-D.ietf-bess-evpn-modes-interop] Krattiger, L., Sajassi, A., Thoria, S., Rabadan, J., and J. E. Drake, "EVPN Interoperability Modes", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-modes- interop-00, 31 May 2021, . Wang Expires 24 May 2022 [Page 11] Internet-Draft EVPN IRB Evolution November 2021 [I-D.ietf-bess-srv6-services] Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay Services", Work in Progress, Internet-Draft, draft-ietf-bess-srv6-services-08, 10 November 2021, . [I-D.sajassi-bess-evpn-ac-aware-bundling] Sajassi, A., Brissette, P., Mishra, M., Thoria, S., Rabadan, J., and J. Drake, "AC-Aware Bundling Service Interface in EVPN", Work in Progress, Internet-Draft, draft-sajassi-bess-evpn-ac-aware-bundling-04, 11 July 2021, . [I-D.wang-bess-evpn-arp-nd-synch-without-irb] Wang, Y. and Z. Zhang, "ARP/ND Synching And IP Aliasing without IRB", Work in Progress, Internet-Draft, draft- wang-bess-evpn-arp-nd-synch-without-irb-08, 1 September 2021, . [I-D.wang-bess-evpn-ether-tag-id-usage] Wang, Y., "Ethernet Tag ID Usage Update for Ethernet A-D per EVI Route", Work in Progress, Internet-Draft, draft- wang-bess-evpn-ether-tag-id-usage-03, 26 August 2021, . [I-D.wz-bess-evpn-vpws-as-vrf-ac] Wang, Y. and Z. Zhang, "EVPN VPWS as VRF Attachment Circuit", Work in Progress, Internet-Draft, draft-wz-bess- evpn-vpws-as-vrf-ac-02, 28 August 2021, . Author's Address Yubao Wang ZTE Corporation No.68 of Zijinghua Road, Yuhuatai Distinct Nanjing China Email: wang.yubao2@zte.com.cn Wang Expires 24 May 2022 [Page 12]