idnits 2.17.1 draft-ietf-l3vpn-virtual-hub-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 220: '...b of a given VPN MUST export a VPN-IP ...' RFC 2119 keyword, line 221: '... VPN. This route MUST be exported to o...' RFC 2119 keyword, line 226: '...IP default route MUST use a distinct R...' RFC 2119 keyword, line 242: '...b of a given VPN MUST NOT import a VPN...' RFC 2119 keyword, line 248: '...n VPN, a V-spoke MUST import all VPN-I...' (56 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Huajin Jeng 3 Internet Draft AT&T 4 Intended status: Standards Track 5 Expires: January 2014 James Uttaro 6 AT&T 8 Luay Jalil 9 Verizon 11 Bruno Decraene 12 France Telecom 14 Yakov Rekhter 15 Juniper Networks 17 Rahul Aggarwal 18 Arktan 20 July 1 2013 22 Virtual Hub-and-Spoke in BGP/MPLS VPNs 24 draft-ietf-l3vpn-virtual-hub-08.txt 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Abstract 63 With BGP/MPLS VPNs, providing any-to-any connectivity among sites of 64 a given Virtual Private Network would require each Provider Edge 65 router that has one or more of these sites connected to it to hold 66 all the routes of that Virtual Private Network. The approach 67 described in this document allows the VPN service provider to reduce 68 the number of Provider Edge routers that have to maintain all these 69 routes by requiring only a subset of these routers to maintain all 70 these routes. 72 Furthermore, when Provider Edge routers use ingress replication to 73 carry multicast traffic of VPN customers, the approach described in 74 this document may under certain circumstances allow to reduce 75 bandwidth inefficiency associated with ingress replication, and to 76 redistribute the replication load among Provider Edge routers. 78 Table of Contents 80 1 Specification of requirements ......................... 4 81 2 Overview .............................................. 4 82 3 Routing Information Exchange .......................... 6 83 4 Forwarding Considerations ............................. 8 84 5 Internet Connectivity ................................. 10 85 6 Deployment Considerations ............................. 13 86 7 Multicast Considerations .............................. 14 87 7.1 Terminology ........................................... 15 88 7.2 Eligible Upstream Multicast Hop (UMH) routes .......... 15 89 7.3 Originating VPN-IP default route by a V-hub ........... 15 90 7.4 Handling C-multicast routes ........................... 16 91 7.5 Originating I-PMSI/S-PMSI/SA A-D routes by V-spoke .... 16 92 7.6 Originating I-PMSI/S-PMSI/SA A-D routes by V-hub ...... 17 93 7.7 Receiving I-PMSI/S-PMSI/SA A-D routes by V-spoke ...... 18 94 7.8 Receiving I-PMSI/S-PMSI/SA A-D routes by V-hub ........ 18 95 7.8.1 Case 1 ................................................ 18 96 7.8.2 Case 2 ................................................ 19 97 7.9 Use of Ingress Replication with I-PMSI A-D routes ..... 21 98 8 An example of RT provisioning ......................... 22 99 8.1 Unicast routing ....................................... 22 100 8.2 Multicast routing ..................................... 23 101 9 Further Refinements ................................... 24 102 10 IANA Considerations ................................... 24 103 11 Security Considerations ............................... 24 104 12 Acknowledgements ...................................... 24 105 13 Normative References .................................. 25 106 14 Informative References ................................ 25 107 15 Authors' Addresses .................................... 26 108 1. Specification of requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [rfc2119]. 114 2. Overview 116 With BGP/MPLS VPNs [rfc4364], providing any-to-any connectivity among 117 sites of a given Virtual Private Network (VPN) is usually 118 accomplished by requiring each Provider Edge router (PE) that has one 119 or more of these sites connected to it to hold all the routes of that 120 VPN. The approach described in this document allows the VPN service 121 provider to reduce the number of PEs that have to maintain all these 122 routes by requiring only a subset of such PEs to maintain all these 123 routes. 125 Consider a set of PEs that maintain VRFs of a given VPN. In the 126 context of this VPN we designate a subset of these PEs as "Virtual 127 Spoke" PEs (or just Virtual Spokes), while some other (non- 128 overlapping) subset of these PEs will be "Virtual Hub" PEs (or just 129 Virtual Hubs), with the rest of the PEs in the set will be "vanilla" 130 PEs (PEs that implement the [rfc4364] procedures, but do not 131 implement procedures specified in this document). 133 For the sake of brevity we will use the term "V-hub" to denote a 134 Virtual Hub, and "V-spoke" to denote a Virtual Spoke. 136 For a given VPN, its set of V-hubs may include not only the PEs that 137 have sites of that VPN connected to them, but also PEs that have no 138 sites of that VPN connected to them. On such PEs the VRF associated 139 with that VPN may import routes from other VRFs of that VPN, even if 140 the VRF has no sites of that VPN connected to it. 142 Note that while in the context of one VPN a given PE may act as a V- 143 hub, in the context of another VPN the same PE may act as a V-spoke, 144 and vice versa. Thus a given PE may act as a V-hub only for some, but 145 not all the VPNs present on that PE. Likewise, a given PE may act as 146 a V-spoke only for some, but not all the VPNs present on that PE. 148 For a given VPN each V-spoke of that VPN is "associated" with one or 149 more V-hubs of that VPN (one may use two V-hubs for redundancy to 150 avoid a single point of failure). Note that a given V-hub may have no 151 V-spokes associated with it. For more on how a V-spoke and a V-hub 152 become "associated" with each other see section "Routing Information 153 Exchange". 155 Consider a set of V-spokes that are associated with a given V-hub, V- 156 hub-1. If one of these V-spokes is also associated with some other V- 157 hub, V-hub-2, then other V-spokes in the set need not be associated 158 with the same V-hub, V-hub-2, but may be associated with some other 159 V-hubs (e.g., V-hub-3, V-hub-4, etc...) 161 This document defines a VPN-IP default route as a VPN-IP route whose 162 VPN-IP prefix contains just an RD (for the definition of VPN-IP route 163 see [rfc4364]). 165 A PE that acts as a V-hub of a given VPN maintains all the routes of 166 that VPN (such a PE imports routes from all other V-hubs and V- 167 spokes, as well as from "vanilla" PEs of that VPN). A PE that acts as 168 a V-spoke of a given VPN needs to maintain only the routes of that 169 VPN that are originated by the sites of that VPN connected to that 170 PE, plus one or more VPN-IP default route originated by the V-hub(s) 171 associated with that V-spoke (such a PE need to import only VPN-IP 172 default route from certain V-hubs). This way, only a subset of PEs 173 that maintain VRFs of a given VPN, namely only the PEs acting as V- 174 hubs of that VPN, have to maintain all the routes of that VPN. PEs 175 acting as V-spokes of that VPN need to maintain only a (small) subset 176 of the routes of that VPN. 178 This document assumes that a given V-hub and its associated V- 179 spoke(s) are in the same Autonomous System. However, if PEs that 180 maintain VRFs of a given VPN span multiple Autonomous Systems, this 181 document does not restrict all the V-hubs of that VPN to be in the 182 same Autonomous System - the V-hubs may be spread among these 183 Autonomous Systems. 185 One could model the approach defined in this document as a two-level 186 hierarchy, where the top level consists of V-hubs and the bottom 187 level consists of V-spokes. Generalization of this approach to more 188 than two levels of hierarchy is outside the scope of this document. 190 When PEs use ingress replication to carry multicast traffic of VPN 191 customers, the approach described in this document may under certain 192 circumstances allow to reduce bandwidth inefficiency associated with 193 ingress replication, and to redistribute the replication load among 194 the PEs. This is because a PE that acts as a V-spoke of a given VPN 195 would need to replicate multicast traffic only to other V-hubs (while 196 other V-hubs would replicate this traffic to the V-spokes associated 197 with these V-hubs), rather than to all the PEs of that VPN. Likewise, 198 a PE that acts as a V-hub of a given VPN would need to replicate 199 multicast traffic to other V-hubs, and the V-spokes, but only to the 200 V-spokes associated with that V-hub, rather than replicating the 201 traffic to all the PEs of that VPN. Limiting replication could be 202 especially beneficial if the V-spoke PEs have limited replication 203 capabilities and/or have links with limited bandwidth. 205 3. Routing Information Exchange 207 Routing information exchange among all the PEs of a given VPN is 208 subject to the following rules. 210 A PE that has sites of a given VPN connected to it has to retain 211 routing information received from these sites. This is irrespective 212 of whether this PE acts as a V-hub or a V-spoke of that VPN, and 213 follows the rules specified in [rfc4364]. 215 A PE that has sites of a given VPN connected to it follows the rules 216 specified in [rfc4364] when exporting (as VPN-IP routes) the routes 217 received from these sites. This is irrespective of whether this PE 218 acts as a V-hub or a V-spoke of that VPN. 220 In addition, a V-hub of a given VPN MUST export a VPN-IP default 221 route for that VPN. This route MUST be exported to only the V-spokes 222 of that VPN that are associated with that V-hub. 224 To enable a V-spoke of a given VPN to share its outbound traffic load 225 among the V-hubs associated with that V-spoke, each V-hub of that 226 VPN, when originating a VPN-IP default route MUST use a distinct RD 227 (per V-hub, per VPN). Use of Type 1 RDs may be an attractive option 228 for such RDs. 230 If a V-spoke imports several VPN-IP default routes, each originated 231 by its own V-hub, and these routes have the same preference, then 232 traffic from the V-spoke to other sites of that VPN would be load 233 shared among the V-hubs. 235 Following the rules specified in [rfc4364], a V-hub of a given VPN 236 imports all the non-default VPN-IP routes originated by all other PEs 237 that have sites of that VPN connected to them (irrespective of 238 whether these other PEs act as V-hubs or V-spokes or just "vanilla" 239 PEs for that VPN, and irrespective of whether these V-spokes are 240 associated with the V-hub or not). 242 A V-hub of a given VPN MUST NOT import a VPN-IP default route unless 243 this is the Internet VPN-IP default route (for the definition of the 244 "Internet VPN-IP default route", and how to distinguish between a 245 VPN-IP default route and the Internet VPN-IP default route see 246 section "Internet Connectivity"). 248 Within a given VPN, a V-spoke MUST import all VPN-IP default routes 249 that have been originated by the V-hubs associated with that V-spoke. 251 In addition, a V-spoke of a given VPN MAY import VPN-IP routes for 252 that VPN that have been originated by some other V-spokes of that 253 VPN, but only by the V-spokes that are associated with the same V- 254 hub(s) as the V-spoke itself. 256 The above rules are realized using Route Target (RT) extended 257 communities [rfc4360] and VRF export/import policies based on these 258 RTs. This document defines the following procedures for realizing the 259 above rules. 261 Consider a "vanilla" any-to-any VPN. This document assumes that all 262 the PEs of that VPN (or to be more precise, all the VRFs of that VPN) 263 are provisioned with the same export and import RT - we will refer to 264 this RT as RT-VPN (of course, for a given VPN service provider each 265 VPN would use its own RT-VPN, distinct from RT-VPNs used by other 266 VPNs). 268 To evolve this VPN into V-hubs and V-spokes all the PEs (or to be 269 more precise all the VRFs) that are designated as either V-hubs or V- 270 spokes of that VPN keep the same export RT-VPN. This RT-VPN is 271 attached to all the VPN-IP routes originated by these PEs. Also, all 272 the V-hubs keep the same import RT-VPN. 274 In addition, each V-hub of a given VPN is provisioned with its own 275 export RT, called RT-VH. This RT-VH MUST be different from the export 276 RT (RT-VPN) provisioned on that V-hub. Furthermore, for a given VPN 277 service provider no two VPNs can use the same RT-VH. 279 A given V-spoke becomes associated with a given V-hub by virtue of 280 provisioning the V-spoke to import only the VPN-IP route(s) that 281 carry RT-VH provisioned on the V-hub (thus associating a new V-spoke 282 with a given V-hub requires provisioning only on that V-spoke - no 283 provisioning changes are required on the V-hub). 285 To avoid the situation where within a given VPN all the V-spokes 286 would be associated with every V-hub (in other words, to partition V- 287 spokes among V-hubs), different V-hubs within that VPN MAY use 288 different RT-VHs. At one extreme every V-hub may use a distinct RT- 289 VH. Use of IP-address specific RTs may be an attractive option for 290 this scenario. However, it is also possible for several V-hubs to use 291 the same RT-VH, in which case all these V-hubs would be associated 292 with the same set of V-spokes. 294 When a V-hub originates a (non-Internet) VPN-IP default route, the V- 295 hub MUST attach RT-VH to that route (the case where a V-hub 296 originates the Internet VPN-IP default route is covered in section 297 "Internet Connectivity"). Thus this route is imported by all the V- 298 spokes associated with the V-hub. 300 A V-spoke MAY be provisioned to export VPN-IP routes not just to the 301 V-hubs, but also to the V-spokes that import the same VPN-IP default 302 route(s) as the V-spoke itself. The V-spoke accomplishes this by 303 adding its import RT-VH(s) to the VPN-IP routes exported by the V- 304 spoke. 306 4. Forwarding Considerations 308 This section describes changes/modifications to the forwarding 309 procedures specified in [rfc4364]. 311 For a given VPN, the MPLS label that a V-hub of that VPN advertises 312 with a VPN-IP default route MUST be the label that is mapped to an 313 NHLFE that identifies the VRF of the V-hub. As a result, when the V- 314 hub receives a packet that carries such label, the V-hub pops the 315 label and determines further disposition of the packet based on the 316 lookup in the VRF. 318 Note that this document does not require to advertise labels mapped 319 to an NHLFE that identifies a VRF for routes other than the VPN-IP 320 default route. 322 When a V-hub of a given VPN originates a VPN-IP default route for 323 that VPN, the V-hub MUST NOT install in its VRF of that VPN a default 324 route, unless this route has been originated either (a) as a result 325 of the V-hub receiving an IP default route from one of the CEs of 326 that VPN connected to it, or (b) as a result of the V-hub receiving 327 (and importing) the Internet VPN-IP default route from some other PE 328 (for the definition of the "Internet VPN-IP default route" see 329 section "Internet Connectivity"), or (c) the VRF being provisioned 330 with a default route pointing to the routing table that maintains the 331 Internet routes. 333 When a multi-homed site is connected to a V-hub and a V-spoke, then 334 the V-hub uses the following OPTIONAL procedures to support IBGP/EBGP 335 load balancing for the site's inbound traffic that has been 336 originated by some other V-spoke associated with the V-hub. When the 337 V-hub receives from some other PE a packet that carries an MPLS label 338 that the V-hub advertised in the VPN-IP default route, then the V-hub 339 uses the label to identify the VRF that should be used for further 340 disposition of the packet. If (using the information present in the 341 VRF) the V-hub determines that the packet has to be forwarded using a 342 non-default route present in the VRF, and this route indicates that 343 the packet's destination is reachable either over one of the VRF 344 attachment circuit (for the definition of "VRF attachment circuits" 345 see [rfc4364]) or via some other (V-spoke) PE, the V-hub forwards the 346 packet either over this attachment circuit, or via that other PE. The 347 choice between the two is a local matter to the V-hub. 349 To illustrate this consider the following example: 351 <- RD:0/0 RD:0/0-> 353 <- RD:192.0.2 <-192.0.2/24 354 CE1----PE-S-------------PE-H----------------PE-S1-------------CE2 355 / 356 | | 357 | | 192.0.2/24 358 | | 359 CE4 CE3 361 A multi-homed site (not shown in the above figure) is connect via CE2 362 and CE3. Thus both CE2 and and CE3 advertise a route to 192.0.2/24. 363 CE2 advertises this route (route to 192.0.2/24) to PE-S1, which in 364 turn originates a VPN-IP route RD:192.0.2. CE3 advertises this route 365 to PE-H. 367 PE-H is a V-hub, while PE-S and PE-S1 are V-spokes associated with 368 that V-hub. Thus PE-H originates a VPN-IP default route (RD:0/0), and 369 both PE-S and PE-S1 import that route. 371 PE-H receives from PE-S1 a VPN-IP route to RD:192.0.2 and from CE3 a 372 plain IP route to 192.0.2. Thus the VRF entry on PE-H has two 373 possible next hops for 192.0.2: CE3 and PE-S1 (the latter is a next 374 hop that is not directly connected to PE-H). 376 Now consider what happens when CE1 originates a packet destined to 377 192.0.2.1. When PE-S receives this packet, PE-S (following the VPN-IP 378 default route) forwards the packet to PE-H. The MPLS label in the 379 packet is the label that PE-H advertised to PE-S in the VPN-IP 380 default route. Thus, following the rule specified above, PE-H may 381 forward the packet either via CE3 or via PE-S1 (with PE-S1 382 subsequently forwarding the packet to CE2), resulting in IBGP/EBGP 383 load balancing. 385 Likewise, if CE4 originates a packet destined to 192.0.2.1, PE-H may 386 forward the packet either via CE3 or via PE-S1 (with PE-S1 387 subsequently forwarding the traffic to CE2), resulting in IBGP/EBGP 388 load balancing. 390 Note however, that if there is some other CE, CE5, connected to PE- 391 S1, and that CE5 sends a packet to 192.0.2.1, then (due to the IP 392 longest match rule) PE-S1 will always forward this packet to CE2. 393 Thus for a mult-homed site connected to a V-hub and a V-spoke 394 IBGP/EBGP load balancing will be available for some, but not all the 395 traffic destined to that site. Specifically, IBGP/EBGP load balancing 396 will not be available for the traffic destined to that site if this 397 traffic has been originated within some other site that is connected 398 to the same V-spoke. 400 Moreover, if CE3 advertises 192.0.2.0/25 and 192.0.2/24, while CE2 401 advertises 192.0.2.128/25 and 192.0.2/24 (which is yet another form 402 of load balancing for a multi-homed site), then when CE5 sends a 403 packet to 192.0.2.1, then (due to the IP longest match rule) PE-S1 404 will always forward this packet to CE2, even though the VPN customer 405 would expect this traffic to flow via CE3. 407 This document proposes two options to address the issues raised in 408 the previous two paragraphs. The first option is to disallow for a 409 given VPN to provision PEs that have multi-homed sites of that VPN 410 connected to them as V-spokes (such PEs could be provisioned as 411 either V-hubs, or as plain "vanilla" PEs). The second option is for 412 the V-spoke, when it receives an IP route from a CE, not to install 413 this route in its forwarding table, but just re-advertise this route 414 as a VPN-IP route, together with an MPLS label. The Next Hop Label 415 Forwarding Entry (NHLFE) [rfc3031] associated with that label MUST 416 specify the CE that advertises the IP route as the next hop. As a 417 result, when the PE receives data that carries that label, the PE 418 performs no IP lookup on the data, and just forwards the data to the 419 CE. Note that doing this would result in forcing the traffic between 420 a pair of sites connected to the same V-spoke to go through the V-hub 421 of that V-spoke. 423 An implementation that supports IBGP/EBGP load balancing, as 424 specified above, SHOULD support the second option. If the 425 implementation does not support the second option, then deploying 426 this implementation to support IBGP/EBGP load balancing, as specified 427 above, would either (a) restrict the set of PEs that could be 428 provisioned as V-spokes (any PE that has a multi-homed site connected 429 to it can not be provisioned as a V-spoke), or (b) IBGP/EBGP load 430 balancing may not be available for certain scenarios (the scenarios 431 that the second option is intended to cover). 433 5. Internet Connectivity 435 This document specifies two possible alternatives of providing 436 Internet connectivity for a given VPN. 438 The first alternative is when a PE that maintains Internet routes 439 also maintains a VRF of a given VPN. In this case the Internet 440 connectivity for that VPN MAY be provided by provisioning in the 441 VPN's VRF on that PE a default route pointing to the routing table on 442 that PE that maintains the Internet routes. This PE MUST NOT be 443 provisioned as a V-spoke for that VPN (this PE may be provisioned as 444 either a V-hub, or as a "vanilla" PE). If this PE is provisioned as a 445 V-hub, then this PE MUST originate a VPN-IP default route. The route 446 MUST carry both RT-VPN and RT-VH of the V-hub (see section "Routing 447 Information Exchange" for the definition of "RT-VPN" and "RT-VH"). 448 Thus this route will be imported by all the V-spokes associated with 449 the V-hub, as well as by other V-hubs and "vanilla" PEs. An 450 implementation MUST support the first alternative. 452 The second alternative is when a site of a given VPN has connection 453 to the Internet, and a CE of that site advertises an IP default route 454 to the PE connected to that CE. This alternative has two sub-cases: 455 (a) PE is provisioned as a V-hub, and (b) PE is provisioned as a V- 456 spoke. An implementation MUST support the sub-case (a). An 457 implementation MAY support the sub-case (b). 459 If a PE is provisioned as a V-hub, then the PE re-advertises this IP 460 default route as a VPN-IP default route, and install in its VRF an IP 461 default route with the next hop specifying the CE(s) that advertise 462 the IP default route to the PE. Note, that when re-advertising the 463 VPN-IP default route, the route MUST carry both RT-VPN and RT-VH of 464 the V-hub (see section "Routing Information Exchange" for the 465 definition of "RT-VPN" and "RT-VH"). Thus this route will be imported 466 by all the V-spokes associated with the V-hub, as well as by other V- 467 hubs and "vanilla" PEs. 469 If a PE is provisioned as a V-spoke, then receiving a default route 470 from a CE MUST NOT cause the V-spoke to install an IP default route 471 in its VRF. The V-spoke MUST originate a VPN-IP default route with a 472 (non-null) MPLS label. The route MUST carry only RT-VPN (as a result, 473 this route is not imported by any of the V-spokes, but is imported by 474 V-hubs). The packet's next hop of the Next Hop Label Forwarding Entry 475 (NHLFE) [rfc3031] associated with that label MUST specify the CE that 476 advertises the IP default route. As a result, when the V-spoke 477 receives data that carries that label, the V-spoke performs no IP 478 lookup on the data, and just forwards the data to the CE. Note that 479 in this case the VRF on the V-spoke is going to have an IP default 480 route, but this route would be created as a result of receiving a 481 VPN-IP default route from one of the V-hubs associated with that V- 482 spoke (and not as a result of receiving the IP default route from the 483 CE). Note also that if this V-spoke has other sites of that VPN 484 connected to it, then traffic from these sites to the Internet would 485 go to that V-spoke, then to the V-hub selected by the V-spoke, then 486 from that V-hub back to the V-spoke, and then to the CE that 487 advertises IP default route to the V-spoke. 489 If a PE is provisioned as a V-spoke of a given VPN, and if a CE of 490 that VPN advertises an IP default route to the PE (as the CE belongs 491 to the site that provides the Internet connectivity for the VPN), 492 then the PE MUST NOT advertise an IP default route back to that CE. 493 Yet, the CE has to specify that PE as the next hop for all the 494 traffic to other sites of that VPN. A way to accomplish this is to 495 require the V-spoke to implement procedures of section "Further 496 Refinements". 498 In all of the above scenarios described in this section we refer to 499 the originated VPN-IP default route as the "Internet VPN-IP default 500 route". Specifically, the Internet VPN-IP default route is a VPN-IP 501 default route originated by a PE (this PE could be either a V-hub or 502 a V-spoke) as a result of either (a) receiving an IP default route 503 from a CE, or (b) of PE maintaining Internet routes, and by 504 provisioning in the VPN's VRF on that PE a default route pointing to 505 the routing table on that PE that maintains the Internet routes. 507 The difference between the Internet VPN-IP default route and a non- 508 Internet VPN-IP default route originated by a V-hub is in the RTs 509 carried by the route - for a given VPN and a given V-hub of that VPN 510 the Internet VPN-IP default route carries both RT-VPN and RT-VH of 511 that V-hub, the non-Internet VPN-IP default route carries just RT-VH 512 of that V-hub. 514 When a V-hub originates the Internet VPN-IP default route, the V-hub 515 MUST withdraw the non-Internet VPN-IP default route that has been 516 originated by the V-hub. When a V-hub withdraws the Internet VPN-IP 517 default route that has been originated by the V-hub, the V-hub MUST 518 originate a non-Internet VPN-IP default route. That is, at any given 519 point in time a given V-hub originates either the Internet VPN-IP 520 default route, or a non-Internet VPN-IP default route. 522 As a result of the rules specified above, if a V-hub originates the 523 Internet VPN-IP default route, then all the V-spokes associated with 524 that V-hub MUST import that route. In addition (and in contrast with 525 a non-Internet VPN-IP default route), other V-hubs MAY import that 526 route. A V-hub MAY also import the Internet VPN-IP default routes 527 originated by V-spoke(s). A V-spoke MUST NOT import the Internet VPN- 528 IP default route originated by any other V-spoke. Such a route MAY be 529 imported only by V-hubs. 531 If the Internet VPN-IP default route originated by a V-hub has the 532 same preference as the (non Internet) VPN-IP default route originated 533 by some other V-hub, then a V-spoke that imports VPN-IP default 534 routes originated by both of these V-hubs would load share the 535 outgoing Internet traffic between these two V-hubs (and thus some of 536 the outgoing Internet traffic from that V-spoke will first be routed 537 to the V-hub that does not originate the Internet VPN-IP default 538 route, and then from that V-hub to the V-hub that does originate the 539 Internet VPN-IP default route). 541 If taking an extra-hub hop for the Internet traffic is viewed as 542 undesirable, then it is RECOMMENDED that the Internet VPN-IP default 543 route be of higher preference than a (non-Internet) VPN-IP default 544 route originated by some other V-hub. However, in this case the 545 traffic from the V-spokes to other sites of that VPN will not be load 546 shared between these two V-hubs. 548 6. Deployment Considerations 550 For a given VPN a V-hub and a set of V-spokes associated with that V- 551 hub should be chosen in a way that minimizes the additional network 552 distance/latency penalty, given that VPN geographic footprint. 554 For a given VPN some/all of its V-spokes could be grouped into 555 geographically-based clusters (V-spokes within a given cluster be in 556 close geographical proximity to each other) with any-any connectivity 557 within each cluster. Note that the V-spokes within a given cluster 558 need not be associated with the same V-hub(s). Likewise, not all V- 559 spokes associated with a given V-hub need to be in the same cluster. 560 A use case for this would be VPN for large retail chain in which data 561 traffic is hub/spoke between each store and centralized data-centers 562 but there is need for direct VoIP traffic between stores within same 563 geographical area. 565 Use of RT Constrains [rfc4684] may further facilitate/optimize 566 routing exchange in support of V-hubs and V-spokes. 568 Introducing V-spoke PE in a VPN may introduce the following change 569 for the customer of that VPN: 571 + traceroute from a CE connected to a V-spoke may report an 572 additional hop: the V-hub PE. 574 + latency for traffic sent from a CE connected to a V-spoke may 575 increase, depending on the location of the V-hub in the layer 3 576 and layer 1 network topology of the SP. 578 7. Multicast Considerations 580 This section describes procedures for supporting Multicast VPN (MVPN) 581 in the presence of Virtual Hub-and-Spoke. The procedures rely on MVPN 582 specifications as defined in [rfc6513], [rfc6514], [rfc6625]. 584 The procedures assume that for the purpose of ensuring non- 585 duplication both V-hubs and V-spokes can discard packets from a 586 "wrong" PE, as specified in section 9.1.1 of [rfc6513]. The existing 587 procedures for Selective Provider Multicast Service Interface (S- 588 PMSI) auto-discovery (A-D) routes ([rfc6513], [rfc6514], [rfc6625]) 589 are sufficient to discard packets coming from a "wrong" PE for all 590 types of provider tunnels (P-tunnels) specified in [rfc6514] 591 (including Ingress Replication). The existing procedures for 592 Inclusive Provider Multicast Service Interface (I-PMSI) A-D routes 593 ([rfc6513], [rfc6514]) are sufficient to discard packets coming from 594 a "wrong" PE for all types of P-tunnels specified in [rfc6514], 595 except for Ingress Replication. When Ingress Replication is used for 596 I-PMSI P-tunnels, section "Use of Ingress Replication with I-PMSI A-D 597 route" of the this document specifies changes to the procedures in 598 [rfc6514] to enable discard packets from a "wrong" PE. 600 The V-hub/V-spoke architecture, as specified in this document, 601 affects certain multicast scenarios. In particular, it affects 602 multicast scenarios where the source of a multicast flow is at a site 603 attached to a V-hub, and a receiver of that flow is at a site 604 attached to a V-spoke that is not associated with that same V-hub. 605 It also affects multicast scenarios where the source of a multicast 606 flow is at a site attached to a V-spoke, a receiver of that flow is 607 at a site attached to a different V-spoke, and the set intersection 608 between the V-hub(s) associated with the first V-spoke and the V- 609 hub(s) associated with the second V-spoke is empty. It may also 610 affect multicast scenarios where the source of a multicast flow is at 611 a site connected to a V-spoke, a receiver of that flow is at a site 612 attached to a different V-spoke, and the set intersection between the 613 V-hub(s) associated with the first V-spoke and the V-hub(s) 614 associated with the second V-spoke is non-empty (the multicast 615 scenarios are affected if the I-PMSI/S-PMSI A-D routes originated by 616 the first V-spoke are not imported by the second V-spoke). 618 Use of Virtual Hub-and-Spoke in conjunction with seamless MPLS 619 multicast [seamless-MPLS-multicast] is outside the scope of this 620 document. 622 7.1. Terminology 624 We will speak of a P-tunnel being "bound" to a particular I-PMSI/S- 625 PMSI A-D route if the P-tunnel is specified in that route's PMSI 626 Tunnel Attribute. 628 When Ingress Replication is used, the P-tunnel bound to a particular 629 I-PMSI/S-PMSI A-D route is actually a set of unicast tunnels 630 (procedures differ from [rfc6514] for the case of I-PMSI, and are 631 specified in section 7.9 of this document). The PE originating the I- 632 PMSI/S-PMSI A-D route uses these unicast tunnels to carry traffic to 633 the PEs that import the route. The PEs that import the route 634 advertise labels for the unicast tunnels in Leaf A-D routes 635 originated in response to the I-PMSI/S-PMSI A-D route. When we say 636 that traffic has been received by a PE on a P-tunnel "bound" to 637 particular I-PMSI/S-PMSI A-D route imported by that PE, we refer to 638 the unicast tunnel for which the label was advertised in a Leaf A-D 639 route by the PE that imported the I-PMSI/S-PMSI route; the PE that 640 originated that route uses this tunnel to send traffic to the PE that 641 imported the I-PMSI/S-PMSI route. 643 7.2. Eligible Upstream Multicast Hop (UMH) routes 645 On a V-spoke the set of Eligible UMH routes consists of all the 646 unicast VPN-IP routes received by the V-spoke, including the default 647 VPN-IP routes received from its V-hub(s). Note that such routes MAY 648 include routes received from other V-spokes. The routes received from 649 other V-spokes could be either "vanilla" VPN-IP routes (routes using 650 the IPv4 or IPv6 AFI, and SAFI set to 128 "MPLS-labeled VPN address" 651 [IANA-SAFI]), or routes using the IPv4 or IPv6 AFI (as appropriate), 652 but with the SAFI set to SAFI 129 "Multicast for BGP/MPLS IP Virtual 653 Private Networks (VPNs)" [IANA-SAFI]. 655 The default VPN-IP routes received from the V-hub(s) may be either 656 Internet default VPN-IP routes, or non-Internet default VPN-IP 657 routes. 659 7.3. Originating VPN-IP default route by a V-hub 661 When originating a VPN-IP default route, a V-hub, in addition to the 662 procedures specified in section "Routing Information Exchange", also 663 follows the procedures of sections 6 and 7 of [rfc6514] (see also 664 section 5.1 of [rfc6513]). Specifically the V-hub MUST add the VRF 665 Route Import extended community that embeds the V-hub's IP address. 666 The route also MUST include the Source AS extended community. 668 7.4. Handling C-multicast routes 670 In the following the term "C-multicast routes" refers to BGP routes 671 that carry customer multicast routing information [rfc6514]. 673 Origination of C-multicast routes follow the procedures of [rfc6514] 674 (this is irrespective of whether these routes are originated by a V- 675 hub or by a V-spoke). 677 When a V-spoke receives a C-multicast route, the V-spoke follows the 678 [rfc6514] procedures. 680 When a V-hub receives a C-multicast route, the V-hub determines 681 whether the customer RP (C-RP) or the customer source (C-S) of the 682 route is reachable via one of its VRF interfaces, and if yes, then 683 the V-hub follows the [rfc6514] procedures. 685 Otherwise, the C-RP/C-S of the route is reachable via some other PE 686 (this is the case where the received route was originated by a V- 687 spoke that sees the V-hub as the "upstream PE" for a given source, 688 but the V-hub sees some other PE (either V-hub or V-spoke) as the 689 "upstream PE" for that source). In this case the V-hub uses the type 690 (Source Tree Join vs Shared Tree Join), the Multicast Source, and 691 Multicast Group from the received C-multicast route to construct a 692 new route of the same type, with the same Multicast Source and 693 Multicast Group. The hub constructs the rest of the new route 694 following procedures specified in 11.1.3 of [rfc6514]. The hub also 695 creates the appropriate (C-*, C-G) or (C-S, C-G) state in its MVPN 696 Tree Information Base (MVPN-TIB). 698 7.5. Originating I-PMSI/S-PMSI/SA A-D routes by V-spoke 700 When a V-spoke originates an I-PMSI, or S-PMSI, or Source Active (SA) 701 A-D route, the V-spoke follows the procedures of [rfc6514] (or in the 702 case of a wildcard S-PMSI A-D route the procedures of [rfc6625]), 703 including the procedures for constructing RT(s) carried by the route. 704 Note that as a result, such a route will be imported by the V-hubs. 705 In the case of an I-PMSI/S-PMSI A-D route, the P-tunnel bound to this 706 route is used to carry to these V-hubs traffic originated by the 707 sites connected to the V-spoke. 709 If the V-spoke exports its (unicast) VPN-IP routes not just to the V- 710 hubs, but also to some other V-spokes (as described in section 711 "Routing Information Exchange"), then (as a result of following the 712 procedures of [rfc6514], or in the case of a wildcard S-PMSI A-D 713 route the procedures of [rfc6625]) the I-PMSI/S-PMSI/SA A-D route 714 originated by the V-spoke will be imported not just by the V-hubs, 715 but also by these other V-spokes. This is because in this scenario 716 the route will carry more than one RT; one of these RTs, RT-VPN, will 717 result in importing the route by the V-hubs, while other RT(s) will 718 result in importing the route by the V-spokes (the other RT(s) are 719 the RT(s) that the V-spoke uses for importing the VPN-IP default 720 route). In this case the P-tunnel bound to this I-PMSI/S-PMSI A-D 721 route is also used to carry traffic originated by the sites connected 722 to the V-spoke that originates the route to these other V-spokes. 724 7.6. Originating I-PMSI/S-PMSI/SA A-D routes by V-hub 726 When a V-hub originates an I-PMSI/S-PMSI/SA A-D route, the V-hub 727 follows the procedures of [rfc6514] (or in the case of a wildcard S- 728 PMSI A-D route the procedures of [rfc6625]), except that in addition 729 to the RT(s) constructed following these procedures, the route MUST 730 also carry the RT of the VPN-IP default route advertised by the V-hub 731 (RT-VH). Note that as a result, such a route will be imported by 732 other V-hubs, and also by the V-spokes, but only by the V-spokes that 733 are associated with the V-hub (the V-spokes that import the VPN-IP 734 default route originated by the V-hub). In the case of an I-PMSI/S- 735 PMSI A-D route, the P-tunnel bound to this route is used to carry to 736 these other V-hubs and V-spokes the traffic originated by the sites 737 connected to the V-hub that originates the route. 739 In addition, if a V-hub originates an I-PMSI A-D route following the 740 procedures of [rfc6514], the V-hub MUST originate another I-PMSI A-D 741 route - we'll refer to this route as a "Associated-V-spoke-only I- 742 PMSI A-D route". The RT carried by this route MUST be the RT that is 743 carried in the VPN-IP default route advertised by the V-hub (RT-VH). 744 Therefore, this route will be imported only by the V-spokes 745 associated with the V-hub (the V-spokes that import the VPN-IP 746 default route advertised by this V-hub). The P-tunnel bound to this 747 route is used to carry to these V-spokes traffic originated by the 748 sites connected to either (a) other V-hubs, or (b) other V-spokes, 749 including the V-spokes that import the VPN-IP default route from the 750 V-hub, or (c) "vanilla" PEs. More details on the use of this P-tunnel 751 are described in section "Receiving I-PMSI/S-PMSI/SA A-D routes by V- 752 hub". 754 As a result, a V-hub originates not one, but two I-PMSI A-D routes - 755 one is a "vanilla" I-PMSI A-D route, and another is an Associated-V- 756 spoke-only I-PMSI A-D route. Each of these routes MUST have a 757 distinct RD. 759 When a V-hub receives traffic from one of the sites connected to the 760 V-hub, and the V-hub determines (using some local policies) that this 761 traffic should be transmitted using an I-PMSI, the V-hub forwards 762 this traffic on the P-tunnel bound to the "vanilla" I-PMSI A-D route, 763 but MUST NOT forward it on the P-tunnel bound to the Associated-V- 764 spoke-only I-PMSI A-D route. 766 7.7. Receiving I-PMSI/S-PMSI/SA A-D routes by V-spoke 768 When a V-spoke receives an I-PMSI/S-PMSI/SA A-D route, the V-spoke 769 follows the procedures of [rfc6514] (or in the case of a wildcard S- 770 PMSI A-D route the procedures of [rfc6625]). As a result, a V-spoke 771 that is associated with a given V-hub (the V-spoke that imports the 772 VPN-IP default route originated by that V-hub) will also import I- 773 PMSI/S-PMSI/SA A-D routes originated by that V-hub. Specifically, the 774 V-spoke will import both the "vanilla" I-PMSI A-D route and the 775 Associated-V-spoke-only I-PMSI A-D route originated by the V-hub. 777 In addition, if a V-spoke imports the (unicast) VPN-IP routes 778 originated by some other V-spokes (as described in section "Routing 779 Information Exchange"), then the V-spoke will also import I-PMSI/S- 780 PMSI/SA A-D routes originated by these other V-spokes. 782 7.8. Receiving I-PMSI/S-PMSI/SA A-D routes by V-hub 784 The following describe procedures that a V-hub MUST follow when it 785 receives an I-PMSI/S-PMSI/SA A-D route. 787 7.8.1. Case 1 789 This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D 790 route, and one of the RT(s) carried in the route is the RT that the 791 V-hub uses for advertising its VPN-IP default route (RT-VH). 793 In this case the receiving route was originated either 795 + by a V-spoke associated with the V-hub (the V-spoke that imports 796 the VPN-IP default route originated by the V-hub), or 798 + by some other V-hub that uses the same RT as the receiving V-hub 799 for advertising the VPN-IP default route. 801 In this case the received I-PMSI/S-PMSI/SA A-D route carries more 802 than one RT. One of these RTs results in importing this route by the 803 V-hubs. Another of these RTs is the RT that the V-hub uses when 804 advertising its VPN-IP default route (RT-VH). This RT results in 805 importing the received I-PMSI/S-PMSI/SA A-D route by all the V-spokes 806 associated with the V-hub (the V-spokes that import the VPN-IP 807 default route originated by the V-hub). 809 In handling such I-PMSI/S-PMSI/SA A-D route the V-hub simply follows 810 the procedures of [rfc6514] (or in the case of a wildcard S-PMSI A-D 811 route the procedures of [rfc6625]). Specifically, the V-hub MUST NOT 812 re-originate this route as done in Case 2 below. 814 The following specifies the rules that the V-hub MUST follow when 815 handling traffic that the V-hub receives on a P-tunnel bounded to 816 this I-PMSI/S-PMSI A-D route. The V-hub may forward this traffic to 817 only the sites connected to that V-hub (forwarding this traffic to 818 these sites follows the procedures specified in [rfc6514], or in the 819 case of a wildcard S-PMSI A-D route the procedures of [rfc6625]). The 820 V-hub MUST NOT forward the traffic received on this P-tunnel to any 821 other V-hubs or V-spokes, including the V-spokes that import the VPN- 822 IP default route originated by the V-hub (V-spokes associated with 823 the V-hub). Specifically, the V-hub MUST NOT forward the traffic 824 received on the P-tunnel advertised in the received I-PMSI A-D route 825 over the P-tunnel that the V-hub binds to its Associated-V-spoke-only 826 I-PMSI A-D route. 828 7.8.2. Case 2 830 This is the case where a V-hub receives an I-PMSI/S-PMSI/SA A-D 831 route, and the route does not carry the RT that the receiving V-hub 832 uses when advertising its VPN-IP default route (RT-VH). 834 In this case the receiving I-PMSI/S-PMSI/SA A-D route was originated 835 by either some other V-hub, or by a V-spoke. The I-PMSI/S-PMSI/SA A-D 836 route is imported by the V-hub (as well as by other V-hubs), but not 837 by any of the V-spokes associated with the V-hub (V-spokes that 838 import the VPN-IP default route originated by the V-hub). 840 In this case the V-hubs follows the procedures of [rfc6514] (or in 841 the case of a wildcard S-PMSI A-D route the procedures of [rfc6625]) 842 with the following additions. 844 Once a V-hub accepts an I-PMSI A-D route, when the V-hub receives 845 data on the P-tunnel bound to that I-PMSI A-D route, the V-hub 846 follows procedures in [rfc6513], [rfc6514] to determine whether to 847 accept the data. If the data is accepted, then the V-hub further 848 forwards the data over the P-tunnel bound to the Associated-V-spoke- 849 only I-PMSI A-D route originated by the V-hub. Note that in deciding 850 whether to forward the data over the P-tunnel bound to the 851 Associated-V-spoke-only I-PMSI A-D route originated by the V-hub, the 852 V-hub SHOULD take into account the (multicast) state present in its 853 MVPN-TIB that has been created as a result receiving C-multicast 854 routes from the V-spokes associated with the V-hub. If (using the 855 information present in the MVPN-TIB) the V-hub determines that none 856 of these V-spokes have receivers for the data, the V-hub SHOULD NOT 857 forward the data over the P-tunnel bound to the Associated-V-spoke- 858 only I-PMSI A-D route originated by the V-hub. 860 Whenever a V-hub imports an S-PMSI A-D route (respectively SA A-D 861 route) in a VRF, the V-hub, in contrast to Case 1 above, MUST 862 originate an S-PMSI A-D route (respectively SA A-D route) targeted to 863 its V-spokes. To accomplish this, the V-hub replaces the RT(s) 864 carried in the route with the RT that the V-hub uses when originating 865 its VPN-IP default route (RT-VH), changes the RD of the route to the 866 RD that the V-hub uses when originating its Associated-V-spoke-only 867 I-PMSI A-D route, and sets Next Hop to self. For S-PMSI A-D routes 868 the V-hub also changes the Originating Router's IP address in the 869 MCAST-VPN NLRI of the route to its own IP address (the same address 870 as the one in the Next Hop). Moreover, before advertising the new S- 871 PMSI A-D route, the V-hub modifies their PMSI Tunnel attribute as 872 appropriate (e.g., by replacing the P-tunnel rooted at the originator 873 of these routes with a P-tunnel rooted at the V-hub). 875 Note that a V-hub of a given MVPN may receive and accept multiple 876 (C-*, C-*) wildcard S-PMSI A-D routes [rfc6625], each originated by 877 its own PE. Yet, even if the V-hub receives and accepts such multiple 878 (C-*, C-*) S-PMSI A-D routes, the V-hub re-advertises just one (C-*, 879 C-*) S-PMSI A-D route, thus aggregating the received (C-*, C-*) S- 880 PMSI A-D routes. The same applies for (C-*, C-G) S-PMSI A-D routes. 882 Whenever a V-hub receives data on the P-tunnel bound to a received S- 883 PMSI A-D route, the V-hub follows procedures of [rfc6513], [rfc6514] 884 (or in the case of a wildcard S-PMSI A-D route the procedures of 885 [rfc6625]) to determine whether to accept the data. If the data is 886 accepted, then the V-hub further forwards it over the P-tunnel bound 887 to the S-PMSI A-D route that has been re-advertised by the V-hub. 889 If multiple S-PMSIs received by a V-hub have been aggregated into the 890 same P-tunnel, then the V-hub, prior to forwarding to the V-spokes 891 associated with that V-hub the data received on this P-tunnel MAY de- 892 aggregate and then re-aggregate (in a different way) this data using 893 the state present in its MVPN-TIB that has been created as a result 894 of receiving C-multicast routes from the V-spokes. Even if S-PMSIs 895 received by the V-hub each have their own P-tunnel, the V-hub, prior 896 to forwarding to the V-spokes the data received on these P-tunnels 897 MAY aggregate these S-PMSIs using the state present in its MVPN-TIB 898 that has been created as a result of receiving C-multicast routes 899 from the V-spokes. 901 7.9. Use of Ingress Replication with I-PMSI A-D routes 903 The following modifications to the procedures specified in [rfc6514] 904 for originating/receiving I-PMSI A-D routes enable to discard packets 905 coming from a "wrong" PE when Ingress Replication is used for I-PMSI 906 P-tunnels (for other types of P-tunnels the procedures specified in 907 [rfc6513], [rfc6514] are sufficient). 909 The modifications to the procedures are required to be implemented 910 (by all the PEs of a given MVPN) only under the following conditions: 912 + At least one of those PEs is a V-hub or V-spoke PE for the given 913 MVPN. 915 + The given MVPN is configured to use the optional procedure of 916 using Ingress Replication to instantiate an I-PMSI. 918 If Ingress Replication is used with I-PMSI A-D routes, then when a PE 919 advertises such routes, the Tunnel Type in the PMSI Tunnel attribute 920 MUST be set to Ingress Replication; the Leaf Information Required 921 flag MUST be set to 1; the the attribute MUST carry no MPLS labels. 923 A PE that receives such I-PMSI A-D route MUST respond with a Leaf A-D 924 route. The PMSI Tunnel attribute of that Leaf A-D route is 925 constructed as follows. The Tunnel Type is set to Ingress 926 Replication. The Tunnel Identifier MUST carry a routable address of 927 the PE that originates the Leaf A-D route. The PMSI Tunnel attribute 928 MUST carry a downstream assigned MPLS label that is used to 929 demultiplex the traffic received over a unicast tunnel by the PE. 930 The receiving PE MUST assign the label in such a way as to enable the 931 receiving PE to identify (a) the VRF on that PE that should be used 932 to process the traffic received with this label, and (b) the PE that 933 sends the traffic with this label. 935 This document assumes that for a given MVPN all the PEs that have 936 sites of that MVPN connected to them implement the procedures 937 specified in this section. 939 8. An example of RT provisioning 941 Consider a VPN A that consists of 9 sites - site-1 through site-9. 942 Each site is connected to its own PE - PE-1 through PE-9. 944 We designate PE-3, PE-6, and PE-9 as V-hubs. 946 To simplify the presentation the following example assumes that each 947 V-spoke is associated with just one V-hub. However, as mentioned 948 earlier, in practice each V-spoke should be associated with two or 949 more V-hubs. 951 PE-1 and PE-2 are V-spokes associated with PE-3. PE-4 and PE-5 are V- 952 spokes associated with PE-6. PE-7 and PE-8 are V-spokes associated 953 with PE-9. 955 8.1. Unicast routing 957 All the PEs (both V-hubs and V-spokes) are provisioned to export 958 routes using RT-A (just as it would be with "vanilla" any-to-any 959 VPN). 961 All the V-hubs (PE-3, PE-6, and PE-9) are provisioned to import 962 routes with RT-A (just as it would be with "vanilla" any-to-any VPN). 964 In addition, PE-3 is provisioned to originate a VPN-IP default route 965 with RT-A-VH-1 (but not with RT-A), while PE-1 and PE-2 are 966 provisioned to import routes with RT-A-VH-1. 968 Likewise, PE-6 is provisioned to originate a VPN-IP default route 969 with RT-A-VH-2 (but not with RT-A), while PE-4 and PE-5 are 970 provisioned to import routes with RT-A-VH-2. 972 Finally, PE-9 is provisioned to originate a VPN-IP default route with 973 RT-A-VH-3 (but not with RT-A), while PE-7 and PE-8 are provisioned to 974 import routes with RT-A-VH-3. 976 Now let's modify the above a bit by assuming that site-3 has Internet 977 connectivity. Thus site-3 advertises an IP default route to PE-3. 978 PE-3, in turn originates a VPN-IP default route. In this case, the 979 VPN-IP default route carries RT-A and RT-A-VH-1 (rather than just RT- 980 A-VH-1, as before), which results in importing this route to PE-6 and 981 PE-9, as well as to PE-1 and PE-2. 983 If PE-7 and PE-8, in addition to importing VPN-IP default route from 984 PE-9, also want to import each other VPN-IP routes, then PE-7 and 985 PE-8 export their VPN-IP routes with two RTs: RT-A and RT-A-VH-3. 987 8.2. Multicast routing 989 All the PEs designated as V-spokes (PE-1, PE-2, PE-4, PE-5, PE-7, and 990 PE-8) are provisioned to export their I-PMSI/S-PMSI/SA A-D routes 991 using RT-A (just as it would be with "vanilla" any-to-any MVPN). Thus 992 these routes could be imported by all the V-hubs (PE-3, PE-6, and 993 PE-9). 995 The V-hub on PE-3 is provisioned to export its I-PMSI/S-PMSI/SA A-D 996 routes with two RTs: RT-A and RT-A-VH-1. Thus these routes could be 997 imported by all the other V-hubs (PE-6 and PE-9), and also by the V- 998 spokes, but only by the V-spokes associated with the V-hub on PE-3 999 (PE-1 and PE-2). In addition, the V-hub on PE-3 originates the 1000 Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-1. This route 1001 could be imported only by the V-spokes associated with the V-hub on 1002 PE-3 (PE-1 and PE-2). 1004 The V-hub on PE-6 is provisioned to export its I-PMSI/S-PMSI/SA A-D 1005 routes with two RTs: RT-A and RT-A-VH-2. Thus these routes could be 1006 imported by all the other V-hubs (PE-3 and PE-9), and also by the V- 1007 spokes, but only by the V-spokes associated with the V-hub on PE-6 1008 (PE-4 and PE-5). In addition, the V-hub on PE-6 originates the 1009 Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-2. This route 1010 could be imported only by the V-spokes associated with the V-hub on 1011 PE-6 (PE-4 and PE-5). 1013 The V-hub on PE-9 is provisioned to export its I-PMSI/S-PMSI/SA A-D 1014 routes with two RTs: RT-A and RT-A-VH-3. Thus these routes could be 1015 imported by all the other V-hubs (PE-3 and PE-6), and also by the V- 1016 spokes, but only by the V-spokes associated with the V-hub on PE-9 1017 (PE-7 and PE-8). In addition, the V-hub on PE-9 originates the 1018 Associated-V-spoke-only I-PMSI A-D route with RT-A-VH-3. This route 1019 could be imported only by the V-spokes associated with the V-hub on 1020 PE-9 (PE-7 and PE-8). 1022 If PE-7 and PE-8, in addition to importing VPN-IP default route from 1023 PE-9, also want to import each other VPN-IP routes, then PE-7 and 1024 PE-8 export their I-PMSI/S-PMSI/SA A-D routes with two RTs: RT-A and 1025 RT-A-VH-3. 1027 If the V-hub on PE-9 imports an S-PMSI A-D route or SA A-D route 1028 originated by either some other V-hub (PE-3 or PE-6), or by a V-spoke 1029 that is not associated with this V-hub (PE-1, or PE-2, or PE-4, or 1030 PE-5), the V-hub originates an S-PMSI A-D route (respectively SA A-D 1031 route). The V-hub constructs this route from the imported route 1032 following the procedures specified in section "Case 2". Specifically, 1033 the V-hub replaces the RT(s) carried in the imported route with just 1034 one RT - RT-A-VH-3. Thus, the originated route could be imported only 1035 by the V-spokes associated with the V-hub on PE-9 (PE-7 and PE-8). 1037 9. Further Refinements 1039 In some cases a VPN customer may not want to rely solely on an (IP) 1040 default route being advertised from a V-spoke to a CE, but may want 1041 CEs to receive all the VPN routes (e.g., for the purpose of faster 1042 detection of VPN connectivity failures, and activating some backup 1043 connectivity). 1045 In this case an OPTIONAL approach would be to install in the V- 1046 spoke's data plane only the VPN-IP default route advertised by the V- 1047 hub associated with the V-spoke, even if the V-spoke receives an IP 1048 default route from the CE, and keep all the VPN-IP routes in the V- 1049 spoke's control plane (thus being able to advertise these routes as 1050 IP routes from the V-spoke to the CEs). Granted, this would not 1051 change control plane resource consumption, but would reduce 1052 forwarding state on the data plane. 1054 10. IANA Considerations 1056 This document introduces no new IANA Considerations. 1058 11. Security Considerations 1060 This document introduces no new Security Considerations, above and 1061 beyond what is already specified in [rfc4364]. 1063 12. Acknowledgements 1065 We would like to acknowledge Han Nguyen (AT&T) for his contributions 1066 to this document. We would like to thank Eric Rosen(Cisco) for his 1067 review and comments. We would also like to thank Samir Saad (AT&T), 1068 Jeffrey (Zhaohui) Zhang (Juniper), and Thomas Morin (France Telecom) 1069 for their review and comments. 1071 13. Normative References 1073 [rfc1918] Rekhter, Y., et.al., "Address Allocation for Private 1074 Internets", RFC 1918, February 1996. 1076 [rfc2119] "Key words for use in RFCs to Indicate Requirement 1077 Levels.", Bradner, March 1997 1079 [rfc3031] Rosen, E., et. al., "MPLS Architecture", RFC3031, January 1080 2001. 1082 [rfc4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1083 Communities Attribute", RFC 4360, February 2006. 1085 [rfc4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1086 Networks (VPNs)", RFC 4364, February 2006. 1088 [rfc4684] Pedro Marques, et al., "Constrained Route Distribution for 1089 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1090 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC4684, 1091 November 2006 1093 [rfc6513] Eric C. Rosen, Rahul Aggarwal, et. al., "Multicast in 1094 MPLS/BGP IP VPNs", RFC6513, February 2012 1096 [rfc6514] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP Encodings 1097 and Procedures for Multicast in MPLS/BGP IP VPNs", RFC6514, February 1098 2012 1100 [rfc6625] Eric Rosen, et. al., "Wildcards in Multicast VPN Auto- 1101 Discovery Routes", RFC6625, May 2012 1103 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace/safi- 1104 namespace.xhtml 1106 14. Informative References 1108 [seamless-MPLS-multicast] Yakov Rekhter, et. al., "Inter-Area P2MP 1109 Segmented LSPs", draft-ietf-mpls-seamless-mcast, work in progress. 1111 15. Authors' Addresses 1113 Huajin Jeng 1114 AT&T 1115 e-mail: hj2387@att.com 1117 James Uttaro 1118 AT&T 1119 e-mail: ju1738@att.com 1121 Luay Jalil 1122 Verizon 1123 e-mail: luay.jalil@verizon.com 1125 Bruno Decraene 1126 France Telecom 1127 e-mail: bruno.decraene@orange.com 1129 Rahul Aggarwal 1130 e-mail: raggarwa_1@yahoo.com 1132 Yakov Rekhter 1133 Juniper Networks, Inc. 1134 e-mail: yakov@juniper.net