idnits 2.17.1 draft-quinn-sfc-nsh-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 (February 14, 2014) is 3723 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) == 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 Summary: 0 errors (**), 0 flaws (~~), 3 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 J. Guichard 4 Intended status: Standards Track R. Fernando 5 Expires: August 18, 2014 S. Kumar 6 M. Smith 7 N. Yadav 8 Cisco Systems, Inc. 9 P. Agarwal 10 R. Manur 11 Broadcom 12 A. Chauhan 13 Citrix 14 U. Elzur 15 Intel 16 B. McConnell 17 Rackspace 18 C. Wright 19 Red Hat Inc. 20 February 14, 2014 22 Network Service Header 23 draft-quinn-sfc-nsh-02.txt 25 Abstract 27 This draft describes a Network Service Header (NSH) added to 28 encapsulated packets or frames to realize service function paths. 29 NSH also provides a mechanism for metadata exchange along the 30 instantiated service path. 32 1. Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 18, 2014. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 73 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 75 2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Network Service Header . . . . . . . . . . . . . . . . . . . . 8 77 3.1. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . 9 79 3.3. NSH Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.4. NSH Proxy Nodes . . . . . . . . . . . . . . . . . . . . . 10 81 4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5. NSH Example: GRE . . . . . . . . . . . . . . . . . . . . . . . 15 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 91 2. Introduction 93 Service functions are widely deployed and essential in many networks. 94 These service functions provide a range of features such as security, 95 WAN acceleration, and server load balancing. Service functions may 96 be instantiated at different points in the network infrastructure 97 such as the wide area network, data center, campus, and so forth. 99 The current service function 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 service function 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 platforms. 123 An NSH aware control plane is outside the scope of this document. 125 The SFC Architecture document [SFC-arch] provides an overview of a 126 chaining architecture that clearly defines the roles of the various 127 elements and the scope of a service function chaining encapsulation. 129 2.1. Definition of Terms 131 Classification: Locally instantiated policy and customer/network/ 132 service profile matching of traffic flows for identification of 133 appropriate outbound forwarding actions. 135 SFC Network Forwarder (SFCNF): SFC network forwarders provide 136 network connectivity for service functions forwarders and service 137 functions. SFC network forwarders participate in the network 138 overlay used for service function chaining as well as in the SFC 139 encapsulation. 141 Service Function Forwarder (SFF): A service function forwarder is 142 responsible for delivering traffic received from the SFCNF to one 143 or more connected service functions, and from service functions to 144 the SFCNF. 146 Service Function (SF): A function that is responsible for specific 147 treatment of received packets. A service function can act at the 148 network layer or other OSI layers. A service function can be a 149 virtual instance or be embedded in a physical network element. 150 One of multiple service functions can be embedded in the same 151 network element. Multiple instances of the service function can 152 be enabled in the same administrative domain. 154 Service Node (SN): Physical or virtual element that hosts one or 155 more service functions and has one or more network locators 156 associated with it for reachability and service delivery. 158 Service Function Chain (SFC): A service Function chain defines an 159 ordered set of service functions that must be applied to packets 160 and/or frames selected as a result of classification. The implied 161 order may not be a linear progression as the architecture allows 162 for nodes that copy to more than one branch. The term service 163 chain is often used as shorthand for service function chain. 165 Service Function Path (SFP): The instantiation of a SFC in the 166 network. Packets follow a service function path from a classifier 167 through the requisite service functions 169 Network Node/Element: Device that forwards packets or frames based 170 on outer header information. In most cases is not aware of the 171 presence of NSH. 173 Network Overlay: Logical network built on top of existing network 174 (the underlay). Packets are encapsulated or tunneled to create 175 the overlay network topology. 177 Network Service Header: Data plane header added to frames/packets. 178 The header contains information required for service chaining, as 179 well as metadata added and consumed by network nodes and service 180 elements. 182 Service Classifier: Function that performs classification and 183 imposes an NSH. Creates a service path. Non-initial (i.e. 184 subsequent) classification can occur as needed and can alter, or 185 create a new service path. 187 Service Hop: NSH aware node, akin to an IP hop but in the service 188 overlay. 190 Service Path Segment: A segment of a service path overlay. 192 NSH Proxy: Acts as a gateway: removes and inserts NSH on behalf of a 193 service function that is not NSH aware. 195 2.2. Problem Space 197 Network Service Header (NSH) addresses several limitations associated 198 with service function deployments today. 200 1. Topological Dependencies: Network service deployments are often 201 coupled to network topology. Such dependency imposes constraints 202 on the service delivery, potentially inhibiting the network 203 operator from optimally utilizing service resources, and reduces 204 the flexibility. This limits scale, capacity, and redundancy 205 across network resources. 207 2. Service Chain Construction: Service function chains today are 208 most typically built through manual configuration processes. 209 These are slow and error prone. With the advent of newer service 210 deployment models the control/management planes provide not only 211 connectivity state, but will also be increasingly utilized for 212 the creation of network services. Such a control/management 213 planes could be centralized, or be distributed. 215 3. Application of Service Policy: Service functions rely on topology 216 information such as VLANs or packet (re) classification to 217 determine service policy selection, i.e. the service function 218 specific action taken. Topology information is increasingly less 219 viable due to scaling, tenancy and complexity reasons. The 220 topological information is often stale, providing the operator 221 with inaccurate placement that can result in suboptimal resource 222 utilization. Furthermore topology-centric information often does 223 not convey adequate information to the service functions, forcing 224 functions to individually perform more granular classification. 226 4. Per-Service (re)Classification: Classification occurs at each 227 service function independent from previously applied service 228 functions. More importantly, the classification functionality 229 often differs per service function and service functions may not 230 leverage the results from other service functions. 232 5. Common Header Format: Various proprietary methods are used to 233 share metadata and create service paths. An open header provides 234 a common format for all network and service devices. 236 6. Limited End-to-End Service Visibility: Troubleshooting service 237 related issues is a complex process that involve both network- 238 specific and service-specific expertise. This is especially the 239 case when service function chains span multiple DCs, or across 240 administrative boundaries. Furthermore, the physical and virtual 241 environments (network and service), can be highly divergent in 242 terms of topology and that topological variance adds to these 243 challenges. 245 7. Transport Dependence: Service functions can and will be deployed 246 in networks with a range of transports, including under and 247 overlays. The coupling of service functions to topology requires 248 service functions to support many transports or for a transport 249 gateway function to be present. 251 Please see the Service Function Chaining Problem Statement [SFC-PS] 252 for a more detailed analysis of service function deployment problem 253 areas. 255 3. Network Service Header 257 A Network Service Header (NSH) contains metadata and service path 258 information that is added to a packet or frame and used to create a 259 service plane. The packets and the NSH are then encapsulated in an 260 outer header for transport. 262 The service header is added by a service classification function - a 263 device or application - that determines which packets require 264 servicing, and correspondingly which service path to follow to apply 265 the appropriate service. 267 A NSH is composed of a 64-bit base header, and four 32-bit context 268 headers as shown in figure 1 below. 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 | Base Header | 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Context Header | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Context Header | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Context Header | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Context Header | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 1: Network Service Header 287 Base header: provides information about the service header and 288 service path identification. 290 Context headers: carry opaque metadata. 292 3.1. NSH Actions 294 Service header aware nodes - service classifiers, SFF, SF and NSH 295 proxies, have several possible header related actions: 297 1. Insert or remove service header: These actions can occur at the 298 start and end respectively of a service path. Packets are 299 classified, and if determined to require servicing, a service 300 header imposed. The last node in a service chain, an SF, or an 301 associated SFF, removes NSH. A service classifier MUST insert a 302 NSH. At the end of a service function chain, the last node 303 operating on the service header MUST remove it. 305 A service function can re-classify data as required and that re- 306 classification might result in a new service path. If a SF 307 performs re-classification that results in a change of service 308 path, it MUST remove the existing NSH and MUST imposes a new NSH 309 with the base header reflecting the new path. 311 2. Select service path: The base header provides service chain 312 information and is used by SFFs to determine correct service path 313 selection. SFFs MUST use the base header for selecting the next 314 service in the service path. 316 3. Update a service header: NSH aware service functions MUST 317 decrement the service index. A service index = 0 indicates that 318 a packet MUST be dropped by the SFF performing NSH based 319 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 non-aware 325 service function for NSH actions), then the proxy MUST update 326 service index and MAY update contexts. 328 4. Service policy selection: Service function instances derive 329 policy selection from the service header. Context shared in the 330 service header can provide a range of service-relevant 331 information such as traffic classification. Service functions 332 SHOULD use NSH to select local service policy. 334 3.2. NSH Encapsulation 336 Once NSH is added to a packet, an outer encapsulation is used to 337 forward the original packet and the associated metadata to the start 338 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. Transit network nodes simply forward the encapsulated packets as 345 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 or other indicator in the outer 350 encapsulation. 352 See section 4 for an example using GRE and NSH encapsulation. 354 3.3. NSH Usage 356 NSH creates a dedicated service plane, that addresses many of the 357 limitations highlighted in section 2.2. More specifically, NSH 358 enables: 360 1. Topological Independence: Service forwarding occurs within the 361 service plane, via a network overlay, the underlying network 362 topology does not require modification. Service functions have 363 one or more network locators (e.g. IP address), to receive/send 364 data within the service plane, the NSH header contains an 365 identifier that is used to uniquely identify a service path and 366 the services within that path. 368 2. Service Chaining: NSH contains path identification information 369 needed to realize a service path (see section 4 for header 370 specifics). Furthermore, NSH provides the ability to monitor and 371 troubleshoot a service chain, end-to-end via service-specific OAM 372 messages. The NSH fields can be used by administrators (via, for 373 example a traffic analyzer) to verify (account, ensure correct 374 chaining, provide reports, etc.) the path specifics of packets 375 being forwarded along a service path. 377 3. Metadata Sharing: NSH provides a mechanism to carry shared 378 metadata between network devices and service function, and 379 between service functions. The semantics of the shared metadata 380 is communicated via a control plane to participating nodes. 381 Examples of metadata include classification information used for 382 policy enforcement and network context for forwarding post 383 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 functions, an NSH proxy is 391 used. The proxy node removes the NSH header and delivers, to the 392 service node, the original packet/frame via a local attachment 393 circuit. Examples of a local attachment circuit include, but are not 394 limited to: VLANs, IP in IP, GRE, VXLAN. When complete, the service 395 function returns the packet to the NSH-proxy via the same or 396 different attachment circuit. 398 NSH is re-imposed on packets returned to the proxy from the non-NSH 399 aware service. 401 Typically, a SFCNF will act as a NSH-proxy when required. 403 An NSH proxy MUST perform NSH actions as described in section 3.1. 405 4. Header Format 407 Base Service Header: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |O|C|R|R|R|R|R|R| Reserved | Protocol Type | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Service path | Service index | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Flags: 8 418 Reserved: 8 419 Protocol Type (PT): 16 420 Service path (SP): 24 421 Service index (SI): 8 423 Figure 2: NSH Base Header 425 Base Header Field Descriptions 427 O bit: Indicates that this packet is an operations and management 428 (OAM) packet. SFF and SFs nodes MUST examine the payload and take 429 appropriate action (i.e. return status information). 431 OAM message specifics and handling details are outside the scope of 432 this document. 434 C bit: Context headers MUST be present. When C is set, one or more 435 contexts are in use (i.e. a value placed in a context is 436 significant). The C bit specifies that their ordering and sizing is 437 as per figure 4: network platform (32 bits), network shared (32 438 bits), service platform (32 bits), service shared (32 bits). 440 A C bit equal to zero indicates that no contexts are in use (although 441 they MUST be present to ensure a fixed size header) and that they can 442 be ignored. 444 If a context header is not in use, the value of that context header 445 MUST be zero. 447 All other flag fields are reserved. 449 Protocol type: indicates the protocol type of the original packet or 450 frame as per [ETYPES] 451 Service Index (SI): provides location within the service path. 452 Service index MUST be decremented by service functions or proxy nodes 453 after performing required services. MAY be used in conjunction with 454 service path for path selection. Service Index is also valuable when 455 troubleshooting/reporting service paths. In addition to location 456 within a path, SI can be used for loop detection. 458 Service Path: identifies a service path. Participating nodes MUST 459 use this identifier for path selection. An administrator can use the 460 service path value for reporting and troubleshooting packets along a 461 specific path. 463 Context Headers: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Context data | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 3: Context Data 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Network Platform Context | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Network Shared Context | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Service Platform Context | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Service Shared Context | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Figure 4: Context Data Significance 487 The following examples of context header allocation are guidelines 488 that illustrate how various forms of information can carried and 489 exchanged via NSH. 491 Network platform context: provides platform-specific metadata shared 492 between network nodes. Examples include (but are not limited to) 493 ingress port information, forwarding context and encapsulation type. 495 Network shared context: metadata relevant to any network node such as 496 the result of edge classification. For example, application 497 information, identity information or tenancy information can be 498 shared using this context header. 500 Service platform context: provides service platform specific metadata 501 shared between service functions. This context header is analogous 502 to the network platform context, enabling service platforms to 503 exchange platform-centric information such as an identifier used for 504 load balancing decisions. 506 Service shared context: metadata relevant to, and shared, between 507 service functions. As with the shared network context, 508 classification information such as application type can be conveyed 509 using this context. 511 5. NSH Example: GRE 513 IP Packet: 514 +----------+--------------------+--------------------+ 515 |L2 header | L3 header, proto=47|GRE header,PT=0x894F| 516 +----------+--------------------+--------------------+ 517 --------------+----------------+ 518 NSH, PT=0x800 |original packet | 519 --------------+----------------+ 521 L2 Frame: 522 +----------+--------------------+---------------------+ 523 |L2 header | L3 header, proto=47|GRE header, PT=0x894F| 524 +----------+--------------------+---------------------+ 525 ---------------+---------------+ 526 NSH, PT=0x6558 |original frame | 527 ---------------+---------------+ 529 Figure 5: GRE + NSH 531 6. Security Considerations 533 As with many other protocols, NSH data can be spoofed or otherwise 534 modified. In many deployments, NSH will be used in a controlled 535 environment, with trusted devices (e.g. a data center) thus 536 mitigating the risk of unauthorized header manipulation. 538 NSH is always encapsulated in a transport protocol and therefore, 539 when required, existing security protocols that provide authenticity 540 (e.g. RFC 2119 [RFC6071]) can be used. 542 Similarly if confidentiality is required, existing encryption 543 protocols can be used in conjunction with encapsulated NSH. 545 7. Acknowledgments 547 The authors would like to thank Nagaraj Bagepalli, Abhijit Patra, 548 Carlos Pignataro, Ron Parker, Peter Bosch, Tom Nadeau, Darrel Lewis, 549 Pritesh Kothari and Ken Gray for their detailed review, comments and 550 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, 0x894F, has been allocated 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 [SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Service Function 584 Chaining Problem Statement", 2014, . 588 [SFC-arch] 589 Quinn, P., Ed. and A. Beliveau, Ed., "Service Function 590 Chaining (SFC) Architecture", 2014, 591 . 593 Authors' Addresses 595 Paul Quinn 596 Cisco Systems, Inc. 598 Email: paulq@cisco.com 600 Jim Guichard 601 Cisco Systems, Inc. 603 Email: jguichar@cisco.com 605 Rex Fernando 606 Cisco Systems, Inc. 608 Email: rex@cisco.com 610 Surendra Kumar 611 Cisco Systems, Inc. 613 Email: smkumar@cisco.com 615 Michael Smith 616 Cisco Systems, Inc. 618 Email: michsmit@cisco.com 620 Navindra Yadav 621 Cisco Systems, Inc. 623 Email: nyadav@cisco.com 625 Puneet Agarwal 626 Broadcom 628 Email: pagarwal@broadcom.com 629 Rajeev Manur 630 Broadcom 632 Email: rmanur@broadcom.com 634 Abhishek Chauhan 635 Citrix 637 Email: Abhishek.Chauhan@citrix.com 639 Uri Elzur 640 Intel 642 Email: uri.elzur@intel.com 644 Brad McConnell 645 Rackspace 647 Email: bmcconne@rackspace.com 649 Chris Wright 650 Red Hat Inc. 652 Email: chrisw@redhat.com