idnits 2.17.1 draft-ietf-bess-mvpn-expl-track-12.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 (October 9, 2018) is 2026 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: April 12, 2019 Z. Zhang 7 Juniper Networks, Inc. 8 October 9, 2018 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-12 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 April 12, 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 . . . . . . . . . . . . . . . . . . . . . . . 18 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 This document clarifies the procedures for originating and receiving 203 S-PMSI A-D routes and Leaf A-D routes. This document also adds new 204 procedures to allow more efficient explicit tracking. The procedures 205 being clarified and/or extended are discussed in multiple places in 206 the documents being updated. 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in BCP 211 14 [RFC2119] [RFC8174] when, and only when, they appear in all 212 capitals, as shown here. 214 2. The Explicit Tracking Flags 216 [RFC6514] defines one flag in the PTA, the "Leaf Information 217 Required" (LIR) flag, that is used for explicit tracking. 219 This document defines a new flag in the flags field of the PMSI 220 Tunnel attribute. This new flag is known as the "Leaf Information 221 Required per Flow" bit (LIR-pF). This flag may be set in the PTA of 222 a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The 223 conditions under which it should be set by the originator of the 224 route are discussed in Section 4. The significance of the flag in a 225 received S-PMSI A-D route is discussed in Sections 5 and 5.2. 227 If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR 228 flag of that PTA MUST also be set. 230 Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD 231 NOT be set unless it is known that all the PEs that are to receive 232 the route carrying the PTA support the flag. How this is known is 233 outside the scope of this document. 235 The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The 236 conditions under which it should be set by the originator of the 237 route are discussed in Section 5.2. The significance of the flag in 238 a received Leaf A-D route is discussed in Section 6. 240 Use of this flag in the PTA carried by other route types is outside 241 the scope of this document. Use of this flag in the PTA carried by 242 an S-PMSI A-D routes whose NLRI does not contain a wildcard is 243 outside the scope of this document. 245 It is worth noting what will happen if the LIR-pF flag is set in the 246 PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an 247 ingress node, but one or more of the egress nodes do not support the 248 LIR-pF flag: 250 1. The ingress node will not be able to determine the complete set 251 of egress node that are expecting a particular multicast flow 252 from that ingress node. 254 2. Depending upon the tunnel type, the ingress node may send a 255 particular multicast flow only to the egress nodes that do 256 support the LIR-pF flag. From the perspective of egress nodes 257 that do not support LIR-pF, certain flows may appear to be 258 "blackholed". 260 It is also worth noting that it is possible for an ingress node that 261 sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of 262 egress nodes that do not support this flag. 264 Since an ingress node that sets the LIR-pF flag is also REQUIRED to 265 set the LIR flag, egress nodes that do not support the LIR-pF flag 266 will respond, as specified in [RFC6514], to the ingress node's 267 (C-*,C-*) S-PMSI A-D route with a Leaf A-D route operator. 269 As will be discussed in Section 5.2, any Leaf A-D route originated in 270 response to an S-PMSI A-D route that has LIR-pF set will carry a PTA 271 whose LIR-pF flag is set. If an ingress node receives a Leaf A-D 272 route whose "route key" field corresponds to the NLRI of an S-PMSI 273 A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a 274 PTA or has a PTA where LIR-pF is clear, the ingress node can conclude 275 that the egress node originating that Leaf A-D route does not support 276 the LIR-pF flag. 278 The software at the ingress node MUST detect this, and MUST have a 279 way of alerting the operator that the deployment is not properly 280 configured. 282 3. Match for Tracking vs. Match for Reception 284 Section 3.2 of [RFC6625] specifies a set of rules for finding the 285 S-PMSI A-D route that is the "match for data reception" (or more 286 simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) 287 state. These rules do not take into account the fact that some 288 S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying 289 PTAs that do not identify any P-tunnel. (A PTA that does not 290 identify any P-tunnel is one whose "tunnel type" field has been set 291 to "no tunnel information present", as specified in Section 5 of 292 [RFC6514].) 294 The rules for finding a "match for reception" in [RFC6625] are hereby 295 modified as follows: 297 When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it 298 is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or 299 whose PTA specifies "no tunnel information present". 301 There are other RFCs that update [RFC6625] and that modify the rules 302 for finding a "match for reception". See, e.g., [RFC7582] and 303 [RFC7900]. When applying those modified rules, it is REQUIRED to 304 ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies 305 "no tunnel information present". 307 We also introduce a new notion, the "match for tracking": 309 For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for 310 tracking" is chosen as follows. Ignore any S-PMSI A-D route that 311 has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies 312 "no tunnel information present", but does not have either LIR or 313 LIR-pF set. (That is, DO NOT ignore an S-PMSI A-D route that has 314 a PTA specifying "no tunnel information present" unless its LIR 315 and LIR-pF bits are both clear). Then apply the rules (from 316 [RFC6625] and other documents that update [RFC6625]) for finding 317 the "match for reception". The result (if any) is the match for 318 tracking". 320 Note that the procedure for finding the match for tracking takes 321 into account S-PMSI A-D routes whose PTAs specify "no tunnel 322 information present" and that have either LIR or LIR-pf set. The 323 procedure for finding the match for reception ignores such routes. 325 We will clarify this with a few examples. In these examples, we 326 assume that there is only one segmentation domain. In this case, the 327 ingress and egress nodes are Provider Edge (PE) routers. 329 Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 330 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has 331 installed the following two routes that were originated by PE2: 333 o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a 334 tunnel. 336 o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no 337 tunnel information present" and has LIR set. 339 Route1 is (C-S1,C-G1)'s match for reception, and Route2 is 340 (C-S1,C-G1)'s match for tracking. 342 Continuing this example, suppose: 344 o PE1 has chosen PE2 as the upstream PE for a different flow, 345 (C-S2,C-G2). 347 o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). 349 In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for 350 tracking as well as its match for reception. 352 Also note that if a match for tracking does not have the LIR flag or 353 the LIR-pF flag set, no explicit tracking information will be 354 generated. See Section 5. 356 As another example, suppose PE1 has installed the following two 357 routes that were originated by PE2: 359 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 360 PTA specifies a tunnel) 362 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 363 tunnel. 365 Then Route2 is both the "match for reception" and the "match for 366 tracking" for (C-S1,C-G1). 368 Note that for a particular C-flow, PE1's match for reception might be 369 the same route as its match for tracking, or its match for reception 370 might be a "less specific" route than its match for tracking. But 371 its match for reception can never be a "more specific" route than its 372 match for tracking. 374 4. Ingress Node Initiation of Tracking 376 An ingress node that needs to initiate explicit tracking for a 377 particular flow or set of flows can do so by performing one of the 378 following procedures: 380 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 381 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 382 its NLRI, including a PTA in that route, and setting the LIR flag 383 in that PTA. The PTA may specify a particular tunnel, or may 384 specify "no tunnel information present". 386 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 387 specify "no tunnel information present" unless the ingress node 388 also originates an A-D route carrying a PTA that specifies the 389 tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route 390 could be an I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a 391 (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. 392 (There is no point in requesting explicit tracking for a given 393 flow if there is no tunnel on which the flow is being carried.) 395 Note that if the ingress node originates a wildcard S-PMSI A-D 396 route carrying a PTA specifying the tunnel to be used for 397 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 398 set, then explicit tracking for (C-S1,C-G1) is requested by that 399 S-PMSI A-D route. In that case, the ingress node SHOULD NOT 400 originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no 401 tunnel information present"; such a route would not provide any 402 additional functionality. 404 To terminate explicit tracking that has been initiated by an 405 S-PMSI A-D route whose PTA specifies "no tunnel information 406 present", the ingress node withdraws the route. 408 To terminate explicit tracking that has been initiated by an 409 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 410 re-originates the route without the LIR flag set. 412 2. The following procedure can be used if and only if it is known 413 that the egress nodes support the optional LIR-pF flag. If the 414 ingress node originates a wildcard S-PMSI A-D route, it can 415 initiate explicit tracking for the individual flows that match 416 the wildcard route by setting the LIR-pF flag in the PTA of the 417 wildcard route. If an egress node needs to receive one or more 418 flows for which that wildcard route is a match for tracking, the 419 egress node will originate a Leaf A-D route for each such flow, 420 as specified in Section 5.2). 422 When following this procedure, the PTA of the S-PMSI A-D route 423 may specify a tunnel, or may specify "no tunnel information 424 present". The choice between these two options is determined by 425 considerations that are outside the scope of this document. 427 To terminate explicit tracking that has been initiated by an 428 S-PMSI A-D route whose PTA specifies "no tunnel information 429 present", the ingress node withdraws the route. 431 To terminate explicit tracking that has been initiated by an 432 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 433 re-originates the route without either the LIR or LIR-pF flags 434 set. 436 Note that this procedure (procedure 2 of Section 4) may not yield 437 the expected results if there are egress nodes that do not 438 support the LIR-pF flag, and hence SHOULD NOT be used in that 439 case. 441 5. Egress Node Response to the Match for Tracking 443 5.1. General Egress Node Procedures 445 There are four cases to consider: 447 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 448 state, the egress node's match for tracking is same as its match 449 for reception, and neither LIR nor LIR-pF flags are on. 451 In this case, the egress node does not originate a Leaf A-D route 452 in response to the match for reception/tracking, and there is no 453 explicit tracking of the flow. This document specifies no new 454 procedures for this case. 456 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 457 state, the egress node's match for tracking is the same as its 458 match for reception, LIR is set, but LIR-pF is not set. 460 In this case, a Leaf A-D route is originated by the egress node, 461 corresponding to the S-PMSI A-D route that is the match for 462 reception/tracking. Construction of the Leaf A-D route is as 463 specified in [RFC6514]; this document specifies no new procedures 464 for this case. 466 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 467 state, the egress node's match for tracking is the same as its 468 match for reception, and LIR-pF is set. The egress node MUST 469 follow whatever procedures are required by other specifications, 470 based on the match for reception. If the egress node supports 471 the LIR-pF flag, it MUST also follow the procedures of 472 Section 5.2. 474 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 475 state, the egress node's match for tracking is not the same as 476 its match for reception. This can only happen if the match for 477 tracking has a PTA specifying "no tunnel information present", 478 with either LIR or LIR-pF set. In this case, the egress node 479 MUST respond, separately, BOTH to the match for tracking and to 480 the match for reception. 482 When responding to the match for reception, the egress node MUST 483 ignore the LIR-pF flag. However, the LIR flag is processed 484 normally per the procedures for the match for reception. 486 If the match for tracking has LIR set and if either (a) the 487 egress node does not support LIR-pF, or (b) LIR-pF is not set, 488 then the behavior of the egress node is not affected by the 489 procedures of this document. 491 If the match for tracking has LIR-pF set, and the egress node 492 supports the LIR-pF flag, the egress node must originate one or 493 more Leaf A-D routes, as specified in Section 5.2. 495 Note that if LIR is set in the PTA of the match for reception, 496 the egress node may need to originate one or more Leaf A-D routes 497 corresponding to the match for tracking, as well as originating a 498 Leaf A-D route corresponding to the match for reception. 500 5.2. Responding to the LIR-pF Flag 502 To respond to a match for tracking that has LIR-pF set, an egress 503 node originates one or more Leaf A-D routes. 505 Suppose the egress node has multicast state for a (C-S,C-G) or a 506 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 507 which has the LIR-pF flag set, to be the match for tracking for that 508 flow. Then if the egress node supports the LIR-pF flag, it MUST 509 originate a Leaf A-D route whose NLRI identifies that particular 510 flow. Note that if a single S-PMSI A-D route (with wild cards) is 511 the match for tracking for multiple flows, the egress node may need 512 to originate multiple Leaf A-D routes, one for each such flow. We 513 say that, from the perspective of a given egress node, a given S-PMSI 514 A-D route tracks the set of flows for which it is the match for 515 tracking. Each of the Leaf A-D routes originated in response to that 516 S-PMSI A-D route tracks a single such flow. 518 The NLRI of each the Leaf A-D route that tracks a particular flow is 519 constructed as follows. The "route key" field of the NLRI will have 520 the following format: 522 +-----------------------------------+ 523 | RD (8 octets) | 524 +-----------------------------------+ 525 | Multicast Source Length (1 octet) | 526 +-----------------------------------+ 527 | Multicast Source (Variable) | 528 +-----------------------------------+ 529 | Multicast Group Length (1 octet) | 530 +-----------------------------------+ 531 | Multicast Group (Variable) | 532 +-----------------------------------+ 533 | Ingress PE's IP address | 534 +-----------------------------------+ 536 Figure 1: NLRI of S-PMSI A-D Route 538 o The "ingress PE" address is taken from the "originating router" 539 field of the NLRI of the S-PMSI A-D route that is the match for 540 tracking. 542 o The multicast source and group fields specify the S and G of one 543 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 544 is being tracked by this Leaf A-D route, the source field is 545 omitted, and its length is set to 0. 547 o The Route Distinguisher (RD) field is set to the value of the RD 548 field from the NLRI of the S-PMSI A-D route. 550 The encoding of these Leaf A-D routes is similar to the encoding of 551 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 552 were designed for the support of "global table multicast". However, 553 [RFC7524] sets the RD to either 0 or -1; following the procedures of 554 the present document, the RD will never be 0 or -1. Therefore Leaf 555 A-D routes constructed according to the procedures of this section 556 can always be distinguished from the Leaf A-D routes constructed 557 according to the procedures of section 6.2.2 of [RFC7524]. Also, 558 Leaf A-D routes constructed according to the procedures of this 559 section are VPN-specific routes, and will always carry an IP-address- 560 specific Route Target, as specified in [RFC6514]. 562 If a Leaf A-D route is originated as a response to a match for 563 tracking whose PTA specifies "no tunnel information present", the 564 Leaf A-D route MUST carry a PTA that specifies "no tunnel information 565 present". The LIR-pF flag in this PTA MUST be set. 567 In the case where the match for tracking and the match for reception 568 are the same, the PTA of the match may have both the LIR and the 569 LIR-pF flags set. This may cause the egress node to originate one 570 Leaf A-D route in response to the LIR bit, and one or more Leaf A-D 571 routes in response to the LIR-pF bit. Each such Leaf A-D route MUST 572 have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that 573 when the match for tracking is the same as the match for reception, 574 the PTA of the match for tracking/reception will have specified a 575 tunnel type. The following rules specify how the PTA of the Leaf A-D 576 route is to be constructed: 578 o If the tunnel type of the PTA attached to the match for tracking/ 579 reception is Ingress Replication, the Leaf A-D route's PTA MAY 580 specify Ingress Replication. In this case, the MPLS Label field 581 of the PTA MAY be a non-zero value. If so, this label value will 582 be used by the ingress PE when it transmits, to the egress PE, 583 packets of the flow identified in the Leaf A-D route's NLRI. 585 Alternatively, the egress PE MAY specify an MPLS label value of 586 zero, or it MAY specify a tunnel type of "no tunnel information 587 present". In either of these cases, when the ingress PE transmits 588 packets of the identified flow to the egress PE, it will use the 589 label that the egress PE specified in the PTA of the Leaf A-D 590 route that it originated in response to the LIR bit of the match 591 for reception. 593 o If the tunnel type of the PTA attached to the match for tracking/ 594 reception is any of the other tunnel types listed in [RFC6514] 595 Section 5, the PTA attached to the Leaf A-D route MUST specify a 596 tunnel type of "no tunnel information present". 598 o When additional tunnel types are defined, the specification for 599 how MVPN is to use those tunnel types must also specify how to 600 construct the PTA of a Leaf A-D route that is originated in 601 response to the LIR-pF flag. As an example, see [BIER-MVPN]. 603 Of course, an egress node that originates such Leaf A-D routes needs 604 to remember which S-PMSI A-D route caused these Leaf A-D routes to be 605 originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D 606 routes MUST be withdrawn. 608 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 609 or explicitly) if the egress node changes its Upstream Multicast Hop 610 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 611 route's NLRI, or if the egress node that originated the route no 612 longer needs to receive the flow identified in the NLRI of the route. 614 Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G) 615 state after it has already received the S-PMSI A-D that is the match 616 for tracking for that state. In this case, a Leaf A-D route needs to 617 be originated at that time, and the egress node must remember that 618 the new Leaf A-D route corresponds to that match for tracking. 620 Note that if a particular S-PMSI A-D route is a match for tracking 621 but not a match for reception, the LIR bit in its PTA is ignored if 622 the LIR-pF bit is set. 624 5.3. When the Egress Node is an ABR or ASBR 626 When segmented P-tunnels are used, the ingress and egress nodes may 627 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 628 S-PMSI A-D route also forwards that route. If the PTA of an 629 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 630 MAY change the PTA to specify a different tunnel type (as discussed 631 in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to 632 originate a Leaf A-D route, as specified in [RFC6514] and/or 633 [RFC7524]. 635 Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, 636 and also has LIR-pF set. The egress ABR/ASBR originates a 637 corresponding Leaf A-D route for a given (C-S,C-G) only if it knows 638 that it needs to receive that flow. It will know this by virtue of 639 receiving a corresponding Leaf A-D route from downstream. (In the 640 case where the PTA specifies a tunnel but LIR-pF is not set, this 641 document does not specify any new procedures.) 643 The procedures in the remainder of this section apply only when an 644 egress ABR/ASBR has installed an S-PMSI A-D route whose PTA specifies 645 "no tunnel information present" but has LIR or LIR-pF set. 647 If the PTA of the installed S-PMSI A-D route specifies "no tunnel 648 information present", the egress ABR/ASBR MUST pass the PTA along 649 unchanged when it forwards the S-PMSI A-D route. (That is, a PTA 650 specifying "no tunnel information present" MUST NOT be changed into a 651 PTA specifying a tunnel.) Furthermore, if the PTA specifies "no 652 tunnel information present", the LIR and LIR-pF flags in the PTA MUST 653 be passed along unchanged. 655 As a result of propagating such an S-PMSI A-D route, the egress ABR/ 656 ASBR may receive one or more Leaf A-D routes that correspond to that 657 S-PMSI A-D route. These routes will be received carrying an IP- 658 address-specific Route Target (RT) Extended Community that specifies 659 the address of the egress ABR/ASBR. The egress ABR/ASBR will 660 propagate these Leaf A-D routes, after changing the RT as follows. 661 The "global administrator" field of the modified RT will be set to 662 the IP address taken either from the S-PMSI A-D route's next hop 663 field ([RFC6514]), or from its Segmented P2MP Next Hop Extended 664 Community ([RFC7524]). 666 This procedure enables the ingress PE to explicitly track the egress 667 PEs for a given flow, even if segmented tunnels are being used. 668 However, cross-domain explicit tracking utilizes S-PMSI A-D routes 669 that do not specify tunnel information; therefore it can only be done 670 when the S-PMSI A-D route which is a flow's match for tracking is 671 different than the S-PMSI A-D route which is that flow's match for 672 reception. 674 6. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set 676 Consider the following situation: 678 o An ingress node, call it N, receives a Leaf A-D route, call it L. 680 o L carries an IP-address-specific RT identifying N. 682 o The route key field of L's NLRI is not identical to the NLRI of 683 any current I-PMSI or S-PMSI A-D route originated by N. 685 Per the procedures of [RFC6514] and [RFC7524], such a Leaf A-D route 686 does not cause any MVPN-specific action to be taken by N. 688 This document modifies those procedures in the case where there is a 689 current S-PMSI A-D route with a wildcard NLRI, originated by N, to 690 which L is a valid response according to the procedures of 691 Section 5.2. In this case, L MUST be processed by N. 693 Suppose that L's PTA specifies a tunnel type of Ingress Replication, 694 and that it also specifies a non-zero MPLS label. Then if N needs to 695 send to L a packet belonging to the multicast flow or flows 696 identified in L's NLRI, N MUST use the specified label. 698 If L's PTA meets any of the following conditions: 700 o It specifies a tunnel type of "no tunnel information present", or 702 o It specifies a tunnel type of Ingress Replication, but specifies 703 an MPLS label of zero, or 705 o It specifies another of the tunnel types listed in Section 5 of 706 [RFC6514], 708 then the action taken by N when it receives L is a local matter. In 709 this case, the Leaf A-D route L provides N with explicit tracking 710 information for the flow identified by L's NLRI. However, that 711 information is for management/monitoring purposes and does not have 712 an effect on the flow of multicast traffic. 714 If L's PTA specifies a tunnel type not mentioned above, the 715 specification for how MVPN uses that tunnel type must specify the 716 actions that N is to take upon receiving L. As an example, see 717 [BIER-MVPN]. 719 7. Acknowledgments 721 The authors wish to thank Robert Kebler for his ideas and comments. 722 We also thank Stephane Litkowski for his thorough review and useful 723 suggestions. 725 8. IANA Considerations 727 IANA is requested to add a new entry to the the "P-Multicast Service 728 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 729 Gateway Protocol (BGP) Parameters" registry. This registry is 730 defined in [RFC7902]. The new entry is: 732 o Value: 2 734 o Name: LIR-PF 736 o Description: Leaf Information Required per-Flow 738 o Reference: this document. 740 9. Security Considerations 742 The Security Considerations of [RFC6513] and [RFC6514] apply. 744 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 745 large number of Leaf A-D routes can be elicited. If this flag is set 746 when not desired (through either error or malfeasance), a significant 747 increase in control plane overhead can result. The specification of 748 counter-measures for this problem is outside the scope of this 749 document. 751 10. References 753 10.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, 757 DOI 10.17487/RFC2119, March 1997, 758 . 760 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 761 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 762 2012, . 764 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 765 Encodings and Procedures for Multicast in MPLS/BGP IP 766 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 767 . 769 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 770 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 771 RFC 6625, DOI 10.17487/RFC6625, May 2012, 772 . 774 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 775 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 776 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 777 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 778 . 780 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 781 P-Multicast Service Interface Tunnel Attribute Flags", 782 RFC 7902, DOI 10.17487/RFC7902, June 2016, 783 . 785 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 786 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 787 May 2017, . 789 10.2. Informative References 791 [BIER-MVPN] 792 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 793 Przygienda, "Multicast VPN Using BIER", internet-draft 794 draft-ietf-bier-mvpn-11, March 2018. 796 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 797 "Multicast Virtual Private Network (MVPN): Using 798 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 799 July 2015, . 801 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 802 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 803 RFC 7900, DOI 10.17487/RFC7900, June 2016, 804 . 806 Authors' Addresses 808 Andrew Dolganow 809 Nokia 810 438B Alexandra Rd #08-07/10 811 Alexandra Technopark 812 Singapore 119968 813 Singapore 815 Email: andrew.dolganow@nokia.com 817 Jayant Kotalwar 818 Nokia 819 701 East Middlefield Rd 820 Mountain View, California 94043 821 United States of America 823 Email: jayant.kotalwar@nokia.com 825 Eric C. Rosen (editor) 826 Juniper Networks, Inc. 827 10 Technology Park Drive 828 Westford, Massachusetts 01886 829 United States of America 831 Email: erosen@juniper.net 833 Zhaohui Zhang 834 Juniper Networks, Inc. 835 10 Technology Park Drive 836 Westford, Massachusetts 01886 837 United States of America 839 Email: zzhang@juniper.net