Internet DRAFT - draft-rekhter-l3vpn-virtual-hub

draft-rekhter-l3vpn-virtual-hub









Network Working Group                                 Huajin Jeng (AT&T)
Internet Draft                                       James Uttaro (AT&T)
Expiration Date: March 2012                         Luay Jalil (Verizon)
Intended Status: Proposed Standard       Bruno Decraene (France Telecom)
                                        Yakov Rekhter (Juniper Networks)
                                       Rahul Aggarwal (Juniper Networks)
                                                       September 6, 2011

                 Virtual Hub-and-Spoke in BGP/MPLS VPNs

                 draft-rekhter-l3vpn-virtual-hub-02.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-02.txtSeptember 6, 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 some other (non-
   overlapping) subset of these PEs will be "Virtual Hub" PEs (or just
   Virtual Hubs), with the rest of the PEs in the set will be "vanilla"
   PEs (PEs that implement the [rfc4364] procedures, but do not
   implement procedures specified in this document).

   For the sake of brevity we will use the term "V-hub" to denote a
   Virtual Hub, and "V-spoke" to denote a Virtual Spoke.

   For a given VPN, its set of V-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 V-
   hub, in the context of another VPN the same PE may act as a V-spoke,
   and vice versa. Thus a given PE may act as a V-hub only for some, but
   not all the VPNs present on that PE. Likewise, a given PE may act as



                                                              [Page 2]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   a V-spoke only for some, but not all the VPNs present on that PE.

   For a given VPN each V-spoke of that VPN is "associated" with two or
   more V-hubs of that VPN (we use two V-hubs for redundancy to avoid a
   single point of failure). Note that a given V-hub may have no V-
   spokes associated with it.

   A PE that acts as a V-hub of a given VPN maintains all the routes of
   that VPN. A PE that acts as a V-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 V-hubs associated with that V-
   spoke. This way, only a subset of PEs that have sites of a given VPN,
   namely only the PEs acting as V-hubs of that VPN,  have to maintain
   all the routes of that VPN. PEs acting as V-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 this PE acts as a V-hub or a V-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 this PE acts as a V-hub or a V-spoke of that
   VPN.

   In addition, a V-hub of a given VPN has to export a VPN-IP default
   route for that VPN. This route SHOULD be exported to only the V-
   spokes of that VPN that are associated with that V-hub.

   To enable a V-spoke of a given VPN to share its outbound traffic load
   among the V-hubs associated with that V-spoke, each V-hub of that
   VPN, when originating a VPN-IP default route MUST use a distinct RD
   (per V-hub, per VPN).

   If a V-spoke imports several VPN-IP default routes, each originated
   by its own V-hub, and these routes have the same preference, then
   traffic from the V-spoke to other sites of that VPN would be load
   shared among the V-hubs.

   A V-hub of a given VPN has to import all the non-default VPN-IP



                                                              [Page 3]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   routes originated by all other PEs that have sites of that VPN
   connected to them (irrespective of whether these other PEs act as V-
   hubs or V-spokes for that VPN).

   A V-hub of a given VPN MUST NOT import a VPN-IP default route unless
   this is the Internet VPN-IP default route (for the definition of
   "Internet VPN-IP default route" see section "Internet Connectivity").

   A V-spoke of a given VPN has to import a VPN-IP default route for
   that VPN that has been originated by the V-hubs of that VPN that are
   associated with that V-spoke.

   In addition, a V-spoke of a given VPN MAY import VPN-IP routes for
   that VPN that have been originated by some other V-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 Considerations". 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].

   The MPLS label that the V-hub advertises with a VPN-IP default route
   MUST be the label that points to the VRF of the V-hub.  This way,
   whenever the V-hub receives packets carrying this label, the V-hub
   forwards the packets by performing IP lookup in the VRF identified by
   the label.

   When a V-hub of a given VPN originates a VPN-IP default route for
   that VPN, the V-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 V-hub receiving an IP default route from one of the CEs of
   that VPN connected to it, or (b) as a result of the V-hub receiving
   (and importing) a VPN-IP default route from some other PE, or (c) the
   VRF being provisioned with a default route pointing to the routing
   table on the same PE that maintains the Internet routes.

   In the absence of V-hubs and V-spokes, support for 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



                                                              [Page 4]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   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 V-hub the above
   rule is modified as follows. When a V-hub receives a packet from
   another PE scenario, the V-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 V-hub advertised in the VPN-IP default route, then the
   V-hub is not restricted to use only one of the VRF attachment
   circuits for forwarding the packet - the V-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 V-hub, while PE-S and PE-S1 are V-spokes associated with
   that V-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).

   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



                                                              [Page 5]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   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 attachment circuit).  However, that would prevent IBGP/EBGP
   load balancing, as it would preclude the possibility 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 preserving 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 V-spoke.

   Moreover, if CE3 advertises 10.2.1.0/25 and 10.2.1/24, while CE2
   advertises 10.2.1.128/25 and 10.2.1/24 (which is yet another form of
   load balancing for a multi-homed site), then when 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, even though the VPN customer would
   expect this traffic to flow via CE3.

   This document proposes two options to address this, as well as to
   make the IBGP/EBGP load balancing available for the destinations that
   have been learned locally by a V-spoke. One option is to provision
   PEs that have multi-homed sites connected to them as V-hubs. Another
   option is for the V-spoke, when it receives an IP route from a CE,
   not to install this route in its forwarding table, but just re-
   advertise this route as a VPN-IP route, together with an MPLS label.
   The packet's next hop of the Next Hop Label Forwarding Entry (NHLFE)
   [rfc3031] associated with that label MUST point to the CE that
   advertised the IP route. As a result, when the PE receives data that
   carries that label, the PE performs no IP lookup on the data, and
   just forwards the data to the CE. Note that doing this would result
   in forcing the traffic between a pair of sites connected to the same
   V-spoke to go through the V-hub of that V-spoke.







                                                              [Page 6]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


