idnits 2.17.1 draft-ietf-bess-mvpn-expl-track-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 22, 2017) is 2407 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: March 26, 2018 Z. Zhang 7 Juniper Networks, Inc. 8 September 22, 2017 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-03 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 March 26, 2018. 44 Copyright Notice 46 Copyright (c) 2017 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 . . . . . . . 8 66 5.1. General Egress Node Procedures . . . . . . . . . . . . . 8 67 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 9 68 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 12 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 [RFC6513] and [RFC6514] define the "Selective Provider Multicast 80 Service Interface Auto-Discovery route" (S-PMSI A-D route). By 81 originating one of these BGP routes, an ingress node advertises that 82 it is transmitting a particular multicast flow. In the terminology 83 of those RFCs, each flow is denoted by (C-S,C-G), where C-S is an IP 84 source address and C-G is an IP multicast address, both in the 85 address space of a VPN customer. The (C-S,C-G) of the multicast flow 86 is encoded into the Network Layer Reachability Information (NLRI) of 87 the S-PMSI A-D route. 89 Additionally, each S-PMSI A-D route contains a PMSI Tunnel attribute 90 (PTA), which identifies a tunnel through the provider backbone 91 network (a "P-tunnel"). If a P-tunnel is identified in the PTA of a 92 given S-PMSI A-D route, the originator of that route is advertising 93 that it will transmit the flow identified in the NLRI through the 94 tunnel identified in the PTA. 96 [RFC6513] and [RFC6514] also define a procedure that allows an 97 ingress node to determine the set of egress nodes that have requested 98 to receive a particular flow from that ingress node. The ability of 99 an ingress node to identify the egress nodes for a particular flow is 100 known as "explicit tracking". An ingress node requests explicit 101 tracking by setting a flag (the "Leaf Information Required" flag, or 102 LIR) in the PTA. When an egress node receives an S-PMSI A-D route 103 with LIR set, the egress node originates a Leaf A-D route whose NLRI 104 contains the NLRI from the corresponding S-PMSI A-D route. In this 105 way, the egress node advertises that it has requested to receive the 106 particular flow identified in the NLRI of that S-PMSI A-D route. 108 [RFC6513] and [RFC6514] also allow an ingress node to originate an 109 S-PMSI A-D route whose PTA has LIR set, but which does not identify 110 any P-tunnel. This mechanism can be used when it is desired to do 111 explicit tracking of a flow without at the same time binding that 112 flow to a particular P-tunnel. 114 [RFC6625] (and other RFCs that update it) extends the specification 115 of S-PMSI A-D routes, and allows an S-PMSI A-D route to encode a 116 wildcard in its NLRI. Either the C-S or the C-G or both can be 117 replaced by wildcards. These routes are known as (C-*,C-S) S-PMSI 118 A-D routes, or as (C-S,C-*) S-PMSI A-D routes, or as (C-*,C-*) S-PMSI 119 A-D routes, depending on whether the C-S or C-G or both have been 120 replaced by wildcards. These routes are known jointly as "wildcard 121 S-PMSI A-D routes". 123 One purpose of this document is to clarify the way that the explicit 124 tracking procedures of [RFC6513] and [RFC6514] are applied when 125 wildcard S-PMSI A-D routes are used. 127 In addition, this document addresses the following scenario, which is 128 not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an 129 ingress node originates an S-PMSI A-D route whose NLRI specifies, for 130 example, (C-*,C-*) (i.e., both C-S and C-G are replaced by 131 wildcards), and whose PTA identifies a particular P-tunnel. Now 132 suppose that the ingress node wants explicit tracking for each 133 individual flow that it transmits (following the procedures of 134 [RFC6625] on that P-tunnel. 136 In this example, if the ingress node sets LIR in the PTA of the 137 wildcard S-PMSI A-D route, each egress node that needs to receive a 138 flow from the ingress node will respond with a Leaf A-D route whose 139 NLRI specifies contains the (C-*,C-*) wildcard. This allows the 140 ingress node to determine the set of egress nodes that are receiving 141 flows from the ingress node. However, it does not allow the ingress 142 node to determine which flows are being received by which egress 143 nodes. 145 If the ingress node needs to determine which egress nodes are 146 receiving which flows, it needs to originate an S-PMSI A-D route for 147 each individual (C-S,C-G) flow that it is transmitting, and it needs 148 to set LIR in the PTA of each such route. However, since all the 149 flows are being sent through the tunnel identified in the (C-*,C-*) 150 S-PMSI A-D route, there is no need to identify a tunnel in the PTA of 151 each (C-S,C-G) S-PMSI A-D route. Per [RFC6514], the PTA of the 152 (C-S,C-G) S-PMSI A-D routes can specify "no tunnel information". 153 This procedure allows explicit tracking of individual flows, even 154 though all those flows are assigned to tunnels in widlcard S-PMSI A-D 155 routes. 157 Howver, this procedure requires several clarifications: 159 o The procedures of [RFC6625] do not clearly state how to handle an 160 S-PMSI A-D route if its NLRI contains wild cards, but its PTA 161 specifies "no tunnel info". 163 o If it is desired to send a set of flows through the same tunnel 164 (where that tunnel is advertised in a wildcard S-PMSI A-D route), 165 but it is also desired to explicitly track each individual flow 166 transmitted over that tunnel, one has to send an S-PMSI A-D route 167 (with LIR set in the PTA) for each individual flow. It would be 168 more optimal if the ingress node could just send a single wildcard 169 S-PMSI A-D route binding the set of flows to a particular tunnel, 170 and have the egress nodes respond with Leaf A-D routes for each 171 individual flow. 173 o [RFC6513] and [RFC6514] support the notion of "segmented 174 P-tunnels", where "segmentation" occurs at ASBRs; [RFC7524] 175 extends the notion segmented P-tunnels so that segmentation can 176 occur at ABRs. One can think of a segmented P-tunnel as passing 177 through a number of "segmentation domains". In each segmentation 178 domain, a given P-tunnel has an ingress node and a set of egress 179 nodes. The explicit tracking procedures allow an ingress node of 180 a particular segmentation domain to determine, for a particular 181 flow or set of flows, the egress nodes of that segmentation 182 domain. This has given rise to two further problems: 184 * The explicit tracking procedures do not allow an ingress node 185 to "see" past the boundaries of the segmentation domain. 187 This particular problem is not further addressed in this 188 revision of this document. 190 * The prior specifications do not make it very clear whether an 191 egress node, upon receiving an S-PMSI A-D route whose PTA 192 specifies "no tunnel information", is expected to forward the 193 S-PMSI A-D route, with the same PTA, to the next segmentation 194 domain. This document provides the necessary clarifications. 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 198 "OPTIONAL", when and only when appearing in all capital letters, are 199 to be interpreted as described in [RFC2119]. 201 2. The Explicit Tracking Flags 203 Prior specifications define one flag in the PTA, the "Leaf Info 204 Required" (LIR) flag, that is used for explicit tracking. 206 This document defines a new flag in the flags field of the PMSI 207 Tunnel attribute. This new flag is known as the "Leaf Info Required 208 per Flow" bit (LIR-pF). This flag MAY be set in the PTA of a 209 (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. (Use of this 210 flag in a PTA carried by other routes is outside the scope of this 211 document.) Support for this flag is OPTIONAL. 213 The action taken by an egress node when the LIR-pF bit is set is 214 detailed in Section 5. 216 If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA 217 SHOULD also be set. (By setting LIR as well as LIR-pF, one forces a 218 a response to be sent an egress node that does not support LIR-pF, 219 and it is possible to tell from that response that the egress node 220 does not support LIR-pF.) 222 3. Match for Tracking vs. Match for Reception 224 RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a 225 set of rules for finding the S-PMSI A-D route that is the "match for 226 reception" for a given (C-S,C-G) or (C-*,C-G) state. These rules do 227 not take into account the fact that some S-PMSI A-D routes may not be 228 carrying PTAs at all, or may be carrying PTAs that do not identify 229 any P-tunnel. (A PTA that does not identify any P-tunnel is one 230 whose "tunnel type" field has been set to "no tunnel information", as 231 specified in Section 5 of [RFC6514].) 233 The definition of "match for reception" in [RFC6625] is hereby 234 modified as follows: 236 When finding the "match for reception" for a given (C-S,C-G) or 237 (C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose 238 PTA specifying "no tunnel information". 240 We also introduce a new notion: the "match for tracking". This 241 differs from the "match for reception" as follows: 243 For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for 244 tracking" is chosen as follows. Ignore any S-PMSI A-D route that 245 has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies 246 "no tunnel information", but does not have either LIR or LIR-pF 247 set. (In particular, DO NOT ignore an S-PMSI A-D route that has a 248 PTA specifying "no tunnel information", but whose LIR or LIR-pF 249 bits are set). Then apply the rules (from [RFC6625] and other 250 documents that that update it) for finding the "match for 251 reception". The result (if any) is the match for tracking". 253 We will clarify this with a few examples. In these examples, we 254 assume that there is only one segmentation domain. In this case, the 255 ingress and egress nodes are Provider Edge (PE) routers. 257 Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 258 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has 259 installed the following two routes that were originated by PE2: 261 o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a 262 tunnel. 264 o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no 265 tunnel info" and has LIR set. 267 Route1 is (C-S1,C-G1)'s match for reception, and Route2 is 268 (C-S1,C-G1)'s match for tracking. 270 Continuing this example, suppose: 272 o PE1 has chosen PE2 as the upstream PE for a different flow, 273 (C-S2,C-G2). 275 o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). 277 In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for 278 tracking as well as its match for reception. 280 Also note that if a match for tracking does not have the LIR flag or 281 the LIR-pF flag set, no explicit tracking information will be 282 generated. See Section 5. 284 As another example, suppose PE1 has installed the following two 285 routes that were originated by PE2: 287 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 288 PTA specifies a tunnel) 290 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 291 tunnel. 293 Then Route2 is both the "match for reception" and the "match for 294 tracking" for (C-S1,C-G1). 296 Note that for a particular C-flow, PE1's match for reception might be 297 the same route as its match for tracking, or its match for reception 298 might be a "less specific" route than its match for tracking. But 299 its match for reception can never be a "more specific" route than its 300 match for tracking. 302 4. Ingress Node Initiation of Tracking 304 An ingress node that needs to initiate explicit tracking for a 305 particular flow or set of flows can do so by performing one of the 306 following procedures: 308 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 309 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 310 its NLRI, including a PTA in that route, and setting the LIR flag 311 in that PTA. The PTA may specify a particular tunnel, or may 312 specify "no tunnel info". 314 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 315 specify "no tunnel info" unless the ingress node also originates 316 an A-D route carrying a PTA that specifies the tunnel to be used 317 for carrying (C-S1,C-G1) traffic. Such a route could be an 318 I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) 319 S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. (There is no 320 point in requesting explicit tracking for a given flow if there 321 is no tunnel on which the flow is being carried.) 323 Further, if the ingress node originates a wildcard S-PMSI A-D 324 route carrying a PTA specifying the tunnel to be used for 325 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 326 set, then explicit tracking for (C-S1,C-G1) is requested by that 327 S-PMSI A-D route. Thus the ingress node SHOULD NOT originate a 328 (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel 329 info"; such a route would not provide any additional 330 functionality. 332 To terminate explicit tracking that has been initiated by an 333 S-PMSI A-D route whose PTA specifies "no tunnel info", the 334 ingress node withdraws the route. 336 To terminate explicit tracking that has been initiated by an 337 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 338 re-originates the route without the LIR flag set. 340 2. The following procedure can be used if (and only if) it is known 341 that the egress nodes support the optional LIR-pF flag. If the 342 ingress node originates a wildcard S-PMSI A-D route, it can 343 initiate explicit tracking for the individual flows that match 344 the wildcard route by setting the LIR-pF flag in the PTA of the 345 wildcard route. If an egress node needs to receive one or more 346 flows for which that wildcard route is a match for tracking, the 347 egress node will originate a Leaf A-D route for each such flow, 348 as specified in Section 5.2). 350 When following this procedure, the PTA of the S-PMSI A-D route 351 may specify a tunnel, or may specify "no tunnel info". The 352 choice between these two options is determined by considerations 353 that are outside the scope of this document. 355 To terminate explicit tracking that has been initiated by an 356 S-PMSI A-D route whose PTA specifies "no tunnel info", the 357 ingress node withdraws the route. 359 To terminate explicit tracking that has been initiated by an 360 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 361 re-originates the route without the LIR flag set 363 5. Egress Node Response to the Match for Tracking 365 5.1. General Egress Node Procedures 367 There are four cases to consider: 369 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 370 state, the egress node's match for tracking is same as its match 371 for reception, and neither LIR nor LIR-pF flags are on. 373 In this case, the egress node does not originate a Leaf A-D route 374 in response to the match for reception/tracking, and there is no 375 explicit tracking of the flow. This document specifies no new 376 procedures for this case. 378 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 379 state, the egress node's match for tracking is the same as its 380 match for reception, LIR is set, but LIR-pF is not set. 382 In this case, a Leaf A-D route is originated by the egress node, 383 corresponding to the S-PMSI A-D route that is the match for 384 reception/tracking. Construction of the Leaf A-D route is as 385 specified in [RFC6514]; this document specifies no new procedures 386 for this case. 388 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 389 state, the egress node's match for tracking is the same as its 390 match for reception, and LIR-pF is set. The egress PE MUST 391 follow whatever procedures are required by other specifications, 392 based on the match for reception. If the egress PE supports the 393 LIR-pF flag, it MUST also follow the procedures of Section 5.2. 395 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 396 state, the egress node's match for tracking is not the same as 397 its match for reception. This can only happen if the match for 398 tracking has a PTA specifying "no tunnel info", with either LIR 399 or LIR-pF set. In this case, the egress node must respond, 400 separately, BOTH to the match for tracking and to the match for 401 reception. 403 When responding to the match for reception, the egress node MUST 404 ignore the LIR-pF flag. However, the LIR flag is processed 405 normally per the procedures for the match for reception. 407 If the match for tracking has LIR set and if either (a) the 408 egress node does not support LIR-pF, or (b) LIR-pF is not set, 409 then the egress node must respond to the match for tracking, 410 following procedures specified in other documents for the case 411 where LIR is set. 413 If the match for tracking has LIR-pF set, and the egress node 414 supports the LIR-pF flag, the egress node must originate one or 415 more Leaf A-D routes, as specified in Section 5.2. 417 Note that if LIR is set in the PTA of the match for reception, 418 the egress node may need to originate one or more Leaf A-D routes 419 corresponding to the match for tracking, as well as originating a 420 Leaf A-D route corresponding to the match for reception. 422 5.2. Responding to the LIR-pF Flag 424 To respond to a match for tracking that has LIR-pF set, an egress 425 node originates one or more Leaf A-D routes. 427 Suppose the egress node has multicast state for a (C-S,C-G) or a 428 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 429 which has the LIR-pF flag set, to be the match for tracking for that 430 flow. Then if the egress node supports the LIR-pF flag, it MUST 431 originate a Leaf A-D route whose NLRI identifies that particular 432 flow. Note that if a single S-PMSI A-D route (with wild cards) is 433 the match for tracking for multiple flows, the egress PE may need to 434 originate multiple Leaf A-D routes, one for each such flow. We say 435 that, from the perspective of a given egress node, a given S-PMSI A-D 436 route tracks the set of flows for which it is the match for tracking. 437 Each of the Leaf A-D routes originated in response to that S-PMSI A-D 438 route tracks a single such flow. 440 The NLRI of each the Leaf A-D route that tracks a particular flow is 441 constructed as follows. The "route key" field of the NLRI will have 442 the following format: 444 +-----------------------------------+ 445 | RD (8 octets) | 446 +-----------------------------------+ 447 | Multicast Source Length (1 octet) | 448 +-----------------------------------+ 449 | Multicast Source (Variable) | 450 +-----------------------------------+ 451 | Multicast Group Length (1 octet) | 452 +-----------------------------------+ 453 | Multicast Group (Variable) | 454 +-----------------------------------+ 455 | Ingress PE's IP address | 456 +-----------------------------------+ 458 Figure 1: NLRI of S-PMSI A-D Route 460 o The "ingress PE" address is taken from the "originating router" 461 field of the NLRI of the S-PMSI A-D route that is the match for 462 tracking. 464 o The multicast source and group fields specify the S and G of one 465 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 466 is being tracked by this Leaf A-D route, the source field is 467 omitted, and its length is set to 0. 469 o The RD field is constructed as follows: 471 * Take the RD value from the NLRI of the S-PMSI A-D route. 473 * Add 16 to the second octet of the RD. 475 Note that, per RFC4364, every RD begins with a two-octet type field 476 that is either 0, 1, or 2. By adding 16 to the second octet of the 477 RD, we force the type field to be 16, 17, or 18. The presence of one 478 of these values will indicate that the Leaf A-D route was constructed 479 in response to a less specific S-PMSI A-D route that had the LIR-pF 480 bit set. (That is, it distinguishes the routes from "ordinary" MVPN 481 Leaf A-D routes.) 483 The encoding of these Leaf A-D routes is similar to the encoding of 484 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 485 were designed for the support of "global table multicast". However, 486 that document sets the RD to either 0 or -1; following the procedures 487 of this document, the RD will never be 0 or -1. Therefore Leaf A-D 488 routes constructed according to the procedures of this section can 489 always be distinguished from the Leaf A-D routes constructed 490 according to the procedures of section 6.2.2 of [RFC7524]. Also, 491 Leaf A-D routes constructed according to the procedures of this 492 section are VPN-specific routes, and will always carry an IP-address- 493 specific Route Target, as specified in [RFC6514]. 495 If a Leaf A-D route is originated as a response to a match for 496 tracking whose PTA specifies "no tunnel info", a PTA SHOULD NOT be 497 attached to the Leaf A-D route; if a PTA is attached, it MUST specify 498 "no tunnel info". 500 In the case where the match for tracking and the match for reception 501 are the same, the PTA of the match may have both the LIR and the LIR- 502 pF flags set. This may cause the egress node to originate one Leaf 503 A-D route in response to the LIR bit, and one or more Leaf A-D routes 504 in response to the LIR-pF bit. A PTA SHOULD NOT be attached to the 505 Leaf A-D routes that are originated in response to the LIR-pF bit. 507 When a Leaf A-D route constructed according to the procedures of this 508 section is received, it MUST be processed by the node identified in 509 its IP-address-specific Route Target, even though its "route key" 510 field does not correspond to the NLRI of any S-PMSI A-D route. 512 Of course, an egress node that originates such Leaf A-D routes needs 513 to remember which S-PMSI A-D route caused these Leaf A-D routes to be 514 originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D 515 routes MUST be withdrawn. 517 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 518 or explicitly) if the egress node changes its Upstream Multicast Hop 519 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 520 route's NLRI, or if the egress node that originated the route no 521 longer needs to receive the flow identified in the NLRI of the route. 523 Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G) 524 state after it has already received the S-PMSI A-D that is the match 525 for tracking for that state. In this case, a Leaf A-D route needs to 526 be originated at that time, and the egress node must remember that 527 the new Leaf A-D route corresponds to that match for tracking. 529 Note that if a particular S-PMSI A-D route is a match for tracking 530 but not a match for reception, the LIR bit in its PTA is ignored if 531 the LIR-pF bit is set. 533 5.3. When the Egress Node is an ABR or ASBR 535 When segmented P-tunnels are used, the ingress and egress nodes may 536 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 537 S-PMSI A-D route also forwards that route. If the PTA of an 538 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 539 MAY change the PTA to specify a different tunnel type (as discussed 540 in [RFC6514] and/or [RFC7524]). 542 However, if the PTA of the installed S-PMSI A-D route specifies "no 543 tunnel info", the egress ABR/ASBR MUST pass the PTA along unchanged 544 when it forwards the S-PMSI A-D route. (That is, a PTA specifying 545 "no tunnel info" MUST NOT be changed into a PTA specifying a tunnel.) 546 Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR- 547 pF flags in the PTA MUST be passed along unchanged. 549 In the case where the egress node is a PE, it will know whether it 550 needs to receive a given flow by virtue of its having received a PIM 551 or IGMP Join for that flow from a CE. In the case where the egress 552 node is not a PE, but rather an ABR or ASBR, it will not know whether 553 it needs to receive a given flow unless it receives a Leaf A-D route 554 whose NLRI specifies that flow and whose IP-address-specific RT 555 specifies an address of the egress node. Therefore an egress ABR/ 556 ASBR MUST NOT originate a Leaf A-D route for a given flow UNLESS it 557 has an installed Leaf A-D route for that flow, received from further 558 downstream. 560 This will ensure that an egress ABR/ASBR only sends a Leaf A-D route 561 in response to a "match for tracking" if it is on the path to an 562 egress PE for the flow(s) identified in the corresponding S-PMSI A-D 563 route. 565 Then we can establish the following rule for egress ABRs/ASBRs. 566 Suppose an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is 567 X, and whose PTA (a) specifies "no tunnel info" and (b) has LIR set. 568 The egress ABR/ASBR should not immediately originate a Leaf A-D route 569 in response. Rather it should wait until it receives a Leaf A-D 570 route whose NLRI contains X in the "route key" field. If it receives 571 such a Leaf A-D route, it redistributes that route, but first it 572 changes that route's RT. The "global administrator" field of the 573 modified RT will be set to the IP address taken either from the 574 S-PMSI A-D route's next hop field, or from its Segmented P2MP Next 575 Hop Extended Community. (This is the same rule that is used for when 576 the PTA does specify a tunnel type.) 578 6. Acknowledgments 580 The authors wish to thank Robert Kebler for his ideas and comments. 582 7. IANA Considerations 584 The LIR-pF flag needs to be added to the "P-Multicast Service 585 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 586 Gateway Protocol (BGP) Parameters" registry. This registry is 587 defined in [RFC7902]. The requested value is Bit Position 2. This 588 document should be the reference. 590 IANA is requested to allocate three new types from the Route 591 Distinguisher Type Field registry: 593 o Administrator field is two-byte Autonomous System Number. To be 594 used only in certain MCAST-VPN Leaf A-D routes. 596 o Administrator field is four-byte IP Address. To be used only in 597 certain MCAST-VPN Leaf A-D routes. 599 o Administrator field is four-byte Autonomous System Number. To be 600 used only in certain MCAST-VPN Leaf A-D routes. 602 The requested values are 16, 17, and 18 respectively. 604 8. Security Considerations 606 The Security Considerations of [RFC6513] and [RFC6514] apply. 608 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 609 large number of Leaf A-D routes can be elicited. If this flag is set 610 when not desired (through either error or malfeasance), a significant 611 increase in control plane overhead can result. 613 9. References 615 9.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 623 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 624 2012, . 626 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 627 Encodings and Procedures for Multicast in MPLS/BGP IP 628 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 629 . 631 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 632 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 633 RFC 6625, DOI 10.17487/RFC6625, May 2012, 634 . 636 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 637 P-Multicast Service Interface Tunnel Attribute Flags", 638 RFC 7902, DOI 10.17487/RFC7902, June 2016, 639 . 641 9.2. Informative References 643 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 644 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 645 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 646 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 647 . 649 Authors' Addresses 651 Andrew Dolganow 652 Nokia 653 438B Alexandra Rd #08-07/10 654 Alexandra Technopark 655 Singapore 119968 657 Email: andrew.dolganow@nokia.com 659 Jayant Kotalwar 660 Nokia 661 701 East Middlefield Rd 662 Mountain View, California 94043 663 United States 665 Email: jayant.kotalwar@nokia.com 666 Eric C. Rosen (editor) 667 Juniper Networks, Inc. 668 10 Technology Park Drive 669 Westford, Massachusetts 01886 670 United States 672 Email: erosen@juniper.net 674 Zhaohui Zhang 675 Juniper Networks, Inc. 676 10 Technology Park Drive 677 Westford, Massachusetts 01886 678 United States 680 Email: zzhang@juniper.net