idnits 2.17.1 draft-morin-l3vpn-mvpn-fast-failover-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: [RFC4875], the status of the corresponding P-Tunnel SHOULD be re-evaluated. If the P-Tunnel transitions from up to down state, the upstream PE, that is the ingress of the P-Tunnel, SHOULD not be considered a valid UMH. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2014) is 3581 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-rtgwg-mofrr-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Morin, Ed. 3 Internet-Draft Orange 4 Intended status: Experimental R. Kebler, Ed. 5 Expires: January 2, 2015 Y. Rekhter 6 R. Qiu 7 Juniper Networks 8 R. Aggarwal 9 Arktan 10 W. Henderickx 11 P. Muley 12 Alcatel-Lucent 13 July 1, 2014 15 Multicast VPN fast upstream failover 16 draft-morin-l3vpn-mvpn-fast-failover-06 18 Abstract 20 This document defines multicast VPN extensions and procedures that 21 allow fast failover for upstream failures, by allowing downstream PEs 22 to take into account the status of Provider-Tunnels (P-tunnels) when 23 selecting the upstream PE for a VPN multicast flow, and extending BGP 24 MVPN routing so that a C-multicast route can be advertized toward a 25 standby upstream PE. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 2, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. UMH Selection based on tunnel status . . . . . . . . . . . . 3 70 3.1. Determining the status of a tunnel . . . . . . . . . . . 4 71 3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5 72 3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5 73 3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 5 74 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6 75 3.1.5. P2MP LSP OAM . . . . . . . . . . . . . . . . . . . . 6 76 3.1.6. (S,G) counter information . . . . . . . . . . . . . . 6 77 4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 7 78 4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 7 79 4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 8 80 4.3. Reachability determination . . . . . . . . . . . . . . . 9 81 4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 10 82 4.4.1. Inter-AS procedures for downstream PEs, ASBR fast 83 failover . . . . . . . . . . . . . . . . . . . . . . 10 84 4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 10 85 5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . 11 86 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 10.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 In the context of multicast in BGP/MPLS VPNs, it is desirable to 98 provide mechanisms allowing fast recovery of connectivity on 99 different types of failures. This document addresses failures of 100 elements in the provider network that are upstream of PEs connected 101 to VPN sites with receivers. 103 The sections 3 and 4 describe two independent mechanisms, allowing 104 different levels of resiliency, and providing different failure 105 coverage: 107 o Section 3 describes local procedures allowing an egress PE (a PE 108 connected to a receiver site) to take into account the status of 109 P-Tunnels to determine the Upstream Multicast Hop (UMH) for a 110 given (C-S, C-G). This method does not provide a "fast failover" 111 solution when used alone, but can be used with the following 112 sections for a "fast failover" solution. 114 o Section 4 describes protocol extensions that can speed up failover 115 by not requiring any multicast VPN routing message exchange at 116 recovery time. 118 Moreover, section 5 describes a "hot leaf standby" mechanism, that 119 uses a combination of these two mechanisms. This approach has 120 similarities with the solution described in [I-D.mofrr] to improve 121 failover times when PIM routing is used in a network given some 122 topology and metric constraints. 124 2. Terminology 126 The terminology used in this document is the terminology defined in 127 [RFC6513] and [RFC6514]. 129 3. UMH Selection based on tunnel status 131 Current multicast VPN specifications [RFC6513], section 5.1, describe 132 the procedures used by a multicast VPN downstream PE to determine 133 what the upstream multicast hop (UMH) is for a said (C-S,C-G). 135 The procedure described here is an OPTIONAL procedure that consist in 136 having a downstream PE take into account the status of P-tunnels 137 rooted at each possible upstream PEs, for including or not including 138 each said PE in the list of candidate UMHs for a said (C-S,C-G) 139 state. The result is that, if a P-tunnel is "down" (see 140 Section 3.1), the PE that is the root of the P-Tunnel will not be 141 considered for UMH selection, which will result in the downstream PE 142 to failover to the upstream PE which is next in the list of 143 candidates. 145 A downstream PE monitors the status of the tunnels of UMHs that are 146 ahead of the current one. Whenever the downstream PE determines that 147 one of these tunnels is no longer "known to down", the PE selects the 148 UMH corresponding to that as the new UMH. 150 More precisely, UMH determination for a said (C-S,C-G) will consider 151 the UMH candidates in the following order: 153 o first, the UMH candidates that either (a) advertise a PMSI bound 154 to a tunnel, where the specified tunnel is not known to be down or 155 (b) do not advertise any I- or S- PMSI applicable to the said 156 (C-S,C-G) but have associated a VRF Route Import BGP attribute to 157 the unicast VPN route for S (this is necessary to avoid 158 considering invalid some UMH PEs that use a policy where no I-PMSI 159 is advertized for a said VRF and where only S-PMSI are used, the 160 S-PMSI advertisement being possibly done only after the upstream 161 PE receives a C-multicast route for (C-S, C-G)/(C-*, C-G) to be 162 carried over the advertized S-PMSI) 164 o second, the UMH candidates that advertise a PMSI bound to a tunnel 165 that is "down" -- these will thus be used as a last resort to 166 ensure a graceful fallback to the basic MVPN UMH selection 167 procedures in the hypothetical case where a false negative would 168 occur when determining the status of all tunnels 170 For a said downstream PE and a said VRF, the P-tunnel corresponding 171 to a said upstream PE for a said (C-S,C-G) state is the S-PMSI tunnel 172 advertized by that upstream PE for this (C-S,C-G) and imported into 173 that VRF, or if there isn't any such S-PMSI, the I-PMSI tunnel 174 advertized by that PE and imported into that VRF. 176 Note that this documents assumes that if a site of a given MVPN that 177 contains C-S is dual-homed to two PEs, then all the other sites of 178 that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) 179 routes to C-S, each with its own RD. 181 3.1. Determining the status of a tunnel 183 Different factors can be considered to determine the "status" of a 184 P-tunnel and are described in the following sub-sections. The 185 procedure proposed here also allows that all downstream PEs don't 186 apply the same rules to define what the status of a P-tunnel is 187 (please see Section 6), and some of them will produce a result that 188 may be different for different downstream PEs. Thus what is called 189 the "status" of a P-tunnel in this section, is not a characteristic 190 of the tunnel in itself, but is the status of the tunnel, *as seen 191 from a particular downstream PE*. 193 Depending on the criteria used to determine the status of a P-tunnel, 194 there may be an interaction with other resiliency mechanism used for 195 the P-tunnel itself, and the UMH update may happen immediately or may 196 need to be delayed. Each particular case is covered in each separate 197 sub-section below. 199 3.1.1. mVPN tunnel root tracking 201 A condition to consider that the status of a P-tunnel is up is that 202 the root of the tunnel, as determined in the PMSI tunnel attribute, 203 is reachable through unicast routing tables. In this case the 204 downstream PE can immediately update its UMH when the reachability 205 condition changes. 207 This is similar to BGP next-hop tracking for VPN routes, except that 208 the address considered is not the BGP next-hop address, but the root 209 address in the PMSI tunnel attribute. 211 If BGP next-hop tracking is done for VPN routes, and the root address 212 of a said tunnel happens to be the same as the next-hop address in 213 the BGP autodiscovery route advertising the tunnel, then this 214 mechanisms may be omitted for this tunnel, as it will not bring any 215 specific benefit. 217 3.1.2. PE-P Upstream link status 219 A condition to consider a tunnel status as up can be that the last- 220 hop link of the P-tunnel is up. 222 This method should not be used when there is a fast restoration 223 mechanism (such as MPLS FRR [RFC4090]) in place for the link. 225 3.1.3. P2MP RSVP-TE tunnels 227 For P-Tunnels of type P2MP MPLS-TE, the status of the P-Tunnel is 228 considered up if one or more of the P2MP RSVP-TE LSPs, identified by 229 the P-Tunnel Attribute, are in up state. The determination of 230 whether a P2MP RSVP-TE LSP is in up state requires Path and Resv 231 state for the LSP and is based on procedures in [RFC4875]. In this 232 case the downstream PE can immediately update its UMH when the 233 reachability condition changes. 235 When signaling state for a P2MP TE LSP is removed (e.g. if the 236 ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE 237 LSP changes state from up to down as determined by procedures in 239 [RFC4875], the status of the corresponding P-Tunnel SHOULD be re- 240 evaluated. If the P-Tunnel transitions from up to down state, the 241 upstream PE, that is the ingress of the P-Tunnel, SHOULD not be 242 considered a valid UMH. 244 3.1.4. Leaf-initiated P-tunnels 246 A PE can be removed from the UMH candidate list for a said (S,G) if 247 the P-tunnel for this S,G (I or S , depending) is leaf triggered 248 (PIM, mLDP), but for some reason internal to the protocol the 249 upstream one-hop branch of the tunnel from P to PE cannot be built. 250 In this case the downstream PE can immediately update its UMH when 251 the reachability condition changes. 253 3.1.5. P2MP LSP OAM 255 When a P2MP connectivity verification mechanism such as 256 [I-D.katz-ward-bfd-multipoint] used in conjunction with bootstrapping 257 mechanisms described in [I-D.ietf-mpls-mcast-cv] has been setup for a 258 tunnel, the result of the connectivity verification can be used to 259 define the status of the tree. 261 If a MultipointHead session has been established on a P2MP MPLS LSP 262 so that BFD packets are periodically sent from the root toward 263 leaves, a condition to consider the status of corresponding tunnel as 264 up is that the BFD SessionState is Up. 266 When such a procedure is used, in context where fast restoration 267 mechanisms are used for the P-tunnels, downstream PEs should be 268 configured to wait before updating the UMH, to let the P-tunnel 269 restoration mechanism happen. A configurable timer MUST be provided 270 for this purpose, and it is recommended to provide a reasonable 271 default value for this timer. 273 3.1.6. (S,G) counter information 275 In cases, where the downstream node can be configured so that the 276 maximum inter-packet time is known for all the multicast flows mapped 277 on a P-tunnel, the local per-(C-S,C-G) traffic counter information 278 for traffic received on this P-tunnel can be used to determine the 279 status of the P-tunnel. 281 When such a procedure is used, in context where fast restoration 282 mechanisms are used for the P-tunnels, downstream PEs should be 283 configured to wait before updating the UMH, to let the P-tunnel 284 restoration mechanism happen. A configurable timer MUST be provided 285 for this purpose, and it is recommended to provide a reasonable 286 default value for this timer. 288 This method can be applicable for instance when a (S,G) flow is 289 mapped on an S-PMSI. 291 In cases where this mechanism is used in conjunction with 292 Hot leaf standby, then no prior knowledge of the rate of the 293 multicast streams is required ; downstream PEs can compare reception 294 on the two P-tunnels to determine when one of them is down. 296 4. Standby C-multicast route 298 The procedures described below are limited to the case where the site 299 that contains C-S is connected to exactly two PEs. The procedures 300 require all the PEs of that MVPN to follow the single forwarder PE 301 selection, as specified in [RFC6513]. The procedures assume that if 302 a site of a given MVPN that contains C-S is dual-homed to two PEs, 303 then all the other sites of that MVPN would have two unicast VPN 304 routes (VPN-IPv4 or VPN-IPv6) routes to C-S, each with its own RD. 306 As long as C-S is reachable via both PEs, a said downstream PE will 307 select one of the PEs connected to C-S as its Upstream PE with 308 respect to C-S. We will refer to the other PE connected to C-S as 309 the "Standby Upstream PE". Note that if the connectivity to C-S 310 through the Primary Upstream PE becomes unavailable, then the PE will 311 select the Standby Upstream PE as its Upstream PE with respect to 312 C-S. 314 For readability, in the following sub-sections, the procedures are 315 described for BGP C-multicast Source Tree Join routes, but they apply 316 equally to BGP C-multicast Shared Tree Join routes failover for the 317 case where the customer RP is dual-homed (substitute "C-RP" to 318 "C-S"). 320 4.1. Downstream PE behavior 322 When a (downstream) PE connected to some site of an MVPN needs to 323 send a C-multicast route (C-S, C-G), then following the procedures 324 specified in Section "Originating C-multicast routes by a PE" of 325 [RFC6514] the PE sends the C-multicast route with RT that identifies 326 the Upstream PE selected by the PE originating the route. As long as 327 C-S is reachable via the Primary Upstream PE, the Upstream PE is the 328 Primary Upstream PE. If C-S is reachable only via the Standby 329 Upstream PE, then the Upstream PE is the Standby Upstream PE. 331 If C-S is reachable via both the Primary and the Standby Upstream PE, 332 then in addition to sending the C-multicast route with an RT that 333 identifies the Primary Upstream PE, the PE also originates and sends 334 a C-multicast route with an RT that identifies the Standby Upstream 335 PE. This route, that has the semantic of being a 'standby' 336 C-multicast route, is further called a "Standby BGP C-multicast 337 route", and is constructed as follows: 339 o the NLRI is constructed as the original C-multicast route, except 340 that the RD is the same as if the C-multicast route was built 341 using the standby PE as the UMH (it will carry the RD associated 342 to the unicast VPN route advertized by the standby PE for S) 344 o SHOULD carry the "Standby PE" BGP Community (this is a new BGP 345 Community, see Section 7) 347 The normal and the standby C-multicast routes must have their Local 348 Preference attribute adjusted so that, if two C-multicast routes with 349 same NLRI are received by a BGP peer, one carrying the "Standby PE" 350 attribute and the other one *not* carrying the "Standby PE" 351 community, then preference is given to the one *not* carrying the 352 "Standby PE" attribute. Such a situation can happen when, for 353 instance due to transient unicast routing inconsistencies, two 354 different downstream PEs consider different upstream PEs to be the 355 primary one ; in that case, without any precaution taken, both 356 upstream PEs would process a standby C-multicast route and possibly 357 stop forwarding at the same time. For this purpose a Standby BGP 358 C-multicast route MUST have the LOCAL_PREF attribute set to zero. 360 Note that, when a PE advertizes such a Standby C-multicast join for 361 an (S,G) it must join the corresponding P-tunnel. 363 If at some later point the local PE determines that C-S is no longer 364 reachable through the Primary Upstream PE, the Standby Upstream PE 365 becomes the Upstream PE, and the local PE re-sends the C-multicast 366 route with RT that identifies the Standby Upstream PE, except that 367 now the route does not carry the Standby PE BGP Community (which 368 results in replacing the old route with a new route, with the only 369 difference between these routes being the presence/absence of the 370 Standby PE BGP Community). 372 4.2. Upstream PE behavior 374 When a PE receives a C-multicast route for a particular (C-S, C-G), 375 and the RT carried in the route results in importing the route into a 376 particular VRF on the PE, if the route carries the Standby PE BGP 377 Community, then the PE performs as follows: 379 when the PE determines that C-S is not reachable through some 380 other PE, the PE SHOULD install VRF PIM state corresponding to 381 this Standby BGP C-multicast route (the result will be that a PIM 382 Join message will be sent to the CE towards C-S, and that the PE 383 will receive (C-S,C-G) traffic), and the PE SHOULD forward (C-S, 384 C-G) traffic received by the PE to other PEs through a P-tunnel 385 rooted at the PE. 387 Furthermore, irrespective of whether C-S carried in that route is 388 reachable through some other PE: 390 a) based on local policy, as soon as the PE receives this Standby BGP 391 C-multicast route, the PE MAY install VRF PIM state corresponding 392 to this BGP Source Tree Join route (the result will be that Join 393 messages will be sent to the CE toward C-S, and that the PE will 394 receive (C-S,C-G) traffic) 396 b) based on local policy, as soon as the PE receives this Standby BGP 397 C-multicast route, the PE MAY forward (C-S, C-G) traffic to other 398 PEs through a P-tunnel independently of the reachability of C-S 399 through some other PE. [note that this implies also doing (a)] 401 Doing neither (a), nor (b) for a said (C-S,C-G) is called "cold root 402 standby". 404 Doing (a) but not (b) for a said (C-S,C-G) is called "warm root 405 standby". 407 Doing (b) (which implies also doing (a)) for a said (C-S,C-G) is 408 called "hot root standby". 410 Note that, if an upstream PE uses an S-PMSI only policy, it shall 411 advertise an S-PMSI for an (S,G) as soon as it receives a C-multicast 412 route for (S,G), normal or Standby ; i.e. it shall not wait for 413 receiving a non-Standby C-multicast route before advertising the 414 corresponding S-PMSI. 416 Section 9.3.2 of [RFC6514], describes the procedures of sending a 417 Source-Active A-D result as a result of receiving the C-multicast 418 route. These procedures should be followed for both the normal and 419 Standby C-multicast routes. 421 4.3. Reachability determination 423 The standby PE can use the following information to determine that 424 C-S can or cannot be reached through the primary PE: 426 o presence/absence of a unicast VPN route toward C-S 428 o supposing that the standby PE is an egress of the tunnel rooted at 429 the Primary PE, the standby PE can determine the reachability of 430 C-S through the Primary PE based on the status of this tunnel, 431 determined thanks to the same criteria as the ones described in 432 Section 3.1 (without using the UMH selection procedures of 433 Section 3) 435 o other mechanisms MAY be used 437 4.4. Inter-AS 439 If the non-segmented inter-AS approach is used, the procedures in 440 section 4 can be applied. 442 When multicast VPNs are used in a inter-AS context with the segmented 443 inter-AS approach described in section 8.2 of [RFC6514], the 444 procedures in this section can be applied. 446 A pre-requisite for the procedures described below to be applied for 447 a source of a said MVPN is: 449 o that any PE of this MVPN receives two Inter-AS I-PMSI auto- 450 discovery routes advertized by the AS of the source (or more) 452 o that these Inter-AS I-PMSI autodiscovery routes have distinct 453 Route Distinguishers (as described in item "(2)" of section 9.2 of 454 [RFC6514]). 456 As an example, these conditions will be satisfied when the source is 457 dual homed to an AS that connects to the receiver AS through two ASBR 458 using auto-configured RDs. 460 4.4.1. Inter-AS procedures for downstream PEs, ASBR fast failover 462 The following procedure is applied by downstream PEs of an AS, for a 463 source S in a remote AS. 465 Additionally to choosing an Inter-AS I-PMSI autodiscovery route 466 advertized from the AS of the source to construct a C-multicast 467 route, as described in section 11.1.3 [RFC6514] a downstream PE will 468 choose a second Inter-AS I-PMSI autodiscovery route advertized from 469 the AS of the source and use this route to construct and advertise a 470 Standby C-multicast route (C-multicast route carrying the Standby 471 extended community) as described in Section 4.1. 473 4.4.2. Inter-AS procedures for ASBRs 475 When an upstream ASBR receives a C-multicast route, and at least one 476 of the RTs of the route matches one of the ASBR Import RT, the ASBR 477 locates an Inter-AS I-PMSI A-D route whose RD and Source AS matches 478 the RD and Source AS carried in the C-multicast route. If the match 479 is found, and C-multicast route carries the Standby PE BGP Community, 480 then the ASBR performs as follows: 482 o if the route was received over iBGP ; the route is expected to 483 have a LOCAL_PREF attribute set to zero and it should be re- 484 advertized in eBGP with a MED attribute (MULTI_EXIT_DISC) set to 485 the highest possible value (0xffff) 487 o if the route was received over eBGP ; the route is expected to 488 have a MED attribute set of 0xffff and should be re-advertized in 489 iBGP with a LOCAL_PREF attribute set to zero 491 Other ASBR procedures are applied without modification. 493 5. Hot leaf standby 495 The mechanisms defined in sections Section 4 and Section 3 can be 496 used together as follows. 498 The principle is that, for a said VRF (or possibly only for a said 499 C-S,C-G): 501 o downstream PEs advertise a Standby BGP C-multicast route (based on 502 Section 4) 504 o upstream PEs use the "hot standby" optional behavior and thus will 505 forward traffic for a said multicast state as soon as they have 506 whether a (primary) BGP C-multicast route or a Standby BGP 507 C-multicast route for that state (or both) 509 o downstream PEs accept traffic from the primary or standby tunnel, 510 based on the status of the tunnel (based on Section 3) 512 Other combinations of the mechanisms proposed in Section 4) and 513 Section 3 are for further study. 515 Note that the same level of protection would be achievable with a 516 simple C-multicast Source Tree Join route advertized to both the 517 primary and secondary upstream PEs (carrying as Route Target extended 518 communities, the values of the VRF Route Import attribute of each VPN 519 route from each upstream PEs). The advantage of using the Standby 520 semantic for is that, supposing that downstream PEs always advertise 521 a Standby C-multicast route to the secondary upstream PE, it allows 522 to choose the protection level through a change of configuration on 523 the secondary upstream PE, without requiring any reconfiguration of 524 all the downstream PEs. 526 6. Duplicate packets 528 Multicast VPN specifications [RFC6513] impose that a PE only forwards 529 to CEs the packets coming from the expected usptream PE 530 (Section 9.1). 532 We highlight the reader's attention to the fact that the respect of 533 this part of multicast VPN specifications is especially important 534 when two distinct upstream PEs are susceptible to forward the same 535 traffic on P-tunnels at the same time in steady state. This will be 536 the case when "hot root standby" mode is used (Section 4), and which 537 can also be the case if procedures of Section 3 are used and (a) the 538 rules determining the status of a tree are not the same on two 539 distinct downstream PEs or (b) the rule determining the status of a 540 tree depend on conditions local to a PE (e.g. the PE-P upstream link 541 being up). 543 7. IANA Considerations 545 Allocation is expected from IANA for the BGP "Standby PE" community. 546 (TBC) 548 [Note to RFC Editor: this section may be removed on publication as an 549 RFC.] 551 8. Security Considerations 553 9. Acknowledgements 555 The authors want to thank Greg Reaume and Eric Rosen for their review 556 and useful feedback. 558 10. References 560 10.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 566 "Extensions to Resource Reservation Protocol - Traffic 567 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 568 Switched Paths (LSPs)", RFC 4875, May 2007. 570 [RFC6513] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 571 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 572 MPLS/BGP IP VPNs", RFC 6513, February 2012. 574 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 575 Encodings and Procedures for Multicast in MPLS/BGP IP 576 VPNs", RFC 6514, February 2012. 578 10.2. Informative References 580 [I-D.ietf-mpls-mcast-cv] 581 Swallow, G., "Connectivity Verification for Multicast 582 Label Switched Paths", draft-ietf-mpls-mcast-cv-00 (work 583 in progress), April 2007. 585 [I-D.katz-ward-bfd-multipoint] 586 Katz, D. and D. Ward, "BFD for Multipoint Networks", 587 draft-katz-ward-bfd-multipoint-02 (work in progress), 588 February 2009. 590 [I-D.mofrr] 591 Karan, A., Filsfils, C., Farinacci, D., Decraene, B., 592 Leymann, N., and T. Telkamp, "Multicast only Fast Re- 593 Route", draft-ietf-rtgwg-mofrr-04 (work in progress), 594 November 2014. 596 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 597 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 598 2005. 600 Authors' Addresses 602 Thomas Morin (editor) 603 Orange 604 2, avenue Pierre Marzin 605 Lannion 22307 606 France 608 Email: thomas.morin@orange-ftgroup.com 610 Robert Kebler (editor) 611 Juniper Networks 612 1194 North Mathilda Ave. 613 Sunnyvale, CA 94089 614 U.S.A. 616 Email: rkebler@juniper.net 617 Yakov Rekhter 618 Juniper Networks 619 1194 North Mathilda Ave. 620 Sunnyvale, CA 94089 621 U.S.A. 623 Email: yakov@juniper.net 625 Ray (Lei) Qiu 626 Juniper Networks 627 1194 North Mathilda Ave. 628 Sunnyvale, CA 94089 629 U.S.A. 631 Email: rqiu@juniper.net 633 Rahul Aggarwal 634 Arktan 636 Email: raggarwa_1@yahoo.com 638 Wim Henderickx 639 Alcatel-Lucent 640 Copernicuslaan 50 641 Antwerp 2018 642 Belgium 644 Email: wim.henderickx@alcatel-lucent.com 646 Praveen Muley 647 Alcatel-Lucent 648 701 East Middlefield Rd 649 Mountain View, CA 94043 650 U.S.A. 652 Email: praveen.muley@alcatel-lucent.com