4. Internet Connectivity

   In this document we consider two possible scenarios of providing
   Internet connectivity for a given VPN.

   The first scenario is when one or more sites of a given VPN are
   connected to a PE, and that PE also maintains Internet routes. In
   this case the Internet connectivity for that VPN is provided by
   provisioning in the VPN's VRF on that PE a default route pointing to
   the routing table on that PE that maintains the Internet routes.
   This PE MUST act as a V-hub for that VPN, and therefore MUST
   originate a VPN-IP default route.

   The second scenario is when a site of a given VPN has connection to
   the Internet, and a CE of that site advertises an IP default route to
   the PE connected to that CE. This scenario has two sub-cases: (a) PE
   is provisioned as a V-hub, and (b) PE is provisioned as a V-spoke.

   If a PE is provisioned as a V-hub, then the PE re-advertises this IP
   default route as a VPN-IP default route, and install in its VRF an IP
   default route with the next hop pointing to the CE(s) that advertise
   the IP default route to the PE.

   If a PE is provisioned as a V-spoke, then the PE MUST NOT install in
   its VRF an IP default route. The PE MUST originate a VPN-IP default
   route with a (non-null) MPLS label. The packet's next hop of the Next
   Hop Label Forwarding Entry (NHLFE) [rfc3031] associated with that
   label MUST point to the CE that advertises the IP default route. As a
   result, when the PE receives data that carries that label, the PE
   performs no IP lookup on the data, and just forwards the data to the
   CE. Note that in this case the VRF on the PE is going to have an IP
   default route, but this route would be created as a result of
   receiving a VPN-IP default route from one of the V-hubs of that PE
   (and not as a result of receiving the IP default route from the CE).
   Note also that if this PE has other sites of that VPN connected to
   it, then traffic from these sites to the Internet would go to that
   PE, then to the V-hub selected by the PE, then from that V-hub back
   to the PE, and then to the CE that advertises IP default route to the
   PE.

   If a PE is provisioned as a V-spoke of a given VPN, and if a CE of
   that VPN advertises an IP default route to the PE (as the CE belongs
   to the site that provides the Internet connectivity for the VPN),
   then the PE can not advertise an IP default route back to that CE.
   Yet, the CE has to point to the PE as the next hop for all the
   traffic to other sites of that VPN. This document proposes the
   following options to accomplish this. The first option is to require
   the V-spoke to implement procedures of section "Further refinements".



                                                              [Page 7]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   The second option is for the V-spoke to advertise to the CE 10/8,
   172.16/12, and 192.168/16. Note that this option is applicable only
   if the service provider knows that the VPN customer uses only the
   [rfc1918] addresses. The third option is to re-provision this PE as a
   V-hub.

   In all of the above we refer to the originated VPN-IP default route
   as the "Internet VPN-IP default route".

   Note that if a V-hub originates the Internet VPN-IP default route for
   a given VPN, the V-hub does not originate any other VPN-IP default
   routes for that VPN.

   If a V-hub originates the Internet VPN-IP default route, then all the
   V-spokes associated with that V-hub MUST import that route. In
   addition (and in contrast with a non-Internet VPN-IP default route),
   other V-hubs MAY import that route.

   A V-hub MAY also import the Internet VPN-IP default routes originated
   by V-spoke(s).

   A V-spoke MUST NOT import the Internet VPN-IP default route
   originated by any other V-spoke. Such a route MAY be imported only by
   V-hubs.

   The above rules that govern exchange of the Internet VPN-IP default
   route 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
   Considerations".  This document does not preclude use of other
   schemes, as long as such schemes would support the above rules.

   If the Internet VPN-IP default route originated by a V-hub has the
   same preference as the (non Internet) VPN-IP default route originated
   by some other V-hub, then a V-spoke that imports VPN-IP default
   routes originated by both of these V-hubs would load share the
   outgoing Internet traffic between these two V-hubs (and thus some of
   the outgoing Internet traffic from that V-spoke will first be routed
   to the V-hub that does not originate the Internet VPN-IP default
   route, and then from that V-hub to the V-hub that does originate the
   Internet VPN-IP default route).

   If taking an extra-hub hop for the Internet traffic is viewed as
   undesirable, then it is RECOMMENDED that the Internet VPN-IP default
   route be of higher preference than a (non-Internet) VPN-IP default
   route originated by some other V-hub.  However, in this case the
   traffic from the V-spokes to other sites of that VPN will not be load



                                                              [Page 8]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   shared between these two V-hubs.


