idnits 2.17.1 draft-ietf-bess-mvpn-expl-track-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7524, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6514, updated by this document, for RFC5378 checks: 2006-08-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 19, 2018) is 2199 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 (~~), 1 warning (==), 3 comments (--). 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: 6514 6625 7524 (if approved) Nokia 5 Intended status: Standards Track E. Rosen, Ed. 6 Expires: October 21, 2018 Z. Zhang 7 Juniper Networks, Inc. 8 April 19, 2018 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-09 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 RFCs 25 6514, 6625, and 7524. 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 October 21, 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 . . . . . . . . . 6 64 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 8 65 5. Egress Node Response to the Match for Tracking . . . . . . . 10 66 5.1. General Egress Node Procedures . . . . . . . . . . . . . 10 67 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 11 68 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 14 69 6. Ingress Node Handling of Received Leaf A-D Routes with 70 LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 10.2. Informative References . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 [RFC6513] and [RFC6514] define the "Selective Provider Multicast 82 Service Interface Auto-Discovery route" (S-PMSI A-D route). 84 Per those RFCs, the S-PMSI A-D route contains a Network Layer 85 Reachability Information (NLRI) field that identifies a particular 86 multicast flow. In the terminology of those RFCs, each flow is 87 denoted by (C-S,C-G), where C-S is an IP source address and C-G is an 88 IP multicast address, both in the address space of a VPN customer. 89 The (C-S,C-G) of the multicast flow is encoded into the NLRI field. 91 An S-PMSI A-D route also carries a PMSI Tunnel attribute (PTA). 92 Typically, the PTA is used to identify a tunnel through the provider 93 backbone network (a "P-tunnel"). 95 By originating an S-PMSI A-D route identifying a particular multicast 96 flow and a particular P-tunnel, a node is advertising the following: 98 if the node has to transmit packets of the identified flow over 99 the backbone, it will transmit them through the identified tunnel. 101 [RFC6513] and [RFC6514] also define a procedure that allows an 102 ingress node of particular multicast flow to determine the set of 103 egress nodes that have requested to receive that flow from that 104 ingress node. The ability of an ingress node to identify the egress 105 nodes for a particular flow is known as "explicit tracking". An 106 ingress node requests explicit tracking by setting a flag (the "Leaf 107 Information Required" flag, or LIR) in the PTA. When an egress node 108 receives an S-PMSI A-D route with LIR set, the egress node originates 109 a Leaf A-D route whose NLRI field contains the NLRI from the 110 corresponding S-PMSI A-D route. In this way, the egress node 111 advertises that it has requested to receive the particular flow 112 identified in the NLRI of that S-PMSI A-D route. 114 [RFC6513] and [RFC6514] also allow an ingress node to originate an 115 S-PMSI A-D route whose PTA has LIR set, but which does not identify 116 any P-tunnel. This mechanism can be used when it is desired to do 117 explicit tracking of a flow without at the same time binding that 118 flow to a particular P-tunnel. 120 [RFC6625] (and other RFCs that update it) extends the specification 121 of S-PMSI A-D routes, and allows an S-PMSI A-D route to encode a 122 wildcard in its NLRI. Either the C-S or the C-G or both can be 123 replaced by wildcards. These routes are known as (C-*,C-S) S-PMSI 124 A-D routes, or as (C-S,C-*) S-PMSI A-D routes, or as (C-*,C-*) S-PMSI 125 A-D routes, depending on whether the C-S or C-G or both have been 126 replaced by wildcards. These routes are known jointly as "wildcard 127 S-PMSI A-D routes". 129 One purpose of this document is to clarify the way that the explicit 130 tracking procedures of [RFC6513] and [RFC6514] are applied when 131 wildcard S-PMSI A-D routes are used. 133 In addition, this document addresses the following scenario, which is 134 not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an 135 ingress node originates an S-PMSI A-D route whose NLRI specifies, for 136 example, (C-*,C-*) (i.e., both C-S and C-G are replaced by 137 wildcards), and whose PTA identifies a particular P-tunnel. Now 138 suppose that the ingress node wants explicit tracking for each 139 individual flow that it transmits (following the procedures of 140 [RFC6625]) on that P-tunnel. 142 In this example, if the ingress node sets LIR in the PTA of the 143 wildcard S-PMSI A-D route, each egress node that needs to receive a 144 flow from the ingress node will respond with a Leaf A-D route whose 145 NLRI specifies contains the (C-*,C-*) wildcard. This allows the 146 ingress node to determine the set of egress nodes that are interested 147 in receiving flows from the ingress node. However, it does not allow 148 the ingress node to determine exactly which flows are of interest to 149 which egress nodes. 151 If the ingress node needs to determine which egress nodes are 152 interested in receiving which flows, it needs to originate an S-PMSI 153 A-D route for each individual (C-S,C-G) flow that it is transmitting, 154 and it needs to set LIR in the PTA of each such route. However, 155 since all the flows are being sent through the tunnel identified in 156 the (C-*,C-*) S-PMSI A-D route, there is no need to identify a tunnel 157 in the PTA of each (C-S,C-G) S-PMSI A-D route. Per [RFC6514], the 158 PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel 159 information". This procedure allows explicit tracking of individual 160 flows, even though all those flows are assigned to tunnels in 161 wildcard S-PMSI A-D routes. 163 However, this procedure requires several clarifications: 165 o The procedures of [RFC6625] do not address the case of an S-PMSI 166 A-D route whose NLRI contains wild cards, but whose PTA specifies 167 "no tunnel info". 169 o If it is desired to send a set of flows through the same tunnel 170 (where that tunnel is advertised in a wildcard S-PMSI A-D route), 171 but it is also desired to explicitly track each individual flow 172 transmitted over that tunnel, one has to send an S-PMSI A-D route 173 (with LIR set in the PTA) for each individual flow. It would be 174 more optimal if the ingress node could just send a single wildcard 175 S-PMSI A-D route binding the set of flows to a particular tunnel, 176 and have the egress nodes respond with Leaf A-D routes for each 177 individual flow. 179 o [RFC6513] and [RFC6514] support the notion of "segmented 180 P-tunnels", where "segmentation" occurs at Autonomous System 181 Border Routers (ASBRs); [RFC7524] extends the notion of segmented 182 P-tunnels so that segmentation can occur at Area Border Routers 183 (ABRs). One can think of a segmented P-tunnel as passing through 184 a number of "segmentation domains". In each segmentation domain, 185 a given P-tunnel has an ingress node and a set of egress nodes. 186 The explicit tracking procedures allow an ingress node of a 187 particular segmentation domain to determine, for a particular flow 188 or set of flows, the egress nodes of that segmentation domain. 189 This has given rise to two further problems: 191 * The explicit tracking procedures do not allow an ingress node 192 to "see" past the boundaries of the segmentation domain. 194 * The prior specifications do not make it very clear whether a 195 segmented tunnel egress node, upon receiving an S-PMSI A-D 196 route whose PTA specifies "no tunnel information", is expected 197 to forward the S-PMSI A-D route, with the same PTA, to the next 198 segmentation domain. 200 These problems are addressed in Section 5.3. 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 2. The Explicit Tracking Flags 210 [RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR) 211 flag, that is used for explicit tracking. 213 This document defines a new flag in the flags field of the PMSI 214 Tunnel attribute. This new flag is known as the "Leaf Info Required 215 per Flow" bit (LIR-pF). This flag may be set in the PTA of a 216 (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The conditions 217 under which it should be set by the originator of the route are 218 discussed in Section 4. The significance of the flag in a received 219 S-PMSI A-D route is discussed in Sections 5 and 5.2. 221 If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR 222 flag of that PTA MUST also be set. 224 Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD 225 NOT be set unless it is known that all the PEs that are to receive 226 the route carrying the PTA support the flag. How this is known is 227 outside the scope of this document. 229 The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The 230 conditions under which it should be set by the originator of the 231 route are discussed in Section 5.2. The significance of the flag in 232 a received Leaf A-D route is discussed in Section 6. 234 Use of this flag in the PTA carried by other route types is outside 235 the scope of this document. Use of this flag in the PTA carried by 236 an S-PMSI A-D routes whose NLRI does not contain a wildcard is 237 outside the scope of this document. 239 It is worth noting what will happen if the LIR-pF flag is set in the 240 PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an 241 ingress node, but one or more of the egress nodes do not support the 242 LIR-pF flag: 244 1. The ingress node will not be able to determine the complete set 245 of egress node that are expecting a particular multicast flow 246 from that ingress node. 248 2. Depending upon the tunnel type, the ingress node may send a 249 particular multicast flow only to the egress nodes that do 250 support the LIR-pF flag. From the perspective of egress nodes 251 that do not support LIR-pF, certain flows may appear to be 252 "blackholed". 254 It is also worth noting that it is possible for an ingress node that 255 sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of 256 egress nodes that do not support this flag. 258 Since an ingress node that sets the LIR-pF flag is also REQUIRED to 259 set the LIR flag, egress nodes that do not support the LIR-pF flag 260 will respond, as specified in [RFC6514], to the ingress node's 261 (C-*,C-*) S-PMSI A-D route with a Leaf A-D route operator. 263 As will be discussed in Section 5.2, any Leaf A-D route originated in 264 response to an S-PMSI A-D route that has LIR-pF set will carry a PTA 265 whose LIR-pF flag is set. If an ingress node receives a Leaf A-D 266 route whose "route key" field corresponds to the NLRI of an S-PMSI 267 A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a 268 PTA or has a PTA where LIR-pF is clear, the ingress node can conclude 269 that the egress node originating that Leaf A-D route does not support 270 the LIR-pF flag. 272 The software at the ingress node SHOULD detect this, and should have 273 a way of alerting the operator that the deployment is not properly 274 configured. 276 3. Match for Tracking vs. Match for Reception 278 Section 3.2 of [RFC6625] specifies a set of rules for finding the 279 S-PMSI A-D route that is the "match for data reception" (or more 280 simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) 281 state. These rules do not take into account the fact that some 282 S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying 283 PTAs that do not identify any P-tunnel. (A PTA that does not 284 identify any P-tunnel is one whose "tunnel type" field has been set 285 to "no tunnel information", as specified in Section 5 of [RFC6514].) 287 The rules for finding a "match for reception" in [RFC6625] are hereby 288 modified as follows: 290 When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it 291 is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or 292 whose PTA specifies "no tunnel information". 294 There are other RFCs that update [RFC6625] and that modify the rules 295 for finding a "match for reception". See, e.g., [RFC7582] and 296 [RFC7900]. When applying those modified rules, it is REQUIRED to 297 ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies 298 "no tunnel information". 300 We also introduce a new notion, the "match for tracking": 302 For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for 303 tracking" is chosen as follows. Ignore any S-PMSI A-D route that 304 has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies 305 "no tunnel information", but does not have either LIR or LIR-pF 306 set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA 307 specifying "no tunnel information" unless its LIR and LIR-pF bits 308 are both clear). Then apply the rules (from [RFC6625] and other 309 documents that that update it) for finding the "match for 310 reception". The result (if any) is the match for tracking". 312 Note that the procedure for finding the match for tracking takes 313 into account S-PMSI A-D routes whose PTAs specify "no tunnel 314 information" and that have either LIR or LIR-pf set. The 315 procedure for finding the match for reception ignores such routes. 317 We will clarify this with a few examples. In these examples, we 318 assume that there is only one segmentation domain. In this case, the 319 ingress and egress nodes are Provider Edge (PE) routers. 321 Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 322 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has 323 installed the following two routes that were originated by PE2: 325 o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a 326 tunnel. 328 o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no 329 tunnel info" and has LIR set. 331 Route1 is (C-S1,C-G1)'s match for reception, and Route2 is 332 (C-S1,C-G1)'s match for tracking. 334 Continuing this example, suppose: 336 o PE1 has chosen PE2 as the upstream PE for a different flow, 337 (C-S2,C-G2). 339 o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). 341 In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for 342 tracking as well as its match for reception. 344 Also note that if a match for tracking does not have the LIR flag or 345 the LIR-pF flag set, no explicit tracking information will be 346 generated. See Section 5. 348 As another example, suppose PE1 has installed the following two 349 routes that were originated by PE2: 351 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 352 PTA specifies a tunnel) 354 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 355 tunnel. 357 Then Route2 is both the "match for reception" and the "match for 358 tracking" for (C-S1,C-G1). 360 Note that for a particular C-flow, PE1's match for reception might be 361 the same route as its match for tracking, or its match for reception 362 might be a "less specific" route than its match for tracking. But 363 its match for reception can never be a "more specific" route than its 364 match for tracking. 366 4. Ingress Node Initiation of Tracking 368 An ingress node that needs to initiate explicit tracking for a 369 particular flow or set of flows can do so by performing one of the 370 following procedures: 372 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 373 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 374 its NLRI, including a PTA in that route, and setting the LIR flag 375 in that PTA. The PTA may specify a particular tunnel, or may 376 specify "no tunnel info". 378 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 379 specify "no tunnel info" unless the ingress node also originates 380 an A-D route carrying a PTA that specifies the tunnel to be used 381 for carrying (C-S1,C-G1) traffic. Such a route could be an 382 I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) 383 S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. (There is no 384 point in requesting explicit tracking for a given flow if there 385 is no tunnel on which the flow is being carried.) 386 Note that if the ingress node originates a wildcard S-PMSI A-D 387 route carrying a PTA specifying the tunnel to be used for 388 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 389 set, then explicit tracking for (C-S1,C-G1) is requested by that 390 S-PMSI A-D route. In that case, the ingress node SHOULD NOT 391 originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no 392 tunnel info"; such a route would not provide any additional 393 functionality. 395 To terminate explicit tracking that has been initiated by an 396 S-PMSI A-D route whose PTA specifies "no tunnel info", the 397 ingress node withdraws the route. 399 To terminate explicit tracking that has been initiated by an 400 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 401 re-originates the route without the LIR flag set. 403 2. The following procedure can be used if and only if it is known 404 that the egress nodes support the optional LIR-pF flag. If the 405 ingress node originates a wildcard S-PMSI A-D route, it can 406 initiate explicit tracking for the individual flows that match 407 the wildcard route by setting the LIR-pF flag in the PTA of the 408 wildcard route. If an egress node needs to receive one or more 409 flows for which that wildcard route is a match for tracking, the 410 egress node will originate a Leaf A-D route for each such flow, 411 as specified in Section 5.2). 413 When following this procedure, the PTA of the S-PMSI A-D route 414 may specify a tunnel, or may specify "no tunnel info". The 415 choice between these two options is determined by considerations 416 that are outside the scope of this document. 418 To terminate explicit tracking that has been initiated by an 419 S-PMSI A-D route whose PTA specifies "no tunnel info", the 420 ingress node withdraws the route. 422 To terminate explicit tracking that has been initiated by an 423 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 424 re-originates the route without either the LIR or LIR-pF flags 425 set. 427 Note that this procedure (procedure 2 of Section 4) may not yield 428 the expected results if there are egress nodes that do not 429 support the LIR-pF flag, and hence SHOULD NOT be used in that 430 case. 432 5. Egress Node Response to the Match for Tracking 434 5.1. General Egress Node Procedures 436 There are four cases to consider: 438 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 439 state, the egress node's match for tracking is same as its match 440 for reception, and neither LIR nor LIR-pF flags are on. 442 In this case, the egress node does not originate a Leaf A-D route 443 in response to the match for reception/tracking, and there is no 444 explicit tracking of the flow. This document specifies no new 445 procedures for this case. 447 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 448 state, the egress node's match for tracking is the same as its 449 match for reception, LIR is set, but LIR-pF is not set. 451 In this case, a Leaf A-D route is originated by the egress node, 452 corresponding to the S-PMSI A-D route that is the match for 453 reception/tracking. Construction of the Leaf A-D route is as 454 specified in [RFC6514]; this document specifies no new procedures 455 for this case. 457 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 458 state, the egress node's match for tracking is the same as its 459 match for reception, and LIR-pF is set. The egress node MUST 460 follow whatever procedures are required by other specifications, 461 based on the match for reception. If the egress node supports 462 the LIR-pF flag, it MUST also follow the procedures of 463 Section 5.2. 465 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 466 state, the egress node's match for tracking is not the same as 467 its match for reception. This can only happen if the match for 468 tracking has a PTA specifying "no tunnel info", with either LIR 469 or LIR-pF set. In this case, the egress node must respond, 470 separately, BOTH to the match for tracking and to the match for 471 reception. 473 When responding to the match for reception, the egress node MUST 474 ignore the LIR-pF flag. However, the LIR flag is processed 475 normally per the procedures for the match for reception. 477 If the match for tracking has LIR set and if either (a) the 478 egress node does not support LIR-pF, or (b) LIR-pF is not set, 479 then the behavior of the egress node is not affected by the 480 procedures of this document. 482 If the match for tracking has LIR-pF set, and the egress node 483 supports the LIR-pF flag, the egress node must originate one or 484 more Leaf A-D routes, as specified in Section 5.2. 486 Note that if LIR is set in the PTA of the match for reception, 487 the egress node may need to originate one or more Leaf A-D routes 488 corresponding to the match for tracking, as well as originating a 489 Leaf A-D route corresponding to the match for reception. 491 5.2. Responding to the LIR-pF Flag 493 To respond to a match for tracking that has LIR-pF set, an egress 494 node originates one or more Leaf A-D routes. 496 Suppose the egress node has multicast state for a (C-S,C-G) or a 497 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 498 which has the LIR-pF flag set, to be the match for tracking for that 499 flow. Then if the egress node supports the LIR-pF flag, it MUST 500 originate a Leaf A-D route whose NLRI identifies that particular 501 flow. Note that if a single S-PMSI A-D route (with wild cards) is 502 the match for tracking for multiple flows, the egress node may need 503 to originate multiple Leaf A-D routes, one for each such flow. We 504 say that, from the perspective of a given egress node, a given S-PMSI 505 A-D route tracks the set of flows for which it is the match for 506 tracking. Each of the Leaf A-D routes originated in response to that 507 S-PMSI A-D route tracks a single such flow. 509 The NLRI of each the Leaf A-D route that tracks a particular flow is 510 constructed as follows. The "route key" field of the NLRI will have 511 the following format: 513 +-----------------------------------+ 514 | RD (8 octets) | 515 +-----------------------------------+ 516 | Multicast Source Length (1 octet) | 517 +-----------------------------------+ 518 | Multicast Source (Variable) | 519 +-----------------------------------+ 520 | Multicast Group Length (1 octet) | 521 +-----------------------------------+ 522 | Multicast Group (Variable) | 523 +-----------------------------------+ 524 | Ingress PE's IP address | 525 +-----------------------------------+ 527 Figure 1: NLRI of S-PMSI A-D Route 529 o The "ingress PE" address is taken from the "originating router" 530 field of the NLRI of the S-PMSI A-D route that is the match for 531 tracking. 533 o The multicast source and group fields specify the S and G of one 534 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 535 is being tracked by this Leaf A-D route, the source field is 536 omitted, and its length is set to 0. 538 o The Route Distinguisher (RD) field is set to the value of the RD 539 field from the NLRI of the S-PMSI A-D route. 541 The encoding of these Leaf A-D routes is similar to the encoding of 542 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 543 were designed for the support of "global table multicast". However, 544 that document sets the RD to either 0 or -1; following the procedures 545 of this document, the RD will never be 0 or -1. Therefore Leaf A-D 546 routes constructed according to the procedures of this section can 547 always be distinguished from the Leaf A-D routes constructed 548 according to the procedures of section 6.2.2 of [RFC7524]. Also, 549 Leaf A-D routes constructed according to the procedures of this 550 section are VPN-specific routes, and will always carry an IP-address- 551 specific Route Target, as specified in [RFC6514]. 553 If a Leaf A-D route is originated as a response to a match for 554 tracking whose PTA specifies "no tunnel info", the Leaf A-D route 555 MUST carry a PTA that specifies "no tunnel info". The LIR-pF flag in 556 this PTA MUST be set. 558 In the case where the match for tracking and the match for reception 559 are the same, the PTA of the match may have both the LIR and the 560 LIR-pF flags set. This may cause the egress node to originate one 561 Leaf A-D route in response to the LIR bit, and one or more Leaf A-D 562 routes in response to the LIR-pF bit. Each such Leaf A-D route MUST 563 have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that 564 when the match for tracking is the same as the match for reception, 565 the PTA of the match for tracking/reception will have specified a 566 tunnel type. The following rules specify how the PTA of the Leaf A-D 567 route is to be constructed: 569 o If the tunnel type of the PTA attached to the match for tracking/ 570 reception is Ingress Replication, the Leaf A-D route's PTA MAY 571 specify Ingress Replication. In this case, the MPLS Label field 572 of the PTA MAY be a non-zero value. If so, this label value will 573 be used by the ingress PE when it transmits, to the egress PE, 574 packets of the flow identified in the Leaf A-D route's NLRI. 576 Alternatively, the egress PE MAY specify an MPLS label value of 577 zero, or it MAY specify a tunnel type of "no tunnel info". In 578 either of these cases, when the ingress PE transmits packets of 579 the identified flow to the egress PE, it will use the label that 580 the egress PE specified in the PTA of the Leaf A-D route that it 581 originated in response to the LIR bit of the match for reception. 583 o If the tunnel type of the PTA attached to the match for tracking/ 584 reception is any of the other tunnel types listed in [RFC6514] 585 Section 5, the PTA attached to the Leaf A-D route MUST specify a 586 tunnel type of "no tunnel info". 588 o When additional tunnel types are defined, the specification for 589 how MVPN is to use those tunnel types must also specify how to 590 construct the PTA of a Leaf A-D route that is originated in 591 response to the LIR-pF flag. As an example, see [BIER-MVPN]. 593 Of course, an egress node that originates such Leaf A-D routes needs 594 to remember which S-PMSI A-D route caused these Leaf A-D routes to be 595 originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D 596 routes MUST be withdrawn. 598 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 599 or explicitly) if the egress node changes its Upstream Multicast Hop 600 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 601 route's NLRI, or if the egress node that originated the route no 602 longer needs to receive the flow identified in the NLRI of the route. 604 Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G) 605 state after it has already received the S-PMSI A-D that is the match 606 for tracking for that state. In this case, a Leaf A-D route needs to 607 be originated at that time, and the egress node must remember that 608 the new Leaf A-D route corresponds to that match for tracking. 610 Note that if a particular S-PMSI A-D route is a match for tracking 611 but not a match for reception, the LIR bit in its PTA is ignored if 612 the LIR-pF bit is set. 614 5.3. When the Egress Node is an ABR or ASBR 616 When segmented P-tunnels are used, the ingress and egress nodes may 617 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 618 S-PMSI A-D route also forwards that route. If the PTA of an 619 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 620 MAY change the PTA to specify a different tunnel type (as discussed 621 in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to 622 originate a Leaf A-D route, as specified in [RFC6514] and/or 623 [RFC7524]. 625 Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, 626 and also has LIR-pF set. The egress ABR/ASBR originates a 627 corresponding Leaf A-D route for a given (C-S,C-G) only if it knows 628 that it needs to receive that flow. It will know this by virtue of 629 receiving a corresponding Leaf A-D route from downstream. (In the 630 case where the PTA specifies a tunnel but LIR-pF is not set, this 631 document does not specify any new procedures.) 633 The procedures in the remainder of this section apply only when an 634 egress ABR/ASBR has installed an S-PMSI A-D route whose PTA specifies 635 "no tunnel info" but has LIR or LIR-pF set. 637 If the PTA of the installed S-PMSI A-D route specifies "no tunnel 638 info", the egress ABR/ASBR MUST pass the PTA along unchanged when it 639 forwards the S-PMSI A-D route. (That is, a PTA specifying "no tunnel 640 info" MUST NOT be changed into a PTA specifying a tunnel.) 641 Furthermore, if the PTA specifies "no tunnel info", the LIR and 642 LIR-pF flags in the PTA MUST be passed along unchanged. 644 As a result of propagating such an S-PMSI A-D route, the egress ABR/ 645 ASBR may receive one or more Leaf A-D routes that correspond to that 646 S-PMSI A-D route. These routes will be received carrying an IP- 647 address-specific Route Target (RT) Extended Community that specifies 648 the address of the egress ABR/ASBR. The egress ABR/ASBR will 649 propagate these Leaf A-D routes, after changing the RT as follows. 650 The "global administrator" field of the modified RT will be set to 651 the IP address taken either from the S-PMSI A-D route's next hop 652 field ([RFC6514]), or from its Segmented P2MP Next Hop Extended 653 Community ([RFC7524]). 655 This procedure enables the ingress PE to explicitly track the egress 656 PEs for a given flow, even if segmented tunnels are being used. 657 However, cross-domain explicit tracking utilizes S-PMSI A-D routes 658 that do not specify tunnel information; therefore it can only be done 659 when the S-PMSI A-D route which is a flow's match for tracking is 660 different than the S-PMSI A-D route which is that flow's match for 661 reception. 663 6. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set 665 Consider the following situation: 667 o An ingress node, call it N, receives a Leaf A-D route, call it L. 669 o L carries an IP-address-specific RT identifying N. 671 o The route key field of L's NLRI is not identical to the NLRI of 672 any current I-PMSI or S-PMSI A-D route originated by N. 674 Per the procedures of [RFC6514] and [RFC7524], such a Leaf A-D route 675 does not cause any MVPN-specific action to be taken by N. 677 This document modifies those procedures in the case where there is a 678 current S-PMSI A-D route with a wildcard NLRI, originated by N, to 679 which L is a valid response according to the procedures of 680 Section 5.2. In this case, L MUST be processed by N. 682 Suppose that L's PTA specifies a tunnel type of Ingress Replication, 683 and that it also specifies a non-zero MPLS label. Then if N needs to 684 send to L a packet belonging to the multicast flow or flows 685 identified in L's NLRI, N MUST use the specified label. 687 If L's PTA meets any of the following conditions: 689 o It specifies a tunnel type of "no tunnel information", or 691 o It specifies a tunnel type of Ingress Replication, but specifies 692 an MPLS label of zero, or 694 o It specifies another of the tunnel types listed in Section 5 of 695 [RFC6514], 697 then the action taken by N when it receives L is a local matter. In 698 this case, the Leaf A-D route L provides N with explicit tracking 699 information for the flow identified by L's NLRI. However, that 700 information is for management/monitoring purposes and does not have 701 an effect on the flow of multicast traffic. 703 If L's PTA specifies a tunnel type not mentioned above, the 704 specification for how MVPN uses that tunnel type must specify the 705 actions that N is to take upon receiving L. As an example, see 706 [BIER-MVPN]. 708 7. Acknowledgments 710 The authors wish to thank Robert Kebler for his ideas and comments. 711 We also thank Stephane Litkowski for his thorough review and useful 712 suggestions. 714 8. IANA Considerations 716 The LIR-pF flag needs to be added to the "P-Multicast Service 717 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 718 Gateway Protocol (BGP) Parameters" registry. This registry is 719 defined in [RFC7902]. The requested value is Bit Position 2. This 720 document should be the reference. 722 9. Security Considerations 724 The Security Considerations of [RFC6513] and [RFC6514] apply. 726 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 727 large number of Leaf A-D routes can be elicited. If this flag is set 728 when not desired (through either error or malfeasance), a significant 729 increase in control plane overhead can result. The specification of 730 counter-measures for this problem is outside the scope of this 731 document. 733 10. References 735 10.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 743 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 744 2012, . 746 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 747 Encodings and Procedures for Multicast in MPLS/BGP IP 748 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 749 . 751 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 752 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 753 RFC 6625, DOI 10.17487/RFC6625, May 2012, 754 . 756 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 757 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 758 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 759 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 760 . 762 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 763 P-Multicast Service Interface Tunnel Attribute Flags", 764 RFC 7902, DOI 10.17487/RFC7902, June 2016, 765 . 767 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 768 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 769 May 2017, . 771 10.2. Informative References 773 [BIER-MVPN] 774 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 775 Przygienda, "Multicast VPN Using BIER", internet-draft 776 draft-ietf-bier-mvpn-11, March 2018. 778 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 779 "Multicast Virtual Private Network (MVPN): Using 780 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 781 July 2015, . 783 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 784 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 785 RFC 7900, DOI 10.17487/RFC7900, June 2016, 786 . 788 Authors' Addresses 790 Andrew Dolganow 791 Nokia 792 438B Alexandra Rd #08-07/10 793 Alexandra Technopark 794 Singapore 119968 795 Singapore 797 Email: andrew.dolganow@nokia.com 798 Jayant Kotalwar 799 Nokia 800 701 East Middlefield Rd 801 Mountain View, California 94043 802 United States of America 804 Email: jayant.kotalwar@nokia.com 806 Eric C. Rosen (editor) 807 Juniper Networks, Inc. 808 10 Technology Park Drive 809 Westford, Massachusetts 01886 810 United States of America 812 Email: erosen@juniper.net 814 Zhaohui Zhang 815 Juniper Networks, Inc. 816 10 Technology Park Drive 817 Westford, Massachusetts 01886 818 United States of America 820 Email: zzhang@juniper.net