From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8534.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc8534.txt (limited to 'doc/rfc/rfc8534.txt') diff --git a/doc/rfc/rfc8534.txt b/doc/rfc/rfc8534.txt new file mode 100644 index 0000000..b55b976 --- /dev/null +++ b/doc/rfc/rfc8534.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Dolganow +Request for Comments: 8534 J. Kotalwar +Updates: 6514, 6625, 7524, 7582, 7900 Nokia +Category: Standards Track E. Rosen, Ed. +ISSN: 2070-1721 Z. Zhang + Juniper Networks, Inc. + February 2019 + + + Explicit Tracking with Wildcard Routes in Multicast VPN + +Abstract + + The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) + provide procedures to allow a multicast ingress node to invoke + "explicit tracking" for a multicast flow or set of flows, thus + learning the egress nodes for that flow or set of flows. However, + the specifications are not completely clear about how the explicit + tracking procedures work in certain scenarios. This document + provides the necessary clarifications. It also specifies a new, + optimized explicit-tracking procedure. This new procedure allows an + ingress node, by sending a single message, to request explicit + tracking of each of a set of flows, where the set of flows is + specified using a wildcard mechanism. This document updates RFCs + 6514, 6625, 7524, 7582, and 7900. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8534. + + + + + + + + + + + + +Dolganow, et al. Standards Track [Page 1] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. The Explicit-Tracking Flags . . . . . . . . . . . . . . . . . 5 + 3. Match for Tracking versus Match for Reception . . . . . . . . 7 + 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 9 + 5. Egress Node Response to the Match for Tracking . . . . . . . 11 + 5.1. General Egress Node Procedures . . . . . . . . . . . . . 11 + 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 12 + 5.3. When the Egress Node Is an ABR or ASBR . . . . . . . . . 15 + 6. Ingress Node Handling of Received Leaf A-D Routes with + LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 9.2. Informative References . . . . . . . . . . . . . . . . . 20 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + +1. Introduction + + The base Multicast VPN (MVPN) specifications, [RFC6513] and + [RFC6514], define the "Selective Provider Multicast Service Interface + Auto-Discovery route" (S-PMSI A-D route). + + Per those RFCs, the S-PMSI A-D route contains a Network Layer + Reachability Information (NLRI) field that identifies a particular + multicast flow. In the terminology of those RFCs, each flow is + denoted by (C-S,C-G), where C-S is an IP source address and C-G is an + IP multicast address, both in the address space of a VPN customer. + The (C-S,C-G) of the multicast flow is encoded into the NLRI field. + + + +Dolganow, et al. Standards Track [Page 2] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + An S-PMSI A-D route also carries a PMSI Tunnel attribute (PTA). + Typically, the PTA is used to identify a tunnel through the provider + backbone network (a "P-tunnel"). + + By originating an S-PMSI A-D route identifying a particular multicast + flow and a particular P-tunnel, a node is advertising the following: + + If the node has to transmit packets of the identified flow over + the backbone, it will transmit them through the identified tunnel. + + [RFC6513] and [RFC6514] also define a procedure that allows an + ingress node of a particular multicast flow to determine the set of + egress nodes that have requested to receive that flow from that + ingress node. The ability of an ingress node to identify the egress + nodes for a particular flow is known as "explicit tracking". An + ingress node requests explicit tracking by setting a flag (the "Leaf + Information Required" flag, or LIR flag) in the PTA. When an egress + node receives an S-PMSI A-D route with the LIR flag set, the egress + node originates a Leaf A-D route whose NLRI field contains the NLRI + from the corresponding S-PMSI A-D route. In this way, the egress + node advertises that it has requested to receive the particular flow + identified in the NLRI of that S-PMSI A-D route. + + [RFC6513] and [RFC6514] also allow an ingress node to originate an + S-PMSI A-D route whose PTA has the LIR flag set but that does not + identify any P-tunnel. This mechanism can be used when desired to do + explicit tracking of a flow without at the same time binding that + flow to a particular P-tunnel. + + [RFC6625] (and other RFCs that update it) extends the specification + of S-PMSI A-D routes and allows an S-PMSI A-D route to encode a + wildcard in its NLRI. Either the C-S or the C-G or both can be + replaced by wildcards. These routes are known as (C-*,C-S) S-PMSI + A-D routes, (C-S,C-*) S-PMSI A-D routes, or (C-*,C-*) S-PMSI A-D + routes, depending on whether the C-S or C-G or both have been + replaced by wildcards. These routes are known jointly as "wildcard + S-PMSI A-D routes". + + One purpose of this document is to clarify the way that the explicit + tracking procedures of [RFC6513] and [RFC6514] are applied when + wildcard S-PMSI A-D routes are used. + + In addition, this document addresses the following scenario, which is + not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an + ingress node originates an S-PMSI A-D route whose NLRI specifies, for + example, (C-*,C-*) (i.e., both C-S and C-G are replaced by wildcards) + + + + + +Dolganow, et al. Standards Track [Page 3] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + and whose PTA identifies a particular P-tunnel. Now suppose that the + ingress node wants explicit tracking for each individual flow that it + transmits (following the procedures of [RFC6625]) on that P-tunnel. + + In this example, if the ingress node sets the LIR flag in the PTA of + the wildcard S-PMSI A-D route, each egress node that needs to receive + a flow from the ingress node will respond with a Leaf A-D route whose + NLRI contains the (C-*,C-*) wildcard. This allows the ingress node + to determine the set of egress nodes that are interested in receiving + flows from the ingress node. However, it does not allow the ingress + node to determine exactly which flows are of interest to which egress + nodes. + + If the ingress node needs to determine which egress nodes are + interested in receiving which flows, it needs to originate an S-PMSI + A-D route for each individual (C-S,C-G) flow that it is transmitting, + and it needs to set the LIR flag in the PTA of each such route. + However, since all the flows are being sent through the tunnel + identified in the (C-*,C-*) S-PMSI A-D route, there is no need to + identify a tunnel in the PTA of each (C-S,C-G) S-PMSI A-D route. Per + Section 5 of [RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes + can specify "no tunnel information present". This procedure allows + explicit tracking of individual flows, even though all those flows + are assigned to tunnels by wildcard S-PMSI A-D routes. + + However, this procedure requires several clarifications: + + o The procedures of [RFC6625] do not address the case of an S-PMSI + A-D route whose NLRI contains wildcards but whose PTA specifies + "no tunnel information present". + + o If it is desired to send a set of flows through the same tunnel + (where that tunnel is advertised in a wildcard S-PMSI A-D route), + but it is also desired to explicitly track each individual flow + transmitted over that tunnel, one has to send an S-PMSI A-D route + (with the LIR flag set in the PTA) for each individual flow. It + would be more optimal if the ingress node could just send a single + wildcard S-PMSI A-D route binding the set of flows to a particular + tunnel and have the egress nodes respond with Leaf A-D routes for + each individual flow. + + o [RFC6513] and [RFC6514] support the notion of "segmented + P-tunnels", where "segmentation" occurs at Autonomous System + Border Routers (ASBRs); [RFC7524] extends the notion of segmented + P-tunnels so that segmentation can occur at Area Border Routers + (ABRs). One can think of a segmented P-tunnel as passing through + a number of "segmentation domains". In each segmentation domain, + a given P-tunnel has an ingress node and a set of egress nodes. + + + +Dolganow, et al. Standards Track [Page 4] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + The explicit tracking procedures allow an ingress node of a + particular segmentation domain to determine, for a particular flow + or set of flows, the egress nodes of that segmentation domain. + This has given rise to two further problems: + + * The explicit tracking procedures do not allow an ingress node + to "see" past the boundaries of the segmentation domain. + + * The prior specifications do not make it very clear whether a + segmented tunnel egress node, upon receiving an S-PMSI A-D + route whose PTA specifies "no tunnel information present", is + expected to forward the S-PMSI A-D route, with the same PTA, to + the next segmentation domain. + + These problems are addressed in Section 5.3. + + This document clarifies the procedures for originating and receiving + S-PMSI A-D routes and Leaf A-D routes. This document also adds new + procedures to allow more efficient explicit tracking. The procedures + being clarified and/or extended are discussed in multiple places in + the documents being updated. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. The Explicit-Tracking Flags + + [RFC6514] defines one flag in the PTA, the "Leaf Information + Required" (LIR) flag, that is used for explicit tracking. + + This document defines a new flag in the Flags field of the PMSI + Tunnel attribute. This new flag is known as the "Leaf Information + Required per Flow" flag (LIR-pF). This flag may be set in the PTA of + a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The + conditions under which it should be set by the originator of the + route are discussed in Section 4. The significance of the flag in a + received wildcard S-PMSI A-D route is discussed in Sections 5 and + 5.2. + + The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The + conditions under which it should be set by the originator of the + route are discussed in Section 5.2. The significance of the flag in + a received Leaf A-D route is discussed in Section 6. + + + +Dolganow, et al. Standards Track [Page 5] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD + NOT be set in a route's PTA unless it is known that the flag is + supported by all the Provider Edge (PE) routers that are to receive + that route. Typically, this might mean that the ability to set this + flag would be controlled by a configuration knob, and operators would + not set this knob unless they know that all the relevant PEs support + this feature. How this is known is outside the scope of this + document. + + This document only defines procedures for the LIR-pF flag when that + flag is in the PTA of a wildcard S-PMSI A-D route or a Leaf A-D + route. In all other cases, the flag SHOULD be clear, and its value + SHOULD be ignored. Use of the flag in these other cases is outside + the scope of this document. + + Section 5 of [RFC6514] lists a number of tunnel types. We will refer + to these as "6514-tunnel-types". Other tunnel types will be referred + to as "non-6514-tunnel-types". This document specifies procedures + for using the LIR-pF flag with 6514-tunnel-types. Procedures for + using the LIR-pF flag with non-6514-tunnel-types are outside the + scope of this document. + + If it is desired to use a particular non-6514-tunnel-type in MVPN, + there needs to be a specification for how that tunnel type is used in + MVPN. If it is desired to use that tunnel type along with the LIR-pF + flag, that specification (or a follow-on specification) will have to + specify the rules for using the LIR-pF flag with that tunnel type. + As an example, see [BIER-MVPN]. In the absence of such a + specification (or in the absence of support for such a + specification): + + o the originator of a route that carries a PTA SHOULD NOT set the + LIR-pF flag in any PTA that specifies that tunnel type, and + + o the receiver of a route that carries a PTA specifying that tunnel + type SHOULD treat the LIR-pF flag as if it were not set. + + If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the + originator of that route MUST also set the LIR flag. If the PTA of a + received wildcard S-PMSI A-D route has the LIR-pF flag set but does + not have the LIR flag set, the receiver MUST log the fact that the + flags appear to have been improperly set. However, the route MUST + then be processed normally (as if both flags were set), as specified + in this document. + + + + + + + +Dolganow, et al. Standards Track [Page 6] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + It is worth noting what will happen if the LIR-pF flag is set in the + PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an + ingress node, but one or more of the egress nodes do not support the + LIR-pF flag: + + 1. The ingress node will not be able to determine the complete set + of egress nodes that are expecting a particular multicast flow + from that ingress node. + + 2. Depending upon the tunnel type, the ingress node may send a + particular multicast flow only to the egress nodes that do + support the LIR-pF flag. From the perspective of egress nodes + that do not support the LIR-pF flag, certain flows may appear to + be "blackholed". + + It is also worth noting that it is possible for an ingress node that + sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of + egress nodes that do not support this flag. + + Since an ingress node that sets the LIR-pF flag is also required to + set the LIR flag, egress nodes that do not support the LIR-pF flag + will respond, as specified in [RFC6514], to the ingress node's + (C-*,C-*) S-PMSI A-D route with a Leaf A-D route. + + As discussed in Section 5.2, any Leaf A-D route originated in + response to an S-PMSI A-D route that has the LIR-pF flag set will + carry a PTA whose LIR-pF flag is set. If an ingress node receives a + Leaf A-D route whose Route Key field corresponds to the NLRI of an + S-PMSI A-D route whose PTA has the LIR-pF flag set, but the Leaf A-D + route lacks a PTA or has a PTA where the LIR-pF flag is clear, the + ingress node can infer that the egress node originating that Leaf A-D + route does not support the LIR-pF flag. The software at the ingress + node MUST detect this and MUST have a way of alerting the operator + that the deployment is not properly configured. + +3. Match for Tracking versus Match for Reception + + Section 3.2 of [RFC6625] specifies a set of rules for finding the + S-PMSI A-D route that is the "match for data reception" (or more + simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) + state. These rules do not take into account the fact that some + S-PMSI A-D routes may not be carrying PTAs at all or may be carrying + PTAs that do not identify any P-tunnel. (A PTA that does not + identify any P-tunnel is one whose Tunnel Type field has been set to + "no tunnel information present", as specified in Section 5 of + [RFC6514].) + + + + + +Dolganow, et al. Standards Track [Page 7] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + The rules for finding a "match for reception" in [RFC6625] are hereby + modified as follows: + + When applying the rules of Sections 3.2.1 or 3.2.2 of [RFC6625], + it is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or + whose PTA specifies "no tunnel information present". + + There are other RFCs that update [RFC6625] and modify the rules for + finding a "match for reception". See, e.g., [RFC7582] and [RFC7900]. + When applying those modified rules, it is REQUIRED to ignore any + S-PMSI A-D route that has no PTA, or whose PTA specifies "no tunnel + information present". + + We also introduce a new notion, the "match for tracking": + + For a given C-flow ((C-S,C-G) or (C-*,C-G)), the "match for + tracking" is chosen as follows. Ignore any S-PMSI A-D route that + has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies + "no tunnel information present" and has neither the LIR flag nor + the LIR-pF flag set. (That is, *do not* ignore an S-PMSI A-D + route that has a PTA specifying "no tunnel information present" + unless its LIR and LIR-pF flags are both clear). Then apply the + rules (from [RFC6625] and other documents that update it) for + finding the "match for reception". The result (if any) is the + "match for tracking". + + Note that the procedure for finding the match for tracking takes + into account S-PMSI A-D routes whose PTAs specify "no tunnel + information present" and that have either the LIR or LIR-pf flag + set. The procedure for finding the match for reception ignores + such routes. + + We will clarify this with a few examples. In these examples, we + assume that there is only one segmentation domain. In this case, the + ingress and egress nodes are PE routers. + + Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" + [RFC6513] for a given flow (C-S1,C-G1). And suppose PE1 has + installed the following two routes that were originated by PE2: + + o Route1: A (C-*,C-*) S-PMSI A-D route whose PTA specifies a tunnel. + + o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no + tunnel information present" and has the LIR flag set. + + Route1 is the match of (C-S1,C-G1) for reception, and Route2 is the + match of (C-S1,C-G1) for tracking. + + + + +Dolganow, et al. Standards Track [Page 8] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + Continuing this example, suppose: + + o PE1 has chosen PE2 as the upstream PE for a different flow, + (C-S2,C-G2). + + o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). + + In this case, PE1 would consider Route1 to be the match of + (C-S2,C-G2) for tracking as well as its match for reception. + + Also note that if a match for tracking does not have the LIR flag or + the LIR-pF flag set, no explicit tracking information will be + generated. See Section 5. + + As another example, suppose PE1 has installed the following two + routes that were originated by PE2: + + o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the + PTA specifies a tunnel). + + o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a + tunnel. + + In this case, Route2 is both the "match for reception" and the "match + for tracking" for (C-S1,C-G1). + + Note that for a particular C-flow, PE1's match for reception might be + the same route as its match for tracking, or its match for reception + might be a "less specific" route than its match for tracking. But + its match for reception can never be a "more specific" route than its + match for tracking. + +4. Ingress Node Initiation of Tracking + + An ingress node that needs to initiate explicit tracking for a + particular flow or set of flows can do so by performing one of the + following procedures: + + 1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by + originating an S-PMSI A-D route that identifies (C-S1,C-G1) in + its NLRI, including a PTA in that route, and setting the LIR flag + in that PTA. The PTA may specify either a particular tunnel or + "no tunnel information present". + + However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT + specify "no tunnel information present" unless the ingress node + also originates an A-D route carrying a PTA that specifies the + tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route + + + +Dolganow, et al. Standards Track [Page 9] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + could be an "Inclusive Provider Multicast Service Interface Auto- + Discovery route" (I-PMSI A-D route), a (C-*,C-G1) S-PMSI A-D + route, a (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D + route. (There is no point in requesting explicit tracking for a + given flow if there is no tunnel on which the flow is being + carried.) + + Note that if the ingress node originates a wildcard S-PMSI A-D + route carrying a PTA specifying the tunnel to be used for + carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF flag + set, then explicit tracking for (C-S1,C-G1) is requested by that + S-PMSI A-D route. In that case, the ingress node SHOULD NOT + originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no + tunnel information present"; such a route would not provide any + additional functionality. + + To terminate explicit tracking that has been initiated by an + S-PMSI A-D route whose PTA specifies "no tunnel information + present", the ingress node withdraws the route. + + To terminate explicit tracking that has been initiated by an + S-PMSI A-D route whose PTA specifies a tunnel, the ingress node + re-originates the route without the LIR flag set. + + 2. The following procedure can be used if and only if it is known + that the egress nodes support the optional LIR-pF flag. If the + ingress node originates a wildcard S-PMSI A-D route, it can + initiate explicit tracking for the individual flows that match + the wildcard route by setting the LIR-pF flag in the PTA of the + wildcard route. If an egress node needs to receive one or more + flows for which that wildcard route is a match for tracking, the + egress node will originate a Leaf A-D route for each such flow, + as specified in Section 5.2). + + When following this procedure, the PTA of the S-PMSI A-D route + may specify either a tunnel or "no tunnel information present". + The choice between these two options is determined by + considerations that are outside the scope of this document. + + To terminate explicit tracking that has been initiated by an + S-PMSI A-D route whose PTA specifies "no tunnel information + present", the ingress node withdraws the route. + + To terminate explicit tracking that has been initiated by an + S-PMSI A-D route whose PTA specifies a tunnel, the ingress node + re-originates the route without either the LIR or LIR-pF flags + set. + + + + +Dolganow, et al. Standards Track [Page 10] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + Note that this procedure (Procedure 2 of Section 4) may not yield + the expected results if there are egress nodes that do not + support the LIR-pF flag; hence, it SHOULD NOT be used in that + case. + +5. Egress Node Response to the Match for Tracking + +5.1. General Egress Node Procedures + + There are four cases to consider: + + 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast + state, the egress node's match for tracking is the same as its + match for reception, and neither the LIR nor the LIR-pF flags are + set. + + In this case, the egress node does not originate a Leaf A-D route + in response to the match for reception/tracking, and there is no + explicit tracking of the flow. This document specifies no new + procedures for this case. + + 2. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast + state, the egress node's match for tracking is the same as its + match for reception, and the LIR flag is set, but the LIR-pF flag + is not set. + + In this case, a Leaf A-D route is originated by the egress node, + corresponding to the S-PMSI A-D route that is the match for + reception/tracking. Construction of the Leaf A-D route is as + specified in [RFC6514]; this document specifies no new procedures + for this case. + + 3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast + state, the egress node's match for tracking is the same as its + match for reception, and LIR-pF is set. The egress node follows + whatever procedures are required by other specifications, based + on the match for reception. However, any Leaf A-D route + originated by the egress node as a result MUST have the LIR-pF + flag set in its PTA. The egress node MUST also follow the + procedures of Section 5.2. + + 4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast + state, the egress node's match for tracking is *not* the same as + its match for reception. This can only happen if the match for + tracking has a PTA specifying "no tunnel information present", + with either the LIR flag or the LIR-pF flag set. In this case, + the egress node MUST respond, separately, to *both* the match for + tracking and the match for reception. + + + +Dolganow, et al. Standards Track [Page 11] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + If a Leaf A-D route is originated in response to the match for + reception, the LIR-pF flag in the Leaf A-D route's PTA MUST have + the same value as the LIR-pF flag in the match for reception's + PTA. In all other respects, the procedures for responding to the + match for reception are not affected by this document. + + If the match for tracking has the LIR flag set but the LIR-pF + flag is not set, then the behavior of the egress node is not + affected by the procedures of this document. + + If the match for tracking has the LIR-pF flag set, the egress + node MUST follow the procedures of Section 5.2. + + Note that if the LIR flag is set in the PTA of the match for + reception, the egress node may need to originate one or more Leaf + A-D routes corresponding to the match for tracking, as well as + originating a Leaf A-D route corresponding to the match for + reception. + +5.2. Responding to the LIR-pF Flag + + To respond to a match for tracking that has the LIR-pF flag set, an + egress node originates one or more Leaf A-D routes. + + Suppose the egress node has multicast state for a (C-S,C-G) or a + (C-*,C-G) flow and has determined a particular S-PMSI A-D route, + which has the LIR-pF flag set, to be the match for tracking for that + flow. Then if the egress node supports the LIR-pF flag, it MUST + originate a Leaf A-D route whose NLRI identifies that particular + flow. Note that if a single S-PMSI A-D route (with wildcards) is the + match for tracking for multiple flows, the egress node may need to + originate multiple Leaf A-D routes, one for each such flow. We say + that, from the perspective of a given egress node, a given S-PMSI A-D + route tracks the set of flows for which it is the match for tracking. + Each of the Leaf A-D routes originated in response to that S-PMSI A-D + route tracks a single such flow. + + The NLRI of each Leaf A-D route that tracks a particular flow is + constructed as follows. The Route Key field of the NLRI will have + the format shown in Figure 1 (as defined in Sections 4.3 and 4.4 of + [RFC6514]). + + + + + + + + + + +Dolganow, et al. Standards Track [Page 12] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + +------------------------------------+ + | RD (8 octets) | + +------------------------------------+ + | Multicast Source Length (1 octet) | + +------------------------------------+ + | Multicast Source (Variable) | + +------------------------------------+ + | Multicast Group Length (1 octet) | + +------------------------------------+ + | Multicast Group (Variable) | + +------------------------------------+ + | Ingress PE's IP Address | + +------------------------------------+ + + Figure 1: NLRI of S-PMSI A-D Route + + o The "ingress PE" address is taken from the Originating Router + field of the NLRI of the S-PMSI A-D route that is the match for + tracking. Section 2 of [RFC6515] explains how the receiver of a + Leaf A-D route determines the length of this field and the address + family of the PE's IP address. + + o The Multicast Source and Multicast Group fields respectively + specify a source address (S) and a group address(G) that together + identify the flow or flows being tracked by this Leaf A-D route. + If a (C-*,C-G) is being tracked by this Leaf A-D route, the + Multicast Source field is omitted, and the Multicast Source Length + field is set to 0. In this case, the Leaf A-D route is known as a + "wildcard Leaf A-D route". + + o The Route Distinguisher (RD) field is set to the value of the RD + field from the NLRI of the S-PMSI A-D route. + + The encoding of these Leaf A-D routes is similar to the encoding of + the Leaf A-D routes described in Section 6.2.2 of [RFC7524], which + were designed for the support of "global table multicast". However, + that document sets the RD to either 0 or -1; following the procedures + of the present document, the RD will never be 0 or -1. Therefore, + Leaf A-D routes constructed according to the procedures of this + section can always be distinguished from the Leaf A-D routes + constructed according to the procedures of Section 6.2.2 of + [RFC7524]. Also, Leaf A-D routes constructed according to the + procedures of this section are VPN-specific routes and will always + carry an IP-address-specific Route Target, as specified in [RFC6514]. + + + + + + + +Dolganow, et al. Standards Track [Page 13] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + If a Leaf A-D route is originated as a response to a match for + tracking whose PTA specifies "no tunnel information present", the + Leaf A-D route MUST carry a PTA that specifies "no tunnel information + present". The LIR-pF flag in this PTA MUST be set. + + If an egress node originates multiple Leaf A-D routes in response to + a single S-PMSI A-D route, and that S-PMSI A-D route is later + withdrawn, then those Leaf A-D routes MUST also be withdrawn. + + Similarly, a Leaf A-D route needs to be withdrawn (either implicitly + or explicitly) if the egress node changes its Upstream Multicast Hop + (UMH) [RFC6513] for the flow that is identified in the Leaf A-D + route's NLRI, or if the egress node that originated the route no + longer needs to receive that flow. + + It is possible that an egress node will acquire (C-S,C-G) state or + (C-*,C-G) state after it has already received the S-PMSI A-D that is + the match for tracking for that state. In this case, a Leaf A-D + route needs to be originated at that time, and the egress node must + remember that the new Leaf A-D route corresponds to that match for + tracking. + + If a particular S-PMSI A-D route is a match for tracking but not a + match for reception, the LIR flag in its PTA is ignored if the LIR-pF + flag is set. + + When the match for tracking is the same as the match for reception, + the PTA of the match for tracking/reception will have specified a + tunnel type. Some of the rules for constructing the PTA of the Leaf + A-D route depend on the tunnel type, and some are independent of the + tunnel type. No matter what the tunnel type is, the LIR-pF flag MUST + be set. + + If the match for tracking/reception is a wildcard S-PMSI A-D route, + the egress node may originate a wildcard Leaf A-D route in response, + as well as originating one or more non-wildcard Leaf A-D routes. + Note that the LIR-pF flag MUST be set in the wildcard Leaf A-D route + as well as in the non-wildcard Leaf A-D routes. + + This document provides additional rules for constructing the PTA when + the tunnel type is a 6514-tunnel-type (see Section 2). + + As discussed in Section 2, if a non-6514-tunnel-type is being used, + then presumably there is a specification for how that tunnel type is + used in MVPN. If it is desired to use that tunnel type along with + the LIR-pF flag, that specification (or a follow-on specification) + will have to specify the additional rules for constructing the PTA. + As an example, see [BIER-MVPN]. + + + +Dolganow, et al. Standards Track [Page 14] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + For 6514-tunnel-types, additional rules for constructing the PTA are + as follows: + + o If the tunnel type of the PTA attached to the match for tracking/ + reception is Ingress Replication, the Leaf A-D route's PTA MAY + specify Ingress Replication. In this case, the MPLS Label field + of the PTA MAY be a non-zero value. If so, this label value will + be used by the ingress PE when it transmits, to the egress PE, + packets of the flow identified in the Leaf A-D route's NLRI. + + Alternatively, the egress PE MAY specify an MPLS label value of + zero, or it MAY specify a tunnel type of "no tunnel information + present". In either of these cases, when the ingress PE transmits + packets of the identified flow to the egress PE, it will use the + label that the egress PE specified in the PTA of the Leaf A-D + route that it originated in response to the LIR flag of the match + for reception. + + o If the tunnel type of the PTA attached to the match for tracking/ + reception is any of the other 6514-tunnel-types, the PTA attached + to the Leaf A-D route MUST specify a tunnel type of "no tunnel + information present". + + It may happen that the tunnel type is a non-6514-tunnel type, but + either (a) there is no specification for how to use that tunnel type + with the LIR-pF flag or (b) there is such a specification, but the + egress node does not support it. In that case, the egress node MUST + treat the match for tracking/reception as if it had the LIR-pF flag + clear. + +5.3. When the Egress Node Is an ABR or ASBR + + When segmented P-tunnels are used, the ingress and egress nodes may + be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an + S-PMSI A-D route also forwards that route. If the received PTA of an + installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR + MAY change the PTA before forwarding the route, in order to specify a + different tunnel type (as discussed in [RFC6514] and/or [RFC7524]). + The egress ABR/ASBR may also need to originate a Leaf A-D route, as + specified in [RFC6514] and/or [RFC7524]. + + Suppose the S-PMSI A-D route as received has a PTA specifying a + tunnel and also has the LIR-pF flag set. The egress ABR/ASBR + originates a corresponding Leaf A-D route for a given (C-S,C-G) only + if it knows that it needs to receive that flow. It will know this by + virtue of receiving a corresponding Leaf A-D route from downstream. + (In the case where the PTA specifies a tunnel but the LIR-pF flag is + not set, this document does not specify any new procedures.) + + + +Dolganow, et al. Standards Track [Page 15] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + The procedures in the remainder of this section apply only when an + egress ABR/ASBR has installed an S-PMSI A-D route whose PTA as + received specifies "no tunnel information present" but has the LIR + flag or the LIR-pF flag set. + + If the received PTA of the installed S-PMSI A-D route specifies "no + tunnel information present", the egress ABR/ASBR MUST pass the PTA + along unchanged when it forwards the S-PMSI A-D route. (That is, a + PTA specifying "no tunnel information present" MUST NOT be changed + into a PTA specifying a tunnel.) Furthermore, if the PTA specifies + "no tunnel information present", the LIR and LIR-pF flags in the PTA + MUST be passed along unchanged. + + As a result of propagating such an S-PMSI A-D route, the egress ABR/ + ASBR may receive one or more Leaf A-D routes that correspond to that + S-PMSI A-D route. These routes will be received carrying an + IP-address-specific Route Target (RT) Extended Community that + specifies the address of the egress ABR/ASBR. The egress ABR/ASBR + will propagate these Leaf A-D routes after changing the RT as + follows. The Global Administrator field of the modified RT will be + set to the IP address taken either from the S-PMSI A-D route's + Next-Hop field [RFC6514] or its Segmented Point-to-Multipoint (P2MP) + Next-Hop Extended Community [RFC7524]. The address from the + Segmented P2MP Next-Hop Extended Community is used if that Extended + Community is present; otherwise, the address from the Next-Hop field + is used. + + This procedure enables the ingress PE to explicitly track the egress + PEs for a given flow, even if segmented tunnels are being used. + However, cross-domain explicit tracking utilizes S-PMSI A-D routes + that do not specify tunnel information; therefore, it can only be + done when the S-PMSI A-D route that is a flow's match for tracking is + different from the S-PMSI A-D route that is that flow's match for + reception. + +6. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set + + Consider the following situation: + + o An ingress node, call it N, receives a Leaf A-D route, call it L. + + o L carries an IP-address-specific RT identifying N. + + o The Route Key field of L's NLRI is not identical to the NLRI of + any current I-PMSI or S-PMSI A-D route originated by N. + + Per the procedures of [RFC6514] and [RFC7524], such a Leaf A-D route + does not cause any MVPN-specific action to be taken by N. + + + +Dolganow, et al. Standards Track [Page 16] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + + This document modifies those procedures in the case where there is a + current wildcard S-PMSI A-D route, originated by N, to which L is a + valid response according to the procedures of Section 5.2. In this + case, L MUST be processed by N. + + Suppose that L's PTA specifies a tunnel type of Ingress Replication + and that it also specifies a non-zero MPLS label. Then if N needs to + send to L a packet belonging to the multicast flow or flows + identified in L's NLRI, N MUST use the specified label. + + If L's PTA meets any of the following conditions: + + o It specifies a tunnel type of "no tunnel information present", or + + o It specifies a tunnel type of Ingress Replication, but specifies + an MPLS label of zero, or + + o It specifies any other 6514-tunnel-type, + + then the action taken by N when it receives L is a local matter. In + this case, the Leaf A-D route L provides N with explicit tracking + information for the flow identified by L's NLRI. However, that + information is for management/monitoring purposes and does not have + any direct effect on the flow of multicast traffic. + + If L's PTA specifies a non-6514-tunnel-type not mentioned above, + presumably there is a specification for how MVPN uses that tunnel + type. If the LIR-pF flag is to be used with that tunnel type, that + specification must specify the actions that N is to take upon + receiving L. As an example, see [BIER-MVPN]. In the absence of such + a specification, the LIR-pF flag SHOULD BE ignored. See Section 2 + for further discussion of non-6514-tunnel-types. + +7. IANA Considerations + + IANA has added the following entry to the "P-Multicast Service + Interface (PMSI) Tunnel Attribute Flags" registry under the "Border + Gateway Protocol (BGP) Parameters" registry. This registry is + defined in [RFC7902]. The entry appears as: + + o Value: 2 + + o Name: Leaf Information Required per-Flow (LIR-pF) + + o Reference: RFC 8534 + + + + + + +Dolganow, et al. Standards Track [Page 17] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + +8. Security Considerations + + The Security Considerations of [RFC6513] and [RFC6514] apply. + + By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a + large number of Leaf A-D routes can be elicited. If this flag is set + when not desired (through either error or malfeasance), a significant + increase in control plane overhead can result. Properly protecting + the control plane should prevent this kind of attack. + + In the event such an attack occurs, mitigating it is unfortunately + not very straightforward. The ingress node can take note of the fact + that it is getting, in response to an S-PMSI A-D route that has + LIR-pF clear, one or more Leaf A-D routes that have LIR-pF set. By + default, the reception of such a route MUST be logged. However, it + is possible for such log entries to be "false positives" that + generate a lot of "noise" in the log; therefore, implementations + SHOULD have a knob to disable this logging. + + In theory, if one or more Leaf A-D routes with LIR-pF set arrive in + response to an S-PMSI A-D route with LIR-pF clear, withdrawing the + S-PMSI A-D route could put a stop to the attack. In practice, that + is not likely to be a very good strategy, because: + + o Under normal operating conditions, there are some race conditions + that may cause the ingress node to think it is being attacked, + when in fact it is not. + + o If some egress nodes have a bug that causes them to set LIR-pF + when it should be clear, withdrawing the S-PMSI A-D route will + stop the flow of multicast data traffic to all the egress nodes, + causing an unnecessary customer-visible disruption. + + o The same situation that caused the S-PMSI A-D route to be + originated in the first place will still exist after the S-PMSI + A-D route is withdrawn, so the route will just be re-originated. + + In other words, any action that would ameliorate the effects of this + sort of attack would likely have a negative effect during normal + operation. Therefore, it is really better to rely on security + mechanisms that protect the control plane generally than to have a + mechanism that is focused on this one particular type of attack. + + + + + + + + + +Dolganow, et al. Standards Track [Page 18] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February + 2012, . + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + . + + [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure + Addresses in BGP Updates for Multicast VPN", RFC 6515, + DOI 10.17487/RFC6515, February 2012, + . + + [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and + R. Qiu, "Wildcards in Multicast VPN Auto-Discovery + Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, + . + + [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., + Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area + Point-to-Multipoint (P2MP) Segmented Label Switched Paths + (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, + . + + [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for + P-Multicast Service Interface Tunnel Attribute Flags", + RFC 7902, DOI 10.17487/RFC7902, June 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + + + + + + + + +Dolganow, et al. Standards Track [Page 19] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + +9.2. Informative References + + [BIER-MVPN] + Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and + T. Przygienda, "Multicast VPN Using BIER", Work in + Progress, draft-ietf-bier-mvpn-11, March 2018. + + [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, + "Multicast Virtual Private Network (MVPN): Using + Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, + July 2015, . + + [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., + and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", + RFC 7900, DOI 10.17487/RFC7900, June 2016, + . + +Acknowledgments + + The authors wish to thank Robert Kebler for his ideas and comments + and Stephane Litkowski and Benjamin Kaduk for their thorough reviews + and useful suggestions. We would also like to thank Mirja Kuhlewind + for her attention to the Security Considerations section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dolganow, et al. Standards Track [Page 20] + +RFC 8534 MVPN: Explicit Tracking and Wildcards February 2019 + + +Authors' Addresses + + Andrew Dolganow + Nokia + 438B Alexandra Rd #08-07/10 + Alexandra Technopark + 119968 + Singapore + + Email: andrew.dolganow@nokia.com + + + Jayant Kotalwar + Nokia + 701 East Middlefield Rd + Mountain View, California 94043 + United States of America + + Email: jayant.kotalwar@nokia.com + + + Eric C. Rosen (editor) + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, Massachusetts 01886 + United States of America + + Email: erosen52@gmail.com + + + Zhaohui Zhang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, Massachusetts 01886 + United States of America + + Email: zzhang@juniper.net + + + + + + + + + + + + + + +Dolganow, et al. Standards Track [Page 21] + -- cgit v1.2.3