5. Deployment Considerations

   For a given VPN a V-hub and a set of V-spokes associated with that V-
   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 V-spokes could be grouped into
   geographically-based clusters with any-any connectivity within each
   cluster. Note that the V-spokes within a given cluster need not be
   associated with the same V-hub(s). Likewise, not all V-spokes
   associated with a given V-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".

   Consider a "vanilla" any-to-any VPN. All the PEs of such VPN are
   provisioned with the same export and import RT - we will refer to
   this RT as RT-VPN.

   To evolve this VPN into V-hubs and V-spokes we keep the same export
   RT-VPN on all the PEs of that VPN (both V-hubs and V-spokes). This
   RT-VPN is attached to all the VPN-IP routes that PEs originate as a
   result of receiving corresponding IP routes from their CEs.  We also
   keep the same import RT-VPN on all the V-hubs.

   In addition, each V-hub is provisioned with its own import RT, called
   RT-VH.  This RT-VH MUST be different from the export RT provisioned
   on that V-hub. For a given PE this RT-VH has to be distinct for every
   V-hub present on that PE. To avoid the situation where within a given
   VPN all the V-spokes would be associated with every V-hub (in other
   words, to partition V-spokes among V-hubs), different V-hubs within
   that VPN MAY use different RT-VHs. At one extreme every V-hub may use
   a distinct RT-VH. However, it is also possible for several V-hubs to
   use the same RT-VH, in which case all these V-hubs are used by the
   same set of V-spokes. Use of IP-address specific RTs may be an
   attractive option for RT-VHs.

   When a V-hub originates a (non-Internet) VPN-IP default route, then
   the V-hub attaches RT-VH to that route. Thus this route is imported
   by all the V-spokes associated with the V-hub.



                                                              [Page 9]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   If a V-hub originates the Internet VPN-IP default route, then the V-
   hub attaches both RT-VH and RT-VPN to that route. Thus this route is
   imported by all the V-spokes associated with the V-hub, as well as by
   other V-hubs.

   If a V-spoke originates the Internet VPN-IP default route, then the
   V-spoke attaches only RT-VPN to that route. Thus this route is not
   imported by any of the V-spokes, but is imported by V-hubs.

   A given V-spoke is provisioned to import only VPN-IP routes that
   carry RT-VHs of the V-hubs associated with that V-spoke (thus
   associating a new V-spoke with a given V-hub requires provisioning
   only on that V-spoke - no provisioning changes are required on the V-
   hub).

   A V-spoke may be provisioned to export VPN-IP routes not just to the
   V-hubs, but also to the V-spokes that import the same VPN-IP default
   route(s) as the V-spoke itself. The V-spoke accomplishes this by
   adding its import RT-VH(s) to the VPN-IP routes exported by the V-
   spoke.

   Use of RT Constrains [rfc4684] may further facilitate/optimize
   routing exchange in support of V-hubs and V-spokes.


