idnits 2.17.1 draft-ietf-trill-oam-req-00.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 7, 2012) is 4304 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4377' is defined on line 584, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-opsawg-oam-overview-06 -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft CISCO 3 Intended status: Informational David Bond 4 IBM 5 Sam Aldrin 6 Yizhou Li 7 Huawei 8 Rohit Watve 9 CISCO 10 Anoop Ghanwani 11 DELL 12 Jon Hudson 13 Brocade 14 Naveen Nimmu 15 Broadcom 16 Radia Perlman 17 Intel 18 Tal Mizrahi 19 Marvell 21 July 7, 2012 22 Expires: January 2013 24 Requirements for Operations, Administration and Maintenance (OAM) in 25 TRILL 26 draft-ietf-trill-oam-req-00.txt 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on December 7, 2012. 50 Copyright Notice 52 Copyright (c) 2012 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 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Abstract 67 OAM (Operations, Administration and Maintenance) is a general term 68 used to identify functions and toolsets to troubleshoot and monitor 69 networks. This document presents, OAM Requirements applicable to 70 TRILL. Also presented in this document is the proposed frame 71 structure for TRILL OAM messages. 73 Table of Contents 75 1. Introduction...................................................3 76 1.1. Contributors..............................................3 77 2. Conventions used in this document..............................4 78 3. Terminology....................................................4 79 4. OAM Requirements...............................................5 80 4.1. Data Plane................................................5 81 4.2. Connectivity Verification.................................5 82 4.2.1. Unicast..............................................5 83 4.2.2. Multicast............................................6 84 4.3. Continuity Check..........................................6 85 4.4. Path Tracing..............................................7 86 4.5. General Requirements......................................7 87 4.6. Performance Monitoring....................................8 88 4.6.1. Packet Loss..........................................8 89 4.6.2. Packet Delay.........................................8 90 4.7. ECMP Utilization..........................................9 91 4.8. Security and Operational considerations...................9 92 4.9. Fault Indications.........................................9 93 4.10. Defect Indications......................................10 94 4.11. Live Traffic monitoring.................................10 95 5. General Format of TRILL OAM Messages..........................10 96 5.1. Requirements of OAM Message channel......................12 97 6. Security Considerations.......................................12 98 7. IANA Considerations...........................................12 99 8. References....................................................12 100 8.1. Normative References.....................................12 101 8.2. Informative References...................................13 102 9. Acknowledgments...............................................13 104 1. Introduction 106 OAM (Operations, Administration and Maintenance) generally covers 107 various production aspects of a network. In this document we use the 108 term OAM as defined in [RFC6291]. 110 Success of any mission critical network depends on the ability to 111 proactively monitor networks for faults, performance, etc. as well 112 as its ability to efficiently and quickly troubleshoot defects and 113 failures. A well-defined OAM toolset is a vital requirement for 114 wider adoption of TRILL as the next generation data forwarding 115 technology in larger networks such as data centers. 117 In this document we define the Requirements for TRILL OAM. Also the 118 proposed format for OAM frames is presented. 120 It is assumed that the readers are familiar with the OAM concepts 121 and terminologies defined in other OAM standards such as [8021ag], 122 [RFC5860]. This document does not attempt to redefine the terms and 123 concepts specified elsewhere. 125 1.1. Contributors 127 The following members were part of the design team that produced 128 this document. Their names are listed below in alphabetical order. 130 Anoop Ghanwani, David Bond, Donald Eastlake, Jon Hudson, Naveen 131 Nimmu, Radia Perlman, Rohit Watve, Sam Aldrin, Shivakumar Sundaram, 132 Tal Mizrahi, Thomas Narten, Tissa Senevirathne, Yizhou Li. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC-2119 [RFC2119]. 139 Although this document is not a protocol specification, the use of 140 this language clarifies the instructions to protocol designers 141 producing solutions that satisfy the requirements set out in this 142 document. 144 3. Terminology 146 Section: The term Section refers to a partial segment of a path 147 between any two given RBridges. As an example, consider the case 148 where RB1 is connected to RBx via RB2,RB3 and RB4. The segment 149 between RB2 to RB4 is referred to as a Section of the path RB1 to 150 RBx. 152 Flow: The term Flow indicates a set of packets that share the same 153 path and per-hop behavior (such as priority). A flow is typically 154 identified by a portion of the inner payload that affects the hop-by 155 hop forwarding decisions. This may contain Layer 2 through Layer 4 156 information. 158 All Least Cost Paths: The term "all least cost paths" refers to all 159 potentially available least cost paths from a given source to a 160 specified destination RBridge as determined by the TRILL network 161 topology learned from IS-IS. ECMP: Equal Cost Multi Path. 163 Connectivity: The term connectivity indicates reachability between 164 an arbitrary RBridge RB1 and any other RBridge RB2. The specific 165 path can be either explicit (e.g. specific flow) or unspecified. 166 Unspecified means taking whatever the path connectivity verification 167 message happen to take. 169 Continuity Verification: Continuity Verification refers to proactive 170 verification of Connectivity between two RBridges at periodic 171 intervals and generation of explicit notification when Connectivity 172 failures occur. 174 Fault: The term Fault refers to an inability to perform a required 175 action, e.g., an unsuccessful attempt to deliver a packet. 177 Defect: The term Defect refers to an interruption in the normal 178 operation, such that over a period of time no packets are delivered 179 successfully. 181 Failure: The term Failure refers to the termination of the required 182 function over a longer period of time. Persistence of a defect for a 183 period of time is interpreted as a failure. 185 4. OAM Requirements 187 4.1. Data Plane 189 OAM frames, utilized for connectivity verification, continuity 190 checks, performance measurements, etc., MUST follow the same path as 191 the specified flow. 193 OAM frames, utilized for connectivity verification, continuity 194 checks, performance measurements, etc., when a specific flow is not 195 specified MUST follow whatever the path TRILL choose based on 196 current topology, per-hop forwarding behavior and default flow 197 entropy. 199 RBridges MUST have the ability to identify OAM frames destined for 200 them or which require processing by the OAM plane from normal data 201 frames. 203 RBridges MUST have the ability to differentiate between OAM frames 204 and data frames experiencing errors. 206 TRILL OAM frames MUST be confined to the TRILL domain and MUST NOT 207 be forwarded out of the TRILL domain. E.g. they must not be sent as 208 native frames on an end station service enabled port 210 OAM MUST have the capability to provide services for both IP and 211 non-IP flows. 213 OAM MUST be able to function in IP and non-IP infrastructure. 215 4.2. Connectivity Verification 217 4.2.1. Unicast 219 OAM MUST have the ability to verify connectivity from an arbitrary 220 RBridge RB1 to any other RBridge RB2. 222 OAM MUST have the ability to verify connectivity from an arbitrary 223 RBridge RB1 to any other RBridge RB2 for a specific flow. 225 An RBridge SHOULD have the ability to verify the above connectivity 226 tests on sections. As an example, assume RB1 is connected to RB5 via 227 RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to 228 RB5 connectivity on the section from RB3 to RB5. The difference is 229 that the ingress and egress TRILL nicknames in this case are RB1 and 230 RB5 as opposed to RB3 and RB5, even though the message itself may 231 originate at RB3. 233 OAM MUST have the ability to invoke the above functions on-demand. 235 4.2.2. Multicast 237 OAM MUST have the ability to verify connectivity, from an arbitrary 238 RBridge RB1, to either to a specific set of RBridges or all member 239 RBridges, for a specified multicast tree. This functionality is 240 referred to as verification of the un-pruned multicast tree. 242 OAM MUST have the ability to verify connectivity, from an arbitrary 243 RBridge RB1, to either to a specific set of RBridges or all member 244 RBridges, for a specified multicast tree and for a specified flow. 245 This functionality is referred to as verification of the pruned 246 tree. 248 OAM MUST have the ability to invoke the above functions on-demand. 250 4.3. Continuity Check 252 [RFC5860] defines Continuity Check as the ability of end points to 253 monitor liveliness of a path or a section of a path [RFC5860]. We 254 use similar semantics in this document where end points are the 255 ingress or egress RBridges. 257 OAM MUST provide functions that allow any arbitrary RBridge RB1 to 258 perform a Continuity Check to any other RBridge. 260 OAM MUST provide functions that allow any arbitrary RBridge RB1 to 261 perform a Continuity Check to any other RBridge for a specified 262 flow. 264 OAM SHOULD provide functions that allow any arbitrary RBridge to 265 perform a Continuity Check to any other RBridge over all available 266 least cost paths. 268 OAM SHOULD provide the ability to perform a Continuity Check on 269 sections of any path within the network. 271 OAM SHOULD provide the ability to perform a multicast Continuity 272 Check for specified multi-destination tree(s) as well as specified 273 multi-destination tree and flow combinations. The former is referred 274 to as an un-pruned multi-destination tree Continuity Check and the 275 latter is referred to as a pruned tree Continuity Check. 277 OAM implementations SHOULD support at least a minimum frequency of 1 278 second of Continuity check. 280 OAM implementations SHOULD support multiple concurrent Continuity 281 sessions from and/or to the same RBridge. 283 4.4. Path Tracing 285 OAM MUST provide the ability to trace a path between any two 286 RBridges per specified unicast flow. 288 OAM SHOULD provide the ability to trace all least cost paths between 289 any two RBridges. 291 OAM SHOULD provide functionality to trace all branches of a 292 specified multi-destination tree (un-pruned tree) 294 OAM SHOULD provide functionality to trace all branches of a 295 specified multi-destination tree for a specified flow (pruned tree). 297 4.5. General Requirements 299 OAM MUST provide the ability to initiate and maintain multiple 300 concurrent sessions for multiple OAM functions between any arbitrary 301 RBridge RB1 to any other RBridge. 303 OAM MUST NOT require extensions to or modifications of the TRILL 304 header. 306 OAM MUST provide a single OAM framework for all TRILL OAM functions 308 OAM, as practical and as possible, SHOULD provide a single framework 309 between TRILL and other similar standards. 311 OAM MUST maintain related error and operational counters. SUCH 312 counters MUST be accessible via network management applications 313 (e.g. SNMP). 315 Operations of OAM MUST NOT result in errors on end devices. 317 OAM MAY be required to provide the ability to specify a desired 318 response mode for a specific OAM message. The desired response mode 319 can be either in-band, out-of band or none. 321 The OAM Framework MUST be extensible to future needs of TRILL and 322 the needs of other standard organizations. 324 OAM MAY provide methods to verify control plane and forwarding plane 325 alignments. 327 OAM SHOULD leverage existing OAM technologies, where practical. 329 4.6. Performance Monitoring 331 4.6.1. Packet Loss 333 In this document, term loss of a packet is used as defined in 334 [RFC2680] (see Section 2.4 of RFC2680). 336 NOTE: Term simulated flow below indicates a flow that is generated 337 by an RBRidge RB1 for OAM purposes. The fields of the simulated flow 338 may or may not be identical to the actual data. However, simulated 339 flow is required to follow the intended path. 341 OAM SHOULD provide the ability to measure packet loss statistics for 342 a simulated flow from any arbitrary RBridge RB1 to any other 343 RBridge. 345 OAM SHOULD provide the ability to measure packet loss statistics 346 over a segment, for a simulated flow between any arbitrary RBridge 347 RB1 to any other RBridge. 349 OAM SHOULD provide the ability to measure simulated packet loss 350 statistics between any two RBridges over all least cost paths. 352 An RBridge SHOULD be able to perform the above packet loss 353 measurement functions either proactively or on-demand. 355 4.6.2. Packet Delay 357 There are two types of packet delays -- one-way delay and two-way 358 delay (Round Trip Delay). 360 One-way delay is defined in [RFC2679] as the time elapsed from the 361 start of transmission of the first bit of a packet by an RBridge 362 until the reception of the last bit of the packet by the destination 363 RBridge. 365 Two-way delay is also referred to as Round Trip Delay is defined 366 similar to [RFC2681]; i.e. the time elapsed from the start of 367 transmission of the first bit of a packet by an RBridge until the 368 reception of the last bit of the packet by the same RBridge. 370 OAM SHOULD provide functions to measure two-way delay between two 371 RBridges for a specified flow. 373 OAM SHOULD provide functions to measure two-way delay between two 374 RBridges for a specified flow over a specific section. 376 OAM MAY provide functions to measure one-way delay between two 377 RBridges for a specified flow. 379 OAM MAY provide functions to measure one-way delay between two 380 RBridges for a specified flow over a specific section. 382 4.7. ECMP Utilization 384 OAM MAY provide functionality to monitor the effectiveness of per- 385 hop ECMP hashing. For example, individual RBridges could maintain 386 counters that show how packets are being distributed across equal 387 cost next hops for a specified destination RBridge or RBridges as a 388 result of ECMP hashing. 390 4.8. Security and Operational considerations 392 Methods MUST be provided to protect against exploitation of OAM 393 framework for security and denial of service attacks. 395 Methods SHOULD be provided to prevent OAM messages causing 396 congestion in the networks. Periodically generated messages with 397 high frequencies may lead to congestion, hence methods such as 398 shaping or rate limiting SHOULD be utilized. 400 4.9. Fault Indications 402 The term Fault refers to an inability to perform a required action, 403 e.g., an unsuccessful attempt to deliver a packet [OAMOVER]. The 404 unsuccessful attempt may be due to Hop Count expiry, invalid 405 nickname, etc. 407 OAM MUST provide a Fault Indication framework to notify faults to 408 the ingress RBRidge of the flow or other interested parties (such as 409 syslog servers). 411 OAM MUST provide functions to selectively enable or disable 412 different types of Fault Indications. 414 4.10. Defect Indications 416 [OAMOVER] defines "The term Defect refers to an interruption in the 417 normal operation, such as a consecutive period of time where no 418 packets are delivered successfully." 420 OAM SHOULD provide a framework for Defect Detection and Indication. 422 OAM implementations that provide Defect Indication MUST provide 423 methods to selectively enable or disable Defect Detection per defect 424 type. 426 OAM implementations that provide Defect Indication MUST provide 427 methods to configure Defect Detection thresholds per different types 428 of defects. 430 OAM implementations that provide Defect Indication facilities MUST 431 provide methods to log defect indications to a locally defined 432 archive such as log buffer or SNMP traps. 434 OAM implementations that provide Defect Indication facilities SHOULD 435 provide a Remote Defect Indication framework that facilitates 436 notifying the originator/owner of the flow experiencing the defect, 437 which is the ingress RBridge. 439 Remote Defect Indication MAY be either in-band or out-of-band. 441 4.11. Live Traffic monitoring 443 OAM implementations MAY provide methods to utilize live traffic for 444 troubleshooting and performance monitoring. 446 Implementations MAY leverage Data Driven CFM [8021Q] or IPFIX 447 [RFC5101] for the purpose of performance monitoring. 449 5. General Format of TRILL OAM Messages 451 The TRILL forwarding paradigm allows an implementation to select a 452 path from a set of equal cost paths to forward a packet. Selection 453 of the path of choice is implementation dependent. However, it is a 454 common practice to utilize Layer 2 through Layer 4 information in 455 the inner payload for path selection. 457 As specified above, OAM Messages are required to follow the exact 458 path as the data packets. 460 The proposed frame format for TRILL OAM messages is as follows. 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 . Outer Header . (variable) 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 + TRILL Header + 8 bytes 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 . Flow Entropy . 128 bytes 473 . . 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 . OAM Message Channel . Variable 478 . . 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 1 Frame format of OAM Messages 484 Outer Header: Media dependent header. For Ethernet this included 485 Destination MAC, Source MAC, VLAN (optional) and EtherType fields. 487 TRILL Header: Minimum of 8 bytes when the Extended Header is not 488 included [RFC6325] 490 Flow Entropy: This is a 128 byte Fixed size opaque field. The field 491 MUST be padded with zeros when the flow entropy is less than 128 492 bytes. Flow entropy emulates the forwarding behavior of the desired 493 data packets. 495 OAM Message Channel: This is a variable size section that carries 496 OAM related information. Reusing existing OAM message definitions 497 such as [RFC4379] and [8021ag] will be explored. 499 5.1. Requirements of OAM Message channel 501 The OAM Message channel header MUST contain a version number 503 The OAM Message channel header MUST contain flags that facilitate 504 hardware level processing. (e.g. indicate this is two-way delay 505 measurement probe) 507 The OAM Message channel MUST contain time stamping in fixed 508 locations to facilitate hardware level performance monitoring. (e.g. 509 delay measurements). 511 The OAM Message channel MUST have the ability to be extensible to 512 include future capabilities without requiring a change to the 513 version of the message header. (e.g. include TLV structures) 515 The OAM Message header MUST contain a unique marker that allows for 516 identifying the presence of the OAM channel. This marker MUST 517 provide equal or better uniqueness compared to the IP checksum 518 define in [RFC791] 520 The OAM Message SHOULD provide methods to include arbitrary data to 521 test functions such as MTU testing. 523 6. Security Considerations 525 Security Requirements are specified in section 4.8. 527 7. IANA Considerations 529 531 8. References 533 8.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [OAMOVER] Mizrahi, T, et.al., "An Overview of Operations, 539 Administration, and Maintenance (OAM) Mechanisms", draft- 540 ietf-opsawg-oam-overview-06, Work in Progress, March 2012. 542 [RFC5860] Vigoureux, M., et.al., "Requirements for Operations, 543 Administration and Maintenance (OAM) in MPLS Transport 544 Networks", RFC5860, May 2010. 546 [RFC4377] Nadeau, T., et.al., "Operations and Management (OAM) 547 Requirements for Multi-Protocol Label Switched (MPLS) 548 Networks", RFC 4377, February 2006. 550 8.2. Informative References 552 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 553 Protocol Specification", RFC 6325, July 2011. 555 [RFC5101] Claise, B., "Specification of the IP Flow Information 556 Export (IPFIX) Protocol for the Exchange of IP Traffic 557 Flow Information", RFC5101, January 2008. 559 [RFC2680] Almes, G., et.al. "A One-way Packet Loss Metric for IPPM", 560 RFC 2680, September 1999. 562 [RFC2679] Almes, G., et.al. "A One-way Delay Metric for IPPM", RFC 563 2679, September 1999. 565 [RFC2681] Almes, G., et.al. "A Round-trip Delay Metric for IPPM", 566 RFC 2681, September 1999. 568 [RFC6291] Anderson, L., et.al. "Guidelines for the Use of the "OAM" 569 Acronym in the IETF", RFC 6291, June 2011. 571 [8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: 572 Connectivity Fault Management", 802.1ag, 2007. 574 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 575 Bridged Local Area Networks", IEEE Std 802.1Q-2011, 576 August, 2011. 578 [RFC791] "Internet Protocol", RFC 791, September 1981. 580 [RFC4379] Kompela, K., et.al. "Detecting Multi-protocol Label 581 Switched (MPLS) Data Plane Failures", RFC 4379, February 582 2006. 584 [RFC4377] Nadeau, T., et.al. "Operations and Management (OAM) 585 Requirements for Multi-protocol Label Switched 586 (MPLS)Networks", RFC 4377, February 2006. 588 9. Acknowledgments 590 Special acknowledgments to IEEE 802.1 chair, Tony Jeffree for 591 allowing us to solicit comments from IEEE 802.1 group. Also 592 recognized are the comments received from IEEE group, Ayal Loir and 593 others. 595 This document was prepared using 2-Word-v2.0.template.dot. 597 Authors' Addresses 599 Tissa Senevirathne 600 CISCO Systems 601 375 East Tasman Drive 602 San Jose, CA 95134 603 USA. 605 Phone: +1-408-853-2291 606 Email: tsenevir@cisco.com 608 David Bond 609 IBM 610 2051 Mission College Blvd 611 Santa Clara, CA 95054 612 USA 614 Phone: +1-603-339-7575 615 Email: mokon@mokon.net 617 Sam Aldrin 618 Huawei Technologies 619 2330 Central Express Way 620 Santa Clara, CA 95951 621 USA 623 Email: aldrin.ietf@gmail.com 624 Yizhou Li 625 Huawei Technologies 626 101 Software Avenue, 627 Nanjing 210012 628 China 630 Phone: +86-25-56625375 631 Email: liyizhou@huawei.com 633 Rohit Watve 634 CISCO Systems 635 375 East Tasman Drive 636 San Jose, CA 95134 637 USA. 639 Phone: +1-408-424-2091 640 Email: rwatve@cisco.com 642 Anoop Ghanwani 643 DELL 644 350 Holger Way 645 San Jose, CA 95134 646 USA. 648 Phone: +1-408-571-3500 649 Email: Anoop@duke.alumni.duke.edu 651 John Hudson 652 Brocade 653 120 Holger Way 654 San Jose, CA 95134 655 USA. 657 Email: jon.hudson@gmail.com 659 Naveen Nimmu 660 Broadcom 661 9th Floor, Building no 9, Raheja Mind space 662 Hi-Tec City, Madhapur, 663 Hyderabad - 500 081, INDIA 665 Phone: +1-408-218-8893 666 Email: naveen@broadcom.com 667 Radia Perlman 668 Intel Labs 669 2700 156th Ave NE, Suite 300, 670 Bellevue, WA 98007 671 USA. 673 Phone: +1-425-881-4824 674 Email: radia.perlman@intel.com 676 Tal Mizrahi 677 Marvell 678 6 Hamada St. 679 Yokneam, 20692 Israel 681 Email: talmi@marvell.com