idnits 2.17.1 draft-ietf-bess-mvpn-expl-track-00.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 (June 20, 2016) is 2860 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: December 22, 2016 Z. Zhang 7 Juniper Networks, Inc. 8 June 20, 2016 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-00 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 http://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 December 22, 2016. 44 Copyright Notice 46 Copyright (c) 2016 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 (http://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 Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2), 271 then Route1 would be (C-S2,C-G2)'s match for reception and also its 272 match for tracking. Also note that if a match for tracking does not 273 have the LIR flag or the LIR-pF flag set, no explicit tracking 274 information will be generated. See Section 5. 276 As another example, suppose PE1 has installed the following two 277 routes that were originated by PE2: 279 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 280 PTA specifies a tunnel) 282 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 283 tunnel. 285 Then Route2 is both the "match for reception" and the "match for 286 tracking" for (C-S1,C-G1). 288 Note that for a particular C-flow, PE1's match for reception might be 289 the same route as its match for tracking, or its match for reception 290 might be a "less specific" route than its match for tracking. But 291 its match for reception can never be a "more specific" route than its 292 match for tracking. 294 4. Ingress Node Initiation of Tracking 296 An ingress node that needs to initiate explicit tracking for a 297 particular flow or set of flows can do so by performing one of the 298 following procedures: 300 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 301 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 302 its NLRI, including a PTA in that route, and setting the LIR flag 303 in that PTA. The PTA may specify a particular tunnel, or may 304 specify "no tunnel info". 306 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 307 specify "no tunnel info" unless the ingress node also originates 308 an A-D route carrying a PTA that specifies the tunnel to be used 309 for carrying (C-S1,C-G1) traffic. Such a route could be an 310 I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) 311 S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. (There is no 312 point in requesting explicit tracking for a given flow if there 313 is no tunnel on which the flow is being carried.) 315 Further, if the ingress node originates a wildcard S-PMSI A-D 316 route carrying a PTA specifying the tunnel to be used for 317 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 318 set, then explicit tracking for (C-S1,C-G1) is requested by that 319 S-PMSI A-D route. Thus the ingress node SHOULD NOT originate a 320 (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel 321 info"; such a route would not provide any additional 322 functionality. 324 To terminate explicit tracking that has been initiated by an 325 S-PMSI A-D route whose PTA specifies "no tunnel info", the 326 ingress node withdraws the route. 328 To terminate explicit tracking that has been initiated by an 329 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 330 re-originates the route without the LIR flag set. 332 2. The following procedure can be used if (and only if) it is known 333 that the egress nodes support the optional LIR-pF flag. If the 334 ingress node originates a wildcard S-PMSI A-D route, it can 335 initiate explicit tracking for the individual flows that match 336 the wildcard route by setting the LIR-pF flag in the PTA of the 337 wildcard route. If an egress node needs to receive one or more 338 flows for which that wildcard route is a match for tracking, the 339 egress node will originate a Leaf A-D route for each such flow, 340 as specified in Section 5.2). 342 When following this procedure, the PTA of the S-PMSI A-D route 343 may specify a tunnel, or may specify "no tunnel info". The 344 choice between these two options is determined by considerations 345 that are outside the scope of this document. 347 To terminate explicit tracking that has been initiated by an 348 S-PMSI A-D route whose PTA specifies "no tunnel info", the 349 ingress node withdraws the route. 351 To terminate explicit tracking that has been initiated by an 352 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 353 re-originates the route without the LIR flag set 355 5. Egress Node Response to the Match for Tracking 357 5.1. General Egress Node Procedures 359 There are four cases to consider: 361 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 362 state, the egress node's match for tracking is same as its match 363 for reception, and neither LIR nor LIR-pF flags are on. 365 In this case, the egress node does not originate a Leaf A-D route 366 in response to the match for reception/tracking, and there is no 367 explicit tracking of the flow. This document specifies no new 368 procedures for this case. 370 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 371 state, the egress node's match for tracking is the same as its 372 match for reception, LIR is set, but LIR-pF is not set. 374 In this case, a Leaf A-D route is originated by the egress node, 375 corresponding to the S-PMSI A-D route that is the match for 376 reception/tracking. Construction of the Leaf A-D route is as 377 specified in [RFC6514]; this document specifies no new procedures 378 for this case. 380 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 381 state, the egress node's match for tracking is the same as its 382 match for reception, and LIR-pF is set. The egress PE MUST 383 follow whatever procedures are required by other specifications, 384 based on the match for reception. If the egress PE supports the 385 LIR-pF flag, it MUST also follow the procedures of Section 5.2. 387 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 388 state, the egress node's match for tracking is not the same as 389 its match for reception. This can only happen if the match for 390 tracking has a PTA specifying "no tunnel info", with either LIR 391 or LIR-pF set. In this case, the egress node must respond, 392 separately, BOTH to the match for tracking and to the match for 393 reception. 395 When responding to the match for reception, the egress node MUST 396 ignore the LIR-pF flag. However, the LIR flag is processed 397 normally per the procedures for the match for reception. 399 If the match for tracking has LIR set and if either (a) the 400 egress node does not support LIR-pF, or (b) LIR-pF is not set, 401 then the egress node must respond to the match for tracking, 402 following procedures specified in other documents for the case 403 where LIR is set. 405 If the match for tracking has LIR-pF set, and the egress node 406 supports the LIR-pF flag, the egress node must originate one or 407 more Leaf A-D routes, as specified in Section 5.2. 409 Note that if LIR is set in the PTA of the match for reception, 410 the egress node may need to originate one or more Leaf A-D routes 411 corresponding to the match for tracking, as well as originating a 412 Leaf A-D route corresponding to the match for reception. 414 5.2. Responding to the LIR-pF Flag 416 To respond to a match for tracking that has LIR-pF set, an egress 417 node originates one or more Leaf A-D routes. 419 Suppose the egress node has multicast state for a (C-S,C-G) or a 420 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 421 which has the LIR-pF flag set, to be the match for tracking for that 422 flow. Then if the egress node supports the LIR-pF flag, it MUST 423 originate a Leaf A-D route whose NLRI identifies that particular 424 flow. Note that if a single S-PMSI A-D route (with wild cards) is 425 the match for tracking for multiple flows, the egress PE may need to 426 originate multiple Leaf A-D routes, one for each such flow. We say 427 that, from the perspective of a given egress node, a given S-PMSI A-D 428 route tracks the set of flows for which it is the match for tracking. 429 Each of the Leaf A-D routes originated in response to that S-PMSI A-D 430 route tracks a single such flow. 432 The NLRI of each the Leaf A-D route that tracks a particular flow is 433 constructed as follows. The "route key" field of the NLRI will have 434 the following format: 436 +-----------------------------------+ 437 | RD (8 octets) | 438 +-----------------------------------+ 439 | Multicast Source Length (1 octet) | 440 +-----------------------------------+ 441 | Multicast Source (Variable) | 442 +-----------------------------------+ 443 | Multicast Group Length (1 octet) | 444 +-----------------------------------+ 445 | Multicast Group (Variable) | 446 +-----------------------------------+ 447 | Ingress PE's IP address | 448 +-----------------------------------+ 450 Figure 1: NLRI of S-PMSI A-D Route 452 o The "ingress PE" address is taken from the "originating router" 453 field of the NLRI of the S-PMSI A-D route that is the match for 454 tracking. 456 o The multicast source and group fields specify the S and G of one 457 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 458 is being tracked by this Leaf A-D route, the source field is 459 omitted, and its length is set to 0. 461 o The RD field is constructed as follows: 463 * Take the RD value from the NLRI of the S-PMSI A-D route. 465 * Add 16 to the second octet of the RD. 467 Note that, per RFC4364, every RD begins with a two-octet type field 468 that is either 0, 1, or 2. By adding 16 to the second octet of the 469 RD, we force the type field to be 16, 17, or 18. The presence of one 470 of these values will indicate that the Leaf A-D route was constructed 471 in response to a less specific S-PMSI A-D route that had the LIR-pF 472 bit set. (That is, it distinguishes the routes from "ordinary" MVPN 473 Leaf A-D routes.) 475 The encoding of these Leaf A-D routes is similar to the encoding of 476 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 477 were designed for the support of "global table multicast". However, 478 that document sets the RD to either 0 or -1; following the procedures 479 of this document, the RD will never be 0 or -1. Therefore Leaf A-D 480 routes constructed according to the procedures of this section can 481 always be distinguished from the Leaf A-D routes constructed 482 according to the procedures of section 6.2.2 of [RFC7524]. Also, 483 Leaf A-D routes constructed according to the procedures of this 484 section are VPN-specific routes, and will always carry an IP-address- 485 specific Route Target, as specified in [RFC6514]. 487 If a Leaf A-D route is originated as a response to a match for 488 tracking whose PTA specifies "no tunnel info", a PTA SHOULD NOT be 489 attached to the Leaf A-D route; if a PTA is attached, it MUST specify 490 "no tunnel info". 492 In the case where the match for tracking and the match for reception 493 are the same, the PTA of the match may have both the LIR and the LIR- 494 pF flags set. This may cause the egress node to originate one Leaf 495 A-D route in response to the LIR bit, and one or more Leaf A-D routes 496 in response to the LIR-pF bit. A PTA SHOULD NOT be attached to the 497 Leaf A-D routes that are originated in response to the LIR-pF bit. 499 When a Leaf A-D route constructed according to the procedures of this 500 section is received, it MUST be processed by the node identified in 501 its IP-address-specific Route Target, even though its "route key" 502 field does not correspond to the NLRI of any S-PMSI A-D route. 504 Of course, an egress node that originates such Leaf A-D routes needs 505 to remember which S-PMSI A-D route caused these Leaf A-D routes to be 506 originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D 507 routes MUST be withdrawn. 509 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 510 or explicitly) if the egress node changes its Upstream Multicast Hop 511 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 512 route's NLRI, or if the egress node that originated the route no 513 longer needs to receive the flow identified in the NLRI of the route. 515 Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G) 516 state after it has already received the S-PMSI A-D that is the match 517 for tracking for that state. In this case, a Leaf A-D route needs to 518 be originated at that time, and the egress node must remember that 519 the new Leaf A-D route corresponds to that match for tracking. 521 Note that if a particular S-PMSI A-D route is a match for tracking 522 but not a match for reception, the LIR bit in its PTA is ignored if 523 the LIR-pF bit is set. 525 5.3. When the Egress Node is an ABR or ASBR 527 When segmented P-tunnels are used, the ingress and egress nodes may 528 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 529 S-PMSI A-D route also forwards that route. If the PTA of an 530 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 531 MAY change the PTA to specify a different tunnel type (as discussed 532 in [RFC6514] and/or [RFC7524]). 534 However, if the PTA of the installed S-PMSI A-D route specifies "no 535 tunnel info", the egress ABR/ASBR MUST pass the PTA along unchanged 536 when it forwards the S-PMSI A-D route. (That is, a PTA specifying 537 "no tunnel info" MUST NOT be changed into a PTA specifying a tunnel.) 538 Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR- 539 pF flags in the PTA MUST be passed along unchanged. 541 In the case where the egress node is a PE, it will know whether it 542 needs to receive a given flow by virtue of its having received a PIM 543 or IGMP Join for that flow from a CE. In the case where the egress 544 node is not a PE, but rather an ABR or ASBR, it will not know whether 545 it needs to receive a given flow unless it receives a Leaf A-D route 546 whose NLRI specifies that flow and whose IP-address-specific RT 547 specifies an address of the egress node. Therefore an egress ABR/ 548 ASBR MUST NOT originate a Leaf A-D route for a given flow UNLESS it 549 has an installed Leaf A-D route for that flow, received from further 550 downstream. 552 This will ensure that an egress ABR/ASBR only sends a Leaf A-D route 553 in response to a "match for tracking" if it is on the path to an 554 egress PE for the flow(s) identified in the corresponding S-PMSI A-D 555 route. 557 Then we can establish the following rule for egress ABRs/ASBRs. 558 Suppose an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is 559 X, and whose PTA (a) specifies "no tunnel info" and (b) has LIR set. 560 The egress ABR/ASBR should not immediately originate a Leaf A-D route 561 in response. Rather it should wait until it receives a Leaf A-D 562 route whose NLRI contains X in the "route key" field. If it receives 563 such a Leaf A-D route, it redistributes that route, but first it 564 changes that route's RT. The "global administrator" field of the 565 modified RT will be set to the IP address taken either from the 566 S-PMSI A-D route's next hop field, or from its Segmented P2MP Next 567 Hop Extended Community. (This is the same rule that is used for when 568 the PTA does specify a tunnel type.) 570 6. Acknowledgments 572 The authors wish to thank Robert Kebler for his ideas and comments. 574 7. IANA Considerations 576 The LIR-pF flag needs to be added to the "P-Multicast Service 577 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 578 Gateway Protocol (BGP) Parameters" registry. This registry is 579 defined in [RFC7902]. The requested value is Bit Position 2. This 580 document should be the reference. 582 IANA is requested to allocate three new types from the Route 583 Distinguisher Type Field registry: 585 o Administrator field is two-byte Autonomous System Number. To be 586 used only in certain MCAST-VPN Leaf A-D routes. 588 o Administrator field is four-byte IP Address. To be used only in 589 certain MCAST-VPN Leaf A-D routes. 591 o Administrator field is four-byte Autonomous System Number. To be 592 used only in certain MCAST-VPN Leaf A-D routes. 594 The requested values are 16, 17, and 18 respectively. 596 8. Security Considerations 598 The Security Considerations of [RFC6513] and [RFC6514] apply. 600 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 601 large number of Leaf A-D routes can be elicited. If this flag is set 602 when not desired (through either error or malfeasance), a significant 603 increase in control plane overhead can result. 605 9. References 607 9.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, 611 DOI 10.17487/RFC2119, March 1997, 612 . 614 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 615 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 616 2012, . 618 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 619 Encodings and Procedures for Multicast in MPLS/BGP IP 620 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 621 . 623 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 624 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 625 RFC 6625, DOI 10.17487/RFC6625, May 2012, 626 . 628 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 629 P-Multicast Service Interface Tunnel Attribute Flags", 630 RFC 7902, DOI 10.17487/RFC7902, June 2016, 631 . 633 9.2. Informative References 635 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 636 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 637 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 638 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 639 . 641 Authors' Addresses 643 Andrew Dolganow 644 Nokia 645 600 March Rd. 646 Ottawa, Ontario K2K 2E6 647 Canada 649 Email: andrew.dolganow@nokia.com 651 Jayant Kotalwar 652 Nokia 653 701 East Middlefield Rd 654 Mountain View, California 94043 655 United States 657 Email: jayant.kotalwar@nokia.com 658 Eric C. Rosen (editor) 659 Juniper Networks, Inc. 660 10 Technology Park Drive 661 Westford, Massachusetts 01886 662 United States 664 Email: erosen@juniper.net 666 Zhaohui Zhang 667 Juniper Networks, Inc. 668 10 Technology Park Drive 669 Westford, Massachusetts 01886 670 United States 672 Email: zzhang@juniper.net