6. Multicast Considerations

   This section describes procedures for supporting MVPN in the presence
   of Virtual Hub-and-Spoke. The procedures rely on MVPN specifications
   as defined in [MVPN], [BGP-MVPN].

   The procedures assume that for the purpose of ensuring non-
   duplication both V-hubs and V-spokes can discard packets from a
   "wrong" PE, as specified in [MVPN]. This applies for all types of P-
   tunnels, including Ingress Replication.


6.1. Terminology

   When Ingress Replication is used to realize P-tunnels, a P-tunnel
   being "bound" to a particular I-PMSI/S-PMSI A-D route means the set
   of (unicast) tunnels used to carry traffic from the PE originating
   the route to the PEs that import the route.

   When Ingress Replication is used to realize P-tunnels, traffic
   received by a PE on a P-tunnel "bound" to particular I-PMSI/S-PMSI A-
   D received by the PE means the traffic received on the (unicast)
   tunnel that the PE originating the route uses to send traffic to the



                                                             [Page 10]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   PE that receives the route.


6.2. Eligible Upstream Multicast Hop (UMH) routes

   On a V-spoke the set of Eligible UMH routes consists of all the
   unicast VPN-IP routes received by the V-spoke, including the default
   VPN-IP routes received from its V-hub(s). Note that such routes may
   include VPN-IP routes received from other V-spokes.


6.3. Originating VPN-IP default route by a V-hub

   A V-hub, when originating a VPN-IP default route, follows the
   procedures of [BGP-MVPN]. Specifically the V-hub must add the VRF
   Route Import extended community that embeds the V-hub's IP address.
   The route also must include the Source AS extended community.


6.4. Handling C-multicast routes

   Origination of C-multicast routes follow the procedures of [BGP-MVPN]
   (this is irrespective of whether these routes are originated by a V-
   hub or by a V-spoke). Note that for a given V-spoke its set of
   eligible UMH routes may contains not only the VPN-IP default routes
   advertised by its V-hubs, but also VPN-IP routes advertised by some
   other V-spokes.

   When a V-hub receives a C-multicast route, the V-hub determines
   whether the C-RP/C-S of the route is reachable via one of its VRF
   interfaces, and if yes, then the V-hub follows the [BGP-MVPN]
   procedures. Otherwise, the C-RP/C-S of the route is reachable via
   some other PE, in which case the V-hub uses the type (Source Tree
   Join vs Shared Tree Join), the Multicast Source, and Multicast Group
   from the received route to construct a new route. The hub constructs
   the rest of the new route following procedures specified in "11.1.3.
   Constructing the rest of the C-multicast route" of [BGP-MVPN]. The
   hub also creates the appropriate (C-*, C-G)/(C-S, C-G) state in its
   MVPN-TIB.


