idnits 2.17.1 draft-mirsky-6man-unified-id-sr-04.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 (November 3, 2019) is 1633 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) -- Looks like a reference, but probably isn't: '0' on line 197 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network C. Weiqiang 3 Internet-Draft China Mobile 4 Intended status: Standards Track G. Mirsky 5 Expires: May 6, 2020 ZTE Corp. 6 P. Shaofu 7 L. Aihua 8 ZTE Corporation 9 W. Xiaolan 10 New H3C Technologies Co. Ltd 11 C. Wei 12 Centec 13 S. Zadok 14 Broadcom 15 November 3, 2019 17 Unified Identifier in IPv6 Segment Routing Networks 18 draft-mirsky-6man-unified-id-sr-04 20 Abstract 22 Segment Routing architecture leverages the paradigm of source 23 routing. It can be realized in a network data plane by prepending 24 the packet with a list of instructions, a.k.a. segments. A segment 25 can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4 26 address, or IPv6 address. Segment Routing can be applied in MPLS 27 data plane by encoding segments in MPLS label stack. It also can be 28 applied to IPv6 data plane by encoding a list of segment identifiers 29 in IPv6 Segment Routing Extension Header (SRH). This document 30 extends the use of the SRH to unified identifiers encoded as MPLS 31 label or IPv4 address, to compress the SRH, and support support more 32 detailed network programming and interworking between SR-MPLS and 33 SRv6 domains. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 6, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Conventions used in this document . . . . . . . . . . . . 3 70 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 71 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 72 2. Segment Routing Extension Header: Benefits and Challenges . . 4 73 3. Unified SIDs in IPv6 Segment Routing Extension Header . . . . 4 74 4. The Use Case of Unified Segment Identifier . . . . . . . . . 6 75 4.1. Interworking Between SR-MPLS and SRv6 Using U-SID . . . . 6 76 5. Operations with Unified Segment Identifier . . . . . . . . . 7 77 5.1. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . 8 78 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 Segment Routing architecture [RFC8402] leverages the paradigm of 88 source routing. It can be realized in a network data plane by 89 prepending the packet with a list of instructions, a.k.a. segment 90 identifiers (SIDs). A segment can be encoded as a Multi-Protocol 91 Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment 92 Routing can be applied in MPLS data plane by encoding 20-bits SIDs in 93 MPLS label stack [I-D.ietf-spring-segment-routing-mpls]. It also can 94 be applied to IPv6 data plane by encoding a list of 128-bits SIDs in 95 IPv6 Segment Routing Extension Header (SRH) 97 [I-D.ietf-6man-segment-routing-header]. Applicability of 32-bits SID 98 that may represent an IPv4 address has not been defined. 100 SR extensions to Interior Gateway Protocols (IGP), IS-IS 101 [I-D.ietf-isis-segment-routing-extensions], OSPF 102 [I-D.ietf-ospf-segment-routing-extensions], and OSPFv3 103 [I-D.ietf-ospf-ospfv3-segment-routing-extensions], defined how 104 20-bits and 32-bits SIDs advertised and bound to SR objects and/or 105 instructions. Extensions to BGP link-state address family 106 [I-D.ietf-idr-bgp-ls-segment-routing-ext] enabled propagation of 107 segment information of variable length via BGP. 109 This document extends the use of the SRH 110 [I-D.ietf-6man-segment-routing-header] to unified identifiers encoded 111 as MPLS label or IPv4 address to support more detailed network 112 programming and interworking between SR-MPLS and SRv6 domains. 114 1.1. Conventions used in this document 116 1.1.1. Terminology 118 SR: Segment Routing 120 SRH: Segment Routing Extension Header 122 MPLS: Multiprotocol Label Switching 124 SR-MPLS: Segment Routing using MPLS data plane 126 SID: Segment Identifier 128 IGP: Interior Gateway Protocol 130 DA: Destination Address 132 ILM: Incoming Label Map 134 FEC: Forwarding Equivalence Class 136 FTN: FEC-to-NHLFE map 138 OAM: Operation, Administration and Maintenance 140 TE: Traffic Engineering 142 SRv6: Segment Routing in IPv6 144 U-SID: Unified Segment Identifier 145 PSP: Penultimate Segment Popping 147 FIB: Forwarding Information Base 149 1.1.2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 2. Segment Routing Extension Header: Benefits and Challenges 159 Many functions related to Operation, Administration and Maintenance 160 (OAM) require identification of the SR tunnel ingress and the path, 161 constructed by segments, between the ingress and the egress SR nodes. 162 Combination of IPv6 encapsulation [RFC8200] and SRH 163 [I-D.ietf-6man-segment-routing-header], referred to as SRv6, comply 164 with these requirements while it is challenging when applying SR in 165 MPLS networks, also referred to as SR-MPLS. 167 On the other hand, the size of IPv6 SID presents a scaling challenge 168 to use topological instructions that define strict explicit traffic 169 engineered (TE) path or support network programming in combination 170 with service-based instructions. At the same time, that is where SR- 171 MPLS approach provides better results due to smaller SID length. It 172 can be used to compress the SRv6 header size when a smaller namespace 173 of available SIDs is sufficient for addressing the particular 174 network. 176 SR-MPLS is broadly used in metro networks. With the gradual 177 deployment of SRv6 in the core networks, supporting interworking 178 between SR-MPLS and SRv6 becomes the necessity for operators. It is 179 operationally more efficient and straightforward if SRv6 can use the 180 same size SIDs as in SR-MPLS. The SRH can be extended to define the 181 same as in SR-MPLS SID length to support the unified segment 182 identifier (U-SID). As a result, end-to-end SR tunnel may use U-SIDs 183 across SR-MPLS and SRv6 domains. 185 3. Unified SIDs in IPv6 Segment Routing Extension Header 187 SRH format has been defined in Section 3 of 188 [I-D.ietf-6man-segment-routing-header] as presented in Figure 1 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Last Entry | Flags | Tag | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 | Segment List[0] (128 bits IPv6 address) | 198 | | 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 | | 203 ... 204 | | 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 | Segment List[n] (128 bits IPv6 address) | 209 | | 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 // // 213 // Optional Type Length Value objects (variable) // 214 // // 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 1: SRH format 219 This document defines a new field Size in the SRH Flags field as a 220 two-bits field with the following values: 222 0b00 - 128-bits SID, an IPv6 address; 224 0b01 - 32-bits SID, an IPv4 address; 226 0b10 - 32-bits SID, an MPLS label in leftmost 20-bits, rightmost 227 12-bits for context information used by the label forwarding 228 entry. The context information could be U-SID function code. 230 0b11 - reserved for future use. 232 Entries of the segment list in the SRH MUST be of the same length. 234 4. The Use Case of Unified Segment Identifier 236 U-SID can be used for interworking between SR-MPLS and SRv6 domains. 237 SR-MPLS is often used in a metro network, for example, in the 238 backhaul metro network of CMCC. If the core network uses SRv6, for 239 example, the core network of the same operator, U-SID can be used in 240 the SRv6 domain to interwork with SR-MPLS in the metro network to 241 form an end-to-end tunnel. 243 4.1. Interworking Between SR-MPLS and SRv6 Using U-SID 245 SR-MPLS uses SR SIDs as MPLS label in MPLS stack, and the SIDs are 246 32-bits long. SRv6 uses SR SIDs as IPv6 extension header in SRH, and 247 the SIDs are 128-bits long. 249 The U-SID uses the same 32-bits long SIDs in MPLS stack and SRH. 250 Thus, four 32-bits long U-SIDs can be placed in the space of a single 251 128-bits long header. The encapsulation is illustrated in Figure 2. 253 +---------+ +----------------------------------+ 254 | | | IPv6 header | 255 | Ethernet| +----------------------------------+ 256 | | | SRH | 257 +---------+ +----------------------------------+ 258 | USID1 | | USID1 | USID2 | ... | USID4 | 259 +---------+ +----------------------------------+ 260 | USID2 | | USID5 |... | USIDn | Null | 261 +---------+ +----------------------------------+ 262 | ... | + Payload | 263 +---------+ +----------------------------------+ 264 | USIDn | 265 +---------+ 266 | Payload | 267 +---------+ 269 Figure 2: 32-bits long U-SIDs Encapsulation 271 The SR-MPLS and SRv6 interworking is illustrated in Figure 3. An 272 end-to-end SR tunnel from A to F crosses the SR-MPLS and SRv6 273 domains. The SR-MPLS domain could be using IPv4 or IPv6 address 274 family. The SRv6 border nodes (E/G) receive SR-MPLS packets and 275 forward them into the SRv6 domain using an SR-MPLS Binding SID 276 [I-D.ietf-spring-segment-routing-mpls]. 278 +-----+ +-----+ +-----+ +-----+ 279 | A +-----------+ B +-----------+ E +-----------+ F | 280 +-----+ +--+--+ +--+--+ +--+--+ 281 | SR-MPLS | | SRv6 | 282 | | | | 283 +-----+ +--+--+ +--+--+ +--+--+ 284 | C |-----------| D +-----------+ G +-----------+ H | 285 +-----+ +-----+ +-----+ +-----+ 287 +--------------+ 288 | Eth(E->G) | 289 +--------------+ +--------------+ 290 | Eth(A->B) | |IPv6 DA:G.intf| 291 +--------------+ +--------------+ +--------------+ 292 | USID(B) | | Eth(B->E) | |SRH | 293 +--------------+ +--------------+ |NH:MPLS SL:2| 294 | USID(E1) | | USID(E1) | |USID(ADJ E->G)| 295 +--------------+ +--------------+ |USID(ADJ G->H)| 296 | USID(E2) | | USID(E2) | |USID(ADJ H->F)| 297 +--------------+ +--------------+ +--------------+ 298 | USID(F) | | USID(F) | | USID(F) | 299 +--------------+ +--------------+ +--------------+ 300 |Label(service)| |Label(service)| |Label(service)| 301 +--------------+ +--------------+ +--------------+ 302 | Payload | -> | Payload | -> | Payload | 303 +--------------+ +--------------+ +--------------+ 305 Figure 3: SR-MPLS and SRv6 interworking 307 The SRv6 edge node E assigns two SIDs, e.g., E1 and E2, E1 is an SR- 308 MPLS Node-SID, E2 is an SR-MPLS Binding-SID, which represents an SRv6 309 policy (from E to F, via segment list E-G-H-F) with U-SID 310 encapsulation. Figure 4 demonstrates an example of the packet 311 forwarding, where U-SID is an MPLS label. 313 The controller may assign the end-to-end SR tunnel U-SIDs (from A to 314 F), and another method is outside the scope of this document. 316 5. Operations with Unified Segment Identifier 318 When SRH is used to include 32-bits long U-SIDs, the ingress and 319 transit nodes of an SR tunnel act as described in Section 5.1 and 320 Section 5.2 of [I-D.ietf-6man-segment-routing-header] respectively. 322 If U-SID is used to support interworking between SR-MPLS and SRv6 323 domains, it is beneficila that U-SID type matches to an MPLS label. 324 In that case, an ILM (Incoming Label Map) entry can be used to map a 325 U-SID to an IPv6 address. As result, it is not necessary to 326 introduce a new type of index-based mapping table. For ILM entry of 327 Adjacency-SID, the mapping result copied to DA (Destination Address) 328 is the remote interface IPv6 address, for ILM entry of Node-SID, the 329 mapping result copied to DA is remote node loopback IPv6 address. 331 Operations oon an MPLS label of U-SID type are the same as those 332 defined in [I-D.ietf-mpls-sr-over-ip]. However, SR-MPLS over SRH has 333 the following advantages compared with SR-MPLS over UDP: 335 o SRH is flexible to extend flags or sub-TLVs for service 336 requirements, but UDP not. 338 o Labels in SRH can meet 8 bytes alignment requirements as per 339 [RFC8200], but UDP not. 341 o The source address of the SR policy is not discarded, but UDP not. 343 5.1. Procedures of SR-MPLS over IP 345 Procedures of SR-MPLS over IP of [I-D.ietf-mpls-sr-over-ip] described 346 how to construct an adjusted SR-MPLS FTN (FEC-to-NHLFE map) and ILM 347 entry towards a prefix-SID when next-hops are IP-only routers, the 348 action of FTN and ILM entry will steer the packet along an outer 349 tunnel to the target node that originated the FEC (Forwarding 350 Equivalence Class), and on each airway node along the segment list, 351 UDP header is frequently removed and put again. However, for SR-MPLS 352 over SRH in this document we don't try to depend on that adjusted FIB 353 (Forwarding Information Base) entry, because there are not any 354 actions needed to get from the FIB entry, a traditional ILM entry 355 (maybe without out-label because of IP-only next-hop) is enough to 356 get the FEC information, i.e., to map a U-SID to an IPv6 address and 357 copy to DA. An SRv6 policy chosen to encapsulate U-SID list within 358 SRH is determined at the ingress node of this SRv6 policy, SRH is 359 preserved along the SR to egress, though PSP (Penutimate Segment 360 Popping) may be used, that is different from SR-MPLS over IP/UDP 361 method [I-D.ietf-mpls-sr-over-ip], so the source address (i.e., the 362 ingress of the SRv6 policy) is not discarded. 364 5.2. Packet Forwarding 366 U-SID based packet forwarding is similar to the processing described 367 in [I-D.ietf-mpls-sr-over-ip]. But it differs from that in FIB 368 action and segment list processing. For completeness, we repeat the 369 description of [I-D.ietf-mpls-sr-over-ip] with modification as 370 follows. 372 +-----+ +-----+ +-----+ +-----+ +-----+ 373 | A +-------+ B +-------+ C +--------+ D +--------+ H | 374 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 375 | | | 376 | | | 377 +--+--+ +--+--+ +--+--+ 378 | E +-------+ F +--------+ G | 379 +-----+ +-----+ +-----+ 381 +--------+ +--------+ +--------+ 382 |IP(A->E)| |IP(A->G)| |IP(A->G)| 383 +--------+ +--------+ +--------+ 384 |SRH | |SRH | |SRH |(or PSP) 385 | SL:2 | | SL:1 | | SL:0 | 386 | L(E) | | L(E) | | L(E) | 387 | L(G) | | L(G) | | L(G) | 388 | L(H) | | L(H) | | L(H) | 389 +--------+ +--------+ +--------+ 390 | Packet | ---> | Packet | ---> | Packet | 391 +--------+ +--------+ +--------+ 393 Figure 4: Packet Forwarding Example 395 In the example shown in Figure 4, assume that routers A, E, G, and H 396 are U-SID capable (i.e, both SR-MPLS and SRv6 capable ) while the 397 remaining routers (B, C, D, and F) are only capable of forwarding IP 398 packets. Routers A, E, G, and H advertise their Segment Routing 399 related information via IS-IS or OSPF. 401 Now assume that router A (the Domain ingress) wants to send a packet 402 to router H (the Domain egress) via an SRv6 policy with the explicit 403 path {E->G->H}. Router A will impose an MPLS label stack within SRH 404 on the packet that corresponds to that explicit path. Router A 405 searches ILM entry by the top label (that indicated router E), get 406 the FEC information, a loopback IPv6 address of E, and then copy to 407 DA and sends the packet. The value of SRH.SL is 2. 409 When the IPv6 packet arrives at router E, router E get the next 410 segment (label) within SRH according to SL 2, searches ILM entry by 411 the next label, get the FEC information, a loopback IPv6 address of 412 G, and then copy to DA and sends the packet. The value of SRH.SL is 413 1. 415 When the IPv6 packet arrives at router G, router G gets the next 416 segment (label) within SRH according to SRH.SL 1, looks up ILM entry 417 by the next label, gets the FEC information, a loopback IPv6 address 418 of H, and then copies it to IP DA and transmits the packet. Because 419 the value of SRH.SL is 0, the SRH can be removed if the Prefix-SID of 420 H is set to PSP. 422 6. IANA Considerations 424 IANA is requested to allocate from the Segment Routing Header Flags 425 registry the two-bits long field referred to as Size. 427 7. Security Considerations 429 This specification inherits all security considerations of [RFC8402] 430 and [I-D.ietf-6man-segment-routing-header]. 432 8. Acknowledgements 434 TBD 436 9. Normative References 438 [I-D.ietf-6man-segment-routing-header] 439 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 440 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 441 Routing Header (SRH)", draft-ietf-6man-segment-routing- 442 header-26 (work in progress), October 2019. 444 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 445 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 446 and M. Chen, "BGP Link-State extensions for Segment 447 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 448 (work in progress), June 2019. 450 [I-D.ietf-isis-segment-routing-extensions] 451 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 452 Gredler, H., and B. Decraene, "IS-IS Extensions for 453 Segment Routing", draft-ietf-isis-segment-routing- 454 extensions-25 (work in progress), May 2019. 456 [I-D.ietf-mpls-sr-over-ip] 457 Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 458 W., and Z. Li, "SR-MPLS over IP", draft-ietf-mpls-sr-over- 459 ip-07 (work in progress), June 2019. 461 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 462 Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment 463 Routing", draft-ietf-ospf-ospfv3-segment-routing- 464 extensions-23 (work in progress), January 2019. 466 [I-D.ietf-ospf-segment-routing-extensions] 467 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 468 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 469 Extensions for Segment Routing", draft-ietf-ospf-segment- 470 routing-extensions-27 (work in progress), December 2018. 472 [I-D.ietf-spring-segment-routing-mpls] 473 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 474 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 475 data plane", draft-ietf-spring-segment-routing-mpls-22 476 (work in progress), May 2019. 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 485 May 2017, . 487 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 488 (IPv6) Specification", STD 86, RFC 8200, 489 DOI 10.17487/RFC8200, July 2017, 490 . 492 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 493 Decraene, B., Litkowski, S., and R. Shakir, "Segment 494 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 495 July 2018, . 497 Authors' Addresses 499 Cheng Weiqiang 500 China Mobile 501 Beijing 502 China 504 Email: chengweiqiang@chinamobile.com 506 Greg Mirsky 507 ZTE Corp. 509 Email: gregimirsky@gmail.com 510 Peng Shaofu 511 ZTE Corporation 512 No.50 Software Avenue, Yuhuatai District 513 Nanjing 514 China 516 Email: peng.shaofu@zte.com.cn 518 Liu Aihua 519 ZTE Corporation 520 Zhongxing Industrial Park, Nanshan District 521 Shenzhen 522 China 524 Email: liu.aihua@zte.com.cn 526 Wan Xiaolan 527 New H3C Technologies Co. Ltd 528 No.8, Yongjia Road, Haidian District 529 Beijing 530 China 532 Email: wxlan@h3c.com 534 Cheng Wei 535 Centec 536 Building B, No.5 Xing Han Street, Suzhou Industrial Park 537 Suzhou 538 China 540 Email: Chengw@centecnetworks.com 542 Shay 543 Broadcom 544 Israel 546 Email: shay.zadok@broadcom.com