idnits 2.17.1 draft-quinn-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 12, 2014) is 3726 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 561, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 573, 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 16, 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 B. McConnell 15 Rackspace 16 C. Wright 17 Red Hat Inc. 18 February 12, 2014 20 Network Service Header 21 draft-quinn-nsh-02.txt 23 Abstract 25 This draft describes a Network Service Header (NSH) added to 26 encapsulated packets or frames to realize service function paths. 27 NSH also provides a mechanism for metadata exchange along the 28 instantiated service path. 30 1. Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 16, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 73 2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Network Service Header . . . . . . . . . . . . . . . . . . . . 8 75 3.1. NSH Actions . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.2. NSH Encapsulation . . . . . . . . . . . . . . . . . . . . 9 77 3.3. NSH Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 78 3.4. NSH Proxy Nodes . . . . . . . . . . . . . . . . . . . . . 10 79 4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5. NSH Example: GRE . . . . . . . . . . . . . . . . . . . . . . . 15 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 2. Introduction 91 Service functions are widely deployed and essential in many networks. 92 These service functions provide a range of features such as security, 93 WAN acceleration, and server load balancing. Service functions may 94 be instantiated at different points in the network infrastructure 95 such as the wide area network, data center, campus, and so forth. 97 The current service function deployment models are relatively static, 98 and bound to topology for insertion and policy selection. 99 Furthermore, they do not adapt well to elastic service environments 100 enabled by virtualization. 102 New data center network and cloud architectures require more flexible 103 service function deployment models. Additionally, the transition to 104 virtual platforms requires an agile service insertion model that 105 supports elastic service delivery; the movement of service functions 106 and application workloads in the network and the ability to easily 107 bind service policy to granular information such as per-subscriber 108 state are necessary. 110 The approach taken by NSH is composed of two elements: 112 1. Fixed size, transport independent per-packet/frame service meta- 113 data 115 2. Data plane encapsulation that utilizes the network overlay 116 topology used to deliver packets to the requisite services. 118 NSH is designed to be easy to implement across a range of devices, 119 both physical and virtual, including hardware platforms. 121 An NSH aware control plane is outside the scope of this document. 123 The SFC Architecture document [SFC-arch] provides an overview of a 124 chaining architecture that clearly defines the roles of the various 125 elements and the scope of a service function chaining encapsulation. 127 2.1. Definition of Terms 129 Classification: Locally instantiated policy and customer/network/ 130 service profile matching of traffic flows for identification of 131 appropriate outbound forwarding actions. 133 SFC Network Forwarder (SFCNF): SFC network forwarders provide 134 network connectivity for service functions forwarders and service 135 functions. SFC network forwarders participate in the network 136 overlay used for service function chaining as well as in the SFC 137 encapsulation. 139 Service Function Forwarder (SFF): A service function forwarder is 140 responsible for delivering traffic received from the SFCNF to one 141 or more connected service functions, and from service functions to 142 the SFCNF. 144 Service Function (SF): A function that is responsible for specific 145 treatment of received packets. A service function can act at the 146 network layer or other OSI layers. A service function can be a 147 virtual instance or be embedded in a physical network element. 148 One of multiple service functions can be embedded in the same 149 network element. Multiple instances of the service function can 150 be enabled in the same administrative domain. 152 Service Node (SN): Physical or virtual element that hosts one or 153 more service functions and has one or more network locators 154 associated with it for reachability and service delivery. 156 Service Function Chain (SFC): A service Function chain defines an 157 ordered set of service functions that must be applied to packets 158 and/or frames selected as a result of classification. The implied 159 order may not be a linear progression as the architecture allows 160 for nodes that copy to more than one branch. The term service 161 chain is often used as shorthand for service function chain. 163 Service Function Path (SFP): The instantiation of a SFC in the 164 network. Packets follow a service function path from a classifier 165 through the requisite service functions 167 Network Node/Element: Device that forwards packets or frames based 168 on outer header information. In most cases is not aware of the 169 presence of NSH. 171 Network Overlay: Logical network built on top of existing network 172 (the underlay). Packets are encapsulated or tunneled to create 173 the overlay network topology. 175 Network Service Header: Data plane header added to frames/packets. 176 The header contains information required for service chaining, as 177 well as metadata added and consumed by network nodes and service 178 elements. 180 Service Classifier: Function that performs classification and 181 imposes an NSH. Creates a service path. Non-initial (i.e. 182 subsequent) classification can occur as needed and can alter, or 183 create a new service path. 185 Service Hop: NSH aware node, akin to an IP hop but in the service 186 overlay. 188 Service Path Segment: A segment of a service path overlay. 190 NSH Proxy: Acts as a gateway: removes and inserts NSH on behalf of a 191 service function that is not NSH aware. 193 2.2. Problem Space 195 Network Service Header (NSH) addresses several limitations associated 196 with service function deployments today. 198 1. Topological Dependencies: Network service deployments are often 199 coupled to network topology. Such dependency imposes constraints 200 on the service delivery, potentially inhibiting the network 201 operator from optimally utilizing service resources, and reduces 202 the flexibility. This limits scale, capacity, and redundancy 203 across network resources. 205 2. Service Chain Construction: Service function chains today are 206 most typically built through manual configuration processes. 207 These are slow and error prone. With the advent of newer service 208 deployment models the control/management planes provide not only 209 connectivity state, but will also be increasingly utilized for 210 the creation of network services. Such a control/management 211 planes could be centralized, or be distributed. 213 3. Application of Service Policy: Service functions rely on topology 214 information such as VLANs or packet (re) classification to 215 determine service policy selection, i.e. the service function 216 specific action taken. Topology information is increasingly less 217 viable due to scaling, tenancy and complexity reasons. The 218 topological information is often stale, providing the operator 219 with inaccurate placement that can result in suboptimal resource 220 utilization. Furthermore topology-centric information often does 221 not convey adequate information to the service functions, forcing 222 functions to individually perform more granular classification. 224 4. Per-Service (re)Classification: Classification occurs at each 225 service function independent from previously applied service 226 functions. More importantly, the classification functionality 227 often differs per service function and service functions may not 228 leverage the results from other service functions. 230 5. Common Header Format: Various proprietary methods are used to 231 share metadata and create service paths. An open header provides 232 a common format for all network and service devices. 234 6. Limited End-to-End Service Visibility: Troubleshooting service 235 related issues is a complex process that involve both network- 236 specific and service-specific expertise. This is especially the 237 case when service function chains span multiple DCs, or across 238 administrative boundaries. Furthermore, the physical and virtual 239 environments (network and service), can be highly divergent in 240 terms of topology and that topological variance adds to these 241 challenges. 243 7. Transport Dependence: Service functions can and will be deployed 244 in networks with a range of transports, including under and 245 overlays. The coupling of service functions to topology requires 246 service functions to support many transports or for a transport 247 gateway function to be present. 249 Please see the Service Function Chaining Problem Statement [SFC-PS] 250 for a more detailed analysis of service function deployment problem 251 areas. 253 3. Network Service Header 255 A Network Service Header (NSH) contains metadata and service path 256 information that is added to a packet or frame and used to create a 257 service plane. The packets and the NSH are then encapsulated in an 258 outer header for transport. 260 The service header is added by a service classification function - a 261 device or application - that determines which packets require 262 servicing, and correspondingly which service path to follow to apply 263 the appropriate service. 265 A NSH is composed of a 64-bit base header, and four 32-bit context 266 headers as shown in figure 1 below. 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 | Base Header | 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Context Header | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Context Header | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Context Header | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Context Header | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 1: Network Service Header 285 Base header: provides information about the service header and 286 service path identification. 288 Context headers: carry opaque metadata. 290 3.1. NSH Actions 292 Service header aware nodes - service classifiers, SFF, SF and NSH 293 proxies, have several possible header related actions: 295 1. Insert or remove service header: These actions can occur at the 296 start and end respectively of a service path. Packets are 297 classified, and if determined to require servicing, a service 298 header imposed. The last node in a service chain, an SF, or an 299 associated SFF, removes NSH. A service classifier MUST insert a 300 NSH. At the end of a service function chain, the last node 301 operating on the service header MUST remove it. 303 A service function can re-classify data as required and that re- 304 classification might result in a new service path. If a SF 305 performs re-classification that results in a change of service 306 path, it MUST remove the existing NSH and MUST imposes a new NSH 307 with the base header reflecting the new path. 309 2. Select service path: The base header provides service chain 310 information and is used by SFFs to determine correct service path 311 selection. SFFs MUST use the base header for selecting the next 312 service in the service path. 314 3. Update a service header: NSH aware service functions MUST 315 decrement the service index. A service index = 0 indicates that 316 a packet MUST be dropped by the SFF performing NSH based 317 forwarding. 319 Service functions MAY update context headers if new/updated 320 context is available. 322 If an NSH proxy is in use (acting on behalf of a non-aware 323 service function for NSH actions), then the proxy MUST update 324 service index and MAY update contexts. 326 4. Service policy selection: Service function instances derive 327 policy selection from the service header. Context shared in the 328 service header can provide a range of service-relevant 329 information such as traffic classification. Service functions 330 SHOULD use NSH to select local service policy. 332 3.2. NSH Encapsulation 334 Once NSH is added to a packet, an outer encapsulation is used to 335 forward the original packet and the associated metadata to the start 336 of a service chain. The encapsulation serves two purposes: 338 1. Creates a topologically independent services plane. Packets are 339 forwarded to the required services without changing the 340 underlying network topology. 342 2. Transit network nodes simply forward the encapsulated packets as 343 is. 345 The service header is independent of the encapsulation used and is 346 encapsulated in existing transports. The presence of NSH is 347 indicated via protocol type or other indicator in the outer 348 encapsulation. 350 See section 4 for an example using GRE and NSH encapsulation. 352 3.3. NSH Usage 354 NSH creates a dedicated service plane, that addresses many of the 355 limitations highlighted in section 2.2. More specifically, NSH 356 enables: 358 1. Topological Independence: Service forwarding occurs within the 359 service plane, via a network overlay, the underlying network 360 topology does not require modification. Service functions have 361 one or more network locators (e.g. IP address), to receive/send 362 data within the service plane, the NSH header contains an 363 identifier that is used to uniquely identify a service path and 364 the services within that path. 366 2. Service Chaining: NSH contains path identification information 367 needed to realize a service path (see section 4 for header 368 specifics). Furthermore, NSH provides the ability to monitor and 369 troubleshoot a service chain, end-to-end via service-specific OAM 370 messages. The NSH fields can be used by administrators (via, for 371 example a traffic analyzer) to verify (account, ensure correct 372 chaining, provide reports, etc.) the path specifics of packets 373 being forwarded along a service path. 375 3. Metadata Sharing: NSH provides a mechanism to carry shared 376 metadata between network devices and service function, and 377 between service functions. The semantics of the shared metadata 378 is communicated via a control plane to participating nodes. 379 Examples of metadata include classification information used for 380 policy enforcement and network context for forwarding post 381 service delivery. 383 4. Transport Agnostic: NSH is transport independent and can be used 384 with overlay and underlay forwarding topologies. 386 3.4. NSH Proxy Nodes 388 In order to support NSH unaware service functions, an NSH proxy is 389 used. The proxy node removes the NSH header and delivers, to the 390 service node, the original packet/frame via a local attachment 391 circuit. Examples of a local attachment circuit include, but are not 392 limited to: VLANs, IP in IP, GRE, VXLAN. When complete, the service 393 function returns the packet to the NSH-proxy via the same or 394 different attachment circuit. 396 NSH is re-imposed on packets returned to the proxy from the non-NSH 397 aware service. 399 Typically, a SFCNF will act as a NSH-proxy when required. 401 An NSH proxy MUST perform NSH actions as described in section 3.1. 403 4. Header Format 405 Base Service Header: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |O|C|R|R|R|R|R|R| Reserved | Protocol Type | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Service path | Service index | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Flags: 8 416 Reserved: 8 417 Protocol Type (PT): 16 418 Service path (SP): 24 419 Service index (SI): 8 421 Figure 2: NSH Base Header 423 Base Header Field Descriptions 425 O bit: Indicates that this packet is an operations and management 426 (OAM) packet. SFF and SFs nodes MUST examine the payload and take 427 appropriate action (i.e. return status information). 429 OAM message specifics and handling details are outside the scope of 430 this document. 432 C bit: Context headers MUST be present. When C is set, one or more 433 contexts are in use (i.e. a value placed in a context is 434 significant). The C bit specifies that their ordering and sizing is 435 as per figure 4: network platform (32 bits), network shared (32 436 bits), service platform (32 bits), service shared (32 bits). 438 A C bit equal to zero indicates that no contexts are in use (although 439 they MUST be present to ensure a fixed size header) and that they can 440 be ignored. 442 If a context header is not in use, the value of that context header 443 MUST be zero. 445 All other flag fields are reserved. 447 Protocol type: indicates the protocol type of the original packet or 448 frame as per [ETYPES] 449 Service Index (SI): provides location within the service path. 450 Service index MUST be decremented by service functions or proxy nodes 451 after performing required services. MAY be used in conjunction with 452 service path for path selection. Service Index is also valuable when 453 troubleshooting/reporting service paths. In addition to location 454 within a path, SI can be used for loop detection. 456 Service Path: identifies a service path. Participating nodes MUST 457 use this identifier for path selection. An administrator can use the 458 service path value for reporting and troubleshooting packets along a 459 specific path. 461 Context Headers: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Context data | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 3: Context Data 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Network Platform Context | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Network Shared Context | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Service Platform Context | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Service Shared Context | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 4: Context Data Significance 485 The following examples of context header allocation are guidelines 486 that illustrate how various forms of information can carried and 487 exchanged via NSH. 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 identifier used for 502 load balancing decisions. 504 Service shared context: metadata relevant to, and shared, between 505 service functions. As with the shared network context, 506 classification information 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=0x894F| 514 +----------+--------------------+--------------------+ 515 --------------+----------------+ 516 NSH, PT=0x800 |original packet | 517 --------------+----------------+ 519 L2 Frame: 520 +----------+--------------------+---------------------+ 521 |L2 header | L3 header, proto=47|GRE header, PT=0x894F| 522 +----------+--------------------+---------------------+ 523 ---------------+---------------+ 524 NSH, PT=0x6558 |original frame | 525 ---------------+---------------+ 527 Figure 5: GRE + NSH 529 6. Security Considerations 531 As with many other protocols, NSH data can be spoofed or otherwise 532 modified. In many deployments, NSH will be used in a controlled 533 environment, with trusted devices (e.g. a data center) thus 534 mitigating the risk of unauthorized header manipulation. 536 NSH is always encapsulated in a transport protocol and therefore, 537 when required, existing security protocols that provide authenticity 538 (e.g. RFC 2119 [RFC6071]) can be used. 540 Similarly if confidentiality is required, existing encryption 541 protocols can be used in conjunction with encapsulated NSH. 543 7. Acknowledgments 545 The authors would like to thank Nagaraj Bagepalli, Abhijit Patra, 546 Carlos Pignataro, Ron Parker, Peter Bosch, Tom Nadeau, Darrel Lewis, 547 Pritesh Kothari and Ken Gray for their detailed review, comments and 548 contributions. 550 A special thank you goes to David Ward and Tom Edsall for their 551 guidance and feedback. 553 8. IANA Considerations 555 An IEEE EtherType, 0x894F, has been allocated for NSH. 557 9. References 559 9.1. Normative References 561 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 562 September 1981. 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 9.2. Informative References 569 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 570 . 573 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 574 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 575 March 2000. 577 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 578 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 579 February 2011. 581 [SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Service Function 582 Chaining Problem Statement", 2014, . 586 [SFC-arch] 587 Quinn, P., Ed. and A. Beliveau, Ed., "Service Function 588 Chaining (SFC) Architecture", 2014, 589 . 591 Authors' Addresses 593 Paul Quinn 594 Cisco Systems, Inc. 596 Email: paulq@cisco.com 598 Jim Guichard 599 Cisco Systems, Inc. 601 Email: jguichar@cisco.com 603 Rex Fernando 604 Cisco Systems, Inc. 606 Email: rex@cisco.com 608 Surendra Kumar 609 Cisco Systems, Inc. 611 Email: smkumar@cisco.com 613 Michael Smith 614 Cisco Systems, Inc. 616 Email: michsmit@cisco.com 618 Navindra Yadav 619 Cisco Systems, Inc. 621 Email: nyadav@cisco.com 623 Puneet Agarwal 624 Broadcom 626 Email: pagarwal@broadcom.com 627 Rajeev Manur 628 Broadcom 630 Email: rmanur@broadcom.com 632 Abhishek Chauhan 633 Citrix 635 Email: Abhishek.Chauhan@citrix.com 637 Brad McConnell 638 Rackspace 640 Email: bmcconne@rackspace.com 642 Chris Wright 643 Red Hat Inc. 645 Email: chrisw@redhat.com