6.5. Originating I-PMSI/S-PMSI/SA A-D routes by V-spoke

   When a V-spoke originates an I-PMSI/S-PMSI/SA A-D route, the V-spoke
   follows the procedures of [BGP-MVPN], including the procedures for
   constructing RT(s) carried by the route. Note that as a result, such
   a route will be imported by the V-hubs. The P-tunnel bound to this
   route is used to carry to these V-hubs traffic originated by the



                                                             [Page 11]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   sites connected to the V-spoke.

   This route may also be imported by some other V-spokes - the V-spokes
   that import the (unicast) VPN-IP routes originated by the V-spoke
   that originates the I-PMSI/S-PMSI/SA A-D route. In this case the
   route would carry not one, but two RTs: the first one results in
   importing the route by V-hubs, the second results in importing the
   route by the V-spokes (the second RT is the RT that V-spoke use for
   importing the VPN-IP default route). In this case the P-tunnel bound
   to this route is also used to carry traffic originated by the sites
   connected to the V-spoke that originates the route to these other V-
   spokes.


6.6. Originating I-PMSI/S-PMSI/SA A-D routes by V-hub

   When a V-hub originates an I-PMSI/S-PMSI/SA A-D route, the V-hub
   follows the procedures of [BGP-MVPN], except that in addition to the
   RT(s) constructed following these procedures, the route also carries
   the RT of the VPN-IP default route advertised by the V-hub.  Note
   that as a result, such a route will be imported by other V-hubs, and
   also by the V-spokes, but only by the V-spokes that import the VPN-IP
   default route originated by the V-hub.  The P-tunnel bound to this
   route is used to carry to these other V-hubs and V-spokes the traffic
   originated by the sites connected to the V-hub that originates the
   route.

   In addition, a V-hub originates another I-PMSI A-D route - we'll
   refer to this route as a "Default I-PMSI A-D route". The RT carried
   by this route is the RT that is carried in the VPN-IP default route
   advertised by the V-hub (RT-VH). Therefore, this route will be
   imported only by the V-spokes that import the VPN-IP default route
   advertised by this V-hub. The P-tunnel bound to this route is used to
   carry to these V-spokes traffic originated by either (a) other V-
   hubs, or (b) V-spokes, including the V-spokes that import the VPN-IP
   default route from the V-hub. More details on the use of this P-
   tunnel is described later.

   As a result, a V-hub originates not one, but two I-PMSI A-D routes.
   Each of these routes MUST have a distinct RD.

   When a V-hub receives traffic from one of the sites connected to the
   V-hub, and the V-hub determines (using some local policies) that this
   traffic should be transmitted using an I-PMSI, the V-hub forwards
   this traffic on the P-tunnel bound to the first (non Default) I-PMSI
   A-D route, but not on the P-tunnel bound to the second, the Default
   I-PMSI A-D route.




                                                             [Page 12]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


6.7. Receiving I-PMSI/S-PMSI/SA A-D routes by V-spoke

   When a V-spoke receives an I-PMSI/S-PMSI/SA A-D route, the V-spoke
   follows the procedures of [BGP-MVPN]. As a result, a V-spoke that
   imports the VPN-IP default route originated by a given V-hub will
   also import I-PMSI/S-PMSI/SA A-D routes originated by that V-hub.
   Specifically, the V-spoke will import both the non Default I-PMSI A-D
   route and the Default I-PMSI A-D route originated by the V-hub.

   In addition, if a V-spoke imports the (unicast) VPN-IP routes
   originated by some other V-spokes, then the V-spoke will also import
   I-PMSI/S-PMSI/SA A-D routes originated by these other V-spokes.


6.8. Receiving I-PMSI/S-PMSI/SA A-D routes by V-hub

   The following describe procedures that a V-hub must follow when it
   receives an I-PMSI/S-PMSI/SA A-D route.


