idnits 2.17.1 draft-rfernando-l3vpn-service-chaining-00.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 18, 2013) is 4085 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: 'RFC2119' is mentioned on line 156, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Fernando 3 Intended Status: Standards track D. Rao 4 Expires: August 18, 2013 L. Fang 5 Cisco 6 M. Napierala 7 AT&T 8 N. Bitar 9 Verizon 10 N. So 11 Tata Communications 13 February 18, 2013 15 Virtual Topologies for Service Chaining in BGP IP VPNs 16 draft-rfernando-l3vpn-service-chaining-00 18 Abstract 20 This document presents the techniques built upon BGP/MPLS IP VPN 21 control plane mechanisms to construct virtual service topologies for 22 service chaining. These virtual service topologies allow a sequence 23 of service nodes to be visited across multiple zones in a data center 24 to form a service chain. The method uses service topology specific 25 Route Targets (RTs) in addition to general purpose RTs. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2 Intra-Zone Routing and Traffic Forwarding . . . . . . . . . . . 6 68 3 Inter-Zone Routing and Traffic Forwarding . . . . . . . . . . . 7 69 4 Proposed Inter-Zone Model . . . . . . . . . . . . . . . . . . . 8 70 4.1 Constructing the Virtual Service Topology . . . . . . . . . 8 71 4.2 Inter-zone Routing and Service Chaining . . . . . . . . . . 10 72 5 Routing Considerations . . . . . . . . . . . . . . . . . . . . 11 73 5.1 Multiple service topologies . . . . . . . . . . . . . . . . 12 74 5.2 Multipath . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.3 Supporting redundancy . . . . . . . . . . . . . . . . . . . 12 76 5.4 Route Aggregation . . . . . . . . . . . . . . . . . . . . . 12 77 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 78 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 79 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1 Introduction 86 Network topologies and routing design in enterprise, Data Center, and 87 campus networks typically reflect the needs of the organization in 88 terms of performance, scale, security and availability. For scale and 89 security reasons, these networks may be composed of multiple small 90 domains or zones each serving one or more functions of the 91 organization. 93 A network zone is a logical grouping of physical assets that support 94 certain applications or a subset thereof. Hosts can communicate 95 freely within a zone, that is, a datagram traveling between two hosts 96 in the same zone is not routed through any servers that examine the 97 datagram payload, but a datagram traveling between hosts in different 98 zones is subject to additional services to meet the needs of scaling, 99 performance, and security for specific applications. Example of such 100 services can be a security gateway or a load-balancer. 102 Traditional networks achieve this by using a combination of physical 103 topology constraints and routing. For example, one can force 104 datagrams going through a FireWall (FW) by putting the firewall in 105 the data path from a source to a destination. In some other cases, 106 the datagrams needs to go through a security gateway for security 107 service, and a Load Balancer (LB) for load balancing service. 109 In the modern virtualized Data Centers, appliances, applications, and 110 network functions are virtualized, they are software instances 111 residing in servers or appliances instead of individual physical 112 devices. 114 Porting a traditional network with all its functions and 115 infrastructure elements to a virtualized DC requires network overlay 116 mechanisms that provide the ability to create virtual network 117 topologies that mimic physical networks and the ability to constrain 118 the flow of routing and traffic over these virtual network 119 topologies. 121 A Data Center needs a virtual topology in which the servers are in 122 the "virtual" data path, rather than in the physical data path. For 123 example, a traffic flow in the traditional network has the resource 124 as Provider Edge (PE) 1, and destination as Autonomous System Border 125 Router (ASBR) 1, the flow must be serviced by FW1 and LB2, its path 126 would be PE1 -> FW1 -> LB1 -> ASBR1. In a virtualized DC, the virtual 127 topology for this path may be vPE1 -> vFW1 -> vLB1 -> ASBR1, assume 128 PE1, FW1 and LB1 are virtual nodes. This sequence represents an 129 example of virtual service chain. The nodes in the chain may be 130 placed at arbitrary physical locations. 132 Furthermore, data centers might need multiple virtual topologies per 133 tenant to handle different types of application traffic. A tenant is 134 a customer who uses the virtualized data center services. The term 135 Multi-tenant means virtualized single end device, for example, a 136 server, supports multiple tenants which requires routing isolation 137 among the tenants' traffic. Each tenant might dictate a different 138 topology of connectedness between their zones and applications and 139 might need the ability to apply network policies and services for 140 inter-zone traffic in specific order to the organization objectives 141 of the tenant. Therefore, the mechanisms devised should be flexible 142 to accommodate the custom needs of a tenant and their applications at 143 the same time MUST be robust enough to satisfy the scale, performance 144 and HA needs that they demand from the virtual network 145 infrastructure. 147 Towards this end, this document introduces the concept of virtual 148 service topologies and extends MPLS/VPN control plane mechanisms to 149 constrain routing and traffic flow over virtual service topologies. 151 1.1 Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2. Suggested text under terminology in 1.1 (after the key word 158 paragraph) 160 Terms description 161 ----- --------------------------- 163 AS Autonomous System 164 ASBR Autonomous System Border Router 165 BGP Border Gateway Protocol 166 CE Customer Edge 167 ED End device: where Guest OS, Host OS/Hypervisor, 168 applications, VMs, and virtual router may reside 169 Forwarder L3VPN forwarding function 170 FW FireWall 171 GRE Generic Routing Encapsulation 172 Hypervisor Virtual Machine Manager running on each end device 173 I2RS Interface to Routing System 174 LB Load Balancer 175 LTE Long Term Evolution 176 MP-BGP Multi-Protocol Border Gateway Protocol 177 PCEF Policy Charging and Enforcement Function 178 P Provider backbone router 179 proxy-arp proxy-Address Resolution Protocol 180 QoS Quality of Service 181 RR Route Reflector 182 RT Route Target 183 RTC RT Constraint 184 SDN Software Defined Network 185 ToR Top-of-Rack switch 186 VI Virtual Interface 187 vCE virtual Customer Router 188 vFW virtual FireWall 189 vLB virtual Load Balancer 190 VM Virtual Machine 191 vPC virtual Private Cloud 192 vPE virtual Provider Edge 193 VPN Virtual Private Network 194 vRR virtual Route Reflector1.2 Scope of the document 195 WAN Wide Area Network 197 General terminologies: 199 Service-PE: A BGP IP-VPN PE to which a service node in a virtual 200 service topology is attached. The PE directs incoming traffic from 201 other PEs to the service node via an MPLS VPN label or IP lookup; and 202 forwards traffic from the service node to the next node in the chain. 203 A Service-PE is a logical entity, in that a given PE may be attached 204 to both a service node and an application VM. 206 Service node: A physical or virtual service appliance/application 207 which inspects and/or redirects the flow of inter-zone traffic. 208 Examples of service CEs: Firewalls, load-balancers, deep packet 209 inspectors. The Service node acts as a CE in the VPN network. 211 Service Chain: A sequence of service-PE's and the corresponding 212 service nodes created in a specific order. The service chain is 213 unidirectional and creates a one way traffic flow between source 214 Service-PE in the source zone and Destination Service-PE in the 215 destination zone. 217 Service topology route: A topology service route is a route that is 218 used to direct the traffic flow along the service topology. There 219 should be one such route per service topology. The service topology - 220 and hence the service route - is constructed on a per-VPN basis. This 221 service topology is independent of the routes for the actual 222 addresses of the VMs present in the various zones. There can be 223 multiple service topologies for a given VPN. Topologies are 224 constructed unidirectonally. Between the same pair of zones, traffic 225 in opposite directions will be supported by two service topologies. 227 Source Service-PE: The service-PE closest to the source zone. 229 Destination Service-PE: The service PE closest to the destination 230 zone. 232 Service-import-RT: A RT allows the routes to be imported into a 233 Service-VRF. The route which is imported through service-import-RT 234 MUST be re-originated with the corresponding service-export-RT. 236 Service-export-RT: A RT allows the routes to be exported from a 237 Service-VRF. 239 Service-topology-RT: identifies the specific service topology. 241 Tenant. A tenant is a higher-level management construct. In the 242 control/forwarding plane, it is the various virtual networks that get 243 instantiated. A tenant may have more than one virtual network or VPN. 245 Zone: A logical grouping of physical assets that supports certain 246 applications or a subset thereof. VMs can communicate freely within a 247 zone. 249 2 Intra-Zone Routing and Traffic Forwarding 251 This section provides a brief overview of how BGP/MPLS IP VPNs 252 [RFC4364] control plane can be used in DC networks to used to divide 253 a DC network into a number of zones. The subsequent sections in the 254 document build on this base model to create inter-zone service 255 topologies by interconnecting these zones and forcing inter-zone 256 traffic to travel through a sequence of servers where the sequence of 257 servers depends on . 259 The notion of BGP IP VPN when applied to the virtual Data Center 260 works in the following manner. 262 The VM that runs the applications in the server is treated as a CE 263 attached to the VPN. A CE/VM belongs to a zone. The PE is the first 264 hop router from the CE/VM and the PE-CE link is single hop from an L3 265 perspective. Any of the available physical, logical or tunneling 266 technologies can be used to create this "direct" link between the 267 CE/VM and its attached PE(s). 269 If a PE attaches to one or more CEs of a certain zone, the PE must 270 have exactly one VRF for that zone, and the PE-CE links to those CEs 271 must all be associated with that VRF. Intra-zone connectivity between 272 CE/VMs that attach to different PEs is achieved by designating an RT 273 per zone (zone-RT) that is both an import RT and an export RT of all 274 PE VRFs that terminate the CE/VMs that belong to the zone. A VM may 275 have multiple virtual interfaces that attach to different zones. 277 It is further assumed that the CE/VM's are associated with network 278 policies that become activated on an attached PE when a CE/VM becomes 279 alive. These policies dictate how networking should be set up for the 280 CE/VM including the properties of the CE-PE link, the IP address of 281 the CE/VM, the zone(s) that it belongs to, QoS policies etc. There 282 are many ways to accomplish this step, a description of which is 283 outside the scope of this document. 285 When the CE/VM is activated, the attached PE starts exporting its IP 286 address with the corresponding zone-RT. This allows unrestricted any- 287 to-any communication between the newly active VM and the rest of the 288 VMs in the zone. 290 Note that the IP address mask of the CE/VM that the PE advertises 291 along with the CE's address need not necessarily be a /32 for IPv4, 292 and /128 for IPv6. This is the case when the CE/VM's in a zone belong 293 to a single IP subnet. The PE, in this case, would use proxy-arp to 294 resolve ARP's for remote destinations in the IP subnet. 296 Alternatively, there may be a pool of dedicated service appliances 297 which support multiple contexts. 299 The classification of VMs into a zone is driven by the communication 300 and security policy and is independent of the addressing for the VMs. 301 The VMs in a zone may be in the same or different IP subnets with 302 user-defined mask-lengths. The PE advertises /32 routes to advertise 303 reachability to a locally attached VM. If two VMs are in the same IP 304 subnet, the PE employs proxy-ARP to assist the VM resolve ARP for 305 other VMs in the IP subnet, and uses IP forwarding to carry traffic 306 between the VMs. When a VM is remotely attached to another PE, BGP 307 IP-VPN forwarding is used. 309 3 Inter-Zone Routing and Traffic Forwarding 311 A simple form of inter-zone traffic forwarding can be achieved using 312 extranets BGP IP VPN configurations. However, extranet procedures do 313 not by themselves provide the ability to force inter-zone traffic 314 flows through a set of servers. 316 Note that the inter-zone services cannot always be assumed to reside 317 on a PE. There is a need to virtualize the services themselves so 318 that they can be implemented on commodity hardware and scaled out 319 'elastically' when traffic demands increase. Alternatively, there may 320 be a pool of dedicated service appliances which support multiple 321 contexts and hence multiple tenants, that are attached to different 322 PEs distributed across the DC.This creates a situation where services 323 for traffic between zones may not be applied only at the source-zone 324 PE or the destination-zone PE. Mechanisms are required that make it 325 easy to direct inter-zone traffic through the appropriate set of 326 service nodes that might be remote and virtualized. 328 A service node for the purposes of this proposal is a physical or 329 virtual service appliance that inspects and/or impacts the flow of 330 inter-zone traffic. Firewalls, load-balancers, deep packet inspectors 331 are examples of service nodes. Service nodes modeled as CEs, either 332 they are reside on a PE, or they are then attached to a service-PE. 334 A service-PE is a normal BGP IP VPN PE that recognizes and directs 335 the appropriate traffic flows to its attached service nodes through 336 VPN label lookup. Service nodes may be integrated or attached to 337 service-PEs. 339 A sequence of service-PE's and the corresponding service nodes create 340 a service chain for inter-zone traffic. The service chain is 341 unidirectional and creates a one way traffic flow between source zone 342 and destination zone. The first service PE in the path is called as 343 the source service-PE and the last service PE in the path is called 344 the destination service-PE, there can be arbitrary numbers of 345 service-PE between the source service-PE and the destination service- 346 PE. An example of a service chain may look like this: ingress-PE --> 347 source-service-PE --> other-service-PE --> destination-service-PE --> 348 egress-PE. 350 4 Proposed Inter-Zone Model 352 The proposed model has two steps to it. 354 4.1 Constructing the Virtual Service Topology 356 The first step involves creating the virtual service topology that 357 ties two or more zones through one or more service nodes. 359 This is done by originating a service topology route that creates the 360 route resolution state for the zone prefixes in a set of service-PEs. 361 The service topology route is originated in the destination service- 362 PE. It then propagates through the series of service-PE's from the 363 destination service-PE to the source service-PE. 365 """""""""""""""""""""" """""""""""""""""""""" 366 " +-------+ " +--------+ +--------+ " +-------+ " 367 " +-----+ | vPE-1 | " |ServPE-A| |ServPE-B| " | vPE-2 | +-----+ " 368 " |VM/CE|--| |---| |---| |---| |--|VM/CE| " 369 " +-----+ |(VRF-1)| " |(VRF-A) | |(VRF-B) | " |(VRF-2)| +-----+ " 370 " +-------+ " +--------+ +--------+ " +-------+ " 371 " " | | " " 372 " Zone 1 " +--------+ +--------+ " Zone 2 " 373 """""""""""""""""""""" | Serv-A | | Serv-B | """""""""""""""""""""" 374 +--------+ +--------+ 376 Figure 1. Construct of Service Chain Topology 378 A modification is proposed to the service-PE behavior to allow the 379 automatic and constrained propagation of service topology routes 380 through the service-PE's that form the service chain. A service-PE in 381 a given service chain is provisioned to accept the service topology 382 route and re-originate it such that the upstream service-PE imports 383 it and so on. The sequential import and export of the service 384 topology route along the service chain is controlled by RTs 385 provisioned appropriately at each service-PE. 387 To create the service chain and give it a unique identity, each 388 service-PE is provisioned with three service RT's per VRF for every 389 service chain that it belongs to: {service-import-RT, service-export- 390 RT, service-topology-RT}. 392 A service-import-RT acts exactly as a regular import RT importing any 393 route that carries that RT into the service-VRF. Additionally, any 394 route that was imported using the service-import-RT MUST be 395 automatically re-originated with the corresponding service-export-RT. 397 The next-hop of the re-originated route points to the service node 398 attached to the service-PE. The VPN label carried in the re- 399 originated route directs all traffic received by the service-PE to 400 the service node. 402 The service-export-RT of a downstream service-PE MUST be equal to the 403 service-import-RT of the immediate upstream service-PE. The service 404 topology route MUST be originated in the destination service-PE 405 carrying its service-export-RT. The flow of the service topology 406 route creates both the service chain as well as the route resolution 407 state for the zone prefixes. 409 Finally, the presence of the service topology route in a service-PE 410 triggers the addition of the service-topology-RT to the regular 411 import RT's of the service-VRF. Every service chain has a single 412 unique service-topology-RT that's provisioned in all participating 413 service-PE's. 415 The three service RT's (import, export and topology) are special RTs 416 which should not be reused for other purposes within the network. The 417 service RT's that establish the chain and give it its identity can be 418 pre-provisioned or activated due to the appearance of a attached 419 virtual service node. The provisioning system is assumed to have the 420 intelligence to create loop-free virtual service topologies. 422 There should be one service topology route per virtual service 423 topology. There can be multiple virtual service topologies and hence 424 service topology routes for a given VPN. 426 Virtual service topologies are constructed unidirectionally. Between 427 the same pair of zones, traffic in opposite directions will be 428 supported by two service topologies and hence two service topology 429 routes. These two service topologies might or might not be 430 symmetrical, i.e. they might or might not traverse the same service- 431 PE's/service-nodes in opposite directions. 433 As noted above, a service topology route can be advertised with a 434 per-next-hop label that directs incoming traffic to the attached 435 service node. Alternatively, an aggregate label may be used for the 436 service route and an IP route lookup done at the service-PE to send 437 traffic to the service node. 439 Note that a new service node could be inserted seamlessly by just 440 configuring the three service RT's in the attached service-PE. This 441 technique could be used to elastically scale out the service nodes 442 with traffic demand. 444 The distribution of the service topology route itself can be 445 controlled by RT constrains [RFC4684] to only the interesting 446 service-PE's. 448 Finally, note that the service topology route is independent of the 449 zone prefixes which are the actual addresses of the VMs present in 450 the various zones. The zone prefixes use the service topology route 451 to resolve their next-hop. 453 4.2 Inter-zone Routing and Service Chaining 455 Routes representing hosts or VMs from a zone are called zone 456 prefixes. A zone prefix will have its regular zone RTs attached when 457 it is originated. This will be used by PEs in the same zone to import 458 these prefixes to enable direct communication between VM's of the 459 same zone. 461 In addition to the intra-zone RT's, zone prefixes are also tagged at 462 the point of origination with the set of service-topology-RTs to 463 which they belong. 465 Since they are tagged with the service-topology-RT, zone prefixes get 466 imported into the appropriate service-VRF's of particular service- 467 PE's that form the service chain associated to that topology RT. Note 468 that the topology RT was added to the relevant service-VRF's import 469 RT list during the virtual topology construction phase. 471 Once the zone prefixes are imported into the service-PE, their next- 472 hops are resolved as follows. 474 - If the importing service-PE is the destination service-PE, it uses 475 the next hop that came with the zone prefix for route resolution. It 476 also uses the VPN label that came with the prefix. 478 - If the importing service-PE is not the destination service-PE, it 479 rewrites the received next-hop of the zone prefix with the service 480 topology route. 482 In an MPLS VPN, the zone prefixes come with VPN labels. The labels 483 also must be ignored when in the intermediate service-PEs. Instead, 484 the zone prefix gets resolved via the service topology route and uses 485 the associated service route's VPN label. 487 This way the zone prefixes in the intermediate service-PE hops 488 recurse over the service topology route forcing the traffic destined 489 to them flow through the virtual service topology. 491 Traffic for the zone prefix goes through the service hops created by 492 the service topology route. At each service hop, the service-PE 493 directs the traffic to the service node. Once the service node is 494 done processing the traffic, it then sends it back to the service-PE 495 which forwards the traffic to the next service-PE and so on. 497 A significant benefit of this next-hop indirection is to avoid 498 redundant advertisement of zone prefixes from the service-PE's. Also, 499 when the virtual service topology is changed (due to addition or 500 removal of service-PEs), there should be no change to the zone 501 prefix's import/export RT configuration. 503 Note that this proposal introduces a change in the behavior of the 504 service-PE's but does not require protocol changes to BGP. 506 5 Routing Considerations 507 5.1 Multiple service topologies 509 A service-PE can support multiple distinct service topologies for a 510 VPN. 512 5.2 Multipath 514 One could use all tools available in BGP to constrain the propagation 515 and resolution state created by the service topology route. A service 516 topology route can have multiple equal cost paths, for inter-zone 517 traffic to get load-balanced over. 519 5.3 Supporting redundancy 521 For stateful services an active-standby mechanism could be used at 522 the service level. In this case, the inter-zone traffic should prefer 523 the active service node over the standby service node. 525 At a routing level, this is achieved by setting up two paths for the 526 same service topology route - one path goes through the active 527 service node and the other through the standby service node. The 528 active service path can then be made to win over the standby service 529 path by appropriately setting the BGP path attributes of the service 530 topology route such that the active path succeeds in path selection. 531 This forces all inter-zone traffic through the active service node. 533 5.4 Route Aggregation 535 Instead of the actual zone prefixes being imported and used at 536 various points along the chain, the zone prefixes may be aggregated 537 at the destination service-PE and the aggregate zone prefix used in 538 the service chain between zones. In such a case, it is the aggregate 539 zone prefix that carries the service-topology-RT and gets imported in 540 the service-PE's that comprise the service chain. 542 6 Security Considerations 544 This proposal does not change the security model of MPLS/VPN BGP. 546 7 IANA Considerations 548 This proposal does not have any IANA implications. 550 8 Acknowledgements 552 The authors would like to thank the following individuals for their 553 review and feedback on the proposal: Eric Rosen, Jim Guichard, Paul 554 Quinn, David Ward, Ashok Ganesan. 556 9 References 558 9.1 Normative References 560 [RFC4364] Rosen, E., "BGP/MPLS IP Virtual Private Networks (VPNs)", 561 RFC4364. 563 [RFC4684] Marques, P., "Constrained Route Distribution for Border 564 Gateway Protocol/Multiprotocol Label Switching (BGP/MPLS) 565 Internet Protocol (IP) Virtual Private Networks (VPNs) 567 Authors' Addresses 569 Dhananjaya Rao 570 Cisco 571 170 W Tasman Dr 572 San Jose, CA 573 US 574 Email: dhrao@cisco.com 576 Rex Fernando 577 Cisco 578 170 W Tasman Dr 579 San Jose, CA 580 US 581 Email: rex@cisco.com 582 Luyuan Fang 583 Cisco 584 170 W Tasman Dr 585 San Jose, CA 586 US 587 Email: lufang@cisco.com 589 Maria Napierala 590 AT&T 591 200 Laurel Avenue 592 Middletown, NJ 07748 593 US 594 Email: mnapierala@att.com 596 Nabil Bitar 597 Verizon 598 40 Sylvan Road 599 Waltham, MA 02145 600 US 601 Email: nabil.bitar@verizon.com 603 Ning So 604 Tata Communications 605 Plano, TX 75082, USA 606 Email: ning.so@tatacommunications.com