draft-ietf-bess-mvpn-expl-track-03.txt   draft-ietf-bess-mvpn-expl-track-04.txt 
BESS WG A. Dolganow BESS WG A. Dolganow
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Updates: 6625 (if approved) Nokia Updates: 6625 (if approved) Nokia
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: March 26, 2018 Z. Zhang Expires: July 20, 2018 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
September 22, 2017 January 16, 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-03 draft-ietf-bess-mvpn-expl-track-04
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 26, 2018. This Internet-Draft will expire on July 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . 5
4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 7 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 7
5. Egress Node Response to the Match for Tracking . . . . . . . 8 5. Egress Node Response to the Match for Tracking . . . . . . . 9
5.1. General Egress Node Procedures . . . . . . . . . . . . . 8 5.1. General Egress Node Procedures . . . . . . . . . . . . . 9
5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 9 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 . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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). By Service Interface Auto-Discovery route" (S-PMSI A-D route).
originating one of these BGP routes, an ingress node advertises that
it is transmitting 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 Network Layer Reachability Information (NLRI) of
the S-PMSI A-D route.
Additionally, each S-PMSI A-D route contains a PMSI Tunnel attribute Per those RFCs, the S-PMSI A-D route contains a Network Layer
(PTA), which identifies a tunnel through the provider backbone Reachability Information (NLRI) field that identifies a particular
network (a "P-tunnel"). If a P-tunnel is identified in the PTA of a multicast flow. In the terminology of those RFCs, each flow is
given S-PMSI A-D route, the originator of that route is advertising denoted by (C-S,C-G), where C-S is an IP source address and C-G is an
that it will transmit the flow identified in the NLRI through the IP multicast address, both in the address space of a VPN customer.
tunnel identified in the PTA. The (C-S,C-G) of the multicast flow is encoded into the NLRI field.
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 [RFC6513] and [RFC6514] also define a procedure that allows an
ingress node to determine the set of egress nodes that have requested ingress node of particular multicast flow to determine the set of
to receive a particular flow from that ingress node. The ability of egress nodes that have requested to receive that flow from that
an ingress node to identify the egress nodes for a particular flow is ingress node. The ability of an ingress node to identify the egress
known as "explicit tracking". An ingress node requests explicit nodes for a particular flow is known as "explicit tracking". An
tracking by setting a flag (the "Leaf Information Required" flag, or ingress node requests explicit tracking by setting a flag (the "Leaf
LIR) in the PTA. When an egress node receives an S-PMSI A-D route Information Required" flag, or LIR) in the PTA. When an egress node
with LIR set, the egress node originates a Leaf A-D route whose NLRI receives an S-PMSI A-D route with LIR set, the egress node originates
contains the NLRI from the corresponding S-PMSI A-D route. In this a Leaf A-D route whose NLRI field contains the NLRI from the
way, the egress node advertises that it has requested to receive the corresponding S-PMSI A-D route. In this way, the egress node
particular flow identified in the NLRI of that S-PMSI A-D route. 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 [RFC6513] and [RFC6514] also allow an ingress node to originate an
S-PMSI A-D route whose PTA has LIR set, but which does not identify S-PMSI A-D route whose PTA has LIR set, but which does not identify
any P-tunnel. This mechanism can be used when it is desired to do any P-tunnel. This mechanism can be used when it is desired to do
explicit tracking of a flow without at the same time binding that explicit tracking of a flow without at the same time binding that
flow to a particular P-tunnel. flow to a particular P-tunnel.
[RFC6625] (and other RFCs that update it) extends the specification [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 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 wildcard in its NLRI. Either the C-S or the C-G or both can be
skipping to change at page 3, line 43 skipping to change at page 3, line 47
tracking procedures of [RFC6513] and [RFC6514] are applied when tracking procedures of [RFC6513] and [RFC6514] are applied when
wildcard S-PMSI A-D routes are used. wildcard S-PMSI A-D routes are used.
In addition, this document addresses the following scenario, which is In addition, this document addresses the following scenario, which is
not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an not addressed in [RFC6513], [RFC6514], or [RFC6625]. Suppose an
ingress node originates an S-PMSI A-D route whose NLRI specifies, for 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 example, (C-*,C-*) (i.e., both C-S and C-G are replaced by
wildcards), and whose PTA identifies a particular P-tunnel. Now wildcards), and whose PTA identifies a particular P-tunnel. Now
suppose that the ingress node wants explicit tracking for each suppose that the ingress node wants explicit tracking for each
individual flow that it transmits (following the procedures of individual flow that it transmits (following the procedures of
[RFC6625] on that P-tunnel. [RFC6625]) on that P-tunnel.
In this example, if the ingress node sets LIR in the PTA of the In this example, if the ingress node sets LIR in the PTA of the
wildcard S-PMSI A-D route, each egress node that needs to receive a 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 flow from the ingress node will respond with a Leaf A-D route whose
NLRI specifies contains the (C-*,C-*) wildcard. This allows the NLRI specifies contains the (C-*,C-*) wildcard. This allows the
ingress node to determine the set of egress nodes that are receiving ingress node to determine the set of egress nodes that are interested
flows from the ingress node. However, it does not allow the ingress in receiving flows from the ingress node. However, it does not allow
node to determine which flows are being received by which egress the ingress node to determine exactly which flows are of interest to
nodes. which egress nodes.
If the ingress node needs to determine which egress nodes are If the ingress node needs to determine which egress nodes are
receiving which flows, it needs to originate an S-PMSI A-D route for interested in receiving which flows, it needs to originate an S-PMSI
each individual (C-S,C-G) flow that it is transmitting, and it needs A-D route for each individual (C-S,C-G) flow that it is transmitting,
to set LIR in the PTA of each such route. However, since all the and it needs to set LIR in the PTA of each such route. However,
flows are being sent through the tunnel identified in the (C-*,C-*) since all the flows are being sent through the tunnel identified in
S-PMSI A-D route, there is no need to identify a tunnel in the PTA of the (C-*,C-*) S-PMSI A-D route, there is no need to identify a tunnel
each (C-S,C-G) S-PMSI A-D route. Per [RFC6514], the PTA of the in the PTA of each (C-S,C-G) S-PMSI A-D route. Per [RFC6514], the
(C-S,C-G) S-PMSI A-D routes can specify "no tunnel information". PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel
This procedure allows explicit tracking of individual flows, even information". This procedure allows explicit tracking of individual
though all those flows are assigned to tunnels in widlcard S-PMSI A-D flows, even though all those flows are assigned to tunnels in
routes. wildcard S-PMSI A-D routes.
Howver, 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 clearly state how to handle an
S-PMSI A-D route if its NLRI contains wild cards, but its PTA S-PMSI A-D route if its NLRI contains wild cards, but its PTA
specifies "no tunnel info". specifies "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.
o [RFC6513] and [RFC6514] support the notion of "segmented o [RFC6513] and [RFC6514] support the notion of "segmented
P-tunnels", where "segmentation" occurs at ASBRs; [RFC7524] P-tunnels", where "segmentation" occurs at Autonomous System
extends the notion segmented P-tunnels so that segmentation can Border Routers (ASBRs); [RFC7524] extends the notion of segmented
occur at ABRs. One can think of a segmented P-tunnel as passing P-tunnels so that segmentation can occur at Area Border Routers
through a number of "segmentation domains". In each segmentation (ABRs). One can think of a segmented P-tunnel as passing through
domain, a given P-tunnel has an ingress node and a set of egress a number of "segmentation domains". In each segmentation domain,
nodes. The explicit tracking procedures allow an ingress node of a given P-tunnel has an ingress node and a set of egress nodes.
a particular segmentation domain to determine, for a particular The explicit tracking procedures allow an ingress node of a
flow or set of flows, the egress nodes of that segmentation particular segmentation domain to determine, for a particular flow
domain. This has given rise to two further problems: 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 * The explicit tracking procedures do not allow an ingress node
to "see" past the boundaries of the segmentation domain. to "see" past the boundaries of the segmentation domain.
This particular problem is not further addressed in this * The prior specifications do not make it very clear whether a
revision of this document. segmented tunnel egress node, upon receiving an S-PMSI A-D
route whose PTA specifies "no tunnel information", is expected
to forward the S-PMSI A-D route, with the same PTA, to the next
segmentation domain.
* The prior specifications do not make it very clear whether an These problems are resolved in Section 5.3.
egress node, upon receiving an S-PMSI A-D route whose PTA
specifies "no tunnel information", is expected to forward the
S-PMSI A-D route, with the same PTA, to the next segmentation
domain. This document provides the necessary clarifications.
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", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119]. to be interpreted as described in [RFC2119].
2. The Explicit Tracking Flags 2. The Explicit Tracking Flags
Prior specifications define one flag in the PTA, the "Leaf Info [RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR)
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. (Use of this
flag in a PTA carried by other routes is outside the scope of this flag in a PTA carried by other routes is outside the scope of this
document.) Support for this flag is OPTIONAL. document.) Support for this flag is OPTIONAL.
The action taken by an egress node when the LIR-pF bit is set is The action taken by an egress node when the LIR-pF bit is set is
detailed in Section 5. detailed in Section 5.
If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
SHOULD also be set. (By setting LIR as well as LIR-pF, one forces a SHOULD also be set. (By setting LIR as well as LIR-pF, one forces a
a response to be sent an egress node that does not support LIR-pF, a response to be sent by an egress node that does not support LIR-pF,
and it is possible to tell from that response that the egress node and it is possible to tell from that response that the egress node
does not support LIR-pF.) does not support LIR-pF.)
3. Match for Tracking vs. Match for Reception 3. Match for Tracking vs. Match for Reception
RFC6625 (and other RFCs or RFCs-to-be that update RFC6625) specify a Section 3.2 of [RFC6625] specifies a set of rules for finding the
set of rules for finding the S-PMSI A-D route that is the "match for S-PMSI A-D route that is the "match for data reception" (or more
reception" for a given (C-S,C-G) or (C-*,C-G) state. These rules do simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G)
not take into account the fact that some S-PMSI A-D routes may not be state. These rules do not take into account the fact that some
carrying PTAs at all, or may be carrying PTAs that do not identify S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying
any P-tunnel. (A PTA that does not identify any P-tunnel is one PTAs that do not identify any P-tunnel. (A PTA that does not
whose "tunnel type" field has been set to "no tunnel information", as identify any P-tunnel is one whose "tunnel type" field has been set
specified in Section 5 of [RFC6514].) to "no tunnel information", as specified in Section 5 of [RFC6514].)
The definition of "match for reception" in [RFC6625] is hereby The rules for finding a "match for reception" in [RFC6625] are hereby
modified as follows: modified as follows:
When finding the "match for reception" for a given (C-S,C-G) or When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it
(C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or
PTA specifying "no tunnel information". whose PTA specifies "no tunnel information".
There are other RFCS that update [RFC6625] and that 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".
We also introduce a new notion: the "match for tracking". This We also introduce a new notion: the "match for tracking". This
differs from the "match for reception" as follows: 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. (In particular, DO NOT ignore an S-PMSI A-D route that has a set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA
PTA specifying "no tunnel information", but whose LIR or LIR-pF specifying "no tunnel information" unless its LIR and LIR-pF bits
bits are set). 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".
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:
skipping to change at page 7, line 41 skipping to change at page 7, line 51
However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT However, the PTA of the (C-S1,C-G1) S-PMSI A-D route SHOULD NOT
specify "no tunnel info" unless the ingress node also originates specify "no tunnel info" unless the ingress node also originates
an A-D route carrying a PTA that specifies the tunnel to be used an A-D route carrying a PTA that specifies the tunnel to be used
for carrying (C-S1,C-G1) traffic. Such a route could be an for carrying (C-S1,C-G1) traffic. Such a route could be an
I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) 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 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 point in requesting explicit tracking for a given flow if there
is no tunnel on which the flow is being carried.) is no tunnel on which the flow is being carried.)
Further, if the ingress node originates a wildcard S-PMSI A-D Note that if the ingress node originates a wildcard S-PMSI A-D
route carrying a PTA specifying the tunnel to be used for 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 bit carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit
set, then explicit tracking for (C-S1,C-G1) is requested by that set, then explicit tracking for (C-S1,C-G1) is requested by that
S-PMSI A-D route. Thus the ingress node SHOULD NOT originate a S-PMSI A-D route. In that case, the ingress node SHOULD NOT
(C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no
info"; such a route would not provide any additional tunnel info"; such a route would not provide any additional
functionality. functionality.
To terminate explicit tracking that has been initiated by an To terminate explicit tracking that has been initiated by an
S-PMSI A-D route whose PTA specifies "no tunnel info", the S-PMSI A-D route whose PTA specifies "no tunnel info", the
ingress node withdraws the route. ingress node withdraws the route.
To terminate explicit tracking that has been initiated by an To terminate explicit tracking that has been initiated by an
S-PMSI A-D route whose PTA specifies a tunnel, the ingress node S-PMSI A-D route whose PTA specifies a tunnel, the ingress node
re-originates the route without the LIR flag set. re-originates the route without the LIR flag set.
2. The following procedure can be used if (and only if) it is known 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 that the egress nodes support the optional LIR-pF flag. If the
ingress node originates a wildcard S-PMSI A-D route, it can ingress node originates a wildcard S-PMSI A-D route, it can
initiate explicit tracking for the individual flows that match initiate explicit tracking for the individual flows that match
the wildcard route by setting the LIR-pF flag in the PTA of the 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 wildcard route. If an egress node needs to receive one or more
flows for which that wildcard route is a match for tracking, the 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, egress node will originate a Leaf A-D route for each such flow,
as specified in Section 5.2). as specified in Section 5.2).
When following this procedure, the PTA of the S-PMSI A-D route When following this procedure, the PTA of the S-PMSI A-D route
may specify a tunnel, or may specify "no tunnel info". The may specify a tunnel, or may specify "no tunnel info". The
choice between these two options is determined by considerations choice between these two options is determined by considerations
that are outside the scope of this document. that are outside the scope of this document.
To terminate explicit tracking that has been initiated by an To terminate explicit tracking that has been initiated by an
S-PMSI A-D route whose PTA specifies "no tunnel info", the S-PMSI A-D route whose PTA specifies "no tunnel info", the
ingress node withdraws the route. ingress node withdraws the route.
To terminate explicit tracking that has been initiated by an To terminate explicit tracking that has been initiated by an
S-PMSI A-D route whose PTA specifies a tunnel, the ingress node S-PMSI A-D route whose PTA specifies a tunnel, the ingress node
re-originates the route without the LIR flag set re-originates the route without either the LIR or LIR-pF flags
set.
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, and hence SHOULD NOT be used in that
case.
5. Egress Node Response to the Match for Tracking 5. Egress Node Response to the Match for Tracking
5.1. General Egress Node Procedures 5.1. General Egress Node Procedures
There are four cases to consider: There are four cases to consider:
1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 1. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast
state, the egress node's match for tracking is same as its match state, the egress node's match for tracking is same as its match
for reception, and neither LIR nor LIR-pF flags are on. for reception, and neither LIR nor LIR-pF flags are on.
skipping to change at page 9, line 10 skipping to change at page 9, line 32
match for reception, LIR is set, but LIR-pF is not set. match for reception, LIR is set, but LIR-pF is not set.
In this case, a Leaf A-D route is originated by the egress node, 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 corresponding to the S-PMSI A-D route that is the match for
reception/tracking. Construction of the Leaf A-D route is as reception/tracking. Construction of the Leaf A-D route is as
specified in [RFC6514]; this document specifies no new procedures specified in [RFC6514]; this document specifies no new procedures
for this case. for this case.
3. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 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 state, the egress node's match for tracking is the same as its
match for reception, and LIR-pF is set. The egress PE MUST match for reception, and LIR-pF is set. The egress node MUST
follow whatever procedures are required by other specifications, follow whatever procedures are required by other specifications,
based on the match for reception. If the egress PE supports the based on the match for reception. If the egress node supports
LIR-pF flag, it MUST also follow the procedures of Section 5.2. the LIR-pF flag, it MUST also follow the procedures of
Section 5.2.
4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 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 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 its match for reception. This can only happen if the match for
tracking has a PTA specifying "no tunnel info", with either LIR tracking has a PTA specifying "no tunnel info", with either LIR
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
skipping to change at page 10, line 5 skipping to change at page 10, line 27
To respond to a match for tracking that has LIR-pF set, an egress To respond to a match for tracking that has LIR-pF set, an egress
node originates one or more Leaf A-D routes. node originates one or more Leaf A-D routes.
Suppose the egress node has multicast state for a (C-S,C-G) or a 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, (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 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 flow. Then if the egress node supports the LIR-pF flag, it MUST
originate a Leaf A-D route whose NLRI identifies that particular originate a Leaf A-D route whose NLRI identifies that particular
flow. Note that if a single S-PMSI A-D route (with wild cards) is flow. Note that if a single S-PMSI A-D route (with wild cards) is
the match for tracking for multiple flows, the egress PE may need to the match for tracking for multiple flows, the egress node may need
originate multiple Leaf A-D routes, one for each such flow. We say to originate multiple Leaf A-D routes, one for each such flow. We
that, from the perspective of a given egress node, a given S-PMSI A-D say that, from the perspective of a given egress node, a given S-PMSI
route tracks the set of flows for which it is the match for tracking. A-D route tracks the set of flows for which it is the match for
Each of the Leaf A-D routes originated in response to that S-PMSI A-D tracking. Each of the Leaf A-D routes originated in response to that
route tracks a single such flow. S-PMSI A-D route tracks a single such flow.
The NLRI of each the Leaf A-D route that tracks a particular flow is The NLRI of each the Leaf A-D route that tracks a particular flow is
constructed as follows. The "route key" field of the NLRI will have constructed as follows. The "route key" field of the NLRI will have
the following format: the following format:
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source Length (1 octet) | | Multicast Source Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 10, line 41 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 RD field is constructed as follows: o The Route Distinguisher (RD) field is constructed as follows:
* Take the RD value from the NLRI of the S-PMSI A-D route. * Take the RD value from the NLRI of the S-PMSI A-D route.
* Add 16 to the second octet of the RD. * 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.)
Note that, per RFC4364, every RD begins with a two-octet type field The presence of one of these values will indicate that the Leaf
that is either 0, 1, or 2. By adding 16 to the second octet of the A-D route was constructed in response to a less specific S-PMSI
RD, we force the type field to be 16, 17, or 18. The presence of one A-D route that had the LIR-pF bit set. (That is, it
of these values will indicate that the Leaf A-D route was constructed distinguishes the routes from "ordinary" MVPN Leaf A-D routes.)
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
skipping to change at page 12, line 27 skipping to change at page 13, line 14
MAY change the PTA to specify a different tunnel type (as discussed MAY change the PTA to specify a different tunnel type (as discussed
in [RFC6514] and/or [RFC7524]). in [RFC6514] and/or [RFC7524]).
However, if the PTA of the installed S-PMSI A-D route specifies "no However, 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 tunnel 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 when it 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.) "no 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 LIR-
pF flags in the PTA MUST be passed along unchanged. pF flags in the PTA MUST be passed along unchanged.
In the case where the egress node is a PE, it will know whether it In the case where the egress node of a given P-tunnel is a PE, it
needs to receive a given flow by virtue of its having received a PIM will know whether it needs to receive a given flow by virtue of its
or IGMP Join for that flow from a CE. In the case where the egress having received a PIM or IGMP Join for that flow from a Customer Edge
node is not a PE, but rather an ABR or ASBR, it will not know whether (CE) router. In the case where the egress node is not a PE, but
it needs to receive a given flow unless it receives a Leaf A-D route rather an ABR or ASBR, it will not know whether it needs to receive a
whose NLRI specifies that flow and whose IP-address-specific RT given flow unless it receives a Leaf A-D route whose NLRI specifies
specifies an address of the egress node. Therefore an egress ABR/ that flow, and which carries an IP-address-specific Route Target (RT)
ASBR MUST NOT originate a Leaf A-D route for a given flow UNLESS it Extended Community that specifies the address of the egress ABR/ASBR.
has an installed Leaf A-D route for that flow, received from further Therefore an egress ABR/ASBR MUST NOT originate a Leaf A-D route for
downstream. a given flow UNLESS it has an installed Leaf A-D route for that flow,
received from further downstream.
This will ensure that an egress ABR/ASBR only sends a Leaf A-D route This will ensure that an egress ABR/ASBR only sends a Leaf A-D route
in response to a "match for tracking" if it is on the path to an in response to a "match for tracking" if it is on the path to an
egress PE for the flow(s) identified in the corresponding S-PMSI A-D egress PE for the flow(s) identified in the corresponding S-PMSI A-D
route. route.
Then we can establish the following rule for egress ABRs/ASBRs. We can thus establish the following rule for egress ABRs/ASBRs.
Suppose an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is Suppose an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is
X, and whose PTA (a) specifies "no tunnel info" and (b) has LIR set. X, and whose PTA (a) specifies "no tunnel info" and (b) has LIR set.
The egress ABR/ASBR should not immediately originate a Leaf A-D route The egress ABR/ASBR should not immediately originate a Leaf A-D route
in response. Rather it should wait until it receives a Leaf A-D in response. Rather it should wait until it receives a Leaf A-D
route whose NLRI contains X in the "route key" field. If it receives route whose NLRI contains X in the "route key" field. If it receives
such a Leaf A-D route, it redistributes that route, but first it such a Leaf A-D route, it redistributes that route, but first it
changes that route's RT. The "global administrator" field of the changes that route's RT. The "global administrator" field of the
modified RT will be set to the IP address taken either from the modified RT will be set to the IP address taken either from the
S-PMSI A-D route's next hop field, or from its Segmented P2MP Next S-PMSI A-D route's next hop field, or from its Segmented P2MP Next
Hop Extended Community. (This is the same rule that is used for when Hop Extended Community. (This is the same rule that is used for when
skipping to change at page 13, line 23 skipping to change at page 14, line 16
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 IANA is requested to allocate three new types from the Route
Distinguisher Type Field registry: Distinguisher Type Field registry:
o Administrator field is two-byte Autonomous System Number. To be o TBD1: Administrator field is two-byte Autonomous System Number.
used only in certain MCAST-VPN Leaf A-D routes. To be used only in certain MCAST-VPN Leaf A-D routes.
o Administrator field is four-byte IP Address. To be used only in o TBD2: Administrator field is four-byte IP Address. To be used
certain MCAST-VPN Leaf A-D routes. only in certain MCAST-VPN Leaf A-D routes.
o Administrator field is four-byte Autonomous System Number. To be o TBD3: Administrator field is four-byte Autonomous System Number.
used only in certain MCAST-VPN Leaf A-D routes. To be used only in certain MCAST-VPN Leaf A-D routes.
The requested values are 16, 17, and 18 respectively. The requested values are 16, 17, and 18 respectively.
8. Security Considerations 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
skipping to change at page 14, line 5 skipping to change at page 14, line 45
9. References 9. References
9.1. Normative References 9.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.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<https://www.rfc-editor.org/info/rfc6625>. <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 [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 9.2. Informative References
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area "Multicast Virtual Private Network (MVPN): Using
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, July 2015, <https://www.rfc-editor.org/info/rfc7582>.
<https://www.rfc-editor.org/info/rfc7524>.
[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>.
Authors' Addresses Authors' Addresses
Andrew Dolganow Andrew Dolganow
Nokia Nokia
438B Alexandra Rd #08-07/10 438B Alexandra Rd #08-07/10
Alexandra Technopark Alexandra Technopark
Singapore 119968 Singapore 119968
Singapore
Email: andrew.dolganow@nokia.com Email: andrew.dolganow@nokia.com
Jayant Kotalwar Jayant Kotalwar
Nokia Nokia
701 East Middlefield Rd 701 East Middlefield Rd
Mountain View, California 94043 Mountain View, California 94043
United States United States of America
Email: jayant.kotalwar@nokia.com Email: jayant.kotalwar@nokia.com
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States of America
Email: erosen@juniper.net Email: erosen@juniper.net
Zhaohui Zhang Zhaohui Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States United States of America
Email: zzhang@juniper.net Email: zzhang@juniper.net
 End of changes. 47 change blocks. 
138 lines changed or deleted 171 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/