idnits 2.17.1 draft-sivabalan-pce-binding-label-sid-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 5, 2019) is 1899 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 (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 9, 2019 J. Tantsura 6 Apstra, Inc. 7 J. Hardwick 8 Metaswitch Networks 9 S. Previdi 10 C. Li 11 Huawei Technologies 12 February 5, 2019 14 Carrying Binding Label/Segment-ID in PCE-based Networks. 15 draft-sivabalan-pce-binding-label-sid-06 17 Abstract 19 In order to provide greater scalability, network opacity, and service 20 independence, SR utilizes a Binding Segment Identifier (BSID). It is 21 possible to associate a BSID to RSVP-TE signaled Traffic Engineering 22 Label Switching Path or binding Segment-ID (SID) to Segment Routed 23 (SR) Traffic Engineering path. Such a binding label/SID can be used 24 by an upstream node for steering traffic into the appropriate TE path 25 to enforce SR policies. This document proposes an approach for 26 reporting binding label/SID to Path Computation Element (PCE) for 27 supporting PCE-based Traffic Engineering policies. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 9, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8 78 6.1.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . . 8 79 6.2. PCEP Error Type and Value . . . . . . . . . . . . . . . . 9 80 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 9.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 A PCE can compute Traffic Engineering paths (TE paths) through a 91 network that are subject to various constraints. Currently, TE paths 92 are either set up using the RSVP-TE signaling protocol or Segment 93 Routing (SR). We refer to such paths as RSVP-TE paths and SR-TE 94 paths respectively in this document. 96 As per [RFC8402] SR allows a headend node to steer a packet flow 97 along any path. The headend node is said to steer a flow into an 98 Segment Routing Policy (SR Policy). Further, as per 99 [I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework 100 that enables instantiation of an ordered list of segments on a node 101 for implementing a source routing policy with a specific intent for 102 traffic steering from that node. 104 As described in [RFC8402], Binding Segment Identifier (BSID) is bound 105 to an Segment Routed (SR) Policy, instantiation of which may involve 106 a list of SIDs. Any packets received with an active segment equal to 107 BSID are steered onto the bound SR Policy. A BSID may be either a 108 local (SRLB) or a global (SRGB) SID. As per 109 [I-D.ietf-spring-segment-routing-policy] a BSID can also be 110 associated with any type of interfaces or tunnel to enable the use of 111 a non-SR interface or tunnels as segments in a SID-list. 113 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 114 communication between a Path Computation Client (PCC) and a PCE or 115 between a pair of PCEs as per [RFC4655]. [RFC8231] specifies 116 extension to PCEP that allows a PCC to delegate its LSPs to a 117 stateful PCE. A stateful PCE can then update the state of LSPs 118 delegated to it. [RFC8281] specifies a mechanism allowing a PCE to 119 dynamically instantiate an LSP on a PCC by sending the path and 120 characteristics. The PCEP extension to setup and maintain SR-TE 121 paths is specified in [I-D.ietf-pce-segment-routing]. 123 [I-D.ietf-pce-segment-routing] provides a mechanism for a network 124 controller (acting as a PCE) to instantiate candidate paths for an SR 125 Policy onto a head-end node (acting as a PCC) using PCEP. For more 126 information on the SR Policy Architecture, see 127 [I-D.ietf-spring-segment-routing-policy]. 129 Binding label/SID has local significance to the ingress node of the 130 corresponding TE path. When a stateful PCE is deployed for setting 131 up TE paths, it may be desirable to report the binding label or SID 132 to the stateful PCE for the purpose of enforcing end-to-end TE/SR 133 policy. A sample Data Center (DC) use-case is illustrated in the 134 following diagram. In the MPLS DC network, an SR LSP (without 135 traffic engineering) is established using a prefix SID advertised by 136 BGP (see [I-D.ietf-idr-bgp-prefix-sid]). In IP/MPLS WAN, an SR-TE 137 LSP is setup using the PCE. The list of SIDs of the SR-TE LSP is {A, 138 B, C, D}. The gateway node 1 (which is the PCC) allocates a binding 139 SID X and reports it to the PCE. In order for the access node to 140 steer the traffic over the SR-TE LSP, the PCE passes the SID stack 141 {Y, X} where Y is the prefix SID of the gateway node-1 to the access 142 node. In the absence of the binding SID X, the PCE should pass the 143 SID stack {Y, A, B, C, D} to the access node. This example also 144 illustrates the additional benefit of using the binding SID to reduce 145 the number of SIDs imposed on the access nodes with a limited 146 forwarding capacity. 148 SID stack 149 {Y, X} +-----+ 150 _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | 151 | +-----+ 152 | ^ 153 | | Binding 154 | .-----. | SID (X) .-----. 155 | ( ) | ( ) 156 V .--( )--. | .--( )--. 157 +------+ ( ) +-------+ ( ) +-------+ 158 |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| 159 | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | 160 +------+ ( SR path ) +-------+ ( SR-TE path ) +-------+ 161 '--( )--' Prefix '--( )--' 162 ( ) SID of ( ) 163 '-----' Node-1 '-----' 164 is Y SIDs for SR-TE LSP: 165 {A, B, C, D} 167 Figure 1: A sample Use-case of Binding SID 169 A PCC could report the binding label/SID allocated by it to the 170 stateful PCE via Path Computation State Report (PCRpt) message. It 171 is also possible for a stateful PCE to request a PCC to allocate a 172 specific binding label/SID by sending an Path Computation Update 173 Request (PCUpd) message. If the PCC can successfully allocate the 174 specified binding value, it reports the binding value to the PCE. 175 Otherwise, the PCC sends an error message to the PCE indicating the 176 cause of the failure. A local policy or configuration at the PCC 177 SHOULD dictate if the binding label/SID needs to be assigned. 179 In this document, we introduce a new OPTIONAL TLV that a PCC can use 180 in order to report the binding label/SID associated with a TE LSP, or 181 a PCE to request a PCC to allocate a specific binding label/SID 182 value. This TLV is intended for TE LSPs established using RSVP-TE, 183 SR, or any other future method. Also, in the case of SR-TE LSPs, the 184 TLV can carry a binding MPLS label (for SR-TE path with MPLS data- 185 plane) or a binding IPv6 SID (e.g., IPv6 address for SR-TE paths with 186 IPv6 data-plane). However, use of this TLV for carrying non-MPLS 187 binding SID will be described in separate document(s). Binding value 188 means either MPLS label or SID throughout this document. 190 Additionally, to support the PCE based central controller [RFC8283] 191 operation where the PCE would take responsibility for managing some 192 part of the MPLS label space for each of the routers that it 193 controls, the PCE could directly make the binding label/SID 194 allocation and inform the PCC. See 195 [I-D.ietf-pce-pcep-extension-for-pce-controller] for details. 197 2. Terminology 199 The following terminologies are used in this document: 201 BSID: Binding Segment Identifier. 203 LER: Label Edge Router. 205 LSP: Label Switched Path. 207 LSR: Label Switching Router. 209 PCC: Path Computation Client. 211 PCE: Path Computation Element 213 PCEP: Path Computation Element Protocol. 215 RSVP-TE: Resource ReserVation Protocol-Traffic Engineering. 217 SID: Segment Identifier. 219 SR: Segment Routing. 221 SRGB: Segment Routing Global Block. 223 SRLB: Segment Routing Local Block. 225 TLV: Type, Length, and Value. 227 3. Path Binding TLV 229 The new optional TLV is called "TE-PATH-BINDING TLV" whose format is 230 shown in the diagram below is defined to carry binding label or SID 231 for a TE path. This TLV is associated with the LSP object specified 232 in ([RFC8231]). The type of this TLV is to be allocated by IANA. 234 0 1 2 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type | Length | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | BT | Reserved | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 ~ Binding Value (variable length) ~ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: TE-PATH-BINDING TLV 246 TE-PATH-BINDING TLV is a generic TLV such that it is able to carry 247 MPLS label binding as well as other types of future bindings (e.g., 248 SRv6 path). It is formatted according to the rules specified in 249 [RFC5440]. 251 Binding Type (BT): A one byte field identifies the type of binding 252 included in the TLV. This document specifies the following BT 253 values: 255 o BT = 0: The binding value is an MPLS label carried in the format 256 specified in [RFC5462] where only the label value is valid, and 257 other fields (TC, S, and TTL) fields MUST be considered invalid. 258 The Length MUST be set to 6. 260 o BT = 1: Similar to the case where BT is 0 except that all the 261 fields on the MPLS label entry are set on transmission. However, 262 the receiver MAY choose to override TC, S, and TTL values 263 according its local policy. 265 o BT = 2: The binding value is a SRv6 SID with a format of an 16 266 byte IPv6 address, representing the binding SID for SRv6. 268 Reserved: MUST be set to 0 while sending and ignored on receipt. 270 Binding Value: A variable length field, padded with trailing zeros to 271 a 4-byte boundary. For the BT as 0, the 20 bits represents the MPLS 272 label. For the BT as 1, the 32-bits represents the label stack entry 273 as per [RFC5462]. For the BT as 2, the 128-bits represent the SRv6 274 SID. 276 4. Operation 278 The binding value is allocated by the PCC and reported to a PCE via 279 PCRpt message. If a PCE does not recognize the TE-PATH-BINDING TLV, 280 it MUST ignore the TLV in accordance with ([RFC5440]). If a PCE 281 recognizes the TLV but does not support the TLV, it MUST send PCErr 282 with Error-Type = 2 (Capability not supported). 284 If a TE-PATH-BINDING TLV is absent in PCRpt message, PCE MUST assume 285 that the corresponding LSP does not have any binding. If there are 286 more than one TE-PATH-BINDING TLVs, only the first TLV MUST be 287 processed and the rest MUST be silently ignored. If a PCE recognizes 288 an invalid binding value (e.g., label value from the reserved label 289 space when MPLS label binding is used), it MUST send the PCErr 290 message with Error-Type = 10 ("Reception of an invalid object") and 291 Error Value = TBD ("Bad label value") as specified in 292 [I-D.ietf-pce-segment-routing]. 294 If a PCE requires a PCC to allocate a specific binding value, it may 295 do so by sending a PCUpd or PCInitiate message containing a TE-PATH- 296 BINDING TLV. If the value can be successfully allocated, the PCC 297 reports the binding value to the PCE. If the PCC considers the 298 binding value specified by the PCE invalid, it MUST send a PCErr 299 message with Error-Type = TBD ("Binding label/SID failure") and Error 300 Value = TBD ("Invalid SID"). If the binding value is valid, but the 301 PCC is unable to allocate the binding value, it MUST send a PCErr 302 message with Error-Type = TBD ("Binding label/SID failure") and Error 303 Value = TBD ("Unable to allocate the specified label/SID"). 305 If a PCC receives TE-PATH-BINDING TLV in any message other than PCUpd 306 or PCInitiate, it MUST close the corresponding PCEP session with the 307 reason "Reception of a malformed PCEP message" (according to 308 [RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in 309 any message other than a PCRpt or if the TE-PATH-BINDING TLV is 310 associated with any object other than LSP object, the PCE MUST close 311 the corresponding PCEP session with the reason "Reception of a 312 malformed PCEP message" (according to [RFC5440]). 314 If a PCC wishes to withdraw or modify a previously reported binding 315 value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV 316 or with the TE-PATH-BINDING TLV containing the new binding value 317 respectively. 319 If a PCE wishes to modify a previously requested binding value, it 320 MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new 321 binding value. Absence of TE-PATH-BINDING TLV in PCUpd message means 322 that the PCE does not specify a binding value in which case the 323 binding value allocation is governed by the PCC's local policy. 325 If a PCC receives a valid binding value from a PCE which is different 326 than the current binding value, it MUST try to allocate the new 327 value. If the new binding value is successfully allocated, the PCC 328 MUST report the new value to the PCE. Otherwise, it MUST send a 329 PCErr message with Error-Type = TBD ("Binding label/SID failure") and 330 Error Value = TBD ("Unable to allocate the specified label/SID"). 332 In some cases, a stateful PCE can request the PCC to allocate a 333 binding value. It may do so by sending a PCUpd message containing an 334 empty TE-PATH-BINDING TLV, i.e., no binding value is specified 335 (making the length field of the TLV as 2). A PCE can also make the 336 request PCC to allocate a binding at the time of initiation by 337 sending a PCInitiate message with an empty TE-PATH-BINDING TLV. 339 5. Security Considerations 341 The security considerations described in [RFC5440], [RFC8231], 342 [RFC8281] and [I-D.ietf-pce-segment-routing] are applicable to this 343 specification. No additional security measure is required. 345 As described [I-D.ietf-pce-segment-routing], SR allows a network 346 controller to instantiate and control paths in the network. Note 347 that if the security mechanisms of [RFC5440] and [RFC8281] are not 348 used, then the protocol described in this document could be attacked 349 via manipulation of BSID. 351 6. IANA Considerations 353 6.1. PCEP TLV Type Indicators 355 This document defines a new PCEP TLV; IANA is requested to make the 356 following allocations from the "PCEP TLV Type Indicators" sub- 357 registry of the PCEP Numbers registry, as follows: 359 Value Name Reference 361 TBD TE-PATH-BINDING This document 363 6.1.1. TE-PATH-BINDING TLV 365 IANA is requested to create a sub-registry to manage the value of the 366 Binding Type field in the TE-PATH-BINDING TLV. 368 Value Description Reference 370 0 MPLS Label This document 371 1 MPLS Label Stack This document 372 Entry 374 6.2. PCEP Error Type and Value 376 This document defines a new Error-type and Error-Values for the PCErr 377 message. IANA is requested to allocate new error-type and error- 378 values within the "PCEP-ERROR Object Error Types and Values" 379 subregistry of the PCEP Numbers registry, as follows: 381 Error-Type Meaning 382 ---------- ------- 383 TBD Binding label/SID failure: 385 Error-value = TBD: Invalid SID 386 Error-value = TBD: Unable to allocate 387 the specified 388 label/SID 390 7. Manageability Considerations 392 TBD 394 8. Acknowledgements 396 We like to thank Milos Fabian for his valuable comments. 398 9. References 400 9.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 408 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 409 DOI 10.17487/RFC5440, March 2009, 410 . 412 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 413 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 414 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 415 2009, . 417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 419 May 2017, . 421 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 422 Computation Element Communication Protocol (PCEP) 423 Extensions for Stateful PCE", RFC 8231, 424 DOI 10.17487/RFC8231, September 2017, 425 . 427 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 428 Computation Element Communication Protocol (PCEP) 429 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 430 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 431 . 433 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 434 Decraene, B., Litkowski, S., and R. Shakir, "Segment 435 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 436 July 2018, . 438 [I-D.ietf-pce-segment-routing] 439 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 440 and J. Hardwick, "PCEP Extensions for Segment Routing", 441 draft-ietf-pce-segment-routing-14 (work in progress), 442 October 2018. 444 9.2. Informative References 446 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 447 Element (PCE)-Based Architecture", RFC 4655, 448 DOI 10.17487/RFC4655, August 2006, 449 . 451 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 452 Architecture for Use of PCE and the PCE Communication 453 Protocol (PCEP) in a Network with Central Control", 454 RFC 8283, DOI 10.17487/RFC8283, December 2017, 455 . 457 [I-D.ietf-spring-segment-routing-policy] 458 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 459 bogdanov@google.com, b., and P. Mattes, "Segment Routing 460 Policy Architecture", draft-ietf-spring-segment-routing- 461 policy-02 (work in progress), October 2018. 463 [I-D.ietf-idr-bgp-prefix-sid] 464 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 465 and H. Gredler, "Segment Routing Prefix SID extensions for 466 BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), 467 June 2018. 469 [I-D.ietf-pce-pcep-extension-for-pce-controller] 470 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 471 and C. Zhou, "PCEP Procedures and Protocol Extensions for 472 Using PCE as a Central Controller (PCECC) of LSPs", draft- 473 ietf-pce-pcep-extension-for-pce-controller-00 (work in 474 progress), November 2018. 476 Appendix A. Contributor Addresses 478 Dhruv Dhody 479 Huawei Technologies 480 Divyashree Techno Park, Whitefield 481 Bangalore, Karnataka 560066 482 India 484 EMail: dhruv.ietf@gmail.com 486 Mahendra Singh Negi 487 Huawei Technologies 488 Divyashree Techno Park, Whitefield 489 Bangalore, Karnataka 560066 490 India 492 EMail: mahendrasingh@huawei.com 494 Authors' Addresses 496 Siva Sivabalan 497 Cisco Systems, Inc. 498 2000 Innovation Drive 499 Kanata, Ontario K2K 3E8 500 Canada 502 EMail: msiva@cisco.com 504 Clarence Filsfils 505 Cisco Systems, Inc. 506 Pegasus Parc 507 De kleetlaan 6a, DIEGEM BRABANT 1831 508 BELGIUM 510 EMail: cfilsfil@cisco.com 512 Jeff Tantsura 513 Apstra, Inc. 515 EMail: jefftant.ietf@gmail.com 516 Jonathan Hardwick 517 Metaswitch Networks 518 100 Church Street 519 Enfield, Middlesex 520 UK 522 EMail: Jonathan.Hardwick@metaswitch.com 524 Stefano Previdi 525 Huawei Technologies 527 EMail: stefano@previdi.net 529 Cheng Li 530 Huawei Technologies 531 Huawei Campus, No. 156 Beiqing Rd. 532 Beijing 100095 533 China 535 EMail: chengli13@huawei.com