6.8.1. Case 1

   This is the case where the received I-PMSI/S-PMSI/SA A-D route was
   originated by a V-spoke that imports the VPN-IP default route
   originated by the V-hub, and the received route is imported not just
   by the V-hub (as well as by all other V-hubs), but also by other V-
   spokes, but only by the V-spokes that import the VPN-IP default route
   originated by the V-hub. This is also the case where the received
   route was originated by a V-hub that uses the same RT as the received
   V-hub for advertising the VPN-IP default route.

   In this case the received I-PMSI/S-PMSI/SA A-D route carries more
   than one RT. One of these RTs results in importing this route by the
   V-hubs. Another of these RTs is the RT that the V-hub uses when
   advertising its VPN-IP default route (RT-VH). This RT results in
   importing the received I-PMSI/S-PMSI/SA A-D route o all the V-spokes
   that import the VPN-IP default route originated by the V-hub.

   In handling such I-PMSI/S-PMSI/SA A-D route the V-hub follows the
   [BGP-MVPN] procedures. Specifically, in contrast to Case 2 below, the
   V-hub MUST NOT re-advertise this route.

   The V-hub may forward traffic received on a P-tunnel bound to this I-
   PMSI/S-PMSI A-D route to only the sites connected to that V-hub.  The
   V-hub MUST NOT forward the traffic received on this P-tunnel to any
   other V-hubs or V-spokes, including the V-spokes that import the VPN-
   IP default route originated by the V-hub. Specifically, the V-hub
   MUST NOT forward the traffic received on the P-tunnel advertised in



                                                             [Page 13]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   the received I-PMSI A-D route over the P-tunnel that the V-hub binds
   to its Default I-PMSI A-D route.


6.8.2. Case 2

   This is the case where the received I-PMSI/S-PMSI/SA A-D route was
   originated by either some other V-hub, or by a V-spoke. The I-PMSI/S-
   PMSI/SA A-D route is imported by the V-hub (as well as by other V-
   hubs), but not by any of the V-spokes that import the VPN-IP default
   route originated by the V-hub.

   In this case the received I-PMSI/S-PMSI/SA A-D route does not carry
   the RT that the receiving V-hub uses when advertising its VPN-IP
   default route (RT-VH), although the route may carry more than one RT.

   In this case the V-hubs follows the procedures of [BGP-MVPN] with the
   following additions.

   Once a V-hub accepts an I-PMSI A-D route, when the V-hub receives
   data on the P-tunnel bound to that I-PMSI A-D route, the V-hub
   follows procedures in [MVPN], [MVPN-BGP] to determine whether to
   accept the data. If the data is accepted, then the V-hub further
   forwards the data over the P-tunnel bound to the Default I-PMSI A-D
   route originated by the V-hub. Note that in deciding whether to
   forward the data over the P-tunnel bound to the Default I-PMSI A-D
   route originated by the V-hub, the V-hub SHOULD take into account the
   (multicast) state present in its MVPN-TIB that has been created as a
   result receiving C-multicast routes from the V-spokes associated with
   the V-hub.

   Whenever a V-hub accepts an S-PMSI/SA A-D route, the V-hub, in
   contrast to Case 1 above, MUST re-advertise this route to its V-
   spokes. To accomplish this, the V-hub changes the RT carried by the
   route to the RT that the V-hub uses when originating its VPN-IP
   default route (RT-VH), and sets Next Hop to self. In addition, for S-
   PMSI/SA A-D routes the V-hub changes the RD of the route to the RD
   that the hub uses when originating its VPN-IP default route, and for
   S-PMSI A-D routes the V-hub changes the Originating Router's IP
   address in the MCAST-VPN NLRI of the route to its own IP address.

   Moreover, before re-advertising S-PMSI A-D routes to V-spokes, the V-
   hub modifies the PMSI Tunnel attribute of these routes as appropriate
   (e.g., by replacing the P-tunnel rooted at the originator of these
   routes with a P-tunnel rooted at the V-hub).

   Whenever the V-hub receives data on the P-tunnel bound to the
   received S-PMSI A-D route, the V-hub follows procedures of [MVPN],



                                                             [Page 14]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   [MVPN-BGP] to determine whether to accept the data. If the data is
   accepted, then the V-hub further forwards it over the P-tunnel bound
   to the S-PMSI A-D route that has been re-advertised by the V-hub.

   If multiple S-PMSIs received by the V-hub have been aggregated into
   the same P-tunnel, then the V-hub, prior to forwarding to the V-
   spokes the data received on this P-tunnel may de-aggregate and then
   re-aggregate (in a different way) this data using the state present
   in its MVPN-TIB that has been created as a result of receiving C-
   multicast routes from the V-spokes. Even if S-PMSIs received by the
   V-hub each has its own P-tunnel, the V-hub, prior to forwarding to
   the V-spokes the data received on these P-tunnels may aggregate these
   S-PMSIs using the state present in its MVPN-TIB that has been created
   as a result of receiving C-multicast routes from the V-spokes.



