idnits 2.17.00 (12 Aug 2021) /tmp/idnits24720/draft-ietf-ippm-ioam-ipv6-options-06.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 31, 2021) is 294 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-14 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-ioam-direct-export-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm S. Bhandari, Ed. 3 Internet-Draft Thoughtspot 4 Intended status: Standards Track F. Brockners, Ed. 5 Expires: February 1, 2022 Cisco 6 July 31, 2021 8 In-situ OAM IPv6 Options 9 draft-ietf-ippm-ioam-ipv6-options-06 11 Abstract 13 In-situ Operations, Administration, and Maintenance (IOAM) records 14 operational and telemetry information in the packet while the packet 15 traverses a path between two points in the network. This document 16 outlines how IOAM data fields are encapsulated in IPv6. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 1, 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 4. In-situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 4 58 5. IOAM Deployment In IPv6 Networks . . . . . . . . . . . . . . 7 59 5.1. Considerations for IOAM deployment in IPv6 networks . . . 7 60 5.2. IOAM domains bounded by hosts . . . . . . . . . . . . . . 8 61 5.3. IOAM domains bounded by network devices . . . . . . . . . 8 62 5.4. Deployment options . . . . . . . . . . . . . . . . . . . 8 63 5.4.1. IPv6-in-IPv6 encapsulation . . . . . . . . . . . . . 8 64 5.4.2. IP-in-IPv6 encapsulation with ULA . . . . . . . . . . 9 65 5.4.3. x-in-IPv6 Encapsulation that is used Independently . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 In-situ Operations, Administration, and Maintenance (IOAM) records 78 operational and telemetry information in the packet while the packet 79 traverses a path between two points in the network. This document 80 outlines how IOAM data fields are encapsulated in the IPv6 [RFC8200] 81 and discusses deployment options for networks that use 82 IPv6-encapsulated IOAM data fields. These options have distinct 83 deployment considerations; for example, the IOAM domain can either be 84 between hosts, or be between IOAM encapsulating and decapsulating 85 network nodes that forward traffic, such as routers. 87 2. Contributors 89 This document was the collective effort of several authors. The text 90 and content were contributed by the editors and the co-authors listed 91 below. The contact information of the co-authors appears at the end 92 of this document. 94 o Carlos Pignataro 96 o Hannes Gredler 97 o John Leddy 99 o Stephen Youell 101 o Tal Mizrahi 103 o Aviv Kfir 105 o Barak Gafni 107 o Petr Lapukhov 109 o Mickey Spiegel 111 o Suresh Krishnan 113 o Rajiv Asati 115 o Mark Smith 117 3. Conventions 119 3.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 3.2. Abbreviations 129 Abbreviations used in this document: 131 E2E: Edge-to-Edge 133 IOAM: In-situ Operations, Administration, and Maintenance 135 ION: IOAM Overlay Network 137 OAM: Operations, Administration, and Maintenance 139 POT: Proof of Transit 141 4. In-situ OAM Metadata Transport in IPv6 143 In-situ OAM in IPv6 is used to enhance diagnostics of IPv6 networks. 144 It complements other mechanisms designed to enhance diagnostics of 145 IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics 146 Destination Option described in [RFC8250]. 148 IOAM data fields can be encapsulated in "option data" fields using 149 two types of extension headers in IPv6 packets - either Hop-by-Hop 150 Options header or Destination options header. Deployments select one 151 of these extension header types depending on how IOAM is used, as 152 described in section 4 of [I-D.ietf-ippm-ioam-data]. Multiple 153 options with the same Option Type MAY appear in the same Hop-by-Hop 154 Options or Destination Options header, with distinct content. 156 In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly 157 enabled per interface on every node within the IOAM domain. Unless a 158 particular interface is explicitly enabled (i.e., explicitly 159 configured) for IOAM, a router MUST drop packets that contain 160 extension headers carrying IOAM data-fields. This is the default 161 behavior and is independent of whether the Hop-by-Hop options or 162 Destination options are used to encode the IOAM data. This ensures 163 that IOAM data does not unintentionally get forwarded outside the 164 IOAM domain. 166 An IPv6 packet carrying IOAM data in an Extension header can have 167 other extension headers, compliant with [RFC8200]. 169 IPv6 Hop-by-Hop and Destination Option format for carrying in-situ 170 OAM data fields: 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Option Type | Opt Data Len | Reserved | IOAM Type | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 175 | | | 176 . . I 177 . . O 178 . . A 179 . . M 180 . . . 181 . Option Data . O 182 . . P 183 . . T 184 . . I 185 . . O 186 . . N 187 | | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 190 Option Type: 8-bit option type identifier as defined inSection 7. 192 Opt Data Len: 8-bit unsigned integer. Length of this option, in 193 octets, not including the first 2 octets. 195 Reserved: 8-bit field MUST be set to zero upon transmission and 196 ignored upon reception. 198 IOAM Type: 8-bit field as defined in section 7.2 in 199 [I-D.ietf-ippm-ioam-data]. 201 Option Data: Variable-length field. Option-Type-specific data. 203 In-situ OAM Option-Types are inserted as Option data as follows: 205 1. Pre-allocated Trace Option: The in-situ OAM Preallocated Trace 206 Option-Type defined in [I-D.ietf-ippm-ioam-data] is represented 207 as an IPv6 option in the Hop-by-Hop extension header: 209 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 210 option. xxxxx=TBD. 212 IOAM Option-Type: IOAM Pre-allocated Trace Option-Type. 214 2. Incremental Trace Option: The in-situ OAM Incremental Trace 215 Option-Type defined in [I-D.ietf-ippm-ioam-data] is represented 216 as an IPv6 option in the Hop-by-Hop extension header: 218 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 219 option. xxxxx=TBD. 221 IOAM Option-Type: IOAM Incremental Trace Option-Type. 223 3. Proof of Transit Option: The in-situ OAM POT Option-Type defined 224 in [I-D.ietf-ippm-ioam-data] is represented as an IPv6 option in 225 the Hop-by-Hop extension header: 227 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 228 option. xxxxx=TBD. 230 IOAM Option-Type: IOAM POT Option-Type. 232 4. Edge to Edge Option: The in-situ OAM E2E option defined in 233 [I-D.ietf-ippm-ioam-data] is represented as an IPv6 option in 234 Destination extension header: 236 Option Type: 000xxxxx 8-bit identifier of the IOAM type of 237 option. xxxxx=TBD. 239 IOAM Option-Type: IOAM E2E Option-Type. 241 5. Direct Export (DEX) Option: The in-situ OAM Direct Export Option- 242 Type defined in [I-D.ietf-ippm-ioam-direct-export] is represented 243 as an IPv6 option in the Hop-by-Hop extension header: 245 Option Type: 000xxxxx 8-bit identifier of the IOAM type of 246 option. xxxxx=TBD. 248 IOAM Option-Type: IOAM Direct Export (DEX) Option-Type. 250 All the in-situ OAM IPv6 options defined here have alignment 251 requirements. Specifically, they all require 4n alignment. This 252 ensures that fields specified in [I-D.ietf-ippm-ioam-data] are 253 aligned at a multiple-of-4 offset from the start of the Hop-by-Hop 254 and Destination Options header. In addition, to maintain IPv6 255 extension header 8-octet alignment and avoid the need to add or 256 remove padding at every hop, the Trace-Type for Incremental Trace 257 Option in IPv6 MUST be selected such that the IOAM node data length 258 is a multiple of 8-octets. 260 IPv6 options can have a maximum length of 255 octets. Consequently, 261 the total lenght of IOAM Option-Types including all data fields is 262 also limited to 255 octets when encapsulated into IPv6. 264 5. IOAM Deployment In IPv6 Networks 266 5.1. Considerations for IOAM deployment in IPv6 networks 268 IOAM deployments in IPv6 networks should take the following 269 considerations and requirements into account: 271 C1 It is desirable that the addition of IOAM data fields neither 272 changes the way routers forward packets nor the forwarding 273 decisions the routers take. Packets with added OAM information 274 should follow the same path within the domain that an identical 275 packet without OAM information would follow, even in the presence 276 of ECMP. Such behavior is particularly important for deployments 277 where IOAM data fields are only added "on-demand", e.g., to 278 provide further insights in case of undesired network behavior for 279 certain flows. Implementations of IOAM SHOULD ensure that ECMP 280 behavior for packets with and without IOAM data fields is the 281 same. 283 C2 Given that IOAM data fields increase the total size of a packet, 284 the size of a packet including the IOAM data could exceed the 285 PMTU. In particular, the incremental trace IOAM Hop-by-Hop (HbH) 286 Option, which is intended to support hardware implementations of 287 IOAM, changes Option Data Length en-route. Operators of an IOAM 288 domain SHOULD ensure that the addition of OAM information does not 289 lead to fragmentation of the packet, e.g., by configuring the MTU 290 of transit routers and switches to a sufficiently high value. 291 Careful control of the MTU in a network is one of the reasons why 292 IOAM is considered a domain-specific feature (see also 293 [I-D.ietf-ippm-ioam-data]). In addition, the PMTU tolerance range 294 in the IOAM domain should be identified (e.g., through 295 configuration) and IOAM encapsulation operations and/or IOAM data 296 field insertion (in case of incremental tracing) should not be 297 performed if it exceeds the packet size beyond PMTU. 299 C3 Packets with IOAM data or associated ICMP errors, should not 300 arrive at destinations that have no knowledge of IOAM. For 301 exmample, if IOAM is used in in transit devices, misleading ICMP 302 errors due to addition and/or presence of OAM data in a packet 303 could confuse the host that sent the packet if it did not insert 304 the OAM information. 306 C4 OAM data leaks can affect the forwarding behavior and state of 307 network elements outside an IOAM domain. IOAM domains SHOULD 308 provide a mechanism to prevent data leaks or be able to ensure 309 that if a leak occurs, network elements outside the domain are not 310 affected (i.e., they continue to process other valid packets). 312 C5 The source that inserts and leaks the IOAM data needs to be easy 313 to identify for the purpose of troubleshooting, due to the high 314 complexity of troubleshooting a source that inserted the IOAM data 315 and did not remove it when the packet traversed across an 316 Autonomous System (AS). Such a troubleshooting process might 317 require coordination between multiple operators, complex 318 configuration verification, packet capture analysis, etc. 320 C6 Compliance with [RFC8200] requires OAM data to be encapsulated 321 instead of header/option insertion directly into in-flight packets 322 using the original IPv6 header. 324 5.2. IOAM domains bounded by hosts 326 For deployments where the IOAM domain is bounded by hosts, hosts will 327 perform the operation of IOAM data field encapsulation and 328 decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or 329 Destination options as specified in this document. 331 5.3. IOAM domains bounded by network devices 333 For deployments where the IOAM domain is bounded by network devices, 334 network devices such as routers form the edge of an IOAM domain. 335 Network devices will perform the operation of IOAM data field 336 encapsulation and decapsulation. 338 5.4. Deployment options 340 This section lists out possible deployment options that can be 341 employed to meet the requirements listed in Section 5.1. 343 5.4.1. IPv6-in-IPv6 encapsulation 345 The "IPv6-in-IPv6" approach preserves the original IP packet and add 346 an IPv6 header including IOAM data fields in an extension header in 347 front of it, to forward traffic within and across an IOAM domain. 348 The overlay network formed by the additional IPv6 header with the 349 IOAM data fields included in an extension header is referred to as 350 IOAM Overlay Network (ION) in this document. 352 The following steps should be taken to perform an IPv6-in-IPv6 353 approach: 355 1. The source address of the outer IPv6 header is that of the IOAM 356 encapsulating node. The destination address of the outer IPv6 357 header is the same as the inner IPv6 destination address, i.e., 358 the destination address of the packet does not change. 360 2. To simplify debugging in case of leaked IOAM data fields, 361 consider a new IOAM E2E destination option to identify the Source 362 IOAM domain (AS, v6 prefix). Insert this option into the IOAM 363 destination options EH attached to the outer IPv6 header. This 364 additional information would allow for easy identification of an 365 AS operator that is the source of packets with leaked IOAM 366 information. Note that leaked packets with IOAM data fields 367 would only occur in case a router would be misconfigured. 369 3. All the IOAM options are defined with type "00" - skip over this 370 option and continue processing the header. Presence of these 371 options must not cause packet drops in network elements that do 372 not understand the option. In addition, 373 [I-D.ietf-6man-hbh-header-handling] should be considered. 375 5.4.2. IP-in-IPv6 encapsulation with ULA 377 The "IP-in-IPv6 encapsulation with ULA" [RFC4193] approach can be 378 used to apply IOAM to either an IPv6 or an IPv4 network. In 379 addition, it fulfills requirement C4 (avoid leaks) by using ULA for 380 the ION. Similar to the IPv6-in-IPv6 encapsulation approach above, 381 the original IP packet is preserved. An IPv6 header including IOAM 382 data fields in an extension header is added in front of it, to 383 forward traffic within and across the IOAM domain. IPv6 addresses 384 for the ION, i.e. the outer IPv6 addresses are assigned from the ULA 385 space. Addressing and routing in the ION are to be configured so 386 that the IP-in-IPv6 encapsulated packets follow the same path as the 387 original, non-encapsulated packet would have taken. This would 388 create an internal IPv6 forwarding topology using the IOAM domain's 389 interior ULA address space which is parallel with the forwarding 390 topology that exists with the non-IOAM address space (the topology 391 and address space that would be followed by packets that do not have 392 supplemental IOAM information). Establishment and maintenance of the 393 parallel IOAM ULA forwarding topology could be automated, e.g., 394 similar to how LDP [RFC5036] is used in MPLS to establish and 395 maintain an LSP forwarding topology that is parallel to the network's 396 IGP forwarding topology. 398 Transit across the ION could leverage the transit approach for 399 traffic between BGP border routers, as described in [RFC1772], "A.2.3 400 Encapsulation". Assuming that the operational guidelines specified 401 in Section 4 of [RFC4193] are properly followed, the probability of 402 leaks in this approach will be almost close to zero. If the packets 403 do leak through IOAM egress device misconfiguration or partial IOAM 404 egress device failure, the packets' ULA destination address is 405 invalid outside of the IOAM domain. There is no exterior destination 406 to be reached, and the packets will be dropped when they encounter 407 either a router external to the IOAM domain that has a packet filter 408 that drops packets with ULA destinations, or a router that does not 409 have a default route. 411 5.4.3. x-in-IPv6 Encapsulation that is used Independently 413 In some cases it is desirable to monitor a domain that uses an 414 overlay network that is deployed independently of the need for IOAM, 415 e.g., an overlay network that runs Geneve-in-IPv6, or VXLAN-in-IPv6. 416 In this case IOAM can be encapsulated in as an extension header in 417 the tunnel (outer) IPv6 header. Thus, the tunnel encapsulating node 418 is also the IOAM encapsulating node, and the tunnel end point is also 419 the IOAM decapsulating node. 421 6. Security Considerations 423 This document describes the encapsulation of IOAM data fields in 424 IPv6. Security considerations of the specific IOAM data fields for 425 each case (i.e., Trace, Proof of Transit, and E2E) are described and 426 defined in [I-D.ietf-ippm-ioam-data]. 428 As this document describes new options for IPv6, these are similar to 429 the security considerations of [RFC8200] and the weakness documented 430 in [RFC8250]. 432 7. IANA Considerations 434 This draft requests the following IPv6 Option Type assignments from 435 the Destination Options and Hop-by-Hop Options sub-registry of 436 Internet Protocol Version 6 (IPv6) Parameters. 438 http://www.iana.org/assignments/ipv6-parameters/ipv6- 439 parameters.xhtml#ipv6-parameters-2 441 Hex Value Binary Value Description Reference 442 act chg rest 443 ---------------------------------------------------------------- 444 TBD_1_0 00 0 TBD_1 IOAM [This draft] 445 TBD_1_1 00 1 TBD_1 IOAM [This draft] 447 8. Acknowledgements 449 The authors would like to thank Tom Herbert, Eric Vyncke, Nalini 450 Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra 451 Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik 452 Nordmark, LJ Wobker, Mark Smith, Andrew Yourtchenko and Justin Iurman 453 for the comments and advice. For the IPv6 encapsulation, this 454 document leverages concepts described in 455 [I-D.kitamura-ipv6-record-route]. The authors would like to 456 acknowledge the work done by the author Hiroshi Kitamura and people 457 involved in writing it. 459 9. References 461 9.1. Normative References 463 [I-D.ietf-ippm-ioam-data] 464 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 465 for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in 466 progress), June 2021. 468 [I-D.ietf-ippm-ioam-direct-export] 469 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 470 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 471 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 472 export-05 (work in progress), July 2021. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 480 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 481 May 2017, . 483 9.2. Informative References 485 [I-D.ietf-6man-hbh-header-handling] 486 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 487 Extension Header", March 2016. 489 [I-D.kitamura-ipv6-record-route] 490 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 491 Option Extension", draft-kitamura-ipv6-record-route-00 492 (work in progress), November 2000. 494 [RFC1772] Rekhter, Y. and P. Gross, "Application of the Border 495 Gateway Protocol in the Internet", RFC 1772, 496 DOI 10.17487/RFC1772, March 1995, 497 . 499 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 500 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 501 . 503 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 504 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 505 October 2007, . 507 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 508 (IPv6) Specification", STD 86, RFC 8200, 509 DOI 10.17487/RFC8200, July 2017, 510 . 512 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 513 Performance and Diagnostic Metrics (PDM) Destination 514 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 515 . 517 Contributors' Addresses 519 Carlos Pignataro 520 Cisco Systems, Inc. 521 7200-11 Kit Creek Road 522 Research Triangle Park, NC 27709 523 United States 524 Email: cpignata@cisco.com 526 Hannes Gredler 527 RtBrick Inc. 528 Email: hannes@rtbrick.com 530 John Leddy 531 Email: john@leddy.net 533 Stephen Youell 534 JP Morgan Chase 535 25 Bank Street 536 London E14 5JP 537 United Kingdom 538 Email: stephen.youell@jpmorgan.com 540 Tal Mizrahi 541 Huawei Network.IO Innovation Lab 542 Israel 543 Email: tal.mizrahi.phd@gmail.com 544 Aviv Kfir 545 Mellanox Technologies, Inc. 546 350 Oakmead Parkway, Suite 100 547 Sunnyvale, CA 94085 548 U.S.A. 549 Email: avivk@mellanox.com 551 Barak Gafni 552 Mellanox Technologies, Inc. 553 350 Oakmead Parkway, Suite 100 554 Sunnyvale, CA 94085 555 U.S.A. 556 Email: gbarak@mellanox.com 558 Petr Lapukhov 559 Facebook 560 1 Hacker Way 561 Menlo Park, CA 94025 562 US 563 Email: petr@fb.com 565 Mickey Spiegel 566 Barefoot Networks, an Intel company 567 4750 Patrick Henry Drive 568 Santa Clara, CA 95054 569 US 570 Email: mickey.spiegel@intel.com 572 Suresh Krishnan 573 Kaloom 574 Email: suresh@kaloom.com 576 Rajiv Asati 577 Cisco Systems, Inc. 578 7200 Kit Creek Road 579 Research Triangle Park, NC 27709 580 US 581 Email: rajiva@cisco.com 583 Mark Smith 584 PO BOX 521 585 HEIDELBERG, VIC 3084 586 AU 587 Email: markzzzsmith+id@gmail.com 589 Authors' Addresses 591 Shwetha Bhandari (editor) 592 Thoughtspot 593 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 594 Bangalore, KARNATAKA 560 102 595 India 597 Email: shwetha.bhandari@thoughtspot.com 599 Frank Brockners (editor) 600 Cisco Systems, Inc. 601 Hansaallee 249, 3rd Floor 602 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 603 Germany 605 Email: fbrockne@cisco.com