Network Working Group Han Nguyen (AT&T) Internet Draft James Uttaro (AT&T) Expiration Date: September 2011 Rahul Aggarwal (Juniper Networks) Intended Status: Proposed Standard Yakov Rekhter (Juniper Networks) March 7, 2011 Virtual Hub-and-Spoke in BGP/MPLS VPNs draft-rekhter-l3vpn-virtual-hub-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. [Page 1] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 Abstract With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1. Overview With BGP/MPLS VPNs [rfc4364] providing any-to-any connectivity among sites of a given Virtual Private Network (VPN) is usually accomplished by requiring each Provider Edge router (PE) that has one or more of these sites connected to it to hold all the routes of that VPN. The approach described in this document allows to reduce the number of PEs that have to maintain all these routes by requiring only a subset of such PEs to maintain all these routes. Consider a VPN that has its sites connected to a set of PEs. In the context of this VPN we designate a subset of these PEs as "Virtual Spoke" PEs (or just Virtual Spokes), while the rest of PEs in the set will be "Virtual Hub" PEs (or just Virtual Hubs). For a given VPN, its set of Virtual Hubs could include not only the PEs that have sites of that VPN connected to them, but also PEs that have no sites of that VPN connected to them. Note that while in the context of one VPN a given PE may act as a Virtual Hub, in the context of another VPN the same PE may act as a Virtual Spoke, and vice versa. Thus a given PE may act as a Virtual Hub only for some, but not all the VPNs present on that PE. Likewise, a given PE may act as a Virtual Spoke only for some, but not all the VPNs present on that PE. For a given VPN each Virtual Spoke of that VPN is "associated" with two or more Virtual Hubs of that VPN (we use two Virtual Hubs for redundancy to avoid a single point of failure). Note that a given Virtual Hub may have no Virtual Spokes associated with it, in which case it acts as a "vanilla" PE. [Page 2] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 A PE that acts as a Virtual Hub of a given VPN maintains all the routes of that VPN. A PE that acts as a Virtual Spoke of a given VPN needs to maintain only the routes originated by the sites of that VPN connected to that PE, plus two or more VPN-IP default routes whose Next Hops are the addresses of the Virtual Hubs associated with that Virtual Spoke. This way, only a subset of PEs that have sites of a given VPN, namely only the PEs acting as Virtual Hubs of that VPN, have to maintain all the routes of that VPN. PEs acting as Virtual Spokes of that VPN need to maintain only a (small) subset of the routes of that VPN. 2. Routing Information Exchange Routing information exchange among all the PEs of a given VPN is subject to the following rules. A PE that has sites of a given VPN connected to it has to retain routing information received from the VPN sites connected to it. This is irrespective of whether the PE acts as a Virtual Hub or a Virtual Spoke of that VPN. A PE that has sites of a given VPN connected to it has to export (as VPN-IP routes) all the routes received from these sites. This is irrespective of whether the PE acts as a Virtual Hub or a Virtual Spoke of that VPN. In addition, a Virtual Hub of a given VPN has to export a VPN-IP default route for that VPN. This route SHOULD be exported to only the Virtual Spokes of that VPN that are associated with that Virtual Hub. To enable a Virtual Spoke of a given VPN to share its outbound traffic load among the Virtual Hubs associated with that Spoke, each Virtual Hub of that VPN, when originating a VPN-IP default route MUST use a distinct RD (per Hub, per VPN). If one or more sites of a given VPN originate an IP default route (e.g., this may happen when these sites have connection to the Internet), and the PEs connected to these sites re-advertise it as a VPN-IP default route, then these PEs MUST act as Virtual Hubs of that VPN. It is RECOMMENDED that this VPN-IP default route be of higher preference than a VPN-IP default route originated by a Virtual Hub that does not receive an IP default route from one of the VPN sites connected to it. A Virtual Hub of a given VPN has to import all the non-default VPN-IP routes originated by all other PEs that have sites of that VPN connected to them (irrespective of whether these other PEs act as [Page 3] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 Virtual Hubs or Virtual Spokes for that VPN). A Virtual Hub of a given VPN MUST NOT import a VPN-IP default route unless this route has been originated by another Virtual Hub that has sites connected to it, and these sites originate a default route used for Internet connectivity. In other words, the Virtual Hub of a given VPN MUST NOT import a VPN-IP default route, unless this route has been originated by some other Virtual Hub, and that other Virtual Hub originated this default route as a result of receiving an IP default route from one of the CEs of that VPN connected to that other Virtual Hub. A Virtual Spoke of a given VPN has to import a VPN-IP default route for that VPN that has been originated by the Virtual Hubs of that VPN that are associated with that Virtual Spoke. In addition, a Virtual Spoke of a given VPN MAY import VPN-IP routes for that VPN that have been originated by some other Virtual Spokes of that VPN. The above rules that govern the routing information exchange among all the PEs of a given VPN are realized using Route Target (RT) extended communities [rfc4360] and VRF export/import policies based on these RTs. One possible scheme that enables to realize such rules is described in Section "Deployment Scenarios". This document does not preclude use of other schemes, as long as such schemes would support the above rules. 3. Forwarding Considerations This section describes changes/modifications to the forwarding procedures specified in [rfc4364]. A Virtual Hub of a given VPN MUST use a VRF-table-label pointing to the VRF of that VPN for the MPLS label that the Hub advertises with a VPN-IP default route for that VPN. When a Virtual Hub of a given VPN originates a VPN-IP default route for that VPN, the Virtual Hub MUST NOT install in its VRF of that VPN a default route, unless this route has been originated either (a) as a result of the Virtual Hub receiving an IP default route from one of the CEs of that VPN connected to it, or (b) as a result of the Virtual Hub receiving (and importing) a VPN-IP default route from some other Virtual Hub. In the absence of Virtual Hubs and Virtual Spokes, support for [Page 4] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 IBGP/EBGP load balancing in the presence of any-to-any connectivity uses the following rule. When a PE receives a packet from another PE, the PE that receives the packet determines (using the MPLS label carried in the packet) the VRF that should be used for further forwarding the packet. If (using the information present in the VRF) the PE determines that the packet could be forwarded over one of the attachment circuits of that VRF (for the definition of "VRF attachment circuits" see [rfc4364]), then the PE MUST forward the packet over one of these circuits, and MUST NOT forward the packet to another PE. In order to support IBGP/EBGP load balancing on a Virtual Hub the above rule is modified as follows. When a Virtual Hub receives a packet from another PE scenario, the Virtual Hub identifies (using the MPLS label carried in the packet) the VRF that should be used for further forwarding the packet. If the MPLS label carried in the packet is the label that the Virtual Hub advertised in the VPN-IP default route, then the Virtual Hub is not restricted to use only one of the VRF attachment circuits for forwarding the packet - the Virtual Hub may forward the packet to another PE. To illustrate this consider the following example: <- RD:0/0 RD:0/0-> <- RD:10.2.1 <-10.2.1/24 CE1----PE-S-------------PE-H----------------PE-S1--------------CE2 / | | | | 10.2.1/24 | | CE4 CE3 A multi-homed site (not shown in the above figure) is connect via CE2 and CE3. Thus both CE2 and and CE3 advertise a route to 10.2.1/24. CE2 advertises this route to PE-S1, which in turn originates a VPN-IP route RD:10.2.1. CE3 advertises this route to PE-H. PE-H is a Virtual Hub, while PE-S and PE-S1 are Virtual Spokes associated with that Virtual Hub. Thus PE-H originates a VPN-IP default route (RD:0/0), and both PE-S and PE-S1 import that route. PE-H receives from PE-S1 a VPN-IP route to RD:10.2.1 and from CE3 a plain IP route to 10.2.1. Thus the VRF entry on PE-H has two possible next hops for 10.2.1: CE3 and PE-S1 (the latter is an indirect next hop). [Page 5] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 Now consider what happens when CE1 originates a packet destined to 10.2.1.1. When PE-S receives this packet, PE-S (following the VPN-IP default route) forwards the packet to PE-H. In the absence of the modification specified above, when PE-H receives this packet, PE-H will be forced to forward the packet to CE3 (as PE-H can reach CE3 via a VRF attachement circuit). However, that would prevent IBGP/EBGP load balancing, as it would preclude the possiblity of forwarding this packet via PE-S1 and CE2. With the modified rule specified above, PE-H determines that the MPLS label in the packet is the MPLS label that PE-H advertised to PE-S in the VPN-IP default route. Thus PE-H may forward the packet either via CE3 or via PE-S1 (with PE-S1 subsequently forwarding the packet to CE2), resulting in preseving IBGP/EBGP load balancing. Likewise, if CE4 originates a packet destined to 10.2.1.1, PE-H may forward the packet either via CE3 or via PE-S1 (with PE-S1 subsequently forwarding the traffic to CE2), resulting in preserving IBGP/EBGP load balancing. Note however, that if there is some other CE, CE5, connected to PE- S1, and that CE5 sends a packet to 10.2.1.1, then (due to the IP longest match rule) PE-S1 will always forward this packet to CE2. Thus IBGP/EBGP load balancing will not be available for the destinations that have been learned locally by a Virtual Spoke. 4. Deployment considerations For a given VPN a Virtual Hub and a set of Virtual Spokes associated with that Virtual Hub should be chosen in a way that minimizes the additional network distance/latency penalty, given that VPN geographic footprint. For a given VPN some/all of its Virtual Spokes could be grouped into geographically-based clusters with any-any connectivity within each cluster. Note that the Virtual Spokes within a given cluster need not be associated with the same Virtual Hub(s). Likewise, not all Virtual Spokes associated with a given Virtual Hub need to be in the same cluster. A use case for this would be VPN for large retail chain in which data traffic is hub/spoke between each store and centralized data-centers but there is need for direct VoIP traffic between stores within same geographical area. The following describes one possible scheme that enables to realize the rules for exchanging routing information among PEs, as specified in Section "Routing Information Exchange". [Page 6] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 Consider a "vanilla" any-to-any VPN. All the PEs of such VPN are provisioned with the same export and import RT. To evolve this VPN into Virtual Hubs and Spokes we keep the same export RT on all the PEs of that VPN (both Virtual Hubs and Virtual Spokes). This RT is attached to all the VPN-IP routes that PEs originate as a result of receiving corresponding IP routes from their CEs (including the VPN- IP default route originated as a result of receiving an IP default route). We also keep the same Import RT on all the Virtual Hubs. In addition, each Virtual Hub is provisioned with its own RT, called RT-VH. This RT-VH MUST be different from the export RT provisioned on that Virtual Hub. For a given PE this RT-VH has to be distinct for every Virtual Hub present on that PE. To avoid the situation where within a given VPN all the Virtual Spokes would be associated with every Virtual Hub (in other words, to partition Virtual Spokes among Virtual Hubs), different Virtual Hubs within that VPN SHOULD use different RT-VHs. Use of IP-address specific RTs may be an attractive option for RT-VHs. When a Virtual Hub originates a VPN-IP default route, if this route is NOT originated as a result of receiving an IP default route from one of the CEs of that VPN connected to the Virtual Hub, then the Virtual Hub attaches RT-VH to that route. A given Virtual Spoke is provisioned to import only VPN-IP routes that carry RT-VH of the Virtual Hubs associated with that Virtual Spoke (thus associating a new Virtual Spoke with a given Virtual Hub requires provisioning only on that Virtual Spoke - no provisioning changes are required on the Virtual Hub). Use of RT Constrains [rfc4684] may further facilitate/optimize routing exchange in support of Virtual Hubs and Spokes. 5. An example of RT provisioning Consider a VPN A that consists of 9 sites - site-1 through site-9. Each site is connected to its own PE - PE-1 through PE-9. We designate PE-3, PE-6, and PE-9 as Virtual Hubs. PE-1 and PE-2 are Virtual Spokes associated with PE-3. PE-4 and PE-5 are Virtual Spokes associated with PE-6. PE-7 and PE-8 are Virtual Spokes associated with PE-9. All the PEs (both Virtual Hubs and Virtual Spokes) are provisioned to export routes using RT-A (just as it would be with "vanilla" any-to- any VPN). [Page 7] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 All the Virtual Hubs (PE-3, PE-6, and PE-9) are provisioned to import routes with RT-A (just as it would be with "vanilla" any-to-any VPN). In addition, PE-3 is provisioned to originate a VPN-IP default route with RT-A-VH-1, while PE-1 and PE-2 are provisioned to import routes with RT-A-VH-1. Likewise, PE-6 is provisioned to originate a VPN-IP default route with RT-A-VH-2, while PE-4 and PE-5 are provisioned to import routes with RT-A-VH-2. Finally, PE-9 is provisioned to originate a VPN-IP default route with RT-A-VH-3, while PE-7 and PE-8 are provisioned to import routes with RT-A-VH-3. Now let's modify the above a bit by assuming that site-3 has Internet connectivity. Thus site-3 advertises an IP default route to PE-3. PE-3, in turn originates a VPN-IP default route. In this case, the VPN-IP default route carries RT-A (rather than RT-A-VH-1, as before), which results in importing this route to PE-3, PE-6, and PE-9. 6. IANA Considerations This document introduces no new IANA Considerations. 7. Security Considerations This document introduces no new Security Considerations, above and beyond what is already specified in [rfc4364]. 8. Acknowledgements 9. Normative References [rfc4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [rfc4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [rfc4684] Pedro Marques, et al., "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC4684, November 2006 [Page 8] Internet Draft draft-rekhter-l3vpn-virtual-hub-00.txt March 1, 2011 10. Non-normative References 11. Authors' Addresses Han Nguyen AT&T e-mail: han.nguyen@att.com James Uttaro AT&T e-mail: ju1738@att.com Rahul Aggarwal Juniper Networks, Inc. e-mail: rahul@juniper.net Yakov Rekhter Juniper Networks, Inc. e-mail: yakov@juniper.net [Page 9]