draft-ietf-bess-mvpn-expl-track-09.txt   draft-ietf-bess-mvpn-expl-track-10.txt 
BESS WG A. Dolganow BESS WG A. Dolganow
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Updates: 6514 6625 7524 (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: October 21, 2018 Z. Zhang Expires: March 29, 2019 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
April 19, 2018 September 25, 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-09 draft-ietf-bess-mvpn-expl-track-10
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 October 21, 2018. This Internet-Draft will expire on March 29, 2019.
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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
in receiving flows from the ingress node. However, it does not allow in receiving flows from the ingress node. However, it does not allow
the ingress node to determine exactly which flows are of interest to the ingress node to determine exactly which flows are of interest to
which egress 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
interested in receiving which flows, it needs to originate an S-PMSI 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, A-D route for each individual (C-S,C-G) flow that it is transmitting,
and it needs to set LIR in the PTA of each such route. However, and it needs to set LIR in the PTA of each such route. However,
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 Section 5 of
PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no tunnel [RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no
information". This procedure allows explicit tracking of individual tunnel information present". This procedure allows explicit tracking
flows, even though all those flows are assigned to tunnels in of individual flows, even though all those flows are assigned to
wildcard S-PMSI A-D routes. tunnels in 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 address the case of an S-PMSI o The procedures of [RFC6625] do not address the case of an S-PMSI
A-D route whose NLRI contains wild cards, but whose PTA specifies A-D route whose NLRI contains wild cards, but whose PTA specifies
"no tunnel info". "no tunnel information present".
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 7 skipping to change at page 5, line 7
The explicit tracking procedures allow an ingress node of a The explicit tracking procedures allow an ingress node of a
particular segmentation domain to determine, for a particular flow particular segmentation domain to determine, for a particular flow
or set of flows, the egress nodes of that segmentation domain. or set of flows, the egress nodes of that segmentation domain.
This has given rise to two further problems: 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.
* 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 present", is
to forward the S-PMSI A-D route, with the same PTA, to the next expected to forward the S-PMSI A-D route, with the same PTA, to
segmentation domain. the next 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" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 Information
flag, that is used for explicit tracking. Required" (LIR) 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 Information
per Flow" bit (LIR-pF). This flag may be set in the PTA of a Required per Flow" bit (LIR-pF). This flag may be set in the PTA of
(C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The conditions a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The
under which it should be set by the originator of the route are conditions under which it should be set by the originator of the
discussed in Section 4. The significance of the flag in a received route are discussed in Section 4. The significance of the flag in a
S-PMSI A-D route is discussed in Sections 5 and 5.2. received S-PMSI A-D route is discussed in Sections 5 and 5.2.
If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR 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. flag of that PTA MUST also be set.
Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD
NOT be set unless it is known that all the PEs that are to receive 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 the route carrying the PTA support the flag. How this is known is
outside the scope of this document. outside the scope of this document.
The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The
skipping to change at page 6, line 48 skipping to change at page 6, line 48
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 present", 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 present".
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 present".
We also introduce a new notion, the "match for tracking": 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 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 present", but does not have either LIR or
set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA LIR-pF set. (That is, DO NOT ignore an S-PMSI A-D route that has
specifying "no tunnel information" unless its LIR and LIR-pF bits a PTA specifying "no tunnel information present" unless its LIR
are both clear). Then apply the rules (from [RFC6625] and other and LIR-pF bits are both clear). Then apply the rules (from
documents that that update it) for finding the "match for [RFC6625] and other documents that update [RFC6625]) for finding
reception". The result (if any) is the match for tracking". the "match for reception". The result (if any) is the match for
tracking".
Note that the procedure for finding the match for tracking takes Note that the procedure for finding the match for tracking takes
into account S-PMSI A-D routes whose PTAs specify "no tunnel into account S-PMSI A-D routes whose PTAs specify "no tunnel
information" and that have either LIR or LIR-pf set. The information present" and that have either LIR or LIR-pf set. The
procedure for finding the match for reception ignores such routes. 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.
o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no
tunnel info" and has LIR set. tunnel information present" and has LIR set.
Route1 is (C-S1,C-G1)'s match for reception, and Route2 is Route1 is (C-S1,C-G1)'s match for reception, and Route2 is
(C-S1,C-G1)'s match for tracking. (C-S1,C-G1)'s match for tracking.
Continuing this example, suppose: Continuing this example, suppose:
o PE1 has chosen PE2 as the upstream PE for a different flow, o PE1 has chosen PE2 as the upstream PE for a different flow,
(C-S2,C-G2). (C-S2,C-G2).
o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2). o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2).
skipping to change at page 8, line 42 skipping to change at page 8, line 47
4. Ingress Node Initiation of Tracking 4. Ingress Node Initiation of Tracking
An ingress node that needs to initiate explicit tracking for a 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 particular flow or set of flows can do so by performing one of the
following procedures: following procedures:
1. An ingress node can initiate explicit tracking for (C-S1,C-G1) by 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 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 its NLRI, including a PTA in that route, and setting the LIR flag
in that PTA. The PTA may specify a particular tunnel, or may in that PTA. The PTA may specify a particular tunnel, or may
specify "no tunnel info". specify "no tunnel information present".
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 information present" unless the ingress node
an A-D route carrying a PTA that specifies the tunnel to be used also originates an A-D route carrying a PTA that specifies the
for carrying (C-S1,C-G1) traffic. Such a route could be an tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route
I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*) could be an I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a
S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. (There is no (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route.
point in requesting explicit tracking for a given flow if there (There is no point in requesting explicit tracking for a given
is no tunnel on which the flow is being carried.) 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 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. In that case, the ingress node SHOULD NOT 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 originate a (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no
tunnel info"; such a route would not provide any additional tunnel information present"; such a route would not provide any
functionality. additional 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 information
ingress node withdraws the route. present", the 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 information
choice between these two options is determined by considerations present". The choice between these two options is determined by
that are outside the scope of this document. considerations 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 information
ingress node withdraws the route. present", the 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 either the LIR or LIR-pF flags re-originates the route without either the LIR or LIR-pF flags
set. set.
Note that this procedure (procedure 2 of Section 4) may not yield Note that this procedure (procedure 2 of Section 4) may not yield
the expected results if there are egress nodes that do not the expected results if there are egress nodes that do not
support the LIR-pF flag, and hence SHOULD NOT be used in that support the LIR-pF flag, and hence SHOULD NOT be used in that
case. case.
skipping to change at page 10, line 41 skipping to change at page 10, line 43
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 node 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 node supports based on the match for reception. If the egress node supports
the LIR-pF flag, it MUST also follow the procedures of the LIR-pF flag, it MUST also follow the procedures of
Section 5.2. 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 information present",
or LIR-pF set. In this case, the egress node must respond, with either LIR or LIR-pF set. In this case, the egress node
separately, BOTH to the match for tracking and to the match for MUST respond, separately, BOTH to the match for tracking and to
reception. the match for 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 behavior of the egress node is not affected by the then the behavior of the egress node is not affected by the
procedures of this document. procedures of this document.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
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 set to the value of the RD 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. 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 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 [RFC7524] sets the RD to either 0 or -1; following the procedures of
of this document, the RD will never be 0 or -1. Therefore Leaf A-D the present document, the RD will never be 0 or -1. Therefore Leaf
routes constructed according to the procedures of this section can A-D routes constructed according to the procedures of this section
always be distinguished from the Leaf A-D routes constructed can 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", the Leaf A-D route tracking whose PTA specifies "no tunnel information present", the
MUST carry a PTA that specifies "no tunnel info". The LIR-pF flag in Leaf A-D route MUST carry a PTA that specifies "no tunnel information
this PTA MUST be set. present". The LIR-pF flag in 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 are the same, the PTA of the match may have both the LIR and the
LIR-pF flags set. This may cause the egress node to originate one LIR-pF flags set. This may cause the egress node to originate one
Leaf A-D route in response to the LIR bit, and one or more Leaf A-D Leaf A-D route in response to the LIR bit, and one or more Leaf A-D
routes in response to the LIR-pF bit. Each such Leaf A-D route MUST routes in response to the LIR-pF bit. Each such Leaf A-D route MUST
have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that
when the match for tracking is the same as the match for reception, 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 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 tunnel type. The following rules specify how the PTA of the Leaf A-D
route is to be constructed: route is to be constructed:
o If the tunnel type of the PTA attached to the match for tracking/ 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 reception is Ingress Replication, the Leaf A-D route's PTA MAY
specify Ingress Replication. In this case, the MPLS Label field 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 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, 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. packets of the flow identified in the Leaf A-D route's NLRI.
Alternatively, the egress PE MAY specify an MPLS label value of Alternatively, the egress PE MAY specify an MPLS label value of
zero, or it MAY specify a tunnel type of "no tunnel info". In zero, or it MAY specify a tunnel type of "no tunnel information
either of these cases, when the ingress PE transmits packets of present". In either of these cases, when the ingress PE transmits
the identified flow to the egress PE, it will use the label that packets of the identified flow to the egress PE, it will use the
the egress PE specified in the PTA of the Leaf A-D route that it label that the egress PE specified in the PTA of the Leaf A-D
originated in response to the LIR bit of the match for reception. 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/ 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] 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 Section 5, the PTA attached to the Leaf A-D route MUST specify a
tunnel type of "no tunnel info". tunnel type of "no tunnel information present".
o When additional tunnel types are defined, the specification for o When additional tunnel types are defined, the specification for
how MVPN is to use those tunnel types must also specify how to 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 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]. 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.
skipping to change at page 14, line 32 skipping to change at page 14, line 32
Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel,
and also has LIR-pF set. The egress ABR/ASBR originates a and also has LIR-pF set. The egress ABR/ASBR originates a
corresponding Leaf A-D route for a given (C-S,C-G) only if it knows 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 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 receiving a corresponding Leaf A-D route from downstream. (In the
case where the PTA specifies a tunnel but LIR-pF is not set, this case where the PTA specifies a tunnel but LIR-pF is not set, this
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 information present" 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 information present", the egress ABR/ASBR MUST pass the PTA along
forwards the S-PMSI A-D route. (That is, a PTA specifying "no tunnel unchanged when it forwards the S-PMSI A-D route. (That is, a PTA
info" MUST NOT be changed into a PTA specifying a tunnel.) specifying "no tunnel information present" MUST NOT be changed into a
Furthermore, if the PTA specifies "no tunnel info", the LIR and PTA specifying a tunnel.) Furthermore, if the PTA specifies "no
LIR-pF flags in the PTA MUST be passed along unchanged. 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/ 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
skipping to change at page 15, line 39 skipping to change at page 15, line 39
which L is a valid response according to the procedures of which L is a valid response according to the procedures of
Section 5.2. In this case, L MUST be processed by N. Section 5.2. In this case, L MUST be processed by N.
Suppose that L's PTA specifies a tunnel type of Ingress Replication, 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 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 send to L a packet belonging to the multicast flow or flows
identified in L's NLRI, N MUST use the specified label. identified in L's NLRI, N MUST use the specified label.
If L's PTA meets any of the following conditions: 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 "no tunnel information present", or
o It specifies a tunnel type of Ingress Replication, but specifies o It specifies a tunnel type of Ingress Replication, but specifies
an MPLS label of zero, or an MPLS label of zero, or
o It specifies another of the tunnel types listed in Section 5 of o It specifies another of the tunnel types listed in Section 5 of
[RFC6514], [RFC6514],
then the action taken by N when it receives L is a local matter. In 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 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 for the flow identified by L's NLRI. However, that
 End of changes. 29 change blocks. 
74 lines changed or deleted 78 lines changed or added

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