doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc7024.txt b/doc/rfc/rfc7024.txt
new file mode 100644
index 0000000..0e915ef
--- /dev/null
+++ b/doc/rfc/rfc7024.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           H. Jeng
+Request for Comments: 7024                                     J. Uttaro
+Category: Standards Track                                           AT&T
+ISSN: 2070-1721                                                 L. Jalil
+                                                                 Verizon
+                                                             B. Decraene
+                                                                  Orange
+                                                              Y. Rekhter
+                                                        Juniper Networks
+                                                             R. Aggarwal
+                                                                  Arktan
+                                                            October 2013
+
+
+                 Virtual Hub-and-Spoke in BGP/MPLS VPNs
+
+Abstract
+
+   With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any
+   connectivity among sites of a given VPN would require each Provider
+   Edge (PE) router connected to one or more of these sites to hold all
+   the routes of that VPN.  The approach described in this document
+   allows the VPN service provider to reduce the number of PE routers
+   that have to maintain all these routes by requiring only a subset of
+   these routers to maintain all these routes.
+
+   Furthermore, when PE routers use ingress replication to carry the
+   multicast traffic of VPN customers, the approach described in this
+   document may, under certain circumstances, reduce bandwidth
+   inefficiency associated with ingress replication and redistribute the
+   replication load among PE routers.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7024.
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                    [Page 1]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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.
+
+Table of Contents
+
+   1. Overview ........................................................3
+   2. Specification of Requirements ...................................4
+   3. Routing Information Exchange ....................................5
+   4. Forwarding Considerations .......................................7
+   5. Internet Connectivity ...........................................9
+   6. Deployment Considerations ......................................12
+   7. Multicast Considerations .......................................13
+      7.1. Terminology ...............................................14
+      7.2. Eligible Upstream Multicast Hop (UMH) Routes ..............14
+      7.3. Originating VPN-IP Default Route by a V-Hub ...............14
+      7.4. Handling C-Multicast Routes ...............................15
+      7.5. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ........15
+      7.6. Originating I-PMSI/S-PMSI/SA A-D Routes by V-Hub ..........16
+      7.7. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Spoke ..........17
+      7.8. Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Hub ............17
+           7.8.1. Case 1 .............................................17
+           7.8.2. Case 2 .............................................18
+      7.9. Use of Ingress Replication with I-PMSI A-D Routes .........20
+   8. An Example of RT Provisioning ..................................21
+      8.1. Unicast Routing ...........................................21
+      8.2. Multicast Routing .........................................22
+   9. Further Refinements ............................................23
+   10. Security Considerations .......................................23
+   11. Acknowledgements ..............................................23
+   12. References ....................................................24
+      12.1. Normative References .....................................24
+      12.2. Informative References ...................................24
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                    [Page 2]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+1.  Overview
+
+   With BGP/MPLS VPNs [RFC4364], providing any-to-any connectivity among
+   sites of a given VPN is usually accomplished by requiring each
+   Provider Edge (PE) router connected to one or more of these sites to
+   hold all that VPN's routes.  The approach described in this document
+   allows the VPN service provider (SP) to reduce the number of PEs that
+   have to maintain all these routes by requiring only a subset of these
+   routers to maintain all these routes.
+
+   Consider a set of PEs that maintain VPN Routing and Forwarding tables
+   (VRFs) of a given VPN.  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).  The rest of the PEs in the
+   set will be "vanilla" PEs (PEs that implement the procedures
+   described in [RFC4364] but that do not implement the 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 may 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.  On such PEs, the VRF associated
+   with that VPN may import routes from other VRFs of that VPN, even if
+   the VRF has no sites of that VPN connected to it.
+
+   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, VPNs present on that PE.  Likewise, a given PE
+   may act as a V-spoke only for some, but not all, VPNs present on
+   that PE.
+
+   For a given VPN, each V-spoke of that VPN is "associated" with one or
+   more V-hubs of that VPN (one may 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.  For more on how a V-spoke and a
+   V-hub become "associated" with each other, see Section 3.
+
+   Consider a set of V-spokes that are associated with a given V-hub,
+   V-hub-1.  If one of these V-spokes is also associated with some other
+   V-hub, V-hub-2, then other V-spokes in the set need not be associated
+   with the same V-hub, V-hub-2, but may be associated with some other
+   V-hubs (e.g., V-hub-3, V-hub-4, etc.).
+
+
+
+
+
+Jeng, et al.                 Standards Track                    [Page 3]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   This document defines a VPN-IP default route as a VPN-IP route whose
+   VPN-IP prefix contains only a Route Distinguisher (RD) (for the
+   definition of "VPN-IP route", see [RFC4364]).
+
+   A PE that acts as a V-hub of a given VPN maintains all routes of that
+   VPN (such a PE imports routes from all other V-hubs and V-spokes, as
+   well as from "vanilla" PEs of that VPN).  A PE that acts as a V-spoke
+   of a given VPN needs to maintain only the routes of that VPN that are
+   originated by the sites of that VPN connected to that PE, plus one or
+   more VPN-IP default routes originated by the V-hub(s) associated with
+   that V-spoke (such a PE needs to import only VPN-IP default routes
+   from certain V-hubs).  This way, only a subset of PEs that maintain
+   VRFs of a given VPN -- namely, only the PEs acting as V-hubs of that
+   VPN -- has to maintain all 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.
+
+   This document assumes that a given V-hub and its associated
+   V-spoke(s) are in the same Autonomous System (AS).  However, if PEs
+   that maintain a given VPN's VRFs span multiple ASes, this document
+   does not restrict all V-hubs of that VPN to be in the same AS -- the
+   V-hubs may be spread among these ASes.
+
+   One could model the approach defined in this document as a two-level
+   hierarchy, where the top level consists of V-hubs and the bottom
+   level consists of V-spokes.  Generalization of this approach to more
+   than two levels of hierarchy is outside the scope of this document.
+
+   When PEs use ingress replication to carry the multicast traffic of
+   VPN customers, the approach described in this document may, under
+   certain circumstances, reduce bandwidth inefficiency associated with
+   ingress replication and redistribute the replication load among the
+   PEs.  This is because a PE that acts as a V-spoke of a given VPN
+   would need to replicate multicast traffic only to other V-hubs (while
+   other V-hubs would replicate this traffic to the V-spokes associated
+   with these V-hubs), rather than to all PEs of that VPN.  Likewise, a
+   PE that acts as a V-hub of a given VPN would need to replicate
+   multicast traffic to other V-hubs and the V-spokes, but only the
+   V-spokes associated with that V-hub, rather than replicating the
+   traffic to all PEs of that VPN.  Limiting replication could be
+   especially beneficial if the V-spoke PEs have limited replication
+   capabilities and/or have links with limited bandwidth.
+
+2.  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 [RFC2119].
+
+
+
+Jeng, et al.                 Standards Track                    [Page 4]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+3.  Routing Information Exchange
+
+   Routing information exchange among all 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 these sites, irrespective of
+   whether this PE acts as a V-hub or a V-spoke of that VPN and follows
+   the rules specified in [RFC4364].
+
+   A PE that has sites of a given VPN connected to it follows the rules
+   specified in [RFC4364] when exporting (as VPN-IP routes) the routes
+   received from these sites, 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 MUST export a VPN-IP default
+   route for that VPN.  This route MUST be exported to only the V-spokes
+   of that VPN that are associated with that V-hub.
+
+   To enable a given VPN's V-spoke to share its outbound traffic load
+   among the V-hubs associated with that V-spoke, each of the VPN's
+   V-hubs MUST use a distinct RD (per V-hub, per VPN) when originating a
+   VPN-IP default route.  The use of Type 1 RDs may be an attractive
+   option for such RDs.
+
+   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.
+
+   Following the rules specified in [RFC4364], a V-hub of a given VPN
+   imports 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 V-hubs or V-spokes or just "vanilla"
+   PEs for that VPN, and irrespective of whether or not these V-spokes
+   are associated with the V-hub).
+
+   A V-hub of a given VPN MUST NOT import a VPN-IP default route unless
+   the imported route is the Internet VPN-IP default route (for the
+   definition of "Internet VPN-IP default route" and information on how
+   to distinguish between a VPN-IP default route and the Internet VPN-IP
+   default route, see Section 5).
+
+   Within a given VPN, a V-spoke MUST import all VPN-IP default routes
+   that have been originated by the V-hubs associated with that V-spoke.
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                    [Page 5]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   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, but only by the V-spokes that are associated with the same
+   V-hub(s) as the V-spoke itself.
+
+   The above rules are realized by using Route Target (RT) extended
+   communities [RFC4360] and VRF export/import policies based on these
+   RTs.  This document defines the following procedures for implementing
+   the above rules.
+
+   Consider a "vanilla" any-to-any VPN.  This document assumes that all
+   the PEs of that VPN (or to be more precise, all VRFs of that VPN) are
+   provisioned with the same export and import RT -- we will refer to
+   this RT as "RT-VPN" (of course, for a given VPN service provider,
+   each VPN would use its own RT-VPN, distinct from RT-VPNs used by
+   other VPNs).
+
+   To evolve this VPN into V-hubs and V-spokes, all PEs (or to be more
+   precise, all VRFs) that are designated as either V-hubs or V-spokes
+   of that VPN keep the same export RT-VPN.  This RT-VPN is attached to
+   all VPN-IP routes originated by these PEs.  Also, all the V-hubs keep
+   the same import RT-VPN.
+
+   In addition, each of a given VPN's V-hubs is provisioned with its own
+   export RT, called RT-VH.  This RT-VH MUST be different from the
+   export RT (RT-VPN) provisioned on that V-hub.  Furthermore, for a
+   given VPN service provider, no two VPNs can use the same RT-VH.
+
+   A given V-spoke becomes associated with a given V-hub by virtue of
+   provisioning the V-spoke to import only the VPN-IP route(s) that
+   carry RT-VH provisioned on the V-hub (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).
+
+   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.  The use of IP-address-specific RTs may be an attractive
+   option for this scenario.  However, it is also possible for several
+   V-hubs to use the same RT-VH, in which case all of these V-hubs would
+   be associated with the same set of V-spokes.
+
+   When a V-hub originates a (non-Internet) VPN-IP default route, the
+   V-hub MUST attach RT-VH to that route (the case where a V-hub
+   originates the Internet VPN-IP default route is covered in
+   Section 5).  Thus, this route is imported by all V-spokes associated
+   with the V-hub.
+
+
+
+Jeng, et al.                 Standards Track                    [Page 6]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   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.
+
+4.  Forwarding Considerations
+
+   This section describes changes/modifications to the forwarding
+   procedures specified in [RFC4364].
+
+   For a given VPN, the MPLS label that a V-hub of that VPN advertises
+   with a VPN-IP default route MUST be the label that is mapped to a
+   Next Hop Label Forwarding Entry (NHLFE) that identifies the VRF of
+   the V-hub.  As a result, when the V-hub receives a packet that
+   carries such a label, the V-hub pops the label and determines further
+   disposition of the packet based on the lookup in the VRF.
+
+   Note that this document does not require the advertisement of labels
+   mapped to an NHLFE that identifies a VRF for routes other than the
+   VPN-IP default route.
+
+   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 that route has been originated as a result of
+
+   a) the V-hub receiving an IP default route from one of the VPN
+      Customer Edge (CE) routers connected to it, or
+
+   b) the V-hub receiving (and importing) the Internet VPN-IP default
+      route (Section 5) from some other PE, or
+
+   c) the VRF being provisioned with a default route pointing to the
+      routing table that maintains the Internet routes.
+
+   When a multihomed site is connected to a V-hub and a V-spoke, then
+   the V-hub uses the following OPTIONAL procedures to support Internal
+   BGP (IBGP) / External BGP (EBGP) load balancing for the site's
+   inbound traffic that has been originated by some other V-spoke
+   associated with the V-hub.  When the V-hub receives from some other
+   PE a packet that carries an MPLS label that the V-hub advertised in
+   the VPN-IP default route, then the V-hub uses the label to identify
+   the VRF that should be used for further disposition of the packet.
+   If (using the information present in the VRF) the V-hub determines
+   that the packet has to be forwarded using a non-default route present
+   in the VRF, and this route indicates that the packet's destination is
+   reachable either over one of the VRF attachment circuits (for the
+   definition of "VRF attachment circuits", see [RFC4364]) or via some
+
+
+
+Jeng, et al.                 Standards Track                    [Page 7]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   other (V-spoke) PE, the V-hub forwards the packet either over this
+   attachment circuit or via that other PE.  The choice between the two
+   is a local matter to the V-hub.
+
+   To illustrate this, consider the following example:
+
+                  <- RD:0/0           RD:0/0->
+
+                                   <- RD:192.0.2        <-192.0.2/24
+    CE1----PE-S-------------PE-H----------------PE-S1-------------CE2
+                           /
+                           |    |
+                           |    |  192.0.2/24
+                           |    |
+                          CE4   CE3
+
+   A multihomed site (not shown in the above figure) is connected via
+   CE2 and CE3.  Thus, both CE2 and CE3 advertise a route to 192.0.2/24.
+   CE2 advertises this route (route to 192.0.2/24) to PE-S1, which in
+   turn originates a VPN-IP route RD:192.0.2.  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:192.0.2 and from CE3 a
+   plain IP route to 192.0.2.  Thus, the VRF entry on PE-H has two
+   possible next hops for 192.0.2: CE3 and PE-S1 (the latter is a next
+   hop that is not directly connected to PE-H).
+
+   Now consider what happens when CE1 originates a packet destined to
+   192.0.2.1.  When PE-S receives this packet, PE-S (following the
+   VPN-IP default route) forwards the packet to PE-H.  The MPLS label in
+   the packet is the label that PE-H advertised to PE-S in the VPN-IP
+   default route.  Thus, following the rule specified above, PE-H may
+   forward the packet either via CE3 or via PE-S1 (with PE-S1
+   subsequently forwarding the packet to CE2), resulting in IBGP/EBGP
+   load balancing.
+
+   Likewise, if CE4 originates a packet destined to 192.0.2.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 IBGP/EBGP
+   load balancing.
+
+   Note, however, that if there is some other CE, CE5, connected to
+   PE-S1, and CE5 sends a packet to 192.0.2.1, then (due to the IP
+   longest match rule) PE-S1 will always forward this packet to CE2.
+
+
+
+Jeng, et al.                 Standards Track                    [Page 8]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   Thus, for a multihomed site connected to a V-hub and a V-spoke,
+   IBGP/EBGP load balancing will be available for some but not all the
+   traffic destined to that site.  Specifically, IBGP/EBGP load
+   balancing will not be available for the traffic destined to that site
+   if this traffic has been originated within some other site that is
+   connected to the same V-spoke.
+
+   Moreover, if CE3 advertises 192.0.2.0/25 and 192.0.2/24, while CE2
+   advertises 192.0.2.128/25 and 192.0.2/24 (which is yet another form
+   of load balancing for a multihomed site), when CE5 sends a packet to
+   192.0.2.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 the issues raised in
+   the previous two paragraphs.  The first option is to disallow a given
+   VPN to provision PEs that have multihomed sites of that VPN connected
+   to them as V-spokes (such PEs could be provisioned as either V-hubs
+   or plain "vanilla" PEs).  The second option is for the V-spoke, when
+   it receives an IP route from a CE, to not install this route in its
+   forwarding table but just re-advertise this route as a VPN-IP route,
+   together with an MPLS label.  The NHLFE [RFC3031] associated with
+   that label MUST specify the CE that advertises the IP route as the
+   next hop.  As a result, when the PE receives data that carries that
+   label, the PE just forwards the data to the CE without performing an
+   IP lookup on the data.  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.
+
+   An implementation that supports IBGP/EBGP load balancing, as
+   specified above, SHOULD support the second option.  If the
+   implementation does not support the second option, then deploying
+   this implementation to support IBGP/EBGP load balancing, as specified
+   above, would either (a) restrict the set of PEs that could be
+   provisioned as V-spokes (any PE that has a multihomed site connected
+   to it cannot be provisioned as a V-spoke) or (b) result in IBGP/EBGP
+   load balancing not being available for certain scenarios (the
+   scenarios that the second option is intended to cover).
+
+5.  Internet Connectivity
+
+   This document specifies two possible alternatives for providing
+   Internet connectivity for a given VPN.
+
+   The first alternative is when a PE that maintains Internet routes
+   also maintains a VRF of a given VPN.  In this case, the Internet
+   connectivity for that VPN MAY be provided by provisioning a default
+   route in the VPN's VRF on that PE pointing to the routing table on
+
+
+
+Jeng, et al.                 Standards Track                    [Page 9]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   that PE that maintains the Internet routes.  This PE MUST NOT be
+   provisioned as a V-spoke for that VPN (this PE may be provisioned as
+   either a V-hub or a "vanilla" PE).  If this PE is provisioned as a
+   V-hub, then this PE MUST originate a VPN-IP default route.  The route
+   MUST carry both RT-VPN and RT-VH of the V-hub (see Section 3 for the
+   definitions of "RT-VPN" and "RT-VH").  Thus, this route will be
+   imported by all the V-spokes associated with the V-hub, as well as by
+   other V-hubs and "vanilla" PEs.  An implementation MUST support the
+   first alternative.
+
+   The second alternative 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 alternative has two subcases:
+   (a) the PE is provisioned as a V-hub, and (b) the PE is provisioned
+   as a V-spoke.  An implementation MUST support subcase (a).  An
+   implementation MAY support subcase (b).
+
+   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 installs in its VRF an IP
+   default route with the next hop specifying the CE(s) that advertise
+   the IP default route to the PE.  Note that when re-advertising the
+   VPN-IP default route, the route MUST carry both RT-VPN and RT-VH of
+   the V-hub (see Section 3 for the definitions of "RT-VPN" and
+   "RT-VH").  Thus, this route will be imported by all the V-spokes
+   associated with the V-hub, as well as by other V-hubs and
+   "vanilla" PEs.
+
+   If a PE is provisioned as a V-spoke, then receiving a default route
+   from a CE MUST NOT cause the V-spoke to install an IP default route
+   in its VRF.  The V-spoke MUST originate a VPN-IP default route with a
+   (non-null) MPLS label.  The route MUST carry only RT-VPN (as a
+   result, this route is not imported by any of the V-spokes but is
+   imported by V-hubs).  The packet's next hop of the NHLFE [RFC3031]
+   associated with that label MUST specify the CE that advertises the IP
+   default route.  As a result, when the V-spoke receives data that
+   carries that label, it just forwards the data to the CE without
+   performing an IP lookup on the data.  Note that in this case, the VRF
+   on the V-spoke will 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 associated with that V-spoke (and not as a result of
+   receiving the IP default route from the CE).  Note also that if this
+   V-spoke has other sites of that VPN connected to it, then traffic
+   from these sites to the Internet would go to that V-spoke, then to
+   the V-hub selected by the V-spoke, then from that V-hub back to the
+   V-spoke, and then to the CE that advertises an IP default route to
+   the V-spoke.
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 10]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   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 MUST NOT advertise an IP default route back to that CE.
+   Yet, the CE has to specify that PE as the next hop for all the
+   traffic to other sites of that VPN.  A way to accomplish this is to
+   require the V-spoke to implement procedures specified in Section 9.
+
+   In all the scenarios described above in this section, we refer to the
+   originated VPN-IP default route as the "Internet VPN-IP default
+   route".  Specifically, the Internet VPN-IP default route is a VPN-IP
+   default route originated by a PE (this PE could be either a V-hub or
+   a V-spoke) as a result of (a) receiving an IP default route from a CE
+   or (b) the PE maintaining Internet routes and also provisioning in
+   the VRF of its VPN a default route pointing to its (the PE's) routing
+   table that contains Internet routes.
+
+   The difference between the Internet VPN-IP default route and a
+   non-Internet VPN-IP default route originated by a V-hub is in the RTs
+   carried by the route -- for a given VPN and a given V-hub of that
+   VPN, the Internet VPN-IP default route carries both RT-VPN and RT-VH
+   of that V-hub, while the non-Internet VPN-IP default route carries
+   just RT-VH of that V-hub.
+
+   When a V-hub originates the Internet VPN-IP default route, the V-hub
+   MUST withdraw the non-Internet VPN-IP default route that has been
+   originated by the V-hub.  When a V-hub withdraws the Internet VPN-IP
+   default route that has been originated by the V-hub, the V-hub MUST
+   originate a non-Internet VPN-IP default route.  That is, at any given
+   point in time, a given V-hub originates either the Internet VPN-IP
+   default route or a non-Internet VPN-IP default route.
+
+   As a result of the rules specified above, 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.
+
+   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
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 11]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   to the V-hub that does not originate the Internet VPN-IP default
+   route, 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
+   shared between these two V-hubs.
+
+6.  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 or all of its V-spokes could be grouped into
+   geographically based clusters (e.g., V-spokes within a given cluster
+   could be in close geographical proximity to each other) with
+   any-to-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 a VPN for a large
+   retail chain in which data traffic is hub/spoke between each store
+   and centralized datacenters, but there is a need for direct Voice
+   over IP (VoIP) traffic between stores within the same geographical
+   area.
+
+   The use of constrained route distribution for BGP/MPLS IP VPNs
+   ("RT constrains") [RFC4684] may further facilitate/optimize routing
+   exchange in support of V-hubs and V-spokes.
+
+   Introducing a V-spoke PE in a VPN may introduce the following changes
+   for the customer of that VPN:
+
+   +  Traceroute from a CE connected to a V-spoke may report an
+      additional hop: the V-hub PE.
+
+   +  Latency for traffic sent from a CE connected to a V-spoke may
+      increase, depending on the location of the V-hub in the layer 3
+      and layer 1 network topology of the SP.
+
+
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 12]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+7.  Multicast Considerations
+
+   This section describes procedures for supporting Multicast VPN (MVPN)
+   in the presence of Virtual Hub-and-Spoke.  The procedures rely on
+   MVPN specifications as defined in [RFC6513], [RFC6514], and
+   [RFC6625].
+
+   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 Section 9.1.1 of [RFC6513].  The existing
+   procedures for Selective Provider Multicast Service Interface
+   (S-PMSI) auto-discovery (A-D) routes [RFC6513] [RFC6514] [RFC6625]
+   are sufficient to discard packets coming from a "wrong" PE for all
+   types of provider tunnels (P-tunnels) specified in [RFC6514]
+   (including Ingress Replication).  The existing procedures for
+   Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes
+   [RFC6513] [RFC6514] are sufficient to discard packets coming from a
+   "wrong" PE for all types of P-tunnels specified in [RFC6514], except
+   for Ingress Replication.  Section 7.9 of this document specifies
+   changes to the procedures in [RFC6514], to enable the discarding of
+   packets from a "wrong" PE when Ingress Replication is used for I-PMSI
+   P-tunnels.
+
+   The V-hub/V-spoke architecture, as specified in this document,
+   affects certain multicast scenarios.  In particular, it affects
+   multicast scenarios where the source of a multicast flow is at a site
+   attached to a V-hub and a receiver of that flow is at a site attached
+   to a V-spoke that is not associated with that same V-hub.  It also
+   affects multicast scenarios where the source of a multicast flow is
+   at a site attached to a V-spoke, a receiver of that flow is at a site
+   attached to a different V-spoke, and the set intersection between the
+   V-hub(s) associated with the first V-spoke and the V-hub(s)
+   associated with the second V-spoke is empty.  It may also affect
+   multicast scenarios where the source of a multicast flow is at a site
+   connected to a V-spoke, a receiver of that flow is at a site attached
+   to a different V-spoke, and the set intersection between the V-hub(s)
+   associated with the first V-spoke and the V-hub(s) associated with
+   the second V-spoke is non-empty (the multicast scenarios are affected
+   if the I-PMSI/S-PMSI A-D routes originated by the first V-spoke are
+   not imported by the second V-spoke).
+
+   The use of Virtual Hub-and-Spoke in conjunction with seamless MPLS
+   multicast [MPLS-MCAST] is outside the scope of this document.
+
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 13]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+7.1.  Terminology
+
+   We will speak of a P-tunnel being "bound" to a particular
+   I-PMSI/S-PMSI A-D route if the P-tunnel is specified in that route's
+   PMSI Tunnel attribute.
+
+   When Ingress Replication is used, the P-tunnel bound to a particular
+   I-PMSI/S-PMSI A-D route is actually a set of unicast tunnels
+   (procedures differ from [RFC6514] for the case of I-PMSI and are
+   specified in Section 7.9 of this document).  The PE originating the
+   I-PMSI/S-PMSI A-D route uses these unicast tunnels to carry traffic
+   to the PEs that import the route.  The PEs that import the route
+   advertise labels for the unicast tunnels in Leaf A-D routes
+   originated in response to the I-PMSI/S-PMSI A-D route.  When we say
+   that traffic has been received by a PE on a P-tunnel "bound" to a
+   particular I-PMSI/S-PMSI A-D route imported by that PE, we refer to
+   the unicast tunnel for which the label was advertised in a Leaf A-D
+   route by the PE that imported the I-PMSI/S-PMSI route; the PE that
+   originated that route uses this tunnel to send traffic to the PE that
+   imported the I-PMSI/S-PMSI route.
+
+7.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 routes received from other V-spokes.  The routes received
+   from other V-spokes could be either "vanilla" VPN-IP routes (routes
+   using the IPv4 or IPv6 Address Family Identifier (AFI) and Subsequent
+   Address Family Identifier (SAFI) set to 128 "MPLS-labeled VPN
+   address" [IANA-SAFI]) or routes using the IPv4 or IPv6 AFI (as
+   appropriate) but with the SAFI set to SAFI 129 "Multicast for
+   BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA-SAFI].
+
+   The default VPN-IP routes received from the V-hub(s) may be either
+   Internet default VPN-IP routes or non-Internet default VPN-IP routes.
+
+7.3.  Originating VPN-IP Default Route by a V-Hub
+
+   When originating a VPN-IP default route, a V-hub, in addition to
+   following the procedures specified in Section 3, also follows the
+   procedures specified in Sections 6 and 7 of [RFC6514] (see also
+   Section 5.1 of [RFC6513]).  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.
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 14]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+7.4.  Handling C-Multicast Routes
+
+   In the following, the term "C-multicast routes" refers to BGP routes
+   that carry customer multicast routing information [RFC6514].
+
+   Origination of C-multicast routes follows the procedures specified in
+   [RFC6514] (irrespective of whether these routes are originated by a
+   V-hub or a V-spoke).
+
+   When a V-spoke receives a C-multicast route, the V-spoke follows the
+   procedures described in [RFC6514].
+
+   When a V-hub receives a C-multicast route, the V-hub determines
+   whether the customer Rendezvous Point (C-RP) or the customer source
+   (C-S) of the route is reachable via one of its VRF interfaces; if
+   yes, then the V-hub follows the procedures described in [RFC6514].
+
+   Otherwise, the C-RP/C-S of the route is reachable via some other PE
+   (this is the case where the received route was originated by a
+   V-spoke that sees the V-hub as the "upstream PE" for a given source,
+   but the V-hub sees some other PE -- either V-hub or V-spoke -- as the
+   "upstream PE" for that source).  In this case, the V-hub uses the
+   type (Source Tree Join vs Shared Tree Join), the Multicast Source,
+   and Multicast Group from the received C-multicast route to construct
+   a new route of the same type, with the same Multicast Source and
+   Multicast Group.  The hub constructs the rest of the new route
+   following procedures specified in Section 11.1.3 of [RFC6514].  The
+   hub also creates the appropriate (C-*, C-G) or (C-S, C-G) state in
+   its MVPN Tree Information Base (MVPN-TIB).
+
+7.5.  Originating I-PMSI/S-PMSI/SA A-D Routes by V-Spoke
+
+   When a V-spoke originates an I-PMSI, an S-PMSI, or Source Active (SA)
+   A-D route, the V-spoke follows the procedures specified in [RFC6514]
+   (or in the case of a wildcard S-PMSI A-D route, the procedures
+   specified in [RFC6625]), 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.  In the case of an I-PMSI/S-PMSI A-D
+   route, the P-tunnel bound to this route is used to carry to these
+   V-hubs traffic originated by the sites connected to the V-spoke.
+
+   If the V-spoke exports its (unicast) VPN-IP routes not just to the
+   V-hubs but also to some other V-spokes (as described in Section 3),
+   then (as a result of following the procedures specified in [RFC6514]
+   or, in the case of a wildcard S-PMSI A-D route, the procedures
+   specified in [RFC6625]) the I-PMSI/S-PMSI/SA A-D route originated by
+   the V-spoke will be imported not just by the V-hubs but also by the
+   other V-spokes.  This is because in this scenario, the route will
+
+
+
+Jeng, et al.                 Standards Track                   [Page 15]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   carry more than one RT; one of these RTs, RT-VPN, will result in
+   importing the route by the V-hubs, while other RT(s) will result in
+   importing the route by the V-spokes (the other RT(s) are the RT(s)
+   that the V-spoke uses for importing the VPN-IP default route).  In
+   this case, the P-tunnel bound to this I-PMSI/S-PMSI A-D 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.
+
+7.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 specified in [RFC6514] (or in the case of a
+   wildcard S-PMSI A-D route, the procedures specified in [RFC6625]),
+   except that in addition to the RT(s) constructed following these
+   procedures, the route MUST also carry the RT of the VPN-IP default
+   route advertised by the V-hub (RT-VH).  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 are associated with the V-hub (the V-spokes
+   that import the VPN-IP default route originated by the V-hub).  In
+   the case of an I-PMSI/S-PMSI A-D route, 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, if a V-hub originates an I-PMSI A-D route following
+   the procedures specified in [RFC6514], the V-hub MUST originate
+   another I-PMSI A-D route -- we'll refer to this route as an
+   "Associated-V-spoke-only I-PMSI A-D route".  The RT carried by this
+   route MUST be 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 associated with the V-hub (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 the sites connected to either (a) other V-hubs,
+   (b) other V-spokes, including the V-spokes that import the VPN-IP
+   default route from the V-hub, or (c) "vanilla" PEs.
+
+   More details on the use of this P-tunnel are described in
+   Section 7.8.
+
+   As a result, a V-hub originates not one, but two I-PMSI A-D routes --
+   one is a "vanilla" I-PMSI A-D route and another is an
+   Associated-V-spoke-only I-PMSI A-D route.  Each of these routes MUST
+   have a distinct RD.
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 16]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   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 "vanilla" I-PMSI A-D route
+   but MUST NOT forward it on the P-tunnel bound to the
+   Associated-V-spoke-only I-PMSI A-D route.
+
+7.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 specified in [RFC6514] (or in the case of a
+   wildcard S-PMSI A-D route, the procedures specified in [RFC6625]).
+   As a result, a V-spoke that is associated with a given V-hub (the
+   V-spoke that imports the VPN-IP default route originated by that
+   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 "vanilla"
+   I-PMSI A-D route and the Associated-V-spoke-only 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 (as described in Section 3), then
+   the V-spoke will also import I-PMSI/S-PMSI/SA A-D routes originated
+   by these other V-spokes.
+
+7.8.  Receiving I-PMSI/S-PMSI/SA A-D Routes by V-Hub
+
+   The following describes procedures that a V-hub MUST follow when it
+   receives an I-PMSI/S-PMSI/SA A-D route.
+
+7.8.1.  Case 1
+
+   This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D
+   route, and one of the RT(s) carried in the route is the RT that the
+   V-hub uses for advertising its VPN-IP default route (RT-VH).
+
+   In this case, the receiving route was originated either
+
+   +  by a V-spoke associated with the V-hub (the V-spoke that imports
+      the VPN-IP default route originated by the V-hub), or
+
+   +  by some other V-hub that uses the same RT as the receiving 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
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 17]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   importing the received I-PMSI/S-PMSI/SA A-D route by all the V-spokes
+   associated with the V-hub (the V-spokes that import the VPN-IP
+   default route originated by the V-hub).
+
+   In handling such an I-PMSI/S-PMSI/SA A-D route, the V-hub simply
+   follows the procedures specified in [RFC6514] (or in the case of a
+   wildcard S-PMSI A-D route, the procedures specified in [RFC6625]).
+
+   Specifically, the V-hub MUST NOT reoriginate this route as done in
+   Case 2 below.
+
+   The following specifies the rules that the V-hub MUST follow when
+   handling traffic that the V-hub receives on a P-tunnel bound to this
+   I-PMSI/S-PMSI A-D route.  The V-hub may forward this traffic to only
+   the sites connected to that V-hub (forwarding this traffic to these
+   sites follows the procedures specified in [RFC6514] or, in the case
+   of a wildcard S-PMSI A-D route, the procedures specified in
+   [RFC6625]).  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 (V-spokes
+   associated with the V-hub).  Specifically, the V-hub MUST NOT forward
+   the traffic received on the P-tunnel advertised in the received
+   I-PMSI A-D route over the P-tunnel that the V-hub binds to its
+   Associated-V-spoke-only I-PMSI A-D route.
+
+7.8.2.  Case 2
+
+   This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D
+   route, and the route does not carry the RT that the receiving V-hub
+   uses when advertising its VPN-IP default route (RT-VH).
+
+   In this case, the receiving I-PMSI/S-PMSI/SA A-D route was originated
+   by either some other V-hub or 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 associated with the V-hub (V-spokes that
+   import the VPN-IP default route originated by the V-hub).
+
+   In this case, the V-hubs follow the procedures specified in [RFC6514]
+   (or in the case of a wildcard S-PMSI A-D route, the procedures
+   specified in [RFC6625]), 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 the procedures specified in [RFC6513] and [RFC6514] 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
+   Associated-V-spoke-only I-PMSI A-D route originated by the V-hub.
+   Note that in deciding whether to forward the data over the P-tunnel
+
+
+
+Jeng, et al.                 Standards Track                   [Page 18]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   bound to the Associated-V-spoke-only 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 of
+   receiving C-multicast routes from the V-spokes associated with the
+   V-hub.  If (using the information present in the MVPN-TIB) the V-hub
+   determines that none of these V-spokes have receivers for the data,
+   the V-hub SHOULD NOT forward the data over the P-tunnel bound to the
+   Associated-V-spoke-only I-PMSI A-D route originated by the V-hub.
+
+   Whenever a V-hub imports an S-PMSI A-D route (respectively, SA A-D
+   route) in a VRF, the V-hub, in contrast to Case 1 above, MUST
+   originate an S-PMSI A-D route (respectively, SA A-D route) targeted
+   to its V-spokes.  To accomplish this, the V-hub replaces the RT(s)
+   carried in the route with the RT that the V-hub uses when originating
+   its VPN-IP default route (RT-VH), changes the RD of the route to the
+   RD that the V-hub uses when originating its Associated-V-spoke-only
+   I-PMSI A-D route, and sets Next Hop to the IP address that the V-hub
+   places in the Global Administrator field of the VRF Route Import
+   Extended Community of the VPN-IP routes advertised by the V-hub.  For
+   S-PMSI A-D routes, the V-hub also changes the Originating Router's IP
+   address in the MCAST-VPN NLRI (Network Layer Reachability
+   Information) of the route to the same address as the one in the Next
+   Hop.  Moreover, before advertising the new S-PMSI A-D route, the
+   V-hub modifies its PMSI Tunnel attribute as appropriate (e.g., by
+   replacing the P-tunnel rooted at the originator of this route with a
+   P-tunnel rooted at the V-hub).
+
+   Note that a V-hub of a given MVPN may receive and accept multiple
+   (C-*, C-*) wildcard S-PMSI A-D routes [RFC6625], each originated by
+   its own PE.  Yet, even if the V-hub receives and accepts such
+   multiple (C-*, C-*) S-PMSI A-D routes, the V-hub re-advertises just
+   one (C-*, C-*) S-PMSI A-D route, thus aggregating the received (C-*,
+   C-*) S-PMSI A-D routes.  The same applies for (C-*, C-G) S-PMSI A-D
+   routes.
+
+   Whenever a V-hub receives data on the P-tunnel bound to a received
+   S-PMSI A-D route, the V-hub follows the procedures specified in
+   [RFC6513] and [RFC6514] (or in the case of a wildcard S-PMSI A-D
+   route, the procedures specified in [RFC6625]) 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 a V-hub have been aggregated into the
+   same P-tunnel, then the V-hub, prior to forwarding to the V-spokes
+   associated with that V-hub the data received on this P-tunnel, MAY
+   de-aggregate and then reaggregate (in a different way) this data
+   using the state present in its MVPN-TIB that has been created as a
+
+
+
+Jeng, et al.                 Standards Track                   [Page 19]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   result of receiving C-multicast routes from the V-spokes.  Even if
+   S-PMSIs received by the V-hub each have their 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.
+
+7.9.  Use of Ingress Replication with I-PMSI A-D Routes
+
+   The following modifications to the procedures specified in [RFC6514]
+   for originating/receiving I-PMSI A-D routes enable the discarding of
+   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 [RFC6513] and [RFC6514] are sufficient).
+
+   The modifications to the procedures are required to be implemented
+   (by all the PEs of a given MVPN) only under the following conditions:
+
+   +  At least one of those PEs is a V-hub or V-spoke PE for the given
+      MVPN.
+
+   +  The given MVPN is configured to use the optional procedure of
+      using Ingress Replication to instantiate an I-PMSI.
+
+   If Ingress Replication is used with I-PMSI A-D routes, when a PE
+   advertises such routes, the Tunnel Type in the PMSI Tunnel attribute
+   MUST be set to Ingress Replication; the Leaf Information Required
+   flag MUST be set to 1; the attribute MUST carry no MPLS labels.
+
+   A PE that receives such an 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:
+
+   o  The Tunnel Type is set to Ingress Replication.
+
+   o  The Tunnel Identifier MUST carry a routable address of the PE that
+      originates the Leaf A-D route.
+
+   o  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.
+
+   o  The receiving PE MUST assign the label in such a way as to enable
+      the receiving PE to identify (a) the VRF on that PE that should be
+      used to process the traffic received with this label and (b) the
+      PE that sends the traffic with this label.
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 20]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   This document assumes that for a given MVPN, all the PEs that have
+   sites of that MVPN connected to them implement the procedures
+   specified in this section.
+
+8.  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.
+
+8.1.  Unicast Routing
+
+   All the PEs (both V-hubs and V-spokes) are provisioned to export
+   routes using RT-A (just as 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 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 example 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.
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 21]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   If PE-7 and PE-8, in addition to importing a VPN-IP default route
+   from PE-9, also want to import each other's VPN-IP routes, then PE-7
+   and PE-8 export their VPN-IP routes with two RTs: RT-A and RT-A-VH-3.
+
+8.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 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
+   Associated-V-spoke-only 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
+   Associated-V-spoke-only 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
+   Associated-V-spoke-only 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 a VPN-IP default route
+   from PE-9, also want to import each other's 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 imports an S-PMSI A-D route or SA A-D route
+   originated by either some other V-hub (PE-3 or PE-6) or 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 originates an S-PMSI A-D route (respectively, SA A-D
+   route).  The V-hub constructs this route from the imported route
+
+
+
+Jeng, et al.                 Standards Track                   [Page 22]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+   following the procedures specified in Section 7.8.2.  Specifically,
+   the V-hub replaces the RT(s) carried in the imported route with just
+   one RT -- RT-A-VH-3.  Thus, the originated route could be imported
+   only by the V-spokes associated with the V-hub on PE-9 (PE-7
+   and PE-8).
+
+9.  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, an OPTIONAL approach would be to install in the
+   V-spoke's data plane only the VPN-IP default route advertised by the
+   V-hub associated with the V-spoke, even if the V-spoke receives an IP
+   default route from the CE, and to keep all the VPN-IP routes in the
+   V-spoke's control plane (thus being able to advertise these routes as
+   IP routes from the V-spoke to the CEs).  Granted, this would not
+   change control-plane resource consumption but would reduce forwarding
+   state on the data plane.
+
+10.  Security Considerations
+
+   This document introduces no new security considerations above and
+   beyond those already specified in [RFC4364].
+
+11.  Acknowledgements
+
+   We would like to acknowledge Han Nguyen (AT&T) for his contributions
+   to this document.  We would like to thank Eric Rosen (Cisco) for his
+   review and comments.  We would also like to thank Samir Saad (AT&T),
+   Jeffrey (Zhaohui) Zhang (Juniper), and Thomas Morin (Orange) for
+   their review and comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 23]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+12.  References
+
+12.1.  Normative References
+
+   [IANA-SAFI]  IANA Subsequent Address Family Identifiers (SAFI)
+                Parameters,
+                <http://www.iana.org/assignments/safi-namespace/>.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3031]    Rosen, E., Viswanathan, A., and R. Callon,
+                "Multiprotocol Label Switching Architecture", RFC 3031,
+                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.
+
+   [RFC4684]    Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
+                R., Patel, K., and J. Guichard, "Constrained Route
+                Distribution for Border Gateway Protocol/MultiProtocol
+                Label Switching (BGP/MPLS) Internet Protocol (IP)
+                Virtual Private Networks (VPNs)", RFC 4684, November
+                2006.
+
+   [RFC6513]    Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
+                MPLS/BGP IP VPNs", RFC 6513, February 2012.
+
+   [RFC6514]    Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
+                Encodings and Procedures for Multicast in MPLS/BGP IP
+                VPNs", RFC 6514, February 2012.
+
+   [RFC6625]    Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
+                Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
+                RFC 6625, May 2012.
+
+12.2.  Informative References
+
+   [MPLS-MCAST] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I.,
+                Leymann, N., and S. Saad, "Inter-Area P2MP Segmented
+                LSPs", Work in Progress, May 2013.
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 24]
+
+RFC 7024         Virtual Hub-and-Spoke in BGP/MPLS VPNs     October 2013
+
+
+Authors' Addresses
+
+   Huajin Jeng
+   AT&T
+
+   EMail: hj2387@att.com
+
+
+   James Uttaro
+   AT&T
+
+   EMail: ju1738@att.com
+
+
+   Luay Jalil
+   Verizon
+
+   EMail: luay.jalil@verizon.com
+
+
+   Bruno Decraene
+   Orange
+
+   EMail: bruno.decraene@orange.com
+
+
+   Yakov Rekhter
+   Juniper Networks, Inc.
+
+   EMail: yakov@juniper.net
+
+
+   Rahul Aggarwal
+   Arktan
+
+   EMail: raggarwa_1@yahoo.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeng, et al.                 Standards Track                   [Page 25]
+