GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8534

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8534.txt · Last modified: 2019/02/20 06:52 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki