idnits 2.17.1 draft-ietf-bess-ir-03.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 == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC6513, updated by this document, for RFC5378 checks: 2005-06-01) -- 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 (April 11, 2016) is 2934 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-bess-mvpn-extranet-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 6513,6514 (if approved) K. Subramanian 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: October 13, 2016 Z. Zhang 7 Juniper Networks, Inc. 8 April 11, 2016 10 Ingress Replication Tunnels in Multicast VPN 11 draft-ietf-bess-ir-03 13 Abstract 15 RFCs 6513, 6514, and other RFCs describe procedures by which a 16 Service Provider may offer Multicast VPN service to its customers. 17 These procedures create point-to-multipoint (P2MP) or multipoint-to- 18 multipoint trees across the Service Provider's backbone. One type of 19 P2MP tree that may be used is known as an "Ingress Replication (IR) 20 tunnel". In an IR tunnel, a parent node need not be "directly 21 connected" to its child nodes. When a parent node has to send a 22 multicast data packet to its child nodes, it does not use layer 2 23 multicast, IP multicast, or MPLS multicast to do so. Rather, it 24 makes n individual copies, and then unicasts each copy, through an IP 25 or MPLS unicast tunnel, to exactly one child node. While the prior 26 MVPN specifications allow the use of IR tunnels, those specifications 27 are not always very clear or explicit about how the MVPN protocol 28 elements and procedures are applied to IR tunnels. This document 29 updates RFCs 6513 and 6514 by adding additional details that are 30 specific to the use of IR tunnels. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 13, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5 68 3. How are IR P-tunnels Identified? . . . . . . . . . . . . . . 7 69 4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 9 70 4.1. Advertised IR P-tunnels . . . . . . . . . . . . . . . . . 9 71 4.1.1. If the 'Leaf Info Required Bit' is Set . . . . . . . 9 72 4.1.2. If the 'Leaf Info Required Bit' is Not Set . . . . . 10 73 4.2. Unadvertised IR P-tunnels . . . . . . . . . . . . . . . . 11 74 5. The PTA's 'Tunnel Identifier' Field . . . . . . . . . . . . . 11 75 6. A Note on IR P-tunnels and 'Discarding Packets from the Wrong 76 PE' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 13 78 7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14 79 7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 15 80 7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17 81 8. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 17 82 9. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 18 83 10. Use of Timers when Switching UMH . . . . . . . . . . . . . . 19 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 14.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 RFCs 6513, 6514, and others describe procedures by which a Service 95 Provider (SP) may offer Multicast VPN (MVPN) service to its 96 customers. These procedures create point-to-multipoint (P2MP) or 97 multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels" 98 (Provider-tunnels), across the SP's backbone network. Customer 99 multicast traffic is carried through the P-tunnels. 101 A number of different P-tunnel technologies are supported. One of 102 the supported P-tunnel technologies is known as "ingress replication" 103 or "unicast replication". We will use the acronym "IR" to refer to 104 this P-tunnel technology. 106 An IR P-tunnel is a P2MP tree, but a given node on the tree is not 107 necessarily "directly attached" to its parent node or to its child 108 nodes. To send a multicast data packet from a parent node to one of 109 its child nodes, the parent node encapsulates the packet and then 110 unicasts it through a tunnel to the child node. The tunnel may be a 111 P2P (point-to-point) or MP2P (multipoint-to-point) MPLS LSP (label 112 switched path) or a unicast IP tunnel. If a node on an IR tree has n 113 child nodes, and has a multicast data packet that must be sent along 114 the tree, the parent node makes n individual copies of the data 115 packet, and then sends each copy, through a unicast tunnel, to 116 exactly one child node. No lower layer multicast technology is used 117 when sending traffic from a parent node to a child node; multiple 118 copies of the packet may therefore be sent out a single interface. 120 With the single exception of IR, the P-tunnel technologies supported 121 by the MVPN specifications are pre-existing IP multicast or MPLS 122 multicast technologies. Each such technology has its own set of 123 specifications, its own setup and maintenance protocols, its own 124 syntax for identifying specific multicast trees, and its own 125 procedures for enabling a router to be added to or removed from a 126 particular multicast tree. For IR P-tunnels, on the other hand, 127 there is no prior specification for setting up and maintaining the 128 P2MP trees; the procedures and protocol elements used for setting up 129 and maintaining the P2MP trees are specified in the MVPN 130 specifications themselves, and all the signaling/setup is done by 131 using the BGP A-D (Auto-Discovery) routes that are defined in 132 [RFC6514]. (The unicast tunnels used to transmit multicast data from 133 one node to another in an IR P-tunnel may of course have their own 134 setup and maintenance protocols, e.g., [RFC5036], [RFC3209].) 136 Since the transmission of a multicast data packet along an IR 137 P-tunnel is done by transmitting the packet through a unicast tunnel, 138 previous RFCs sometimes speak of an IR P-tunnel as "consisting of" a 139 set of unicast tunnels. However, that way of speaking is not quite 140 accurate. For one thing, it obscures the fact that an IR P-tunnel is 141 really a P2MP tree, whose nodes must maintain multicast state in both 142 the control and data planes. For another, it obscures the fact the 143 unicast tunnels used by a particular IR P-tunnel need not be specific 144 to that P-tunnel; a single unicast tunnel can carry the multicast 145 traffic of many different IR P-tunnels (and can also carry unicast 146 traffic as well). 148 In this document, we provide a clearer and more explicit conceptual 149 model for IR P-tunnels, clarifying the relationship between an IR 150 P-tunnel and the unicast tunnels that are used for data transmission 151 along the IR P-tunnel. 153 Section 5 of [RFC6514] defines a BGP Path Attribute known as the 154 "PMSI (Provider Multicast Service Interface) Tunnel attribute" (PTA). 155 This attribute contains a field known as the "Tunnel Identifier" 156 field. For most P-tunnel technologies, the PTA's "Tunnel Identifier" 157 field is used to identify a P-tunnel (i.e., to identify a P2MP or 158 MP2MP tree). However, when IR P-tunnels are used, the PTA "Tunnel 159 Identifier" field does not actually identify an IR P-tunnel. In some 160 cases it identifies one of the P-tunnel's constituent unicast 161 tunnels, and in other cases it is not used to identify a tunnel at 162 all. In this document, we provide an explicit specification for how 163 IR P-tunnels are actually identified. 165 Some of the MVPN specifications use phrases like "join the identified 166 P-tunnel", even though there has up to now not been an explicit 167 specification of how to identify an IR P-tunnel, of how a router 168 joins such a P-tunnel, or of how a router prunes itself from such a 169 P-tunnel. In this document, we make these procedures more explicit. 171 [RFC6514] does provide a method for binding an MPLS label to a 172 P-tunnel, but does not discuss the label allocation policies that are 173 needed for correct operation when the P-tunnel is an IR P-tunnel. 174 Those policies are discussed in this document. 176 This document does not provide any new protocol elements, or any 177 fundamentally new procedures; its purpose is to make explicit just 178 how a router is to use the protocol elements and procedures of 179 [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR 180 P-tunnel, and to prune itself from an IR P-tunnel. 182 This document also discusses the MPLS label allocation policies that 183 need to be supported when binding MPLS labels to IR P-tunnels, and 184 the timer policies that need to be supported when switching a 185 customer multicast flow from one IR P-tunnel to another. These are 186 procedures that are not clearly specified in [RFC6513] or [RFC6514]. 187 As the material in this document must be understood in order to 188 properly implement IR P-tunnels, this document is considered to 189 update [RFC6513] and [RFC6514]. 191 This document also discusses the application of "seamless multicast" 192 [RFC7524] and "extranet" [MVPN-XNET] procedures to IR P-tunnels. 194 This draft does not discuss the use of IR P-tunnels to support a VPN 195 customer's use of Bidirectional Protocol Independent Multicast 196 (BIDIR-PIM). [RFC7740] explains how to adapt the procedures of 197 [RFC6513], [RFC6514], and [RFC7582] so that a customer's use of 198 BIDIR-PIM can be supported by IR P-tunnels. 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL", when and only when appearing in all capital letters, are 203 to be interpreted as described in [RFC2119]. 205 2. What is an IR P-tunnel? 207 An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that 208 support the MVPN procedures of [RFC6514] and related RFCs. In 209 general, the nodes of an IR P-tunnel are either Provider Edge (PE) 210 routers, Autonomous System Border Routers (ASBRs), or (if [RFC7524] 211 is supported) Area Border Routers (ABRs). (MVPN procedures are 212 sometimes used to support non-MVPN, or "global table" multicast; one 213 way of doing this is defined in [RFC7524]. Another way is defined in 214 [RFC7716]. In such cases, IR P-tunnels can be used outside the 215 context of MVPN.) 217 MVPN P-tunnels may be either "segmented" or "non-segmented" (as these 218 terms are defined in [RFC6513] and [RFC6514]). 220 A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting 221 only of a root node and a set of nodes that are children of the root 222 node. When used in an MVPN context, the root is an ingress PE, and 223 the child nodes of the root are the egress PEs. 225 In a segmented P-tunnel, IR may be used for some or all of the 226 segments. If a particular segment of a segmented P-tunnel uses IR, 227 then the root of that segment may have child nodes that are ABRs or 228 ASBRs, rather than egress PEs. 230 As with any type of P2MP tree, each node of an IR P-tunnel holds 231 "multicast state" for the P-tunnel. That is, each node knows the 232 identity of its parent node on the tree, and each node knows the 233 identities of its child nodes on the tree. In the MVPN specs, the 234 "parent" node is also known as the "Upstream Multicast Hop" or "UMH". 235 Note that the "UMH" may be a PE, an ASBR, or (if procedures from 237 [RFC7524] are being used) an ABR. (In [RFC7524], the term "upstream 238 node" is used instead of "UMH".) 240 What distinguishes an IR P-tunnel from any other kind of P2MP tree is 241 the method by which a data packet is transmitted from a parent node 242 to a child node. To transmit a multicast data packet from a parent 243 node to a child node along a particular IR P-tunnel, the parent node 244 does the following: 246 o It labels the packet with a label (call it a "P-tunnel label") 247 that the child node has assigned to that P-tunnel, 249 o It then places the packet in a unicast encapsulation and unicasts 250 the packet to the child node. That is, the parent node sends the 251 packet through a "unicast tunnel" to a particular child node. 252 This unicast tunnel need not be specially created to be part of 253 the IR P-tunnel; it can be any P2P or MP2P unicast tunnel that 254 will get the packets from the parent node to the child node. A 255 single such unicast tunnel may be carrying multicast data packets 256 of several different P2MP trees, and may also be carrying unicast 257 data packets. 259 The parent node repeats this process for each child node, creating 260 one copy for each child node, and sending each copy through a unicast 261 tunnel to corresponding child node. It does not use layer 2 262 multicast, IP multicast, or MPLS multicast to transmit packets to its 263 child nodes. As a result, multiple copies of each packet may be sent 264 out a single interface; this may happen, e.g., if that interface is 265 the next hop interface, according to unicast routing, from the parent 266 node to several of the child nodes. 268 Since data traveling along an IR P-tunnel is always unicast from 269 parent node to child node, it can be convenient to think of an IR 270 P-tunnel as a P2MP tree whose arcs are unicast tunnels. However, it 271 is important to understand that the unicast tunnels need not be 272 specific to any particular IR P-tunnel. If R1 is the parent node of 273 R2 on two different IR P-tunnels, a single unicast tunnel from R1 to 274 R2 may be used to carry data along both IR P-tunnels. All that is 275 required is that when the data packets arrive at R2, R2 will see the 276 "P-tunnel label" at the top of the packets' label stack; R2's further 277 processing of the packets will depend upon that label. Note that the 278 same unicast tunnel between R1 and R2 may also be carrying unicast 279 data packets. 281 Typically the unicast tunnels are the Label Switched Paths (LSPs) 282 that already exist to carry unicast traffic; either MP2P LSPs created 283 by LDP (Label Distribution Protocol, [RFC5036]) or P2P LSPs created 284 by RSVP-TE (Resource Reservation Protocol - Traffic Engineering, 286 [RFC3209]). However, any other kind of unicast tunnel may be used. 287 A unicast tunnel may have an arbitrary number of intermediate 288 routers; those routers do not maintain any multicast state for the IR 289 P-tunnel, and in general are not even aware of its existence. 291 As with all other P-tunnel types, IR P-tunnels may be used as 292 Inclusive P-tunnels or as Selective P-tunnels. 294 3. How are IR P-tunnels Identified? 296 There are four MVPN BGP route types in which P-tunnels can be 297 identified: Intra-AS I-PMSI A-D (Intra Autonomous System Inclusive 298 PMSI A-D) routes, Inter-AS I-PMSI A-D routes, S-PMSI (Selective PMSI) 299 A-D routes, and Leaf A-D routes. (These route types are all defined 300 in [RFC6514]). 302 Whenever it is necessary to identify a P-tunnel in a route of one of 303 these types, a "PMSI Tunnel Attribute" (PTA) is added to the route. 304 As defined in [RFC6514] section 5, the PTA contains four fields: 305 "Tunnel Type", "MPLS Label", "Tunnel Identifier", and "Flags". 306 [RFC6514] defines only one bit in the "Flags" field, the "Leaf 307 Information Required" bit. 309 If a route identifies an IR P-tunnel, the "Tunnel Type" field of its 310 PTA is set to the value 6, meaning "Ingress Replication". 312 Most types of P-tunnel are associated with specific protocols that 313 are used to set up and maintain tunnels of that type. For example, 314 if the "Tunnel Type" field is set to 2, meaning "mLDP P2MP LSP", the 315 associated setup protocol is mLDP [RFC6388]. The associated setup 316 protocol always has a method of identifying the tunnels that it sets 317 up. For example, mLDP uses a "FEC element" (Forwarding Equivalence 318 Class Element) to identify a tree. If the "Tunnel type" field is set 319 to 3, meaning "PIM SSM Tree" (Protocol Independent Multicast Source- 320 Specific Tree), the associated setup protocol is PIM, and "(S,G)" is 321 used to identify the tree. In these cases, the "Tunnel Identifier" 322 field of the PTA carries a tree identifier as defined by the setup 323 protocol used for the particular tunnel type. 325 IR P-tunnels, on the other hand, are entirely setup and maintained by 326 the use of BGP A-D routes, and are not associated with any other 327 setup protocol. (The unicast tunnels used to transmit multicast data 328 along an IR P-tunnel may have their own setup and maintenance 329 protocols, of course.) The means of identifying a P-tunnel is very 330 different for IR P-tunnels than for other types of P-tunnel: 332 When an IR P-tunnel is identified in an S-PMSI A-D route, an 333 Intra-AS I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we 334 will refer to these three route types as "advertising A-D 335 routes"), its identifier is hereby defined to be the NLRI (Network 336 Layer Reachability Information) of that route. See sections 4.1, 337 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs. 338 Note that the IR P-tunnel identifier includes the "route type" and 339 "length" octets of the NLRI. 341 To reiterate: 343 The identifier of the IR P-tunnel does not appear in the PTA at 344 all; the "Tunnel Identifier" field of the PTA does not contain the 345 identifier of the IR P-tunnel. 347 Rather,the identifier of the IR P-tunnel appears in the "Network 348 Layer Reachability Information" (NLRI) field of the A-D routes 349 that are used to advertise and to setup the IR P-tunnel. 351 Note that an advertising A-D route is considered to identify an IR 352 P-tunnel only if it carries a PTA whose "Tunnel Type" field is set to 353 "IR". 355 When an IR P-tunnel is identified in an S-PMSI A-D route or in an 356 Inter-AS I-PMSI A-D route, the "Leaf Info Required" bit of the Flags 357 field of the PTA MUST be set. 359 In an advertising A-D route: 361 o If the "Leaf Info Required" bit of the Flags field of the PTA is 362 set, then the "Tunnel Identifier" field of the PTA has no 363 significance whatsoever, and MUST be ignored upon reception. 365 Note that, per RFC6514, the length of the "Tunnel Identifier" 366 field of the PTA is variable, and is inferred from the length of 367 the PTA. Even when this field is of no significance, its length 368 MUST be the length of an IP address in the address space of the 369 SP's backbone, as specified in section 4.2 of [RFC6515]. In this 370 case, it is RECOMMENDED that it be set to a routable address of 371 the router that constructed the PTA. (While it might make more 372 sense to allow or even require the field to be omitted entirely, 373 that might raise issues of backwards compatibility with 374 implementations that were designed prior to the publication of 375 this document.) 377 o If the "Leaf Info Required" bit is not set, the "Tunnel 378 Identifier" field of the PTA does have significance, but it does 379 not identify the IR P-tunnel. The use of the PTA's "Tunnel 380 Identifier" field in this case is discussed in Section 5 of this 381 document. 383 Note that according to the above definition, there is no way for two 384 different advertising A-D routes (i.e., two advertising A-D routes 385 with different NLRIs) to advertise the same IR P-tunnel. In the 386 terminology of [RFC6513], an IR P-tunnel can instantiate only a 387 single PMSI. If an ingress PE, for example, wants to bind two 388 customer multicast flows to a single IR P-tunnel, it must advertise 389 that IR P-tunnel either in an I-PMSI A-D route or in an S-PMSI A-D 390 route whose NLRI contains wildcards ([RFC6625]). 392 When an IR P-tunnel is identified in a Leaf A-D route, its identifier 393 is the "route key" field of the route's NLRI. See section 4.4 of 394 [RFC6514]. 396 A Leaf A-D route is considered to identify an IR P-tunnel only if it 397 carries a PTA whose "Tunnel Type" field is set to "IR". In this type 398 of route, the "Tunnel Identifier" field of the PTA does have 399 significance, but it does not identify the IR P-tunnel. The use of 400 the PTA's "Tunnel Identifier" field in this case is discussed in 401 Section 5. 403 4. How to Join an IR P-tunnel 405 The procedures for joining an IR P-tunnel depend upon whether the 406 P-tunnel has been previously advertised, and if so, upon how the 407 P-tunnel was advertised. Note that joining an unadvertised IR 408 P-tunnel is only possible when using the "Global Table Multicast" 409 procedures of [RFC7524]. 411 4.1. Advertised IR P-tunnels 413 The procedures in this section apply when the IR P-tunnel to be 414 joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI 415 A-D route, or an Intra-AS I-PMSI A-D route. 417 The procedures for joining an advertised IR P-tunnel depend upon 418 whether the A-D route that advertises the IR P-tunnel has the "Leaf 419 Info Required" bit set in its PTA. 421 4.1.1. If the 'Leaf Info Required Bit' is Set 423 The procedures in this section apply when the P-tunnel to be joined 424 has been advertised in a route whose PTA has the "Leaf Info Required 425 Bit" set. 427 The router joining a particular IR P-tunnel must determine its UMH 428 for that P-tunnel. If the route that advertised the IR P-tunnel 429 contains a P2MP Segmented Next Hop Extended Community, the UMH is 430 determined from the value of this community (see [RFC7524]). 432 Otherwise the UMH is determined from the route's next hop (see 433 [RFC6514]). 435 Once the UMH is determined, the router joining the IR P-tunnel 436 originates a Leaf A-D route. The NLRI of the Leaf A-D route is 437 formed following the procedures of [RFC6514]. As a result, the NLRI 438 of the Leaf A-D route will contain the IR P-tunnel identifier defined 439 in Section 3 above as its "route key". The UMH MUST be identified by 440 attaching an "IP Address Specific Route Target" (or an "IPv6 Address 441 Specific Route Target") to the Leaf A-D route. The IP address of the 442 UMH appears in the "global administrator" field of the Route Target 443 (RT). Details can be found in [RFC6514] and [RFC7524]. 445 The Leaf A-D route MUST also contain a PTA whose fields are set as 446 follows: 448 o The "Tunnel Type" field is set to "IR". 450 o The "Tunnel Identifier" field is set as described in Section 5 of 451 this document. (Note that this field does not contain the IR 452 P-tunnel Identifier that is defined in Section 3.) 454 o The "MPLS Label" field is set to a non-zero value. This is the 455 "P-tunnel label". The value must be chosen so as to satisfy 456 various constraints, as discussed in Section 7 this document. 458 4.1.2. If the 'Leaf Info Required Bit' is Not Set 460 The procedures in this section apply when the IR P-tunnel to be 461 joined has been advertised in a route whose PTA does not have the 462 "Leaf Info Required Bit" set. This can only be the case if the IR 463 P-tunnel was advertised in an Intra-AS I-PMSI A-D route. 465 If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes 466 originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can 467 be thought of as being instantiated by a set of IR P-tunnels. Each 468 PE is the root of one such IR P-tunnel, and the other PEs are 469 children of the root. A PE simultaneously joins all these P-tunnels 470 by originating (if it hasn't already done so) an Intra-AS I-PMSI A-D 471 route with a PTA whose fields are set as follows: 473 o The "Tunnel Type" field is set to "IR". 475 o The "Tunnel Identifier" field is set as described in Section 5 of 476 this document. (Note that this field does not contain the IR 477 P-tunnel Identifier that defined in Section 3.) 479 o The "MPLS Label" field MUST be set to a non-zero value. This 480 label value will be used by the child node to associate a received 481 packet with the I-PMSI of a particular MVPN. The MPLS label 482 allocation policy must be such as to ensure that the binding from 483 label to I-PMSI is one-to-one. 485 The NLRI and the RTs of the originated I-PMSI A-D route are set as 486 specified in [RFC6514]. 488 4.2. Unadvertised IR P-tunnels 490 In [RFC7524], a procedure is defined for "Global Table Multicast", in 491 which a P-tunnel can be joined even if the P-tunnel has not been 492 previously advertised. See the sections of that document entitled 493 "Leaf A-D Route for Global Table Multicast" and "Constructing the 494 Rest of the Leaf A-D Route". The route key of the Leaf A-D route has 495 the form of the "S-PMSI Route-Type Specific NLRI" in this case, and 496 that should be considered to be the IR P-tunnel identifier. Note 497 that the procedure for finding the UMH is different in this case; the 498 UMH is the next hop of the best UMH-eligible route towards the 499 "ingress PE". See the section of that document entitled "Determining 500 the Upstream ABR/PE/ASBR (Upstream Node)". 502 5. The PTA's 'Tunnel Identifier' Field 504 As previously specified, when the "Tunnel Type" field of a PTA is set 505 to "IR", the "Tunnel Identifier" field of that PTA does not contain 506 the IR P-tunnel identifier. This section specifies the procedures 507 for setting the "Tunnel Identifier" field of the PTA when the "Tunnel 508 Type" field of the PTA is set to "IR". 510 If the "Tunnel Type" field of a PTA is set to "IR", its "Tunnel 511 Identifier" field is significant only when one of the following two 512 conditions holds: 514 o The PTA is carried by a Leaf A-D route, or 516 o The "Leaf Information Required" bit of the "Flags" field of the 517 PTA is not set. 519 If one of these conditions holds, then the "Tunnel Identifier" field 520 must contain a routable IP address of the originator of the route. 521 (See [RFC6514] sections 9.2.3.2.1 and 9.2.3.4.1 for the detailed 522 specification of the contents of this field.) This address is used 523 by the UMH to determine the unicast tunnel that it will use in order 524 to send data, along the IR P-tunnel identified by the route key, to 525 the originator of the Leaf A-D route. 527 The means by which the unicast tunnel is determined from this IP 528 address is outside the scope of this document. The means by which 529 the unicast tunnel is set up and maintained is also outside the scope 530 of this document. 532 Section 4 of [RFC6515] MUST be applied when a PTA is carried in a 533 Leaf A-D route, and describes how to determine whether the "Tunnel 534 Identifier" field carries an IPv4 or an IPv6 address. 536 If neither of the above conditions hold, then the "Tunnel Identifier" 537 field is of no significance, and MUST be ignored upon reception. 539 6. A Note on IR P-tunnels and 'Discarding Packets from the Wrong PE' 541 Section 9.1.1 of [RFC6513] specifies a procedure known as "Discarding 542 Packets from the Wrong PE". When an egress PE receives a multicast 543 data packet, this procedure requires it to determine the packet's 544 ingress PE. 546 In this document, we assume that when a packet has reached an egress 547 PE via an IR P-tunnel, the egress PE will infer the identity of the 548 packet's ingress PE by examining the packet's P-tunnel label. 550 Section 7 specifies certain constraints on the way in which the 551 P-tunnel label is allocated for a given P-tunnel. In general, if 552 these constraints are followed, an egress PE will be able to infer 553 the identity of a packet's ingress PE from the P-tunnel label, and 554 hence will be able to apply the procedures of Section 9.1.1 of 555 [RFC6513]. This method of identifying a packet's ingress PE works 556 exactly the same when the unicast tunnels are IP tunnels as it does 557 when the unicast tunnels are MPLS LSPs. 559 However, if the egress PE joined a particular IR P-tunnel using the 560 procedures of Section 4.1.2, then when the egress PE receives a 561 packet through that P-tunnel, it will not be able to infer the 562 identity of the packet's ingress PE from the P-tunnel label, and thus 563 will not be able to apply the procedures of Section 9.1.1 of 564 [RFC6513]. 566 One might think that if a particular IR P-tunnel uses IP unicast 567 tunnels rather than MPLS LSPs, an egress PE could identify the 568 ingress PE by inspecting the IP source address field of the 569 encapsulating IP header. However, there are several reasons why this 570 procedure is not desirable: 572 o When segmented P-tunnels are being used, the IP source address 573 field of the encapsulating IP header might not contain the address 574 of the ingress PE. 576 o Even if the IP source address field of the encapsulating IP header 577 does identify the ingress PE, there is no guarantee that the IP 578 source address in that header is the same as the IP address used 579 by the ingress PE for the MVPN signaling procedures. 581 o To apply the procedures of Section 9.1.1 of [RFC6513] when 582 extranet functionality [MVPN-XNET] is supported, it is necessary 583 to infer a packet's ingress VRF (Virtual Routing and Forwarding 584 table), not merely its ingress PE. This can be inferred from the 585 P-tunnel label (assuming that the label is allocated following the 586 procedures of Section 7), but can not be inferred from the IP 587 source address of the encapsulating IP header. 589 We therefore assume in this document that if the procedures of 590 Section 9.1.1 of [RFC6513] are to be applied to packets traveling 591 through IR P-tunnels, those procedures will be based on the P-tunnel 592 label, even if the IR P-tunnel is using IP unicast tunnels. 594 This means that if an egress PE joined a particular IR P-tunnel using 595 the procedures of Section 4.1.2, duplicate prevention on that IR 596 P-tunnel requires the use of either Single Forwarder Selection 597 ([RFC6513] section 9.1.2) or native PIM procedures ([RFC6513] section 598 9.1.3). 600 7. The PTA's 'MPLS Label' Field 602 When the "Tunnel Type" field of a PTA is set to "IR", the "MPLS 603 Label" field is not always significant. It is significant only under 604 the following conditions: 606 1. Either the PTA is being carried in a Leaf A-D route, or 608 2. the "Leaf Information Required" flag of the PTA is NOT set. 610 Note that the "Leaf Information Required" flag of the PTA is always 611 set when a PTA specifying an IR P-tunnel is carried in an S-PMSI A-D 612 route or in an Inter-AS I-PMSI A-D route; thus the "MPLS Label" field 613 of the PTA is never significant when the PTA is carried by one of 614 these route types. The "MPLS Label" field is significant only when 615 the PTA appears either in a Leaf A-D route or in an Intra-AS I-PMSI 616 A-D route that does not have the "Leaf Information Required" bit set. 617 In these cases, the MPLS label is the label that the originator of 618 the route is assigning to the IR P-tunnel(s) identified by the 619 route's NLRI. (That is, the MPLS label assigned in the PTA is what 620 we have called the "P-tunnel label".) 621 In those cases where the "MPLS Label" field is not significant, it 622 SHOULD be set to zero upon transmission and MUST be ignored upon 623 reception. 625 7.1. Leaf A-D Route Originated by an Egress PE 627 As previously stated, when a Leaf A-D route is used to join an IR 628 P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel 629 identifier. 631 We now define the notion of the "root of an IR P-tunnel". 633 o If the identifier of an IR P-tunnel is of the form of an S-PMSI 634 NLRI, the "root" of the IR P-tunnel is the router identified in 635 the "Originating Router's IP Address" field of that NLRI. 637 o If the identifier of an IR P-tunnel is of the form specified in 638 Section "Leaf A-D Route for Global Table Multicast" of [RFC7524], 639 the "root" of the IR P-tunnel is the router identified in the 640 "Ingress PE's IP Address" field of that NLRI. 642 o If the identifier of an IR P-tunnel is of the form of an Intra-AS 643 I-PMSI NLRI, the "root" of the IR P-tunnel is the router 644 identified in the "Originating Router's IP Address" field of that 645 NLRI. 647 o If the identifier of an IR P-tunnel is of the form of an Inter-AS 648 I-PMSI NLRI, the "root" of the IR P-tunnel is same as the 649 identifier of the IR P-tunnel, i.e., the combination of an RD and 650 an AS. 652 Note that if an IR P-tunnel is segmented, the root of the IR 653 P-tunnel, by this definition, is actually the root of the entire 654 P-tunnel, not the root of the local segment. In this case, there may 655 be segments upstream that are not themselves IR P-tunnels. However, 656 the egress PE is aware only of the final segment of the P-tunnel, and 657 hence considers the P-tunnel to be an IR P-tunnel. 659 In order to apply the procedures of RFC 6513 Section 9.1.1 660 ("Discarding Packets from Wrong PE"), the following condition MUST be 661 met by the MPLS label allocation policy: 663 Suppose an egress PE originates two Leaf A-D routes, each with a 664 different route key in its NLRI, and each with a PTA specifying a 665 "Tunnel Type" of "IR". Thus each of the Leaf A-D routes 666 identifies a different IR P-tunnel. Suppose further that each of 667 those IR P-tunnels has a different root. Then the egress PE MUST 668 NOT specify the same MPLS label in both PMSI Tunnel attributes. 670 That is, to apply the "Discarding Packets from the Wrong PE" 671 duplicate prevention procedures ([RFC6513] section 9.1.1), the same 672 MPLS label MUST NOT be assigned to two IR P-tunnels that have 673 different roots. 675 If segmented P-tunnels are in use, the above rule is necessary but 676 not sufficient to prevent a PE from forwarding duplicate data to the 677 CEs. For various reasons, a given egress PE or egress ABR or egress 678 ASBR may decide to change its parent node, on a given segmented 679 P-tunnel, from one router to another. It does this by changing the 680 RT of the Leaf A-D route that it originated in order to join that 681 P-tunnel. Once the RT is changed, there may be a period of time 682 during which the old parent node and the new parent node are both 683 sending data of the same multicast flow. To ensure that the egress 684 node not forward duplicate data, whenever the egress node changes the 685 RT that it attaches to a Leaf A-D route, it MUST also change the 686 "MPLS Label" specified in the Leaf A-D route's PTA. This allows the 687 egress router to distinguish between packets arriving on a given 688 P-tunnel from the old parent and packets arriving on that same 689 P-tunnel from the new parent. At any given time, a router MUST 690 consider itself to have only a single parent node on a given 691 P-tunnel, and MUST discard traffic that arrives on that P-tunnel from 692 a different parent node. 694 If extranet functionality [MVPN-XNET] is not implemented in a 695 particular egress PE, or if an egress PE is provisioned with the 696 knowledge that extranet functionality is not needed, the PE may adopt 697 the policy of assigning a label that is unique for the ordered triple 698 . This will enable the egress PE to 699 apply the duplicate prevention procedures discussed above, and to 700 determine the VRF to which an arriving packet must be directed. 702 However, this policy is not sufficient to support the "Discard 703 Packets from the Wrong P-tunnel" procedures that are specified in 704 [MVPN-XNET]. To support those procedures, the labels specified in 705 the PTA of Leaf A-D routes originated by a given egress PE MUST be 706 unique for the ordered triple , where the 707 "root RD" is taken from the RD field of the IR P-tunnel identifier. 708 (All forms of IR P-tunnel identifier contain an embedded "RD" field.) 709 This policy is also sufficient for supporting non-extranet cases, but 710 in some cases may result in the use of more labels than the policy of 711 the previous paragraph. 713 7.2. Leaf A-D Route Originated by an Intermediate Node 715 When a P-tunnel is segmented, there will be "intermediate nodes", 716 i.e., nodes that have a parent and also have children on the 717 P-tunnel. Each intermediate node is a leaf node of an "upstream 718 segment" and a parent node of one or more "downstream segments". The 719 intermediate node needs to set up its forwarding state so that data 720 it receives on the upstream segment gets transmitted on the proper 721 downstream segments. 723 If the upstream segment is instantiated by IR, the intermediate node 724 will need to originate a Leaf A-D route to join that segment, and 725 will need to allocate a downstream-assigned MPLS label to advertise 726 in the MPLS label field of the Leaf A-D route's PTA. Section 7.1 727 specifies constraints on the label allocation policy for egress PEs; 728 this section specifies constraints on the label allocation policy for 729 intermediate nodes. 731 Suppose intermediate node N originates two Leaf A-D routes, one whose 732 route key is K1, and one whose route key is K2, where K1 != K2. The 733 respective PTAs of these Leaf A-D routes MUST specify distinct non- 734 zero MPLS labels, UNLESS the following conditions all hold: 736 1. N's parent node for P-tunnel K1 is the same as N's parent node 737 for P-tunnel K2. 739 2. N's forwarding state is such that any packet it receives from 740 P-tunnel K1 is forwarded to the exact same set of downstream 741 neighbors as any packet it receives from P-tunnel K2. 743 3. For each downstream neighbor D to which N sends the packets it 744 receives from P-tunnels K1 and K2, N's forwarding state is such 745 that it applies the exact same encapsulation to packets it 746 forwards from either tunnel to D. (E.g., if N uses MPLS to 747 forward the packets to D, it pushes the exact same set of labels 748 on packets from P-tunnel K1 as it pushes on packets from P-tunnel 749 K2.) 751 Of course, N MAY always specify distinct non-zero labels in each of 752 the Leaf A-D routes that it originates. 754 Note that the rules of this section apply whenever the upstream 755 P-tunnel segment is an IR P-tunnel. These rules hold whether or not 756 some or all of the downstream segments are other types of P-tunnels. 758 If the P-tunnels from N to a particular downstream neighbor D are IR 759 P-tunnels, then condition 3 above will hold with respect to D only if 760 the following conditions all hold as well: 762 o N has received and installed a Leaf A-D route from D, whose route 763 key is K1, and which carries an IP-address-specific RT identifying 764 N, 766 o N has received and installed a Leaf A-D route from D, whose route 767 key is K2, and which carries an IP-address-specific RT identifying 768 N, 770 o Those two Leaf A-D routes specify the same MPLS label in their 771 respective PTAs. 773 7.3. Intra-AS I-PMSI A-D Route 775 When a router joins a set of IR P-tunnels using the procedures of 776 Section 4.1.2 of this document, the procedures of section 9.1.1 of 777 [RFC6513] cannot be applied, no matter what the label allocation 778 policy is. In this case, the ingress PE is the same as the UMH, but 779 it is not possible to assign a label uniquely to a particular ingress 780 PE or UMH. However, the label in the MPLS label field of the PTA 781 MUST NOT appear in the MPLS label field of the PTA carried by any 782 other route originated by the same router. 784 8. How A Child Node Prunes Itself from an IR P-tunnel 786 If a particular IR P-tunnel was joined via the procedures of 787 Section 4.1.2 of this document, a router can prune itself from the 788 P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join 789 the P-tunnel. This is not usually done unless the router is removing 790 itself entirely from a particular MVPN. 792 The procedures in the remainder of this section apply when a router 793 joined a particular IR P-tunnel by originating a Leaf A-D route (as 794 described in Section 4.1.1 or Section 4.2 of this document). 796 If a router no longer has a need to receive any multicast data from a 797 given IR P-tunnel, it may prune itself from the P-tunnel by 798 withdrawing the Leaf A-D route it used to join the tunnel. This is 799 done, e.g., if the router no longer needs any of the flows traveling 800 over the P-tunnel, or if all the flows the router does need are being 801 received over other P-tunnels. 803 A router that is attached to a particular IR P-tunnel via a 804 particular parent node may determine that it needs to stay joined to 805 that IR P-tunnel, but via a different parent node. This can happen, 806 for example, if there is a change in the Next Hop or the P2MP 807 Segmented Next Hop Extended Community of the S-PMSI A-D route in 808 which that P-tunnel was advertised. In this case, the router changes 809 the Route Target of the Leaf A-D route it used to join the IR 810 P-tunnel, so that the Route Target now identifies the new parent 811 node. 813 A parent node must notice when a child node has been pruned from a 814 particular tree, as this will affect the parent node's multicast data 815 state. Note that the pruning of a child node may appear to the 816 parent node as the explicit withdrawal of a Leaf A-D route, or it may 817 appear as a change in the Route Target of a Leaf A-D route. If the 818 Route Target of a particular Leaf A-D route previously identified a 819 particular parent node, but changes so that it no longer does so, the 820 effect on the multicast state of the parent node is the same as if 821 the Leaf A-D route had been explicitly withdrawn. 823 9. Parent Node Actions Upon Receiving Leaf A-D Route 825 These actions are detailed in [RFC6514] and [RFC7524]. Two points of 826 clarification are made: 828 o If a router R1 receives and installs a Leaf A-D route originated 829 by router R2, R1's multicast state is affected only if the Leaf 830 A-D route carries an "IP Address Specific RT" (or "IPv6 Address 831 Specific RT") whose "global administrator" field identifies R1. 833 (This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D 834 route's RT does not identify R1, but then changes so that it does 835 identify R1, R1 must take the same actions it would take if the 836 Leaf A-D route were newly received. 838 o It is possible that router R1 will receive and install a Leaf A-D 839 route originated by router R2, where: 841 * the route's RT identifies R1, 843 * the route's NLRI contains a route key whose first octet 844 indicates that it is identifying a P-tunnel advertised in an 845 S-PMSI A-D route, 847 * R1 has neither originated nor installed any such S-PMSI A-D 848 route. 850 If at some later time, R1 installs the corresponding S-PMSI A-D 851 route, and the Leaf A-D route is still installed, and the Leaf A-D 852 route's RT still identifies R1, then R1 MUST follow the same 853 procedures it would have followed if the S-PMSI A-D route had been 854 installed before the Leaf A-D route was installed. (I.e., 855 implementers must not assume that events occur in the "usual" or 856 "expected" order.) 858 10. Use of Timers when Switching UMH 860 Consider a child node that has joined a particular IR P-tunnel via a 861 particular UMH. To do so, it will have originated a Leaf A-D route 862 with an RT that identifies the UMH. Suppose the child node now 863 determines (for whatever reason) that it needs to change its UMH for 864 that P-tunnel. It does this by: 866 o modifying the RT of the Leaf A-D route, so that the RT now 867 identifies the new parent rather than the old one, and by 869 o modifying the PTA of the Leaf A-D route, changing the MPLS Label 870 field as discussed in Section 7. 872 Note that, in accordance with the procedures of [RFC6514] and of 873 Section 4 of this document, the NLRI of the Leaf A-D route is not 874 modified; only the RT and the PTA are changed. 876 It is desirable for such a "switch of UMH" to be done using a "make 877 before break" technique, so that the old UMH does not stop 878 transmitting packets of the given P-tunnel to the child until the new 879 UMH has a chance to start transmitting packets of the given P-tunnel 880 to the child. However, the control plane operation (i.e., modifying 881 the RT and PTA of the Leaf A-D route) does not permit the child node 882 to first join the IR P-tunnel via the new UMH, and then later prune 883 itself from the old UMH. Rather, a single control plane operation 884 has both effects. 886 Therefore, the old UMH MUST continue transmitting to the child node 887 for a period of time after it sees the child's Leaf A-D route being 888 withdrawn (or its RT changing to identify a different UMH). This 889 timer (the "parent-continues" timer) SHOULD have a default value of 890 60 seconds, and SHOULD be configurable. 892 By the procedures of Section 7, the child node will have advertised a 893 different label for the IR P-tunnel to the new UMH than it had 894 advertised to the old UMH. This allows it to distinguish the packets 895 of that IR P-tunnel transmitted by the new UMH from packets of that 896 IR P-tunnel transmitted by the old UMH. At any given time, the child 897 node will accept packets of that IR P-tunnel from only one parent 898 node, and will discard packets of that IR P-tunnel that are received 899 from the other. To achieve "make before break" functionality, the 900 child node needs to continue to accept packets from the old UMH for a 901 period of time. After this period, it will discard any packets from 902 the given IR P-tunnel that it receives from the old UMH, and will 903 only accept such packets from the new UMH. 905 Once the child node modifies the RT of its Leaf A-D route, it MUST 906 run a timer (the "switch-parents-delay" timer). This timer SHOULD 907 default to 30 seconds, and SHOULD be configurable. The child node 908 MUST continue to accept packets of the given IR P-tunnel from the old 909 UMH until the timer expires. However, once the child node receives a 910 packet of the given IR P-tunnel from the new UMH, it MAY consider the 911 switch-parents-delay timer to have expired. 913 The "parent-continues" timer MUST be longer than the "switch-parents- 914 delay" timer. Note that both timers are specific to a given IR 915 P-tunnel. 917 11. IANA Considerations 919 This document contains no actions for IANA. 921 12. Acknowledgments 923 The authors wish to thank Yakov Rekhter for his contributions to this 924 work. We also wish to thank Huajin Jeng and Samir Saad for their 925 contributions, and to thank Thomas Morin for pointing out (both 926 before and after the document was written) some of the issues that 927 needed further elaboration. We also thank Lucy Yong for her review 928 and comments. 930 Section 7.1 discusses the importance of having an MPLS label 931 allocation policy that, when ingress replication is used, allows an 932 egress PE to infer the identity of a received packet's ingress PE. 933 This issue was first raised in earlier work by Xu Xiaohu. 935 13. Security Considerations 937 No security considerations are raised by this document beyond those 938 already discussed in [RFC6513] and [RFC6514]. 940 14. References 942 14.1. Normative References 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, 946 DOI 10.17487/RFC2119, March 1997, 947 . 949 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 950 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 951 2012, . 953 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 954 Encodings and Procedures for Multicast in MPLS/BGP IP 955 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 956 . 958 [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure 959 Addresses in BGP Updates for Multicast VPN", RFC 6515, 960 DOI 10.17487/RFC6515, February 2012, 961 . 963 14.2. Informative References 965 [MVPN-XNET] 966 Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. 967 Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet- 968 draft draft-ietf-bess-mvpn-extranet-06, January 2016. 970 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 971 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 972 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 973 . 975 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 976 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 977 October 2007, . 979 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 980 Thomas, "Label Distribution Protocol Extensions for Point- 981 to-Multipoint and Multipoint-to-Multipoint Label Switched 982 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 983 . 985 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 986 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 987 RFC 6625, DOI 10.17487/RFC6625, May 2012, 988 . 990 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 991 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 992 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 993 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 994 . 996 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 997 "Multicast Virtual Private Network (MVPN): Using 998 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 999 July 2015, . 1001 [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., 1002 and D. Pacella, "Global Table Multicast with BGP Multicast 1003 VPN (BGP-MVPN) Procedures", RFC 7716, 1004 DOI 10.17487/RFC7716, December 2015, 1005 . 1007 [RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating 1008 Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider 1009 Tunnels with Ingress Replication", RFC 7740, 1010 DOI 10.17487/RFC7740, January 2016, 1011 . 1013 Authors' Addresses 1015 Eric C. Rosen (editor) 1016 Juniper Networks, Inc. 1017 10 Technology Park Drive 1018 Westford, Massachusetts 01886 1019 United States 1021 Email: erosen@juniper.net 1023 Karthik Subramanian 1024 Cisco Systems, Inc. 1025 170 Tasman Drive 1026 San Jose, California 95134 1027 United States 1029 Email: kartsubr@cisco.com 1031 Zhaohui Zhang 1032 Juniper Networks, Inc. 1033 10 Technology Park Drive 1034 Westford, Massachusetts 01886 1035 United States 1037 Email: zzhang@juniper.net