6.9. Use of Ingress Replication with I-PMSI A-D routes

   The existing procedures for S-PMSI A-D routes are sufficient to
   discard packets coming from a "wrong" PE for any type of P-tunnels,
   including Ingress Replication.

   The following modifications to originating/receiving I-PMSI A-D
   routes enable to discard packets coming from a "wrong" PE when
   Ingress Replication is used for I-PMSI P-tunnels (for other types of
   P-tunnels the procedures specified in [MVPN], [BGP-MVPN] are
   sufficient).

   If Ingress Replication is used with I-PMSI A-D routes, then when a PE
   advertises such routes, the Tunnel Type in the PMSI Tunnel attribute
   is set to Ingress Replication; the Leaf Information Required flag is
   set to 1; the the attribute carries no MPLS labels.

   A PE that receives such I-PMSI A-D route MUST respond with a Leaf A-D
   route.  The PMSI Tunnel attribute of that Leaf A-D route is
   constructed as follows. The Tunnel Type is set to Ingress
   Replication.  The Tunnel Identifier MUST carry a routable address of
   the PE that originates the Leaf A-D route. The PMSI Tunnel attribute
   MUST carry a downstream assigned MPLS label that is used to
   demultiplex the traffic received over a unicast tunnel by the PE.










                                                             [Page 15]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


7. 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 V-hubs.

   To simplify the presentation the following example assumes that each
   V-spoke is associated with just one V-hub. However, as mentioned
   earlier, in practice each V-spoke should be associated with two or
   more V-hubs.

   PE-1 and PE-2 are V-spokes associated with PE-3. PE-4 and PE-5 are V-
   spokes associated with PE-6. PE-7 and PE-8 are V-spokes associated
   with PE-9.


7.1. Unicast routing

   All the PEs (both V-hubs and V-spokes) are provisioned to export
   routes using RT-A (just as it would be with "vanilla" any-to-any
   VPN).

   All the V-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 (but not with RT-A), 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 (but not with RT-A), 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 (but not with RT-A), 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 and RT-A-VH-1 (rather than just RT-
   A-VH-1, as before), which results in importing this route to PE-6 and
   PE-9, as well as to PE-1 and PE-2.

   If PE-7 and PE-8, in addition to importing VPN-IP default route from
   PE-9, also want to import each other VPN-IP routes, then PE-7 and
   PE-8 export their VPN-IP routes with two RTs: RT-A and RT-A-VH-3.



                                                             [Page 16]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


