idnits 2.17.1 draft-ietf-bess-mvpn-expl-track-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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). -- The document date (January 31, 2018) is 2270 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG A. Dolganow 3 Internet-Draft J. Kotalwar 4 Updates: 6625 (if approved) Nokia 5 Intended status: Standards Track E. Rosen, Ed. 6 Expires: August 4, 2018 Z. Zhang 7 Juniper Networks, Inc. 8 January 31, 2018 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-06 13 Abstract 15 The MVPN specifications provide procedures to allow a multicast 16 ingress node to invoke "explicit tracking" for a multicast flow or 17 set of flows, thus learning the egress nodes for that flow or set of 18 flows. However, the specifications are not completely clear about 19 how the explicit tracking procedures work in certain scenarios. This 20 document provides the necessary clarifications. It also specifies a 21 new, optimized explicit tracking procedure. This new procedure 22 allows an ingress node, by sending a single message, to request 23 explicit tracking of each of a set of flows, where the set of flows 24 is specified using a wildcard mechanism. This document updates 25 RFC6625. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 4, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. The Explicit Tracking Flags . . . . . . . . . . . . . . . . . 5 63 3. Match for Tracking vs. Match for Reception . . . . . . . . . 5 64 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 7 65 5. Egress Node Response to the Match for Tracking . . . . . . . 9 66 5.1. General Egress Node Procedures . . . . . . . . . . . . . 9 67 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 10 68 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 12 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 9.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 [RFC6513] and [RFC6514] define the "Selective Provider Multicast 80 Service Interface Auto-Discovery route" (S-PMSI A-D route). 82 Per those RFCs, the S-PMSI A-D route contains a Network Layer 83 Reachability Information (NLRI) field that identifies a particular 84 multicast flow. In the terminology of those RFCs, each flow is 85 denoted by (C-S,C-G), where C-S is an IP source address and C-G is an 86 IP multicast address, both in the address space of a VPN customer. 87 The (C-S,C-G) of the multicast flow is encoded into the NLRI field. 89 An S-PMSI A-D route also carries a PMSI Tunnel attribute (PTA). 90 Typically, the PTA is used to identify a tunnel through the provider 91 backbone network (a "P-tunnel"). 93 By originating an S-PMSI A-D route identifying a particular multicast 94 flow and a particular P-tunnel, a node is advertising the following: 96 if the node has to transmit packets of the identified flow over 97 the backbone, it will transmit them through the identified tunnel. 99 [RFC6513] and [RFC6514] also define a procedure that allows an 100 ingress node of particular multicast flow to determine the set of 101 egress nodes that have requested to receive that flow from that 102 ingress node. The ability of an ingress node to identify the egress 103 nodes for a particular flow is known as "explicit tracking". An 104 ingress node requests explicit tracking by setting a flag (the "Leaf 105 Information Required" flag, or LIR) in the PTA. When an egress node 106 receives an S-PMSI A-D route with LIR set, the egress node originates 107 a Leaf A-D route whose NLRI field contains the NLRI from the 108 corresponding S-PMSI A-D route. In this way, the egress node 109 advertises that it has requested to receive the particular flow 110 identified in the NLRI of that S-PMSI A-D route. 112 [RFC6513] and [RFC6514] also allow an ingress node to originate an 113 S-PMSI A-D route whose PTA has LIR set, but which does not identify 114 any P-tunnel. This mechanism can be used when it is desired to do 115 explicit tracking of a flow without at the same time binding that 116 flow to a particular P-tunnel. 118 [RFC6625] (and other RFCs that update it) extends the specification 119 of S-PMSI A-D routes, and allows an S-PMSI A-D route to encode a 120 wildcard in its NLRI. Either the C-S or the C-G or both can be 121 replaced by wildcards. These routes are known as (C-*,C-S) S-PMSI 122 A-D routes, or as (C-S,C-*) S-PMSI A-D routes, or as (C-*,C-*) S-PMSI 123 A-D routes, depending on whether the C-S or C-G or both have been 124 replaced by wildcards. These routes are known jointly as "wildcard 125 S-PMSI A-D routes". 127 One purpose of this document is to clarify the way that the explicit 128 tracking procedures of [RFC6513] and [RFC6514] are applied when 129 wildcard S-PMSI A-D routes are used. 131 In addition, this document addresses the following scenario, which is 132 not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an 133 ingress node originates an S-PMSI A-D route whose NLRI specifies, for 134 example, (C-*,C-*) (i.e., both C-S and C-G are replaced by 135 wildcards), and whose PTA identifies a particular P-tunnel. Now 136 suppose that the ingress node wants explicit tracking for each 137 individual flow that it transmits (following the procedures of 138 [RFC6625]) on that P-tunnel. 140 In this example, if the ingress node sets LIR in the PTA of the 141 wildcard S-PMSI A-D route, each egress node that needs to receive a 142 flow from the ingress node will respond with a Leaf A-D route whose 143 NLRI specifies contains the (C-*,C-*) wildcard. This allows the 144 ingress node to determine the set of egress nodes that are interested 145 in receiving flows from the ingress node. However, it does not allow 146 the ingress node to determine exactly which flows are of interest to 147 which egress nodes. 149 If the ingress node needs to determine which egress nodes are 150 interested in receiving which flows, it needs to originate an S-PMSI 151 A-D route for each individual (C-S,C-G) flow that it is transmitting, 152 and it needs to set LIR in the PTA of each such route. However, 153 since all the flows are being sent through the tunnel identified in 154 the (C-*,C-*) S-PMSI A-D route, there is no need to identify a tunnel 155 in the PTA of each (C-S,C-G) S-PMSI A-D route. Per [RFC6514], the 156 PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel 157 information". This procedure allows explicit tracking of individual 158 flows, even though all those flows are assigned to tunnels in 159 wildcard S-PMSI A-D routes. 161 However, this procedure requires several clarifications: 163 o The procedures of [RFC6625] do not clearly state how to handle an 164 S-PMSI A-D route if its NLRI contains wild cards, but its PTA 165 specifies "no tunnel info". 167 o If it is desired to send a set of flows through the same tunnel 168 (where that tunnel is advertised in a wildcard S-PMSI A-D route), 169 but it is also desired to explicitly track each individual flow 170 transmitted over that tunnel, one has to send an S-PMSI A-D route 171 (with LIR set in the PTA) for each individual flow. It would be 172 more optimal if the ingress node could just send a single wildcard 173 S-PMSI A-D route binding the set of flows to a particular tunnel, 174 and have the egress nodes respond with Leaf A-D routes for each 175 individual flow. 177 o [RFC6513] and [RFC6514] support the notion of "segmented 178 P-tunnels", where "segmentation" occurs at Autonomous System 179 Border Routers (ASBRs); [RFC7524] extends the notion of segmented 180 P-tunnels so that segmentation can occur at Area Border Routers 181 (ABRs). One can think of a segmented P-tunnel as passing through 182 a number of "segmentation domains". In each segmentation domain, 183 a given P-tunnel has an ingress node and a set of egress nodes. 184 The explicit tracking procedures allow an ingress node of a 185 particular segmentation domain to determine, for a particular flow 186 or set of flows, the egress nodes of that segmentation domain. 187 This has given rise to two further problems: 189 * The explicit tracking procedures do not allow an ingress node 190 to "see" past the boundaries of the segmentation domain. 192 * The prior specifications do not make it very clear whether a 193 segmented tunnel egress node, upon receiving an S-PMSI A-D 194 route whose PTA specifies "no tunnel information", is expected 195 to forward the S-PMSI A-D route, with the same PTA, to the next 196 segmentation domain. 198 These problems are addressed in Section 5.3. 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL", when and only when appearing in all capital letters, are 203 to be interpreted as described in [RFC2119]. 205 2. The Explicit Tracking Flags 207 [RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR) 208 flag, that is used for explicit tracking. 210 This document defines a new flag in the flags field of the PMSI 211 Tunnel attribute. This new flag is known as the "Leaf Info Required 212 per Flow" bit (LIR-pF). This flag MAY be set in the PTA of a 213 (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. (Use of this 214 flag in a PTA carried by other routes is outside the scope of this 215 document.) Support for this flag is OPTIONAL. 217 The action taken by an egress node when the LIR-pF bit is set is 218 detailed in Section 5. 220 If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA 221 SHOULD also be set. (By setting LIR as well as LIR-pF, one forces a 222 a response to be sent by an egress node that does not support LIR-pF, 223 and it is possible to tell from that response that the egress node 224 does not support LIR-pF.) 226 3. Match for Tracking vs. Match for Reception 228 Section 3.2 of [RFC6625] specifies a set of rules for finding the 229 S-PMSI A-D route that is the "match for data reception" (or more 230 simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) 231 state. These rules do not take into account the fact that some 232 S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying 233 PTAs that do not identify any P-tunnel. (A PTA that does not 234 identify any P-tunnel is one whose "tunnel type" field has been set 235 to "no tunnel information", as specified in Section 5 of [RFC6514].) 237 The rules for finding a "match for reception" in [RFC6625] are hereby 238 modified as follows: 240 When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it 241 is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or 242 whose PTA specifies "no tunnel information". 244 There are other RFCS that update [RFC6625] and that modify the rules 245 for finding a "match for reception". See, e.g., [RFC7582] and 246 [RFC7900]. When applying those modified rules, it is REQUIRED to 247 ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies 248 "no tunnel information". 250 We also introduce a new notion: the "match for tracking". This 251 differs from the "match for reception" as follows: 253 For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for 254 tracking" is chosen as follows. Ignore any S-PMSI A-D route that 255 has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies 256 "no tunnel information", but does not have either LIR or LIR-pF 257 set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA 258 specifying "no tunnel information" unless its LIR and LIR-pF bits 259 are both clear). Then apply the rules (from [RFC6625] and other 260 documents that that update it) for finding the "match for 261 reception". The result (if any) is the match for tracking". 263 We will clarify this with a few examples. In these examples, we 264 assume that there is only one segmentation domain. In this case, the 265 ingress and egress nodes are Provider Edge (PE) routers. 267 Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 268 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has 269 installed the following two routes that were originated by PE2: 271 o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a 272 tunnel. 274 o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no 275 tunnel info" and has LIR set. 277 Route1 is (C-S1,C-G1)'s match for reception, and Route2 is 278 (C-S1,C-G1)'s match for tracking. 280 Continuing this example, suppose: 282 o PE1 has chosen PE2 as the upstream PE for a different flow, 283 (C-S2,C-G2). 285 o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). 287 In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for 288 tracking as well as its match for reception. 290 Also note that if a match for tracking does not have the LIR flag or 291 the LIR-pF flag set, no explicit tracking information will be 292 generated. See Section 5. 294 As another example, suppose PE1 has installed the following two 295 routes that were originated by PE2: 297 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 298 PTA specifies a tunnel) 300 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 301 tunnel. 303 Then Route2 is both the "match for reception" and the "match for 304 tracking" for (C-S1,C-G1). 306 Note that for a particular C-flow, PE1's match for reception might be 307 the same route as its match for tracking, or its match for reception 308 might be a "less specific" route than its match for tracking. But 309 its match for reception can never be a "more specific" route than its 310 match for tracking. 312 4. Ingress Node Initiation of Tracking 314 An ingress node that needs to initiate explicit tracking for a 315 particular flow or set of flows can do so by performing one of the 316 following procedures: 318 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 319 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 320 its NLRI, including a PTA in that route, and setting the LIR flag 321 in that PTA. The PTA may specify a particular tunnel, or may 322 specify "no tunnel info". 324 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 325 specify "no tunnel info" unless the ingress node also originates 326 an A-D route carrying a PTA that specifies the tunnel to be used 327 for carrying (C-S1,C-G1) traffic. Such a route could be an 328 I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) 329 S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. (There is no 330 point in requesting explicit tracking for a given flow if there 331 is no tunnel on which the flow is being carried.) 333 Note that if the ingress node originates a wildcard S-PMSI A-D 334 route carrying a PTA specifying the tunnel to be used for 335 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 336 set, then explicit tracking for (C-S1,C-G1) is requested by that 337 S-PMSI A-D route. In that case, the ingress node SHOULD NOT 338 originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no 339 tunnel info"; such a route would not provide any additional 340 functionality. 342 To terminate explicit tracking that has been initiated by an 343 S-PMSI A-D route whose PTA specifies "no tunnel info", the 344 ingress node withdraws the route. 346 To terminate explicit tracking that has been initiated by an 347 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 348 re-originates the route without the LIR flag set. 350 2. The following procedure can be used if and only if it is known 351 that the egress nodes support the optional LIR-pF flag. If the 352 ingress node originates a wildcard S-PMSI A-D route, it can 353 initiate explicit tracking for the individual flows that match 354 the wildcard route by setting the LIR-pF flag in the PTA of the 355 wildcard route. If an egress node needs to receive one or more 356 flows for which that wildcard route is a match for tracking, the 357 egress node will originate a Leaf A-D route for each such flow, 358 as specified in Section 5.2). 360 When following this procedure, the PTA of the S-PMSI A-D route 361 may specify a tunnel, or may specify "no tunnel info". The 362 choice between these two options is determined by considerations 363 that are outside the scope of this document. 365 To terminate explicit tracking that has been initiated by an 366 S-PMSI A-D route whose PTA specifies "no tunnel info", the 367 ingress node withdraws the route. 369 To terminate explicit tracking that has been initiated by an 370 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 371 re-originates the route without either the LIR or LIR-pF flags 372 set. 374 Note that this procedure (procedure 2 of Section 4) may not yield 375 the expected results if there are egress nodes that do not 376 support the LIR-pF flag, and hence SHOULD NOT be used in that 377 case. 379 5. Egress Node Response to the Match for Tracking 381 5.1. General Egress Node Procedures 383 There are four cases to consider: 385 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 386 state, the egress node's match for tracking is same as its match 387 for reception, and neither LIR nor LIR-pF flags are on. 389 In this case, the egress node does not originate a Leaf A-D route 390 in response to the match for reception/tracking, and there is no 391 explicit tracking of the flow. This document specifies no new 392 procedures for this case. 394 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 395 state, the egress node's match for tracking is the same as its 396 match for reception, LIR is set, but LIR-pF is not set. 398 In this case, a Leaf A-D route is originated by the egress node, 399 corresponding to the S-PMSI A-D route that is the match for 400 reception/tracking. Construction of the Leaf A-D route is as 401 specified in [RFC6514]; this document specifies no new procedures 402 for this case. 404 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 405 state, the egress node's match for tracking is the same as its 406 match for reception, and LIR-pF is set. The egress node MUST 407 follow whatever procedures are required by other specifications, 408 based on the match for reception. If the egress node supports 409 the LIR-pF flag, it MUST also follow the procedures of 410 Section 5.2. 412 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 413 state, the egress node's match for tracking is not the same as 414 its match for reception. This can only happen if the match for 415 tracking has a PTA specifying "no tunnel info", with either LIR 416 or LIR-pF set. In this case, the egress node must respond, 417 separately, BOTH to the match for tracking and to the match for 418 reception. 420 When responding to the match for reception, the egress node MUST 421 ignore the LIR-pF flag. However, the LIR flag is processed 422 normally per the procedures for the match for reception. 424 If the match for tracking has LIR set and if either (a) the 425 egress node does not support LIR-pF, or (b) LIR-pF is not set, 426 then the egress node must respond to the match for tracking, 427 following procedures specified in other documents for the case 428 where LIR is set. 430 If the match for tracking has LIR-pF set, and the egress node 431 supports the LIR-pF flag, the egress node must originate one or 432 more Leaf A-D routes, as specified in Section 5.2. 434 Note that if LIR is set in the PTA of the match for reception, 435 the egress node may need to originate one or more Leaf A-D routes 436 corresponding to the match for tracking, as well as originating a 437 Leaf A-D route corresponding to the match for reception. 439 5.2. Responding to the LIR-pF Flag 441 To respond to a match for tracking that has LIR-pF set, an egress 442 node originates one or more Leaf A-D routes. 444 Suppose the egress node has multicast state for a (C-S,C-G) or a 445 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 446 which has the LIR-pF flag set, to be the match for tracking for that 447 flow. Then if the egress node supports the LIR-pF flag, it MUST 448 originate a Leaf A-D route whose NLRI identifies that particular 449 flow. Note that if a single S-PMSI A-D route (with wild cards) is 450 the match for tracking for multiple flows, the egress node may need 451 to originate multiple Leaf A-D routes, one for each such flow. We 452 say that, from the perspective of a given egress node, a given S-PMSI 453 A-D route tracks the set of flows for which it is the match for 454 tracking. Each of the Leaf A-D routes originated in response to that 455 S-PMSI A-D route tracks a single such flow. 457 The NLRI of each the Leaf A-D route that tracks a particular flow is 458 constructed as follows. The "route key" field of the NLRI will have 459 the following format: 461 +-----------------------------------+ 462 | RD (8 octets) | 463 +-----------------------------------+ 464 | Multicast Source Length (1 octet) | 465 +-----------------------------------+ 466 | Multicast Source (Variable) | 467 +-----------------------------------+ 468 | Multicast Group Length (1 octet) | 469 +-----------------------------------+ 470 | Multicast Group (Variable) | 471 +-----------------------------------+ 472 | Ingress PE's IP address | 473 +-----------------------------------+ 475 Figure 1: NLRI of S-PMSI A-D Route 477 o The "ingress PE" address is taken from the "originating router" 478 field of the NLRI of the S-PMSI A-D route that is the match for 479 tracking. 481 o The multicast source and group fields specify the S and G of one 482 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 483 is being tracked by this Leaf A-D route, the source field is 484 omitted, and its length is set to 0. 486 o The Route Distinguisher (RD) field is constructed as follows: 488 * Take the RD value from the NLRI of the S-PMSI A-D route. 490 * Per [RFC4364], every RD begins with a two-octet type field that 491 is either 0, 1, or 2. Change the value of this two-octet type 492 field to TBD1, TBD2, or TBD3, respectively. (See Section 7, 493 IANA Considerations.) 495 The presence of one of these values will indicate that the Leaf 496 A-D route was constructed in response to a less specific S-PMSI 497 A-D route that had the LIR-pF bit set. (That is, it 498 distinguishes the routes from "ordinary" MVPN Leaf A-D routes.) 500 The encoding of these Leaf A-D routes is similar to the encoding of 501 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 502 were designed for the support of "global table multicast". However, 503 that document sets the RD to either 0 or -1; following the procedures 504 of this document, the RD will never be 0 or -1. Therefore Leaf A-D 505 routes constructed according to the procedures of this section can 506 always be distinguished from the Leaf A-D routes constructed 507 according to the procedures of section 6.2.2 of [RFC7524]. Also, 508 Leaf A-D routes constructed according to the procedures of this 509 section are VPN-specific routes, and will always carry an IP-address- 510 specific Route Target, as specified in [RFC6514]. 512 If a Leaf A-D route is originated as a response to a match for 513 tracking whose PTA specifies "no tunnel info", a PTA SHOULD NOT be 514 attached to the Leaf A-D route; if a PTA is attached, it MUST specify 515 "no tunnel info". 517 In the case where the match for tracking and the match for reception 518 are the same, the PTA of the match may have both the LIR and the LIR- 519 pF flags set. This may cause the egress node to originate one Leaf 520 A-D route in response to the LIR bit, and one or more Leaf A-D routes 521 in response to the LIR-pF bit. A PTA SHOULD NOT be attached to the 522 Leaf A-D routes that are originated in response to the LIR-pF bit. 524 When a Leaf A-D route constructed according to the procedures of this 525 section is received, it MUST be processed by the node identified in 526 its IP-address-specific Route Target, even though its "route key" 527 field does not correspond to the NLRI of any S-PMSI A-D route. 529 Of course, an egress node that originates such Leaf A-D routes needs 530 to remember which S-PMSI A-D route caused these Leaf A-D routes to be 531 originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D 532 routes MUST be withdrawn. 534 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 535 or explicitly) if the egress node changes its Upstream Multicast Hop 536 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 537 route's NLRI, or if the egress node that originated the route no 538 longer needs to receive the flow identified in the NLRI of the route. 540 Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G) 541 state after it has already received the S-PMSI A-D that is the match 542 for tracking for that state. In this case, a Leaf A-D route needs to 543 be originated at that time, and the egress node must remember that 544 the new Leaf A-D route corresponds to that match for tracking. 546 Note that if a particular S-PMSI A-D route is a match for tracking 547 but not a match for reception, the LIR bit in its PTA is ignored if 548 the LIR-pF bit is set. 550 5.3. When the Egress Node is an ABR or ASBR 552 When segmented P-tunnels are used, the ingress and egress nodes may 553 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 554 S-PMSI A-D route also forwards that route. If the PTA of an 555 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 556 MAY change the PTA to specify a different tunnel type (as discussed 557 in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to 558 originate a Leaf A-D route, as specified in [RFC6514] and/or 559 [RFC7524]. 561 Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, 562 and also has LIR-pF set. The egress ABR/ASBR originates a 563 corresponding Leaf A-D route for a given (C-S,C-G) only if it knows 564 that it needs to receive that flow. It will know this by virtue of 565 receiving a corresponding Leaf A-D route from downstream. (In the 566 case where the PTA specifies a tunnel but LIR-pF is not set, this 567 document does not specify any new procedures.) 569 The procedures in the remainder of this section apply only when an 570 egress ABR/ASBR has installed an S-PMSI A-D route whose PTA specifies 571 "no tunnel info" but has LIR or LIR-pF set. 573 If the PTA of the installed S-PMSI A-D route specifies "no tunnel 574 info", the egress ABR/ASBR MUST pass the PTA along unchanged when it 575 forwards the S-PMSI A-D route. (That is, a PTA specifying "no tunnel 576 info" MUST NOT be changed into a PTA specifying a tunnel.) 577 Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR- 578 pF flags in the PTA MUST be passed along unchanged. 580 As a result of propagating such an S-PMSI A-D route, the egress ABR/ 581 ASBR may receive one or more Leaf A-D routes that correspond to that 582 S-PMSI A-D route. These routes will be received carrying an IP- 583 address-specific Route Target (RT) Extended Community that specifies 584 the address of the egress ABR/ASBR. The egress ABR/ASBR will 585 propagate these Leaf A-D routes, after changing the RT as follows. 586 The "global administrator" field of the modified RT will be set to 587 the IP address taken either from the S-PMSI A-D route's next hop 588 field ([RFC6514]), or from its Segmented P2MP Next Hop Extended 589 Community ([RFC7524]). 591 This procedure enables the ingress PE to explicitly track the egress 592 PEs for a given flow, even if segmented tunnels are being used. 593 However, cross-domain explicit tracking utilizes S-PMSI A-D routes 594 that do not specify tunnel information; therefore it can only be done 595 when the S-PMSI A-D route which is a flow's match for tracking is 596 different than the S-PMSI A-D route which is that flow's match for 597 reception. 599 6. Acknowledgments 601 The authors wish to thank Robert Kebler for his ideas and comments. 603 7. IANA Considerations 605 The LIR-pF flag needs to be added to the "P-Multicast Service 606 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 607 Gateway Protocol (BGP) Parameters" registry. This registry is 608 defined in [RFC7902]. The requested value is Bit Position 2. This 609 document should be the reference. 611 IANA is requested to allocate three new types from the Route 612 Distinguisher Type Field registry: 614 o TBD1: Administrator field is two-byte Autonomous System Number. 615 To be used only in certain MCAST-VPN Leaf A-D routes. 617 o TBD2: Administrator field is four-byte IP Address. To be used 618 only in certain MCAST-VPN Leaf A-D routes. 620 o TBD3: Administrator field is four-byte Autonomous System Number. 621 To be used only in certain MCAST-VPN Leaf A-D routes. 623 The requested values are 16, 17, and 18 respectively. 625 8. Security Considerations 627 The Security Considerations of [RFC6513] and [RFC6514] apply. 629 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 630 large number of Leaf A-D routes can be elicited. If this flag is set 631 when not desired (through either error or malfeasance), a significant 632 increase in control plane overhead can result. 634 9. References 636 9.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 644 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 645 2006, . 647 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 648 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 649 2012, . 651 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 652 Encodings and Procedures for Multicast in MPLS/BGP IP 653 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 654 . 656 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 657 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 658 RFC 6625, DOI 10.17487/RFC6625, May 2012, 659 . 661 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 662 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 663 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 664 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 665 . 667 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 668 P-Multicast Service Interface Tunnel Attribute Flags", 669 RFC 7902, DOI 10.17487/RFC7902, June 2016, 670 . 672 9.2. Informative References 674 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 675 "Multicast Virtual Private Network (MVPN): Using 676 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 677 July 2015, . 679 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 680 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 681 RFC 7900, DOI 10.17487/RFC7900, June 2016, 682 . 684 Authors' Addresses 686 Andrew Dolganow 687 Nokia 688 438B Alexandra Rd #08-07/10 689 Alexandra Technopark 690 Singapore 119968 691 Singapore 693 Email: andrew.dolganow@nokia.com 694 Jayant Kotalwar 695 Nokia 696 701 East Middlefield Rd 697 Mountain View, California 94043 698 United States of America 700 Email: jayant.kotalwar@nokia.com 702 Eric C. Rosen (editor) 703 Juniper Networks, Inc. 704 10 Technology Park Drive 705 Westford, Massachusetts 01886 706 United States of America 708 Email: erosen@juniper.net 710 Zhaohui Zhang 711 Juniper Networks, Inc. 712 10 Technology Park Drive 713 Westford, Massachusetts 01886 714 United States of America 716 Email: zzhang@juniper.net