diff options
Diffstat (limited to 'doc/rfc/rfc7024.txt')
| -rw-r--r-- | doc/rfc/rfc7024.txt | 1403 |
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] + |