idnits 2.17.1 draft-yang-trill-parent-seletion-05.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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 17, 2015) is 3205 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) == Missing Reference: 'RFC2119' is mentioned on line 115, but not defined ** Obsolete normative reference: RFC 7180 (Obsoleted by RFC 7780) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Howard Yang 2 Internet Draft Cisco Systems 3 Intended status: Standards Track Ayan Banerjee 4 Cisco Systems 5 Donald Eastlake 6 Huawei 7 Radia Perlman 8 Intel Labs 9 Expires: January 17, 2016 July 17, 2015 11 TRILL: Parent Selection in Distribution Trees 12 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, except to publish it 19 as an RFC and to translate it into languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on January 17, 2016. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 This document describes a protocol extension in TRILL IS-IS and a 57 parent selection tiebreak algorithm in the calculation of 58 distribution trees in TRILL. The proposal is to modify the current 59 algorithm to improve the stability of the distribution trees when 60 multiple equal cost parents are present. It also offers the 61 capabilities of pinning down multi-destination traffic and re-shaping 62 the distribution trees to improve the traffic load balancing. 64 Table of Contents 66 1. Introduction ................................................... 3 67 1.1. Conventions used in this document ............................ 3 68 2. Problem Definition ............................................. 3 69 3. Explicit Parent Selection Algorithm ............................ 5 70 3.1. Implicit Selection vs. Explicit Selection .................... 5 71 3.1.1. Explicit Selection is a Preference ......................... 6 72 3.1.2. Explicit Selection is a Local Decision ..................... 7 73 3.1.3. Explicit Selection is honoews only if viable ............... 7 74 3.2. Migration and Capability Sub-TLV ............................. 7 75 3.2.1. A Second Approach in the Mixed Environment ................. 6 76 4. Sub-TLV Extensions to IS-IS .................................... 9 77 4.1. Parent Selection Algorithm Version Sub-TLV ................... 9 78 4.2. Explicit Parent Preference Sub-TLV .......................... 10 79 5. Operation of RBridge .......................................... 10 80 6. Other Applications ............................................ 11 81 7. Security Considerations ....................................... 12 82 8. IANA Considerations ........................................... 12 83 9. Conclusions ................................................... 12 84 10. References ................................................... 12 85 10.1. Normative References ....................................... 12 86 11. Acknowledgments .............................................. 13 88 1. Introduction 90 The IETF has standardized the TRILL protocol [RFC6325], which 91 provides transparent Layer 2 forwarding using encapsulation with a 92 hop count and link state routing. TRILL provides optimal pair-wise 93 forwarding without configuration, safe forwarding even during 94 periods of temporary loops, and support for multipathing of both 95 unicast and multicast traffic as well as supporting VLANs. In 96 Section 4.5.1 of [RFC6325], a tiebreak algorithm is described to 97 select a parent node when there are multiple equal cost parents. It 98 uses the tree number as a parameter in the algorithm. 100 While the algorithm described in [RFC6325] is simple and elegant to 101 achieve the goal of traffic load splitting, it exhibits an undesired 102 behavior that a link status change in one tree causes the re- 103 selection of paths in other trees, which impacts the stability of 104 the distribution trees in the event of a link status flap. 106 This document presents a solution to the above problem with the 107 introduction of protocol extension in IS-IS and a modification of 108 the parent selection tiebreak algorithm. 110 1.1. 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 In this document, these words will appear with that interpretation 117 only when in ALL CAPS. Lower case uses of these words are not to be 118 interpreted as carrying RFC-2119 significance. 120 In this document, the characters ">>" preceding an indented line(s) 121 indicates a compliance requirement statement using the key words 122 listed above. This convention aids reviewers in quickly identifying 123 or finding the explicit compliance requirements of this RFC. 125 2. Problem Definition 127 In the following example of TRILL network, there are two groups of 128 RBridges or nodes: one group consists of RBridges X, Y and Z (Let's 129 call it spine node group). The other group consists of RBridges A, B, 130 C, and D (Let's call it leaf node group). Each spine node has one 131 link connecting to each leaf node. There are no links connecting any 132 two spine nodes. There are no links between any two leaf nodes, 133 either. (In this document, node and RBridge are used 134 interchangeably.) 136 +-----------+ +------------+ +-----------+ 137 | X | | Y | | Z | 138 | +--+ | | +--+ | 139 +---+-+---+-+ | ++-+------+-++ | +-+-+---+---+ 140 | | | | | | | | | | | | 141 | | +----|---|-|------|-|-+ | | | | 142 | | | | | | | | | | | | 143 | | | +-|-|------|-|-|-|----+ | | 144 | | | | | | | | | | | | 145 | +--------|-|-|-|------|-|-|-|------|-+ | 146 | | | | | | | | | | | | 147 | +--------|-|-|-|------|-|-|-|------+ | | 148 | | | | | | | | | | | | 149 | | +------|-|-+ | | +-|-|------+ | | 150 | | | | | | | | | | | | 151 +---+-+-+-+ +-+-+---+-+ +-+---+-+-+ +-+-+-+---+ 152 | A | | B | | C | | D | 153 | | | | | | | | 154 +---------+ +---------+ +---------+ +---------+ 156 Assume three multi-destination distribution trees are to be 157 calculated, with Tree 1 rooted at X, Tree 2 at Y, and Tree 3 at Z. 158 Assuming the 7-octet IS-IS IDs of A, B, C, D are in ascending order. 160 When a tree, for example, Tree 2 (rooted at Y), is calculated, and 161 when node X is to be added to the tree, there are 4 equal cost 162 possible parents: A, B, C, D. To pick one as the parent, a tiebreak 163 algorithm is needed. Section 4.5.1 of [RFC6325] describes a parent 164 selection tiebreak algorithm: For each node N, if N has p parents of 165 equal cost, then order the parents in ascending order according to 166 the 7-octet ISIS-ID and number them starting at zero. For Tree j, 167 choose N's parent as choice (j-1) mod p. (See also [RFC7180] for 168 the correction of the algorithm.) We call the algorithm "original 169 tiebreak algorithm". 171 Applying this algorithm, on Tree 2, B is selected as the parent node 172 for X, that is, link XB is on Tree 2. (In this document, link XB 173 means the link between node X and node B.) Similarly, when Tree 3 is 174 calculated, C is selected as the parent for X. (On Tree 1, A is 175 selected as the parent for Y and Z). 177 In the event when the link XA goes down, Tree 1 will select B as the 178 parent node for Y and Z, as there are only 3 equal cost parents (B, 179 C, and D) for Y or Z now. This change on Tree 1 is expected, as XA 180 was on Tree 1. 182 But observe the changes on Tree 2 and 3: Tree 2 now changes to select 183 C as the parent node for X, due to the failure of link XA. Similarly, 184 Tree 3 changes to select D as the parent node for X. 186 Parent of X on Tree 2 Parent of X on Tree 3 187 XA is up B C 188 XA is down C D 190 Although link XA is only on Tree 1, its link status change caused the 191 re-selection of the parents on other trees. That is, the status 192 change on one seemingly unrelated link causes the re-selection of the 193 parent nodes and the changes of the tree paths on other trees. 195 This behavior affects the stability of the multi-destination 196 distribution trees in TRILL. 198 We propose the following modifications to solve the problem. 200 In addition, network designers and administrators wish to "pin" the 201 multi-destination traffic to the paths. They prefer to have the 202 traffic follow trees with some deterministic in nature. The proposal 203 here offers such a tool to "pin" down the traffic to the trees. 205 3. Explicit Parent Selection Algorithm 207 3.1. Implicit Selection vs. Explicit Selection 209 In the current parent selection tiebreak algorithm, when there are p 210 parent nodes, we list them in the ascending order and assignment a 211 number to them starting from 0. And Tree j selects the node (j-1) mod 212 p, in the ordered list as its parent. We call this selection 213 "implicit selection". 215 In the previous example, when the link XA is up, in the calculation 216 of Tree 2, when node X is being added to the tree, B is chosen as the 217 parent. This is implicit selection. In the proposed algorithm, this 218 implicit selection is noted down on X. That is, on X, (Tree 2, B) is 219 saved in memory to be used later on. Similarly, on X, (Tree 3, C) is 220 also noted down in the parent selection database. 222 When link XA goes down, the new implicit selections change for X on 223 Tree 2 and 3. The new implicit selections are (Tree 2, C) and (Tree 224 3, D). Now we propose to change the algorithm to override this. 226 After the link XA goes down, X detects such link status change, and 227 checks against its parent selection database. X then makes a 228 conscious decision and advertises, in its LSP, the previously saved 229 selections (Tree 2, B) and (Tree 3, C). Such advertised selections 230 are called "explicit selections". 232 The essence of the proposed algorithm is: instead of relying on the 233 well-known algorithm for everyone to pick C as the parent for X on 234 Tree 2 and D on Tree 3, X advertises the explicit selection 235 preference and suggests everybody that B should continue to be the 236 parent for X on Tree 2, and C on Tree 3. 238 The way to advertise such explicit selections is to put them in the 239 TLVs of X's LSP, which are propagated to all the nodes in the TRILL 240 network. 242 The new tiebreak algorithm is then modified in such a way that when 243 node X is to be considered to be added to a tree, the RBridge running 244 the algorithm looks for explicit "parent selection preference" TLVs 245 in X's LSP. If no such TLV is present, the current algorithm is used 246 and the implicit selection is chosen. If there is an explicit 247 selection in LSP, this parent selection preference advertisement must 248 be honored, if it is a viable option, meaning it is among the list of 249 currently available equal cost shortest path parent choices. 251 In our example, since X advertises (Tree 2, B), and B is a viable 252 option, B is therefore chosen as the parent for X on Tree 2. 253 Similarly, C is chosen as parent for X on Tree 3. 255 This achieves our goal of keeping the parent selections unchanged on 256 Tree 2 and Tree 3 when link XA goes down. 258 3.1.1. Explicit Selection is a Preference 260 When a node advertises the explicit parent selection, such 261 advertisement is a preference, which may or may not be honored. The 262 explicit selection is honored only when it is among the equal cost 263 parent choices. 265 In the previous example, if Links XA and YB both go down the same 266 time, when calculation Tree 2, and when X is added to the tree path, 267 X's advertisement of (Tree 2, B) cannot be honored, as B is not 268 viable. X advertised that it preferred to choose B as the parent on 269 Tree 2, but such preference is not honored. In such case, the 270 original tiebreak algorithm is applied and C is chosen as the parent. 272 It is worthwhile to point out that in the above case when both XA and 273 YB go down, with the proposed algorithm when X advertises (Tree 2, B) 274 and (Tree 3, C), and Y advertises (Tree 1, A) and (Tree 3, C), Tree 3 275 is not affected by the link status changes. 277 3.1.2. Explicit Selection is a Local Decision 279 It is up to an RBridge to decide whether or not to advertise any 280 explicit selection preference. For example, in the above example, X 281 can choose not to advertise any explicit selection even when link XA 282 goes down, and allow all the nodes in the network to continue to 283 select the implicit selections (which of course causes changes to 284 Trees 2 and 3). X can even advertise a different node, for example, 285 (Tree 2, D). 287 Whether or not to advertise or which node to advertise is a local 288 decision. This characteristic makes it possible to have a smooth 289 system software upgrade and migration in the TRILL network. 291 It is also the responsibility of the local node to decide when to 292 stop any preference advertisement. 294 3.1.3. Explicit Selection is honored only if viable 296 Before the explicit selection advertisement is honored, a "viability 297 check" must be performed. If the explicit advertisement is among the 298 choices of equal cost shortest path parents, then it is viable. Only 299 viable explicit advertisements are to be honored. This is to ensure 300 that the multi-destination trees resulting from the new algorithm are 301 still the SPF trees (short path trees). 303 3.2. Migration and Capability Sub-TLV 305 It is important that all the RBridges in the TRILL network runs the 306 same SPF algorithm (including tiebreak algorithm) for the 307 distribution tree calculation. Therefore, in the software upgrade and 308 migration case, until all the RBridges are upgraded with the 309 capability to run the new explicit selection tiebreak algorithm, any 310 RBridge must continue to run the original tiebreak algorithm 311 described in Section 4.5.1 of [RFC6325]. 313 To achieve the migration goal, a new router-capability sub-TLV will 314 be introduced, which will indicate whether or not an RBridge is 315 capable to run the new algorithm. The absence of such sub-TLV in the 316 LSP implies that the RBridge is not capable to run the new algorithm. 318 RBridge must inspect the LSPs of all the reachable nodes before the 319 tree calculation. When an RBridge detects that there is at least one 320 RBridge which does not advertise this capability sub-TLV, it should 321 not advertise any explicit selections, and the implicit selections 322 MUST be chosen, and any explicit selection advertisement is ignored. 324 In a mixed environment where the network consists of RBs running both 325 existing algorithm and the proposed enhanced algorithm, the above 326 approach prevents loops when mutli-destination trees are calculated. 327 Although, with this approach, until all the RBs are upgraded to run 328 the new algorithm, none of the RBs can take advantage of the new 329 algorithm. 331 3.2.1. A Second Approach in the mixed environment 333 A second proposal is to introduce a new flag in the highest priority 334 RB's LSP. This flag signals to all the RBs in the network which 335 algorithm to run, when highest priority RB's LSP is propagated. 337 Let's call the existing parent selection algorithm "V0", and let's 338 call the new proposed parent selection algorithm "V1". 340 If the new flag in the highest priority RB indicates to run V0, then 341 all the RBs continue to run the existing algorithm, and should ignore 342 any explicit parent advertisements, if they exist. 344 If the new flag in the highest priority RB indicates to run V1, then 345 all the RBs which understand this flag MUST run the new algorithm. Of 346 course, all those RBs which have not been upgraded will not 347 understand this flag and will continue to run the existing algorithm. 349 We also need to introduce a new TLV or sub-TLV in the ISIS hellos to 350 indicate whether an RB supports the new enhanced algorithm. And an RB 351 running V1 must not form ISIS adjacency with RBs running V0. 353 With this approach, RBs can be turned on to run the new algorithm as 354 they are upgraded, and do not have to wait until all the RBs are 355 upgraded. The drawbacks of this approach are that it requires an 356 additional configuration (to set the flag on highest priority RB to 357 signal which version to run), and the V1 and V0 RBs are partitioning 358 the network (as they do not form adjacency with each other). 360 Summary of this approach: Each RBridge announces, in its Hellos (and 361 possibly also in its LSP), whether it can use the new tree 362 algorithm. The highest priority RBridge R1 announces, in its LSP, 363 whether to run the new or old algorithm. R1 makes the decision 364 based solely on configuration. If R1 announces using the new 365 algorithm, and there are still old RBridges that do not support the 366 new algorithm, then new RBridges will refuse to form an adjacency 367 with them. 369 4. Sub-TLV Extensions to IS-IS 371 Two new sub-TLVs are introduced in below sub-sections. Both sub-TLVs 372 can be carried in Router Capability TLV. The Router Capability TLV is 373 defined in [RFC4971]. 375 4.1. Parent Selection Algorithm Version Sub-TLV 377 The Parent Selection Algorithm Version sub-TLV indicates the maximum 378 version of the algorithm supported by an RBridge. By implication, 379 lower versions are also supported. If this sub-TLV is missing, the 380 originating RBridge only supports the based version, which is the 381 original algorithm described in Section 4.5.1 of [RFC6325]. 383 This sub-TLV can also be used in ISIS hellos in port capability TLV 384 if the second approach is used in the mixed environment (Section 385 3.2.1). 387 +-+-+-+-+-+-+-+-+ 388 | Type | (1 byte) 389 +-+-+-+-+-+-+-+-+ 390 | Length | (1 byte) 391 +-+-+-+-+-+-+-+-+ 392 | Max-version | (1 byte) 393 +-+-+-+-+-+-+-+-+ 395 o Type: Router Capability sub-TLV type, set to PARENT-SELECT-VER. 397 o Length: 1. 399 o Max-version: Set to maximum version supported. 0: base version. 1: 400 Explicit Parent Selection algorithm. 402 4.2. Explicit Parent Preference Sub-TLV 404 The Explicit Parent Preference Sub-TLV is a list of pairs of tree 405 number and IS-IS ID. It includes the explicit parent selection 406 advertisements which indicate which nodes the originating RBridge 407 prefers in the equal cost multiple parent case for the trees. 409 +-+-+-+-+-+-+-+-+ 410 | Type | (1 byte) 411 +-+-+-+-+-+-+-+-+ 412 | Length | (1 byte) 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Tree Number a | (2 bytes) 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | IS-IS ID | (7 bytes) 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Tree Number b | (2 bytes) 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | IS-IS ID | (7 bytes) 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Tree Number (...) | (2 bytes) 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | IS-IS ID (...) | (7 bytes) 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 o Type: Router Capability sub-TLV type, set to PARENT-PREFERENCE. 429 o Length: 9*n, where n is the number of trees listed. 431 o Tree Number: This is the tree number on which the explicit parent 432 node will be specified in the next IS-IS ID field. 434 o IS-IS ID: The 7-octet IS-IS ID of the parent node for the 435 originating node on the tree whose number is specified in the 436 previous "Tree Number" field. 438 5. Operation of RBridge 440 An RBridge MUST examine the LSPs of all the reachable nodes before 441 each calculation of multi-destination distribution trees. Depending 442 on the examination result, the RBridge can be in one of the following 443 two states: 445 o "Ineligible" state: if there is at least one node which does not 446 include the "Parent Selection Algorithm Version" sub-TLV, or it 447 includes a lower version than "Explicit Parent Selection" version. 449 o "Eligible" state: if all the reachable nodes includes the "Parent 450 Selection Algorithm Version" sub-TLV, and the version is greater 451 or equal to "Explicit Parent Selection" Version (version 1) 453 An RBridge must follow the following rules. 455 An RBridge can include the "Parent Selection Algorithm Version" sub- 456 TLV in Router-Capability TLV, although such include is not mandatory. 458 In "Ineligible" state, the RBridge should not include "Explicit 459 Parent Preference" sub-TLV in its LSP. It MUST ignore any "Explicit 460 Parent Preference" in other nodes' LSPs, if there is any. And it MUST 461 run the original parent selection algorithm ([RFC6325] as modified by 462 [RFC7180]). 464 In "Eligible" state, the RBridge can include "Explicit Parent 465 Preference" sub-TLV in its LSP. It MUST run the modified tiebreak 466 algorithm in the distribution tree calculation: when a node X is 467 added into the tree j, and when there are p number of equal cost 468 parent choices, the RBridge MUST exam the "Explicit Parent 469 Preference" sub-TLV in X's LSP, and MUST take one of the following 470 actions: 472 1. If the Explicit Parent Preference is among the equal cost parent 473 choices, the explicit parent preference MUST be honored. 475 2. Otherwise, the Explicit Parent Preference MUST be ignored. Select 476 the choice of (j-1) mod p, as described in the original tiebreak 477 algorithm. 479 6. Other Applications 481 The proposed algorithm provides a tool to influence the tree parent 482 node selection, and further makes it possible to re-shape the 483 distribution trees. It is demonstrated how to improve the stability 484 of the distribution trees with the tool. 486 With this tool, network engineers can also redirect multi-destination 487 traffic and improve traffic load sharing. For example, in our 488 previous example, while X can advertise (Tree 2, B) as explicit 489 parent preference, but X can also advertise (Tree 2, D) instead. This 490 makes it possible to utilize link XD, which in some cases may be 491 desirable for the purposes of traffic engineering. 493 7. Security Considerations 495 No additional security risk is introduced by using the mechanisms 496 proposed in this document. 498 For TRILL general Security Considerations, see [RFC6325]. 500 8. IANA Considerations 502 This document introduces two new router-capability sub-TLVs that 503 require code point assignment: 505 o Parent selection tiebreak algorithm version, to be assigned from 506 the IANA "IS-IS TLV Codepoints Registry". 508 o Explicit parent selection, to be assigned from the IANA "IS-IS TLV 509 Codepoints Registry". 511 9. Conclusions 513 This document presents a parent selection tiebreak algorithm in the 514 calculation of distribution trees in TRILL. A protocol extension in 515 IS-IS is defined, and a network migration strategy is also designed. 516 The proposed algorithm provides a tool to influence the parent node 517 selection, which can improve the stability and traffic load sharing 518 of the distribution trees when multiple equal cost parents are 519 present. It also offers a tool to network administrators to pin down 520 the multi-destination traffic to trees in more deterministic way. 522 10. References 524 10.1. Normative References 526 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 527 Ghanwani, "RBridges: Base Protocol Specification", RFC 528 6325, June 2011. 530 [RFC7180] D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. 531 Banerjee, "TRILL: Clarifications, Corrections, and 532 Updates", May 2014. 534 [RFC4971] Vasseur, JP. and N. Shen, "Intermediate System to 535 Intermediate System (IS-IS) Extensions for Advertising 536 Information", 2007. 538 11. Acknowledgments 540 The authors would like to thank Abhay Roy, Erik Nordmark, Varun Shah, 541 Ramkumar Parameswaran and Deepak Sreekantan for review and 542 suggestions. 544 This document was prepared using 2-Word-v2.0.template.dot. 546 Authors' Addresses 548 Howard Yang 549 Cisco Systems 550 170 West Tasman Drive, San Jose, CA 95134 552 Email: howardy@cisco.com 554 Ayan Banerjee 555 Cisco Systems 556 170 West Tasman Drive, San Jose, CA 95134 558 Email: ayabaner@gmail.com 560 Donald Eastlake 561 Huawei R&D USA 562 155 Beaver Street, Milford, MA 01757 564 Phone: 1-508-333-2270 565 Email: d3e3e3@gmail.com 567 Radia Perlman 568 Intel Labs 569 2200 Mission College Blvd., Santa Clara, CA 95054-1549 571 Phone: 1-408-765-8080 572 Email: radia@alum.mit.edu