idnits 2.17.1 draft-ietf-idr-bgpls-inter-as-topology-ext-03.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 (July 1, 2019) is 1761 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) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-12) exists of draft-ietf-teas-native-ip-scenarios-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track H. Chen 5 Expires: January 2, 2020 Futurewei 6 K. Talaulikar 7 Cisco Systems 8 S. Ma 9 Mellanox Technologies 10 July 1, 2019 12 BGP-LS Extension for Inter-AS Topology Retrieval 13 draft-ietf-idr-bgpls-inter-as-topology-ext-03 15 Abstract 17 This document describes the process to build BGP-LS key parameters in 18 inter-domain scenario, defines one new BGP-LS NLRI type(Stub Link 19 NLRI) and some new inter-AS TE related TLVs for BGP-LS to let SDN 20 controller retrieve the network topology automatically under various 21 inter-AS environments. 23 Such extension and process can enable the network operator to collect 24 the interconnect information between different domains and then 25 calculate the overall network topology automatically based on the 26 information provided by BGP-LS protocol. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 2, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Inter-AS Domain Scenarios. . . . . . . . . . . . . . . . . . 3 65 4. Stub Link NLRI . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Inter-AS Native IP Scenario . . . . . . . . . . . . . . . 5 67 4.2. Inter-AS TE Scenario . . . . . . . . . . . . . . . . . . 5 68 5. Inter-AS TE NLRI related TLVs . . . . . . . . . . . . . . . . 6 69 5.1. Remote AS Number TLV . . . . . . . . . . . . . . . . . . 6 70 5.2. IPv4 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7 71 5.3. IPv6 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7 72 6. Topology Reconstruction. . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. New BGP-LS NLRI type . . . . . . . . . . . . . . . . . . 9 76 8.2. New Link Descriptors . . . . . . . . . . . . . . . . . . 9 77 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 BGP-LS [RFC7752] describes the methodology that using BGP protocol to 86 transfer the Link-State information. Such method can enable SDN 87 controller to collect the underlay network topology automatically, 88 but normally it can only get the information within one IGP domain. 89 If the operator has more than one IGP domain, and these domains 90 interconnect with each other, there is no mechanic within current 91 BGP- LS to transfer the interconnect topology information. 93 Draft [I-D.ietf-idr-bgpls-segment-routing-epe] defines some 94 extensions for exporting BGP peering node topology information 95 (including its peers, interfaces and peering ASs) in a way that is 96 exploitable in order to compute efficient BGP Peering Engineering 97 policies and strategies. Such information can also be used to 98 calculate the interconnection topology among different IGP domains, 99 but it requires the border routers to run BGP-LS protocol and report 100 the information to the PCE/SDN controller, which restricts the 101 solution deployment flexibility. 103 This draft analysis the situations that the PCE/SDN controller needs 104 to get the interconnected topology information between different AS 105 domains, defines the new Stub Link NLRI and some new TLVs within the 106 BGP-LS protocol to transfer the key information related to them. 107 After that, the SDN controller can then deduce the multi-domain 108 topology automatically based on the information from BGP-LS protocol. 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119] . 116 3. Inter-AS Domain Scenarios. 118 Fig.1 illustrates the multi-domain scenarios that this draft 119 discusses. Normally, SDN Controller can get the topology of IGP A 120 and IGP B individually via the BGP-LS protocol, but it can't get the 121 topology connection information between these two IGP domains because 122 there is generally no IGP protocol run on the connected links. 124 +-----------------+ 125 +----+IP SDN Controller+----+ 126 | +-----------------+ | 127 | | 128 |BGP-LS |BGP-LS 129 | | 130 +---------------+-----+ +-----+--------------+ 131 | +--+ +-++ ++-+ +-++ +|-+ +--+| 132 | |S1+--------+S2+---+B1+-----------+B2+---+T1+--------+T2|| 133 | +-++ N1 +-++ ++-+ +-++ ++++ N2 +-++| 134 | | | | | || | | 135 | | | | | || | | 136 | +-++ +-++ ++-+ +-++ ++++ +-++| 137 | |S4+--------+S3+---+B3+-----------+B4+---+T3+--------+T4|| 138 | +--+ +--+ ++-+ +-++ ++-+ +--+| 139 | | | | 140 | | | | 141 | IGP A | | IGP B | 142 +---------------------+ +--------------------+ 144 Figure 1: Inter-AS Domain Scenarios 146 4. Stub Link NLRI 148 [RFC7752] defines four NLRI types(Node NLRI, Link NLRI, IPv4 Topology 149 Prefix NLRI, IPv6 Topology Prefix NLRI) to transfer the topology and 150 prefix information. For inter-as link, the two ends of the link 151 locates in different IGP domains, then it is not appropriate to 152 transfer their information within the current defined NLRI types. 154 This draft defines one new NLRI type, called Stub Link NLRI, which is 155 coded as the following format: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+ 160 | Protocol-ID | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Identifier | 163 | (64 bits) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 // Local Node Descriptors (variable) // 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 // Stub Link Descriptors (variable) // 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 2: Stub Link NLRI Format 172 The "Protocol-ID" should be set to the value that indicates "Direct" 173 protocol. 175 The semantics of "Stub Link Descriptors" is same as that defined in 176 [RFC7752] for "Link Descriptor". 178 This newly defined NLRI can be used to describe the link that has 179 only one end located within the IGP domain, as described in the 180 following sections. 182 4.1. Inter-AS Native IP Scenario 184 Draft [I-D.ietf-teas-native-ip-scenarios] describes the situation 185 that operator needs some traffic engineering solution for the inter- 186 as native IP environment. In such situation, different domain may 187 run different IGP protocol. The operator needs to know the inter-as 188 topology first to calculate the end to end optimal centrally. 190 When IGP A or IGP B in Figure 1 runs native IS-IS/OSPF protocol, the 191 operator can use passive feature for the inter-domain links to let 192 the routers within the IGP domain know these links. Such stub links 193 information can then be carried within the Stub Link NLRI reported 194 via the BGP-LS protocol to the SDN controller. 196 The "Local Node Descriptors" should describe the the characteristics 197 of ASBRs that are connected these stub links. 199 When such information is reported via the BGP-LS protocol, the PCE/ 200 SDN controller can construct the underlay inter-domain topology 201 according to procedure described in section 6. 203 4.2. Inter-AS TE Scenario 205 When IGP A or IGP B in Figure 1 runs IS-IS TE/OSPF-TE 206 protocol,[RFC5316] and [RFC5392] define IS-IS and OSPF extensions 207 respectively to deal with the situation for inter-AS traffic 208 engineering. Three new sub-TLVs(Remote AS Number、IPv4 Remote 209 ASBR ID、IPv6 Remote ASBR ID) which are associated with the 210 inter-AS TE link are defined. 212 These TLVs are flooded within the IGP domain automatically. They can 213 also be carried within the newly defined Stub Link NLRI within the 214 BGP-LS protocol, as the descriptors for the inter-AS stub link. 216 The "Local Node Descriptors" should describe the the characteristics 217 of ASBRs that are connected these inter-AS TE links. 219 If the PCE/SDN controller know these information via one of the 220 interior router that runs BGP-LS protocol, the PCE/SDN controller can 221 rebuild the inter-AS TE topology correctly according to the procedure 222 described in section 6 224 5. Inter-AS TE NLRI related TLVs 226 This draft proposes to add three new TLVs that is included within the 227 Stub Link NLRI to transfer the information via BGP-LS, which are 228 required to build the inter-AS TE related topology by the PCE/SDN 229 controller. 231 The following Link Descriptor TLVs are added into the BGP-LS protocol 232 : 234 +-----------+---------------------+--------------+----------------+ 235 | TLV Code | Description |IS-IS/OSPF TLV| Reference | 236 | Point | | /Sub-TLV | (RFC/Section) | 237 +-----------+---------------------+--------------+----------------+ 238 | TBD |Remote AS Number | 24/21 | [RFC5316]/3.3.1| 239 | | | | [RFC5392]/3.3.1| 240 | TBD |IPv4 Remote ASBR ID | 25/22 | [RFC5316]/3.3.2| 241 | | | | [RFC5392]/3.3.2| 242 | TBD |IPv6 Remote ASBR ID | 26/24 | [RFC5316]/3.3.3| 243 | | | | [RFC5392]/3.3.3| 244 +-----------+---------------------+--------------+----------------+ 245 Figure 3: Link Descriptor TLVs 247 Detail encoding of these TLVs are synchronized with the corresponding 248 parts in [RFC5316] and [RFC5392], which keeps the BGP-LS protocol is 249 agnostic to the underly protocol. 251 5.1. Remote AS Number TLV 253 A new TLV, the remote AS number TLV, is defined for inclusion in the 254 link descriptor when advertising inter-AS TE links. The remote AS 255 number TLV specifies the AS number of the neighboring AS to which the 256 advertised link connects. 258 The remote AS number TLV is TLV type TBD (see Section 8) and is 4 259 octets in length. The format is as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Remote AS Number | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 4: Remote AS Number TLV Format 270 The Remote AS number field has 4 octets. When only 2 octets are used 271 for the AS number, as in current deployments, the left (high-order) 2 272 octets MUST be set to 0. The remote AS number TLV MUST be included 273 when a router advertises an inter-AS TE link. 275 5.2. IPv4 Remote ASBR ID 277 A new TLV, which is referred to as the IPv4 remote ASBR ID TLV, is 278 defined for inclusion in the link descriptor when advertising inter- 279 AS TE links. The IPv4 remote ASBR ID TLV specifies the IPv4 280 identifier of the remote ASBR to which the advertised inter-AS link 281 connects. This could be any stable and routable IPv4 address of the 282 remote ASBR. Use of the TE Router ID as specified in the Traffic 283 Engineering router ID TLV [RFC5305] is RECOMMENDED. 285 The IPv4 remote ASBR ID TLV is TLV type TBD (see Section 8) and is 4 286 octets in length. The format of the IPv4 remote ASBR ID sub-TLV is 287 as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Remote ASBR ID | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 5: IPv4 Remote ASBR ID TLV Format 298 The IPv4 remote ASBR ID TLV MUST be included if the neighboring ASBR 299 has an IPv4 address. If the neighboring ASBR does not have an IPv4 300 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID TLV 301 MUST be included instead. An IPv4 remote ASBR ID TLV and IPv6 remote 302 ASBR ID TLV MAY both be present in an inter-AS TE link NLRI. 304 5.3. IPv6 Remote ASBR ID 306 A new TLV, which is referred to as the IPv6 remote ASBR ID TLV, is 307 defined for inclusion in the link descriptor when advertising inter- 308 AS links. The IPv6 remote ASBR ID TLV specifies the IPv6 identifier 309 of the remote ASBR to which the advertised inter-AS link connects. 310 This could be any stable and routable IPv6 address of the remote 311 ASBR. Use of the TE Router ID as specified in the IPv6 Traffic 312 Engineering router ID TLV [RFC6119] is RECOMMENDED. 314 The IPv6 remote ASBR ID TLV is TLV type TBD (see Section 8) and is 16 315 octets in length. The format of the IPv6 remote ASBR ID TLV is as 316 follows: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Remote ASBR ID | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Remote ASBR ID (continued) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Remote ASBR ID (continued) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Remote ASBR ID (continued) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 6: IPv6 Remote ASBR ID TLV Format 333 The IPv6 remote ASBR ID TLV MUST be included if the neighboring ASBR 334 has an IPv6 address. If the neighboring ASBR does not have an IPv6 335 address, the IPv4 remote ASBR ID TLV MUST be included instead. An 336 IPv4 remote ASBR ID TLV and IPv6 remote ASBR ID TLV MAY both be 337 present in an inter-AS TE link NLRI. 339 6. Topology Reconstruction. 341 When SDN Controller gets such information from BGP-LS protocol, it 342 should compares the proximity of these stub links. If they are under 343 the same network scope, then it should find the corresponding 344 associated router information, build the link between these two 345 border routers. 347 After iterating the above procedures for all of the stub links, the 348 SDN controller can then retrieve the connection topology between 349 different domains automatically. 351 7. Security Considerations 353 It is common for one operator to occupy several IGP domains that are 354 composited by its backbone network and several MAN(Metrio-Area- 355 Network)s/IDCs. When they do traffic engineering which spans MAN, 356 Backbone and IDC, they need to know the inter-as topology via the 357 process described in this draft. Using the passive interface 358 features or configuring the TE parameters on the interconnect links 359 will not spread the topology fluctuation across each other domain. 361 8. IANA Considerations 363 This document defines: 365 o A new BGP NLRI Type: Stub Link NLRI. The codepoint is from the 366 "BGP-LS NLRI Types" 368 o Three new Link Descriptors TLV: Remote AS Number TLV, IPv4 Remote 369 ASBR ID, IPv6 Remote ASBR ID. The codepoint are from "BGP-LS Node 370 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 371 TLVs" registry. 373 8.1. New BGP-LS NLRI type 375 This document defines a new value in the registry "BGP-LS NLRI 376 Types": 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Code Point | Description | Status | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | TBD | Stub Link NLRI | Allocation from IANA | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 7: Stub Link NLRI Codepoint 385 8.2. New Link Descriptors 387 This document defines three new values in the registry "BGP-LS Node 388 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Code Point | Description | Status | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | TBD | Remote AS Number | Allocation from IANA | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | TBD |IPv4 Remote ASBR ID| Allocation from IANA | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | TBD |IPv6 Remote ASBR ID| Allocation from IANA | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 8: BGP-LS Link Descriptors TLV 401 9. Acknowledgement 403 The author would like to thank Acee Lindem, Jie Dong, Jeff Tantsura 404 and Dhruv Dhody for their valuable comments and suggestions. 406 10. References 408 10.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 416 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 417 2008, . 419 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 420 Support of Inter-Autonomous System (AS) MPLS and GMPLS 421 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 422 December 2008, . 424 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 425 Support of Inter-Autonomous System (AS) MPLS and GMPLS 426 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 427 January 2009, . 429 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 430 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 431 February 2011, . 433 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 434 S. Ray, "North-Bound Distribution of Link-State and 435 Traffic Engineering (TE) Information Using BGP", RFC 7752, 436 DOI 10.17487/RFC7752, March 2016, 437 . 439 10.2. Informative References 441 [I-D.ietf-idr-bgpls-segment-routing-epe] 442 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 443 S., and J. Dong, "BGP-LS extensions for Segment Routing 444 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 445 segment-routing-epe-19 (work in progress), May 2019. 447 [I-D.ietf-teas-native-ip-scenarios] 448 Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, 449 "Scenarios and Simulation Results of PCE in Native IP 450 Network", draft-ietf-teas-native-ip-scenarios-06 (work in 451 progress), June 2019. 453 Authors' Addresses 455 Aijun Wang 456 China Telecom 457 Beiqijia Town, Changping District 458 Beijing, Beijing 102209 459 China 461 Email: wangaj.bri@chinatelecom.cn 463 Huaimo Chen 464 Futurewei 465 Boston, MA 466 USA 468 Email: hchen@futurewei.com 470 Ketan Talaulikar 471 Cisco Systems 473 Email: ketant@cisco.com 475 Shaowen Ma 476 Mellanox Technologies 478 Email: mashaowen@gmail.com