idnits 2.17.1 draft-rfernando-l3vpn-service-chaining-04.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 : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3582 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: 'I-D.ietf-i2rs-problem-statement' is defined on line 659, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-rfernando-ipse-00 Summary: 1 error (**), 0 flaws (~~), 3 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: January 5, 2015 Cisco 5 L. Fang 6 Microsoft 7 M. Napierala 8 AT&T 9 N. So 10 Vinci Systems 11 A. Farrel 12 Juniper Networks 14 July 4, 2014 16 Virtual Topologies for Service Chaining in BGP/IP MPLS VPNs 18 draft-rfernando-l3vpn-service-chaining-04 20 Abstract 22 This document presents techniques built upon BGP/IP MPLS VPN control 23 plane mechanisms to construct virtual topologies for service 24 chaining. These virtual service topologies interconnect network zones 25 and constrain the flow of traffic between these zones via a sequence 26 of service nodes so that service functions can be applied to the 27 traffic. 29 This document also describes approaches enabled by both the routing 30 control plane and by network orchestration to realize these virtual 31 service topologies. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Intra-Zone Routing and Traffic Forwarding. . . . . . . . . . . 5 74 3. Inter-Zone Routing and Traffic Forwarding. . . . . . . . . . . 7 75 3.1 Traffic Forwarding Operational Flow . . . . . . . . . . . . 8 76 4. Inter-Zone Model . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.1 Constructing the Virtual Service Topology . . . . . . . . . 9 78 4.2 Per-VM Service Chains. . . . . . . . . . . . . . . . . . . . 12 79 5. Routing Considerations . . . . . . . . . . . . . . . . . . . . 12 80 5.1 Multiple Service Topologies . . . . . . . . . . . . . . . . 12 81 5.2 Multipath . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.3 Supporting Redundancy . . . . . . . . . . . . . . . . . . . 12 83 5.4 Route Aggregation . . . . . . . . . . . . . . . . . . . . . 13 84 6. Orchestration Driven Approach . . . . . . . . . . . . . . . . . 13 85 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 86 8. Management Considerations. . . . . . . . . . . . . . . . . . . 13 87 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 88 10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 14 89 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 11.1 Normative References . . . . . . . . . . . . . . . . . . . 14 91 11.2 Informative References . . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 Network topologies and routing design in enterprise, data center, and 97 campus networks typically reflect the needs of the organization in 98 terms of performance, scale, security, and availability. For scale 99 and security reasons, these networks may be composed of multiple 100 small domains or zones each serving one or more functions of the 101 organization. 103 A network zone is a logical grouping of physical assets that supports 104 certain applications. Hosts can communicate freely within a zone. 105 That is, a datagram traveling between two hosts in the same zone is 106 not routed through any servers that examine the datagram payload and 107 apply services (such as security or load balancing) to the traffic. 108 But a datagram traveling between hosts in different zones may be 109 subject to additional services to meet the needs of scaling, 110 performance, and security for the applications or the networks 111 themselves. 113 Networks have achieved division into zones and the imposition of 114 services through a combination of physical topology constraints and 115 routing. For example, one can force datagrams to go through a 116 firewall (FW) by putting the FW in the physical data path from a 117 source to the destination, or by causing the routed path form source 118 to destination to go via a FW that would not normally be on the path. 119 Similarly, the datagrams may need to go through a security gateway 120 for security services, or a Load Balancer (LB) for load balancing 121 services. 123 In virtualized data centers, appliances, applications, and network 124 functions, including IP VPN provider edge (PE) and customer edge (CE) 125 functions are all commonly virtualized. That is, they exist as 126 software instances residing in servers or appliances instead of 127 individual (dedicated) physical devices. 129 Migrating a network with all its functions and infrastructure 130 elements to realization in a virtualized data center requires network 131 overlay mechanisms that provide the ability to create virtual network 132 topologies that mimic physical networks, and that provide the ability 133 to constrain the flow of routing and traffic over these virtual 134 network topologies. 136 A data center uses a virtual topology in which the servers are in the 137 "virtual" data path, rather than in the physical data path. For 138 example, a traffic flow might previously have had the source PE-1 and 139 destination at an Autonomous System Border Router (ASBR), ASBR-1, and 140 the flow might have needed to be serviced by FW-1 and LB-1. In this 141 virtualized data center, the functions of all four nodes could be 142 provided by virtual nodes that could be placed at arbitrary locations 143 across the data center. Thus the "virtual service chain" vPE-1, FW-1, 144 vLB-1, vASBR-1, that is the sequence of virtual service nodes that 145 packet must traverse, could be realized by a logical path between 146 arbitrary physical locations in the data center. 148 A data center will likely support multiple tenants. A tenant is a 149 customer who uses the virtualized data center services. Each tenant 150 might require different connectedness (i.e., a different virtual 151 topology) between their zones and applications, and might need the 152 ability to apply different network policies such that the services 153 for inter-zone traffic are applied in a specific order according to 154 the organization objectives of the tenant. Furthermore, a data center 155 might need multiple virtual topologies per tenant to handle different 156 types of application traffic. 158 Additionally, a data center operator may choose to provide services 159 for multiple tenants on the same virtualized end device, for example, 160 a server. Such multi-tenant devices must utilize techniques such as 161 routing isolation to retain separation between tenants' traffic. 163 To address all of these requirements, the mechanisms devised for use 164 in a data center need to be flexible enough to accommodate the custom 165 needs of the tenants and their applications, and at the same time 166 must be robust enough to satisfy the scale, performance, and high 167 availability needs that are demanded by the operator of the virtual 168 network infrastructure that has a very large number of tenants each 169 with different application types, large networks, multiple services, 170 and high-volume traffic. 172 Toward this end, this document introduces the concept of virtual 173 service topologies and extends IP MPLS VPN control plane mechanisms 174 to constrain routing and traffic flow over virtual service 175 topologies. 177 The creation of these topologies and the setting up of the forwarding 178 tables to steer traffic over them may be carried out either by 179 extensions to IP MPLS VPN procedures and functionality at the PEs, or 180 via a "software defined networking" (SDN) approach. This document 181 specifies the use of both approaches, but uses the IP MPLS VPN option 182 to illustrate the various steps involved. 184 1.1 Terminology 186 This document uses the following acronyms and terms. 188 Terms Meaning 189 ----- -------------------------------------------------- 190 AS Autonomous System 191 ASBR Autonomous System Border Router 192 CE Customer Edge 193 FW Firewall 194 I2RS Interface to the Routing System 195 L3VPN Layer 3 VPN 196 LB Load Balancer 197 NLRI Network Layer Reachability Information [RFC4271] 198 P Provider backbone router 199 proxy-arp proxy-Address Resolution Protocol 200 RR Route Reflector 201 RT Route Target 202 SDN Software Defined Network 203 vCE virtual Customer Edge router 204 [I-D.fang-l3vpn-virtual-ce] 205 vFW virtual Firewall 206 vLB virtual Load Balancer 207 VM Virtual Machine 208 vPC virtual Private Cloud 209 vPE virtual Provider Edge router 210 [I-D.fang-l3vpn-virtual-pe] 211 VPN Virtual Private Network 212 VRF VPN Routing and Forwarding table [RFC4364] 213 vRR virtual Route Reflector 215 This document also uses the following general terms: 217 Service-PE: 218 A BGP/IP MPLS VPN PE to which a service node in a virtual service 219 topology is attached. The PE directs incoming traffic from other 220 PEs or from attached hosts to the service node via an MPLS VPN 221 label or IP lookup. The PE also forwards traffic from the service 222 node to the next node in the chain. A Service-PE is a logical 223 entity and a given PE may be attached to both a service node and 224 an application host VM. 226 Service node: 227 A physical or virtual service appliance/application which inspects 228 and/or redirects the flow of inter-zone traffic. Examples of 229 service nodes include FWs, LBs, and deep packet inspectors. The 230 service node acts as a CE in the VPN network. 232 Service chain: A sequence of service nodes that interconnect the 233 zones containing the source and destination hosts or endpoints. The 234 service chain is unidirectional and creates a one way traffic flow 235 between source zone and destination zone. 237 Virtual service topology: 238 A virtual service topology consists of a sequence of service-PEs 239 and their attached service nodes created in a specific order. A 240 service topology is constructed via one or more routes that direct 241 the traffic flow among the PEs that form the service chain. 243 Service-topology-RT: 244 A BGP route attribute that identifies the specific service 245 topology. 247 Tenant: 248 A tenant is a higher-level management construct. In the control/ 249 forwarding plane it is the collection of various virtual networks 250 that get instantiated. A tenant may have more than one virtual 251 network or VPN. 253 Zone: 254 A logical grouping of physical or virtual assets that supports 255 certain applications or a subset thereof. VMs or hosts can 256 communicate freely within a zone. 258 2. Intra-Zone Routing and Traffic Forwarding 260 This section provides a brief overview of how the BGP/IP MPLS VPN 261 [RFC4364] control plane can be used in a DC network to used to divide 262 the network into a number of zones. The subsequent sections in the 263 document build on this base model to create inter-zone service 264 topologies by interconnecting these zones and forcing inter-zone 265 traffic to travel through a sequence of servers where the sequence of 266 servers depends on the tuple . 269 The notion of a BGP/IP VPN when applied to the virtual data center 270 works in the following manner. 272 The VM that runs the applications in the server is treated as a CE 273 attached to the VPN. A CE/VM belongs to a zone. The PE is the first 274 hop router from the CE/VM and the PE-CE link is single hop from a 275 layer-3 perspective. Any of the available physical, logical or 276 tunneling technologies can be used to create this "direct" link 277 between the CE/VM and its attached PE(s). 279 If a PE attaches to one or more CEs of a certain zone, the PE must 280 have exactly one VRF for that zone, and the PE-CE links to those CEs 281 must all be associated with that VRF. Intra-zone connectivity between 282 CE/VMs that attach to different PEs is achieved by designating an RT 283 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 CEs 296 IP address with the corresponding zone-RT. This allows unrestricted 297 any-to-any communication between the newly active VM and the rest of 298 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 flows 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 The different forwarding paths can be achieved at any PE as follows. 378 o Each service node is associated with two VRFs at the service PE to 379 which it is attached: an in-VRF for traffic toward the service 380 node, and an out-VRF for traffic from the service node. 382 o Traffic for the in-VRF arrives from the previous node in the 383 service chain, and traffic for the out-VRF is destined toward the 384 next node in the service chain, or toward the destination zone. 386 o The in-VRF has one or more routes with a next-hop of a local access 387 interface where the service node is attached. The out-VRF has 388 routes with a next-hop of the next service node, which may be 389 situated locally on the service-PE or at a remote PE. 391 The installation of the forwarding entries to implement the flow 392 described above may be achieved either via IP VPN mechanisms 393 described in Sections 4 and 5, or using an SDN approach, as described 394 in Section 6. 396 4. Inter-Zone Model 398 The inter-zone model has the following steps. 400 4.1 Constructing the Virtual Service Topology 402 The virtual service topology described in the previous section is 403 constructed via one or more service routes that direct the traffic 404 flow among the PEs forming the service chain. There should be a route 405 per service node. The service topologies, and hence the service 406 routes, are constructed on a per-VPN basis. This service topology is 407 independent of the routes for the actual destination for a flow, 408 i.e., the addresses of the VMs present in the various zones. There 409 can be multiple service topologies for a given VPN. 411 4.1.1 Reachability to the Service Nodes 413 Each service node is identified by an IP address that is scoped 414 within the VPN. The service node is also associated with an in-VRF 415 and out-VRF at the attached service node. 417 Reachability to the various service nodes in the service chain occurs 418 via regular BGP/IP VPN route advertisements. 420 A service-PE will export a route for each service node attached to 421 it. Each route will contain the Route-Target configured for the VPN, 422 and a forwarding label that is associated with the logical in-VRF for 423 to directly forward incoming traffic from the other PEs to the 424 service node. 426 The routes to reach the various service nodes are imported into and 427 installed in each out-VRF at a service-PE, as well as in the zone VRF 428 on the ingress zone-PE. 430 4.1.2 Provisioning the Service Chain 432 At each PE supporting a given VPN, the sequence of service nodes in a 433 service chain can be specified in a VPN service route policy. 435 To create the service chain and give it a unique identity, each PE 436 may be provisioned with the following tuple for every service chain 437 that it belongs to: 439 {Service-topology-RT, Service-node-Sequence} 441 where Service-node-Sequence is simply an ordered list of the service 442 node IP addresses that are in the chain. 444 Every service chain has a single unique service-topology-RT that is 445 provisioned in all participating PEs. 447 A PE will also be provisioned with the tables and/or other 448 configuration that support the various zones and the in- and out- 449 VRFs for the services. 451 4.1.3 Zone Prefix Next-Hop Resolution 453 Routes representing hosts, VMs or other destinations associated with 454 a zone are called zone prefixes. A zone prefix will have its regular 455 zone RTs attached when it is originated. This will be used by PEs 456 that have VRFs for the same zone to import these prefixes to enable 457 direct communication between VMs in the same zone. 459 In addition to the intra-zone RTs, zone prefixes are also tagged at 460 the point of origination with the set of Service-topology-RTs to 461 which they belong. 463 Since they are tagged with the Service-topology-RT, zone prefixes get 464 imported into the VRFs of the service-PEs that form the service chain 465 associated to that topology RT. Note that the Service-topology-RT was 466 added to the relevant VRF's import RT list during the virtual 467 topology construction phase. These routes may be installed in the in- 468 VRF and out-VRF at the service-PEs as well as in the ingress zone's 469 VRF. 471 Note that the approach being described introduces a change in the 472 behavior of the service-PEs and ingress zone's PEs compared to normal 473 BGP VPN behavior, but does not require protocol changes to BGP. This 474 modification to PE behavior allows the automatic and constrained flow 475 of traffic via the service chain. 477 The PE, based on the presence of the Service-topology-RT in the zone 478 routes it receives, will perform the following actions: 480 1. It will ignore the next-hop and VPN label that were advertised in 481 the NLRI. 483 2. Instead, it will select the appropriate Service next-hop from the 484 Service-node sequence associated with the Service-topology-RT. In 485 the out-VRF associated with a service node, it will select the 486 next service node in the sequence. 488 3. It will further resolve this Service next-hop IP address locally 489 in the associated VRF, instead of in the global routing table. It 490 will use the next-hop (and label, if remote) associated with this 491 IP address to encapsulate traffic toward the next service node. 493 4. If the importing service-PE is the last service-PE, it uses the 494 next hop that came with the zone prefix for route resolution. It 495 also uses the VPN label that came with the prefix. 497 In this way the zone prefixes in the intermediate service-PE hops 498 recurse over the service chain forcing the traffic destined to them 499 to flow through the virtual service topology. 501 Traffic for the zone prefix goes through the service hops created by 502 the service topology. At each service hop, the service-PE directs the 503 traffic to the service node. Once the service node is done processing 504 the traffic, it sends it back to the service-PE which forwards the 505 traffic to the next service-PE, and so on. 507 A significant benefit of this next-hop indirection is to avoid 508 redundant advertisement of zone prefixes from the end-zone or 509 service-PEs. Also, when the virtual service topology is changed (due 510 to addition or removal of service nodes), there should be no change 511 to the zone prefix's import/export RT configuration, and hence no re- 512 advertisement of zone prefixes. 514 There should be one service topology RT per virtual service topology. 515 There can be multiple virtual service topologies and hence service 516 topology RTs for a given VPN. 518 Virtual service topologies are constructed unidirectionally. Traffic 519 in opposite directions between the same pair of zones will be 520 supported by two different service topologies and hence two service 521 topology routes. These two service topologies might or might not be 522 symmetrical, i.e. they might or might not traverse the same sequence 523 As noted above, a service node route is advertised with a label that 524 directs incoming traffic to the attached service node. Alternatively, 525 an aggregate label may be used for the service route and an IP route 526 lookup done in the in-VRF 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 chain 530 seamlessly by just configuring the service policy appropriately. 532 4.2 Per-VM Service Chains 534 While the service-topology-RT allows an efficient inheritance of the 535 service chain for all VMs or prefixes in a zone, there may be a need 536 to create a distinct service chain for an individual VM or prefix. 537 This may be done by provisioning a separate service-topology RT and 538 service node sequence. The VM route carries the service-topology RT, 539 and the destination and service PEs are provisioned with this RT as 540 described above. 542 5. Routing Considerations 544 5.1 Multiple Service Topologies 546 A service-PE can support multiple distinct service topologies for a 547 VPN. 549 5.2 Multipath 551 One could use all tools available in BGP to constrain the propagation 552 and resolution of state created by the service topology [RFC4684]. 554 Additional service nodes can be introduced to scale out a particular 555 service. Each such service would be represented by a virtual IP 556 address, and multiple service nodes associated with it. Multiple 557 service-PEs may advertise a route to this address based on the 558 presence of an attached service node instance, thereby creating 559 multiple equal cost paths. This technique could be used to 560 elastically scale out the service nodes with traffic demand. 562 5.3 Supporting Redundancy 564 For stateful services an active-standby mechanism could be used at 565 the service level. In this case, the inter-zone traffic should prefer 566 the active service node over the standby service node. 568 At a routing level, this is achieved by setting up two paths for the 569 same service route: one path goes through the active service node and 570 the other through the standby service node. The active service path 571 can then be made to win over the standby service path by 572 appropriately setting the BGP path attributes of the service topology 573 route such that the active path succeeds in path selection. This 574 forces all inter-zone traffic through the active service node. 576 5.4 Route Aggregation 578 Instead of the actual zone prefixes being imported and used at 579 various points along the chain, the zone prefixes may be aggregated 580 at a specific PE and the aggregate zone prefix used in the service 581 chain between zones. In such a case, it is the aggregate zone prefix 582 that carries the service-topology-RT and gets imported in the 583 service-PEs that comprise the service chain. 585 6. Orchestration Driven Approach 587 In an orchestration driven approach, there is no need for the zone or 588 service PEs to determine the appropriate next-hops based on the 589 specified service node sequence. All the necessary policy 590 computations are carried out, and the forwarding tables for the 591 various VRFs at the PEs determined, by a central orchestrator or 592 controller. 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. There are 599 several possible options to this programmatic interface, some being 600 under discussion in the IETF's Interface to Routing Systems (I2RS) 601 initiative, [I-D.ietf-i2rs-architecture], [I-D.ietf-i2rs-problem- 602 statement]. One specific option is defined in [IPSE]. 604 7. Security Considerations 606 To be added. 608 8. Management Considerations 610 To be added. 612 9. IANA Considerations 614 This proposal does not have any IANA implications. 616 10. Acknowledgements 618 The authors would like to thank the following individuals for their 619 review and feedback on the proposal: Eric Rosen, Jim Guichard, Paul 620 Quinn, Peter, Bosch, David Ward, Ashok Ganesan. The option of 621 configuring an ordered sequence of service nodes via policy is 622 derived from a suggestion from Eric Rosen. 624 11. References 626 11.1 Normative References 628 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 629 Networks (VPNs)", RFC 4364, February 2006. 631 11.2 Informative References 633 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 634 Protocol 4 (BGP-4)", RFC 4271, January 2006. 636 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 637 R., Patel, K., and J. Guichard, "Constrained Route 638 Distribution for Border Gateway Protocol/MultiProtocol 639 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 640 Private Networks (VPNs)", RFC 4684, November 2006. 642 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 643 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 644 VPNs", RFC 7024, October 2013. 646 [I-D.fang-l3vpn-virtual-ce] 647 L. Fang, et al.,"BGP/MPLS IP VPN Virtual CE", 648 draft-fang-l3vpn-virtual-ce, work in progress. 650 [I-D.fang-l3vpn-virtual-pe] 651 L. Fang, et al., "BGP/MPLS IP VPN Virtual PE", 652 draft-fang-l3vpn-virtual-pe, work in progress. 654 [I-D.ietf-i2rs-architecture] 655 Atlas, A., Halpern, J., Hares, S., Ward, D., and T Nadeau, 656 "An Architecture for the Interface to the Routing System", 657 draft-ietf-i2rs-architecture, work in progress. 659 [I-D.ietf-i2rs-problem-statement] 660 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 661 Routing System Problem Statement", 662 draft-ietf-i2rs-problem-statement, work in progress. 664 [IPSE] 665 Fernando, R., Boutros, S., Rao, D., "Interface to a 666 Packet Switching Element", 667 draft-rfernando-ipse-00, work in progress. 669 Authors' Addresses 671 Dhananjaya Rao 672 Cisco 673 170 W Tasman Dr 674 San Jose, CA 675 Email: dhrao@cisco.com 677 Rex Fernando 678 Cisco 679 170 W Tasman Dr 680 San Jose, CA 681 Email: rex@cisco.com 683 Luyuan Fang 684 Microsoft 685 5600 148th Ave NE 686 Redmond, WA 98052 687 Email: lufang@microsoft.com 689 Maria Napierala 690 AT&T 691 200 Laurel Avenue 692 Middletown, NJ 07748 693 Email: mnapierala@att.com 695 Ning So 696 Vinci Systems, Inc. 697 Email: ningso@yahoo.com 699 Adrian Farrel 700 Juniper Networks 701 Email: adrian@olddog.co.uk