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]