idnits 2.17.1 draft-rosen-l3vpn-ir-01.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 abstract seems to indicate that this document updates RFC6514, but the header doesn't have an 'Updates:' line to match this. 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, 2014) is 3658 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 (-01) exists of draft-ietf-l3vpn-mvpn-bidir-ingress-replication-00 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-mvpn-bidir-07 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-seamless-mcast-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Eric C. Rosen 3 Internet Draft Karthik Subramanian 4 Intended Status: Standards Track Cisco Systems, Inc. 5 Updates: 6513,6514 6 Expires: October 11, 2014 Jeffrey Zhang 7 Juniper Networks, Inc. 9 April 11, 2014 11 Ingress Replication Tunnels in Multicast VPN 13 draft-rosen-l3vpn-ir-01.txt 15 Abstract 17 RFCs 6513, 6514, and other RFCs describe procedures by which a 18 Service Provider may offer Multicast VPN service to its customers. 19 These procedures create point-to-multipoint (P2MP) or multipoint-to- 20 multipoint trees across the Service Provider's backbone. One type of 21 P2MP tree that may be used is known as an "Ingress Replication (IR) 22 tunnel". In an IR tunnel, a parent node need not be "directly 23 connected" to its child nodes. When a parent node has to send a 24 multicast data packet to its child nodes, it does not use layer 2 25 multicast, IP multicast, or MPLS multicast to do so. Rather, it 26 makes n individual copies, and then unicasts each copy, through an IP 27 or MPLS unicast tunnel, to exactly one child node. While the prior 28 MVPN specifications allow the use of IR tunnels, those specifications 29 are not always very clear or explicit about how the MVPN protocol 30 elements and procedures are applied to IR tunnels. This document 31 updates RFCs 6513 and 6514 by adding additional details that are 32 specific to the use of IR tunnels. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Copyright and License Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1 Introduction .......................................... 4 73 2 What is an IR P-tunnel? ............................... 6 74 3 How are IR P-tunnels Identified? ...................... 8 75 4 How to Join an IR P-tunnel ............................ 10 76 4.1 Advertised P-tunnels .................................. 10 77 4.1.1 If the 'Leaf Info Required Bit' is Set ................ 10 78 4.1.2 If the 'Leaf Info Required Bit' is Not Set ............ 11 79 4.2 Unadvertised P-tunnels ................................ 12 80 5 The PTA's 'Tunnel Identifier' Field ................... 12 81 6 The PTA's 'MPLS Label' Field .......................... 13 82 6.1 Leaf A-D Route Originated by an Egress PE ............. 13 83 6.2 Leaf A-D Route Originated by an Intermediate Node ..... 15 84 6.2.1 Upstream and Downstream Segments are IR Segments ...... 15 85 6.2.2 Only One Segment is IR ................................ 16 86 6.3 Intra-AS I-PMSI A-D Route ............................. 16 87 7 How A Child Node Prunes Itself from an IR P-tunnel .... 17 88 8 Parent Node Actions Upon Receiving Leaf A-D Route ..... 17 89 9 Use of Timers when Switching UMH ...................... 18 90 10 IANA Considerations ................................... 19 91 11 Acknowledgments ....................................... 19 92 12 Security Considerations ............................... 19 93 13 Authors' Addresses .................................... 19 94 14 Normative References .................................. 20 95 15 Informational References .............................. 20 96 1. Introduction 98 RFCs 6513, 6514, and others describe procedures by which a Service 99 Provider (SP) may offer Multicast VPN (MVPN) service to its 100 customers. These procedures create point-to-multipoint (P2MP) or 101 multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels" 102 (Provider-tunnels), across the SP's backbone network. Customer 103 multicast traffic is carried through the P-tunnels. 105 A number of different P-tunnel technologies are supported. One of 106 the supported P-tunnel technologies is known as "ingress replication" 107 or "unicast replication". We will use the acronym "IR" to refer to 108 this P-tunnel technology. 110 An IR P-tunnel is a P2MP tree, but a given node on the tree is not 111 necessarily "directly attached" to its parent node or to its child 112 nodes. To send a multicast data packet from a parent node to one of 113 its child nodes, the parent node encapsulates the packet and then 114 unicasts it (through a P2P or MP2P MPLS LSP or a unicast IP tunnel) 115 to the child node. If a node on an IR tree has n child nodes, and has 116 a multicast data packet that must be sent along the tree, the parent 117 node makes n individual copies of the data packet, and then sends 118 each copy, through a unicast tunnel, to exactly one child node. No 119 lower layer multicast technology is used when sending traffic from a 120 parent node to a child node; multiple copies of the packet may 121 therefore be sent out a single interface. 123 With the single exception of IR, the P-tunnel technologies supported 124 by the MVPN specifications are pre-existing IP multicast or MPLS 125 multicast technologies. Each such technology has its own set of 126 specifications, its own setup and maintenance protocols, its own 127 syntax for identifying specific multicast trees, and its own 128 procedures for enabling a router to be added to or removed from a 129 particular multicast tree. For IR P-tunnels, on the other hand, 130 there is no prior specification for setting up and maintaining the 131 P2MP trees; the procedures and protocol elements used for setting up 132 and maintaining the P2MP trees are specified in the MVPN 133 specifications themselves, and all the signaling/setup is done by 134 using the BGP A-D (Auto-Discovery) routes that are defined in [MVPN- 135 BGP]. (The unicast tunnels used to transmit multicast data from one 136 node to another in an IR P-tunnel may of course have their own setup 137 and maintenance protocols, e.g., [LDP], [RSVP-TE].) 139 Since the transmission of a multicast data packet along an IR P- 140 tunnel is done by transmitting the packet through a unicast tunnel, 141 previous RFCs sometimes speak of an IR P-tunnel as "consisting of" a 142 set of unicast tunnels. However, that way of speaking is not quite 143 accurate. For one thing, it obscures the fact that an IR P-tunnel is 144 really a P2MP tree, whose nodes must maintain multicast state in both 145 the control and data planes. For another, it obscures the fact the 146 unicast tunnels used by a particular IR P-tunnel need not be specific 147 to that P-tunnel; a single unicast tunnel can carry the multicast 148 traffic of many different IR P-tunnels (and can also carry unicast 149 traffic as well). 151 In this document, we provide a clearer and more explicit conceptual 152 model for IR P-tunnels, clarifying the relationship between an IR P- 153 tunnel and the unicast tunnels that are used for data transmission 154 along the IR P-tunnel. 156 RFC 6514 defines a protocol element called a "tunnel identifier", 157 which for most P-tunnel technologies is used to identify a P-tunnel 158 (i.e., to identify a P2MP or MP2MP tree). However, when IR P-tunnels 159 are used, this protocol element does not identify an IR P-tunnel. In 160 some 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 route joins 168 such a P-tunnel, or of how a router prunes itself from such a P- 169 tunnel. In this document, we make these procedures more explicit. 171 RFC 6514 does provide a method for binding an MPLS label to a P- 172 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 177 procedures; rather it makes explicit just how a router is to use the 178 protocol elements and procedures of [MVPN] and [MVPN-BGP] to identify 179 an IR P-tunnel, to join an IR P-tunnel, and to prune itself from an 180 IR P-tunnel. This document also discusses the MPLS label allocation 181 policies that need to be supported when binding MPLS labels to IR P- 182 tunnels, and the timer policies that need to be supported when 183 switching a customer multicast flow from one P-tunnel to another. As 184 the material in this document must be understood in order to properly 185 implement IR P-tunnels, this document is considered to update [MVPN] 186 and [MVPN-BGP]. This document also discusses the application of 187 "seamless multicast" [SMLS-MC] and "extranet" [MVPN-XNET] procedures 188 to IR P-tunnels. 190 This draft does not discuss the use of IR P-tunnels to support a VPN 191 customer's use of BIDIR-PIM. [C-BIDIR-IR] explains how to adapt the 192 procedures of [MVPN], [MVPN-BGP], and [MVPN-BIDIR] so that a 193 customer's use of BIDIR-PIM can be supported by IR P-tunnels. 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 197 "OPTIONAL", when and only when appearing in all capital letters, are 198 to be interpreted as described in [RFC2119]. 200 2. What is an IR P-tunnel? 202 An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that 203 support the MVPN procedures of [MVPN-BGP] and related RFCs. In 204 general, the nodes of an IR P-tunnel are either PE routers, ASBRs, or 205 (if [SMLS-MC] is supported) ABRs. (MVPN procedures are sometimes 206 used to support non-MVPN, or "global table" multicast; one way of 207 doing this is defined in [SMLS-MC]. In such a case, IR P-tunnels can 208 be used outside the context of MVPN.) 210 MVPN P-tunnels may be either "segmented" or "non-segmented" (as these 211 terms are defined in [MVPN] and [MVPN-BGP]). 213 A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting 214 only of a root node and a set of nodes that are children of the root 215 node. When used in an MVPN context, the root is an ingress PE, and 216 the child nodes of the root are the egress PEs. 218 In a segmented P-tunnel, IR may be used for some or all of the 219 segments. If a particular segment of a segmented P-tunnel uses IR, 220 then the root of that segment may have child nodes that are ABRs or 221 ASBRs, rather than egress PEs. 223 As with any type of P2MP tree, each node of an IR P-tunnel holds 224 "multicast state" for the P-tunnel. That is, each node knows the 225 identity of its parent node on the tree, and each node knows the 226 identities of its child nodes on the tree. In the MVPN specs, the 227 "parent" node is also known as the "Upstream Multicast Hop" or "UMH". 229 What distinguishes an IR P-tunnel from any other kind of P2MP tree is 230 the method by which a data packet is transmitted from a parent node 231 to a child node. To transmit a multicast data packet from a parent 232 node to a child node along a particular IR P-tunnel, the parent node 233 does the following: 235 - It labels the packet with a label (call it a "P-tunnel label") 236 that the child node has assigned to that P-tunnel, 238 - It then places the packet in a unicast encapsulation and unicasts 239 the packet to the child node. That is, the parent node sends the 240 packet through a "unicast tunnel" to a particular child node. 241 This unicast tunnel need not be specially created to be part of 242 the IR P-tunnel; it can be any P2P or MP2P unicast tunnel that 243 will get the packets from the parent node to the child node. A 244 single such unicast tunnel may be carrying multicast data packets 245 of several different P2MP trees, and may also be carrying unicast 246 data packets. 248 The parent node repeats this process for each child node, creating 249 one copy for each child node, and sending each copy through a unicast 250 tunnel to corresponding child node. It does not use layer 2 251 multicast, IP multicast, or MPLS multicast to transmit packets to its 252 child nodes. As a result, multiple copies of each packet may be sent 253 out a single interface; this may happen, e.g., if that interface is 254 the next hop interface, according to unicast routing, from the parent 255 node to several of the child nodes. 257 Since data traveling along an IR P-tunnel is always unicast from 258 parent node to child node, it can be convenient to think of an IR P- 259 tunnel as a P2MP tree whose arcs are unicast tunnels. However, it is 260 important to understand that the unicast tunnels need not be specific 261 to any particular IR P-tunnel. If R1 is the parent node of R2 on two 262 different IR P-tunnels, a single unicast tunnel from R1 to R2 may be 263 used to carry data along both IR P-tunnels. All that is required is 264 that when the data packets arrive at R2, R2 will see the "P-tunnel 265 label" at the top of the packets' label stack; R2's further 266 processing of the packets will depend upon that label. Note that the 267 same unicast tunnel between R1 and R2 may also be carrying unicast 268 data packets. 270 Typically the unicast tunnels are the Label Switched Paths (LSPs) 271 that already exist to carry unicast traffic; either MP2P LSPs created 272 by LDP [LDP] or P2P LSPs created by RSVP-TE [RSVP-TE]. However, any 273 other kind of unicast tunnel may be used. A unicast tunnel may have 274 an arbitrary number of intermediate routers; those routers do not 275 maintain any multicast state for the IR P-tunnel, and in general are 276 not even aware of its existence. 278 As with all other P-tunnel types, IR P-tunnels may be used as 279 Inclusive P-tunnels or as Selective P-tunnels. 281 3. How are IR P-tunnels Identified? 283 There are four MVPN BGP route types in which P-tunnels can be 284 identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, 285 S-PMSI A-D routes, and Leaf A-D routes. (These route types are all 286 defined in [MVPN-BGP]). 288 Whenever it is necessary to identify a P-tunnel in a route of one of 289 these types, a "PMSI Tunnel Attribute" (PTA) is added to the route. 290 As defined in [MVPN-BGP] section 5, the PTA contains four fields: 291 "Tunnel Type", "MPLS Label", "Tunnel Identifier", and "Flags". 292 [MVPN-BGP] defines only one bit in the "Flags" field, the "Leaf 293 Information Required" bit. 295 If a route identifies an IR P-tunnel, the "Tunnel Type" field of its 296 PTA is set to the value 6, meaning "Ingress Replication". 298 Most types of P-tunnel are associated with specific protocols that 299 are used to set up and maintain tunnels of that type. For example, 300 if the "Tunnel Type" field is set to 2, meaning "mLDP P2MP LSP", the 301 associated setup protocol is mLDP [mLDP]. The associated setup 302 protocol always has a method of identifying the tunnels that it sets 303 up. For example, mLDP uses a "FEC element" to identify a tree. If 304 the "Tunnel type" field is set to 3, meaning "PIM SSM Tree", the 305 associated setup protocol is PIM, and "(S,G)" is used to identify the 306 tree. In these cases, the "Tunnel Identifier" field of the PTA 307 carries a tree identifier as defined by the setup protocol used for 308 the particular tunnel type. 310 IR P-tunnels, on the other hand, are entirely setup and maintained by 311 the use of BGP A-D routes, and are not associated with any other 312 setup protocol. (The unicast tunnels used to transmit multicast data 313 along an IR P-tunnel may have their own setup and maintenance 314 protocols, of course.) Further, the identifier of an IR P-tunnel 315 does not appear in the PTA at all. Rather, the P-tunnel identifier 316 is in the "Network Layer Reachability Information" (NLRI) field of 317 the A-D routes that are used to advertise and to setup the P-tunnel. 319 When an IR P-tunnel is identified in an S-PMSI A-D route, an Intra-AS 320 I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we will refer to 321 these three route types as "advertising A-D routes"), its identifier 322 is hereby defined to be the NLRI of that route. See sections 4.1, 323 4.2, and 4.3 of [MVPN-BGP] for the specification of these NLRIs. 324 Note that the P-tunnel identifier includes the "route type" and 325 "length" octets of the NLRI. 327 An advertising A-D route is considered to identify an IR P-tunnel 328 only if it carries a PTA whose "Tunnel Type" field is set to "IR". 330 When an IR P-tunnel is identified in an S-PMSI A-D route or in an 331 Inter-AS I-PMSI A-D route, the "Leaf Info Required" bit of the Flags 332 field of the PTA MUST be set. 334 In an advertising A-D route: 336 - If the "Leaf Info Required" bit of the Flags field of the PTA is 337 set, then the "Tunnel Identifier" field of the PTA has no 338 significance whatsoever, and MUST be ignored upon reception. 340 Note that, per RFC6514, the length of the "Tunnel Identifier" 341 field is variable, and is inferred from the length of the PTA. 342 Even when this field is of no significance, its length MUST be 343 the length of an IP address in the address space of the SP's 344 backbone, as specified in section 4.2 of [P-ADDR]. In this case, 345 it is RECOMMENDED that it be set to a routable address of the 346 router that constructed the PTA. (While it might make more sense 347 to allow or even require the field to be omitted entirely, that 348 might raise issues of backwards compatibility with 349 implementations that were designed prior to the publication of 350 this document.) 352 - If the "Leaf Info Required" bit is not set, the "Tunnel 353 Identifier" field of the PTA does have significance, but it does 354 not identify the IR P-tunnel. The use of the PTA's "Tunnel 355 Identifier" field in this case is discussed in section 5 of this 356 document. 358 Note that according to the above definition, there is no way for two 359 different advertising A-D routes (i.e., two advertising A-D routes 360 with different NLRIs) to advertise the same IR P-tunnel. In the 361 terminology of [MVPN], an IR P-tunnel can instantiate only a single 362 PMSI. If an ingress PE, for example, wants to bind two customer 363 multicast flows to a single IR P-tunnel, it must advertise that 364 tunnel in an I-PMSI A-D route or in an S-PMSI A-D route whose NLRI 365 contains wildcards [MVPN-WC]. 367 When an IR P-tunnel is identified in a Leaf A-D route, its identifier 368 is the "route key" field of the route's NLRI. See section 4.4 of 369 [MVPN-BGP]. 371 A Leaf A-D route is considered to identify an IR P-tunnel only if it 372 carries a PTA whose "Tunnel Type" field is set to "IR". In this type 373 of route, the "Tunnel Identifier" field of the PTA does have 374 significance, but it does not identify the IR P-tunnel. The use of 375 the PTA's "Tunnel Identifier" field in this case is discussed in 376 section 5. 378 4. How to Join an IR P-tunnel 380 The procedures for joining an IR P-tunnel depend upon whether the P- 381 tunnel has been previously advertised, and if so, upon how the P- 382 tunnel was advertised. Note that joining an unadvertised P-tunnel is 383 only possible when using the "Global Table Multicast" procedures of 384 [SMLS-MC]. 386 4.1. Advertised P-tunnels 388 The procedures in this section apply when the P-tunnel to be joined 389 has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D 390 route, or an Intra-AS I-PMSI A-D route. 392 The procedures for joining an advertised IR P-tunnel depend upon 393 whether the A-D route that advertises the P-tunnel has the "Leaf Info 394 Required" bit set in its PTA. 396 4.1.1. If the 'Leaf Info Required Bit' is Set 398 The procedures in this section apply when the P-tunnel to be joined 399 has been advertised in a route whose PTA has the "Leaf Info Required 400 Bit" set. 402 The router joining a particular IR P-tunnel must determine its UMH 403 for that P-tunnel. If the route that advertised the P-tunnel 404 contains a P2MP Segmented Next Hop Extended Community, the UMH is 405 determined from the value of this community (see [SMLS-MC]). 406 Otherwise the UMH is determined from the route's next hop (see [MVPN- 407 BGP]). 409 Once the UMH is determined, the router joining the IR P-tunnel 410 originates a Leaf A-D route. The NLRI of the Leaf A-D route MUST 411 contain the tunnel identifier (as defined in section 3 above) as its 412 "route key". The UMH MUST be identified by attaching an "IP Address 413 Specific Route Target" (or an "IPv6 Address Specific Route Target") 414 to the Leaf A-D route. The IP address of the UMH appears in the 415 "global administrator" field of the Route Target (RT). Details can 416 be found in [MVPN-BGP] and [SMLS-MC]. 418 The Leaf A-D route MUST also contain a PTA whose fields are set as 419 follows: 421 - The "Tunnel Type" field is set to "IR". 423 - The "Tunnel Identifier" field is set as described in section 5 of 424 this document. 426 - The "MPLS Label" field is set to a non-zero value. This is the 427 "P-tunnel label". The value must be chosen so as to satisfy 428 various constraints, as discussed in section 6 of this document. 430 4.1.2. If the 'Leaf Info Required Bit' is Not Set 432 The procedures in this section apply when the P-tunnel to be joined 433 has been advertised in a route whose PTA does not have the "Leaf Info 434 Required Bit" set. This can only be the case if the P-tunnel was 435 advertised in an Intra-AS I-PMSI A-D route. 437 If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes 438 originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can 439 be thought of as being instantiated by a set of IR P-tunnels. Each 440 PE is the root of one such P-tunnel, and the other PEs are children 441 of the root. A PE simultaneously joins all these P-tunnels by 442 originating (if it hasn't already done so) an Intra-AS I-PMSI A-D 443 route with a PTA whose fields are set as follows: 445 - The "Tunnel Type" field is set to "IR". 447 - The "Tunnel Identifier" field is set as described in section 5 of 448 this document. 450 - The "MPLS Label" field MUST be set to a non-zero value. This 451 label value will be used by the child node to associate a 452 received packet with the I-PMSI of a particular MVPN. The MPLS 453 label allocation policy must be such as to ensure that the 454 binding from label to I-PMSI is one-to-one. 456 The NLRI and the RTs of the originated I-PMSI A-D route are set as 457 specified in [MVPN-BGP]. 459 Note that if a set of IR P-tunnels is joined in this manner, the 460 "discard from the wrong PE" procedures of [MVPN] section 9.1.1 cannot 461 be applied to that P-tunnel. Thus duplicate prevention on such IR P- 462 tunnels requires the use of either Single Forwarder Selection ([MVPN] 463 section 9.1.2) or native PIM procedures ([MVPN] section 9.1.3). 465 4.2. Unadvertised P-tunnels 467 In [SMLS-MC], a procedure is defined for "Global Table Multicast", in 468 which a P-tunnel can be joined even if the P-tunnel has not been 469 previously advertised. See the sections of that document entitled 470 "Leaf A-D Route for Global Table Multicast" and "Constructing the 471 Rest of the Leaf A-D Route". The route key of the Leaf A-D route has 472 the form of the "S-PMSI Route-Type Specific NLRI" in this case, and 473 that should be considered to be the P-tunnel identifier. Note that 474 the procedure for finding the UMH is different in this case; the UMH 475 is the next hop of the best UMH-eligible route towards the "ingress 476 PE". See the section of that document entitled "Determining the 477 Upstream ABR/PE/ASBR (Upstream Node)". 479 5. The PTA's 'Tunnel Identifier' Field 481 If the "Tunnel Type" field of a PTA is set to "IR", its "Tunnel 482 Identifier" field is significant only when one of the following two 483 conditions holds: 485 - The PTA is carried by a Leaf A-D route, or 487 - The "Leaf Information Required" bit of the "Flags" field of the 488 PTA is not set. 490 If one of these conditions holds, then the "Tunnel Identifier" field 491 must contain a routable IP address of the originator of the route. 492 (See [MVPN-BGP] sections 9.2.3.2.1 and 9.2.3.4.1 for the detailed 493 specification of the contents of this field.) This address is used 494 by the UMH to determine the unicast tunnel that it will use in order 495 to send data, along the IR P-tunnel identified by the route key, to 496 the originator of the Leaf A-D route. 498 The means by which the unicast tunnel is determined from this IP 499 address is outside the scope of this document. The means by which 500 the unicast tunnel is set up and maintained is also outside the scope 501 of this document. 503 Section 4 of [P-ADDR] MUST be applied when a PTA is carried in a Leaf 504 A-D route, and describes how to determine whether the "Tunnel 505 Identifier" field carries an IPv4 or an IPv6 address. 507 If neither of the above conditions hold, then the "Tunnel Identifier" 508 field is of no significance, and MUST be ignored upon reception. 510 6. The PTA's 'MPLS Label' Field 512 When a PTA is carried by an S-PMSI A-D route or an Inter-AS I-PMSI A- 513 D route, and the "Tunnel Type" field is set to "IR", the "MPLS Label" 514 field is of no significance. In this case, it SHOULD be set to zero 515 upon transmission and MUST be ignored upon reception. 517 The "MPLS Label" field is significant only when the PTA appears 518 either in a Leaf A-D route or in an Intra-AS I-PMSI A-D route that 519 does not have the "Leaf Information Required" bit set. In these 520 cases, the MPLS label is the label that the originator of the route 521 is assigning to the IR P-tunnel(s) identified by the route's NLRI. 522 (That is, the MPLS label assigned in the PTA is what we have called 523 the "P-tunnel label".) 525 6.1. Leaf A-D Route Originated by an Egress PE 527 As previously stated, when a Leaf A-D route is used to join an IR P- 528 tunnel, the "route key" of the Leaf A-D route is the P-tunnel 529 identifier. 531 We now define the notion of the "root of an IR P-tunnel". 533 - If the identifier of an IR P-tunnel is of the form of an S-PMSI 534 NLRI, the "root" of the P-tunnel is the router identified in the 535 "Originating Router's IP Address" field of that NLRI. 537 - If the identifier of an IR P-tunnel is of the form specified in 538 Section "Leaf A-D Route for Global Table Multicast" of [SMLS-MC], 539 the "root" of the P-tunnel is the router identified in the 540 "Ingress PE's IP Address" field of that NLRI. 542 - If the identifier of an IR P-tunnel is of the form of an Intra-AS 543 I-PMSI NLRI, the "root" of the P-tunnel is the router identified 544 in the "Originating Router's IP Address" field of that NLRI. 546 - If the identifier of an IR P-tunnel is of the form of an Inter-AS 547 I-PMSI NLRI, the "root" of the P-tunnel is same as the identifier 548 of the P-tunnel, i.e., the combination of an RD and an AS. 550 Note that if a P-tunnel is segmented, the root of the P-tunnel, by 551 this definition, is actually the root of the entire P-tunnel, not the 552 root of the local segment. 554 In order to apply the procedures of RFC 6513 Section 9.1.1 555 ("Discarding Packets from Wrong PE"), the following condition MUST be 556 met by the MPLS label allocation policy:. 558 Suppose an egress PE originates two Leaf A-D routes, each with a 559 different route key in its NLRI, and each with a PTA specifying a 560 "Tunnel Type" of "IR". Thus each of the Leaf A-D routes 561 identifies a different IR P-tunnel. Suppose further that each of 562 those IR P-tunnels has a different root. Then the egress PE MUST 563 NOT specify the same MPLS label in both PMSI Tunnel attributes. 565 That is, to apply the "Discarding Packets from the Wrong PE" 566 duplicate prevention procedures ([MVPN] section 9.1.1), the same MPLS 567 label MUST NOT be assigned to two IR P-tunnels that have different 568 roots. 570 If segmented P-tunnels are in use, the above rule is necessary but 571 not sufficient to prevent a PE from forwarding duplicate data to the 572 CEs. For various reasons, a given egress PE or egress ABR or egress 573 ASBR may decide to change its parent node, on a given segmented P- 574 tunnel, from one router to another. It does this by changing the RT 575 of the Leaf A-D route that it originated in order to join that P- 576 tunnel. Once the RT is changed, there may be a period of time during 577 which the old parent node and the new parent node are both sending 578 data of the same multicast flow. To ensure that the egress node not 579 forward duplicate data, whenever the egress node changes the RT that 580 it attaches to a Leaf A-D route, it MUST also change the "MPLS Label" 581 specified in the Leaf A-D route's PTA. This allows the egress router 582 to distinguish between packets arriving on a given P-tunnel from the 583 old parent and packets arriving on that same P-tunnel from the new 584 parent. At any given time, a router MUST consider itself to have 585 only a single parent node on a given P-tunnel, and MUST discard 586 traffic that arrives on that P-tunnel from a different parent node. 588 If extranet functionality [MVPN-XNET] is not implemented in a 589 particular egress PE, or if an egress PE is provisioned with the 590 knowledge that extranet functionality is not needed, the PE may adopt 591 the policy of assigning a label that is unique for the ordered triple 592 . This will enable the egress PE to 593 apply the duplicate prevention procedures discussed above, and to 594 determine the VRF to which an arriving packet must be directed. 596 However, this policy is not sufficient to support the "Discard 597 Packets from the Wrong P-tunnel" procedures that are specified in 598 [MVPN-XNET]. To support those procedures, the labels specified in 599 the PTA of Leaf A-D routes originated by a given egress PE MUST be 600 unique for the ordered triple , where the 601 "root RD" is taken from the RD field of the IR P-tunnel identifier. 602 (All forms of IR P-tunnel identifier contain an embedded "RD" field.) 603 This policy is also sufficient for supporting non-extranet cases, but 604 in some cases may result in the use of more labels than the policy of 605 the previous paragraph. 607 6.2. Leaf A-D Route Originated by an Intermediate Node 609 When a P-tunnel is segmented, there will be "intermediate nodes" 610 (nodes that have a parent and also have children on the P-tunnel). 611 Each intermediate node is a leaf node of an "upstream segment" and a 612 parent node of a "downstream segment". The intermediate node 613 "splices" together the two segments, so that data it receives on the 614 upstream segment gets transmitted on the downstream segment. If 615 either the upstream or downstream segments (or both) are instantiated 616 by IR, the need to do this splicing places certain constraints on the 617 MPLS label allocation policy. 619 6.2.1. Upstream and Downstream Segments are IR Segments 621 An intermediate node N (i.e., a node that has a parent and also has 622 children) on an IR P-tunnel may originate a Leaf A-D route with a 623 particular route key as a result of receiving a Leaf A-D route with 624 that same route key. This will happen only if the received Leaf A-D 625 route carries an IP address specific RT whose Global Administrator 626 field identifies node N. 628 Suppose intermediate node N originates two Leaf A-D routes, one whose 629 route key is K1, and one whose route key is K2, where K1 != K2. In 630 general, the respective PTAs of these Leaf A-D routes MUST specify 631 distinct non-zero MPLS labels, such that it is possible to map 632 uniquely from the specified label value to a single IR P-tunnel (call 633 this the "uniqueness rule"). There is one exception to this rule; 634 the exception is specified below. 636 Consider the set of Leaf A-D routes with route key K1 or route key K2 637 such that: 639 - N has received these Leaf A-D routes and has them currently 640 installed. 642 - Each of these Leaf A-D routes carries an IP Address Specific 643 Route Target that identifies N in its Global Administrator field. 645 Now suppose that all the Leaf A-D routes in this set have the same 646 originating router, and that the PTAs of these Leaf A-D routes all 647 specify the same MPLS label. Suppose further that N's UMH for K1 is 648 the same as N's UMH for K2. In this particular case, N MAY specify 649 the same MPLS label in the PTA of Leaf A-D route it originates for K1 650 as in the PTA of he route it originates for K2. However, if at any 651 future time these conditions no longer hold, N must reoriginate at 652 least one of the Leaf A-D routes with a different label so that the 653 "uniqueness rule" holds. 655 6.2.2. Only One Segment is IR 657 To handle the case where an intermediate node, call it N, is splicing 658 together two P-tunnel segments, only one of which is IR, it is 659 necessary to generalize the rules of the preceding sub-section. 661 Suppose N is a leaf node of two (upstream) P-tunnel segments, call 662 them U1 and U2. Suppose also that N is a parent node of two 663 (downstream) P-tunnel segments, call them D1 and D2. And suppose 664 that N needs to splice U1 to D1, and U2 to D2. 666 To follow the uniqueness rule of section 6.2.1 of this document, N 667 must assign a different MPLS label to U1 than it assigns to U2. How 668 this assignment is made depends, of course, on the control protocol 669 used to set up U1 and U2. 671 There is one case in which the uniqueness rule need not be followed. 672 Suppose that there is a node M such that (a) M is N's only child node 673 on D1, and (b) M is N's only child node on D2. M will have 674 advertised to N a label L1 bound to D1, and a label L2 bound to D2. 675 If (and for as long as) L1==L2, then N MAY violate the uniqueness 676 rule by advertising to its parent node for U1 the same MPLS label it 677 advertises to its parent node for U2. 679 Section 6.2.1 of this document specifies in detail the way this 680 requirement is applied when the upstream and downstream segments are 681 all IR segments. 683 6.3. Intra-AS I-PMSI A-D Route 685 When a router joins a set of IR P-tunnels using the procedures of 686 section 4.1.2 of this document, the procedures of section 9.1.1 of 687 [MVPN] cannot be applied, no matter what the label allocation policy 688 is. In this case, the ingress PE is the same as the UMH, but it is 689 not possible to assign a label uniquely to a particular ingress PE or 690 UMH. However, the label in the MPLS label field of the PTA MUST NOT 691 appear in the MPLS label field of the PTA carried by any other route 692 originated by the same router. 694 7. How A Child Node Prunes Itself from an IR P-tunnel 696 If a particular IR P-tunnel was joined via the procedures of section 697 4.1.2 of this document, a router can prune itself from the P-tunnel 698 by withdrawing the Intra-AS I-PMSI A-D route it used to join the P- 699 tunnel. This is not usually done unless the router is removing 700 itself entirely from a particular MVPN. 702 The procedures in the remainder of this section apply when a router 703 joined a particular IR P-tunnel by originating a Leaf A-D route (as 704 described in section 4.1.1 or 4.2 of this document). 706 If a router no longer has a need to receive any multicast data from a 707 given IR P-tunnel, it may prune itself from the P-tunnel by 708 withdrawing the Leaf A-D route it used to join the tunnel. This is 709 done, e.g., if the router no longer needs any of the flows traveling 710 over the P-tunnel, or if all the flows the router does need are being 711 received over other P-tunnels. 713 A router that is attached to a particular IR P-tunnel via a 714 particular parent node may determine that it needs to stay joined to 715 that P-tunnel, but via a different parent node. This can happen, for 716 example, if there is a change in the Next Hop or the P2MP Segmented 717 Next Hop Extended Community of the S-PMSI A-D route in which that P- 718 tunnel was advertised. In this case, the router changes the Route 719 Target of the Leaf A-D route it used to join the IR P-tunnel, so that 720 the Route Target now identifies the new parent node. 722 A parent node must notice when a child node has been pruned from a 723 particular tree, as this will affect the parent node's multicast data 724 state. Note that the pruning of a child node may appear to the 725 parent node as the explicit withdrawal of a Leaf A-D route, or it may 726 appear as a change in the Route Target of a Leaf A-D route. If the 727 Route Target of a particular Leaf A-D route previously identified a 728 particular parent node, but changes so that it no longer does so, the 729 effect on the multicast state of the parent node is the same as if 730 the Leaf A-D route had been explicitly withdrawn. 732 8. Parent Node Actions Upon Receiving Leaf A-D Route 734 These actions are detailed in [MVPN-BGP] and [SMLS-MC]. Two points 735 of clarification are made: 737 - If a router R1 receives and installs a Leaf A-D route originated 738 by router R2, R1's multicast state is affected only if the Leaf 739 A-D route carries an "IP Address Specific RT" (or "IPv6 Address 740 Specific RT") whose "global administrator" field identifies R1. 742 (This is as specified in [MVPN-BGP] and [SMLS-MC].) If a Leaf A- 743 D route's RT does not identify R1, but then changes so that it 744 does identify R1, R1 must take the same actions it would take if 745 the Leaf A-D route were newly received. 747 - It is possible that router R1 will receive and install a Leaf A-D 748 route originated by router R2, where: 750 * the route's RT identifies R1, 752 * the route's NLRI contains a route key whose first octet 753 indicates that it is identifying a P-tunnel advertised in an 754 S-PMSI A-D route, 756 * R1 has neither originated nor installed any such S-PMSI A-D 757 route. 759 If at some later time, R1 installs the corresponding S-PMSI A-D 760 route, and the Leaf A-D route is still installed, and the Leaf A-D 761 route's RT still identifies R1, then R1 MUST follow the same 762 procedures it would have followed if the S-PMSI A-D route had been 763 installed before the Leaf A-D route was installed. (I.e., 764 implementers must not assume that events occur in the "usual" or 765 "expected" order.) 767 9. Use of Timers when Switching UMH 769 Suppose a child node has joined a particular IR P-tunnel via a 770 particular UMH, and it now determines (for whatever reason) that it 771 needs to change its UMH on that P-tunnel. It does this by modifying 772 the RT of a Leaf A-D route. 774 It is desirable for such a "switch of UMH" to be done using a "make 775 before break" technique, so that the older UMH does not stop 776 transmitting the packets on the given P-tunnel to the child until the 777 newer UMH has a chance to start transmitting the packets on the given 778 P-tunnel to the child. However, the control plane operation 779 (modifying the RT of the Leaf A-D route) does not permit the child 780 node to first join the P-tunnel at the new UMH, and then later prune 781 itself from the old UMH; a single control plane operation has both 782 effects. Therefore, to achieve "make before break", timers must be 783 used as follows: 785 1. The old UMH must continue transmitting to the child node for a 786 period of time after it sees the child's Leaf A-D route being 787 withdrawn (or its RT changing to identify a different UMH). 789 2. The child node must continue to accept packets from the old UMH 790 for a period of time before it starts to accept packets from 791 the new UMH (and discard packets from the old). 793 Further, the timer in 1 should be longer than the timer in 2. This 794 allows the child to switch from one UMH to another without any loss 795 of data. 797 10. IANA Considerations 799 This document contains no actions for IANA. 801 11. Acknowledgments 803 The authors wish to thank Yakov Rekhter for his contributions to this 804 work. We also wish to thank Huajin Jeng and Samir Saad for their 805 contributions, and to thank Thomas Morin for pointing out some of the 806 issues that needed further elaboration. 808 Section 6.1 discusses the importance of having an MPLS label 809 allocation policy that, when ingress replication is used, allows an 810 egress PE to infer the identity of a received packet's ingress PE. 811 This issue was first raised in earlier work by Xu Xiaohu. 813 12. Security Considerations 815 No security considerations are raised by this document beyond those 816 already discussed in [MVPN] and [MVPN-BGP]. 818 13. Authors' Addresses 820 Eric C. Rosen 821 Cisco Systems, Inc. 822 1414 Massachusetts Avenue 823 Boxborough, MA, 01719 824 Email: erosen@cisco.com 825 Karthik Subramanian 826 Cisco Systems, Inc. 827 170 Tasman Drive 828 San Jose, CA, 95134 829 Email: kartsubr@cisco.com 831 Jeffrey Zhang 832 Juniper Networks 833 10 Technology Park Dr. 834 Westford, MA 01886 835 Email: zzhang@juniper.net 837 14. Normative References 839 [MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen and R. Aggarwal, 840 editors, RFC 6513, February 2012 842 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 843 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, RFC 6514, 844 February 2012 846 [P-ADDR] "IPv4 and IPv6 Infrastructure Addresses in Updates for 847 Multicast VPN", R. Aggarwal and E. Rosen, RFC 6515, February 2012 849 [RFC2119] "Key words for use in RFCs to Indicate Requirement 850 Levels.", Bradner, March 1997 852 15. Informational References 854 [C-BIDIR-IR] "Simulating "Partial Mesh of MP2MP P-Tunnels" with 855 Ingress Replication", Zhang, Rekhter, Dolganow, draft-ietf-l3vpn- 856 mvpn-bidir-ingress-replication-00.txt, February 2014 858 [LDP] "LDP Specification", L. Andersson, I. Minei, and B. Thomas, 859 editors, RFC 5036, October 2007 861 [MVPN-BIDIR] "MVPN: Using Bidirectional P-Tunnels", Rosen, Wijnands, 862 Cai, Boers, draft-ietf-l3vpn-mvpn-bidir-07.txt, January 2014 864 [MVPN-WC] "Wildcards in Multicast VPN Auto-Discovery Routes", Rosen, 865 Rekhter, Henderickx, Qiu, RFC 6625, May 2012 867 [MVPN-XNET] "Extranet Multicast in BGP/IP MPLS VPNs", Y. Rekhter and 868 E. Rosen (editors), draft-ietf-l3vpn-mvpn-extranet-05.txt, April 2014 870 [RSVP-TE] "RSVP-TE: Extensions to RSVP for LSP Tunnels", D. Awduche, 871 L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, RFC 3209, 872 December 2001 874 [SMLS-MC] "Inter-Area P2MP Segmented LSPs", Y. Rekhter, R. Aggarwal, 875 T. Morin, I. Grosclaude, N. Leymann, S. Saad, draft-ietf-mpls- 876 seamless-mcast-09.txt, December 2013