idnits 2.17.1 draft-rfernando-bess-service-chaining-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (October 25, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FLOWSPEC' is mentioned on line 566, but not defined == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 716, 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 (~~), 4 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: April 28, 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 October 25, 2014 16 Virtual Topologies for Service Chaining in BGP/IP MPLS VPNs 18 draft-rfernando-bess-service-chaining-00 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 This draft is a re-submission of draft-rfernando-l3vpn-service- 185 chaining-05.txt, to conform to the bess working group nomenclature. 187 1.1 Terminology 189 This document uses the following acronyms and terms. 191 Terms Meaning 192 ----- -------------------------------------------------- 193 AS Autonomous System 194 ASBR Autonomous System Border Router 195 CE Customer Edge 196 FW Firewall 197 I2RS Interface to the Routing System 198 L3VPN Layer 3 VPN 199 LB Load Balancer 200 NLRI Network Layer Reachability Information [RFC4271] 201 P Provider backbone router 202 proxy-arp proxy-Address Resolution Protocol 203 RR Route Reflector 204 RT Route Target 205 SDN Software Defined Network 206 vCE virtual Customer Edge router 207 [I-D.fang-l3vpn-virtual-ce] 208 vFW virtual Firewall 209 vLB virtual Load Balancer 210 VM Virtual Machine 211 vPC virtual Private Cloud 212 vPE virtual Provider Edge router 213 [I-D.fang-l3vpn-virtual-pe] 214 VPN Virtual Private Network 215 VRF VPN Routing and Forwarding table [RFC4364] 216 vRR virtual Route Reflector 218 This document also uses the following general terms: 220 Service-PE: 221 A BGP/IP MPLS VPN PE to which a service node in a virtual service 222 topology is attached. The PE directs incoming traffic from other 223 PEs or from attached hosts to the service node via an MPLS VPN 224 label or IP lookup. The PE also forwards traffic from the service 225 node to the next node in the chain. A Service-PE is a logical 226 entity and a given PE may be attached to both a service node and 227 an application host VM. 229 Service node: 230 A physical or virtual service appliance/application which inspects 231 and/or redirects the flow of inter-zone traffic. Examples of 232 service nodes include FWs, LBs, and deep packet inspectors. The 233 service node acts as a CE in the VPN network. 235 Service chain: A sequence of service nodes that interconnect the 236 zones containing the source and destination hosts or endpoints. The 237 service chain is unidirectional and creates a one way traffic flow 238 between source zone and destination zone. 240 Virtual service topology: 241 A virtual service topology consists of a sequence of service-PEs 242 and their attached service nodes created in a specific order. A 243 service topology is constructed via one or more routes that direct 244 the traffic flow among the PEs that form the service chain. 246 Service-topology-RT: 247 A BGP route attribute that identifies the specific service 248 topology. 250 Tenant: 251 A tenant is a higher-level management construct. In the control/ 252 forwarding plane it is the collection of various virtual networks 253 that get instantiated. A tenant may have more than one virtual 254 network or VPN. 256 Zone: 257 A logical grouping of physical or virtual assets that supports 258 certain applications or a subset thereof. VMs or hosts can 259 communicate freely within a zone. 261 2. Intra-Zone Routing and Traffic Forwarding 263 This section provides a brief overview of how the BGP/IP MPLS VPN 264 [RFC4364] control plane can be used in a DC network to used to divide 265 the network into a number of zones. The subsequent sections in the 266 document build on this base model to create inter-zone service 267 topologies by interconnecting these zones and forcing inter-zone 268 traffic to travel through a sequence of servers where the sequence of 269 servers depends on the tuple . 272 The notion of a BGP/IP VPN when applied to the virtual data center 273 works in the following manner. 275 The VM that runs the applications in the server is treated as a CE 276 attached to the VPN. A CE/VM belongs to a zone. The PE is the first 277 hop router from the CE/VM and the PE-CE link is single hop from a 278 layer-3 perspective. Any of the available physical, logical or 279 tunneling technologies can be used to create this "direct" link 280 between the CE/VM and its attached PE(s). 282 If a PE attaches to one or more CEs of a certain zone, the PE must 283 have exactly one VRF for that zone, and the PE-CE links to those CEs 284 must all be associated with that VRF. Intra-zone connectivity between 285 CE/VMs that attach to different PEs is achieved by designating an RT 286 per zone (zone-RT) that is both an import RT and an export RT of all 287 PE VRFs that terminate the CE/VMs that belong to the zone. A VM may 288 have multiple virtual interfaces that attach to different zones. 290 It is further assumed that the CE/VMs are associated with network 291 policies that are activated on an attached PE when a CE/VM is 292 instantiated. These policies dictate how the network is set up for 293 the CE/VM including the properties of the CE-PE link, the IP address 294 of the CE/VM, the zones to which it belongs, QoS policies, etc. There 295 are many ways to accomplish this step, but a description of such 296 mechanisms is outside the scope of this document. 298 When the CE/VM is activated, the attached PE starts to export the CEs 299 IP address with the corresponding zone-RT. This allows unrestricted 300 any-to-any communication between the newly active VM and the rest of 301 the VMs in the zone. 303 The classification of VMs into a zone is driven by the communication 304 and security policy and is independent of the addressing scheme for 305 the VMs. The VMs in a zone may be in the same or different IP subnets 306 with user-defined mask-lengths. The PE advertises /32 routes to 307 advertise reachability to locally attached VMs. If two VMs are in the 308 same IP subnet, the PE may employ proxy-ARP to assist the VM to 309 resolve ARP for other VMs in the IP subnet, and may use IP forwarding 310 to carry traffic between the VMs. When a VM is attached to a remote 311 PE, IP VPN forwarding is used to tunnel packets to the remote PE. 313 3. Inter-Zone Routing and Traffic Forwarding 315 A simple form of inter-zone traffic forwarding can be achieved using 316 extranets or hub-and-spoke L3VPN configurations [RFC7024]. However, 317 the ability to enforce constrained traffic flows through a set of 318 services is non-existent in extranets and is limited in hub-and-spoke 319 setups. 321 Note that the inter-zone services cannot always be assumed to reside 322 and be in-lined on a PE. There is a need to virtualize the services 323 themselves so that they can be implemented on commodity hardware and 324 scaled out 'elastically' when traffic demands increase. This creates 325 a situation where services for traffic between zones may be applied 326 not only at the source-zone PE or the destination-zone PE. Mechanisms 327 are required that make it easy to direct inter-zone traffic through 328 the appropriate set of service nodes that might be remote or 329 virtualized. 331 3.1 Traffic Forwarding Operational Flow 333 Traffic from a source endpoint (a VM/CE or PE) in a source zone 334 reaches an ingress zone-PE and is associated with a VRF in that zone 335 as described above. The zone-PE will forward the traffic and direct 336 it toward the first service-node. If the service-node is attached to 337 the zone-PE, the zone-PE will forward the packets out of one of its 338 access interfaces. If the service-node is attached to a different 339 service-PE, the zone-PE will encapsulate the packets and send them 340 toward the service-PE. The zone-PE and service PE may be connected 341 via an intermediate network of devices and the encapsulation causes 342 the packets to be tunneled across this intermediate network. 344 The service-PE will receive these encapsulated packets from the 345 source zone-PE, decapsulate them, and forward them to its attached 346 service-node. The traffic that comes back to the service-PE from the 347 service-node must now be forwarded to the next service-node in the 348 chain. As above, the next service-node may be locally attached or at 349 a remote service-PE. 351 At the last service-PE in the chain, the traffic that comes back from 352 a service-node must be forwarded to the destination in the target 353 zone. Just as with the service-nodes, the destination may be attached 354 to the service-PE or reachable via another PE. 356 As can be seen from this description, a given packet flow needs to be 357 forwarded differently at each PE depending on whether it is arriving 358 from a node attached to the PE or from a remote PE, and depending on 359 whether the traffic is to be routed toward a node attached to the PE 360 or attached to a remote PE. The next-hop for a flow changes depending 361 on the relative position within the service chain. 363 Figure 1 illustrates a virtual service topology, where hosts in Zone 364 1 are interconnected with hosts in Zone 2 via two service nodes 365 (Serv-A and Serv-B) attached to two service-PEs (S-PE-A and S-PE-B 366 respectively). 368 """""""""""""""""""""" """""""""""""""""""""" 369 " +-------+ " +--------+ +--------+ " +-------+ " 370 " +-----+ | vPE-1 | " | S-PE-A | | S-PE-B | " | vPE-2 | +-----+ " 371 " |VM/CE|--| |---| |---| |---| |--|VM/CE| " 372 " +-----+ |(VRF-1)| " |(VRF-A) | |(VRF-B) | " |(VRF-2)| +-----+ " 373 " +-------+ " +--------+ +--------+ " +-------+ " 374 " " | | " " 375 " Zone 1 " +--------+ +--------+ " Zone 2 " 376 """""""""""""""""""""" | Serv-A | | Serv-B | """""""""""""""""""""" 377 +--------+ +--------+ 379 The different forwarding paths can be achieved at any PE as follows. 381 o Each service node is associated with two VRFs at the service PE to 382 which it is attached: an in-VRF for traffic toward the service 383 node, and an out-VRF for traffic from the service node. 385 o Traffic for the in-VRF arrives from the previous node in the 386 service chain, and traffic for the out-VRF is destined toward the 387 next node in the service chain, or toward the destination zone. 389 o The in-VRF has one or more routes with a next-hop of a local access 390 interface where the service node is attached. The out-VRF has 391 routes with a next-hop of the next service node, which may be 392 situated locally on the service-PE or at a remote PE. 394 The installation of the forwarding entries to implement the flow 395 described above may be achieved either via IP VPN mechanisms 396 described in Sections 4 and 5, or using an SDN approach, as described 397 in Section 6. 399 It should be noted that the steps and constructs are logical, and may 400 be implemented differently at each PE. Some options are specified in 401 this document where pertinent. 403 4. Inter-Zone Model 405 The inter-zone model to realize the forwarding operational flow 406 described in the previous section can be categorized into the 407 following steps. 409 4.1 Constructing the Virtual Service Topology 411 The virtual service topology described in the previous section is 412 constructed via one or more service-topology routes that direct the 413 traffic flow among the PEs and service nodes forming the service 414 chain. There should be a route to reach each service node. The 415 service topology, and hence the service routes, are constructed on a 416 per-VPN basis. This service topology setup is typically independent 417 of the routes for the actual destinations or flows that map to the 418 service topology. There can be multiple service topologies for a 419 given VPN. 421 4.1.1 Reachability to the Service Nodes 423 Each service node is identified by an IP address that is scoped 424 within the VPN. Specifically, there is an IP address for each 425 interface on the node that is part of a service chain. The service 426 node is also associated with an in-VRF and out-VRF table at the 427 attached service PE. 429 Reachability to the various service nodes in the service chain is 430 achieved via regular BGP/IP VPN route advertisements. 432 A service-PE will export a route to reach each service node interface 433 attached to it. The service node interface may be a physical or 434 logical interface. Each route will contain the Route-Target 435 configured for the VPN, and a forwarding label that enables the 436 service-PE to directly forward incoming traffic from the other PEs to 437 the service node. 439 The routes to reach the various service nodes are imported into and 440 installed in each service out-VRF at a service-PE, as well as in the 441 ingress zone VRF on an ingress zone PE. 443 The in-VRF and out-VRF are conceptual entities and may be realized in 444 different ways, as described further in this document. For instance, 445 the forwarding label described above serves the purpose of the in-VRF 446 in directing traffic from other PEs to an attached service node. 447 Similarly, a per-interface policy-based-routing rule applied to an 448 access interface serves to direct traffic coming in from attached 449 service nodes. 451 4.1.2 Provisioning the Service Chain 453 At each PE supporting a given VPN, the sequence of service nodes in a 454 service chain can be specified as a VPN service route-policy. 456 To create the service chain and give it a unique identity, each PE 457 may be provisioned with a route-policy that contains the following 458 tuple for every service chain that it belongs to: 460 {Service-topology-name, Service-topology-RT, Service-node- 461 Sequence} 463 where Service-node-Sequence is simply an ordered list of the service 464 node IP addresses that are in the chain. 466 Every service chain has a single unique service-topology-RT that is 467 provisioned on all participating PEs. 469 Each participating PE will also be provisioned with the tables, 470 interfaces and other VPN configuration for the various zone and 471 service VRFs needed on the PE based on attached nodes. 473 At an egress zone PE, the corresponding zone-VRF will have a route- 474 policy that attaches the appropriate Service-topology-RTs to routes 475 exported from the VRF. The ingress zone and service VRFs will have 476 the relevant Service-topology-RTs as import RTs. 478 The service route-policy that lists the service chain tuple described 479 above may be specified using various mechanisms. Using a YANG-defined 480 data model is one suitable option. 482 4.1.3 Service-topology Next-Hop Resolution 484 Routes representing hosts, VMs or other destinations associated with 485 a zone are termed as zone prefixes. A zone prefix will have its 486 regular zone-RTs attached when it is originated. This will be used by 487 PEs that have VRFs for the same zone to import these prefixes to 488 enable direct communication between end-points in the same zone. 490 In addition to the intra-zone RTs, zone prefixes may also be tagged 491 at the point of origination or an intermediate point, with the set of 492 Service-topology-RTs corresponding to the service chains that have 493 been set up towards this zone. 495 Since they are tagged with the Service-topology-RT, zone prefixes can 496 get imported into the VRFs of the PEs that form part of the service 497 chain associated to that Service-topology-RT. These routes may be 498 installed in the out-VRF at the service-PEs as well as in the ingress 499 zone's VRF. 501 However, the procedures described below introduce a change in the 502 actions related to next-hop resolution and route installation in the 503 service and ingress zone VRFs. These actions change the behavior of a 504 PE compared to normal BGP VPN behavior, but does not mandate protocol 505 changes to BGP. This modification to PE behavior allows the automatic 506 and constrained flow of traffic via the service chain. 508 The PE, based on the presence of a Service-topology-RT in the zone 509 routes it receives, will perform the following actions: 511 1. It will ignore the next-hop and VPN label that were advertised in 512 the NLRI. 514 2. Instead, it will select as next-hop the appropriate service node 515 from the Service-node sequence provisioned for the Service- 516 topology-RT. Specifically, in the out-VRF associated with each 517 attached service node, it will select the next service node in the 518 sequence. 520 3. It will further resolve this service next-hop IP address locally 521 in the associated VRF, instead of in the global routing table. The 522 VRF routing table contains routes to reach the service node's IP 523 address, installed as per Sec.4.1.1. The PE will use the next-hop 524 (and label, if remote) associated with this IP address to 525 encapsulate traffic toward the next service node. 527 4. If the importing service-PE is the last service-PE as per the 528 service chain tuple, it will use the VPN next hop that was 529 advertised with the zone prefix, for route resolution and 530 installation. It will also use the VPN label that came with the 531 prefix. 533 In this way, the zone prefixes in the intermediate service-PE hops 534 recurse over the nodes in the service chain forcing the traffic 535 destined to them to flow through the virtual service topology. 537 A significant benefit of this next-hop indirection is to avoid 538 redundant advertisements of zone prefixes from the egress zones and 539 service VRFs. Also, when the virtual service topology is changed (due 540 to addition or removal of service nodes), there should be no change 541 to the zone prefix's import/export RT configuration, and hence no re- 542 advertisement of zone prefixes. 544 4.1.4 Zone Prefix Route Aggregation 546 If the prefixes or addresses in a zone are aggregatable, instead of 547 the individual zone host or prefix routes being imported and used at 548 all hops along the chain, they may be aggregated at a specific hub PE 549 and the aggregate zone prefix used along the service chain between 550 zones. In such a case, the aggregate zone prefix will carry a 551 service-topology-RT and get imported in the ingress zone and service 552 VRFs. 554 In the simplest case, a default route may be used to carry a service- 555 topology-RT and get imported into the various service VRFs, thereby 556 setting up forwarding along the service topology. In this case, 557 however, the actual zone prefixes will be attached with a separate 558 service-topology-RT that is used only on the ingress zone-PE and the 559 last service-PE to import the zone prefixes into the respective VRFs. 561 4.1.5 Fine-grained traffic steering 563 In addition to a destination address or prefix, the steering of 564 traffic into a service chain may also be based on attributes of the 565 packet flow, such as source address or protocol and port types. 566 [FLOWSPEC] is one option that can be used to direct specific VPN 567 traffic into a specific service topology. 569 In this case, it is a flow-spec route that is advertised with the 570 appropriate Service-topology-RT attached, so that the importing PEs 571 resolve it using the service chain tuple as described above and 572 install the flow-spec route with the appropriate next-hop. 574 Using the scheme described in section 4.1.4, the flow-spec route may 575 be installed only in the ingress zone-PE VRF using a distinct 576 Service-topology-RT. 578 4.1.5 Multiple service topologies 580 There should be one service topology RT per virtual service topology. 581 There can be multiple virtual service topologies and hence service 582 topology RTs in a given VPN. 584 Virtual service topologies are constructed unidirectionally. Traffic 585 in opposite directions between the same pair of zones will be 586 supported by two different service topologies and hence two service 587 topology routes. These two service topologies might or might not be 588 symmetrical, i.e. they might or might not traverse the same sequence. 590 As noted above, a service node route is advertised with a label that 591 directs incoming traffic to the attached service node. Alternatively, 592 an aggregate label may be used for the service route and an IP route 593 lookup done in an in-VRF at the service-PE to send traffic to the 594 service node. 596 Note that a new service node could be inserted into the service chain 597 seamlessly by just configuring the service policy appropriately. 599 4.2 Per-VM Service Chains 601 While the service-topology-RT allows an efficient inheritance of the 602 service chain for all VMs or prefixes in a zone, there may be a need 603 to create a distinct service chain for an individual VM or prefix. 604 This may be done by provisioning a separate service-topology RT and 605 service node sequence. The VM route carries the service-topology RT, 606 and the destination and service PEs are provisioned with this RT as 607 described above. 609 5. Routing Considerations 611 5.1 Multiple Service Topologies 613 A service-PE can support multiple distinct service topologies for a 614 VPN. 616 5.2 Service scaling 618 One could use all tools available in BGP to constrain the propagation 619 and resolution of state created by the service topology [RFC4684]. 621 Additional service nodes can be introduced to scale out a particular 622 service. Each such service would be represented by a virtual IP 623 address, and multiple service nodes associated with it. Multiple 624 service-PEs may advertise a route to this address based on the 625 presence of an attached service node instance, thereby creating 626 multiple equal cost paths. This technique could be used to 627 elastically scale out the service nodes with traffic demand. 629 5.3 Supporting Service Redundancy 631 For stateful services an active-standby mechanism could be used at 632 the service level. In this case, the inter-zone traffic should prefer 633 the active service node over the standby service node. 635 At a routing level, this is achieved by setting up two paths for the 636 same service route: one path goes through the active service node and 637 the other through the standby service node. The active service path 638 can then be made to win over the standby service path by 639 appropriately setting the BGP path attributes of the service topology 640 route such that the active path succeeds in path selection. This 641 forces all inter-zone traffic through the active service node. 643 6. Orchestration Driven Approach 645 In an orchestration driven approach, there is no need for the zone or 646 service PEs to determine the appropriate next-hops based on the 647 specified service node sequence. All the necessary policy 648 computations are carried out, and the forwarding tables for the 649 various VRFs at the PEs determined, by a central orchestrator or 650 controller. 652 The orchestrator communicates with the various PEs (typically virtual 653 PEs on the end-servers) to populate the forwarding tables. 655 The protocol used to communicate between the controller/orchestration 656 and the PE/vPE must be a standard, programmatic interface. There are 657 several possible options to this programmatic interface, some being 658 under discussion in the IETF's Interface to Routing Systems (I2RS) 659 initiative, [I-D.ietf-i2rs-architecture], [I-D.ietf-i2rs-problem- 660 statement]. One specific option is defined in [IPSE]. 662 7. Security Considerations 664 To be added. 666 8. Management Considerations 667 To be added. 669 9. IANA Considerations 671 This proposal does not have any IANA implications. 673 10. Acknowledgements 675 The authors would like to thank the following individuals for their 676 review and feedback on the proposal: Eric Rosen, Jim Guichard, Paul 677 Quinn, Peter Bosch, David Ward, Ashok Ganesan and Thomas Morin. The 678 option of configuring an ordered sequence of service nodes via policy 679 is derived from a suggestion from Eric Rosen. 681 11. References 683 11.1 Normative References 685 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 686 Networks (VPNs)", RFC 4364, February 2006. 688 11.2 Informative References 690 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 691 Protocol 4 (BGP-4)", RFC 4271, January 2006. 693 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 694 R., Patel, K., and J. Guichard, "Constrained Route 695 Distribution for Border Gateway Protocol/MultiProtocol 696 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 697 Private Networks (VPNs)", RFC 4684, November 2006. 699 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 700 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 701 VPNs", RFC 7024, October 2013. 703 [I-D.fang-l3vpn-virtual-ce] 704 L. Fang, et al.,"BGP/MPLS IP VPN Virtual CE", 705 draft-fang-l3vpn-virtual-ce, work in progress. 707 [I-D.fang-l3vpn-virtual-pe] 708 L. Fang, et al., "BGP/MPLS IP VPN Virtual PE", 709 draft-fang-l3vpn-virtual-pe, work in progress. 711 [I-D.ietf-i2rs-architecture] 712 Atlas, A., Halpern, J., Hares, S., Ward, D., and T Nadeau, 713 "An Architecture for the Interface to the Routing System", 714 draft-ietf-i2rs-architecture, work in progress. 716 [I-D.ietf-i2rs-problem-statement] 717 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 718 Routing System Problem Statement", 719 draft-ietf-i2rs-problem-statement, work in progress. 721 [IPSE] 722 Fernando, R., Boutros, S., Rao, D., "Interface to a 723 Packet Switching Element", 724 draft-rfernando-ipse-00, work in progress. 726 Authors' Addresses 728 Dhananjaya Rao 729 Cisco 730 170 W Tasman Dr 731 San Jose, CA 732 Email: dhrao@cisco.com 734 Rex Fernando 735 Cisco 736 170 W Tasman Dr 737 San Jose, CA 738 Email: rex@cisco.com 740 Luyuan Fang 741 Microsoft 742 5600 148th Ave NE 743 Redmond, WA 98052 744 Email: lufang@microsoft.com 746 Maria Napierala 747 AT&T 748 200 Laurel Avenue 749 Middletown, NJ 07748 750 Email: mnapierala@att.com 752 Ning So 753 Vinci Systems, Inc. 754 Email: ningso@yahoo.com 756 Adrian Farrel 757 Juniper Networks 758 Email: adrian@olddog.co.uk