idnits 2.17.1 draft-rfernando-l3vpn-service-chaining-03.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 (October 18, 2013) is 3843 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Fernando 2 Intended Status: Standards track D. Rao 3 Expires: April 18, 2014 L. Fang 4 Cisco 5 M. Napierala 6 AT&T 7 N. So 8 Tata Communications 9 A. Farrel 10 Juniper Networks 12 October 18, 2013 14 Virtual Topologies for Service Chaining in BGP/IP MPLS VPNs 16 draft-rfernando-l3vpn-service-chaining-03 18 Abstract 20 This document presents techniques built upon BGP/IP MPLS VPN control 21 plane mechanisms to construct virtual topologies for service 22 chaining. These virtual service topologies interconnect network zones 23 and constrain the flow of traffic between these zones via a sequence 24 of service nodes so that service functions can be applied to the 25 traffic. 27 This document also describes approaches enabled by both the routing 28 control plane and by network orchestration to realize these virtual 29 service topologies. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2013 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Intra-Zone Routing and Traffic Forwarding. . . . . . . . . . . 5 72 3. Inter-Zone Routing and Traffic Forwarding. . . . . . . . . . . 7 73 3.1 Traffic Forwarding Operational Flow . . . . . . . . . . . . 8 74 4. Inter-Zone Model . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1 Constructing the Virtual Service Topology . . . . . . . . . 9 76 4.2 Per-VM Service Chains. . . . . . . . . . . . . . . . . . . . 12 77 5. Routing Considerations . . . . . . . . . . . . . . . . . . . . 12 78 5.1 Multiple Service Topologies . . . . . . . . . . . . . . . . 12 79 5.2 Multipath . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.3 Supporting Redundancy . . . . . . . . . . . . . . . . . . . 12 81 5.4 Route Aggregation . . . . . . . . . . . . . . . . . . . . . 13 82 6. Orchestration Driven Approach . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 84 8. Management Considerations. . . . . . . . . . . . . . . . . . . 13 85 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 86 10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14 87 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 11.1 Normative References . . . . . . . . . . . . . . . . . . . 14 89 11.2 Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 Network topologies and routing design in enterprise, data center, and 95 campus networks typically reflect the needs of the organization in 96 terms of performance, scale, security, and availability. For scale 97 and security reasons, these networks may be composed of multiple 98 small domains or zones each serving one or more functions of the 99 organization. 101 A network zone is a logical grouping of physical assets that supports 102 certain applications. Hosts can communicate freely within a zone. 103 That is, a datagram traveling between two hosts in the same zone is 104 not routed through any servers that examine the datagram payload and 105 apply services (such as security or load balancing) to the traffic. 106 But a datagram traveling between hosts in different zones may be 107 subject to additional services to meet the needs of scaling, 108 performance, and security for the applications or the networks 109 themselves. 111 Networks have achieved division into zones and the imposition of 112 services through a combination of physical topology constraints and 113 routing. For example, one can force datagrams to go through a 114 firewall (FW) by putting the FW in the physical data path from a 115 source to the destination, or by causing the routed path form source 116 to destination to go via an W that would not normally be on the path. 117 Similarly, the datagrams may need to go through a security gateway 118 for security services, or a Load Balancer (LB) for load balancing 119 services. 121 In virtualized data centers, appliances, applications, and network 122 functions, including IP VPN provider edge (PE) and customer edge (CE) 123 functions are all commonly virtualized. That is, they exist as 124 software instances residing in servers or appliances instead of 125 individual (dedicated) physical devices. 127 Migrating a network with all its functions and infrastructure 128 elements to realization in a virtualized data center requires network 129 overlay mechanisms that provide the ability to create virtual network 130 topologies that mimic physical networks, and that provide the ability 131 to constrain the flow of routing and traffic over these virtual 132 network topologies. 134 A data center uses a virtual topology in which the servers are in the 135 "virtual" data path, rather than in the physical data path. For 136 example, a traffic flow might previously have had the source PE-1 and 137 destination at an Autonomous System Border Router (ASBR), ASBR-1, and 138 the flow might have needed to be serviced by FW-1 and LB-1. In this 139 case its path would have been PE-1, FW-1, LB-1, ASBR-1. However, in a 140 virtualized data center, the functions of all four nodes could be 141 provided by virtual nodes that could be placed at arbitrary locations 142 across the data center. Thus the "virtual service chain" vPE-1, 143 vFW-1, vLB-1, vASBR-1, that is the sequence of virtual service nodes 144 that packet must traverse, could be realized by a path between 145 arbitrary physical locations in the data center. 147 A data center will likely support multiple tenants. A tenant is a 148 customer who uses the virtualized data center services. Each tenant 149 might require different connectedness (i.e., a different virtual 150 topology) between their zones and applications, and might need the 151 ability to apply different network policies such that the services 152 for inter-zone traffic are applied in a specific order according to 153 the organization objectives of the tenant. Furthermore, a data center 154 might need multiple virtual topologies per tenant to handle different 155 types of application traffic. 157 Additionally, a data center operator may choose to provide services 158 for multiple tenants on the same virtualized end device, for example, 159 a server. Such multi-tenant devices must utilize techniques such as 160 routing isolation to retain separation between tenants' traffic. 162 To address all of these requirements, the mechanisms devised for use 163 in a data center need to be flexible enough to accommodate the custom 164 needs of the tenants and their applications, and at the same time 165 must be robust enough to satisfy the scale, performance, and high 166 availability needs that are demanded by the operator of the virtual 167 network infrastructure that has a very large number of tenants each 168 with different application types, large networks, multiple services, 169 and high-volume traffic. 171 Toward this end, this document introduces the concept of virtual 172 service topologies and extends IP MPLS VPN control plane mechanisms 173 to constrain routing and traffic flow over virtual service 174 topologies. 176 The creation of these topologies and the setting up of the forwarding 177 tables to steer traffic over them may be carried out either by 178 extensions to IP MPLS VPN procedures and functionality at the PEs, or 179 via a "software defined networking" (SDN) approach. This document 180 specifies the use of both approaches, but uses the IP MPLS VPN option 181 to illustrate the various steps involved. 183 1.1 Terminology 185 This document uses the following acronyms and terms. 187 Terms Meaning 188 ----- -------------------------------------------------- 189 AS Autonomous System 190 ASBR Autonomous System Border Router 191 CE Customer Edge 192 FW Firewall 193 I2RS Interface to the Routing System 194 L3VPN Layer Three VPN 195 LB Load Balancer 196 NLRI Network Layer Reachability Information [RFC4271] 197 P Provider backbone router 198 proxy-arp proxy-Address Resolution Protocol 199 RR Route Reflector 200 RT Route Target 201 SDN Software Defined Network 202 vCE virtual Customer Edge router 203 [I-D.fang-l3vpn-virtual-ce] 204 vFW virtual Firewall 205 vLB virtual Load Balancer 206 VM Virtual Machine 207 vPC virtual Private Cloud 208 vPE virtual Provider Edge router 209 [I-D.fang-l3vpn-virtual-pe] 210 VPN Virtual Private Network 211 VRF VPN Routing and Forwarding table [RFC4364] 212 vRR virtual Route Reflector 214 This document also uses the following general terms: 216 Service-PE: 217 A BGP/IP MPLS VPN PE to which a service node in a virtual service 218 topology is attached. The PE directs incoming traffic from other 219 PEs or from attached hosts to the service node via an MPLS VPN 220 label or IP lookup. The PE also forwards traffic from the service 221 node to the next node in the chain. A Service-PE is a logical 222 entity and a given PE may be attached to both a service node and 223 an application host VM. 225 Service node: 226 A physical or virtual service appliance/application which inspects 227 and/or redirects the flow of inter-zone traffic. Examples of 228 service nodes include FWs, LBs, and deep packet inspectors. The 229 service node acts as a CE in the VPN network. 231 Service chain: A sequence of service nodes that interconnect the 232 zones containing the source and destination hosts. The service 233 chain is unidirectional and creates a one way traffic flow between 234 source zone and destination zone. 236 Virtual service topology: 237 A virtual service topology consists of a sequence of service-PEs 238 and their attached service nodes created in a specific order. A 239 service topology is constructed via one or more routes that direct 240 the traffic flow among the PEs that form the service chain. 242 Service-topology-RT: 243 A BGP route attribute that identifies the specific service 244 topology. 246 Tenant: 247 A tenant is a higher-level management construct. In the control/ 248 forwarding plane it is the collection of various virtual networks 249 that get instantiated. A tenant may have more than one virtual 250 network or VPN. 252 Zone: 253 A logical grouping of physical assets that supports certain 254 applications or a subset thereof. VMs or hosts can communicate 255 freely within a zone. 257 2. Intra-Zone Routing and Traffic Forwarding 259 This section provides a brief overview of how the BGP/IP MPLS VPN 260 [RFC4364] control plane can be used in a DC network to used to divide 261 the network into a number of zones. The subsequent sections in the 262 document build on this base model to create inter-zone service 263 topologies by interconnecting these zones and forcing inter-zone 264 traffic to travel through a sequence of servers where the sequence of 265 servers depends on the tuple . 268 The notion of a BGP/IP VPN when applied to the virtual data center 269 works in the following manner. 271 The VM that runs the applications in the server is treated as a CE 272 attached to the VPN. A CE/VM belongs to a zone. The PE is the first 273 hop router from the CE/VM and the PE-CE link is single hop from a 274 laye-3 perspective. Any of the available physical, logical or 275 tunneling technologies can be used to create this "direct" link 276 between the CE/VM and its attached PE(s). 278 If a PE attaches to one or more CEs of a certain zone, the PE must 279 have exactly one VRF for that zone, and the PE-CE links to those CEs 280 must all be associated with that VRF. Intra-zone connectivity between 281 CE/VMs that attach to different PEs is achieved by designating an RT 282 per zone (zone-RT) that is both an import RT and an export RT of all 284 PE VRFs that terminate the CE/VMs that belong to the zone. A VM may 285 have multiple virtual interfaces that attach to different zones. 287 It is further assumed that the CE/VMs are associated with network 288 policies that are activated on an attached PE when a CE/VM is 289 instantiated. These policies dictate how the network is set up for 290 the CE/VM including the properties of the CE-PE link, the IP address 291 of the CE/VM, the zones to which it belongs, QoS policies, etc. There 292 are many ways to accomplish this step, but a description of such 293 mechanisms is outside the scope of this document. 295 When the CE/VM is activated, the attached PE starts to export the 296 CEs IP address with the corresponding zone-RT. This allows 297 unrestricted any-to-any communication between the newly active VM and 298 the rest of the VMs in the zone. 300 The classification of VMs into a zone is driven by the communication 301 and security policy and is independent of the addressing scheme for 302 the VMs. The VMs in a zone may be in the same or different IP subnets 303 with user-defined mask-lengths. The PE advertises /32 routes to 304 advertise reachability to locally attached VMs. If two VMs are in the 305 same IP subnet, the PE may employ proxy-ARP to assist the VM to 306 resolve ARP for other VMs in the IP subnet, and may use IP forwarding 307 to carry traffic between the VMs. When a VM is attached to a remote 308 PE, IP VPN forwarding is used to tunnel packets to the remote PE. 310 3. Inter-Zone Routing and Traffic Forwarding 312 A simple form of inter-zone traffic forwarding can be achieved using 313 extranets or hub-and-spoke L3VPN configurations [RFC7024]. However, 314 the ability to enforce constrained traffic flowa through a set of 315 services is non-existent in extranets and is limited in hub-and-spoke 316 setups. 318 Note that the inter-zone services cannot always be assumed to reside 319 and be in-lined on a PE. There is a need to virtualize the services 320 themselves so that they can be implemented on commodity hardware and 321 scaled out 'elastically' when traffic demands increase. This creates 322 a situation where services for traffic between zones may be applied 323 not only at the source-zone PE or the destination-zone PE. Mechanisms 324 are required that make it easy to direct inter-zone traffic through 325 the appropriate set of service nodes that might be remote or 326 virtualized. 328 3.1 Traffic Forwarding Operational Flow 330 Traffic from a source endpoint (a VM/CE) in a source zone reaches an 331 ingress zone-PE and is associated with a VRF in that zone as 332 described above. The zone-PE will forward the traffic and direct it 333 toward the first service-node. If the service-node is attached to the 334 zone-PE, the zone-PE will forward the packets out of one of its 335 access interfaces. If the service-node is attached to a different 336 service-PE, the zone-PE will encapsulate the packets and send them 337 toward the service-PE. The zone-PE and service PE may be connected 338 via an intermediate network of devices and the encapsulation causes 339 the packets to be tunneled across this intermediate network. 341 The service-PE will receive these encapsulated packets from the 342 source zone-PE, decapsulate them, and forward them to its attached 343 service-node. The traffic that comes back to the service-PE from the 344 service-node must now be forwarded to the next service-node in the 345 chain. As above, the next service-node may be locally attached or at 346 a remote service-PE. 348 At the last service-PE in the chain, the traffic that comes back from 349 a service-node must be forwarded to the destination in the target 350 zone. Just as with the service-nodes, the destination may be attached 351 to the service-PE or reachable via another PE. 353 As can be seen from this description, a given packet flow needs to be 354 forwarded differently at each PE depending on whether it is arriving 355 from a node attached to the PE or from a remote PE, and depending on 356 whether the traffic is to be routed toward a node attached to the PE 357 or attached to a remote PE. The next-hop for a flow changes depending 358 on the relative position within the service chain. 360 Figure 1 illustrates a virtual service topology, where hosts in Zone 361 1 are interconnected with hosts in Zone 2 via two service nodes 362 (Serv-A and Serv-B) attached to two service-PEs (S-PE-A and S-PE-B 363 respectively). 365 """""""""""""""""""""" """""""""""""""""""""" 366 " +-------+ " +--------+ +--------+ " +-------+ " 367 " +-----+ | vPE-1 | " | S-PE-A | | S-PE-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. Virtual Service Topology Illustration 378 The different forwarding paths can be achieved at any PE as follows. 380 o Each service node is associated with two VRFs at the service PE to 381 which it is attached: an in-VRF for traffic toward the service 382 node, and an out-VRF for traffic from the service node. 384 o Traffic for the in-VRF arrives from the previous node in the 385 service chain, and traffic for the out-VRF is destined toward the 386 next node in the service chain, or toward the destination zone. 388 o The in-VRF has one or more routes with a next-hop of a local access 389 interface where the service node is attached. The out-VRF has 390 routes with a next-hop of the next service node, which may be 391 situated locally on the service-PE or at a remote PE. 393 The installation of the forwarding entries to implement the flow 394 described above may be achieved either via IP VPN mechanisms 395 described in Sections 4 and 5, or using an SDN approach, as described 396 in Section 6. 398 4. Inter-Zone Model 400 The inter-zone model has the following steps. 402 4.1 Constructing the Virtual Service Topology 404 The virtual service topology described in the previous section is 405 constructed via one or more routes that direct the traffic flow among 406 the PEs forming the service chain. There should be a route per 407 service node. The service topologies, and hence the service routes, 408 are constructed on a per-VPN basis. This service topology is 409 independent of the routes for the actual destination for a flow, 410 i.e., the addresses of the VMs present in the various zones. There 411 can be multiple service topologies for a given VPN. 413 4.1.1 Reachability to the Service Nodes 415 Each service node is identified by an IP address that is scoped 416 within the VPN. The service node is also associated with an in-VRF 417 and out-VRF at the attached service node. 419 Reachability to the various service nodes in the service chain occurs 420 via regular BGP/IP VPN route advertisements. 422 A service-PE will export a route for each service node attached to 423 it. Each route will contain the Route-Target configured for the VPN, 424 and a forwarding label that is associated with the logical in-VRF for 425 a service node on the service-PE. This label enables the service-PE 426 to directly forward incoming traffic from the other PEs to the 427 service node. 429 The routes to reach the various service nodes are imported into and 430 installed in each out-VRF at a service-PE, as well as in the zone VRF 431 on the ingress zone-PE. 433 4.1.2 Provisioning the Service Chain 435 At each PE supporting a given VPN, the sequence of service nodes in a 436 service chain can be specified in a VPN service route policy. 438 To create the service chain and give it a unique identity, each PE 439 may be provisioned with the following tuple for every service chain 440 that it belongs to: 442 {Service-topology-RT, Service-node-Sequence} 444 where Service-node-Sequence is simply an ordered list of the service 445 node IP addresses that are in the chain. 447 Every service chain has a single unique service-topology-RT that is 448 provisioned in all participating PEs. 450 A PE will also be provisioned with the tables and/or configuration 451 that support the various zones and the in- and out- VRFs for the 452 services. 454 4.1.3 Zone Prefix Next-Hop Resolution 456 Routes representing hosts or VMs from a zone are called zone 457 prefixes. A zone prefix will have its regular zone RTs attached when 458 it is originated. This will be used by PEs in the same zone to import 459 these prefixes to enable direct communication between VMs in the same 460 zone. 462 In addition to the intra-zone RTs, zone prefixes are also tagged at 463 the point of origination with the set of service-topology-RTs to 464 which they belong. 466 Since they are tagged with the zone-RT, zone prefixes get imported 467 into the VRFs of the service-PEs that form the service chain 468 associated to that topology RT. Note that the zone-RT was added to 469 the relevant VRF's import RT list during the virtual topology 470 construction phase. These routes may be installed in the in-VRF and 471 out-VRF at the service-PEs as well as in the ingress zone VRF. 473 Note that this approach introduces a change in the behavior of the 474 service-PEs compared to normal BGP VPN behavior, but does not require 475 protocol changes to BGP. This modification to PE behavior allows the 476 automatic and constrained flow of traffic via the service chain. 478 The PE, based on the presence of the configured Service-topology-RT 479 in the received zone routes, will perform the following actions: 481 1. It will ignore the next-hop and VPN label that were advertised in 482 the NLRI. 484 2. Instead, it will select the appropriate Service next-hop from the 485 Service-node sequence associated with the Service-topology-RT. 487 3. It will further resolve this Service next-hop IP address locally 488 in the associated VRF, instead of in the global routing table. It 489 will use the next-hop and label associated with this IP address to 490 encapsulate traffic toward the next service node. 492 4. If the importing service-PE is the last service-PE, it uses the 493 next hop that came with the zone prefix for route resolution. It 494 also uses the VPN label that came with the prefix. 496 In this way the zone prefixes in the intermediate service-PE hops 497 recurse over the service chain forcing the traffic destined to them 498 to flow through the virtual service topology. 500 Traffic for the zone prefix goes through the service hops created by 501 the service topology. At each service hop, the service-PE directs the 502 traffic to the service node. Once the service node is done processing 503 the traffic, it sends it back to the service-PE which forwards the 504 traffic to the next service-PE, and so on. 506 A significant benefit of this next-hop indirection is to avoid 507 redundant advertisement of zone prefixes from the end-zone or 508 service-PEs. Also, when the virtual service topology is changed (due 509 to addition or removal of service-PEs), there should be no change to 510 the zone prefix's import/export RT configuration. 512 There should be one service topology RT per virtual service topology. 513 There can be multiple virtual service topologies and hence service 514 topology RTs for a given VPN. 516 Virtual service topologies are constructed unidirectionally. Traffic 517 in opposite directions between the same pair of zones will be 518 supported by two different service topologies and hence two service 519 topology routes. These two service topologies might or might not be 520 symmetrical, i.e.m they might or might not traverse the same sequence 521 of service-PEs/service-nodes in opposite directions. 523 As noted above, a service node route can be advertised with a label 524 that directs incoming traffic to the attached service node. 525 Alternatively, an aggregate label may be used for the service route 526 and an IP route lookup done at the service-PE to send traffic to the 527 service node. 529 Note that a new service node could be inserted into the service 530 chain seamlessly by just configuring the service policy 531 appropriately. 533 4.2 Per-VM Service Chains 535 While the service-topology-RT allows an efficient inheritance of the 536 service chain for all VMs in a zone, there may be a need to create a 537 distinct service chain for an individual VM. This may be done by 538 provisioning a separate service-topology RT and service node 539 sequence. The VM route carries the service-topology RT, and the 540 destination service-zone is provisioned with this RT as its Service- 541 Import RT. 543 5. Routing Considerations 545 5.1 Multiple Service Topologies 547 A service-PE can support multiple distinct service topologies for a 548 VPN. 550 5.2 Multipath 552 One could use all tools available in BGP to constrain the propagation 553 and resolution of state created by the service topology [RFC4684]. 555 Additional service nodes can be introduced to scale out a particular 556 service. Each such service would be represented by a virtual IP 557 address, and multiple service nodes associated with it. Multiple 558 service-PEs may advertise a route to this address based on the 559 presence of an attached service node instance, thereby creating 560 multiple equal cost paths. This technique could be used to 561 elastically scale out the service nodes with traffic demand. 563 5.3 Supporting Redundancy 565 For stateful services an active-standby mechanism could be used at 566 the service level. In this case, the inter-zone traffic should prefer 567 the active service node over the standby service node. 569 At a routing level, this is achieved by setting up two paths for the 570 same service node route: one path goes through the active service 571 node and the other through the standby service node. The active 572 service path can then be made to win over the standby service path by 573 appropriately setting the BGP path attributes of the service topology 574 route such that the active path succeeds in path selection. This 575 forces all inter-zone traffic through the active service node. 577 5.4 Route Aggregation 579 Instead of the actual zone prefixes being imported and used at 580 various points along the chain, the zone prefixes may be aggregated 581 at the destination service-PE and the aggregate zone prefix used in 582 the service chain between zones. In such a case, it is the aggregate 583 zone prefix that carries the service-topology-RT and gets imported in 584 the service-PEs that comprise the service chain. 586 6. Orchestration Driven Approach 588 In an orchestration driven approach, there is no need for the zone or 589 service PEs to determine the appropriate next-hops based on the 590 specified service node sequence. All the necessary policy 591 computations are carried out, and the forwarding tables for the 592 various VRFs at the PEs determined, by the central orchestrator. 594 The orchestrator communicates with the various PEs (typically virtual 595 PEs on the end-servers) to populate the forwarding tables. 597 The protocol used to communicate between the controller/orchestration 598 and the PE/vPE must be a standard, programmatic interface. The 599 programmatic interface are currently under definition in the IETF's 600 Interface to Routing Systems (I2RS) initiative, 601 [I-D.ietf-i2rs-architecture], [I-D.ietf-i2rs-problem-statement]. 603 7. Security Considerations 605 To be added. 607 8. Management Considerations 609 To be added. 611 9. IANA Considerations 613 This proposal does not have any IANA implications. 615 10. Acknowledgements 617 The authors would like to thank the following individuals for their 618 review and feedback on the proposal: Eric Rosen, Jim Guichard, Paul 619 Quinn, Peter, Bosch, David Ward, Ashok Ganesan. The option of 620 configuring an ordered sequence of service nodes via policy is 621 derived from a suggestion from Eric Rosen. 623 11. References 625 11.1 Normative References 627 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 628 Networks (VPNs)", RFC 4364, February 2006. 630 11.2 Informative References 632 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 633 Protocol 4 (BGP-4)", RFC 4271, January 2006. 635 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 636 R., Patel, K., and J. Guichard, "Constrained Route 637 Distribution for Border Gateway Protocol/MultiProtocol 638 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 639 Private Networks (VPNs)", RFC 4684, November 2006. 641 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 642 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 643 VPNs", RFC 7024, October 2013. 645 [I-D.fang-l3vpn-virtual-ce] 646 L. Fang, et al.,"BGP/MPLS IP VPN Virtual CE", 647 draft-fang-l3vpn-virtual-ce, work in progress. 649 [I-D.fang-l3vpn-virtual-pe] 650 L. Fang, et al., "BGP/MPLS IP VPN Virtual PE", 651 draft-fang-l3vpn-virtual-pe, work in progress. 653 [I-D.ietf-i2rs-architecture] 654 Atlas, A., Halpern, J., Hares, S., Ward, D., and T Nadeau, 655 "An Architecture for the Interface to the Routing System", 656 draft-ietf-i2rs-architecture, work in progress. 658 [I-D.ietf-i2rs-problem-statement] 659 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 660 Routing System Problem Statement", 661 draft-ietf-i2rs-problem-statement, work in progress. 663 Authors' Addresses 665 Dhananjaya Rao 666 Cisco 667 170 W Tasman Dr 668 San Jose, CA 669 Email: dhrao@cisco.com 671 Rex Fernando 672 Cisco 673 170 W Tasman Dr 674 San Jose, CA 675 Email: rex@cisco.com 677 Luyuan Fang 678 Cisco 679 170 W Tasman Dr 680 San Jose, CA 681 Email: luyuanf@gmail.com 683 Maria Napierala 684 AT&T 685 200 Laurel Avenue 686 Middletown, NJ 07748 687 Email: mnapierala@att.com 689 Ning So 690 Tata Communications 691 Plano, TX 75082, USA 692 Email: ning.so@tatacommunications.com 694 Adrian Farrel 695 Juniper Networks 696 Email: adrian@olddog.co.uk