draft-ietf-bess-mvpn-expl-track-06.txt   draft-ietf-bess-mvpn-expl-track-07.txt 
BESS WG A. Dolganow BESS WG A. Dolganow
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Updates: 6625 (if approved) Nokia Updates: 6514 6625 7524 (if approved) Nokia
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: August 4, 2018 Z. Zhang Expires: August 24, 2018 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
January 31, 2018 February 20, 2018
Explicit Tracking with Wild Card Routes in Multicast VPN Explicit Tracking with Wild Card Routes in Multicast VPN
draft-ietf-bess-mvpn-expl-track-06 draft-ietf-bess-mvpn-expl-track-07
Abstract Abstract
The MVPN specifications provide procedures to allow a multicast The MVPN specifications provide procedures to allow a multicast
ingress node to invoke "explicit tracking" for a multicast flow or 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 set of flows, thus learning the egress nodes for that flow or set of
flows. However, the specifications are not completely clear about flows. However, the specifications are not completely clear about
how the explicit tracking procedures work in certain scenarios. This how the explicit tracking procedures work in certain scenarios. This
document provides the necessary clarifications. It also specifies a document provides the necessary clarifications. It also specifies a
new, optimized explicit tracking procedure. This new procedure new, optimized explicit tracking procedure. This new procedure
allows an ingress node, by sending a single message, to request 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 explicit tracking of each of a set of flows, where the set of flows
is specified using a wildcard mechanism. This document updates is specified using a wildcard mechanism. This document updates RFCs
RFC6625. 6514, 6625, and 7524.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2018. This Internet-Draft will expire on August 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Explicit Tracking Flags . . . . . . . . . . . . . . . . . 5 2. The Explicit Tracking Flags . . . . . . . . . . . . . . . . . 5
3. Match for Tracking vs. Match for Reception . . . . . . . . . 5 3. Match for Tracking vs. Match for Reception . . . . . . . . . 6
4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 7 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 7
5. Egress Node Response to the Match for Tracking . . . . . . . 9 5. Egress Node Response to the Match for Tracking . . . . . . . 9
5.1. General Egress Node Procedures . . . . . . . . . . . . . 9 5.1. General Egress Node Procedures . . . . . . . . . . . . . 9
5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 10 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 10
5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 12 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. Ingress Node Handling of Received Leaf A-D Routes with
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
[RFC6513] and [RFC6514] define the "Selective Provider Multicast [RFC6513] and [RFC6514] define the "Selective Provider Multicast
Service Interface Auto-Discovery route" (S-PMSI A-D route). Service Interface Auto-Discovery route" (S-PMSI A-D route).
Per those RFCs, the S-PMSI A-D route contains a Network Layer Per those RFCs, the S-PMSI A-D route contains a Network Layer
Reachability Information (NLRI) field that identifies a particular Reachability Information (NLRI) field that identifies a particular
multicast flow. In the terminology of those RFCs, each flow is 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 denoted by (C-S,C-G), where C-S is an IP source address and C-G is an
skipping to change at page 4, line 23 skipping to change at page 4, line 23
since all the flows are being sent through the tunnel identified in 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 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 [RFC6514], the in the PTA of each (C-S,C-G) S-PMSI A-D route. Per [RFC6514], the
PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel
information". This procedure allows explicit tracking of individual information". This procedure allows explicit tracking of individual
flows, even though all those flows are assigned to tunnels in flows, even though all those flows are assigned to tunnels in
wildcard S-PMSI A-D routes. wildcard S-PMSI A-D routes.
However, this procedure requires several clarifications: However, this procedure requires several clarifications:
o The procedures of [RFC6625] do not clearly state how to handle an o The procedures of [RFC6625] do not address the case of an S-PMSI
S-PMSI A-D route if its NLRI contains wild cards, but its PTA A-D route whose NLRI contains wild cards, but whose PTA specifies
specifies "no tunnel info". "no tunnel info".
o If it is desired to send a set of flows through the same tunnel 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), (where that tunnel is advertised in a wildcard S-PMSI A-D route),
but it is also desired to explicitly track each individual flow 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 transmitted over that tunnel, one has to send an S-PMSI A-D route
(with LIR set in the PTA) for each individual flow. It would be (with LIR set in the PTA) for each individual flow. It would be
more optimal if the ingress node could just send a single wildcard 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, 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 and have the egress nodes respond with Leaf A-D routes for each
individual flow. individual flow.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
* The prior specifications do not make it very clear whether a * The prior specifications do not make it very clear whether a
segmented tunnel egress node, upon receiving an S-PMSI A-D segmented tunnel egress node, upon receiving an S-PMSI A-D
route whose PTA specifies "no tunnel information", is expected route whose PTA specifies "no tunnel information", is expected
to forward the S-PMSI A-D route, with the same PTA, to the next to forward the S-PMSI A-D route, with the same PTA, to the next
segmentation domain. segmentation domain.
These problems are addressed in Section 5.3. These problems are addressed in Section 5.3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are "OPTIONAL" in this document are to be interpreted as described in BCP
to be interpreted as described in [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. The Explicit Tracking Flags 2. The Explicit Tracking Flags
[RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR) [RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR)
flag, that is used for explicit tracking. flag, that is used for explicit tracking.
This document defines a new flag in the flags field of the PMSI This document defines a new flag in the flags field of the PMSI
Tunnel attribute. This new flag is known as the "Leaf Info Required Tunnel attribute. This new flag is known as the "Leaf Info Required
per Flow" bit (LIR-pF). This flag MAY be set in the PTA of a per Flow" bit (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. (Use of this (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The conditions
flag in a PTA carried by other routes is outside the scope of this under which it should be set by the originator of the route are
document.) Support for this flag is OPTIONAL. discussed in Section 4. The significance of the flag in a received
S-PMSI A-D route is discussed in Sections 5 and 5.2. Note that
support for this flag is OPTIONAL. This flag SHOULD NOT be set
unless it is known that all the PEs that are to receive the route
carrying the PTA support the flag. How this is known is outside the
scope of this document.
The action taken by an egress node when the LIR-pF bit is set is The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The
detailed in Section 5. 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.
If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA Use of this flag in the PTA carried by other route types is outside
SHOULD also be set. (By setting LIR as well as LIR-pF, one forces a the scope of this document. Use of this flag in the PTA carried by
a response to be sent by an egress node that does not support LIR-pF, an S-PMSI A-D routes whose NLRI does not contain a wildcard is
and it is possible to tell from that response that the egress node outside the scope of this document.
does not support LIR-pF.)
If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
flag of that PTA MUST also be set. (By setting LIR as well as
LIR-pF, one forces a response to be sent by an egress node that does
not support LIR-pF. It is possible to tell from that response that
the egress node does not support LIR-pF. This may be an aid to
troubleshooting.)
3. Match for Tracking vs. Match for Reception 3. Match for Tracking vs. Match for Reception
Section 3.2 of [RFC6625] specifies a set of rules for finding the 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 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) 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 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 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 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 identify any P-tunnel is one whose "tunnel type" field has been set
to "no tunnel information", as specified in Section 5 of [RFC6514].) to "no tunnel information", as specified in Section 5 of [RFC6514].)
The rules for finding a "match for reception" in [RFC6625] are hereby The rules for finding a "match for reception" in [RFC6625] are hereby
modified as follows: modified as follows:
When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it When applying the rules of Section 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 is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or
whose PTA specifies "no tunnel information". whose PTA specifies "no tunnel information".
There are other RFCS that update [RFC6625] and that modify the rules There are other RFCs that update [RFC6625] and that modify the rules
for finding a "match for reception". See, e.g., [RFC7582] and for finding a "match for reception". See, e.g., [RFC7582] and
[RFC7900]. When applying those modified rules, it is REQUIRED to [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 ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies
"no tunnel information". "no tunnel information".
We also introduce a new notion: the "match for tracking". This We also introduce a new notion, the "match for tracking":
differs from the "match for reception" as follows:
For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for 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 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 has no PTA. Also ignore any S-PMSI A-D route whose PTA specifies
"no tunnel information", but does not have either LIR or LIR-pF "no tunnel information", but does not have either LIR or LIR-pF
set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA
specifying "no tunnel information" unless its LIR and LIR-pF bits specifying "no tunnel information" unless its LIR and LIR-pF bits
are both clear). Then apply the rules (from [RFC6625] and other are both clear). Then apply the rules (from [RFC6625] and other
documents that that update it) for finding the "match for documents that that update it) for finding the "match for
reception". The result (if any) is the match for tracking". 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" and that have either LIR or LIR-pf set. The
procedure for finding the match for reception ignores such routes.
We will clarify this with a few examples. In these examples, we We will clarify this with a few examples. In these examples, we
assume that there is only one segmentation domain. In this case, the assume that there is only one segmentation domain. In this case, the
ingress and egress nodes are Provider Edge (PE) routers. ingress and egress nodes are Provider Edge (PE) routers.
Suppose a given PE router, PE1, has chosen PE2 as the "upstream PE" 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 ([RFC6513]) for a given flow (C-S1,C-G1). And suppose PE1 has
installed the following two routes that were originated by PE2: installed the following two routes that were originated by PE2:
o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a
tunnel. tunnel.
skipping to change at page 9, line 52 skipping to change at page 10, line 19
or LIR-pF set. In this case, the egress node must respond, or LIR-pF set. In this case, the egress node must respond,
separately, BOTH to the match for tracking and to the match for separately, BOTH to the match for tracking and to the match for
reception. reception.
When responding to the match for reception, the egress node MUST When responding to the match for reception, the egress node MUST
ignore the LIR-pF flag. However, the LIR flag is processed ignore the LIR-pF flag. However, the LIR flag is processed
normally per the procedures for the match for reception. normally per the procedures for the match for reception.
If the match for tracking has LIR set and if either (a) the If the match for tracking has LIR set and if either (a) the
egress node does not support LIR-pF, or (b) LIR-pF is not set, egress node does not support LIR-pF, or (b) LIR-pF is not set,
then the egress node must respond to the match for tracking, then the behavior of the egress node is not affected by the
following procedures specified in other documents for the case procedures of this document.
where LIR is set.
If the match for tracking has LIR-pF set, and the egress node If the match for tracking has LIR-pF set, and the egress node
supports the LIR-pF flag, the egress node must originate one or supports the LIR-pF flag, the egress node must originate one or
more Leaf A-D routes, as specified in Section 5.2. more Leaf A-D routes, as specified in Section 5.2.
Note that if LIR is set in the PTA of the match for reception, Note that if LIR is set in the PTA of the match for reception,
the egress node may need to originate one or more Leaf A-D routes 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 corresponding to the match for tracking, as well as originating a
Leaf A-D route corresponding to the match for reception. Leaf A-D route corresponding to the match for reception.
skipping to change at page 11, line 30 skipping to change at page 11, line 30
o The "ingress PE" address is taken from the "originating router" 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 field of the NLRI of the S-PMSI A-D route that is the match for
tracking. tracking.
o The multicast source and group fields specify the S and G of one o The multicast source and group fields specify the S and G of one
of the flow being tracked by this Leaf A-D route. If a (C-*,C-G) of the flow being tracked by this Leaf A-D route. If a (C-*,C-G)
is being tracked by this Leaf A-D route, the source field is is being tracked by this Leaf A-D route, the source field is
omitted, and its length is set to 0. omitted, and its length is set to 0.
o The Route Distinguisher (RD) field is constructed as follows: 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.
* Take the RD value from the NLRI of the S-PMSI A-D route.
* Per [RFC4364], every RD begins with a two-octet type field that
is either 0, 1, or 2. Change the value of this two-octet type
field to TBD1, TBD2, or TBD3, respectively. (See Section 7,
IANA Considerations.)
The presence of one of these values will indicate that the Leaf
A-D route was constructed in response to a less specific S-PMSI
A-D route that had the LIR-pF bit set. (That is, it
distinguishes the routes from "ordinary" MVPN Leaf A-D routes.)
The encoding of these Leaf A-D routes is similar to the encoding of 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 the Leaf A-D routes described in section 6.2.2 of [RFC7524], which
were designed for the support of "global table multicast". However, were designed for the support of "global table multicast". However,
that document sets the RD to either 0 or -1; following the procedures that document sets the RD to either 0 or -1; following the procedures
of this document, the RD will never be 0 or -1. Therefore Leaf A-D of this document, the RD will never be 0 or -1. Therefore Leaf A-D
routes constructed according to the procedures of this section can routes constructed according to the procedures of this section can
always be distinguished from the Leaf A-D routes constructed always be distinguished from the Leaf A-D routes constructed
according to the procedures of section 6.2.2 of [RFC7524]. Also, according to the procedures of section 6.2.2 of [RFC7524]. Also,
Leaf A-D routes constructed according to the procedures of this Leaf A-D routes constructed according to the procedures of this
section are VPN-specific routes, and will always carry an IP-address- section are VPN-specific routes, and will always carry an IP-address-
specific Route Target, as specified in [RFC6514]. specific Route Target, as specified in [RFC6514].
If a Leaf A-D route is originated as a response to a match for If a Leaf A-D route is originated as a response to a match for
tracking whose PTA specifies "no tunnel info", a PTA SHOULD NOT be tracking whose PTA specifies "no tunnel info", the Leaf A-D route
attached to the Leaf A-D route; if a PTA is attached, it MUST specify MUST carry a PTA that specifies "no tunnel info". The LIR-pF flag in
"no tunnel info". this PTA MUST be set.
In the case where the match for tracking and the match for reception In the case where the match for tracking and the match for reception
are the same, the PTA of the match may have both the LIR and the LIR- are the same, the PTA of the match may have both the LIR and the
pF flags set. This may cause the egress node to originate one Leaf LIR-pF flags set. This may cause the egress node to originate one
A-D route in response to the LIR bit, and one or more Leaf A-D routes Leaf A-D route in response to the LIR bit, and one or more Leaf A-D
in response to the LIR-pF bit. A PTA SHOULD NOT be attached to the routes in response to the LIR-pF bit. A Leaf A-D route originated in
Leaf A-D routes that are originated in response to the LIR-pF bit. response to the LIR-pF bit MUST have a PTA. The LIR-pF flag of that
PTA MUST be set. In this case, the PTA of the match for tracking/
reception will have specified a tunnel type. The following rules
specify how the PTA of the Leaf A-D route is to be constructed:
When a Leaf A-D route constructed according to the procedures of this o If the tunnel type of the PTA attached to the match for tracking/
section is received, it MUST be processed by the node identified in reception is Ingress Replication, the Leaf A-D route's PTA MAY
its IP-address-specific Route Target, even though its "route key" specify Ingress Replication. In this case, the MPLS Label field
field does not correspond to the NLRI of any S-PMSI A-D route. 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 info". 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 bit 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 tunnel types listed in [RFC6514]
Section 5, the PTA attached to the Leaf A-D route MUST specify a
tunnel type of "no tunnel info".
o When additional tunnel types are defined, the specification for
how MVPN is to use those tunnel types must also specify how to
construct the PTA of a Leaf A-D route that is originated in
response to the LIR-pF flag. As an example, see [BIER-MVPN].
Of course, an egress node that originates such Leaf A-D routes needs Of course, an egress node that originates such Leaf A-D routes needs
to remember which S-PMSI A-D route caused these Leaf A-D routes to be to remember which S-PMSI A-D route caused these Leaf A-D routes to be
originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D originated; if that S-PMSI A-D route is withdrawn, those Leaf A-D
routes MUST be withdrawn. routes MUST be withdrawn.
Similarly, a Leaf A-D route needs to be withdrawn (either implicitly Similarly, a Leaf A-D route needs to be withdrawn (either implicitly
or explicitly) if the egress node changes its Upstream Multicast Hop or explicitly) if the egress node changes its Upstream Multicast Hop
(UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D (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 route's NLRI, or if the egress node that originated the route no
skipping to change at page 13, line 25 skipping to change at page 13, line 36
document does not specify any new procedures.) document does not specify any new procedures.)
The procedures in the remainder of this section apply only when an 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 specifies egress ABR/ASBR has installed an S-PMSI A-D route whose PTA specifies
"no tunnel info" but has LIR or LIR-pF set. "no tunnel info" but has LIR or LIR-pF set.
If the PTA of the installed S-PMSI A-D route specifies "no tunnel If the PTA of the installed S-PMSI A-D route specifies "no tunnel
info", the egress ABR/ASBR MUST pass the PTA along unchanged when it info", 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 forwards the S-PMSI A-D route. (That is, a PTA specifying "no tunnel
info" MUST NOT be changed into a PTA specifying a tunnel.) info" MUST NOT be changed into a PTA specifying a tunnel.)
Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR- Furthermore, if the PTA specifies "no tunnel info", the LIR and
pF flags in the PTA MUST be passed along unchanged. 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/ 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 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- S-PMSI A-D route. These routes will be received carrying an IP-
address-specific Route Target (RT) Extended Community that specifies address-specific Route Target (RT) Extended Community that specifies
the address of the egress ABR/ASBR. The egress ABR/ASBR will the address of the egress ABR/ASBR. The egress ABR/ASBR will
propagate these Leaf A-D routes, after changing the RT as follows. 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 "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 the IP address taken either from the S-PMSI A-D route's next hop
field ([RFC6514]), or from its Segmented P2MP Next Hop Extended field ([RFC6514]), or from its Segmented P2MP Next Hop Extended
Community ([RFC7524]). Community ([RFC7524]).
This procedure enables the ingress PE to explicitly track the egress This procedure enables the ingress PE to explicitly track the egress
PEs for a given flow, even if segmented tunnels are being used. PEs for a given flow, even if segmented tunnels are being used.
However, cross-domain explicit tracking utilizes S-PMSI A-D routes However, cross-domain explicit tracking utilizes S-PMSI A-D routes
that do not specify tunnel information; therefore it can only be done that do not specify tunnel information; therefore it can only be done
when the S-PMSI A-D route which is a flow's match for tracking is when the S-PMSI A-D route which is a flow's match for tracking is
different than the S-PMSI A-D route which is that flow's match for different than the S-PMSI A-D route which is that flow's match for
reception. reception.
6. Acknowledgments 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.
This document modifies those procedures in the case where there is a
current S-PMSI A-D route with a wildcard NLRI, 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", or
o It specifies a tunnel type of Ingress Replication, but specifies
an MPLS label of zero, or
o It specifies another of the tunnel types listed in Section 5 of
[RFC6514],
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
an effect on the flow of multicast traffic.
If L's PTA specifies a tunnel type not mentioned above, the
specification for how MVPN uses that tunnel type must specify the
actions that N is to take upon receiving L. As an example, see
[BIER-MVPN].
7. Acknowledgments
The authors wish to thank Robert Kebler for his ideas and comments. The authors wish to thank Robert Kebler for his ideas and comments.
We also thank Stephane Litkowski for his thorough review and useful
suggestions.
7. IANA Considerations 8. IANA Considerations
The LIR-pF flag needs to be added to the "P-Multicast Service The LIR-pF flag needs to be added to the "P-Multicast Service
Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border
Gateway Protocol (BGP) Parameters" registry. This registry is Gateway Protocol (BGP) Parameters" registry. This registry is
defined in [RFC7902]. The requested value is Bit Position 2. This defined in [RFC7902]. The requested value is Bit Position 2. This
document should be the reference. document should be the reference.
IANA is requested to allocate three new types from the Route 9. Security Considerations
Distinguisher Type Field registry:
o TBD1: Administrator field is two-byte Autonomous System Number.
To be used only in certain MCAST-VPN Leaf A-D routes.
o TBD2: Administrator field is four-byte IP Address. To be used
only in certain MCAST-VPN Leaf A-D routes.
o TBD3: Administrator field is four-byte Autonomous System Number.
To be used only in certain MCAST-VPN Leaf A-D routes.
The requested values are 16, 17, and 18 respectively.
8. Security Considerations
The Security Considerations of [RFC6513] and [RFC6514] apply. The Security Considerations of [RFC6513] and [RFC6514] apply.
By setting the LIR-pF flag in a single wildcard S-PMSI A-D route, a 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 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 when not desired (through either error or malfeasance), a significant
increase in control plane overhead can result. increase in control plane overhead can result. The specification of
counter-measures for this problem is outside the scope of this
document.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
skipping to change at page 15, line 26 skipping to change at page 16, line 21
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags", P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016, RFC 7902, DOI 10.17487/RFC7902, June 2016,
<https://www.rfc-editor.org/info/rfc7902>. <https://www.rfc-editor.org/info/rfc7902>.
9.2. Informative References [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>.
10.2. Informative References
[BIER-MVPN]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", internet-draft
draft-ietf-bier-mvpn-09, November 2017.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using "Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <https://www.rfc-editor.org/info/rfc7582>. July 2015, <https://www.rfc-editor.org/info/rfc7582>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
RFC 7900, DOI 10.17487/RFC7900, June 2016, RFC 7900, DOI 10.17487/RFC7900, June 2016,
<https://www.rfc-editor.org/info/rfc7900>. <https://www.rfc-editor.org/info/rfc7900>.
 End of changes. 31 change blocks. 
90 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/