idnits 2.17.1 draft-bonica-spring-srv6-end-dtm-07.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 2 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (5 January 2022) is 835 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.hegde-spring-mpls-seamless-sr' is defined on line 514, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-08 == Outdated reference: A later version (-07) exists of draft-hegde-spring-mpls-seamless-sr-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group S. Hegde 3 Internet-Draft P. Kaneriya 4 Intended status: Standards Track R. Bonica 5 Expires: 9 July 2022 Juniper Networks 6 P. Shaofu 7 G. Mirsky 8 Z. Zhang 9 ZTE Corporation 10 B. Decraene 11 Orange 12 5 January 2022 14 SR-MPLS / SRv6 Transport Interworking 15 draft-bonica-spring-srv6-end-dtm-07 17 Abstract 19 This document describes procedures for interworking between an SR- 20 MPLS transit domain and an SRv6 transit domain. Each domain contains 21 Provider Edge (PE) and Provider (P) routers. Area Border Routers 22 (ABR) provide connectivity between domains. 24 The procedures described in this document require the ABR to carry a 25 route to each PE router. However, they do not required the ABR to 26 carry service (i.e., customer) routes. In that respect, these 27 procedures resemble L3VPN Interprovider Option C. 29 Procedures described in this document support interworking for global 30 IPv4 and IPv6 service prefixes. They do not support interworking for 31 VPN services prefixes where the SR-MPLS domain uses MPLS service 32 labels. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 9 July 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 3. Reference Topology . . . . . . . . . . . . . . . . . . . . . 3 69 4. Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. END.DM Processing . . . . . . . . . . . . . . . . . . . . 6 71 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Signaling SR Paths That Originate In The SRv6 Domain . . 8 73 5.2. Signaling SR Paths That Originate In The SR-MPLS 74 Domain . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 9.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Overview 85 Segment Routing (SR) [RFC8402] allows source nodes to steer packets 86 through SR paths. It can be implemented over IPv6 [RFC8200] or MPLS 87 [RFC3031]. When SR is implemented over IPv6, it is called SRv6 88 [RFC8986]. When SR is implemented over MPLS, it is called SR-MPLS 89 [RFC8660]. 91 This document describes procedures for interworking between an SR- 92 MPLS transit domain and an SRv6 transit domain. Each domain contains 93 Provider Edge (PE) and Provider (P) routers. Area Border Routers 94 (ABR) provide connectivity between domains. 96 The procedures described in this document require the ABR to carry a 97 route to each PE router. However, they do not required the ABR to 98 carry service (i.e., customer) routes. In that respect, these 99 procedures resemble L3VPN Interprovider Option C [RFC4364]. 101 Procedures described in this document support interworking for global 102 IPv4 and IPv6 service prefixes. They do not support interworking for 103 VPN services prefixes where the SR-MPLS domain uses MPLS service 104 labels. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Reference Topology 116 ----------------------- SR Path 1 --------------------------> 118 <---------------------- SR Path 2 -------------------------- 120 ------ ------ ------ ------ ------ 121 | PE | | P | | ABR | | P | | PE | 122 |Node 1| --- |Node 2| --- |Node 3| --- |Node 4| --- |Node 5| 123 ------ ------ ------ ------ ------ 125 Seg. A Seg. B Seg. C Seg. D Seg. E 127 <---------- SRv6 Domain ----------> 128 <--------- SR-MPLS Domain ---------> 130 Figure 1: Interworking Between SR Domains 132 Figure 1 depicts interworking between an SR-MPLS domain and an SRv6 133 domain. The SRv6 domain contains PE Node 1 and P Node 2. The SR- 134 MPLS domain contains P Node 4 and PE node 5. Both domains contain 135 ABR Node 3. 137 Nodes 1 and 2 MUST support SRv6 but are NOT REQUIRED to support SR- 138 MPLS. Nodes 4 and 5 MUST support SR-MPLS but are NOT required to 139 support SRv6. Node 3 MUST support both SRv6 and SR-MPLS. It must 140 also support interworking procedures. 142 Network operators configure a loopback interface on Nodes 1 through 143 5. These are called Loopback1 through Loopback5. They also 144 configure 2 additional loopback interfaces on PE Node 5. These are 145 called Loopback5.IPv4 and Loopback5.IPv6. 147 Each node instantiates an SR Segment (i.e., Segment A through Segment 148 E). SR Path 1 begins on PE Node 1 and ends on PE Node 5. It visits 149 Nodes 2, 3, 4, and 5, executing the instructions associated with 150 Segments B, C, and D. SR Path 2 begins on PE Node 5 and ends on PE 151 Node 1. It visits Nodes 4, 3, 2, and 1, executing the instructions 152 associated with Segments D, C, B and A. 154 4. Forwarding Plane 156 ----------------------- SR Path 1 --------------------------> 158 ------ ------ ------ ------ ------ 159 | PE | | P | | ABR | | P | | PE | 160 |Node 1| --- |Node 2| --- |Node 3| --- |Node 4| --- |Node 5| 161 ------ ------ ------ ------ ------ 163 Seg. A Seg. B Seg. C Seg. D Seg. E 165 IPv6: IPv6: SR-MPLS: SR-MPLS: 166 SA: Node 1 SA: Node 1 Seg. D Exp. Null 167 DA: Seg. B DA: Seg. C Exp. Null Payload 168 SRH: SRH: Payload 169 SL: 1 SL: 0 170 SID: Seg. C SID: Seg. C 171 Payload Payload 173 Figure 2: Encapsulation: SRv6 To SR-MPLS 175 Figure 2 depicts the forwarding plane as a packet traverses SR Path 176 1, from Node 1 to Node 5. In this example, PE Node 1 receives an 177 IPv4 packet. 179 PE Node 1 encapsulates the IPv4 packet in an SRv6 header. The SRv6 180 header contains an IPv6 header and a Segment Routing Header (SRH) 181 [RFC8754]. The Destination Address in the IPv6 header is a Segment 182 Identifier (SID) that represents Segment B. Segment B is an END 183 instruction instantiated on P Node 2. The SRH contains a Segments 184 Left field and one SID. The Segments Left field is equal to 1 and 185 the SID represents Segment C, and END.DM (Section 4.1) instruction 186 instantiated on ABR Node 3. 188 PE Node 1 forwards the packet to P Node 2. When P Node 2 receives 189 the packet, it processed the END instruction. It decrements the 190 Segments Left field in the SRH and copies the SID from the SRH to the 191 Destination Address field of the IPv6 header. It then forwards the 192 packet to ABR Node 3. 194 When ABR Node 3 receives the packet, it processes the END.DM 195 instruction. It removes the SRv6 header and replaces it with an SR- 196 MPLS label stack that contains two entries. The top entry represents 197 a prefix SID instantiated on P Node 4. The bottom entry is an 198 Explicit Null instruction (i.e., MPLS label 0), instantiated on PE 199 Node 5. 201 ABR Node 3 then forwards the packet to P Node 4. P Node 4 processes 202 the prefix SID, removing the top entry from the SR-MPLS label stack 203 and forwarding the packet to PE Node 5. PE Node 5 processes the 204 Explicit Null instruction, removing the remaining SR-MPLS label stack 205 entry and processing the payload. 207 <----------------------- SR Path 2 -------------------------- 209 ------ ------ ------ ------ ------ 210 | PE | | P | | ABR | | P | | PE | 211 |Node 1| --- |Node 2| --- |Node 3| --- |Node 4| --- |Node 5| 212 ------ ------ ------ ------ ------ 214 Seg. A Seg. B Seg. C Seg. D Seg. E 216 IPv6: IPv6: SR-MPLS: SR-MPLS: 217 SA: Node 3 SA: Node 3 Seg. C Seg. D 218 DA: Seg. A DA: Seg. B Payload Seg. C 219 SRH: SRH: Payload 220 SL: 0 SL: 1 221 SID: Seg. A SID: Seg. A 222 Payload Payload 224 Figure 3: Encapsulation: SR-MPLS to IPv6 226 Figure 3 depicts the forwarding plane as a packet traverses SR Path 227 2, from Node 5 to Node 1. In this example, PE Node 5 receives an 228 IPv4 packet. 230 PE Node 5 encapsulates the IPv4 packet in an SR-MPLS label stack that 231 contains two entries. The top entry represents a prefix SID 232 instantiated on P Node 4. The bottom entry is a binding SID 233 instantiated on ABR Node 3. 235 PE Node 5 then forwards the packet to P Node 4. P Node 4 processes 236 the prefix SID, removing the top entry from the SR-MPLS label stack 237 and forwarding the packet to ABR Node 3. ABR Node 3 processes 238 binding SID, removing the remaining SR-MPLS label stack entry and 239 replacing it with an SRv6 header. The SRv6 header contains an IPv6 240 header and an SRH. The Destination Address in the IPv6 header is a 241 Segment Identifier (SID) that represents Segment B. Segment B is an 242 END instruction instantiated on P Node 2. The SRH contains a 243 Segments Left field and one SID. The Segments Left field is equal to 244 1 and the SID represents Segment A, an END.DT46 instruction 245 instantiated on PE Node 1. That instruction causes the packet to be 246 forwarded using the main IP forwarding table, not a VPN forwarding 247 table. 249 ABR Node 3 forwards the packet to P Node 2. When P Node 2 receives 250 the packet, it processed the END instruction. It decrements the 251 Segments Left field in the SRH and copies the SID from the SRH to the 252 Destination Address field of the IPv6 header. It then forwards the 253 packet to PE Node 1. PE Node 1 processes its END.DT46 instruction, 254 removing the SRv6 header and processing the payload. 256 4.1. END.DM Processing 258 The End.DM SID MUST be the last segment in a SR Policy. Its 259 arguments are associated with an SR-MPLS label stack. 261 When Node N receives a packet destined to S and S is a locally 262 instantiated End.DM SID, Node N executes the following procedure: 264 S01. When an IPv6 Routing Header is processed { 265 S02. If (Segments Left != 0) { 266 S03. Send an ICMP Parameter Problem to the Source Address, 267 Code 0 (Erroneous header field encountered), 268 Pointer set to the Segments Left field, 269 interrupt packet processing and discard the packet. 270 S04. } 271 S05. Proceed to process the next header in the packet 272 S06. } 274 When processing the Upper-layer header of a packet matching a FIB 275 entry locally instantiated as an End.DM SID, N executes the following 276 procedure: 278 S01. Decapsulate the packet (i.e., remove the outer IPv6 Header and all 279 its extension headers) 280 S02. Push the SR-MPLS label stack that is associated with the END.DM 281 arguments. Set the MPLS Traffic Class and TTL values to reflect 282 the Traffic Class and Hop count values received in the IPv6 header. 283 S03. Submit the packet to the MPLS FIB lookup for transmission to the 284 new destination 286 5. Control Plane 288 <------------------- Customer Routes (iBGP) --------------> 290 <-- PE and ABR Routes (iBGP) -> 291 <-- PE and ABR Routes(BGP-LU) -> 292 ------ ------ ------ ------ ------ 293 | PE | | P | | ABR | | P | | PE | 294 |Node 1| --- |Node 2| --- |Node 3| --- |Node 4| --- |Node 5| 295 ------ ------ ------ ------ ------ 297 <---------- SRv6 Domain ----------> 298 <--------- SR-MPLS Domain ---------> 300 Figure 4: BGP NLRI Exchange 302 In the Figure 4, PE Node 1 and PE Node 5 exchange customer Network 303 Layer Reachability Information (NLRI) [RFC4271] using either a direct 304 BGP session or a route reflector [RFC4456]. All customer routes 305 exchanged between PE Node 1 and PE Node 5 belong to the general 306 routing instance. They cannot belong to a VPN. 308 PE Node 1 exchanges loopback routes with ABR Node 3, using either a 309 direct BGP session or a route reflector. Likewise, ABR Node 3 310 exchanges loopback with PE Node 5, using either a direct BGP session 311 or a route reflector. 313 PE Node 1 and ABR Node 3 bind SIDs to the loopback routes that they 314 exchange, as described in [I-D.ietf-bess-srv6-services]. PE Node 5 315 and ABR Node 3 bind labels to the loopback routes that they exchange, 316 as described in [RFC8277]. 318 Both domains use an IGP to distribute link state information and 319 establish connectivity within the domain. 321 5.1. Signaling SR Paths That Originate In The SRv6 Domain 323 PE Node 5 advertises an IPv4 customer route to PE Node 1 using BGP as 324 follows: 326 * IPv4 Prefix 328 * Next-hop: Loopback5.IPv4 330 This causes PE Node 1 to resolve the customer route through its route 331 to Loopback5.IPv4. The following paragraphs describe how PE Node 1 332 acquires a route to Loopback5.IPv4. 334 PE Node 5 advertises Loopback5.IPv4 to ABR Node 3 using BGP Labeled 335 Unicast (BGP-LU) as follows: 337 * Prefix: Loopback5.IPv4 339 * Next-hop: Loopback5 341 * Color Community: Color to distinguish between paths between ABR 342 Node 3 and PE Node 5 344 * MPLS Label: Explicit Null (0) 346 Now, ABR Node 3 resolves its route to Loopback5.IPv4 through its IGP 347 route to Loopback5. Therefore, when forwarding traffic bound for 348 Loopback5.IPv4, it imposes: 350 * An SR-MPLS label stack associated with the IGP route to Loopback5 352 * An additional Explicit Null label 354 ABR Node 3 advertises Loopback5.IPv4 to PE Node 1 using BGP as 355 follows: 357 * Prefix: Loopback5.IPv4 359 * Next-hop: Loopback3 361 * Color Community: Color to distinguish between paths between ABR 362 Node 3 and PE Node 1 364 * SID: SID C (i.e., an END.DM SID instantiated on ABR Node 3) 366 Now, PE Node 1 resolves its route to Loopback5.IPv4 through its IGP 367 route to Loopback3. Therefore, when forwarding traffic bound for 368 Loopback5.IPv4, it imposes an SRv6 header that includes the following 369 SIDs: 371 * SIDS associated with the IGP route to Loopback3 373 * SID C 375 5.2. Signaling SR Paths That Originate In The SR-MPLS Domain 377 PE Node 1 advertises an IPv4 customer route to PE Node 5 using BGP as 378 follows: 380 * IPv4 Prefix 382 * Next-hop: Loopback1 384 This causes PE Node 5 to resolve the customer route through its route 385 to Loopback1. The following paragraphs describe how PE Node 5 386 acquires a route to Loopback1. 388 PE Node 1 advertises Loopback1 to ABR Node 3 using BGP as follows: 390 * Prefix: Loopback1 392 * Next-hop: Loopback1 394 * Color Community: Color to distinguish between paths between ABR 395 Node 3 and PE Node 1 397 * SID: SID A (i.e., An END.DT46 SID instantiation on PE Node 1. 398 This instruction causes a packet to be forwarded using the main IP 399 forwarding table, not a VPN forwarding table.) 401 Now, ABR Node 3 resolves its route to Loopback1 through its IGP route 402 to Loopback1. Therefore, when forwarding traffic bound for 403 Loopback1, it imposes an SRv6 header that includes: 405 * SIDS associated with the IGP route to Loopback1 407 * SID A 409 ABR Node 3 advertises Loopback1 to PE Node 5 using BGP-LU as follows: 411 * Prefix: Loopback1 413 * Next-hop: Loopback3 415 * Color Community: Color to distinguish between paths between ABR 416 Node 3 and PE Node 5 418 * MPLS Label: A binding label that represents the SRv6 path between 419 ABR Node 3 and PE Node 5 421 Now, PE Node 5 resolves its route to Loopback1 through its IGP route 422 to Loopback3. Therefore, when forwarding traffic bound for 423 Loopback1, it imposes: 425 * An SR-MPLS label stack associated with the IGP route to ABR3 427 * An additional label representing a binding SID. The binding SID 428 maps to the SRv6 path between ABR Node 3 and PE Node 5 430 6. IANA Considerations 432 The authors will request an early allocation from the "SRv6 Endpoint 433 Behaviors" sub-registry of the "Segment Routing Parameters" registry. 435 7. Security Considerations 437 Because SR inter-working requires co-operation between inter-working 438 domains, this document introduces no security consideration beyond 439 those addressed in [RFC8402], [RFC8754] and [RFC8986]. 441 8. Acknowledgements 443 Thanks to Melchior Aelmans, Takuya Miyasaka and Jeff Tantsura for 444 their comments. 446 9. References 448 9.1. Normative References 450 [I-D.ietf-bess-srv6-services] 451 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 452 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 453 Overlay Services", Work in Progress, Internet-Draft, 454 draft-ietf-bess-srv6-services-08, 10 November 2021, 455 . 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 464 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 465 DOI 10.17487/RFC4271, January 2006, 466 . 468 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 469 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 470 2006, . 472 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 473 Reflection: An Alternative to Full Mesh Internal BGP 474 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 475 . 477 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 478 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 479 May 2017, . 481 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 482 (IPv6) Specification", STD 86, RFC 8200, 483 DOI 10.17487/RFC8200, July 2017, 484 . 486 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 487 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 488 . 490 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 491 Decraene, B., Litkowski, S., and R. Shakir, "Segment 492 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 493 July 2018, . 495 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 496 Decraene, B., Litkowski, S., and R. Shakir, "Segment 497 Routing with the MPLS Data Plane", RFC 8660, 498 DOI 10.17487/RFC8660, December 2019, 499 . 501 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 502 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 503 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 504 . 506 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 507 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 508 (SRv6) Network Programming", RFC 8986, 509 DOI 10.17487/RFC8986, February 2021, 510 . 512 9.2. Informative References 514 [I-D.hegde-spring-mpls-seamless-sr] 515 Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A., 516 Uttaro, J., Jalil, L., Khaddam, M., Alston, A., and L. M. 517 Contreras, "Seamless SR Problem Statement", Work in 518 Progress, Internet-Draft, draft-hegde-spring-mpls- 519 seamless-sr-06, 24 September 2021, 520 . 523 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 524 Label Switching Architecture", RFC 3031, 525 DOI 10.17487/RFC3031, January 2001, 526 . 528 Authors' Addresses 530 Shraddha Hegde 531 Juniper Networks 532 Embassy Business Park 533 Bangalore 560093 534 KA 535 India 537 Email: shraddha@juniper.net 539 Parag Kaneriya 540 Juniper Networks 541 Elnath-Exora Business Park Survey 542 Bangalore 560103 543 Karnataka 544 India 546 Email: pkaneria@juniper.net 547 Ron Bonica 548 Juniper Networks 549 Herndon, Virginia 20171 550 United States of America 552 Email: rbonica@juniper.net 554 Peng Shaofu 555 ZTE Corporation 557 Email: peng.shaofu@zte.com.cn 559 Greg Mirsky 560 ZTE Corporation 561 United States of America 563 Email: gregimirsky@gmail.com 565 Zheng Zhang 566 ZTE Corporation 568 Email: zhang.zheng@zte.com.cn 570 Bruno Decraene 571 Orange 572 France 574 Email: bruno.decraene@orange.com