7.2. Multicast routing

   All the PEs designated as V-spokes (PE-1, PE-2, PE-4, PE-5, PE-7, and
   PE-8) are provisioned to export their I-PMSI/S-PMSI/SA A-D routes
   using RT-A (just as it would be with "vanilla" any-to-any MVPN). Thus
   these routes could be imported by all the V-hubs (PE-3, PE-6, and
   PE-9).

   The V-hub on PE-3 is provisioned to export its I-PMSI/S-PMSI/SA A-D
   routes with two RTs: RT-A and RT-A-VH-1. Thus these routes could be
   imported by all the other V-hubs (PE-6 and PE-9), and also by the V-
   spokes, but only by the V-spokes associated with the V-hub on PE-3
   (PE-1 and PE-2). In addition, the V-hub on PE-3 originates the
   Default I-PMSI A-D route with RT-A-VH-1. This route could be imported
   only by the V-spokes associated with the V-hub on PE-3 (PE-1 and
   PE-2).

   The V-hub on PE-6 is provisioned to export its I-PMSI/S-PMSI/SA A-D
   routes with two RTs: RT-A and RT-A-VH-2. Thus these routes could be
   imported by all the other V-hubs (PE-3 and PE-9), and also by the V-
   spokes, but only by the V-spokes associated with the V-hub on PE-6
   (PE-4 and PE-5). In addition, the V-hub on PE-6 originates the
   Default I-PMSI A-D route with RT-A-VH-2. This route could be imported
   only by the V-spokes associated with the V-hub on PE-6 (PE-4 and
   PE-5).

   The V-hub on PE-9 is provisioned to export its I-PMSI/S-PMSI/SA A-D
   routes with two RTs: RT-A and RT-A-VH-3. Thus these routes could be
   imported by all the other V-hubs (PE-3 and PE-6), and also by the V-
   spokes, but only by the V-spokes associated with the V-hub on PE-9
   (PE-7 and PE-8). In addition, the V-hub on PE-9 originates the
   Default I-PMSI A-D route with RT-A-VH-3. This route could be imported
   only by the V-spokes associated with the V-hub on PE-9 (PE-7 and
   PE-8).

   If PE-7 and PE-8, in addition to importing VPN-IP default route from
   PE-9, also want to import each other VPN-IP routes, then PE-7 and
   PE-8 export their I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and
   RT-A-VH-3.

   If the V-hub on PE-9 receives an S-PMSI/SA A-D route originated by
   either some other V-hub (PE-3 or PE-6), or by a V-spoke that is not
   associated with this V-hub (PE-1, or PE-2, or PE-4, or PE-5), the V-
   hub, before re-advertising this route replaces the RT(s) carried in
   this route with just one RT - RT-A-VH-3. Thus, the re-advertised
   route could be imported only by the V-spokes associated with the V-
   hub on PE-9 (PE-7 and PE-8).




                                                             [Page 17]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


8. Further refinements

   In some cases a VPN customer may not want to rely solely on an (IP)
   default route being advertised from a V-spoke to a CE, but may want
   CEs to receive all the VPN routes (e.g., for the purpose of faster
   detection of VPN connectivity failures, and activating some backup
   connectivity).

   In this case one possible approach would be to install in the V-
   spoke's data plane only the default route (following the Virtual Hub
   and Spoke model, as described above), but keep all the VPN-IP routes
   in the V-spoke's control plane (and thus being able to advertise
   these routes from the V-spoke to the CEs).  Granted, this would not
   change control plane resource consumption, but would (significantly)
   reduce resource consumption on the data plane.


9. IANA Considerations

   This document introduces no new IANA Considerations.


10. Security Considerations

   This document introduces no new Security Considerations, above and
   beyond what is already specified in [rfc4364].


11. Acknowledgements

   We would like to acknowledge Han Nguyen (AT&T) for his contributions
   to this document. We would also like to thank Jeffrey (Zhaohui) Zhang
   (Juniper) for his review and comments.


12. Normative References

   [rfc1918] Rekhter, Y., et.al., "Address Allocation for Private
   Internets", RFC 1918, February 1996.

   [rfc3031] Rosen, E., et. al., "MPLS Architecture", RFC3031, January
   2001.

   [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.



                                                             [Page 18]

Internet Draft   draft-rekhter-l3vpn-virtual-hub-02.txtSeptember 6, 2011


   [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

   [MVPN] Eric C. Rosen, Rahul Aggarwal, et. al., "Multicast in MPLS/BGP
   IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10, Work In Progress.

   [BGP-MVPN] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP
   Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", draft-
   ietf-l3vpn-2547bis-mcast-bgp-08.txt, Work In Progress.


13. Non-normative References



14. Authors' Addresses


   Huajin Jeng
   AT&T
   e-mail: hj2387@att.com

   James Uttaro
   AT&T
   e-mail: ju1738@att.com

   Luay Jalil
   Verizon
   e-mail: luay.jalil@verizon.com

   Bruno Decraene
   France Telecom
   e-mail: bruno.decraene@orange-ftgroup.com

   Rahul Aggarwal
   e-mail: raggarwa_1@yahoo.com

   Yakov Rekhter
   Juniper Networks, Inc.
   e-mail: yakov@juniper.net









                                                             [Page 19]