summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8534.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8534.txt')
-rw-r--r--doc/rfc/rfc8534.txt1179
1 files changed, 1179 insertions, 0 deletions
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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
+ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
+ 2012, <https://www.rfc-editor.org/info/rfc6513>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc6514>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc6515>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc6625>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc7524>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc7902>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+
+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, <https://www.rfc-editor.org/info/rfc7582>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc7900>.
+
+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]
+