idnits 2.17.1 draft-quinn-nsh-01.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 12, 2013) is 3933 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPSec' is mentioned on line 541, but not defined == Unused Reference: 'RFC0791' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC6071' is defined on line 579, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn 3 Internet-Draft R. Fernando 4 Intended status: Standards Track J. Guichard 5 Expires: January 13, 2014 S. Kumar 6 Cisco Systems, Inc. 7 P. Agarwal 8 R. Manur 9 Broadcom 10 A. Chauhan 11 Citrix 12 M. Smith 13 N. Yadav 14 Insieme Networks 15 B. McConnell 16 Rackspace 17 C. Wright 18 Red Hat Inc. 19 July 12, 2013 21 Network Service Header 22 draft-quinn-nsh-01.txt 24 Abstract 26 This draft describes a Network Service Header (NSH) that can be added 27 to encapsulated network packets or frames to create network service 28 paths. In addition to path information, this header also carries 29 metadata used by network devices and/or network services. 31 1. Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 13, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 74 2.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 75 3. Network Service Header . . . . . . . . . . . . . . . . . . . . 8 76 3.1. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.2. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . 9 78 3.3. NSH Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4. NSH Proxy Nodes . . . . . . . . . . . . . . . . . . . . . 10 80 4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5. NSH Example: GRE . . . . . . . . . . . . . . . . . . . . . . . 15 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 2. Introduction 92 Network services are widely deployed and essential in many networks. 93 The services provide a range of functions such as security, WAN 94 acceleration, and server load balancing. Service functions that form 95 part of the overall service may be physically located at different 96 points in the network infrastructure such as the wide area network, 97 data center, campus, and so forth. 99 The current network service deployment models are relatively static, 100 and bound to topology for insertion and policy selection. 101 Furthermore, they do not adapt well to elastic service environments 102 enabled by virtualization. 104 New data center network and cloud architectures require more flexible 105 network service deployment models. Additionally, the transition to 106 virtual platforms requires an agile service insertion model that 107 supports elastic service delivery; the movement of service functions 108 and application workloads in the network and the ability to easily 109 bind service policy to granular information such as per-subscriber 110 state are necessary. 112 The approach taken by NSH is composed of two elements: 114 1. Fixed size, transport independent per-packet/frame service meta- 115 data 117 2. Data plane encapsulation that utilizes the network overlay 118 topology used to deliver packets to the requisite services. 120 NSH is designed to be easy to implement across a range of devices, 121 both physical and virtual, including hardware forwarding elements. 123 An NSH aware control plane is outside the scope of this document. 125 2.1. Definition of Terms 127 Classification: Locally instantiated policy and customer/network/ 128 service profile matching of traffic flows for identification of 129 appropriate outbound forwarding actions. 131 Network Node/Element: Device that forwards packets or frames based 132 on outer header information. In most cases is not aware of the 133 presence of NSH. 135 Network Overlay: Logical network built on top of existing network 136 (the underlay). Packets are encapsulated or tunneled to create 137 the overlay network topology. 139 Network Service Header: Data plane header added to frames/packets. 140 The header contains information required for service chaining, as 141 well as metadata added and consumed by network nodes and service 142 elements. 144 Service Chain: A service chain defines the services required (e.g. 145 FW), and their order (service1 --> service2) that must be applied 146 to packets and/or frames. Service chains need not be linear, 147 rather they are represented by a graph topology. 149 Service Classifier: Function that performs classification and 150 imposes an NSH. Creates a service path. Non-initial (i.e. 151 subsequent) classification can occur as needed and can alter, or 152 create a new service path. 154 Service Hop: NSH aware node, akin to an IP hop but in the service 155 overlay (tracked in an NSH). 157 Service Path: Forwarding path used for delivery of traffic along a 158 service chain. A service path is a series of service hops. 160 Service Node: Physical or virtual element providing one or more 161 service functions. Service nodes utilize NSH for path and other 162 information. 164 Service Path Segment: A segment of a service path between two 165 service nodes. 167 Network Service: An externally visible service offered by a network 168 operator; a service may consist of a single service function or a 169 composite built from several service functions executed in one or 170 more pre-determined sequences. 172 NSH Proxy: Acts as a gateway: removes and inserts NSH on behalf of a 173 service that is not NSH aware. 175 Service Function: A service function (NAT, FW, DPI, IDS, application 176 based packet treatment), application, compute resource, storage, 177 or content used singularly or in collaboration with other service 178 functions to enable a service offered by a network operator. 180 2.2. Problem Statement 182 Network Service Header (NSH) addresses several limitations associated 183 with network service deployment today: 185 1. Topological Dependencies: Network service deployments are often 186 coupled to the physical network topology creating artificial 187 constraints on delivery. These topologies serve only to "insert" 188 the service function; they are not required from a native packet 189 delivery perspective. For example, firewalls often require an 190 "in" and "out" L2 segment and adding a new firewall requires 191 changing the topology (i.e. adding new L2 segments). 193 As more services are required - often with strict ordering - 194 topology changes are needed before and after each service 195 resulting in complex network changes and device configuration. 196 In such topologies, all traffic, whether a service needs to be 197 applied or not, will often pass through the same strict order. A 198 common example is web servers using a server load balancer as the 199 default gateway. When the web service responds to non-load 200 balanced traffic (e.g. administrative or backup operations) all 201 traffic from the server must traverse the load balancer forcing 202 network administrators to create complex routing schemes or 203 create additional interfaces to provide an alternate topology. 205 2. Service Chaining: Service functions are typically independent; 206 service function_1 (Sf1)...service function_n (SFn) are unrelated 207 and there is no notion at the service layer that Sf1 occurs 208 before Sf2. However, to an administrator many service functions 209 have a strict ordering that must be in place, yet have no 210 consistent way to impose and verify the deployed service 211 ordering. 213 Service chains can be unidirectional, bidirectional, symmetric or 214 asymmetric. 216 3. Service Policy Application: Service functions rely on either 217 topology information such as VLANs or packet (re)classification 218 to determine service policy selection, the service action taken. 219 Topology information is increasingly less viable due to scaling, 220 tenancy and complexity reasons. Per-service function packet 221 classification is inefficient and prone to errors, duplicating 222 functionality across services. Furthermore packet classification 223 is often too coarse lacking the ability to determine class of 224 traffic with enough detail. 226 4. Per-Service (re)Classification: Classification occurs at each 227 service, independently from previous service functions. These 228 unrelated classification events consume resources per service. 229 More importantly, the classification functionality often differs 230 per service and services cannot leverage the results from other 231 deployed network or service. 233 5. Elastic Service Delivery: Given the current state of the art for 234 adding/removing services largely centers around VLANs and routing 235 changes, rapid changes to the service layer can be hard to 236 realize due to the risk and complexity of such changes. 238 6. Common Header Format: Various proprietary methods are used to 239 share metadata and create service paths. An open header provides 240 a common format for all network and service devices. 242 7. Limited End-to-End Service Visibility: Troubleshooting service 243 related issues is a complex process that involve network and 244 service expertise. 246 8. Transport Agnostic: Services can and will be deployed in networks 247 with a range of transports, including under and overlays. The 248 coupling of services to topology requires services to support 249 many transports or for a transport gateway function to be 250 present. 252 3. Network Service Header 254 A Network Service Header (NSH) is metadata added to a packet or frame 255 that is used to create a service plane. The packets and the NSH are 256 then encapsulated in an outer header for transport. 258 The service header is added by a service classification function - a 259 device or application - that determines which packets require 260 servicing, and correspondingly which service path to follow to apply 261 the appropriate service. 263 A NSH is composed of a 64-bit base header, and four 32-bit context 264 headers as shown in figure 1 below. 266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 | Base Header | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Context Header | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Context Header | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Context Header | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Context Header | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 1: Network Service Header 283 Base header: provides information about the service header and 284 service path identification. 286 Context headers: carry opaque metadata. 288 3.1. NSH Actions 290 Service header aware nodes - service classifiers, services nodes, NSH 291 proxies and forwarding elements in the service plane, have several 292 possible header related actions: 294 1. Insert/remove service header: These actions can occur at the 295 start and end respectively of a service path or can be performed 296 by a service function that determines that a service path must 297 change due to local policy. Data is classified, and if 298 determined to require servicing, a service header imposed. 300 A service function can re-classify data as required. A service 301 classifier MUST insert a NSH. At the end of a service chain, the 302 last node operating on the service header MUST remove it. If a 303 node performs re-classification that requires that results in a 304 change of service path, it MUST remove the existing NSH and MUST 305 imposes a new NSH with the base header reflecting the new path. 307 The last node is signaled via the control plane, i.e. the next- 308 hop communicated by a control plane to the last node is "end of 309 chain". 311 2. Forward based on header fields: The base header provides service 312 chain information and is used by participating nodes to determine 313 correct service path selection and forwarding as well as loop 314 detection. Participating nodes MUST use the base header for 315 selecting the next service in the service path. 317 3. Update a service header: Services MUST decrement the service 318 index. A service index = 0 indicates that a packet MUST be 319 dropped by the node performing NSH based forwarding. 321 Service functions MAY update context headers if new/updated 322 context is available. 324 If an NSH proxy is in use (acting on behalf of a service for NSH 325 actions), then the proxy MUST update service index and MAY update 326 contexts. 328 4. Service policy selection: Service instances derive policy 329 selection from the service header. Context shared in the service 330 header can provide a range of service-relevant information such 331 as traffic classification. Service functions SHOULD use NSH to 332 select local service policy. 334 3.2. NSH Encapsulation 336 Once the metadata is added to a packet, an outer encapsulation is 337 used to forward the original packet and the associated metadata to 338 the start of a service chain. The encapsulation serves two purposes: 340 1. Creates a topologically independent services plane. Packets are 341 forwarded to the required services without changing the 342 underlying network topology. 344 2. Non-participating network nodes simply forward the encapsulated 345 packets as is. 347 The service header is independent of the encapsulation used and is 348 encapsulated in existing transports. The presence of NSH is 349 indicated via protocol type in the outer encapsulation or, in the 350 case of MPLS, the presence of the GAL label as defined in 351 [draft-guichard-mpls-metadata-00]. 353 See section 4 for an example using GRE and NSH encapsulation. 355 3.3. NSH Usage 357 NSH creates a dedicated service plane, that addresses many of the 358 limitations highlighted in section 2.2. More specifically, NSH 359 enables: 361 1. Topological Independence: Service forwarding occurs within the 362 service plane, via a network overlay, the underlying network 363 topology does not require modification. Services have a locator 364 (e.g. IP address), to receive/send data within the service 365 plane, the NSH header contains an identifier that is used to 366 uniquely identify a service chain and the services within that 367 chain. 369 2. Service Chaining: NSH contains forwarding information needed to 370 realize a service path (see section 4 for header specifics). 371 Furthermore, NSH provides the ability to monitor and troubleshoot 372 a service chain, end-to-end via service-specific OAM messages. 373 The service chain information can be used by administrators (via, 374 for example a traffic analyzer) to verify (account, ensure 375 correct chaining, provide reports, etc.) the chain specifics of 376 packets being forwarded along a service chain. 378 3. Metadata Sharing: NSH provides a mechanism to carry shared 379 metadata between network devices and services, and between 380 services. The semantics of the shared metadata is communicated 381 via a control plane to participating nodes. Examples of metadata 382 include classification information used for policy enforcement 383 and network context for forwarding post service delivery. 385 4. Transport Agnostic: NSH is transport independent and can be used 386 with overlay and underlay forwarding topologies. 388 3.4. NSH Proxy Nodes 390 In order to support NSH unaware service nodes, an NSH proxy is used. 391 The proxy node removes the NSH header and delivers, to the service 392 node, the payload packet/frame via a local attachment circuit. 393 Examples of a local attachement circuit include, but aren not limited 394 to: VLANs, IP in IP, GRE, VXLAN. When complete, the service return 395 the packet to the NSH-proxy via the same or different attachment 396 circuit. 398 NSH is re-imposed on packets returned to the proxy from the non-NSH 399 aware service. 401 For example a network node -- physical or virtual -- attached to the 402 non-NSH service provides proxy functionality 404 An NSH proxy MUST perform NSH actions as described in section 3.1. 406 4. Header Format 408 Base Service Header: 410 0 1 2 3 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |O|C|R|R|R|R|R|R| Protocol Type |Service Index | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Service path | Reserved | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Flags: 8 419 Protocol Type (PT): 16 420 Service Index: 8 421 Service path: 24 422 Reserved: 8 424 Figure 2: NSH Base Header 426 Base Header Field Descriptions 428 O bit: Indicates that this packet is an operations and management 429 (OAM) packet. Participating nodes MUST examine the payload and take 430 appropriate action (i.e. return status information). 432 OAM message spefifics and handling details are outside the scope of 433 this document and will be adressed in a future draft. 435 C bit: Context headers MUST be present. When C is set, one or more 436 contexts are in use (i.e. a value placed in a context is 437 significant). The C bit specifies that their ordering and sizing is 438 as per figure 4: network platform (32 bits), network shared (32 439 bits), service platform (32 bits), service shared (32 bits). 441 A C bit equal to zero indicates that no contexts are in use (although 442 they MUST be present to ensure a fixed size header) and that they can 443 be ignored. 445 If a context header is not in use, the value of that context header 446 MUST be zero. 448 All other flag fields are reserved. 450 Protocol type: indicates the protocol type of the original packet or 451 frame as per [ETYPES] 453 Service Index: TTL functionality and location within the service 454 path. Service index MUST be decremented by service nodes or proxy 455 nodes after performing required services. MAY be used in conjunction 456 with service path for path selection. Service Index is also valuable 457 when troubleshooting/reporting service path and indicates the 458 location of a packet in a service chain. 460 Service Path: identifies a service path. Participating node MUST use 461 this identifier for path selection. An administrator can use the 462 service path value for reporting and troubleshooting packets along a 463 specific path. 465 Context Headers: 467 0 1 2 3 468 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Context data | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 3: Context Data 475 0 1 2 3 476 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Network Platform Context | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Network Shared Context | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Service Platform Context | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Service Shared Context | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Figure 4: Context Data Significance 489 Network platform context: provides platform-specific metadata shared 490 between network nodes. Examples include (but are not limited to) 491 ingress port information, forwarding context and encapsulation type. 493 Network shared context: metadata relevant to any network node such as 494 the result of edge classification. For example, application 495 information, identity information or tenancy information can be 496 shared using this context header. 498 Service platform context: provides service platform specific metadata 499 shared between service functions. This context header is analogous 500 to the network platform context, enabling service platforms to 501 exchange platform-centric information such as an indentifier used for 502 load balancing decisions. 504 Service shared context: metadata relevant to, and shared, between 505 service functions. As woth the shared network context, 506 classificaiton iformation such as application type can be conveyed 507 using this context. 509 5. NSH Example: GRE 511 IP Packet: 512 +----------+--------------------+--------------------+ 513 |L2 header | L3 header, proto=47|GRE header, PT=0xNSH| 514 +----------+--------------------+--------------------+ 515 |-------------+----------------+ 516 NSH, PT=0x800 |original packet | 517 |-------------+----------------+ 519 L2 Frame: 520 +----------+--------------------+---------------------+ 521 |L2 header | L3 header, proto=47|GRE header, PT=0xNSH | 522 +----------+--------------------+---------------------+ 523 ---------------+---------------+ 524 NSH, PT=0x6558 |original frame | 525 ---------------+---------------+ 527 Figure 5: GRE + NSH 529 Note: 0xNSH is a placeholder for a NSH specific Ethertype that will 530 be requested. 532 6. Security Considerations 534 As with many other protocols, NSH data can be spoofed or otherwise 535 modified. In many deployments, NSH will be used in a controlled 536 environment, with trusted devices (e.g. a data center) thus 537 mitigating the risk of unauthorized header manipulation. 539 NSH is always encapsulated in a transport protocol and therefore, 540 when required, existing security protocols that provide authenticity 541 (e.g. [IPSec]) can be used. 543 Similarly if confidentiality is required, existing encryption 544 protocols can be used in conjunction with encapsulated NSH. 546 7. Acknowledgments 548 The authors would like to thank Nagaraj Bagepalli, Abhijit Patra, 549 Carlos Pignataro, Ron Parker, Peter Bosch, Tom Nadeau and Ken Gray 550 for their detailed review, comments and contributions. 552 A special thank you goes to David Ward and Tom Edsall for their 553 guidance and feedback. 555 8. IANA Considerations 557 An IEEE EtherType will be requested for NSH. 559 9. References 561 9.1. Normative References 563 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 564 September 1981. 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, March 1997. 569 9.2. Informative References 571 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 572 . 575 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 576 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 577 March 2000. 579 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 580 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 581 February 2011. 583 Authors' Addresses 585 Paul Quinn 586 Cisco Systems, Inc. 588 Email: paulq@cisco.com 590 Rex Fernando 591 Cisco Systems, Inc. 593 Email: rex@cisco.com 595 Jim Guichard 596 Cisco Systems, Inc. 598 Email: jguichar@cisco.com 600 Surendra Kumar 601 Cisco Systems, Inc. 603 Email: smkumar@cisco.com 605 Puneet Agarwal 606 Broadcom 608 Email: pagarwal@broadcom.com 610 Rajeev Manur 611 Broadcom 613 Email: rmanur@broadcom.com 615 Abhishek Chauhan 616 Citrix 618 Email: Abhishek.Chauhan@citrix.com 619 Michael Smith 620 Insieme Networks 622 Email: michsmit@insiemenetworks.com 624 Navindra Yadav 625 Insieme Networks 627 Email: nyadav@insiemenetworks.com 629 Brad McConnell 630 Rackspace 632 Email: bmcconne@rackspace.com 634 Chris Wright 635 Red Hat Inc. 637 Email: chrisw@redhat.com