idnits 2.17.1 draft-ietf-trill-mtu-negotiation-02.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 == Line 438 has weird spacing: '... tbd origi...' -- The document date (February 25, 2016) is 2982 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: 'RFC6439bis' is mentioned on line 137, but not defined ** Obsolete undefined reference: RFC 6439 (Obsoleted by RFC 8139) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Zhang 3 Intended Status: Standards Track X. Zhang 4 Updates: 7177 D. Eastlake 5 Huawei 6 R. Perlman 7 EMC 8 V. Manral 9 Ionos 10 S. Chatterjee 11 Cisco 12 Expires: August 28, 2016 February 25, 2016 14 Transparent Interconnection of Lots of Links (TRILL): 15 MTU Negotiation 16 draft-ietf-trill-mtu-negotiation-02.txt 18 Abstract 20 The base IETF TRILL protocol has a TRILL campus wide MTU feature, 21 specified in RFC 6325 and RFC 7177, that assures that link state 22 changes can be successfully flooded throughout the campus while being 23 able to take advantage of a campus wide capability to support jumbo 24 packets. This document specifies optional updates to that MTU feature 25 to take advantage, for appropriate link local packets, of link local 26 MTUs that exceed the TRILL campus MTU. In addition, it specifies an 27 efficient algorithm for local MTU testing. It updates RFC 7177. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Conventions used in this document . . . . . . . . . . . . . 3 69 2. Link-Wide TRILL MTU Size . . . . . . . . . . . . . . . . . . . 3 70 3. Link MTU Size Testing . . . . . . . . . . . . . . . . . . . . . 5 71 4. Refreshing Campus-Wide Sz . . . . . . . . . . . . . . . . . . . 7 72 5. Relationship between Port MTU, Lz and Sz . . . . . . . . . . . 8 73 6. LSP Synchronization . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Recommendations for Traffic Link MTU Size Testing . . . . . . . 9 75 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . 9 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 [RFC6325] describes the way RBridges agree on the campus-wide minimum 86 acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the 87 campus-wide "Sz" to ensure that link state flooding operates properly 88 and all RBridges converge to the same link state. For the proper 89 operation of TRILL IS-IS, all RBridges MUST format their LSPs to fit 90 in the campus-wide Sz. 92 [RFC7177] diagrams the state transitions of an adjacency. If MTU 93 testing is enabled, "Link MTU size is successfully tested" is part of 94 an event (event A6) causing the transition from "2-way" state to 95 "Report" state for an adjacency. This means the link MTU testing of 96 size X succeeds, and X is greater than or equal to the campus-wide Sz 97 [RFC6325]. In other words, if this link cannot support an MTU of the 98 campus-wide Sz, it will not be reported as part of the campus 99 topology. 101 This document specifies a new value, link-wide "Lz", representing the 102 link-wide minimum acceptable inter-RBridge MTU size for a specific 103 link. There are PDUs that are sent only within a local link, such as 104 CSNPs and PSNPs. These PDUs should be formatted not greater than the 105 link-wide Lz. Since link-wide Lz is frequently greater than the 106 campus-wide Sz, link scope PDUs can, in such cases, be formatted 107 greater than the campus-wide Sz up to Lz. 109 An optional TRILL MTU size testing algorithm is specified in Section 110 3 as an efficient method for the MTU testing described in Section 111 4.3.2 of [RFC6325] and in [RFC7177]. Multicasting the MTU-probes is 112 recommended when there are multiple RBridges on a link responding to 113 the probing with MTU-ack [RFC7177]. The testing method and rules of 114 this document are devised in a way to minimize the number of MTU 115 probes for testing, which therefore reduces the number of multicast 116 packets for MTU testing. 118 1.1. Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Link-Wide TRILL MTU Size 126 This document specifies a new value "Lz" for the acceptable inter- 127 RBridge link MTU size on a local link. Link-wide Lz is the minimum Lz 128 supported between all RBridges on a specific link. If the link is 129 usable, Lz will be greater than or equal to the campus wide Sz MTU. 130 Some TRILL IS-IS PDUs are exchanged only between neighbors instead of 131 the whole campus. They should be confined by the link-wide Lz instead 132 of the campus-wide Sz. CSNPs and PSNPs are examples of such PDUs. 133 These PDUs are exchanged just on the local link. 135 [RFC7356] defines the PDUs which support flooding scopes in addition 136 to area wide scope and domain wide scope. As specified in 137 [RFC6439bis], RBridges MUST support the Extended L1 Circuit Scoped 138 (E-L1CS) flooding. They use that flooding to exchange their maximally 139 supportable value of "Lz". The smallest value of the Lz advertised by 140 the RBridges on a link, but not less than Sz, is the link-wide Lz. An 141 RBridge on a local link will be able to tell which other RBridges on 142 that link support E-L1CS FS-LSPs because, as required by [RFC7180bis] 143 all RBridges are required to include the Scoped Flooding Support TLV 144 [RFC7356] in their TRILL Hellos. 146 The maximum sized level 1 link-local PDU, such as PSNP or CSNP, which 147 may be generated by a system is controlled by the value of the 148 management parameter originatingL1SNPBufferSize. This value 149 determines Lz. The TRILL APPsub-TLV shown in Figure 2.1 SHOULD be 150 included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP 151 fragment zero. If it is missing from a fragment zero E-L1CS FS-LSP or 152 there is no fragment zero E-L1CS FS-LSP, it is assumed that its 153 originating IS is implicitly advertising its originatingSNPBufferSize 154 value as Sz octets. 156 E-L1CS FS-LSPs are link local and can also be sent up to Lz in size 157 but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470 158 bytes. 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | (2 byte) 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Length | (2 byte) 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | originatingSNPBufferSize | (2 byte) 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 2.1: The originatingSNPBufferSize TLV. 170 Type: set to originatingSNPBufferSize subTLV (TRILL APPsub-TLV type 171 tbd). Two bytes because this APPsub-TLV appears in an Extended TLV 172 [RFC7356]. 174 Length: set to 2. 176 originatingSNPBufferSize: the local value of 177 originatingL1SNPBufferSize, limited to 1470 to 65,535 bytes. 179 Lz is reported using a originatingSNPBufferSize TLV that MUST occur 180 in fragment zero of the RBridge's E-L1CS FS-LSP. 182 Lz:1800 Lz:1800 183 +---+ | +---+ 184 |RB1|(2000)---|---(2000)|RB2| 185 +---+ | +---+ 186 | 187 Lz:1800 | 188 +---+ +--+ 189 |RB3|(2000)---(1700)|B1| 190 +---+ +--+ 191 | 193 Figure 2.2: Link-wide Lz = 1800 v.s. tested link MTU size = 1700 195 Even if all RBridges on a specific link have reached consensus on the 196 value of link-wide Lz, it does not mean that these RBridges can 197 safely exchange PDUs between each other. Figure 2.2 shows such a 198 corner case. RB1, RB2 and RB3 are three RBridges on the same link and 199 their Lz is 1800, so the link-wide Lz of this link is 1800. There is 200 an intermediate bridge (say B1) between RB2 and RB3 whose port MTU 201 size is 1700. If RB2 sends PDUs formatted in chunk of size 1800, it 202 will be discarded by B1. 204 Therefore the link MTU size should be tested. After the link MTU size 205 of an adjacency is successfully tested, those link local PDUs such as 206 CSNPs, PSNPs and E-L1CS FS-LSPs will be formatted no greater than the 207 tested link MTU size and will be safely transmitted on this link. 209 As for campus-wide Sz, RBridges continue to propagate their 210 originatingL1LSPBufferSize across the campus through the 211 advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The 212 smallest value of Sz advertised by any RBridge, but not less than 213 1470, will be deemed as the campus-wide Sz. Each RBridge should 214 format their "campus-wide" PDUs, for example LSPs, not greater than 215 what they believe to be the campus-wide Sz. 217 3. Link MTU Size Testing 219 [RFC7177] defines the event A6 as including "MTU test is successful" 220 if the MTU testing is enabled. As described in Section 4.3.2 of 221 [RFC6325], this is a combination of the following event and 222 condition. 224 Event: The link MTU size has been tested. 226 Condition: The link can support the campus-wide Sz. 228 This condition can be efficiently tested by the following "Binary 229 Search Algorithm" and rules. The MTU-probe and MTU-ack PDUs are 230 specified in Section 3 of [RFC7176]. 232 X, X1, and X2 are local integer variables. 234 Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz. 236 1) If RB1 successfully receives the MTU-ack from RB2 to the probe of 237 the value of link-wide Lz within k tries (where k is a 238 configurable parameter whose default is 3), then link MTU size is 239 set to the size of link-wide Lz and stop. 241 2) RB1 tries to send an MTU-probe padded to the size 1470. 243 a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1 244 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello 245 and stop. 247 b) Link MTU size <-- 1470, X1 <-- 1470, X2 <-- link-wide Lz, X <-- 248 [(X1 + X2)/2] (Operation "[...]" returns the fraction-rounded- 249 up integer.). Repeat Step 1. 251 Step 1: RB1 tries to send an MTU-probe padded to the size X. 253 1) If RB1 fails to receive an MTU-ack from RB2 after k tries, then: 255 X2 <-- X and X <-- [(X1 + X2)/2] 257 2) If RB1 receives an MTU-ack to a probe of size X from RB2 then: 259 link MTU size <-- X, X1 <-- X and X <-- [(X1 + X2)/2] 261 3) If X1 >= X2 or Step 1 has been repeated n times (where n is a 262 configurable parameter whose default value is 5), stop. Else 263 repeat Step 1. 265 MTU testing is only done in the Designated VLAN [RFC7177]. Since the 266 execution of the above algorithm can be resource consuming, it is 267 recommended that the DRB take the responsibility to do the testing. 268 Multicast should be used instead of unicast when multiple RBridges 269 are desired to respond with MTU-ack on the link. The Binary Search 270 Algorithm is given here as a way to minimize the probing attempts; it 271 reduces the number of multicast packets for MTU-probing. 273 The following rules are designed to determine whether the 274 aforementioned "Condition" holds. 276 RBridges have figured out the upper bound (X2) and lower bound (X1) 277 for the link MTU size from the execution of the above algorithm. If 278 the campus-wide Sz is smaller than the lower bound or greater than 279 the upper bound, RBridges can directly judge whether the link 280 supports the campus-wide Sz without MTU-probing. 282 (a) If X1 >= campus-wide Sz. This link can support campus-wide Sz. 284 (b) Else if X2 <= campus-wide Sz. This link cannot support campus- 285 wide Sz. 287 Otherwise, RBridges need to test whether the link can support campus- 288 wide Sz: 290 (c) X1 < campus-wide Sz < X2. RBridges need probe the link with MTU- 291 probe messages padded to campus-wide Sz. If an MTU-ack is 292 received within k tries, this link can support campus-wide Sz. 293 Otherwise, this link cannot support campus-wide Sz. Through this 294 test, the lower bound and upper bound of link MTU size can be 295 updated accordingly. 297 4. Refreshing Campus-Wide Sz 299 RBridges may join or leave the campus, which may change the campus- 300 wide Sz. The following recommendations are specified for refreshing 301 the campus-wide Sz. 303 1) When a new RBridge joins the campus and its 304 originatingL1LSPBufferSize is smaller than current campus-wide Sz, 305 reporting its originatingL1LSPBufferSize in its LSPs will cause 306 other RBridges decrease their campus-wide Sz. Then the LSPs in the 307 campus MUST be re-sized to be no greater than the new campus-wide 308 Sz. 310 2) When an RBrige leaves the campus and its 311 originatingL1LSPBufferSize is equal to the campus-wide Sz, its 312 LSPs are purged from the remaining campus after reaching MaxAge 313 [IS-IS]. The campus-wide Sz MAY be recalculated and MAY increase. 314 In other words, while RB1 normally ignores link state information 315 for any IS-IS unreachable [RFC7180bis] RBridge RB2, 316 originatingL1LSPBufferSize is an exception. Its value, even from 317 IS-IS unreachable RBridges, is used in determining Sz. 319 Frequent LSP "re-sizing" is harmful to the stability of the TRILL 320 campus, so it should be dampened. Within the two kinds of resizing 321 actions, only the upward resizing will be dampened. When an upward 322 resizing event happens, a timer is set (this is a configurable 323 parameter whose default value is 300 seconds). Before this timer 324 expires, all subsequent upward resizing will be dampened. Of course, 325 in a well-configured campus with all RBridges configured to have the 326 same originatingL1LSPBufferSize, no resizing will be necessary. It 327 does not matter if different RBridges have different dampening timers 328 or some RBridges re-size upward more quickly than others. 330 If the refreshed campus-wide Sz is smaller than the lower bound or 331 greater than the upper bound of the tested link MTU size, the 332 resource consuming link MTU size testing can be avoided according to 333 rule (a) or (b) specified in Section 3. Otherwise, RBridges need to 334 test the link MTU size according to rule (c). But it's unnecessary to 335 perform the link MTU size testing algorithm all over again. 337 5. Relationship between Port MTU, Lz and Sz 339 When port MTU size is smaller than the local 340 originatingL1SNPBufferSize of an RBridge (sort of a wrong 341 configuration), this port should be explicitly disabled from the 342 TRILL campus. On the other hand, when an RBridge receives an LSP or 343 E-L1CS FS-LSP with size greater than the link-wide Lz or the campus- 344 wide Sz but not greater than its port MTU size, this LSP should be 345 processed normally and not discarded. If the size of an LSP is 346 greater than the MTU size of a port over which it is to be 347 propagated, no attempt shall be made to propagate this LSP over the 348 port and an LSPTooLargeToPropagate alarm shall be generated [IS-IS]. 350 6. LSP Synchronization 352 An RBridge participates in LSP synchronization on a link as soon as 353 it has at least one adjacency on that link that has advanced to at 354 least the 2-Way state [RFC7177]. On a LAN link, CSNP and PSNP PDUs 355 are used for synchronization. On a point-to-point link, only PSNP are 356 used. 358 The CSNPs and PSNPs MUST be formatted in chunks of size at most the 359 link-wide Lz but are processed normally if received larger than that. 360 Since the link MTU size may not have been tested in the 2-Way state, 361 link-wide Lz may be greater than the supported link MTU size. In that 362 case, a CSNP or PSNP may be discarded. After the link MTU size is 363 successfully tested, RBridges will begin to format these PDUs in the 364 size no greater than it, therefore these PDUs will eventually get 365 through. 367 Note that the link MTU size is frequently greater than the campus- 368 wide Sz. Link local PDUs are formatted in the size of link MTU size 369 rather than the campus-wide Sz, which, when Lz is greater than Sz, 370 promises a reduction in the number of PDUs and a faster LSP 371 synchronization process. 373 7. Recommendations for Traffic Link MTU Size Testing 375 Campus-wide Sz and link-wide Lz are used to limit the size of most 376 TRILL IS-IS PDUs. They are different from the MTU size restricting 377 the size of TRILL Data packets. The size of a TRILL Data packet is 378 restricted by the physical MTU of the ports and links the packet 379 traverses. It is possible that a TRILL Data packet successfully gets 380 through the campus but its size is greater than the campus-wide Sz or 381 link-wide Lz values. 383 The algorithm defined in link MTU size testing can also be used in 384 TRILL traffic MTU size testing; in that case the link-wide Lz used in 385 that algorithm should be replaced by the port MTU of the RBridge 386 sending MTU probes. The successfully tested size X can be advertised 387 as an attribute of this link using MTU sub-TLV defined in [RFC7176]. 389 Unlike RBridges, end stations do not participate in the exchange of 390 IS-IS PDUs of TRILL, therefore they cannot grasp the traffic link MTU 391 size from a TRILL campus automatically. An operator may collect these 392 values using network management tools such as TRILL ping or 393 TraceRoute. Then the path MTU is set as the smallest tested link MTU 394 on this path and end stations should not generate frames that, when 395 encapsulated as TRILL Data packets, exceed this path MTU. 397 8. Backwards Compatibility 399 There can be a mixture of Lz-ignorant and Lz-aware RBridges on a 400 link. This will act properly although it will not be as efficient as 401 it would be if all RBridges on the link are Lz-aware. 403 At the side of an Lz-aware RBridge, in case that link-wide Lz is 404 greater than campus-wide Sz, larger link-local TRILL IS-IS PDUs can 405 be sent out to gain efficiencies. Lz-ignorant RBridges as receivers 406 will have no problem handling them since the 407 originatingL1LSPBufferSize value of these RBridges had been reported 408 and the link-wide Lz is not greater than that value. 410 For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted not 411 greater than the campus-wide Sz. Lz-aware RBridges as receivers can 412 handle these PDUs since they cannot be greater than the link-wide Lz. 414 An Lz-ignorant RBridge might not support the link MTU testing 415 algorithm defined in Section 3 but could be using some algorithm just 416 to test for Sz MTU on the link. In any case, if an RBridge per 417 [RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack 418 padded to the same size as the MTU-probe. So the extension of TRILL 419 MTU negotiation with Lz, as specified in this document, is fully 420 backwards compatible. 422 9. Security Considerations 424 This document raises no new security issues for TRILL. For general 425 and adjacency related TRILL security considerations, see [RFC6325] 426 and [RFC7177]. 428 10. IANA Considerations 430 IANA is requested to assign a new APPsub-TLV number from the range 431 less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 432 Application Identifier 1" registry for the TRILL 433 originatingSNPBufferSize sub-TLV defined in Section 2 of this 434 document. The entry is as follows: 436 Type Name Reference 437 ---- ------------------------ --------------- 438 tbd originatingSNPBufferSize [this document] 440 11. References 442 11.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, DOI 446 10.17487/RFC2119, March 1997, . 449 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 450 Ghanwani, "Routing Bridges (RBridges): Base Protocol 451 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 452 . 454 [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and 455 V. Manral, "Transparent Interconnection of Lots of Links 456 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 457 2014, . 459 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., 460 and A. Banerjee, "Transparent Interconnection of Lots of 461 Links (TRILL) Use of IS-IS", RFC 7176, DOI 462 10.17487/RFC7176, May 2014, . 465 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 466 Scope Link State PDUs (LSPs)", RFC 7356, DOI 467 10.17487/RFC7356, September 2014, . 470 [RFC7180bis] D. Eastlake, M. Zhang, et al., "TRILL: Clarifications, 471 Corrections, and Updates", draft-ietf-trill-rfc7180bis, 472 working in progress. 474 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 475 Stokes, "Transparent Interconnection of Lots of Links 476 (TRILL): End Station Address Distribution Information 477 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 478 September 2014, . 480 11.2. Informative References 482 [IS-IS] International Organization for Standardization, 483 "Information technology -- Telecommunications and 484 information exchange between systems -- Intermediate System 485 to Intermediate System intra-domain routeing information 486 exchange protocol for use in conjunction with the protocol 487 for providing the connectionless-mode network service (ISO 488 8473)", ISO/IEC 10589:2002, Second Edition, November 2002. 490 Author's Addresses 492 Mingui Zhang 493 Huawei Technologies 494 No. 156 Beiqing Rd. Haidian District 495 Beijing 100095 496 China 498 Phone: +86-13810702575 499 Email: zhangmingui@huawei.com 501 Xudong Zhang 502 Huawei Technologies 503 No. 156 Beiqing Rd. Haidian District 504 Beijing 100095 505 China 507 Email: zhangxudong@huawei.com 509 Donald E. Eastlake, 3rd 510 Huawei Technologies 511 155 Beaver Street 512 Milford, MA 01757 513 United States 515 Phone: +1-508-333-2270 516 EMail: d3e3e3@gmail.com 518 Radia Perlman 519 EMC 520 2010 256th Avenue NE, #200 521 Bellevue, WA 98007 522 United States 524 Email: radia@alum.mit.edu 526 Vishwas Manral 527 Ionos 528 4100 Moorpark Ave. 529 San Jose, CA 95117 530 United States 532 Email: vishwas@ionosnetworks.com 533 Somnath Chatterjee 534 Cisco Systems 535 SEZ Unit, Cessna Business Park 536 Outer Ring Road 537 Bangalore - 560087 538 India 540 Email: somnath.chatterjee01@gmail.com