idnits 2.17.1 draft-rfernando-l3vpn-service-chaining-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 8) being 215 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 100 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3910 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: 'RFC4684' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC6120' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC4627' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'I-D.fang-l3vpn-virtual-pe' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'I-D.fang-l3vpn-virtual-ce' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'I-D.rfernando-irs-fw-req' is defined on line 623, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-05) exists of draft-fang-l3vpn-virtual-pe-01 == Outdated reference: A later version (-03) exists of draft-fang-l3vpn-virtual-ce-01 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). 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: January 14, 2014 L. Fang 4 Cisco 5 M. Napierala 6 AT&T 7 N. So 8 Tata Communications 10 July 15, 2013 12 Virtual Topologies for Service Chaining in BGP IP VPNs 13 draft-rfernando-l3vpn-service-chaining-02 15 Abstract 17 This document presents techniques built upon BGP MPLS/VPN control 18 plane mechanisms to construct virtual topologies for service chaining. 19 These virtual service topologies interconnect network zones and constrain 20 the flow of traffic between these zones via a sequence of service nodes so 21 that interesting service functions can be applied to such trafic. 23 This document also describes both routing control plane and network 24 orchestration driven approaches to realize these virtual service topologies. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Intra-Zone Routing and Traffic Forwarding . . . . . . . . . . 6 67 3. Inter-Zone Routing and Traffic Forwarding . . . . . . . . . . 7 68 4. Proposed Inter-Zone Model . . . . . . . . . . . . . . . . . . 8 69 4.1 Constructing the Virtual Service Topology . . . . . . . . . 8 70 4.2 Inter-zone Routing and Service Chaining . . . . . . . . . . 10 71 4.3 Per-VM service chains . . . . . . . . . . . . . . . . . . . 11 72 5. Routing Considerations . . . . . . . . . . . . . . . . . . . . 12 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. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10.1 Normative References . . . . . . . . . . . . . . . . . . . 14 83 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 Network topologies and routing design in enterprise, Data Center, and 89 campus networks typically reflect the needs of the organization in 90 terms of performance, scale, security and availability. For scale and 91 security reasons, these networks may be composed of multiple small 92 domains or zones each serving one or more functions of the 93 organization. 95 A network zone is a logical grouping of physical assets that support 96 certain applications or a subset thereof. Hosts can communicate 97 freely within a zone, that is, a datagram traveling between two hosts 98 in the same zone is not routed through any servers that examine the 99 datagram payload, but a datagram traveling between hosts in different 100 zones is subject to additional services to meet the needs of scaling, 101 performance, and security for specific applications. Example of such 102 services can be a security gateway or a load-balancer. 104 Traditional networks achieve this by using a combination of physical 105 topology constraints and routing. For example, one can force 106 datagrams going through a FireWall (FW) by putting the firewall in 107 the data path from a source to a destination. In some other cases, 108 the datagrams needs to go through a security gateway for security 109 service, and a Load Balancer (LB) for load balancing service. 111 In modern virtualized Data Centers, appliances, applications, and 112 network functions, including IP VPN PE and CE functions are commonly 113 virtualized, i.e, they are software instances residing in servers or 114 appliances instead of individual physical devices. 116 Porting a traditional network with all its functions and 117 infrastructure elements to a virtualized data center requires network overlay 118 mechanisms that provide the ability to create virtual network 119 topologies that mimic physical networks and the ability to constrain 120 the flow of routing and traffic over these virtual network 121 topologies. 123 A Data Center needs a virtual topology in which the servers are in 124 the "virtual" data path, rather than in the physical data path. For 125 example, a traffic flow in the traditional network has the resource 126 as Provider Edge (PE) 1, and destination as Autonomous System Border 127 Router (ASBR) 1, the flow must be serviced by FW1 and LB2, its path 128 would be PE1 -> FW1 -> LB1 -> ASBR1. In a virtualized DC, the virtual 129 topology for this path may be vPE1 -> vFW1 -> vLB1 -> ASBR1, assume 130 PE1, FW1 and LB1 are virtual nodes. This sequence represents an 131 example of virtual service chain. The nodes in the chain may be 132 placed at arbitrary physical locations. 134 Furthermore, data centers might need multiple virtual topologies per 135 tenant to handle different types of application traffic. A tenant is 136 a customer who uses the virtualized data center services. The term 137 Multi-tenant means virtualized single end device, for example, a 138 server, supports multiple tenants which requires routing isolation 139 among the tenants' traffic. Each tenant might dictate a different 140 topology of connectedness between their zones and applications and 141 might need the ability to apply network policies and services for 142 inter-zone traffic in specific order to the organization objectives 143 of the tenant. Therefore, the mechanisms devised should be flexible 144 to accommodate the custom needs of a tenant and their applications at 145 the same time MUST be robust enough to satisfy the scale, performance 146 and HA needs that they demand from the virtual network 147 infrastructure. 149 Towards this end, this document introduces the concept of virtual 150 service topologies and extends MPLS/VPN control plane mechanisms to 151 constrain routing and traffic flow over virtual service topologies. 153 The creation of these topologies and the setting up of the forwarding tables 154 to steer traffic over them may be carried out either by extensions to IP-VPN 155 procedures and functionality at the PEs, or via an SDN based approach. This 156 document specifies the use of both approaches, but uses the IP-VPN based option 157 to illustrate the various steps involved. 159 1.1 Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 2. Suggested text under terminology in 1.1 (after the key word 166 paragraph) 168 Terms description 169 ----- --------------------------- 171 AS Autonomous System 172 ASBR Autonomous System Border Router 173 BGP Border Gateway Protocol 174 CE Customer Edge 175 DPI Deep Packet imspection 176 ED End device: where Guest OS, Host OS/Hypervisor, 177 applications, VMs, and virtual router may reside 178 Forwarder L3VPN forwarding function 179 FW FireWall 180 GRE Generic Routing Encapsulation 181 Hypervisor Virtual Machine Manager running on each end device 182 I2RS Interface to Routing System 183 LB Load Balancer 184 LTE Long Term Evolution 185 MP-BGP Multi-Protocol Border Gateway Protocol 186 PCEF Policy Charging and Enforcement Function 187 P Provider backbone router 188 PBR Policy Based Routing 189 proxy-arp proxy-Address Resolution Protocol 190 QoS Quality of Service 191 RR Route Reflector 192 RT Route Target 193 RTC RT Constraint 194 SDN Software Defined Network 195 ToR Top-of-Rack switch 196 VI Virtual Interface 197 vCE virtual Customer Router 198 vFW virtual FireWall 199 vLB virtual Load Balancer 200 VM Virtual Machine 201 vPC virtual Private Cloud 202 vPE virtual Provider Edge 203 VPN Virtual Private Network 204 vRR virtual Route Reflector1.2 Scope of the document 205 WAN Wide Area Network 207 General terminologies: 209 Service-PE: A BGP IP-VPN PE to which a service node in a virtual 210 service topology is attached. The PE directs incoming traffic from 211 other PEs or from attached hosts to the service node via an MPLS VPN 212 label or IP lookup; and forwards traffic from the service node to the next 213 node in the chain. A Service-PE is a logical entity, in that a given PE may 214 be attached to both a service node and an application host VM. 216 Service node: A physical or virtual service appliance/application 217 which inspects and/or redirects the flow of inter-zone traffic. 218 Examples of service CEs: Firewalls, load-balancers, deep packet 219 inspectors. The Service node acts as a CE in the VPN network. 221 Service Chain: A sequence of service nodes that interconnect two end-host zones. 222 The service chain is unidirectional and creates a one way traffic flow between 223 source zone and destination zone. 225 Virtual Service topology: 226 A virtual service topology consists of a sequence of service-PE's and their 227 attached service nodes created in a specific order. A service topology is 228 constructed via one or more routes that direct the traffic flow among the PEs 229 forming the service chain. 231 Service-topology-RT: A BGP route attribute that identifies the specific service 232 topology. 234 Tenant: A tenant is a higher-level management construct. In the 235 control/forwarding plane, it is the various virtual networks that get 236 instantiated. A tenant may have more than one virtual network or VPN. 238 Zone: A logical grouping of physical assets that supports certain 239 applications or a subset thereof. VMs or hosts can communicate freely within a 240 zone. 242 2. Intra-Zone Routing and Traffic Forwarding 244 This section provides a brief overview of how BGP/MPLS IP VPNs 245 [RFC4364] control plane can be used in DC networks to used to divide 246 a DC network into a number of zones. The subsequent sections in the 247 document build on this base model to create inter-zone service 248 topologies by interconnecting these zones and forcing inter-zone 249 traffic to travel through a sequence of servers where the sequence of 250 servers depends on . 252 The notion of BGP IP VPN when applied to the virtual Data Center 253 works in the following manner. 255 The VM that runs the applications in the server is treated as a CE 256 attached to the VPN. A CE/VM belongs to a zone. The PE is the first 257 hop router from the CE/VM and the PE-CE link is single hop from an L3 258 perspective. Any of the available physical, logical or tunneling 259 technologies can be used to create this "direct" link between the 260 CE/VM and its attached PE(s). 262 If a PE attaches to one or more CEs of a certain zone, the PE must 263 have exactly one VRF for that zone, and the PE-CE links to those CEs 264 must all be associated with that VRF. Intra-zone connectivity between 265 CE/VMs that attach to different PEs is achieved by designating an RT 266 per zone (zone-RT) that is both an import RT and an export RT of all 267 PE VRFs that terminate the CE/VMs that belong to the zone. A VM may 268 have multiple virtual interfaces that attach to different zones. 270 It is further assumed that the CE/VM's are associated with network 271 policies that become activated on an attached PE when a CE/VM becomes 272 alive. These policies dictate how networking should be set up for the 273 CE/VM including the properties of the CE-PE link, the IP address of 274 the CE/VM, the zone(s) that it belongs to, QoS policies etc. There 275 are many ways to accomplish this step, a description of which is 276 outside the scope of this document. 278 When the CE/VM is activated, the attached PE starts exporting its IP 279 address with the corresponding zone-RT. This allows unrestricted any- 280 to-any communication between the newly active VM and the rest of the 281 VMs in the zone. 283 The classification of VMs into a zone is driven by the communication 284 and security policy and is independent of the addressing for the VMs. 285 The VMs in a zone may be in the same or different IP subnets with 286 user-defined mask-lengths. The PE advertises /32 routes to advertise 287 reachability to a locally attached VM. If two VMs are in the same IP 288 subnet, the PE may employ proxy-ARP to assist the VM to resolve ARP for 289 other VMs in the IP subnet, and may use IP forwarding to carry traffic 290 between the VMs. When a VM is attached to a remote PE, IP-VPN forwarding is 291 used to tunnel packets to the remote PE. 293 3. Inter-Zone Routing and Traffic Forwarding 295 A simple form of inter-zone traffic forwarding can be achieved using 296 extranets or hub-and-spoke L3VPN configurations. However, the ability 297 to enforce constrained traffic flow through a set of services is non- 298 existent in extranets and is limited in hub-and-spoke setups. 300 Note that the inter-zone services cannot always be assumed to reside 301 and inlined on a PE. There is a need to virtualize the services 302 themselves so that they can be implemented on commodity hardware and 303 scaled out 'elastically' when traffic demands increase. This creates 304 a situation where services for traffic between zones may not be 305 applied only at the source-zone PE or the destination-zone PE. 306 Mechanisms are required that make it easy to direct inter-zone 307 traffic through the appropriate set of service nodes that might be 308 remote and virtualized. 310 3.1 Traffic Forwarding operational flow 312 Traffic from an endpoint in a source zone lands on an ingress zone-PE in a VRF 313 associated with the zone. The zone-PE will forward the traffic and direct it 314 towards the first service-node.If the service-node is attached to the zone-PE, 315 it will forward the packet out one of its access interfaces. If the service-node 316 is attached to a different service-PE, it will encapsulate the packets 317 appropriately and send them towards the service-PE. The PEs may be physically 318 connected via an intermediate network of devices. 320 The service-PE will receive these encapsulated packets from the source zone-PE 321 and forward them to its attached service-node. The traffic that comes back 322 to the service-PE from the service-node must now be forwarded to the next 323 service-node in the chain. As above, the next service-node may be locally 324 attached or at a remote service-PE. 326 At the last service-PE in the chain, the traffic that comes back from a service 327 node must now be forwarded directly to the destination in the target zone. The 328 destination may be attached or reachable via another PE. 330 As can be determined by the above example, a given packet flow needs to be 331 forwarded differently at any PE depending on whether the traffic is destined 332 towards an attached node on the PE or is arriving from an attached node and 333 destined to a node at a remote PE. The next-hop for the flows changes depending 334 on the relative position within the logical service chain. 336 The following figure illustrates a virtual service topology, where hosts in 337 Zone 1 are interconnected with hosts in Zone 2 via two service nodes Serv-A and 338 Serv-B, attached to two service-PEs S-PE A and S-PE B respectively. 340 """""""""""""""""""""" """""""""""""""""""""" 341 " +-------+ " +--------+ +--------+ " +-------+ " 342 " +-----+ | vPE-1 | " |ServPE-A| |ServPE-B| " | vPE-2 | +-----+ " 343 " |VM/CE|--| |---| |---| |---| |--|VM/CE| " 344 " +-----+ |(VRF-1)| " |(VRF-A) | |(VRF-B) | " |(VRF-2)| +-----+ " 345 " +-------+ " +--------+ +--------+ " +-------+ " 346 " " | | " " 347 " Zone 1 " +--------+ +--------+ " Zone 2 " 348 """""""""""""""""""""" | Serv-A | | Serv-B | """""""""""""""""""""" 349 +--------+ +--------+ 350 Figure 1. Virtual Service Topology illustration 352 The different forwarding paths can conceptually be achieved at any PE as follows: 354 Each service node is associated with two VRF tables at the service PE that it is 355 attached to - an in-VRF for traffic towards the service node, and an out-VRF for 356 traffic from the service node. 358 Traffic in the in-VRF arrives from the previous node in the service chain, and 359 traffic in the out-VRF is destined towards the next node in the service chain, 360 or towards the destination zone. 362 The in-VRF has one or more routes with a next-hop of a local access interface 363 where the service node is attached. The out-VRF has routes with a next-hop of 364 the next service node, which may be situated locally on the service-PE or at 365 a remote PE. 367 The installation of the appropriate forwarding entries to implement the 368 forwarding flow described above may be achieved either via IP-VPN mechanisms 369 or via an SDN approach, as described further. 371 4. Proposed Inter-Zone Model 373 The proposed model has the following steps to it. 375 4.1 Constructing the Virtual Service Topology 377 The virtual service topology described in the previous section is constructed 378 via one or more routes that direct the traffic flow among the PEs 379 forming the service chain. There should be a route per service node. The service 380 topologies, and hence the service routes, are constructed on a per-VPN basis. This 381 service topology is independent of the routes for the actual destination for a 382 flow, ie the addresses of the VMs present in the various zones. There can be 383 multiple service topologies for a given VPN. 385 4.1.1 Reachability to the service nodes 387 Each service node is identified by an IP address that is scoped within the VPN. 388 The service node is also associated with an in-VRF and out-VRF at the attached 389 service node. 391 Reachability to the various service nodes in the service chain occurs via regular 392 BGP IP-VPN route advertisements. 394 A service-PE will export a route for each service node attached to it. Each 395 route will contain the Route-Target configured for the VPN, and a forwarding 396 label that is associated with the logical in-VRF for a service node on the 397 service-PE. This label enables the service-PE to directly forward incoming 398 traffic from the other PEs to the service node. 400 The routes to reach the various service nodes are imported into and installed in 401 each out-VRF at a service-PE, as well as in the zone-VRF on the ingress zone-PE. 403 4.1.2 Provisioning the service chain 405 At each PE supporting a given VPN, the sequence of service nodes in a service 406 chain can be specified in a VPN service route policy. 408 To create the service chain and give it a unique identity, each PE may be 409 provisioned with the following tuple for every service chain that it belongs to: 411 {Service-topology-RT, Service-node-Sequence} where Service-node-Sequence is 412 simply an ordered list of the service node IP addresses that are in the chain. 414 Every service chain has a single unique service-topology-RT that's provisioned 415 in all participating PEs. 417 A PE will also be provisioned with the tables and/or configuration that support 418 the various zone, service in- and out- VRFs. 420 4.1.3 Zone prefix next-hop resolution 422 Routes representing hosts or VMs from a zone are called zone 423 prefixes. A zone prefix will have its regular zone RTs attached when 424 it is originated. This will be used by PEs in the same zone to import 425 these prefixes to enable direct communication between VM's of the 426 same zone. 428 In addition to the intra-zone RT's, zone prefixes are also tagged at 429 the point of origination with the set of service-topology-RTs to 430 which they belong. 432 Since they are tagged with the zone-RT, zone prefixes get 433 imported into the appropriate service-VRF's of particular service- 434 PE's that form the service chain associated to that topology RT. Note 435 that the zone RT was added to the relevant service-VRF's import 436 RT list during the virtual topology construction phase. 437 These routes may be installed in the in-VRF, out-VRF tables at the service-PEs 438 as well as in the ingress zone-VRF. 440 Note that this proposal introduces a change in the behavior of the 441 service-PE's but does not require protocol changes to BGP. 442 A modification is proposed to a standard PE behavior to allow the automatic and 443 constrained flow of traffic via the service chain. 445 The PE, based on the presence of the configured Service-topology-RT in the 446 received zone routes, will perform the following actions: 448 1. It will ignore the next-hop and VPN label that were advertised in the NLRI. 449 2. Instead, it will select the appropriate Service next-hop from the Service-node 450 sequence associated with the Service-topology-RT. 451 3. It will further resolve this Service next-hop IP address locally in the 452 associated VRF, instead of in the global table. It will use the next-hop and 453 label associated with this IP address to encapsulate traffic towards the next 454 service node. 455 4. If the importing service-PE is the last service-PE, it uses 456 the next hop that came with the zone prefix for route resolution. It 457 also uses the VPN label that came with the prefix. 459 This way the zone prefixes in the intermediate service-PE hops 460 recurse over the service chain forcing the traffic destined 461 to them flow through the virtual service topology. 463 Traffic for the zone prefix goes through the service hops created by the 464 the service topology. At each service hop, the service-PE 465 directs the traffic to the service node. Once the service node is 466 done processing the traffic, it then sends it back to the service-PE 467 which forwards the traffic to the next service-PE and so on. 469 A significant benefit of this next-hop indirection is to avoid 470 redundant advertisement of zone prefixes from the end-zone or service-PEs. 471 Also, when the virtual service topology is changed (due to addition or 472 removal of service-PEs), there should be no change to the zone 473 prefix's import/export RT configuration. 475 There should be one service topology RT per virtual service 476 topology. There can be multiple virtual service topologies and hence 477 service topology RTs for a given VPN. 479 Virtual service topologies are constructed unidirectionally. Between 480 the same pair of zones, traffic in opposite directions will be 481 supported by two service topologies and hence two service topology 482 routes. These two service topologies might or might not be 483 symmetrical, i.e. they might or might not traverse the same service- 484 PE's/service-nodes in opposite directions. 486 As noted above, a service node route can be advertised with a 487 label that directs incoming traffic to the attached service node. Alternatively, 488 an aggregate label may be used for the service route and an IP route lookup done 489 at the service-PE to send traffic to the service node. 491 Note that a new service node could be inserted seamlessly into the chain by just 492 configuring the service policy appropriately. 494 4.2 Per-VM service chains 496 While the service-topology-RT allows an efficient inheritance of 497 the service chain for all VMs in a zone, there may be a need to 498 create a distinct service chain for an individual VM. This may be 499 done by provisioning a separate service-topology RT and service node sequence. 500 The VM route carries the service-topology RT, and the 501 destination service-zone is provisioned with this RT as its Service- 502 Import RT. 504 5. Routing Considerations 506 5.1 Multiple service topologies 508 A service-PE can support multiple distinct service topologies for a VPN. 510 5.2 Multipath 512 One could use all tools available in BGP to constrain the propagation 513 and resolution state created by the service topology. 515 Additional service nodes can be introduced to scale out a particular service. 516 Each such service would be represented by a virtual IP address, and multiple 517 service nodes associated with it. Multiple service-PEs may advertise a route 518 to this address based on the presence of an attached service node instance, 519 thereby creating multiple equal cost paths. This technique could be used to 520 elastically scale out the service nodes with traffic demand. 522 5.3 Supporting redundancy 524 For stateful services an active-standby mechanism could be used at 525 the service level. In this case, the inter-zone traffic should prefer 526 the active service node over the standby service node. 528 At a routing level, this is achieved by setting up two paths for the 529 same service node route - one path goes through the active 530 service node and the other through the standby service node. The 531 active service path can then be made to win over the standby service 532 path by appropriately setting the BGP path attributes of the service 533 topology route such that the active path succeeds in path selection. 534 This forces all inter-zone traffic through the active service node. 536 5.4 Route Aggregation 538 Instead of the actual zone prefixes being imported and used at 539 various points along the chain, the zone prefixes may be aggregated 540 at the destination service-PE and the aggregate zone prefix used in 541 the service chain between zones. In such a case, it is the aggregate 542 zone prefix that carries the service-topology-RT and gets imported in 543 the service-PE's that comprise the service chain. 545 6. Orchestration driven approach 547 In an orchestration driven approach, there is no need for the zone or service 548 PEs to determine the appropriate next-hops based on the specified service node 549 sequence. All the necessary policy computations are carried out, and the 550 forwarding tables for the various VRFs at the PEs determined, by the central 551 orchestrator. 553 The orchestrator then uses a suitable means of communication with the various 554 PEs, typically virtual PEs on the end-servers to populate the forwarding tables. 556 The controller/Orchestration system used to communicate between 557 PE/vPE MUST support standard, programmatic interface. The 558 programmatic interface are current under definition in IETF Interface 559 to Routing Systems (I2RS)) initiative. [I-D.ward-irs-framework], [I- 560 D.rfernando-irs-fw-req]. Standard data modeling languages will be 561 defined/identified in I2RS. YANG - A Data Modeling Language for the 562 Network Configuration Protocol (NETCONF) [RFC6020] is one of the 563 candidates currently under investigation. 565 7. Security Considerations 567 To be added. 569 8. IANA Considerations 571 This proposal does not have any IANA implications. 573 9. Acknowledgements 575 The authors would like to thank the following individuals for their 576 review and feedback on the proposal: Eric Rosen, Jim Guichard, Paul 577 Quinn, Peter, Bosch, David Ward, Ashok Ganesan. The option of configuring 578 an ordered sequence of service nodes via policy is derived from a suggestion 579 from Eric Rosen. 581 10. References 583 10.1 Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 589 Networks (VPNs)", RFC 4364, February 2006. 591 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 592 R., Patel, K., and J. Guichard, "Constrained Route 593 Distribution for Border Gateway Protocol/MultiProtocol 594 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 595 Private Networks (VPNs)", RFC 4684, November 2006. 597 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 598 the Network Configuration Protocol (NETCONF)", RFC 6020, 599 October 2010. 601 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 602 Protocol (XMPP): Core", RFC 6120, March 2011. 604 10.2 Informative References 606 [RFC4627] Crockford, D., "The application/json Media Type for 607 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 609 [I-D.fang-l3vpn-virtual-pe] Fang, L., Ward, D., Fernando, R., 610 Napierala, M., Bitar, N., Rao, D., Rijsman, B., So, N., 611 "BGP IP VPN Virtual PE", draft-fang-l3vpn-virtual-pe-01, 612 Feb. 2013. 614 [I-D.fang-l3vpn-virtual-ce] Fang, L., Evans, J., Ward, D., Fernando, 615 R., Mullooly, J., So, N., Bitar., N., Napierala, M., "BGP 616 IP VPN Virtual PE", draft-fang-l3vpn-virtual-ce-01, Feb. 617 2013. 619 [I-D.ward-irs-framework] Atlas, A., Nadeau, T., Ward. D., "Interface 620 to the Routing System Framework", draft-ward-irs- 621 framework-00, July 2012. 623 [I-D.rfernando-irs-fw-req] Fernando, R., Medved, J., Ward, D., Atlas, 624 A., Rijsman, B., "IRS Framework Requirements", draft- 625 rfernando-irs-framework-requirement-00, Oct. 2012. 627 Authors' Addresses 629 Dhananjaya Rao 630 Cisco 631 170 W Tasman Dr 632 San Jose, CA 633 US 634 Email: dhrao@cisco.com 636 Rex Fernando 637 Cisco 638 170 W Tasman Dr 639 San Jose, CA 640 US 641 Email: rex@cisco.com 643 Luyuan Fang 644 Cisco 645 170 W Tasman Dr 646 San Jose, CA 647 US 648 Email: lufang@cisco.com 650 Maria Napierala 651 AT&T 652 200 Laurel Avenue 653 Middletown, NJ 07748 654 US 655 Email: mnapierala@att.com 657 Ning So 658 Tata Communications 659 Plano, TX 75082, USA 660 Email: ning.so@tatacommunications.com