idnits 2.17.00 (12 Aug 2021) /tmp/idnits18039/draft-ietf-nvo3-nve-nva-cp-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7364]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-nvo3-arch has been published as RFC 8014 == Outdated reference: draft-ietf-nvo3-hpvr2nve-cp-req has been published as RFC 8394 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Kreeger 3 Internet-Draft Cisco Systems 4 Intended status: Informational D. Dutt 5 Expires: September 22, 2016 Cumulus Networks 6 T. Narten 7 IBM 8 D. Black 9 EMC 10 March 21, 2016 12 Network Virtualization NVE to NVA Control Protocol Requirements 13 draft-ietf-nvo3-nve-nva-cp-req-05 15 Abstract 17 [RFC7364] "Problem Statement: Overlays for Network Virtualization" 18 discusses the needs for network virtualization using overlay networks 19 in highly virtualized data centers. The problem statement outlines a 20 need for control protocols to facilitate running these overlay 21 networks. This document outlines the high level requirements to be 22 fulfilled by the control protocols related to building and managing 23 the mapping tables and other state information used by the Network 24 Virtualization Edge to transmit encapsulated packets across the 25 underlying network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 22, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Control Plane Protocol Functionality . . . . . . . . . . . . 4 64 3.1. Inner to Outer Address Mapping . . . . . . . . . . . . . 7 65 3.2. Underlying Network Multi-Destination Delivery Address(es) 7 66 3.3. VN Connect/Disconnect Notification . . . . . . . . . . . 8 67 3.4. VN Name to VN ID Mapping . . . . . . . . . . . . . . . . 8 68 4. Control Plane Characteristics . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Informative References . . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 73 A.1. Changes from draft-ietf-nvo3-nve-nva-cp-req-01 to -02 . . 12 74 A.2. Changes from draft-ietf-nvo3-nve-nva-cp-req-02 to -03 . . 12 75 A.3. Changes from draft-ietf-nvo3-nve-nva-cp-req-03 to -04 . . 12 76 A.4. Changes from draft-ietf-nvo3-nve-nva-cp-req-04 to -05 . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 [RFC7364] "Problem Statement: Overlays for Network Virtualization" 82 discusses the needs for network virtualization using overlay networks 83 in highly virtualized data centers and provides a general motivation 84 for building such networks. [RFC7365] "Framework for DC Network 85 Virtualization" provides a framework for discussing overlay networks 86 generally and the various components that must work together in 87 building such systems. "An Architecture for Overlay Networks (NVO3)" 88 [I-D.ietf-nvo3-arch] presents a high-level architecture for building 89 NVO3 Overlay networks. The reader is assumed to be familiar with 90 these documents. 92 Section 4.5 of [RFC7364] describes three separate work areas that 93 fall under the general category of a control protocol for NVO3. This 94 document focuses entirely on those aspects of the control protocol 95 related to the building and distributing the mapping tables an NVE 96 uses to tunnel traffic from one VM to another. Specifically, this 97 document focuses on work area 2 given in Section 4.5 of [RFC7364], 98 and discussed in section 8 of [I-D.ietf-nvo3-arch]. Work area 2 99 covers the interaction between an NVE and the Network Virtualization 100 Authority (NVA), while work area 1 concerns operation of the NVA 101 itself. Requirements related to interaction between a hypervisor and 102 NVE when the two entities reside on separate physical devices (work 103 area 3) are covered in [I-D.ietf-nvo3-hpvr2nve-cp-req]. 105 2. Terminology 107 This document uses the same terminology as found in [RFC7365] and 108 [I-D.ietf-nvo3-arch]. This section defines additional terminology 109 used by this document. 111 Network Service Appliance: A stand-alone physical device or a 112 virtual device that provides a network service, such as a 113 firewall, load balancer, etc. Such appliances may embed Network 114 Virtualization Edge (NVE) functionality within them in order to 115 more efficiently operate as part of a virtualized network. 117 VN Alias: A string name for a VN as used by administrators and 118 customers to name a specific VN. A VN Alias is a human-usable 119 string that can be listed in contracts, customer forms, email, 120 configuration files, etc. and that can be communicated easily 121 vocally (e.g., over the phone). A VN Alias is independent of the 122 underlying technology used to implement a VN and will generally 123 not be carried in protocol fields of control protocols used in 124 virtual networks. Rather, a VN Alias will be mapped into a VN 125 Name where precision is required. 127 VN Name: A globally unique identifier for a VN suitable for use 128 within network protocols. A VN Name will usually be paired with a 129 VN Alias, with the VN Alias used by humans as a shorthand way to 130 name and identify a specific VN. A VN Name should have a compact 131 representation to minimize protocol overhead where a VN Name is 132 carried in a protocol field. Using a Universally Unique 133 Identifier (UUID) as discussed in RFC 4122, may work well because 134 it is both compact and a fixed size and can be generated locally 135 with a very high likelihood of global uniqueness. 137 VN ID: A unique and compact identifier for a VN within the scope of 138 a specific NVO3 administrative domain. It will generally be more 139 efficient to carry VN IDs as fields in control protocols than VN 140 Names or VN Aliases. There is a one-to-one mapping between a VN 141 Name and a VN ID within an NVO3 Administrative Domain. Depending 142 on the technology used to implement an overlay network, the VN ID 143 could be used as the VN Context in the data plane, or would need 144 to be mapped to a locally-significant context ID. 146 3. Control Plane Protocol Functionality 148 The NVO3 problem statement [RFC7364], discusses the needs for a 149 control plane protocol (or protocols) to populate each NVE with the 150 state needed to perform its functions. 152 In one common scenario, an NVE provides overlay encapsulation/ 153 decapsulation packet forwarding services to Tenant Systems that are 154 co-resident with the NVE on the same End Device. For example, when 155 the NVE is embedded within a hypervisor or a Network Service 156 Appliance, as depicted in Figure 1 and Figure 2 below. 157 Alternatively, a Tenant System may use an externally connected NVE. 158 For example, an NVE residing on a physical Network Switch connected 159 to the End Device, as depicted in Figure 3 and Figure 4 below. 161 There are two control plane aspects for an NVE. One is the protocol 162 between the NVE and its NVA used to populate the NVE's mapping tables 163 for tunneling traffic across the underlying network. Another is the 164 protocol between an End Device (e.g. Hypervisor) and an external NVE 165 used to promptly update the NVE of Tenant System Interface (TSI) 166 status. This latter control plane aspect is not discussed in this 167 document, but is covered in [I-D.ietf-nvo3-hpvr2nve-cp-req]. The 168 functional requirements for the NVE to NVA control plane are the same 169 regardless of whether the NVE is embedded within and End Device or in 170 an external device as depicted in Figure 1 through Figure 4 below. 172 Hypervisor 173 +-----------------------+ 174 | +--+ +-------+---+ | 175 | |VM|---| | | | 176 | +--+ |Virtual|NVE|----- Underlying 177 | +--+ |Switch | | | Network 178 | |VM|---| | | | 179 | +--+ +-------+---+ | 180 +-----------------------+ 182 Hypervisor with an Embedded NVE. 184 Figure 1 186 Network Service Appliance 187 +---------------------------+ 188 | +------------+ +-----+ | 189 | |Net Service |---| | | 190 | |Instance | | | | 191 | +------------+ | NVE |------ Underlying 192 | +------------+ | | | Network 193 | |Net Service |---| | | 194 | |Instance | | | | 195 | +------------+ +-----+ | 196 +---------------------------+ 198 Network Service Appliance (physical or virtual) with an Embedded NVE. 200 Figure 2 202 Hypervisor Access Switch 203 +------------------+ +-----+-------+ 204 | +--+ +-------+ | | | | 205 | |VM|---| | | VLAN | | | 206 | +--+ |Virtual|---------+ NVE | +--- Underlying 207 | +--+ |Switch | | Trunk | | | Network 208 | |VM|---| | | | | | 209 | +--+ +-------+ | | | | 210 +------------------+ +-----+-------+ 212 Hypervisor with an External NVE. 214 Figure 3 216 Network Service Appliance Access Switch 217 +--------------------------+ +-----+-------+ 218 | +------------+ |\ | | | | 219 | |Net Service |----| \ | | | | 220 | |Instance | | \ | VLAN | | | 221 | +------------+ | |---------+ NVE | +--- Underlying 222 | +------------+ | | | Trunk| | | Network 223 | |Net Service |----| / | | | | 224 | |Instance | | / | | | | 225 | +------------+ |/ | | | | 226 +--------------------------+ +-----+-------+ 228 Physical Network Service Appliance with an External NVE. 230 Figure 4 232 To support an NVE, a control plane protocol is necessary to provide 233 an NVE with the information it needs to maintain its own internal 234 state necessary to carry out its forwarding functions as explained in 235 detail below. 237 1. An NVE maintains a per-VN table of mappings from TSI (inner) 238 addresses to Underlying Network (outer) addresses of remote NVEs. 240 2. An NVE maintains per-VN state for delivering tenant multicast and 241 broadcast packets to other Tenant Systems. Such state could 242 include a list of multicast addresses and/or unicast addresses on 243 the Underlying Network for the NVEs associated with a particular 244 VN. 246 3. End Devices (such as a Hypervisor or Network Service Appliance) 247 utilizing an external NVE need to "attach to" and "detach from" 248 an NVE. Specifically, a mechanism is needed to notify an NVE 249 when a TSI attaches to or detaches from a specific VN. Such a 250 mechanism would provide the necessary information to the NVE that 251 it needs to provide service to a particular TSI. The details of 252 such a mechanism are out-of-scope for this document and are 253 covered in [I-D.ietf-nvo3-hpvr2nve-cp-req]. 255 4. An NVE needs a mapping from each unique VN name to the VN Context 256 value used within encapsulated data packets within the 257 administrative domain that the VN is instantiated. 259 The NVE to NVA control protocol operates directly over the underlay 260 network. The NVA is expected to be connected to the same underlay 261 network as the NVEs. 263 Each NVE communicates with only a single logical NVA; However, the 264 NVA can be centralized or distributed between multiple entities for 265 redundancy purposes. When the NVA is made up of multiple entities, 266 better resiliency may be achieved by physically separating them, 267 which may require each entity to be connected to a different IP 268 subnet of the underlay network. For this reason, each NVE should be 269 allowed to be configured with more than one IP addresses for its 270 logical NVA. NVEs should be able to switch between these IP 271 addresses when it detects that the address it is currently using for 272 the NVA is unreachable. How the NVA represents itself externally is 273 discussed in section 7.3 of [I-D.ietf-nvo3-arch]. 275 Note that a single device could contain both NVE and NVA 276 functionality, but the functional interaction between the NVE and NVA 277 within that device should operate similarly to when the NVE and NVA 278 are implemented in separate devices. 280 3.1. Inner to Outer Address Mapping 282 When presented with a data packet to forward to a TSI within a VN, 283 the NVE needs to know the mapping of the TSI destination (inner) 284 address to the (outer) address on the Underlying Network of the 285 remote NVE which can deliver the packet to the destination Tenant 286 System. In addition, the NVE needs to know what VN Context to use 287 when sending to a destination Tenant System. 289 A protocol is needed to provide this inner to outer mapping and VN 290 Context to each NVE that requires it and keep the mapping updated in 291 a timely manner. Timely updates are important for maintaining 292 connectivity between Tenant Systems when one Tenant System is a VM. 294 Note that one technique that could be used to create this mapping 295 without the need for a control protocol is via data plane learning; 296 However, the learning approach requires packets to be flooded to all 297 NVEs participating in the VN when no mapping exists. One goal of 298 using a control protocol is to eliminate this flooding. 300 3.2. Underlying Network Multi-Destination Delivery Address(es) 302 Each NVE needs a way to deliver multi-destination packets (i.e. 303 tenant broadcast/multicast) within a given VN to each remote NVE 304 which has a destination TSI for these packets. Three possible ways 305 of accomplishing this are: 307 o Use the multicast capabilities of the Underlying Network. 309 o Have each NVE replicate the packets and send a copy across the 310 Underlying Network to each remote NVE currently participating in 311 the VN. 313 o Use one or more distribution servers that replicate the packets on 314 the behalf of the NVEs. 316 Whichever method is used, a protocol is needed to provide on a per VN 317 basis, one or more multicast addresses (assuming the Underlying 318 Network supports multicast), and/or one or more unicast addresses of 319 either the remote NVEs which are not multicast reachable, or of one 320 or more distribution servers for the VN. 322 The protocol must also keep the list of addresses up to date in a 323 timely manner as the set of NVEs for a given VN changes over time. 324 For example, the set of NVEs for a VN could change as VMs power on/ 325 off or migrate to different hypervisors. 327 3.3. VN Connect/Disconnect Notification 329 For the purposes of this document, it is assumed that an NVE receives 330 appropriate notifications when a TSI attaches to or detaches from a 331 specific VN. The details of how that is done are orthogonal to the 332 NVE-to-NVA control plane, so long as such notification provides the 333 necessary information needed by the control plane. As one example, 334 the attach/detach notification would presumably include a VN Name 335 that identifies the specific VN to which the attach/detach operation 336 applies to. 338 3.4. VN Name to VN ID Mapping 340 Once an NVE (embedded or external) receives a VN connect indication 341 with a specified VN Name, the NVE must determine what VN Context 342 value and other necessary information to use to forward Tenant System 343 traffic to remote NVEs. In one approach, the NVE-to-NVA protocol 344 uses VN Names directly when interacting, with the NVA providing such 345 information as the VN Context (or VN ID) along with egress NVE's 346 address. Alternatively, it may be desirable for the NVE-to-NVA 347 protocol to use a more compact representation of the VN name, that 348 is, a VN ID. In such a case, a specific NVE-to-NVA operation might 349 be needed to first map the VN Name into a VN ID, with subsequent NVE- 350 to-NVA operations utilizing the VN ID directly. Thus, it may be 351 useful for the NVE-to-NVA protocol to support an operation that maps 352 VN Names into VN IDs. 354 4. Control Plane Characteristics 356 NVEs are expected to be implemented within both hypervisors (or 357 Network Service Appliances) and within access switches. Any 358 resources used by these protocols (e.g. processing or memory) takes 359 away resources that could be better used by these devices to perform 360 their intended functions (e.g. providing resources for hosted VMs). 362 A large scale data center may contain hundreds of thousands of these 363 NVEs (which may be several independent implementations); Therefore, 364 any savings in per-NVE resources can be multiplied hundreds of 365 thousands of times. 367 Given this, the control plane protocol(s) implemented by NVEs to 368 provide the functionality discussed above should have the below 369 characteristics. 371 1. Minimize the amount of state needed to be stored on each NVE. 372 The NVE should only be required to cache state that it is 373 actively using, and be able to discard any cached state when it 374 is no longer required. For example, an NVE should only need to 375 maintain an inner-to-outer address mapping for destinations to 376 which it is actively sending traffic as opposed to maintaining 377 mappings for all possible destinations. 379 2. Fast acquisition of needed state. For example, when a TSI emits 380 a packet destined to an inner address that the NVE does not have 381 a mapping for, the NVE should be able to acquire the needed 382 mapping quickly. 384 3. Fast detection/update of stale cached state information. This 385 only applies if the cached state is actually being used. For 386 example, when a VM moves such that it is connected to a 387 different NVE, the inner to outer mapping for this VM's address 388 that is cached on other NVEs must be updated in a timely manner 389 (if they are actively in use). If the update is not timely, the 390 NVEs will forward data to the wrong NVE until it is updated. 392 4. Minimize processing overhead. This means that an NVE should 393 only be required to perform protocol processing directly related 394 to maintaining state for the TSIs it is actively communicating 395 with. For example, if the NVA provides unsolicited information 396 to the NVEs, then one way to minimize the processing on the NVE 397 is for it to subscribe for getting these mappings on a per VN 398 basis. Consequently an NVE is not required to maintain state 399 for all VNs within a domain. An NVE only needs to maintain 400 state (or participate in protocol exchanges) about the VNs it is 401 currently attached to. If the NVE obtains mappings on demand 402 from the NVA, then it only needs to obtain the information 403 relevant to the traffic flows that are currently active. This 404 requirement is for the NVE functionality only. The network node 405 that contains the NVE may be involved in other functionality for 406 the underlying network that maintains connectivity that the NVE 407 is not actively using (e.g., routing and multicast distribution 408 protocols for the underlying network). 410 5. Highly scalable. This means scaling to hundreds of thousands of 411 NVEs and several million VNs within a single administrative 412 domain. As the number of NVEs and/or VNs within a data center 413 grows, the protocol overhead at any one NVE should not increase 414 significantly. 416 6. Minimize the complexity of the implementation. This argues for 417 using the least number of protocols to achieve all the 418 functionality listed above. Ideally a single protocol should be 419 able to be used. The less complex the protocol is on the NVE, 420 the more likely interoperable implementations will be created in 421 a timely manner. 423 7. Extensible. The protocol should easily accommodate extension to 424 meet related future requirements. For example, access control 425 or QoS policies, or new address families for either inner or 426 outer addresses should be easy to add while maintaining 427 interoperability with NVEs running older versions. 429 8. Simple protocol configuration. A minimal amount of 430 configuration should be required for a new NVE to be 431 provisioned. Existing NVEs should not require any configuration 432 changes when a new NVE is provisioned. Ideally NVEs should be 433 able to auto configure themselves. 435 9. Do not rely on IP Multicast in the Underlying Network. Many 436 data centers do not have IP multicast routing enabled. If the 437 Underlying Network is an IP network, the protocol should allow 438 for, but not require the presence of IP multicast services 439 within the data center. 441 10. Flexible mapping sources. It should be possible for either NVEs 442 themselves, or other third party entities (e.g. data center 443 management or orchestration systems) to create inner to outer 444 address mappings in the NVA. The protocol should allow for 445 mappings created by an NVE to be automatically removed from all 446 other NVEs if it fails or is brought down unexpectedly. 448 11. Secure. See the Security Considerations section below. 450 5. Security Considerations 452 Editor's Note: This is an initial start on the security 453 considerations section; it will need to be expanded, and suggestions 454 for material to add are welcome. 456 The protocol(s) should protect the integrity of the mapping against 457 both off-path and on-path attacks. It should authenticate the 458 systems that are creating mappings, and rely on light weight security 459 mechanisms to minimize the impact on scalability and allow for simple 460 configuration. 462 Use of an overlay exposes virtual networks to attacks on the 463 underlying network beyond attacks on the control protocol that is the 464 subject of this draft. In addition to the directly applicable 465 security considerations for the networks involved, the use of an 466 overlay enables attacks on encapsulated virtual networks via the 467 underlying network. Examples of such attacks include traffic 468 injection into a virtual network via injection of encapsulated 469 traffic into the underlying network and modifying underlying network 470 traffic to forward traffic among virtual networks that should have no 471 connectivity. The control protocol should provide functionality to 472 help counter some of these attacks, e.g., distribution of NVE access 473 control lists for each virtual network to enable packets from non- 474 participating NVEs to be discarded, but the primary security measures 475 for the underlying network need to be applied to the underlying 476 network. For example, if the underlying network includes 477 connectivity across the public Internet, use of secure gateways 478 (e.g., based on IPsec [RFC4301]) may be appropriate. 480 The inner to outer address mappings used for forwarding data towards 481 a remote NVE could also be used to filter incoming traffic to ensure 482 the inner address sourced packet came from the correct NVE source 483 address, allowing access control to discard traffic that does not 484 originate from the correct NVE. This destination filtering 485 functionality should be optional to use. 487 6. Acknowledgements 489 Thanks to the following people for reviewing and providing feedback: 490 Fabio Maino, Victor Moreno, Ajit Sanzgiri, Chris Wright. 492 7. Informative References 494 [I-D.ietf-nvo3-arch] 495 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 496 Narten, "An Architecture for Overlay Networks (NVO3)", 497 draft-ietf-nvo3-arch-04 (work in progress), October 2015. 499 [I-D.ietf-nvo3-hpvr2nve-cp-req] 500 Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D. 501 Black, "Split-NVE Control Plane Requirements", draft-ietf- 502 nvo3-hpvr2nve-cp-req-04 (work in progress), February 2016. 504 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 505 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 506 December 2005, . 508 [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., 509 Kreeger, L., and M. Napierala, "Problem Statement: 510 Overlays for Network Virtualization", RFC 7364, 511 DOI 10.17487/RFC7364, October 2014, 512 . 514 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 515 Rekhter, "Framework for Data Center (DC) Network 516 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 517 2014, . 519 Appendix A. Change Log 521 A.1. Changes from draft-ietf-nvo3-nve-nva-cp-req-01 to -02 523 1. Added references to the architecture document 524 [I-D.ietf-nvo3-arch]. 526 2. Terminology: Usage of "TSI" in several places. 528 A.2. Changes from draft-ietf-nvo3-nve-nva-cp-req-02 to -03 530 1. Updated references to the framework, problem statement and merged 531 WG hypervisor-to-nve document. 533 A.3. Changes from draft-ietf-nvo3-nve-nva-cp-req-03 to -04 535 1. Minor editorial tweaks. 537 A.4. Changes from draft-ietf-nvo3-nve-nva-cp-req-04 to -05 539 1. Updated references. 541 Authors' Addresses 543 Lawrence Kreeger 544 Cisco Systems 546 Email: kreeger@cisco.com 548 Dinesh Dutt 549 Cumulus Networks 551 Email: ddutt@cumulusnetworks.com 553 Thomas Narten 554 IBM 556 Email: narten@us.ibm.com 558 David Black 559 EMC 561 Email: david.black@emc.com