idnits 2.17.1 draft-ietf-bess-mvpn-expl-track-10.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 (September 25, 2018) is 2012 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: March 29, 2019 Z. Zhang 7 Juniper Networks, Inc. 8 September 25, 2018 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-10 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 March 29, 2019. 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 Section 5 of 158 [RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no 159 tunnel information present". This procedure allows explicit tracking 160 of individual flows, even though all those flows are assigned to 161 tunnels in 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 information present". 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 present", is 197 expected to forward the S-PMSI A-D route, with the same PTA, to 198 the next 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 Information 211 Required" (LIR) 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 Information 215 Required per Flow" bit (LIR-pF). This flag may be set in the PTA of 216 a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The 217 conditions under which it should be set by the originator of the 218 route are discussed in Section 4. The significance of the flag in a 219 received 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 present", as specified in Section 5 of 286 [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 present". 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 present". 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 present", but does not have either LIR or 306 LIR-pF set. (That is, DO NOT ignore an S-PMSI A-D route that has 307 a PTA specifying "no tunnel information present" unless its LIR 308 and LIR-pF bits are both clear). Then apply the rules (from 309 [RFC6625] and other documents that update [RFC6625]) for finding 310 the "match for reception". The result (if any) is the match for 311 tracking". 313 Note that the procedure for finding the match for tracking takes 314 into account S-PMSI A-D routes whose PTAs specify "no tunnel 315 information present" and that have either LIR or LIR-pf set. The 316 procedure for finding the match for reception ignores such routes. 318 We will clarify this with a few examples. In these examples, we 319 assume that there is only one segmentation domain. In this case, the 320 ingress and egress nodes are Provider Edge (PE) routers. 322 Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 323 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has 324 installed the following two routes that were originated by PE2: 326 o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a 327 tunnel. 329 o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no 330 tunnel information present" and has LIR set. 332 Route1 is (C-S1,C-G1)'s match for reception, and Route2 is 333 (C-S1,C-G1)'s match for tracking. 335 Continuing this example, suppose: 337 o PE1 has chosen PE2 as the upstream PE for a different flow, 338 (C-S2,C-G2). 340 o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). 342 In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for 343 tracking as well as its match for reception. 345 Also note that if a match for tracking does not have the LIR flag or 346 the LIR-pF flag set, no explicit tracking information will be 347 generated. See Section 5. 349 As another example, suppose PE1 has installed the following two 350 routes that were originated by PE2: 352 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 353 PTA specifies a tunnel) 355 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 356 tunnel. 358 Then Route2 is both the "match for reception" and the "match for 359 tracking" for (C-S1,C-G1). 361 Note that for a particular C-flow, PE1's match for reception might be 362 the same route as its match for tracking, or its match for reception 363 might be a "less specific" route than its match for tracking. But 364 its match for reception can never be a "more specific" route than its 365 match for tracking. 367 4. Ingress Node Initiation of Tracking 369 An ingress node that needs to initiate explicit tracking for a 370 particular flow or set of flows can do so by performing one of the 371 following procedures: 373 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 374 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 375 its NLRI, including a PTA in that route, and setting the LIR flag 376 in that PTA. The PTA may specify a particular tunnel, or may 377 specify "no tunnel information present". 379 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 380 specify "no tunnel information present" unless the ingress node 381 also originates an A-D route carrying a PTA that specifies the 382 tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route 383 could be an I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a 384 (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. 385 (There is no point in requesting explicit tracking for a given 386 flow if there is no tunnel on which the flow is being carried.) 388 Note that if the ingress node originates a wildcard S-PMSI A-D 389 route carrying a PTA specifying the tunnel to be used for 390 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 391 set, then explicit tracking for (C-S1,C-G1) is requested by that 392 S-PMSI A-D route. In that case, the ingress node SHOULD NOT 393 originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no 394 tunnel information present"; such a route would not provide any 395 additional functionality. 397 To terminate explicit tracking that has been initiated by an 398 S-PMSI A-D route whose PTA specifies "no tunnel information 399 present", the ingress node withdraws the route. 401 To terminate explicit tracking that has been initiated by an 402 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 403 re-originates the route without the LIR flag set. 405 2. The following procedure can be used if and only if it is known 406 that the egress nodes support the optional LIR-pF flag. If the 407 ingress node originates a wildcard S-PMSI A-D route, it can 408 initiate explicit tracking for the individual flows that match 409 the wildcard route by setting the LIR-pF flag in the PTA of the 410 wildcard route. If an egress node needs to receive one or more 411 flows for which that wildcard route is a match for tracking, the 412 egress node will originate a Leaf A-D route for each such flow, 413 as specified in Section 5.2). 415 When following this procedure, the PTA of the S-PMSI A-D route 416 may specify a tunnel, or may specify "no tunnel information 417 present". The choice between these two options is determined by 418 considerations that are outside the scope of this document. 420 To terminate explicit tracking that has been initiated by an 421 S-PMSI A-D route whose PTA specifies "no tunnel information 422 present", the ingress node withdraws the route. 424 To terminate explicit tracking that has been initiated by an 425 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 426 re-originates the route without either the LIR or LIR-pF flags 427 set. 429 Note that this procedure (procedure 2 of Section 4) may not yield 430 the expected results if there are egress nodes that do not 431 support the LIR-pF flag, and hence SHOULD NOT be used in that 432 case. 434 5. Egress Node Response to the Match for Tracking 436 5.1. General Egress Node Procedures 438 There are four cases to consider: 440 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 441 state, the egress node's match for tracking is same as its match 442 for reception, and neither LIR nor LIR-pF flags are on. 444 In this case, the egress node does not originate a Leaf A-D route 445 in response to the match for reception/tracking, and there is no 446 explicit tracking of the flow. This document specifies no new 447 procedures for this case. 449 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 450 state, the egress node's match for tracking is the same as its 451 match for reception, LIR is set, but LIR-pF is not set. 453 In this case, a Leaf A-D route is originated by the egress node, 454 corresponding to the S-PMSI A-D route that is the match for 455 reception/tracking. Construction of the Leaf A-D route is as 456 specified in [RFC6514]; this document specifies no new procedures 457 for this case. 459 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 460 state, the egress node's match for tracking is the same as its 461 match for reception, and LIR-pF is set. The egress node MUST 462 follow whatever procedures are required by other specifications, 463 based on the match for reception. If the egress node supports 464 the LIR-pF flag, it MUST also follow the procedures of 465 Section 5.2. 467 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 468 state, the egress node's match for tracking is not the same as 469 its match for reception. This can only happen if the match for 470 tracking has a PTA specifying "no tunnel information present", 471 with either LIR or LIR-pF set. In this case, the egress node 472 MUST respond, separately, BOTH to the match for tracking and to 473 the match for reception. 475 When responding to the match for reception, the egress node MUST 476 ignore the LIR-pF flag. However, the LIR flag is processed 477 normally per the procedures for the match for reception. 479 If the match for tracking has LIR set and if either (a) the 480 egress node does not support LIR-pF, or (b) LIR-pF is not set, 481 then the behavior of the egress node is not affected by the 482 procedures of this document. 484 If the match for tracking has LIR-pF set, and the egress node 485 supports the LIR-pF flag, the egress node must originate one or 486 more Leaf A-D routes, as specified in Section 5.2. 488 Note that if LIR is set in the PTA of the match for reception, 489 the egress node may need to originate one or more Leaf A-D routes 490 corresponding to the match for tracking, as well as originating a 491 Leaf A-D route corresponding to the match for reception. 493 5.2. Responding to the LIR-pF Flag 495 To respond to a match for tracking that has LIR-pF set, an egress 496 node originates one or more Leaf A-D routes. 498 Suppose the egress node has multicast state for a (C-S,C-G) or a 499 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 500 which has the LIR-pF flag set, to be the match for tracking for that 501 flow. Then if the egress node supports the LIR-pF flag, it MUST 502 originate a Leaf A-D route whose NLRI identifies that particular 503 flow. Note that if a single S-PMSI A-D route (with wild cards) is 504 the match for tracking for multiple flows, the egress node may need 505 to originate multiple Leaf A-D routes, one for each such flow. We 506 say that, from the perspective of a given egress node, a given S-PMSI 507 A-D route tracks the set of flows for which it is the match for 508 tracking. Each of the Leaf A-D routes originated in response to that 509 S-PMSI A-D route tracks a single such flow. 511 The NLRI of each the Leaf A-D route that tracks a particular flow is 512 constructed as follows. The "route key" field of the NLRI will have 513 the following format: 515 +-----------------------------------+ 516 | RD (8 octets) | 517 +-----------------------------------+ 518 | Multicast Source Length (1 octet) | 519 +-----------------------------------+ 520 | Multicast Source (Variable) | 521 +-----------------------------------+ 522 | Multicast Group Length (1 octet) | 523 +-----------------------------------+ 524 | Multicast Group (Variable) | 525 +-----------------------------------+ 526 | Ingress PE's IP address | 527 +-----------------------------------+ 529 Figure 1: NLRI of S-PMSI A-D Route 531 o The "ingress PE" address is taken from the "originating router" 532 field of the NLRI of the S-PMSI A-D route that is the match for 533 tracking. 535 o The multicast source and group fields specify the S and G of one 536 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 537 is being tracked by this Leaf A-D route, the source field is 538 omitted, and its length is set to 0. 540 o The Route Distinguisher (RD) field is set to the value of the RD 541 field from the NLRI of the S-PMSI A-D route. 543 The encoding of these Leaf A-D routes is similar to the encoding of 544 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 545 were designed for the support of "global table multicast". However, 546 [RFC7524] sets the RD to either 0 or -1; following the procedures of 547 the present document, the RD will never be 0 or -1. Therefore Leaf 548 A-D routes constructed according to the procedures of this section 549 can always be distinguished from the Leaf A-D routes constructed 550 according to the procedures of section 6.2.2 of [RFC7524]. Also, 551 Leaf A-D routes constructed according to the procedures of this 552 section are VPN-specific routes, and will always carry an IP-address- 553 specific Route Target, as specified in [RFC6514]. 555 If a Leaf A-D route is originated as a response to a match for 556 tracking whose PTA specifies "no tunnel information present", the 557 Leaf A-D route MUST carry a PTA that specifies "no tunnel information 558 present". The LIR-pF flag in this PTA MUST be set. 560 In the case where the match for tracking and the match for reception 561 are the same, the PTA of the match may have both the LIR and the 562 LIR-pF flags set. This may cause the egress node to originate one 563 Leaf A-D route in response to the LIR bit, and one or more Leaf A-D 564 routes in response to the LIR-pF bit. Each such Leaf A-D route MUST 565 have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that 566 when the match for tracking is the same as the match for reception, 567 the PTA of the match for tracking/reception will have specified a 568 tunnel type. The following rules specify how the PTA of the Leaf A-D 569 route is to be constructed: 571 o If the tunnel type of the PTA attached to the match for tracking/ 572 reception is Ingress Replication, the Leaf A-D route's PTA MAY 573 specify Ingress Replication. In this case, the MPLS Label field 574 of the PTA MAY be a non-zero value. If so, this label value will 575 be used by the ingress PE when it transmits, to the egress PE, 576 packets of the flow identified in the Leaf A-D route's NLRI. 578 Alternatively, the egress PE MAY specify an MPLS label value of 579 zero, or it MAY specify a tunnel type of "no tunnel information 580 present". In either of these cases, when the ingress PE transmits 581 packets of the identified flow to the egress PE, it will use the 582 label that the egress PE specified in the PTA of the Leaf A-D 583 route that it originated in response to the LIR bit of the match 584 for reception. 586 o If the tunnel type of the PTA attached to the match for tracking/ 587 reception is any of the other tunnel types listed in [RFC6514] 588 Section 5, the PTA attached to the Leaf A-D route MUST specify a 589 tunnel type of "no tunnel information present". 591 o When additional tunnel types are defined, the specification for 592 how MVPN is to use those tunnel types must also specify how to 593 construct the PTA of a Leaf A-D route that is originated in 594 response to the LIR-pF flag. As an example, see [BIER-MVPN]. 596 Of course, an egress node that originates such Leaf A-D routes needs 597 to remember which S-PMSI A-D route caused these Leaf A-D routes to be 598 originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D 599 routes MUST be withdrawn. 601 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 602 or explicitly) if the egress node changes its Upstream Multicast Hop 603 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 604 route's NLRI, or if the egress node that originated the route no 605 longer needs to receive the flow identified in the NLRI of the route. 607 Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G) 608 state after it has already received the S-PMSI A-D that is the match 609 for tracking for that state. In this case, a Leaf A-D route needs to 610 be originated at that time, and the egress node must remember that 611 the new Leaf A-D route corresponds to that match for tracking. 613 Note that if a particular S-PMSI A-D route is a match for tracking 614 but not a match for reception, the LIR bit in its PTA is ignored if 615 the LIR-pF bit is set. 617 5.3. When the Egress Node is an ABR or ASBR 619 When segmented P-tunnels are used, the ingress and egress nodes may 620 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 621 S-PMSI A-D route also forwards that route. If the PTA of an 622 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 623 MAY change the PTA to specify a different tunnel type (as discussed 624 in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to 625 originate a Leaf A-D route, as specified in [RFC6514] and/or 626 [RFC7524]. 628 Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, 629 and also has LIR-pF set. The egress ABR/ASBR originates a 630 corresponding Leaf A-D route for a given (C-S,C-G) only if it knows 631 that it needs to receive that flow. It will know this by virtue of 632 receiving a corresponding Leaf A-D route from downstream. (In the 633 case where the PTA specifies a tunnel but LIR-pF is not set, this 634 document does not specify any new procedures.) 636 The procedures in the remainder of this section apply only when an 637 egress ABR/ASBR has installed an S-PMSI A-D route whose PTA specifies 638 "no tunnel information present" but has LIR or LIR-pF set. 640 If the PTA of the installed S-PMSI A-D route specifies "no tunnel 641 information present", the egress ABR/ASBR MUST pass the PTA along 642 unchanged when it forwards the S-PMSI A-D route. (That is, a PTA 643 specifying "no tunnel information present" MUST NOT be changed into a 644 PTA specifying a tunnel.) Furthermore, if the PTA specifies "no 645 tunnel information present", the LIR and LIR-pF flags in the PTA MUST 646 be passed along unchanged. 648 As a result of propagating such an S-PMSI A-D route, the egress ABR/ 649 ASBR may receive one or more Leaf A-D routes that correspond to that 650 S-PMSI A-D route. These routes will be received carrying an IP- 651 address-specific Route Target (RT) Extended Community that specifies 652 the address of the egress ABR/ASBR. The egress ABR/ASBR will 653 propagate these Leaf A-D routes, after changing the RT as follows. 654 The "global administrator" field of the modified RT will be set to 655 the IP address taken either from the S-PMSI A-D route's next hop 656 field ([RFC6514]), or from its Segmented P2MP Next Hop Extended 657 Community ([RFC7524]). 659 This procedure enables the ingress PE to explicitly track the egress 660 PEs for a given flow, even if segmented tunnels are being used. 661 However, cross-domain explicit tracking utilizes S-PMSI A-D routes 662 that do not specify tunnel information; therefore it can only be done 663 when the S-PMSI A-D route which is a flow's match for tracking is 664 different than the S-PMSI A-D route which is that flow's match for 665 reception. 667 6. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set 669 Consider the following situation: 671 o An ingress node, call it N, receives a Leaf A-D route, call it L. 673 o L carries an IP-address-specific RT identifying N. 675 o The route key field of L's NLRI is not identical to the NLRI of 676 any current I-PMSI or S-PMSI A-D route originated by N. 678 Per the procedures of [RFC6514] and [RFC7524], such a Leaf A-D route 679 does not cause any MVPN-specific action to be taken by N. 681 This document modifies those procedures in the case where there is a 682 current S-PMSI A-D route with a wildcard NLRI, originated by N, to 683 which L is a valid response according to the procedures of 684 Section 5.2. In this case, L MUST be processed by N. 686 Suppose that L's PTA specifies a tunnel type of Ingress Replication, 687 and that it also specifies a non-zero MPLS label. Then if N needs to 688 send to L a packet belonging to the multicast flow or flows 689 identified in L's NLRI, N MUST use the specified label. 691 If L's PTA meets any of the following conditions: 693 o It specifies a tunnel type of "no tunnel information present", or 695 o It specifies a tunnel type of Ingress Replication, but specifies 696 an MPLS label of zero, or 698 o It specifies another of the tunnel types listed in Section 5 of 699 [RFC6514], 701 then the action taken by N when it receives L is a local matter. In 702 this case, the Leaf A-D route L provides N with explicit tracking 703 information for the flow identified by L's NLRI. However, that 704 information is for management/monitoring purposes and does not have 705 an effect on the flow of multicast traffic. 707 If L's PTA specifies a tunnel type not mentioned above, the 708 specification for how MVPN uses that tunnel type must specify the 709 actions that N is to take upon receiving L. As an example, see 710 [BIER-MVPN]. 712 7. Acknowledgments 714 The authors wish to thank Robert Kebler for his ideas and comments. 715 We also thank Stephane Litkowski for his thorough review and useful 716 suggestions. 718 8. IANA Considerations 720 The LIR-pF flag needs to be added to the "P-Multicast Service 721 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 722 Gateway Protocol (BGP) Parameters" registry. This registry is 723 defined in [RFC7902]. The requested value is Bit Position 2. This 724 document should be the reference. 726 9. Security Considerations 728 The Security Considerations of [RFC6513] and [RFC6514] apply. 730 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 731 large number of Leaf A-D routes can be elicited. If this flag is set 732 when not desired (through either error or malfeasance), a significant 733 increase in control plane overhead can result. The specification of 734 counter-measures for this problem is outside the scope of this 735 document. 737 10. References 739 10.1. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 747 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 748 2012, . 750 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 751 Encodings and Procedures for Multicast in MPLS/BGP IP 752 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 753 . 755 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 756 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 757 RFC 6625, DOI 10.17487/RFC6625, May 2012, 758 . 760 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 761 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 762 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 763 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 764 . 766 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 767 P-Multicast Service Interface Tunnel Attribute Flags", 768 RFC 7902, DOI 10.17487/RFC7902, June 2016, 769 . 771 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 772 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 773 May 2017, . 775 10.2. Informative References 777 [BIER-MVPN] 778 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 779 Przygienda, "Multicast VPN Using BIER", internet-draft 780 draft-ietf-bier-mvpn-11, March 2018. 782 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 783 "Multicast Virtual Private Network (MVPN): Using 784 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 785 July 2015, . 787 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 788 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 789 RFC 7900, DOI 10.17487/RFC7900, June 2016, 790 . 792 Authors' Addresses 794 Andrew Dolganow 795 Nokia 796 438B Alexandra Rd #08-07/10 797 Alexandra Technopark 798 Singapore 119968 799 Singapore 801 Email: andrew.dolganow@nokia.com 802 Jayant Kotalwar 803 Nokia 804 701 East Middlefield Rd 805 Mountain View, California 94043 806 United States of America 808 Email: jayant.kotalwar@nokia.com 810 Eric C. Rosen (editor) 811 Juniper Networks, Inc. 812 10 Technology Park Drive 813 Westford, Massachusetts 01886 814 United States of America 816 Email: erosen@juniper.net 818 Zhaohui Zhang 819 Juniper Networks, Inc. 820 10 Technology Park Drive 821 Westford, Massachusetts 01886 822 United States of America 824 Email: zzhang@juniper.net