idnits 2.17.1 draft-rosen-l3vpn-ir-02.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 (October 15, 2014) is 3452 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 (-17) exists of draft-ietf-mpls-seamless-mcast-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN 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: April 18, 2015 J. Zhang 7 Juniper Networks, Inc. 8 October 15, 2014 10 Ingress Replication Tunnels in Multicast VPN 11 draft-rosen-l3vpn-ir-02 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 April 18, 2015. 49 Copyright Notice 51 Copyright (c) 2014 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? . . . . . . . . . . . . . . 6 69 4. How to Join an IR P-tunnel . . . . . . . . . . . . . . . . . 8 70 4.1. Advertised 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 P-tunnels . . . . . . . . . . . . . . . . . 10 74 5. The PTA's 'Tunnel Identifier' Field . . . . . . . . . . . . . 11 75 6. The PTA's 'MPLS Label' Field . . . . . . . . . . . . . . . . 11 76 6.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 12 77 6.2. Leaf A-D Route Originated by an Intermediate Node . . . . 13 78 6.2.1. Upstream and Downstream Segments are IR Segments . . 14 79 6.2.2. Only One Segment is IR . . . . . . . . . . . . . . . 14 80 6.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 15 81 7. How A Child Node Prunes Itself from an IR P-tunnel . . . . . 15 82 8. Parent Node Actions Upon Receiving Leaf A-D Route . . . . . . 16 83 9. Use of Timers when Switching UMH . . . . . . . . . . . . . . 17 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 13.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 P2P or MP2P MPLS LSP or a unicast IP tunnel) 111 to the child node. If a node on an IR tree has n child nodes, and 112 has a multicast data packet that must be sent along the tree, the 113 parent node makes n individual copies of the data packet, and then 114 sends each copy, through a unicast tunnel, to exactly one child node. 115 No lower layer multicast technology is used when sending traffic from 116 a parent node to a child node; multiple copies of the packet may 117 therefore be sent out a single interface. 119 With the single exception of IR, the P-tunnel technologies supported 120 by the MVPN specifications are pre-existing IP multicast or MPLS 121 multicast technologies. Each such technology has its own set of 122 specifications, its own setup and maintenance protocols, its own 123 syntax for identifying specific multicast trees, and its own 124 procedures for enabling a router to be added to or removed from a 125 particular multicast tree. For IR P-tunnels, on the other hand, 126 there is no prior specification for setting up and maintaining the 127 P2MP trees; the procedures and protocol elements used for setting up 128 and maintaining the P2MP trees are specified in the MVPN 129 specifications themselves, and all the signaling/setup is done by 130 using the BGP A-D (Auto-Discovery) routes that are defined in 131 [RFC6514]. (The unicast tunnels used to transmit multicast data from 132 one node to another in an IR P-tunnel may of course have their own 133 setup and maintenance protocols, e.g., [RFC5036], [RFC3209].) 135 Since the transmission of a multicast data packet along an IR 136 P-tunnel is done by transmitting the packet through a unicast tunnel, 137 previous RFCs sometimes speak of an IR P-tunnel as "consisting of" a 138 set of unicast tunnels. However, that way of speaking is not quite 139 accurate. For one thing, it obscures the fact that an IR P-tunnel is 140 really a P2MP tree, whose nodes must maintain multicast state in both 141 the control and data planes. For another, it obscures the fact the 142 unicast tunnels used by a particular IR P-tunnel need not be specific 143 to that P-tunnel; a single unicast tunnel can carry the multicast 144 traffic of many different IR P-tunnels (and can also carry unicast 145 traffic as well). 147 In this document, we provide a clearer and more explicit conceptual 148 model for IR P-tunnels, clarifying the relationship between an IR 149 P-tunnel and the unicast tunnels that are used for data transmission 150 along the IR P-tunnel. 152 RFC 6514 defines a protocol element called a "tunnel identifier", 153 which for most P-tunnel technologies is used to identify a P-tunnel 154 (i.e., to identify a P2MP or MP2MP tree). However, when IR P-tunnels 155 are used, this protocol element does not identify an IR P-tunnel. In 156 some cases it identifies one of the P-tunnel's constituent unicast 157 tunnels, and in other cases it is not used to identify a tunnel at 158 all. In this document, we provide an explicit specification for how 159 IR P-tunnels are actually identified. 161 Some of the MVPN specifications use phrases like "join the identified 162 P-tunnel", even though there has up to now not been an explicit 163 specification of how to identify an IR P-tunnel, of how a router 164 joins such a P-tunnel, or of how a router prunes itself from such a 165 P-tunnel. In this document, we make these procedures more explicit. 167 RFC 6514 does provide a method for binding an MPLS label to a 168 P-tunnel, but does not discuss the label allocation policies that are 169 needed for correct operation when the P-tunnel is an IR P-tunnel. 170 Those policies are discussed in this document. 172 This document does not provide any new protocol elements or 173 procedures; rather it makes explicit just how a router is to use the 174 protocol elements and procedures of [RFC6513] and [RFC6514] to 175 identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself 176 from an IR P-tunnel. This document also discusses the MPLS label 177 allocation policies that need to be supported when binding MPLS 178 labels to IR P-tunnels, and the timer policies that need to be 179 supported when switching a customer multicast flow from one P-tunnel 180 to another. As the material in this document must be understood in 181 order to properly implement IR P-tunnels, this document is considered 182 to update [RFC6513] and [RFC6514]. This document also discusses the 183 application of "seamless multicast" [SMLS-MC] and "extranet" [MVPN- 184 XNET] procedures to IR P-tunnels. 186 This draft does not discuss the use of IR P-tunnels to support a VPN 187 customer's use of BIDIR-PIM. [C-BIDIR-IR] explains how to adapt the 188 procedures of [RFC6513], [RFC6514], and [MVPN-BIDIR] so that a 189 customer's use of BIDIR-PIM can be supported by IR P-tunnels. 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL", when and only when appearing in all capital letters, are 194 to be interpreted as described in [RFC2119]. 196 2. What is an IR P-tunnel? 198 An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that 199 support the MVPN procedures of [RFC6514] and related RFCs. In 200 general, the nodes of an IR P-tunnel are either PE routers, ASBRs, or 201 (if [SMLS-MC] is supported) ABRs. (MVPN procedures are sometimes 202 used to support non-MVPN, or "global table" multicast; one way of 203 doing this is defined in [SMLS-MC]. In such a case, IR P-tunnels can 204 be used outside the context of MVPN.) 206 MVPN P-tunnels may be either "segmented" or "non-segmented" (as these 207 terms are defined in [RFC6513] and [RFC6514]). 209 A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting 210 only of a root node and a set of nodes that are children of the root 211 node. When used in an MVPN context, the root is an ingress PE, and 212 the child nodes of the root are the egress PEs. 214 In a segmented P-tunnel, IR may be used for some or all of the 215 segments. If a particular segment of a segmented P-tunnel uses IR, 216 then the root of that segment may have child nodes that are ABRs or 217 ASBRs, rather than egress PEs. 219 As with any type of P2MP tree, each node of an IR P-tunnel holds 220 "multicast state" for the P-tunnel. That is, each node knows the 221 identity of its parent node on the tree, and each node knows the 222 identities of its child nodes on the tree. In the MVPN specs, the 223 "parent" node is also known as the "Upstream Multicast Hop" or "UMH". 225 What distinguishes an IR P-tunnel from any other kind of P2MP tree is 226 the method by which a data packet is transmitted from a parent node 227 to a child node. To transmit a multicast data packet from a parent 228 node to a child node along a particular IR P-tunnel, the parent node 229 does the following: 231 o It labels the packet with a label (call it a "P-tunnel label") 232 that the child node has assigned to that P-tunnel, 234 o It then places the packet in a unicast encapsulation and unicasts 235 the packet to the child node. That is, the parent node sends the 236 packet through a "unicast tunnel" to a particular child node. 237 This unicast tunnel need not be specially created to be part of 238 the IR P-tunnel; it can be any P2P or MP2P unicast tunnel that 239 will get the packets from the parent node to the child node. A 240 single such unicast tunnel may be carrying multicast data packets 241 of several different P2MP trees, and may also be carrying unicast 242 data packets. 244 The parent node repeats this process for each child node, creating 245 one copy for each child node, and sending each copy through a unicast 246 tunnel to corresponding child node. It does not use layer 2 247 multicast, IP multicast, or MPLS multicast to transmit packets to its 248 child nodes. As a result, multiple copies of each packet may be sent 249 out a single interface; this may happen, e.g., if that interface is 250 the next hop interface, according to unicast routing, from the parent 251 node to several of the child nodes. 253 Since data traveling along an IR P-tunnel is always unicast from 254 parent node to child node, it can be convenient to think of an IR 255 P-tunnel as a P2MP tree whose arcs are unicast tunnels. However, it 256 is important to understand that the unicast tunnels need not be 257 specific to any particular IR P-tunnel. If R1 is the parent node of 258 R2 on two different IR P-tunnels, a single unicast tunnel from R1 to 259 R2 may be used to carry data along both IR P-tunnels. All that is 260 required is that when the data packets arrive at R2, R2 will see the 261 "P-tunnel label" at the top of the packets' label stack; R2's further 262 processing of the packets will depend upon that label. Note that the 263 same unicast tunnel between R1 and R2 may also be carrying unicast 264 data packets. 266 Typically the unicast tunnels are the Label Switched Paths (LSPs) 267 that already exist to carry unicast traffic; either MP2P LSPs created 268 by LDP [RFC5036] or P2P LSPs created by RSVP-TE [RFC3209]. However, 269 any other kind of unicast tunnel may be used. A unicast tunnel may 270 have an arbitrary number of intermediate routers; those routers do 271 not maintain any multicast state for the IR P-tunnel, and in general 272 are not even aware of its existence. 274 As with all other P-tunnel types, IR P-tunnels may be used as 275 Inclusive P-tunnels or as Selective P-tunnels. 277 3. How are IR P-tunnels Identified? 279 There are four MVPN BGP route types in which P-tunnels can be 280 identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, 281 S-PMSI A-D routes, and Leaf A-D routes. (These route types are all 282 defined in [RFC6514]). 284 Whenever it is necessary to identify a P-tunnel in a route of one of 285 these types, a "PMSI Tunnel Attribute" (PTA) is added to the route. 286 As defined in [RFC6514] section 5, the PTA contains four fields: 287 "Tunnel Type", "MPLS Label", "Tunnel Identifier", and "Flags". 288 [RFC6514] defines only one bit in the "Flags" field, the "Leaf 289 Information Required" bit. 291 If a route identifies an IR P-tunnel, the "Tunnel Type" field of its 292 PTA is set to the value 6, meaning "Ingress Replication". 294 Most types of P-tunnel are associated with specific protocols that 295 are used to set up and maintain tunnels of that type. For example, 296 if the "Tunnel Type" field is set to 2, meaning "mLDP P2MP LSP", the 297 associated setup protocol is mLDP [mLDP]. The associated setup 298 protocol always has a method of identifying the tunnels that it sets 299 up. For example, mLDP uses a "FEC element" to identify a tree. If 300 the "Tunnel type" field is set to 3, meaning "PIM SSM Tree", the 301 associated setup protocol is PIM, and "(S,G)" is used to identify the 302 tree. In these cases, the "Tunnel Identifier" field of the PTA 303 carries a tree identifier as defined by the setup protocol used for 304 the particular tunnel type. 306 IR P-tunnels, on the other hand, are entirely setup and maintained by 307 the use of BGP A-D routes, and are not associated with any other 308 setup protocol. (The unicast tunnels used to transmit multicast data 309 along an IR P-tunnel may have their own setup and maintenance 310 protocols, of course.) Further, the identifier of an IR P-tunnel 311 does not appear in the PTA at all. Rather, the P-tunnel identifier 312 is in the "Network Layer Reachability Information" (NLRI) field of 313 the A-D routes that are used to advertise and to setup the P-tunnel. 315 When an IR P-tunnel is identified in an S-PMSI A-D route, an Intra-AS 316 I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we will refer to 317 these three route types as "advertising A-D routes"), its identifier 318 is hereby defined to be the NLRI of that route. See sections 4.1, 319 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs. Note 320 that the P-tunnel identifier includes the "route type" and "length" 321 octets of the NLRI. 323 An advertising A-D route is considered to identify an IR P-tunnel 324 only if it carries a PTA whose "Tunnel Type" field is set to "IR". 326 When an IR P-tunnel is identified in an S-PMSI A-D route or in an 327 Inter-AS I-PMSI A-D route, the "Leaf Info Required" bit of the Flags 328 field of the PTA MUST be set. 330 In an advertising A-D route: 332 o If the "Leaf Info Required" bit of the Flags field of the PTA is 333 set, then the "Tunnel Identifier" field of the PTA has no 334 significance whatsoever, and MUST be ignored upon reception. 336 Note that, per RFC6514, the length of the "Tunnel Identifier" 337 field is variable, and is inferred from the length of the PTA. 338 Even when this field is of no significance, its length MUST be the 339 length of an IP address in the address space of the SP's backbone, 340 as specified in section 4.2 of [RFC6515]. In this case, it is 341 RECOMMENDED that it be set to a routable address of the router 342 that constructed the PTA. (While it might make more sense to 343 allow or even require the field to be omitted entirely, that might 344 raise issues of backwards compatibility with implementations that 345 were designed prior to the publication of this document.) 347 o If the "Leaf Info Required" bit is not set, the "Tunnel 348 Identifier" field of the PTA does have significance, but it does 349 not identify the IR P-tunnel. The use of the PTA's "Tunnel 350 Identifier" field in this case is discussed in Section 5 of this 351 document. 353 Note that according to the above definition, there is no way for two 354 different advertising A-D routes (i.e., two advertising A-D routes 355 with different NLRIs) to advertise the same IR P-tunnel. In the 356 terminology of [RFC6513], an IR P-tunnel can instantiate only a 357 single PMSI. If an ingress PE, for example, wants to bind two 358 customer multicast flows to a single IR P-tunnel, it must advertise 359 that tunnel in an I-PMSI A-D route or in an S-PMSI A-D route whose 360 NLRI contains wildcards ([RFC6625]). 362 When an IR P-tunnel is identified in a Leaf A-D route, its identifier 363 is the "route key" field of the route's NLRI. See section 4.4 of 364 [RFC6514]. 366 A Leaf A-D route is considered to identify an IR P-tunnel only if it 367 carries a PTA whose "Tunnel Type" field is set to "IR". In this type 368 of route, the "Tunnel Identifier" field of the PTA does have 369 significance, but it does not identify the IR P-tunnel. The use of 370 the PTA's "Tunnel Identifier" field in this case is discussed in 371 Section 5. 373 4. How to Join an IR P-tunnel 375 The procedures for joining an IR P-tunnel depend upon whether the 376 P-tunnel has been previously advertised, and if so, upon how the 377 P-tunnel was advertised. Note that joining an unadvertised P-tunnel 378 is only possible when using the "Global Table Multicast" procedures 379 of [SMLS-MC]. 381 4.1. Advertised P-tunnels 383 The procedures in this section apply when the P-tunnel to be joined 384 has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D 385 route, or an Intra-AS I-PMSI A-D route. 387 The procedures for joining an advertised IR P-tunnel depend upon 388 whether the A-D route that advertises the P-tunnel has the "Leaf Info 389 Required" bit set in its PTA. 391 4.1.1. If the 'Leaf Info Required Bit' is Set 393 The procedures in this section apply when the P-tunnel to be joined 394 has been advertised in a route whose PTA has the "Leaf Info Required 395 Bit" set. 397 The router joining a particular IR P-tunnel must determine its UMH 398 for that P-tunnel. If the route that advertised the P-tunnel 399 contains a P2MP Segmented Next Hop Extended Community, the UMH is 400 determined from the value of this community (see [SMLS-MC]). 401 Otherwise the UMH is determined from the route's next hop (see 402 [RFC6514]). 404 Once the UMH is determined, the router joining the IR P-tunnel 405 originates a Leaf A-D route. The NLRI of the Leaf A-D route MUST 406 contain the tunnel identifier (as defined in Section 3 above) as its 407 "route key". The UMH MUST be identified by attaching an "IP Address 408 Specific Route Target" (or an "IPv6 Address Specific Route Target") 409 to the Leaf A-D route. The IP address of the UMH appears in the 410 "global administrator" field of the Route Target (RT). Details can 411 be found in [RFC6514] and [SMLS-MC]. 413 The Leaf A-D route MUST also contain a PTA whose fields are set as 414 follows: 416 o The "Tunnel Type" field is set to "IR". 418 o The "Tunnel Identifier" field is set as described in Section 5 of 419 this document. 421 o The "MPLS Label" field is set to a non-zero value. This is the 422 "P-tunnel label". The value must be chosen so as to satisfy 423 various constraints, as discussed in Section 6 this document. 425 4.1.2. If the 'Leaf Info Required Bit' is Not Set 427 The procedures in this section apply when the P-tunnel to be joined 428 has been advertised in a route whose PTA does not have the "Leaf Info 429 Required Bit" set. This can only be the case if the P-tunnel was 430 advertised in an Intra-AS I-PMSI A-D route. 432 If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes 433 originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can 434 be thought of as being instantiated by a set of IR P-tunnels. Each 435 PE is the root of one such P-tunnel, and the other PEs are children 436 of the root. A PE simultaneously joins all these P-tunnels by 437 originating (if it hasn't already done so) an Intra-AS I-PMSI A-D 438 route with a PTA whose fields are set as follows: 440 o The "Tunnel Type" field is set to "IR". 442 o The "Tunnel Identifier" field is set as described in Section 5 of 443 this document. 445 o The "MPLS Label" field MUST be set to a non-zero value. This 446 label value will be used by the child node to associate a received 447 packet with the I-PMSI of a particular MVPN. The MPLS label 448 allocation policy must be such as to ensure that the binding from 449 label to I-PMSI is one-to-one. 451 The NLRI and the RTs of the originated I-PMSI A-D route are set as 452 specified in [RFC6514]. 454 Note that if a set of IR P-tunnels is joined in this manner, the 455 "discard from the wrong PE" procedures of [RFC6513] section 9.1.1 456 cannot be applied to that P-tunnel. Thus duplicate prevention on 457 such IR P-tunnels requires the use of either Single Forwarder 458 Selection ([RFC6513] section 9.1.2) or native PIM procedures 459 ([RFC6513] section 9.1.3). 461 4.2. Unadvertised P-tunnels 463 In [SMLS-MC], a procedure is defined for "Global Table Multicast", in 464 which a P-tunnel can be joined even if the P-tunnel has not been 465 previously advertised. See the sections of that document entitled 466 "Leaf A-D Route for Global Table Multicast" and "Constructing the 467 Rest of the Leaf A-D Route". The route key of the Leaf A-D route has 468 the form of the "S-PMSI Route-Type Specific NLRI" in this case, and 469 that should be considered to be the P-tunnel identifier. Note that 470 the procedure for finding the UMH is different in this case; the UMH 471 is the next hop of the best UMH-eligible route towards the "ingress 472 PE". See the section of that document entitled "Determining the 473 Upstream ABR/PE/ASBR (Upstream Node)". 475 5. The PTA's 'Tunnel Identifier' Field 477 If the "Tunnel Type" field of a PTA is set to "IR", its "Tunnel 478 Identifier" field is significant only when one of the following two 479 conditions holds: 481 o The PTA is carried by a Leaf A-D route, or 483 o The "Leaf Information Required" bit of the "Flags" field of the 484 PTA is not set. 486 If one of these conditions holds, then the "Tunnel Identifier" field 487 must contain a routable IP address of the originator of the route. 488 (See [RFC6514] sections 9.2.3.2.1 and 9.2.3.4.1 for the detailed 489 specification of the contents of this field.) This address is used 490 by the UMH to determine the unicast tunnel that it will use in order 491 to send data, along the IR P-tunnel identified by the route key, to 492 the originator of the Leaf A-D route. 494 The means by which the unicast tunnel is determined from this IP 495 address is outside the scope of this document. The means by which 496 the unicast tunnel is set up and maintained is also outside the scope 497 of this document. 499 Section 4 of [RFC6515] MUST be applied when a PTA is carried in a 500 Leaf A-D route, and describes how to determine whether the "Tunnel 501 Identifier" field carries an IPv4 or an IPv6 address. 503 If neither of the above conditions hold, then the "Tunnel Identifier" 504 field is of no significance, and MUST be ignored upon reception. 506 6. The PTA's 'MPLS Label' Field 508 When a PTA is carried by an S-PMSI A-D route or an Inter-AS I-PMSI 509 A-D route, and the "Tunnel Type" field is set to "IR", the "MPLS 510 Label" field is of no significance. In this case, it SHOULD be set 511 to zero upon transmission and MUST be ignored upon reception. 513 The "MPLS Label" field is significant only when the PTA appears 514 either in a Leaf A-D route or in an Intra-AS I-PMSI A-D route that 515 does not have the "Leaf Information Required" bit set. In these 516 cases, the MPLS label is the label that the originator of the route 517 is assigning to the IR P-tunnel(s) identified by the route's NLRI. 518 (That is, the MPLS label assigned in the PTA is what we have called 519 the "P-tunnel label".) 521 6.1. Leaf A-D Route Originated by an Egress PE 523 As previously stated, when a Leaf A-D route is used to join an IR 524 P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel 525 identifier. 527 We now define the notion of the "root of an IR P-tunnel". 529 o If the identifier of an IR P-tunnel is of the form of an S-PMSI 530 NLRI, the "root" of the P-tunnel is the router identified in the 531 "Originating Router's IP Address" field of that NLRI. 533 o If the identifier of an IR P-tunnel is of the form specified in 534 Section "Leaf A-D Route for Global Table Multicast" of [SMLS-MC], 535 the "root" of the P-tunnel is the router identified in the 536 "Ingress PE's IP Address" field of that NLRI. 538 o If the identifier of an IR P-tunnel is of the form of an Intra-AS 539 I-PMSI NLRI, the "root" of the P-tunnel is the router identified 540 in the "Originating Router's IP Address" field of that NLRI. 542 o If the identifier of an IR P-tunnel is of the form of an Inter-AS 543 I-PMSI NLRI, the "root" of the P-tunnel is same as the identifier 544 of the P-tunnel, i.e., the combination of an RD and an AS. 546 Note that if a P-tunnel is segmented, the root of the P-tunnel, by 547 this definition, is actually the root of the entire P-tunnel, not the 548 root of the local segment. 550 In order to apply the procedures of RFC 6513 Section 9.1.1 551 ("Discarding Packets from Wrong PE"), the following condition MUST be 552 met by the MPLS label allocation policy: 554 Suppose an egress PE originates two Leaf A-D routes, each with a 555 different route key in its NLRI, and each with a PTA specifying a 556 "Tunnel Type" of "IR". Thus each of the Leaf A-D routes 557 identifies a different IR P-tunnel. Suppose further that each of 558 those IR P-tunnels has a different root. Then the egress PE MUST 559 NOT specify the same MPLS label in both PMSI Tunnel attributes. 561 That is, to apply the "Discarding Packets from the Wrong PE" 562 duplicate prevention procedures ([RFC6513] section 9.1.1), the same 563 MPLS label MUST NOT be assigned to two IR P-tunnels that have 564 different roots. 566 If segmented P-tunnels are in use, the above rule is necessary but 567 not sufficient to prevent a PE from forwarding duplicate data to the 568 CEs. For various reasons, a given egress PE or egress ABR or egress 569 ASBR may decide to change its parent node, on a given segmented 570 P-tunnel, from one router to another. It does this by changing the 571 RT of the Leaf A-D route that it originated in order to join that 572 P-tunnel. Once the RT is changed, there may be a period of time 573 during which the old parent node and the new parent node are both 574 sending data of the same multicast flow. To ensure that the egress 575 node not forward duplicate data, whenever the egress node changes the 576 RT that it attaches to a Leaf A-D route, it MUST also change the 577 "MPLS Label" specified in the Leaf A-D route's PTA. This allows the 578 egress router to distinguish between packets arriving on a given 579 P-tunnel from the old parent and packets arriving on that same 580 P-tunnel from the new parent. At any given time, a router MUST 581 consider itself to have only a single parent node on a given 582 P-tunnel, and MUST discard traffic that arrives on that P-tunnel from 583 a different parent node. 585 If extranet functionality [MVPN-XNET] is not implemented in a 586 particular egress PE, or if an egress PE is provisioned with the 587 knowledge that extranet functionality is not needed, the PE may adopt 588 the policy of assigning a label that is unique for the ordered triple 589 . This will enable the egress PE to 590 apply the duplicate prevention procedures discussed above, and to 591 determine the VRF to which an arriving packet must be directed. 593 However, this policy is not sufficient to support the "Discard 594 Packets from the Wrong P-tunnel" procedures that are specified in 595 [MVPN-XNET]. To support those procedures, the labels specified in 596 the PTA of Leaf A-D routes originated by a given egress PE MUST be 597 unique for the ordered triple , where the 598 "root RD" is taken from the RD field of the IR P-tunnel identifier. 599 (All forms of IR P-tunnel identifier contain an embedded "RD" field.) 600 This policy is also sufficient for supporting non-extranet cases, but 601 in some cases may result in the use of more labels than the policy of 602 the previous paragraph. 604 6.2. Leaf A-D Route Originated by an Intermediate Node 606 When a P-tunnel is segmented, there will be "intermediate nodes" 607 (nodes that have a parent and also have children on the P-tunnel). 608 Each intermediate node is a leaf node of an "upstream segment" and a 609 parent node of a "downstream segment". The intermediate node 610 "splices" together the two segments, so that data it receives on the 611 upstream segment gets transmitted on the downstream segment. If 612 either the upstream or downstream segments (or both) are instantiated 613 by IR, the need to do this splicing places certain constraints on the 614 MPLS label allocation policy. 616 6.2.1. Upstream and Downstream Segments are IR Segments 618 An intermediate node N (i.e., a node that has a parent and also has 619 children) on an IR P-tunnel may originate a Leaf A-D route with a 620 particular route key as a result of receiving a Leaf A-D route with 621 that same route key. This will happen only if the received Leaf A-D 622 route carries an IP address specific RT whose Global Administrator 623 field identifies node N. 625 Suppose intermediate node N originates two Leaf A-D routes, one whose 626 route key is K1, and one whose route key is K2, where K1 != K2. In 627 general, the respective PTAs of these Leaf A-D routes MUST specify 628 distinct non-zero MPLS labels, such that it is possible to map 629 uniquely from the specified label value to a single IR P-tunnel (call 630 this the "uniqueness rule"). There is one exception to this rule; 631 the exception is specified below. 633 Consider the set of Leaf A-D routes with route key K1 or route key K2 634 such that: 636 o N has received these Leaf A-D routes and has them currently 637 installed. 639 o Each of these Leaf A-D routes carries an IP Address Specific Route 640 Target that identifies N in its Global Administrator field. 642 Now suppose that all the Leaf A-D routes in this set have the same 643 originating router, and that the PTAs of these Leaf A-D routes all 644 specify the same MPLS label. Suppose further that N's UMH for K1 is 645 the same as N's UMH for K2. In this particular case, N MAY specify 646 the same MPLS label in the PTA of Leaf A-D route it originates for K1 647 as in the PTA of he route it originates for K2. However, if at any 648 future time these conditions no longer hold, N must reoriginate at 649 least one of the Leaf A-D routes with a different label so that the 650 "uniqueness rule" holds. 652 6.2.2. Only One Segment is IR 654 To handle the case where an intermediate node, call it N, is splicing 655 together two P-tunnel segments, only one of which is IR, it is 656 necessary to generalize the rules of the preceding sub-section. 658 Suppose N is a leaf node of two (upstream) P-tunnel segments, call 659 them U1 and U2. Suppose also that N is a parent node of two 660 (downstream) P-tunnel segments, call them D1 and D2. And suppose 661 that N needs to splice U1 to D1, and U2 to D2. 663 To follow the uniqueness rule of Section 6.2.1 of this document, N 664 must assign a different MPLS label to U1 than it assigns to U2. How 665 this assignment is made depends, of course, on the control protocol 666 used to set up U1 and U2. 668 There is one case in which the uniqueness rule need not be followed. 669 Suppose that there is a node M such that (a) M is N's only child node 670 on D1, and (b) M is N's only child node on D2. M will have 671 advertised to N a label L1 bound to D1, and a label L2 bound to D2. 672 If (and for as long as) L1==L2, then N MAY violate the uniqueness 673 rule by advertising to its parent node for U1 the same MPLS label it 674 advertises to its parent node for U2. 676 Section 6.2.1 of this document specifies in detail the way this 677 requirement is applied when the upstream and downstream segments are 678 all IR segments. 680 6.3. Intra-AS I-PMSI A-D Route 682 When a router joins a set of IR P-tunnels using the procedures of 683 Section 4.1.2 of this document, the procedures of section 9.1.1 of 684 [RFC6513] cannot be applied, no matter what the label allocation 685 policy is. In this case, the ingress PE is the same as the UMH, but 686 it is not possible to assign a label uniquely to a particular ingress 687 PE or UMH. However, the label in the MPLS label field of the PTA 688 MUST NOT appear in the MPLS label field of the PTA carried by any 689 other route originated by the same router. 691 7. How A Child Node Prunes Itself from an IR P-tunnel 693 If a particular IR P-tunnel was joined via the procedures of 694 Section 4.1.2 of this document, a router can prune itself from the 695 P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join 696 the P-tunnel. This is not usually done unless the router is removing 697 itself entirely from a particular MVPN. 699 The procedures in the remainder of this section apply when a router 700 joined a particular IR P-tunnel by originating a Leaf A-D route (as 701 described in Section 4.1.1 or Section 4.2 of this document). 703 If a router no longer has a need to receive any multicast data from a 704 given IR P-tunnel, it may prune itself from the P-tunnel by 705 withdrawing the Leaf A-D route it used to join the tunnel. This is 706 done, e.g., if the router no longer needs any of the flows traveling 707 over the P-tunnel, or if all the flows the router does need are being 708 received over other P-tunnels. 710 A router that is attached to a particular IR P-tunnel via a 711 particular parent node may determine that it needs to stay joined to 712 that P-tunnel, but via a different parent node. This can happen, for 713 example, if there is a change in the Next Hop or the P2MP Segmented 714 Next Hop Extended Community of the S-PMSI A-D route in which that 715 P-tunnel was advertised. In this case, the router changes the Route 716 Target of the Leaf A-D route it used to join the IR P-tunnel, so that 717 the Route Target now identifies the new parent node. 719 A parent node must notice when a child node has been pruned from a 720 particular tree, as this will affect the parent node's multicast data 721 state. Note that the pruning of a child node may appear to the 722 parent node as the explicit withdrawal of a Leaf A-D route, or it may 723 appear as a change in the Route Target of a Leaf A-D route. If the 724 Route Target of a particular Leaf A-D route previously identified a 725 particular parent node, but changes so that it no longer does so, the 726 effect on the multicast state of the parent node is the same as if 727 the Leaf A-D route had been explicitly withdrawn. 729 8. Parent Node Actions Upon Receiving Leaf A-D Route 731 These actions are detailed in [RFC6514] and [SMLS-MC]. Two points of 732 clarification are made: 734 o If a router R1 receives and installs a Leaf A-D route originated 735 by router R2, R1's multicast state is affected only if the Leaf 736 A-D route carries an "IP Address Specific RT" (or "IPv6 Address 737 Specific RT") whose "global administrator" field identifies R1. 739 (This is as specified in [RFC6514] and [SMLS-MC].) If a Leaf A-D 740 route's RT does not identify R1, but then changes so that it does 741 identify R1, R1 must take the same actions it would take if the 742 Leaf A-D route were newly received. 744 o It is possible that router R1 will receive and install a Leaf A-D 745 route originated by router R2, where: 747 * the route's RT identifies R1, 749 * the route's NLRI contains a route key whose first octet 750 indicates that it is identifying a P-tunnel advertised in an 751 S-PMSI A-D route, 753 * R1 has neither originated nor installed any such S-PMSI A-D 754 route. 756 If at some later time, R1 installs the corresponding S-PMSI A-D 757 route, and the Leaf A-D route is still installed, and the Leaf A-D 758 route's RT still identifies R1, then R1 MUST follow the same 759 procedures it would have followed if the S-PMSI A-D route had been 760 installed before the Leaf A-D route was installed. (I.e., 761 implementers must not assume that events occur in the "usual" or 762 "expected" order.) 764 9. Use of Timers when Switching UMH 766 Suppose a child node has joined a particular IR P-tunnel via a 767 particular UMH, and it now determines (for whatever reason) that it 768 needs to change its UMH on that P-tunnel. It does this by modifying 769 the RT of a Leaf A-D route. 771 It is desirable for such a "switch of UMH" to be done using a "make 772 before break" technique, so that the older UMH does not stop 773 transmitting the packets on the given P-tunnel to the child until the 774 newer UMH has a chance to start transmitting the packets on the given 775 P-tunnel to the child. However, the control plane operation 776 (modifying the RT of the Leaf A-D route) does not permit the child 777 node to first join the P-tunnel at the new UMH, and then later prune 778 itself from the old UMH; a single control plane operation has both 779 effects. Therefore, to achieve "make before break", timers must be 780 used as follows: 782 1. The old UMH must continue transmitting to the child node for a 783 period of time after it sees the child's Leaf A-D route being 784 withdrawn (or its RT changing to identify a different UMH). 786 2. The child node must continue to accept packets from the old UMH 787 for a period of time before it starts to accept packets from the 788 new UMH (and discard packets from the old). 790 Further, the timer in 1 should be longer than the timer in 2. This 791 allows the child to switch from one UMH to another without any loss 792 of data. 794 10. IANA Considerations 796 This document contains no actions for IANA. 798 11. Acknowledgments 800 The authors wish to thank Yakov Rekhter for his contributions to this 801 work. We also wish to thank Huajin Jeng and Samir Saad for their 802 contributions, and to thank Thomas Morin for pointing out some of the 803 issues that needed further elaboration. 805 Section 6.1 discusses the importance of having an MPLS label 806 allocation policy that, when ingress replication is used, allows an 807 egress PE to infer the identity of a received packet's ingress PE. 808 This issue was first raised in earlier work by Xu Xiaohu. 810 12. Security Considerations 812 No security considerations are raised by this document beyond those 813 already discussed in [RFC6513] and [RFC6514]. 815 13. References 817 13.1. Normative References 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, March 1997. 822 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 823 VPNs", RFC 6513, February 2012. 825 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 826 Encodings and Procedures for Multicast in MPLS/BGP IP 827 VPNs", RFC 6514, February 2012. 829 [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure 830 Addresses in BGP Updates for Multicast VPN", RFC 6515, 831 February 2012. 833 13.2. Informative References 835 [C-BIDIR-IR] 836 Zhang, J., Rekhter, Y., and A. Dolganow, "Simulating 837 'Partial Mesh of MP2MP P-Tunnels' with Ingress 838 Replication", internet-draft draft-ietf-l3vpn-mvpn-bidir- 839 ingress-replication-01, July 2014. 841 [MVPN-BIDIR] 842 Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, ""MVPN: 843 Using Bidirectional P-Tunnels", internet-draft draft-ietf- 844 l3vpn-mvpn-bidir-08, June 2014. 846 [MVPN-XNET] 847 Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP 848 MPLS VPNs", internet-draft draft-ietf-l3vpn-mvpn-extranet- 849 05, July 2014. 851 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 852 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 853 Tunnels", RFC 3209, December 2001. 855 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 856 Specification", RFC 5036, October 2007. 858 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 859 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 860 6625, May 2012. 862 [SMLS-MC] Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., 863 Leymann, N., and S. Saad, "Inter-Area P2MP Segmented 864 LSPs", internet-draft draft-ietf-mpls-seamless-mcast-14, 865 June 2014. 867 Authors' Addresses 869 Eric C. Rosen (editor) 870 Juniper Networks, Inc. 871 10 Technology Park Drive 872 Westford, Massachusetts 01886 873 US 875 Email: erosen@juniper.net 877 Karthik Subramanian 878 Cisco Systems, Inc. 879 170 Tasman Drive 880 San Jose, California 95134 881 US 883 Email: kartsubr@cisco.com 885 Jeffrey Zhang 886 Juniper Networks, Inc. 887 10 Technology Park Drive 888 Westford, Massachusetts 01886 889 US 891 Email: zzhang@juniper.net