idnits 2.17.1 draft-hao-trill-anycast-gw-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 265: '... [RFC6326] to TRILL network and MUST ignore the nickname collision...' RFC 2119 keyword, line 438: '... MUST ignore the nickname collision ...' RFC 2119 keyword, line 457: '...anycast gateways MUST use the nickname...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 279 has weird spacing: '...e nodes i.e. ...' == Line 281 has weird spacing: '...ickname and c...' == Line 282 has weird spacing: '...ickname throu...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2014) is 3723 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: 'FGL' on line 117 -- Looks like a reference, but probably isn't: 'RFC6325' on line 209 -- Looks like a reference, but probably isn't: 'RFC6326' on line 437 == Unused Reference: '1' is defined on line 473, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 476, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 479, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 485, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3768 (ref. '4') (Obsoleted by RFC 5798) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Weiguo Hao 2 Yizhou Li 3 Donald Eastlake 4 Internet Draft Huawei 5 Radia Perlman 6 Intel Labs 7 Intended status: Standards Track February 14, 2014 8 Expires: August 2014 10 TRILL anycast Layer 3 Gateway 11 draft-hao-trill-anycast-gw-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, except to publish it 26 as an RFC and to translate it into languages other than English. 28 This document may contain material from IETF Documents or IETF 29 Contributions published or made publicly available before November 30 10, 2008. The person(s) controlling the copyright in some of this 31 material may not have granted the IETF Trust the right to allow 32 modifications of such material outside the IETF Standards Process. 33 Without obtaining an adequate license from the person(s) controlling 34 the copyright in such materials, this document may not be modified 35 outside the IETF Standards Process, and derivative works of it may 36 not be created outside the IETF Standards Process, except to format 37 it for publication as an RFC or to translate it into languages other 38 than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on August 14, 2014. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. Code Components extracted from this 69 document must include Simplified BSD License text as described in 70 Section 4.e of the Trust Legal Provisions and are provided without 71 warranty as described in the Simplified BSD License. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with 78 respect to this document. 80 Abstract 82 This draft mainly describes centralized anycast layer 3 gateway 83 solution in TRILL campus. Comparing to traditional VRRP based 84 active-standby layer 3 gateway solution, this solution can achieve 85 better load balancing and scalability. Anycast nickname, anycast 86 gateway IP and MAC are introduced. It can ensure inter-subnet 87 traffic forwarding in flow-based load balancing mode among all 88 physical layer 3 gateways. To avoid sending duplicated ARP reply 89 message to the end system, ARP master gateway election mechanism is 90 introduced. The election algorithm is described in this draft. 92 Table of Contents 94 1. Introduction ................................................ 3 95 2. Conventions used in this document............................ 5 96 3. VRRP based gateways ......................................... 5 97 4. Anycast layer 3 gateway...................................... 6 98 4.1. ARP Handling ........................................... 7 99 4.2. Data traffic forwarding................................. 9 100 5. Node failure ................................................ 9 101 6. Anycast MAC aging on edge node.............................. 10 102 7. TRILL protocol extension.................................... 10 103 7.1. The Anycast Gateway TLV................................ 10 104 8. Security Considerations..................................... 11 105 9. IANA Considerations ........................................ 11 106 10. Normative References....................................... 11 107 11. Informative References..................................... 11 108 12. Acknowledgments ........................................... 11 110 1. Introduction 112 In a TRILL based multi-tenancy data center network (DCN), each 113 tenant normally owns one routing domain (RD) which may consist of 114 one or more IP subnets. It is a common practice that one layer 2 115 virtual network (VN) maps to a unique IP subnet. Layer 2 virtual 116 network in a TRILL campus is identified by a 12-bit VLAN ID or 24- 117 bit Fine Grained Label [FGL]. 119 All the inter-subnet communication or inter VN communication need to 120 pass through an L3 GW. Different subnets in one tenant are usually 121 allowed to communicate with each other freely. Gateway plays an 122 important role in both such west-to-east traffic and traditional 123 north-to-south traffic. 125 Figure 1 shows a typical data center network topology. Multiple core 126 switches serve as the layer 3 gateways. All the network nodes are 127 RBridges running TRILL protocol. Gateway functions co-exist with 128 traditional RBridge functions at the GW switch. There are several 129 ways to organize the gateways. A traditional way is to use VRRP 130 based gateways which is explained in section 3. However it has the 131 issue of scalability and efficiency. In order to avoid single point 132 of failure and achieve better load balancing, anycast gateway group 133 can be used.The key idea of anycast gateway is to make multiple 134 physical gateways share the same gateway IP and MAC address for 135 single virtual network(VN). 137 ,---------. 138 ,' `. 139 ( IP/MPLS WAN ) 140 `. ,' 141 * -+------+' * 142 * * 143 * * 144 --------- --------- 145 | GW1 | | GW2 | 146 | | ************ | | 147 --------- --------- 148 * * 149 * * 150 * TRILL Campus * 151 * * 152 * * 153 --------- --------- --------- --------- 154 | TOR1 | ******** | TOR2 | ******** | TOR3 | ******** | TOR4 | 155 | | | | | | | | 156 --------- --------- --------- --------- 157 | | | | | | | | 158 ____ ____ ____ ____ ____ ____ ____ ____ 159 |T | |T | |T | |T | |T | |T | |T | |T | 160 |S1| |S2| |S3| |S4| |S5| |S6| |S7| |S8| 161 ---- ---- ---- ---- ---- ---- ---- ---- 162 Figure 1 Centralized layer 3 gateway in TRILL campus 164 For inter-subnet layer 3 traffic, centralized layer 3 gateway is 165 normally used and put at the boundary of TRILL network and the 166 external IP network. In figure 1 above, GW1 and GW2 are integrated 167 devices of layer 3 gateway and TRILL RB function. TRILL protocol 168 runs on TOR and GW devices. West-to-east IP traffic among different 169 VNs and north-to-south IP traffic between TRILL network and external 170 IP network both pass through the layer 3 gateway. When the gateway 171 receives the unicast TRILL encapsulated traffic from one layer 2 VN, 172 it removes the TRILL encapsulation header. If destination MAC in 173 inner Ethernet header is gateway's MAC, the gateway removes inner 174 Ethernet header. Then the gateway looks up local IP forwarding table. 175 If destination IP belongs to another VN in TRILL campus, the gateway 176 will encapsulate the frame in TRILL format and send to the 177 destination. 179 To eliminate the single point of gateway failure and to enhance the 180 reliability, multiple layer 3 gateways are deployed. These gateways 181 can work in active-standby mode or active-active mode. In active- 182 standby mode, for each VN only one gateway acts as master and is 183 responsible for IP traffic forwarding between VNs. Network bandwidth 184 usage is inefficient with such deployment. In a cloud computing data 185 center, it is estimated that about 70% of traffic is east-west 186 traffic which requires a non-blocking forwarding for line-speed 187 traffic transmission between servers. 189 For inter-subnet layer 3 traffic, multiple centralized layer 3 190 gateways working in flow-based active-active mode will enhance the 191 network efficiency. In this draft, such anycast layer 3 gateway 192 solution for TRILL campus is illustrated. Anycast nickname, anycast 193 gateway IP and MAC address are introduced. Anycast gateway IP and 194 MAC address are set on each layer 3 gateway for each VN to terminate 195 Ethernet traffic. Anycast nickname also is shared by multiple 196 gateways, the TRILL traffic with anycast nickname as egress nickname 197 could go to any one of the gateways by the natural support of ECMP 198 from TRILL protocol, so flow-based load balancing among physical 199 gateways will be achieved. Comparing to traditional VRRP based 200 active-standby layer 3 gateway, anycast gateway can achieve better 201 load balancing and scalability. 203 This document is organized as follows: Section 3 describes VRRP 204 based gateway solution and its disadvantage. Section 4 gives anycast 205 gateway solution overview. Section 5 describes ARP handling process. 206 Section 6 describes data traffic forwarding. Section 7 describes 207 TRILL protocol extension. 209 Familiarity with [RFC6325] is assumed in this document. 211 2. Conventions used in this document 213 ARP - Address Resolution Protocol. 215 ES - End Station. 217 VN - Virtual Network. In TRILL network, each VN can be identified by 218 a 12 bit VLAN ID or a 24 bit Fine Grained Label. 220 3. VRRP based gateways 222 Assuming in figure 1 above, COR1 and COR2 are centralized gateway in 223 active-standby mode. TRILL protocol runs on TOR and GW device. ES is 224 end station. ES1,ES3,ES5 and ES7 belong to VLAN1. ES2,ES4,ES6 and 225 ES8 belong to VLAN2. 227 The Virtual Router Redundancy Protocol (VRRP) is designed to 228 eliminate the single point of gateway failure. VRRP is an election 229 protocol that dynamically assigns responsibility for a virtual 230 router to one of the VRRP routers on a layer 2 VN. Any of the 231 virtual router's IP addresses on a LAN can then be used as the 232 default first hop router by end-hosts. The layer 3 gateway of VRRP 233 master is responsible for forwarding packets destined to the virtual 234 router. If VRRP master fails, VRRP backup will take over. 236 VRRP based solution has the following issues: 238 1. Inefficient network bandwidth usage. Only the VRRP master gateway 239 forwards the traffic. VRRP slave is idle most of the time. 241 2. Low scalability. VRRP session among physical layer 3 gateways 242 should be established per layer 2 VN. Large number of layer 2 VN 243 will cause heavy CPU workload for each layer 3 gateway. 245 4. Anycast layer 3 gateway 247 Multiple gateways share the same IP and MAC address for each VN. 248 These IP and MAC address are called anycast IP and anycast MAC 249 address respectively. Anycast IP is used as the default gateway IP 250 address for all end hosts in the corresponding VN. Gateways always 251 respond with the anycast MAC address when receiving ARP request for 252 the anycast IP. As different VNs are allowed to have overlapping MAC 253 address space, different anycast IP addresses can map to the same 254 anycast MAC. That is to say, each VN should have a unique anycast 255 gateway IP, however multiple anycast gateway IPs may map to the same 256 anycast MAC. It is recommend to configure only one anycast MAC for 257 all VNs on each gateway device for simplicity purpose. Each physical 258 gateway performs layer 2 Ethernet traffic termination when the inner 259 destination MAC of the incoming frame equal to its anycast MAC. 261 To support layer 3 traffic load-balancing among all gateways, 262 besides each layer 3 gateway's own nickname, anycast nickname is 263 introduced, multiple gateways share the same nickname. Each gateway 264 announces anycast nickname through the Nickname Sub-Tlv specified in 265 [RFC6326] to TRILL network and MUST ignore the nickname collision 266 check as defined in basic TRILL protocol. The anycast nickname used 267 by the gateway should be set to the highest priority. With such 268 setting, in case some other RBridge tries to use the same nickname, 269 the gateway can always win in the nickname conflicts. 271 Besides anycast nickname/IP/MAC, each physical gateway also has its 272 own gateway IP and MAC for each VN and its own nickname. 274 The source MAC of ARP reply when responding to ARP request for 275 anycast IP from ES is always the anycast MAC. Ingress nickname 276 should be anycast nickname when the ARP reply message is a unicast 277 TRILL frame. For proactive ARP request from a gateway to ES, source 278 MAC is the gateway's own MAC. In this case ingress nickname in TRILL 279 header should be the gateway's own nickname. Edge nodes i.e. ToRs 280 learn the consistent correspondence of anycast MAC and anycast 281 nickname and correspondence of gateway's physical MAC and 282 nickname through normal data plane learning mechanism. 284 An ES has no knowledge that MAC address it gets for a gateway is 285 actually an address for anycast purpose. The ES operates in normal 286 way. The ES acquires correspondence between anycast MAC and anycast 287 IP through normal ARP procedures. When the ES tries to send traffic 288 cross subnets, it will send the frame to the gateway first. The 289 anycast MAC is used by the end system as destination MAC. As edge 290 nodes, ToRs in this case, learn the consistent correspondence of 291 anycast MAC and nickname for gateway beforehand, frame from the end 292 host sending to the gateway could go to any one of the gateways by 293 the natural support of ECMP from TRILL protocol. The workload is 294 well spread over all the core switches. When one gateway fails, the 295 rest could seamlessly take over the workload automatically without 296 running any VRRP-like keepalive protocol in between. 298 It should not be allowed to telnet each physical gateway using the 299 anycast IP address. The information exchange in a single telnet 300 session may indeed go to the different physical gateways when the 301 anycast gateway IP address is used for telnet. Consequently the 302 state machine at the telnet initiator side may be in unpredictable 303 and disordered states. To overcome this ,it is recommended to use 304 gateway's own physical IP for telnet. ARP tables age independently 305 on each physical gateways. A physical gateway should use its own MAC 306 to send ARP request message to all ES belonging to a VN in proactive 307 mode to acquire destination ES's ARP table. The source MAC of ARP 308 request message should be the gateway's own MAC instead of anycast 309 MAC, the destination ES uses the physical gateway's own MAC as 310 destination MAC to send ARP reply message. Through this mode, the 311 ARP reply message from destination ES can be ensured to reach the 312 physical gateway. Inter-subnet traffic from gateway to ES can use 313 either the gateway's own physical MAC or anycast MAC as source MAC. 315 4.1. ARP Handling 317 Before an ES begins inter-subnet communication, it sends ARP request 318 to ask the MAC address of the gateway. As the ES uses the anycast 319 gateway IP as the target address, all physical layer 3 gateways 320 could possibly respond it. To avoid duplicate ARP reply sending to 321 the end system, only one physical gateway should be elected to 322 respond. The physical gateway that responds to ARP request message 323 is called ARP master gateway. Assuming there are k physical gateways, 324 the algorithm to elect ARP master gateway for each VN is as follows: 326 1. All physical gateways are ordered and numbered from 0 to k-1 in 327 ascending order according to the 7-octet IS-IS ID. 329 2. For VN ID m, choose RB whose number equals (m mod k) as ARP 330 master gateway. 332 The algorithm guarantees each VN has a consistent ARP master gateway. 333 Only ARP master gateway sends ARP reply to an ES's ARP request for 334 that VN. The rest gateways should ignore the ARP request. 336 Sender protocol address (SPA) and Sender hardware address (SHA) in 337 the ARP reply message is set as anycast IP address and anycast MAC 338 address. The ARP reply message is unicast TRILL encapsulated and 339 sent to the ES. Ingress nickname should be anycast nickname. Egress 340 nickname is set as the nickname of egress RB connecting to the ES. 342 As ES broadcasts ARP request message to TRILL campus, all physical 343 gateways can learn the correspondence of from the frame. Gateways can use this information 345 to generate IP forwarding table for that ES. 347 In summary, through the above ARP process: 349 1. Edge RBs i.e. TORs learn anycast MAC address associating with 350 anycast nickname. 352 2. ES learns the anycast MAC address associating with anycast 353 gateway IP. 355 All physical gateways learn the (ES MAC, ES IP and connected edge RB 356 nickname) for all end systems. ARP tables age independently on each 357 layer 3 gateway. To avoid the unnecessary flooding due to ARP table 358 aging, the layer 3 gateway should send ARP detection message 359 periodically in proactive mode to refresh the ARP table state. In 360 this case, source MAC in inner Ethernet header and Sender hardware 361 address (SHA) in the ARP request message is suggested to use the 362 gateway's own MAC, ingress nickname is suggested to use the 363 gateway's own nickname when it is unicast TRILL encapsulated. When 364 the ES receives the ARP request message, ES returns unicast ARP 365 reply message, destination MAC is the layer 3 gateway's own MAC. The 366 message will only reach the layer 3 gateway. When the edge RB 367 connecting the ES receives the ARP reply message, the edge RB will 368 forward the packet to the ARP request sending layer 3 gateway. 370 4.2. Data traffic forwarding 372 After an ES acquires anycast MAC associated with anycast IP through 373 above ARP handling process, it can start to send the inter-subnet IP 374 traffic. Assuming ES1 tries to send data to ES4 in figure1. They 375 belong to different subnet. The IP traffic forwarding process is as 376 following: 378 1. ES1 sends unicast IP traffic to ES4. Destination IP is ES4's IP 379 address, destination MAC is anycast gateway's MAC. 381 2. TOR1 receives the message from ES1. Because TOR1 has already 382 learned anycast MAC address associating with anycast nickname 383 through above ARP process, so it sends the packet with unicast 384 TRILL encapsulation, egress nickname in TRILL header is anycast 385 nickname. The TRILL data will reach one of the physical gateways 386 through ECMP. Assuming the TRILL data reaches GW1. 388 3. GW1 receives the TRILL data from TOR1. It decapsulates the frame 389 and get native packet. It looks up local IP forwarding table 390 based on destination IP and tries to forward the packet to ES4. 391 If entry of was stored 392 on GW1, GW1 encapsulates the frame based on the information and 393 sends it to the egress RB. The source MAC can be the gateway's 394 own MAC or anycast MAC. If the gateway's own MAC is used as 395 source MAC,ingress nickname of TRILL frame should be GW1's own 396 nickname. If anycast MAC is used, ingress nickname should be 397 anycast nickname.(If the entry is not available on GW1, the 398 gateway will send ARP Request message to ES4 proactively.) 400 4. TOR2 receives the TRILL data from GW1. It decapsulates the frame 401 and forward the payload to ES4. 403 All layer 3 traffic will be processed in a flow-based load balancing 404 mode among all physical gateways. Anycast gateway achieves better 405 bandwidth utilization and scalability compared to VRRP-like 406 mechanism. 408 5. Node failure 410 When one of the layer 3 gateways fails, after network convergence, 411 the TRILL traffic to anycast nickname will only reach the remaining 412 gateways. ARP master gateway will be re-elected among the remaining 413 gateways. No VRRP-like protocol session among layer 3 gateways is 414 required to detect the node failure. Network convergence relies 415 purely on TRILL protocol. 417 6. Anycast MAC aging on edge node 419 If anycast MAC aged on an edge node, when the edge node receives 420 inter-subnet traffic from connecting ES, the edge node will flood 421 the unicast traffic to TRILL campus as unknown unicast traffic. All 422 physical gateways will receive the traffic, only one of the physical 423 gateways should forward it, all others should drop it to avoid 424 forwarding duplicated data to destination ES. The forwarding gateway 425 is suggested to be same with ARP master device. 427 7. TRILL protocol extension 429 All layer 3 gateways should announce the anycast gateway TLV in LSP 430 defined in section 6.1 to TRILL campus. Each gateway receiving the 431 anycast gateway TLV from other RBs with the same anycast GW nickname 432 thinks they are in one anycast gateway group. All the gateways 433 should ensure the anycast nickname configuration consistency. If the 434 anycast nickname is different from the local configured one, 435 configuration error occurs and a network warning or SNMP trap should 436 be sent to the network management system. Anycast nickname also is 437 carried in the Nickname Sub-Tlv specified in [RFC6326], each gateway 438 MUST ignore the nickname collision check for anycast nickname. 440 7.1. The Anycast Gateway TLV 442 +-+-+-+-+-+-+-+ 443 |Type= ANY-GW | (1 byte) 444 +-+-+-+-+-+-+-+ 445 | Length | (1 byte) 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Anycast GW Nickname |(2 bytes) 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 o Type: TLV Type, TBD. 452 o Length: indicates the length of LAGID field, it is a fixed value 453 of 1. 455 o Anycast GW Nickname: the nickname is shared by all the physical 456 gateways in the anycast gateway group. All the inter-subnet traffic 457 to the anycast gateways MUST use the nickname as egress nickname in 458 TRILL header. 460 8. Security Considerations 462 The default value of anycast nickname priority should be set as 463 highest value. If nickname on non-gateway and anycast nickname on 464 gateways occurs collision, it can minimize the probability to modify 465 anycast nickname. 467 9. IANA Considerations 469 TBD 471 10. Normative References 473 [1] [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 474 Layer-2 Systems", RFC 6165, April 2011. 476 [2] [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol 477 Specification", RFC 6325, July 2011. 479 [3] [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., 480 and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis- 481 rfc6326bis, work in progress. 483 11. Informative References 485 [4] [RFC 3768] R. Hinden, Ed., "Virtual Router Redundancy Protocol 486 (VRRP)", RFC 3768, April 2004. 488 12. Acknowledgments 490 The authors wish to acknowledge the important contributions of Zhang 491 Chengsong. 493 Authors' Addresses 495 Weiguo Hao 496 Huawei Technologies 497 101 Software Avenue, 498 Nanjing 210012 499 China 500 Phone: +86-25-56623144 501 Email: haoweiguo@huawei.com 503 Yizhou Li 504 Huawei Technologies 505 101 Software Avenue, 506 Nanjing 210012 507 China 508 Phone: +86-25-56625375 509 Email: liyizhou@huawei.com 511 Donald E. Eastlake 512 Huawei Technologies 513 155 Beaver Street 514 Milford, MA 01757 USA 515 Phone: +1-508-333-2270 516 EMail: d3e3e3@gmail.com 518 Radia Perlman 519 Intel Labs 520 2200 Mission College Blvd. 521 Santa Clara, CA 95054-1549 USA 522 Phone: +1-408-765-8080 523 EMail: Radia@alum.mit.edu