idnits 2.17.00 (12 Aug 2021) /tmp/idnits53516/draft-ietf-bess-mvpn-expl-track-13.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 RFC7900, 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 (November 28, 2018) is 1263 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) == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 7582 7900 (if Nokia 5 approved) E. Rosen, Ed. 6 Intended status: Standards Track Z. Zhang 7 Expires: June 1, 2019 Juniper Networks, Inc. 8 November 28, 2018 10 Explicit Tracking with Wild Card Routes in Multicast VPN 11 draft-ietf-bess-mvpn-expl-track-13 13 Abstract 15 The Multicast VPN (MVPN) specifications provide procedures to allow a 16 multicast ingress node to invoke "explicit tracking" for a multicast 17 flow or set of flows, thus learning the egress nodes for that flow or 18 set of flows. However, the specifications are not completely clear 19 about how the explicit tracking procedures work in certain scenarios. 20 This document provides the necessary clarifications. It also 21 specifies a new, optimized explicit tracking procedure. This new 22 procedure allows an ingress node, by sending a single message, to 23 request explicit tracking of each of a set of flows, where the set of 24 flows is specified using a wildcard mechanism. This document updates 25 RFCs 6514, 6625, 7524, 7582, and 7900. 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 June 1, 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 . . . . . . . . . 7 64 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 9 65 5. Egress Node Response to the Match for Tracking . . . . . . . 10 66 5.1. General Egress Node Procedures . . . . . . . . . . . . . 11 67 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 12 68 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 15 69 6. Ingress Node Handling of Received Leaf A-D Routes with 70 LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 76 10.2. Informative References . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 The base Multicast VPN (MVPN) specifications,[RFC6513] and [RFC6514], 82 define the "Selective Provider Multicast Service Interface Auto- 83 Discovery route" (S-PMSI A-D route). 85 Per those RFCs, the S-PMSI A-D route contains a Network Layer 86 Reachability Information (NLRI) field that identifies a particular 87 multicast flow. In the terminology of those RFCs, each flow is 88 denoted by (C-S,C-G), where C-S is an IP source address and C-G is an 89 IP multicast address, both in the address space of a VPN customer. 90 The (C-S,C-G) of the multicast flow is encoded into the NLRI field. 92 An S-PMSI A-D route also carries a PMSI Tunnel attribute (PTA). 93 Typically, the PTA is used to identify a tunnel through the provider 94 backbone network (a "P-tunnel"). 96 By originating an S-PMSI A-D route identifying a particular multicast 97 flow and a particular P-tunnel, a node is advertising the following: 99 if the node has to transmit packets of the identified flow over 100 the backbone, it will transmit them through the identified tunnel. 102 [RFC6513] and [RFC6514] also define a procedure that allows an 103 ingress node of particular multicast flow to determine the set of 104 egress nodes that have requested to receive that flow from that 105 ingress node. The ability of an ingress node to identify the egress 106 nodes for a particular flow is known as "explicit tracking". An 107 ingress node requests explicit tracking by setting a flag (the "Leaf 108 Information Required" flag, or LIR) in the PTA. When an egress node 109 receives an S-PMSI A-D route with LIR set, the egress node originates 110 a Leaf A-D route whose NLRI field contains the NLRI from the 111 corresponding S-PMSI A-D route. In this way, the egress node 112 advertises that it has requested to receive the particular flow 113 identified in the NLRI of that S-PMSI A-D route. 115 [RFC6513] and [RFC6514] also allow an ingress node to originate an 116 S-PMSI A-D route whose PTA has LIR set, but which does not identify 117 any P-tunnel. This mechanism can be used when it is desired to do 118 explicit tracking of a flow without at the same time binding that 119 flow to a particular P-tunnel. 121 [RFC6625] (and other RFCs that update it) extends the specification 122 of S-PMSI A-D routes, and allows an S-PMSI A-D route to encode a 123 wildcard in its NLRI. Either the C-S or the C-G or both can be 124 replaced by wildcards. These routes are known as (C-*,C-S) S-PMSI 125 A-D routes, or as (C-S,C-*) S-PMSI A-D routes, or as (C-*,C-*) S-PMSI 126 A-D routes, depending on whether the C-S or C-G or both have been 127 replaced by wildcards. These routes are known jointly as "wildcard 128 S-PMSI A-D routes". 130 One purpose of this document is to clarify the way that the explicit 131 tracking procedures of [RFC6513] and [RFC6514] are applied when 132 wildcard S-PMSI A-D routes are used. 134 In addition, this document addresses the following scenario, which is 135 not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an 136 ingress node originates an S-PMSI A-D route whose NLRI specifies, for 137 example, (C-*,C-*) (i.e., both C-S and C-G are replaced by 138 wildcards), and whose PTA identifies a particular P-tunnel. Now 139 suppose that the ingress node wants explicit tracking for each 140 individual flow that it transmits (following the procedures of 141 [RFC6625]) on that P-tunnel. 143 In this example, if the ingress node sets LIR in the PTA of the 144 wildcard S-PMSI A-D route, each egress node that needs to receive a 145 flow from the ingress node will respond with a Leaf A-D route whose 146 NLRI specifies contains the (C-*,C-*) wildcard. This allows the 147 ingress node to determine the set of egress nodes that are interested 148 in receiving flows from the ingress node. However, it does not allow 149 the ingress node to determine exactly which flows are of interest to 150 which egress nodes. 152 If the ingress node needs to determine which egress nodes are 153 interested in receiving which flows, it needs to originate an S-PMSI 154 A-D route for each individual (C-S,C-G) flow that it is transmitting, 155 and it needs to set LIR in the PTA of each such route. However, 156 since all the flows are being sent through the tunnel identified in 157 the (C-*,C-*) S-PMSI A-D route, there is no need to identify a tunnel 158 in the PTA of each (C-S,C-G) S-PMSI A-D route. Per Section 5 of 159 [RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no 160 tunnel information present". This procedure allows explicit tracking 161 of individual flows, even though all those flows are assigned to 162 tunnels by wildcard S-PMSI A-D routes. 164 However, this procedure requires several clarifications: 166 o The procedures of [RFC6625] do not address the case of an S-PMSI 167 A-D route whose NLRI contains wild cards, but whose PTA specifies 168 "no tunnel information present". 170 o If it is desired to send a set of flows through the same tunnel 171 (where that tunnel is advertised in a wildcard S-PMSI A-D route), 172 but it is also desired to explicitly track each individual flow 173 transmitted over that tunnel, one has to send an S-PMSI A-D route 174 (with LIR set in the PTA) for each individual flow. It would be 175 more optimal if the ingress node could just send a single wildcard 176 S-PMSI A-D route binding the set of flows to a particular tunnel, 177 and have the egress nodes respond with Leaf A-D routes for each 178 individual flow. 180 o [RFC6513] and [RFC6514] support the notion of "segmented 181 P-tunnels", where "segmentation" occurs at Autonomous System 182 Border Routers (ASBRs); [RFC7524] extends the notion of segmented 183 P-tunnels so that segmentation can occur at Area Border Routers 184 (ABRs). One can think of a segmented P-tunnel as passing through 185 a number of "segmentation domains". In each segmentation domain, 186 a given P-tunnel has an ingress node and a set of egress nodes. 187 The explicit tracking procedures allow an ingress node of a 188 particular segmentation domain to determine, for a particular flow 189 or set of flows, the egress nodes of that segmentation domain. 190 This has given rise to two further problems: 192 * The explicit tracking procedures do not allow an ingress node 193 to "see" past the boundaries of the segmentation domain. 195 * The prior specifications do not make it very clear whether a 196 segmented tunnel egress node, upon receiving an S-PMSI A-D 197 route whose PTA specifies "no tunnel information present", is 198 expected to forward the S-PMSI A-D route, with the same PTA, to 199 the next segmentation domain. 201 These problems are addressed in Section 5.3. 203 This document clarifies the procedures for originating and receiving 204 S-PMSI A-D routes and Leaf A-D routes. This document also adds new 205 procedures to allow more efficient explicit tracking. The procedures 206 being clarified and/or extended are discussed in multiple places in 207 the documents being updated. 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 211 "OPTIONAL" in this document are to be interpreted as described in BCP 212 14 [RFC2119] [RFC8174] when, and only when, they appear in all 213 capitals, as shown here. 215 2. The Explicit Tracking Flags 217 [RFC6514] defines one flag in the PTA, the "Leaf Information 218 Required" (LIR) flag, that is used for explicit tracking. 220 This document defines a new flag in the flags field of the PMSI 221 Tunnel attribute. This new flag is known as the "Leaf Information 222 Required per Flow" bit (LIR-pF). This flag may be set in the PTA of 223 a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The 224 conditions under which it should be set by the originator of the 225 route are discussed in Section 4. The significance of the flag in a 226 received wildcard S-PMSI A-D route is discussed in Sections 5 and 227 5.2. 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 Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD 235 NOT be set in a route's PTA unless it is known that the flag is 236 supported by all the Provider Edge routers (PEs) that are to receive 237 that route. Typically, this might mean that the ability to set this 238 flag would be controlled by a configuration knob, and operators would 239 not set this knob unless they know that all the relevant PEs support 240 this feature. How this is known is outside the scope of this 241 document. 243 This document only defines procedures for the LIR-pF flag when that 244 flag is in the PTA of a wildcard S-PMSI A-D route, or in the PTA of a 245 Leaf A-D route. In all other cases, the flag SHOULD be clear, and 246 its value SHOULD be ignored. Use of the flag in such cases is 247 outside the scope of this document. 249 Section 5 of [RFC6514] lists a number of tunnel types. We will refer 250 to these as "6514-tunnel-types". Other tunnel types will be referred 251 to as "non-6514-tunnel-types". This document specifies procedures 252 for using the LIR-pF flag with 6514-tunnel-types. Procedures for 253 using the LIR-pF flag with non-6514-tunnel-types are outside the 254 scope of this document. 256 If it is desired to use a particular non-6514-tunnel-type in MVPN, 257 there needs to be a specification for how that tunnel type is used in 258 MVPN. If it is desired to use that tunnel type along with the LIR-pF 259 flag, that specification (or a followon specification) will have to 260 specify the rules for using the LIR-pF flag with that tunnel type. 261 As an example, see [BIER-MVPN]. In the absence of such a 262 specification (or in the absence of support for such a 263 specification): 265 o the originator of a route that carries a PTA SHOULD NOT set LIR-pF 266 in any PTA that specifies that tunnel type, and 268 o the receiver of a route that carries a PTA specifying that tunnel 269 type SHOULD treat the LIR-pF flag as if it were not set. 271 If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the 272 originator of that route MUST also set the LIR flag. If the PTA of a 273 received wildcard S-PMSI A-D route has LIR-pF set but does not have 274 LIR set, the receiver MUST log the fact that the flags appear to have 275 been improperly set. However, the route MUST then be processed 276 normally (as if both flags were set), as specified in this document. 278 It is worth noting what will happen if the LIR-pF flag is set in the 279 PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an 280 ingress node, but one or more of the egress nodes do not support the 281 LIR-pF flag: 283 1. The ingress node will not be able to determine the complete set 284 of egress nodes that are expecting a particular multicast flow 285 from that ingress node. 287 2. Depending upon the tunnel type, the ingress node may send a 288 particular multicast flow only to the egress nodes that do 289 support the LIR-pF flag. From the perspective of egress nodes 290 that do not support LIR-pF, certain flows may appear to be 291 "blackholed". 293 It is also worth noting that it is possible for an ingress node that 294 sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of 295 egress nodes that do not support this flag. 297 Since an ingress node that sets the LIR-pF flag is also required to 298 set the LIR flag, egress nodes that do not support the LIR-pF flag 299 will respond, as specified in [RFC6514], to the ingress node's 300 (C-*,C-*) S-PMSI A-D route with a Leaf A-D route. 302 As will be discussed in Section 5.2, any Leaf A-D route originated in 303 response to an S-PMSI A-D route that has LIR-pF set will carry a PTA 304 whose LIR-pF flag is set. If an ingress node receives a Leaf A-D 305 route whose "route key" field corresponds to the NLRI of an S-PMSI 306 A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a 307 PTA or has a PTA where LIR-pF is clear, the ingress node can infer 308 that the egress node originating that Leaf A-D route does not support 309 the LIR-pF flag. The software at the ingress node MUST detect this, 310 and MUST have a way of alerting the operator that the deployment is 311 not properly configured. 313 3. Match for Tracking vs. Match for Reception 315 Section 3.2 of [RFC6625] specifies a set of rules for finding the 316 S-PMSI A-D route that is the "match for data reception" (or more 317 simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) 318 state. These rules do not take into account the fact that some 319 S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying 320 PTAs that do not identify any P-tunnel. (A PTA that does not 321 identify any P-tunnel is one whose "tunnel type" field has been set 322 to "no tunnel information present", as specified in Section 5 of 323 [RFC6514].) 325 The rules for finding a "match for reception" in [RFC6625] are hereby 326 modified as follows: 328 When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it 329 is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or 330 whose PTA specifies "no tunnel information present". 332 There are other RFCs that update [RFC6625] and that modify the rules 333 for finding a "match for reception". See, e.g., [RFC7582] and 334 [RFC7900]. When applying those modified rules, it is REQUIRED to 335 ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies 336 "no tunnel information present". 338 We also introduce a new notion, the "match for tracking": 340 For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for 341 tracking" is chosen as follows. Ignore any S-PMSI A-D route that 342 has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies 343 "no tunnel information present" and has neither LIR nor LIR-pF 344 set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA 345 specifying "no tunnel information present" unless its LIR and 346 LIR-pF bits are both clear). Then apply the rules (from [RFC6625] 347 and other documents that update [RFC6625]) for finding the "match 348 for reception". The result (if any) is the "match for tracking". 350 Note that the procedure for finding the match for tracking takes 351 into account S-PMSI A-D routes whose PTAs specify "no tunnel 352 information present" and that have either LIR or LIR-pf set. The 353 procedure for finding the match for reception ignores such routes. 355 We will clarify this with a few examples. In these examples, we 356 assume that there is only one segmentation domain. In this case, the 357 ingress and egress nodes are Provider Edge (PE) routers. 359 Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 360 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has 361 installed the following two routes that were originated by PE2: 363 o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a 364 tunnel. 366 o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no 367 tunnel information present" and has LIR set. 369 Route1 is (C-S1,C-G1)'s match for reception, and Route2 is 370 (C-S1,C-G1)'s match for tracking. 372 Continuing this example, suppose: 374 o PE1 has chosen PE2 as the upstream PE for a different flow, 375 (C-S2,C-G2). 377 o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). 379 In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for 380 tracking as well as its match for reception. 382 Also note that if a match for tracking does not have the LIR flag or 383 the LIR-pF flag set, no explicit tracking information will be 384 generated. See Section 5. 386 As another example, suppose PE1 has installed the following two 387 routes that were originated by PE2: 389 o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the 390 PTA specifies a tunnel) 392 o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a 393 tunnel. 395 Then Route2 is both the "match for reception" and the "match for 396 tracking" for (C-S1,C-G1). 398 Note that for a particular C-flow, PE1's match for reception might be 399 the same route as its match for tracking, or its match for reception 400 might be a "less specific" route than its match for tracking. But 401 its match for reception can never be a "more specific" route than its 402 match for tracking. 404 4. Ingress Node Initiation of Tracking 406 An ingress node that needs to initiate explicit tracking for a 407 particular flow or set of flows can do so by performing one of the 408 following procedures: 410 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 411 originating an S-PMSI A-D route that identifies (C-S1,C-G1) in 412 its NLRI, including a PTA in that route, and setting the LIR flag 413 in that PTA. The PTA may specify a particular tunnel, or may 414 specify "no tunnel information present". 416 However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT 417 specify "no tunnel information present" unless the ingress node 418 also originates an A-D route carrying a PTA that specifies the 419 tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route 420 could be an "Inclusive Provider Multicast Service Interface Auto- 421 Discovery route" (I-PMSI A-D route), a (C-*,C-G1) S-PMSI A-D 422 route, a (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D 423 route. (There is no point in requesting explicit tracking for a 424 given flow if there is no tunnel on which the flow is being 425 carried.) 427 Note that if the ingress node originates a wildcard S-PMSI A-D 428 route carrying a PTA specifying the tunnel to be used for 429 carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit 430 set, then explicit tracking for (C-S1,C-G1) is requested by that 431 S-PMSI A-D route. In that case, the ingress node SHOULD NOT 432 originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no 433 tunnel information present"; such a route would not provide any 434 additional functionality. 436 To terminate explicit tracking that has been initiated by an 437 S-PMSI A-D route whose PTA specifies "no tunnel information 438 present", the ingress node withdraws the route. 440 To terminate explicit tracking that has been initiated by an 441 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 442 re-originates the route without the LIR flag set. 444 2. The following procedure can be used if and only if it is known 445 that the egress nodes support the optional LIR-pF flag. If the 446 ingress node originates a wildcard S-PMSI A-D route, it can 447 initiate explicit tracking for the individual flows that match 448 the wildcard route by setting the LIR-pF flag in the PTA of the 449 wildcard route. If an egress node needs to receive one or more 450 flows for which that wildcard route is a match for tracking, the 451 egress node will originate a Leaf A-D route for each such flow, 452 as specified in Section 5.2). 454 When following this procedure, the PTA of the S-PMSI A-D route 455 may specify a tunnel, or may specify "no tunnel information 456 present". The choice between these two options is determined by 457 considerations that are outside the scope of this document. 459 To terminate explicit tracking that has been initiated by an 460 S-PMSI A-D route whose PTA specifies "no tunnel information 461 present", the ingress node withdraws the route. 463 To terminate explicit tracking that has been initiated by an 464 S-PMSI A-D route whose PTA specifies a tunnel, the ingress node 465 re-originates the route without either the LIR or LIR-pF flags 466 set. 468 Note that this procedure (procedure 2 of Section 4) may not yield 469 the expected results if there are egress nodes that do not 470 support the LIR-pF flag, and hence SHOULD NOT be used in that 471 case. 473 5. Egress Node Response to the Match for Tracking 474 5.1. General Egress Node Procedures 476 There are four cases to consider: 478 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 479 state, the egress node's match for tracking is same as its match 480 for reception, and neither LIR nor LIR-pF flags are on. 482 In this case, the egress node does not originate a Leaf A-D route 483 in response to the match for reception/tracking, and there is no 484 explicit tracking of the flow. This document specifies no new 485 procedures for this case. 487 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 488 state, the egress node's match for tracking is the same as its 489 match for reception, LIR is set, but LIR-pF is not set. 491 In this case, a Leaf A-D route is originated by the egress node, 492 corresponding to the S-PMSI A-D route that is the match for 493 reception/tracking. Construction of the Leaf A-D route is as 494 specified in [RFC6514]; this document specifies no new procedures 495 for this case. 497 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 498 state, the egress node's match for tracking is the same as its 499 match for reception, and LIR-pF is set. The egress node follows 500 whatever procedures are required by other specifications, based 501 on the match for reception. However, any Leaf A-D route 502 originated by the egress node as a result MUST have the LIR-pF 503 flag set in its PTA. The egress node MUST also follow the 504 procedures of Section 5.2. 506 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 507 state, the egress node's match for tracking is NOT the same as 508 its match for reception. This can only happen if the match for 509 tracking has a PTA specifying "no tunnel information present", 510 with either LIR or LIR-pF set. In this case, the egress node 511 MUST respond, separately, BOTH to the match for tracking and to 512 the match for reception. 514 If a Leaf A-D route is originated in response to the match for 515 reception, the LIR-pF flag in the Leaf A-D route's PTA MUST have 516 the same value as the LIR-pF flag in the match for reception's 517 PTA. In all other respects, the procedures for responding to the 518 match for reception are not affected by this document. 520 If the match for tracking has LIR set but LIR-pF is not set, then 521 the behavior of the egress node is not affected by the procedures 522 of this document. 524 If the match for tracking has LIR-pF set, the egress node MUST 525 follow the procedures of Section 5.2. 527 Note that if LIR is set in the PTA of the match for reception, 528 the egress node may need to originate one or more Leaf A-D routes 529 corresponding to the match for tracking, as well as originating a 530 Leaf A-D route corresponding to the match for reception. 532 5.2. Responding to the LIR-pF Flag 534 To respond to a match for tracking that has LIR-pF set, an egress 535 node originates one or more Leaf A-D routes. 537 Suppose the egress node has multicast state for a (C-S,C-G) or a 538 (C-*,C-G) flow, and has determined a particular S-PMSI A-D route, 539 which has the LIR-pF flag set, to be the match for tracking for that 540 flow. Then if the egress node supports the LIR-pF flag, it MUST 541 originate a Leaf A-D route whose NLRI identifies that particular 542 flow. Note that if a single S-PMSI A-D route (with wild cards) is 543 the match for tracking for multiple flows, the egress node may need 544 to originate multiple Leaf A-D routes, one for each such flow. We 545 say that, from the perspective of a given egress node, a given S-PMSI 546 A-D route tracks the set of flows for which it is the match for 547 tracking. Each of the Leaf A-D routes originated in response to that 548 S-PMSI A-D route tracks a single such flow. 550 The NLRI of each the Leaf A-D route that tracks a particular flow is 551 constructed as follows. The "route key" field of the NLRI will have 552 the following format (as defined in Sections 4.4 and 4.3 of 553 [RFC6514]): 555 +-----------------------------------+ 556 | RD (8 octets) | 557 +-----------------------------------+ 558 | Multicast Source Length (1 octet) | 559 +-----------------------------------+ 560 | Multicast Source (Variable) | 561 +-----------------------------------+ 562 | Multicast Group Length (1 octet) | 563 +-----------------------------------+ 564 | Multicast Group (Variable) | 565 +-----------------------------------+ 566 | Ingress PE's IP address | 567 +-----------------------------------+ 569 Figure 1: NLRI of S-PMSI A-D Route 571 o The "ingress PE" address is taken from the "originating router" 572 field of the NLRI of the S-PMSI A-D route that is the match for 573 tracking. Section 2 of [RFC6515] explains how the receiver of a 574 Leaf A-D route determines the length of this field and the address 575 family of the PE's IP address. 577 o The multicast source and group fields specify the S and G of one 578 of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) 579 is being tracked by this Leaf A-D route, the source field is 580 omitted, and its length is set to 0. In this case, the Leaf A-D 581 route is known as a "wildcard Leaf A-D route". 583 o The Route Distinguisher (RD) field is set to the value of the RD 584 field from the NLRI of the S-PMSI A-D route. 586 The encoding of these Leaf A-D routes is similar to the encoding of 587 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which 588 were designed for the support of "global table multicast". However, 589 [RFC7524] sets the RD to either 0 or -1; following the procedures of 590 the present document, the RD will never be 0 or -1. Therefore Leaf 591 A-D routes constructed according to the procedures of this section 592 can always be distinguished from the Leaf A-D routes constructed 593 according to the procedures of section 6.2.2 of [RFC7524]. Also, 594 Leaf A-D routes constructed according to the procedures of this 595 section are VPN-specific routes, and will always carry an IP-address- 596 specific Route Target, as specified in [RFC6514]. 598 If a Leaf A-D route is originated as a response to a match for 599 tracking whose PTA specifies "no tunnel information present", the 600 Leaf A-D route MUST carry a PTA that specifies "no tunnel information 601 present". The LIR-pF flag in this PTA MUST be set. 603 If an egress node originates multiple Leaf A-D routes in response to 604 a single S-PMSI A-D route, and that S-PMSI A-D route is later 605 withdrawn, then those Leaf A-D routes MUST also be withdrawn. 607 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly 608 or explicitly) if the egress node changes its Upstream Multicast Hop 609 (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D 610 route's NLRI, or if the egress node that originated the route no 611 longer needs to receive that flow. 613 It is possible that an egress node will acquire (C-S,C-G) state or 614 (C-*,C-G) state after it has already received the S-PMSI A-D that is 615 the match for tracking for that state. In this case, a Leaf A-D 616 route needs to be originated at that time, and the egress node must 617 remember that the new Leaf A-D route corresponds to that match for 618 tracking. 620 If a particular S-PMSI A-D route is a match for tracking but not a 621 match for reception, the LIR bit in its PTA is ignored if the LIR-pF 622 bit is set. 624 When the match for tracking is the same as the match for reception, 625 the PTA of the match for tracking/reception will have specified a 626 tunnel type. Some of the rules for constructing the PTA of the Leaf 627 A-D route depend on the tunnel type, and some are independent of the 628 tunnel type. No matter what the tunnel type is, the LIR-pF flag MUST 629 be set. 631 If the match for tracking/reception is a wildcard S-PMSI A-D route, 632 the egress node may originate a wildcard Leaf A-D route in response, 633 as well as originating one or more non-wildcard Leaf A-D routes. 634 Note that the LIR-pF flag MUST be set in the wildcard Leaf A-D route 635 as well as in the non-wildcard Leaf A-D routes. 637 This document provides additional rules for constructing the PTA when 638 the tunnel type is a 6514-tunnel-type (see Section 2). 640 As discussed in Section 2, if a non-6514-tunnel-type is being used, 641 then presumably there is a specification for how that tunnel type is 642 used in MVPN. If it is desired to use that tunnel type along with 643 the LIR-pF flag, that specification (or a followon specification) 644 will have to specify the additional rules for constructing the PTA. 645 As an example, see [BIER-MVPN]. 647 For 6514-tunnel-types, additional rules for constructing the PTA are 648 as follows: 650 o If the tunnel type of the PTA attached to the match for tracking/ 651 reception is Ingress Replication, the Leaf A-D route's PTA MAY 652 specify Ingress Replication. In this case, the MPLS Label field 653 of the PTA MAY be a non-zero value. If so, this label value will 654 be used by the ingress PE when it transmits, to the egress PE, 655 packets of the flow identified in the Leaf A-D route's NLRI. 657 Alternatively, the egress PE MAY specify an MPLS label value of 658 zero, or it MAY specify a tunnel type of "no tunnel information 659 present". In either of these cases, when the ingress PE transmits 660 packets of the identified flow to the egress PE, it will use the 661 label that the egress PE specified in the PTA of the Leaf A-D 662 route that it originated in response to the LIR bit of the match 663 for reception. 665 o If the tunnel type of the PTA attached to the match for tracking/ 666 reception is any of the other 6514-tunnel-types, the PTA attached 667 to the Leaf A-D route MUST specify a tunnel type of "no tunnel 668 information present". 670 It may happen that the tunnel type is a non-6514-tunnel type, but 671 either (a) there is no specification for how to use that tunnel type 672 with the LIR-pF flag, or (b) there is such a specification, but the 673 egress node does not support it. In that case, the egress node MUST 674 treat the match for tracking/reception as if it had the LIR-pF bit 675 clear. 677 5.3. When the Egress Node is an ABR or ASBR 679 When segmented P-tunnels are used, the ingress and egress nodes may 680 be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an 681 S-PMSI A-D route also forwards that route. If the received PTA of an 682 installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR 683 MAY change the PTA before forwarding the route, in order to specify a 684 different tunnel type (as discussed in [RFC6514] and/or [RFC7524]). 685 The egress ABR/ASBR may also need to originate a Leaf A-D route, as 686 specified in [RFC6514] and/or [RFC7524]. 688 Suppose the S-PMSI A-D route as received has a PTA specifying a 689 tunnel, and also has LIR-pF set. The egress ABR/ASBR originates a 690 corresponding Leaf A-D route for a given (C-S,C-G) only if it knows 691 that it needs to receive that flow. It will know this by virtue of 692 receiving a corresponding Leaf A-D route from downstream. (In the 693 case where the PTA specifies a tunnel but LIR-pF is not set, this 694 document does not specify any new procedures.) 696 The procedures in the remainder of this section apply only when an 697 egress ABR/ASBR has installed an S-PMSI A-D route whose PTA as 698 received specifies "no tunnel information present" but has LIR or 699 LIR-pF set. 701 If the received PTA of the installed S-PMSI A-D route specifies "no 702 tunnel information present", the egress ABR/ASBR MUST pass the PTA 703 along unchanged when it forwards the S-PMSI A-D route. (That is, a 704 PTA specifying "no tunnel information present" MUST NOT be changed 705 into a PTA specifying a tunnel.) Furthermore, if the PTA specifies 706 "no tunnel information present", the LIR and LIR-pF flags in the PTA 707 MUST be passed along unchanged. 709 As a result of propagating such an S-PMSI A-D route, the egress ABR/ 710 ASBR may receive one or more Leaf A-D routes that correspond to that 711 S-PMSI A-D route. These routes will be received carrying an IP- 712 address-specific Route Target (RT) Extended Community that specifies 713 the address of the egress ABR/ASBR. The egress ABR/ASBR will 714 propagate these Leaf A-D routes, after changing the RT as follows. 715 The "global administrator" field of the modified RT will be set to 716 the IP address taken either from the S-PMSI A-D route's next hop 717 field ([RFC6514]), or from its Segmented Point-to-Multipoint (P2MP) 718 Next Hop Extended Community ([RFC7524]). The address from the 719 Segmented P2MP Next Hop Extended Community is used if that Extended 720 Community is present; otherwise the address from the next hop field 721 is used. 723 This procedure enables the ingress PE to explicitly track the egress 724 PEs for a given flow, even if segmented tunnels are being used. 725 However, cross-domain explicit tracking utilizes S-PMSI A-D routes 726 that do not specify tunnel information; therefore it can only be done 727 when the S-PMSI A-D route which is a flow's match for tracking is 728 different than the S-PMSI A-D route which is that flow's match for 729 reception. 731 6. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set 733 Consider the following situation: 735 o An ingress node, call it N, receives a Leaf A-D route, call it L. 737 o L carries an IP-address-specific RT identifying N. 739 o The route key field of L's NLRI is not identical to the NLRI of 740 any current I-PMSI or S-PMSI A-D route originated by N. 742 Per the procedures of [RFC6514] and [RFC7524], such a Leaf A-D route 743 does not cause any MVPN-specific action to be taken by N. 745 This document modifies those procedures in the case where there is a 746 current wildcard S-PMSI A-D route, originated by N, to which L is a 747 valid response according to the procedures of Section 5.2. In this 748 case, L MUST be processed by N. 750 Suppose that L's PTA specifies a tunnel type of Ingress Replication, 751 and that it also specifies a non-zero MPLS label. Then if N needs to 752 send to L a packet belonging to the multicast flow or flows 753 identified in L's NLRI, N MUST use the specified label. 755 If L's PTA meets any of the following conditions: 757 o It specifies a tunnel type of "no tunnel information present", or 759 o It specifies a tunnel type of Ingress Replication, but specifies 760 an MPLS label of zero, or 762 o It specifies any other 6514-tunnel-type, 764 then the action taken by N when it receives L is a local matter. In 765 this case, the Leaf A-D route L provides N with explicit tracking 766 information for the flow identified by L's NLRI. However, that 767 information is for management/monitoring purposes and does not have 768 any direct effect on the flow of multicast traffic. 770 If L's PTA specifies a non-6514-tunnel-type not mentioned above, 771 presumably there is a specification for how MVPN uses that tunnel 772 type. If the LIR-pF flag is to be used with that tunnel type, that 773 specification must specify the actions that N is to take upon 774 receiving L. As an example, see [BIER-MVPN]. In the absence of such 775 a specification, the LIR-pF flag SHOULD BE ignored. See 776 Section Section 2 for further discussion of non-6514-tunnel-types. 778 7. Acknowledgments 780 The authors wish to thank Robert Kebler for his ideas and comments, 781 and to thank Stephane Litkowski and Benjamin Kaduk for their thorough 782 reviews and useful suggestions. We would also like to thank Mirja 783 Kuhlewind for her attention to the Security Considerations section. 785 8. IANA Considerations 787 IANA is requested to add a new entry to the the "P-Multicast Service 788 Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border 789 Gateway Protocol (BGP) Parameters" registry. This registry is 790 defined in [RFC7902]. The new entry is: 792 o Value: 2 793 o Name: LIR-PF 795 o Description: Leaf Information Required per-Flow 797 o Reference: this document. 799 9. Security Considerations 801 The Security Considerations of [RFC6513] and [RFC6514] apply. 803 By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 804 large number of Leaf A-D routes can be elicited. If this flag is set 805 when not desired (through either error or malfeasance), a significant 806 increase in control plane overhead can result. Properly protecting 807 the control plane should prevent this kind of attack. 809 In the event such an attack occurs, mitigating it is unfortunately 810 not very straightforward. The ingress node can take note of the fact 811 that it is getting, in response to an S-PMSI A-D route that has 812 LIR-pF clear, one or more Leaf A-D routes that have LIR-pF set. By 813 default, the reception of such a route MUST be logged. However, it 814 is possible for such log entries to be "false positives" that 815 generate a lot of "noise" in the log; therefore implementations 816 SHOULD have a knob to disable this logging. 818 In theory, if one or more Leaf A-D routes with LIR-pF set arrive in 819 response to an S-PMSI A-D route with LIR-pF clear, withdrawing the 820 S-PMSI A-D route could put a stop to the attack. In practice, that 821 is not likely to be a very good strategy because: 823 o Under normal operating conditions, there are some race conditions 824 that may cause the ingress node to think it is being attacked, 825 when in fact it is not. 827 o If some egress nodes have a bug that causes them to set LIR-pF 828 when it should be clear, withdrawing the S-PMSI A-D route will 829 stop the flow of multicast data traffic to all the egress nodes, 830 causing an unnecessary customer-visible disruption. 832 o The same situation that caused the S-PMSI A-D route to be 833 originated in the first place will still exist after the S-PMSI 834 A-D route is withdrawn, so the route will just be re-originated. 836 In other words, any action that would ameliorate the effects of this 837 sort of attack would likely have a negative effect during normal 838 operation. Therefore it is really better to rely on security 839 mechanisms that protect the control plane generally, rather than 840 having a mechanism that is focused on this one particular type of 841 attack. 843 10. References 845 10.1. Normative References 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, 849 DOI 10.17487/RFC2119, March 1997, 850 . 852 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 853 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 854 2012, . 856 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 857 Encodings and Procedures for Multicast in MPLS/BGP IP 858 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 859 . 861 [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure 862 Addresses in BGP Updates for Multicast VPN", RFC 6515, 863 DOI 10.17487/RFC6515, February 2012, 864 . 866 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 867 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 868 RFC 6625, DOI 10.17487/RFC6625, May 2012, 869 . 871 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 872 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 873 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 874 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 875 . 877 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 878 P-Multicast Service Interface Tunnel Attribute Flags", 879 RFC 7902, DOI 10.17487/RFC7902, June 2016, 880 . 882 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 883 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 884 May 2017, . 886 10.2. Informative References 888 [BIER-MVPN] 889 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 890 Przygienda, "Multicast VPN Using BIER", internet-draft 891 draft-ietf-bier-mvpn-11, March 2018. 893 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 894 "Multicast Virtual Private Network (MVPN): Using 895 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 896 July 2015, . 898 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 899 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 900 RFC 7900, DOI 10.17487/RFC7900, June 2016, 901 . 903 Authors' Addresses 905 Andrew Dolganow 906 Nokia 907 438B Alexandra Rd #08-07/10 908 Alexandra Technopark 909 Singapore 119968 910 Singapore 912 Email: andrew.dolganow@nokia.com 914 Jayant Kotalwar 915 Nokia 916 701 East Middlefield Rd 917 Mountain View, California 94043 918 United States of America 920 Email: jayant.kotalwar@nokia.com 922 Eric C. Rosen (editor) 923 Juniper Networks, Inc. 924 10 Technology Park Drive 925 Westford, Massachusetts 01886 926 United States of America 928 Email: erosen@juniper.net 929 Zhaohui Zhang 930 Juniper Networks, Inc. 931 10 Technology Park Drive 932 Westford, Massachusetts 01886 933 United States of America 935 Email: zzhang@juniper.net