idnits 2.17.1 draft-tissa-trill-oam-req-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 -- The document date (June 29, 2012) is 4318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4379' is mentioned on line 494, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'RFC4377' is defined on line 543, but no explicit reference was found in the text == Unused Reference: '8021ag' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '8021Q' is defined on line 571, 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) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 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 June 29, 2012 22 Expires: December 2012 24 Requirements for Operations, Administration and Maintenance (OAM) in 25 TRILL 26 draft-tissa-trill-oam-req-02.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 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on December 29, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. 63 Abstract 65 OAM (Operations, Administration and Maintenance) is a general term 66 used to identify functions and toolsets to troubleshoot and monitor 67 networks. This document presents, OAM Requirements applicable to 68 TRILL. Also presented in this document is the proposed frame 69 structure for TRILL OAM messages. 71 Table of Contents 73 1. Introduction...................................................3 74 1.1. Contributors..............................................4 75 2. Conventions used in this document..............................4 76 3. Terminology....................................................4 77 4. OAM Requirements...............................................5 78 4.1. Data Plane................................................5 79 4.2. Connectivity Verification.................................6 80 4.2.1. Unicast..............................................6 81 4.2.2. Multicast............................................6 82 4.3. Continuity Check..........................................6 83 4.4. Path Tracing..............................................7 84 4.5. General Requirements......................................7 85 4.6. Performance Monitoring....................................8 86 4.6.1. Packet Loss..........................................8 87 4.6.2. Packet Delay.........................................9 88 4.7. ECMP Utilization..........................................9 89 4.8. Security and Operational considerations...................9 90 4.9. Fault Indications........................................10 91 4.10. Defect Indications......................................10 92 4.11. Live Traffic monitoring.................................11 93 5. General Format of TRILL OAM Messages..........................11 94 5.1. Requirements of OAM Message channel......................12 95 6. Security Considerations.......................................12 96 7. IANA Considerations...........................................12 97 8. References....................................................13 98 8.1. Normative References.....................................13 99 8.2. Informative References...................................13 100 9. Acknowledgments...............................................14 102 1. Introduction 104 OAM (Operations, Administration and Maintenance) generally covers 105 various production aspects of a network. In this document we use the 106 term OAM as defined in [RFC6291]. 108 Success of any mission critical network depends on the ability to 109 proactively monitor networks for faults, performance, etc. as well 110 as its ability to efficiently and quickly troubleshoot defects and 111 failures. A well-defined OAM toolset is a vital requirement for 112 wider adoption of TRILL as the next generation data forwarding 113 technology in larger networks such as data centers. 115 In this document we define the Requirements for TRILL OAM. Also the 116 proposed format for OAM frames is presented. 118 It is assumed that the readers are familiar with the OAM concepts 119 and terminologies defined in other OAM standards such as [802.1ag], 120 [RFC5860]. This document does not attempt to redefine the terms and 121 concepts specified elsewhere. 123 1.1. Contributors 125 The following members were part of the design team that produced 126 this document. Their names are listed below in alphabetical order. 127 Anoop Ghanwani, David Bond, Donald Eastlake 3rd, Jon Hudson, Naveen 128 Nimmu, Radia Perlman, Rohit Watve, Sam Aldrin, Shivakumar Sundaram, 129 Tal Mizrahi, Thomas Narten, Tissa Senevirathne, Yizhou Li. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC-2119 [RFC2119]. 136 Although this document is not a protocol specification, the use of 137 this language clarifies the instructions to protocol designers 138 producing solutions that satisfy the requirements set out in this 139 document. 141 3. Terminology 143 Section: The term Section refers to a partial segment of a path 144 between any two given RBridges. As an example, consider the case 145 where RB1 is connected to RBx via RB2,RB3 and RB4. The segment 146 between RB2 to RB4 is referred to as a Section of the path RB1 to 147 RBx. 149 Flow: The term Flow indicates a set of packets that share the same 150 path and per-hop behavior (such as priority). A flow is typically 151 identified by a portion of the inner payload that affects the hop-by 152 hop forwarding decisions. This may contain Layer 2 through Layer 4 153 information. 155 All Least Cost Paths: The term "all least cost paths" refers to all 156 potentially available least cost paths from a given source to a 157 specified destination RBridge as determined by the TRILL network 158 topology learned from IS-IS. ECMP: Equal Cost Multi Path. 160 Connectivity: The term connectivity indicates reachability between 161 an arbitrary RBridge RB1 and any other RBridge RB2. The specific 162 path can be either explicit (e.g. specific flow) or unspecified. 163 Unspecified means taking whatever the path connectivity verification 164 message happen to take. 166 Continuity Verification: Continuity Verification refers to proactive 167 verification of Connectivity between two RBridges at periodic 168 intervals and generation of explicit notification when Connectivity 169 failures occur. 171 Fault: The term Fault refers to an inability to perform a required 172 action, e.g., an unsuccessful attempt to deliver a packet. 174 Defect: The term Defect refers to an interruption in the normal 175 operation, such that over a period of time no packets are delivered 176 successfully. 178 Failure: The term Failure refers to the termination of the required 179 function over a longer period of time. Persistence of a defect for a 180 period of time is interpreted as a failure. 182 4. OAM Requirements 184 4.1. Data Plane 186 OAM frames, utilized for connectivity verification, continuity 187 checks, performance measurements, etc., MUST follow the same path as 188 the specified flow. 190 OAM frames, utilized for connectivity verification, continuity 191 checks, performance measurements, etc., when a specific flow is not 192 specified MUST follow whatever the path TRILL choose based on 193 current topology, per-hop forwarding behavior and default flow 194 entropy. 196 RBridges MUST have the ability to identify OAM frames destined for 197 them or which require processing by the OAM plane from normal data 198 frames. 200 RBridges MUST have the ability to differentiate between OAM frames 201 and data frames experiencing errors. 203 TRILL OAM frames MUST be confined to the TRILL domain and MUST NOT 204 be forwarded out of the TRILL domain. E.g. they must not be sent as 205 native frames on an end station service enabled port 207 OAM MUST have the capability to provide services for both IP and 208 non-IP flows. 210 OAM MUST be able to function in IP and non-IP infrastructure. 212 4.2. Connectivity Verification 214 4.2.1. Unicast 216 OAM MUST have the ability to verify connectivity from an arbitrary 217 RBridge RB1 to any other RBridge RB2. 219 OAM MUST have the ability to verify connectivity from an arbitrary 220 RBridge RB1 to any other RBridge RB2 for a specific flow. 222 An RBridge SHOULD have the ability to verify the above connectivity 223 tests on sections. As an example, assume RB1 is connected to RB5 via 224 RB2, RB3 and RB4. An operator SHOULD be able to verify the RB1 to 225 RB5 connectivity on the section from RB3 to RB5. The difference is 226 that the ingress and egress TRILL nicknames in this case are RB1 and 227 RB5 as opposed to RB3 and RB5, even though the message itself may 228 originate at RB3. 230 OAM MUST have the ability to invoke the above functions on-demand. 232 4.2.2. Multicast 234 OAM MUST have the ability to verify connectivity, from an arbitrary 235 RBridge RB1, to either to a specific set of RBridges or all member 236 RBridges, for a specified multicast tree. This functionality is 237 referred to as verification of the un-pruned multicast tree. 239 OAM MUST have the ability to verify connectivity, from an arbitrary 240 RBridge RB1, to either to a specific set of RBridges or all member 241 RBridges, for a specified multicast tree and for a specified flow. 242 This functionality is referred to as verification of the pruned 243 tree. 245 OAM MUST have the ability to invoke the above functions on-demand. 247 4.3. Continuity Check 249 [RFC5860] defines Continuity Check as the ability of end points to 250 monitor liveliness of a path or a section of a path [RFC5860]. We 251 use similar semantics in this document where end points are the 252 ingress or egress RBridges. 254 OAM MUST provide functions that allow any arbitrary RBridge RB1 to 255 perform a Continuity Check to any other RBridge. 257 OAM MUST provide functions that allow any arbitrary RBridge RB1 to 258 perform a Continuity Check to any other RBridge for a specified 259 flow. 261 OAM SHOULD provide functions that allow any arbitrary RBridge to 262 perform a Continuity Check to any other RBridge over all available 263 least cost paths. 265 OAM SHOULD provide the ability to perform a Continuity Check on 266 sections of any path within the network. 268 OAM SHOULD provide the ability to perform a multicast Continuity 269 Check for specified multi-destination tree(s) as well as specified 270 multi-destination tree and flow combinations. The former is referred 271 to as an un-pruned multi-destination tree Continuity Check and the 272 latter is referred to as a pruned tree Continuity Check. 274 OAM implementations SHOULD support at least a minimum frequency of 1 275 second of Continuity check. 277 OAM implementations SHOULD support multiple concurrent Continuity 278 sessions from and/or to the same RBridge. 280 4.4. Path Tracing 282 OAM MUST provide the ability to trace a path between any two 283 RBridges per specified unicast flow. 285 OAM SHOULD provide the ability to trace all least cost paths between 286 any two RBridges. 288 OAM SHOULD provide functionality to trace all branches of a 289 specified multi-destination tree (un-pruned tree) 291 OAM SHOULD provide functionality to trace all branches of a 292 specified multi-destination tree for a specified flow (pruned tree). 294 4.5. General Requirements 296 OAM MUST provide the ability to initiate and maintain multiple 297 concurrent sessions for multiple OAM functions between any arbitrary 298 RBridge RB1 to any other RBridge. 300 OAM MUST NOT require extensions to or modifications of the TRILL 301 header. 303 OAM MUST provide a single OAM framework for all TRILL OAM functions 305 OAM, as practical and as possible, SHOULD provide a single framework 306 between TRILL and other similar standards. 308 OAM MUST maintain related error and operational counters. SUCH 309 counters MUST be accessible via network management applications 310 (e.g. SNMP). 312 Operations of OAM MUST NOT result in errors on end devices. 314 OAM MAY be required to provide the ability to specify a desired 315 response mode for a specific OAM message. The desired response mode 316 can be either in-band, out-of band or none. 318 The OAM Framework MUST be extensible to future needs of TRILL and 319 the needs of other standard organizations. 321 OAM MAY provide methods to verify control plane and forwarding plane 322 alignments. 324 OAM SHOULD leverage existing OAM technologies, where practical. 326 4.6. Performance Monitoring 328 4.6.1. Packet Loss 330 In this document, term loss of a packet is used as defined in 331 [RFC2680] (see Section 2.4 of RFC2680). 333 NOTE: Term simulated flow below indicates a flow that is generated 334 by an RBRidge RB1 for OAM purposes. The fields of the simulated flow 335 may or may not be identical to the actual data. However, simulated 336 flow is required to follow the intended path. 338 OAM SHOULD provide the ability to measure packet loss statistics for 339 a simulated flow from any arbitrary RBridge RB1 to any other 340 RBridge. 342 OAM SHOULD provide the ability to measure packet loss statistics 343 over a segment, for a simulated flow between any arbitrary RBridge 344 RB1 to any other RBridge. 346 OAM SHOULD provide the ability to measure simulated packet loss 347 statistics between any two RBridges over all least cost paths. 349 An RBridge SHOULD be able to perform the above packet loss 350 measurement functions either proactively or on-demand. 352 4.6.2. Packet Delay 354 There are two types of packet delays -- one-way delay and two-way 355 delay (Round Trip Delay). 357 One-way delay is defined in [RFC2679] as the time elapsed from the 358 start of transmission of the first bit of a packet by an RBridge 359 until the reception of the last bit of the packet by the destination 360 RBridge. 362 Two-way delay is also referred to as Round Trip Delay is defined 363 similar to [RFC2681]; i.e. the time elapsed from the start of 364 transmission of the first bit of a packet by an RBridge until the 365 reception of the last bit of the packet by the same RBridge. 367 OAM SHOULD provide functions to measure two-way delay between two 368 RBridges for a specified flow. 370 OAM SHOULD provide functions to measure two-way delay between two 371 RBridges for a specified flow over a specific section. 373 OAM MAY provide functions to measure one-way delay between two 374 RBridges for a specified flow. 376 OAM MAY provide functions to measure one-way delay between two 377 RBridges for a specified flow over a specific section. 379 4.7. ECMP Utilization 381 OAM MAY provide functionality to monitor the effectiveness of per- 382 hop ECMP hashing. For example, individual RBridges could maintain 383 counters that show how packets are being distributed across equal 384 cost next hops for a specified destination RBridge or RBridges as a 385 result of ECMP hashing. 387 4.8. Security and Operational considerations 389 Methods MUST be provided to protect against exploitation of OAM 390 framework for security and denial of service attacks. 392 Methods SHOULD be provided to prevent OAM messages causing 393 congestion in the networks. Periodically generated messages with 394 high frequencies may lead to congestion, hence methods such as 395 shaping or rate limiting SHOULD be utilized. 397 4.9. Fault Indications 399 The term Fault refers to an inability to perform a required action, 400 e.g., an unsuccessful attempt to deliver a packet [OAMOVER]. The 401 unsuccessful attempt may be due to Hop Count expiry, invalid 402 nickname, etc. 404 OAM MUST provide a Fault Indication framework to notify faults to 405 the ingress RBRidge of the flow or other interested parties (such as 406 syslog servers). 408 OAM MUST provide functions to selectively enable or disable 409 different types of Fault Indications. 411 4.10. Defect Indications 413 [OAMOVER] defines "The term Defect refers to an interruption in the 414 normal operation, such as a consecutive period of time where no 415 packets are delivered successfully." 417 OAM SHOULD provide a framework for Defect Detection and Indication. 419 OAM implementations that provide Defect Indication MUST provide 420 methods to selectively enable or disable Defect Detection per defect 421 type. 423 OAM implementations that provide Defect Indication MUST provide 424 methods to configure Defect Detection thresholds per different types 425 of defects. 427 OAM implementations that provide Defect Indication facilities MUST 428 provide methods to log defect indications to a locally defined 429 archive such as log buffer or SNMP traps. 431 OAM implementations that provide Defect Indication facilities SHOULD 432 provide a Remote Defect Indication framework that facilitates 433 notifying the originator/owner of the flow experiencing the defect, 434 which is the ingress RBridge. 436 Remote Defect Indication MAY be either in-band or out-of-band. 438 4.11. Live Traffic monitoring 440 OAM implementations MAY provide methods to utilize live traffic for 441 troubleshooting and performance monitoring. 443 Implementations MAY leverage Data Driven CFM [802.1Q] or IPFIX 444 [RFC5101] for the purpose of performance monitoring. 446 5. General Format of TRILL OAM Messages 448 The TRILL forwarding paradigm allows an implementation to select a 449 path from a set of equal cost paths to forward a packet. Selection 450 of the path of choice is implementation dependent. However, it is a 451 common practice to utilize Layer 2 through Layer 4 information in 452 the inner payload for path selection. 454 As specified above, OAM Messages are required to follow the exact 455 path as the data packets. 457 The proposed frame format for TRILL OAM messages is as follows. 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | 461 . Outer Header . (variable) 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 + TRILL Header + 8 bytes 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 . Flow Entropy . 128 bytes 470 . . 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | 474 . OAM Message Channel . Variable 475 . . 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 1 Frame format of OAM Messages 481 Outer Header: Media dependent header. For Ethernet this included 482 Destination MAC, Source MAC, VLAN (optional) and EtherType fields. 484 TRILL Header: Minimum of 8 bytes when the Extended Header is not 485 included [RFC6325] 487 Flow Entropy: This is a 128 byte Fixed size opaque field. The field 488 MUST be padded with zeros when the flow entropy is less than 128 489 bytes. Flow entropy emulates the forwarding behavior of the desired 490 data packets. 492 OAM Message Channel: This is a variable size section that carries 493 OAM related information. Reusing existing OAM message definitions 494 such as [RFC4379] and [802.1ag] will be explored. 496 5.1. Requirements of OAM Message channel 498 The OAM Message channel header MUST contain a version number 500 The OAM Message channel header MUST contain flags that facilitate 501 hardware level processing. (e.g. indicate this is two-way delay 502 measurement probe) 504 The OAM Message channel MUST contain time stamping in fixed 505 locations to facilitate hardware level performance monitoring. (e.g. 506 delay measurements). 508 The OAM Message channel MUST have the ability to be extensible to 509 include future capabilities without requiring a change to the 510 version of the message header. (e.g. include TLV structures) 512 The OAM Message header MUST contain a unique marker that allows for 513 identifying the presence of the OAM channel. This marker MUST 514 provide equal or better uniqueness compared to the IP checksum 515 define in [RFC791] 517 The OAM Message SHOULD provide methods to include arbitrary data to 518 test functions such as MTU testing. 520 6. Security Considerations 522 Security Requirements are specified in section 4.8. 524 7. IANA Considerations 526 528 8. References 530 8.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [OAMOVER] Mizrahi, T, et.al., "An Overview of Operations, 536 Administration, and Maintenance (OAM) Mechanisms", draft- 537 ietf-opsawg-oam-overview-06, Work in Progress, March 2012. 539 [RFC5860] Vigoureux, M., et.al., "Requirements for Operations, 540 Administration and Maintenance (OAM) in MPLS Transport 541 Networks", RFC5860, May 2010. 543 [RFC4377] Nadeau, T., et.al., "Operations and Management (OAM) 544 Requirements for Multi-Protocol Label Switched (MPLS) 545 Networks", RFC 4377, February 2006. 547 8.2. Informative References 549 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 550 Protocol Specification", RFC 6325, July 2011. 552 [RFC5101] Claise, B., "Specification of the IP Flow Information 553 Export (IPFIX) Protocol for the Exchange of IP Traffic 554 Flow Information", RFC5101, January 2008. 556 [RFC2680] Almes, G., et.al. "A One-way Packet Loss Metric for IPPM", 557 RFC 2680, September 1999. 559 [RFC2679] Almes, G., et.al. "A One-way Delay Metric for IPPM", RFC 560 2679, September 1999. 562 [RFC2681] Almes, G., et.al. "A Round-trip Delay Metric for IPPM", 563 RFC 2681, September 1999. 565 [RFC6291] Anderson, L., et.al. "Guidelines for the Use of the "OAM" 566 Acronym in the IETF", RFC 6291, June 2011. 568 [8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: 569 Connectivity Fault Management", 802.1ag, 2007. 571 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 572 Bridged Local Area Networks", IEEE Std 802.1Q-2011, 573 August 31st , 2011. 575 [RFC791] "Internet Protocol", RFC 791, September 1981. 577 9. Acknowledgments 579 Special acknowledgments to IEEE 802.1 chair, Tony Jeffree for 580 allowing us to solicit comments from IEEE 802.1 group. Also 581 recognized are the comments received from IEEE group, Ayal Loir and 582 others. 584 This document was prepared using 2-Word-v2.0.template.dot. 586 Authors' Addresses 588 Tissa Senevirathne 589 CISCO Systems 590 375 East Tasman Drive 591 San Jose, CA 95134 592 USA. 594 Phone: +1-408-853-2291 595 Email: tsenevir@cisco.com 597 David Bond 598 IBM 599 2051 Mission College Blvd 600 Santa Clara, CA 95054 601 USA 603 Phone: +1-603-339-7575 604 Email: mokon@mokon.net 606 Sam Aldrin 607 Huawei Technologies 608 2330 Central Express Way 609 Santa Clara, CA 95951 610 USA 612 Email: aldrin.ietf@gmail.com 613 Yizhou Li 614 Huawei Technologies 615 101 Software Avenue, 616 Nanjing 210012 617 China 619 Phone: +86-25-56625375 620 Email: liyizhou@huawei.com 622 Rohit Watve 623 CISCO Systems 624 375 East Tasman Drive 625 San Jose, CA 95134 626 USA. 628 Phone: +1-408-424-2091 629 Email: rwatve@cisco.com 631 Anoop Ghanwani 632 DELL 633 350 Holger Way 634 San Jose, CA 95134 635 USA. 637 Phone: +1-408-571-3500 638 Email: Anoop@duke.alumni.duke.edu 640 John Hudson 641 Brocade 642 120 Holger Way 643 San Jose, CA 95134 644 USA. 646 Email: jon.hudson@gmail.com 648 Naveen Nimmu 649 Broadcom 650 9th Floor, Building no 9, Raheja Mind space 651 Hi-Tec City, Madhapur, 652 Hyderabad - 500 081, INDIA 654 Phone: +1-408-218-8893 655 Email: naveen@broadcom.com 656 Radia Perlman 657 Intel Labs 658 2700 156th Ave NE, Suite 300, 659 Bellevue, WA 98007 660 USA. 662 Phone: +1-425-881-4824 663 Email: radia.perlman@intel.com 665 Tal Mizrahi 666 Marvell 667 6 Hamada St. 668 Yokneam, 20692 Israel 670 Email: talmi@marvell.com