draft-ietf-bess-mvpn-expl-track-12.txt   draft-ietf-bess-mvpn-expl-track-13.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 7582 7900 (if Nokia
Intended status: Standards Track E. Rosen, Ed. approved) E. Rosen, Ed.
Expires: April 12, 2019 Z. Zhang Intended status: Standards Track Z. Zhang
Juniper Networks, Inc. Expires: June 1, 2019 Juniper Networks, Inc.
October 9, 2018 November 28, 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-12 draft-ietf-bess-mvpn-expl-track-13
Abstract Abstract
The MVPN specifications provide procedures to allow a multicast The Multicast VPN (MVPN) specifications provide procedures to allow a
ingress node to invoke "explicit tracking" for a multicast flow or multicast ingress node to invoke "explicit tracking" for a multicast
set of flows, thus learning the egress nodes for that flow or set of flow or set of flows, thus learning the egress nodes for that flow or
flows. However, the specifications are not completely clear about set of flows. However, the specifications are not completely clear
how the explicit tracking procedures work in certain scenarios. This about how the explicit tracking procedures work in certain scenarios.
document provides the necessary clarifications. It also specifies a This document provides the necessary clarifications. It also
new, optimized explicit tracking procedure. This new procedure specifies a new, optimized explicit tracking procedure. This new
allows an ingress node, by sending a single message, to request procedure allows an ingress node, by sending a single message, to
explicit tracking of each of a set of flows, where the set of flows request explicit tracking of each of a set of flows, where the set of
is specified using a wildcard mechanism. This document updates RFCs flows is specified using a wildcard mechanism. This document updates
6514, 6625, and 7524. RFCs 6514, 6625, 7524, 7582, and 7900.
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 April 12, 2019. This Internet-Draft will expire on June 1, 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
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 . . . . . . . . . 6 3. Match for Tracking vs. Match for Reception . . . . . . . . . 7
4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 8 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 9
5. Egress Node Response to the Match for Tracking . . . . . . . 10 5. Egress Node Response to the Match for Tracking . . . . . . . 10
5.1. General Egress Node Procedures . . . . . . . . . . . . . 10 5.1. General Egress Node Procedures . . . . . . . . . . . . . 11
5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 11 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 12
5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 14 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 15
6. Ingress Node Handling of Received Leaf A-D Routes with 6. Ingress Node Handling of Received Leaf A-D Routes with
LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 15 LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[RFC6513] and [RFC6514] define the "Selective Provider Multicast The base Multicast VPN (MVPN) specifications,[RFC6513] and [RFC6514],
Service Interface Auto-Discovery route" (S-PMSI A-D route). define the "Selective Provider Multicast Service Interface Auto-
Discovery route" (S-PMSI A-D route).
Per those RFCs, the S-PMSI A-D route contains a Network Layer 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
IP multicast address, both in the address space of a VPN customer. IP multicast address, both in the address space of a VPN customer.
The (C-S,C-G) of the multicast flow is encoded into the NLRI field. 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). 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 Typically, the PTA is used to identify a tunnel through the provider
skipping to change at page 4, line 19 skipping to change at page 4, line 24
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 Section 5 of in the PTA of each (C-S,C-G) S-PMSI A-D route. Per Section 5 of
[RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no [RFC6514], the PTA of the (C-S,C-G) S-PMSI A-D routes can specify "no
tunnel information present". This procedure allows explicit tracking tunnel information present". This procedure allows explicit tracking
of individual flows, even though all those flows are assigned to of individual flows, even though all those flows are assigned to
tunnels in wildcard S-PMSI A-D routes. tunnels by 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 information present". "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
skipping to change at page 5, line 36 skipping to change at page 5, line 39
[RFC6514] defines one flag in the PTA, the "Leaf Information [RFC6514] defines one flag in the PTA, the "Leaf Information
Required" (LIR) 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 Information Tunnel attribute. This new flag is known as the "Leaf Information
Required per Flow" bit (LIR-pF). This flag may be set in the PTA of Required 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. The a (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The
conditions under which it should be set by the originator of the conditions under which it should be set by the originator of the
route are discussed in Section 4. The significance of the flag in a route are 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. received wildcard 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
flag of that PTA MUST also be set.
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
the route carrying the PTA support the flag. How this is known is
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
conditions under which it should be set by the originator of the conditions under which it should be set by the originator of the
route are discussed in Section 5.2. The significance of the flag in route are discussed in Section 5.2. The significance of the flag in
a received Leaf A-D route is discussed in Section 6. a received Leaf A-D route is discussed in Section 6.
Use of this flag in the PTA carried by other route types is outside Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD
the scope of this document. Use of this flag in the PTA carried by NOT be set in a route's PTA unless it is known that the flag is
an S-PMSI A-D routes whose NLRI does not contain a wildcard is supported by all the Provider Edge routers (PEs) that are to receive
that route. Typically, this might mean that the ability to set this
flag would be controlled by a configuration knob, and operators would
not set this knob unless they know that all the relevant PEs support
this feature. How this is known is outside the scope of this
document.
This document only defines procedures for the LIR-pF flag when that
flag is in the PTA of a wildcard S-PMSI A-D route, or in the PTA of a
Leaf A-D route. In all other cases, the flag SHOULD be clear, and
its value SHOULD be ignored. Use of the flag in such cases is
outside the scope of this document. outside the scope of this document.
Section 5 of [RFC6514] lists a number of tunnel types. We will refer
to these as "6514-tunnel-types". Other tunnel types will be referred
to as "non-6514-tunnel-types". This document specifies procedures
for using the LIR-pF flag with 6514-tunnel-types. Procedures for
using the LIR-pF flag with non-6514-tunnel-types are outside the
scope of this document.
If it is desired to use a particular non-6514-tunnel-type in MVPN,
there needs to be a specification for how that tunnel type is used in
MVPN. If it is desired to use that tunnel type along with the LIR-pF
flag, that specification (or a followon specification) will have to
specify the rules for using the LIR-pF flag with that tunnel type.
As an example, see [BIER-MVPN]. In the absence of such a
specification (or in the absence of support for such a
specification):
o the originator of a route that carries a PTA SHOULD NOT set LIR-pF
in any PTA that specifies that tunnel type, and
o the receiver of a route that carries a PTA specifying that tunnel
type SHOULD treat the LIR-pF flag as if it were not set.
If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the
originator of that route MUST also set the LIR flag. If the PTA of a
received wildcard S-PMSI A-D route has LIR-pF set but does not have
LIR set, the receiver MUST log the fact that the flags appear to have
been improperly set. However, the route MUST then be processed
normally (as if both flags were set), as specified in this document.
It is worth noting what will happen if the LIR-pF flag is set in the It is worth noting what will happen if the LIR-pF flag is set in the
PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an
ingress node, but one or more of the egress nodes do not support the ingress node, but one or more of the egress nodes do not support the
LIR-pF flag: LIR-pF flag:
1. The ingress node will not be able to determine the complete set 1. The ingress node will not be able to determine the complete set
of egress node that are expecting a particular multicast flow of egress nodes that are expecting a particular multicast flow
from that ingress node. from that ingress node.
2. Depending upon the tunnel type, the ingress node may send a 2. Depending upon the tunnel type, the ingress node may send a
particular multicast flow only to the egress nodes that do particular multicast flow only to the egress nodes that do
support the LIR-pF flag. From the perspective of egress nodes support the LIR-pF flag. From the perspective of egress nodes
that do not support LIR-pF, certain flows may appear to be that do not support LIR-pF, certain flows may appear to be
"blackholed". "blackholed".
It is also worth noting that it is possible for an ingress node that It is also worth noting that it is possible for an ingress node that
sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of
egress nodes that do not support this flag. egress nodes that do not support this flag.
Since an ingress node that sets the LIR-pF flag is also REQUIRED to Since an ingress node that sets the LIR-pF flag is also required to
set the LIR flag, egress nodes that do not support the LIR-pF flag set the LIR flag, egress nodes that do not support the LIR-pF flag
will respond, as specified in [RFC6514], to the ingress node's will respond, as specified in [RFC6514], to the ingress node's
(C-*,C-*) S-PMSI A-D route with a Leaf A-D route operator. (C-*,C-*) S-PMSI A-D route with a Leaf A-D route.
As will be discussed in Section 5.2, any Leaf A-D route originated in As will be discussed in Section 5.2, any Leaf A-D route originated in
response to an S-PMSI A-D route that has LIR-pF set will carry a PTA response to an S-PMSI A-D route that has LIR-pF set will carry a PTA
whose LIR-pF flag is set. If an ingress node receives a Leaf A-D whose LIR-pF flag is set. If an ingress node receives a Leaf A-D
route whose "route key" field corresponds to the NLRI of an S-PMSI route whose "route key" field corresponds to the NLRI of an S-PMSI
A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a
PTA or has a PTA where LIR-pF is clear, the ingress node can conclude PTA or has a PTA where LIR-pF is clear, the ingress node can infer
that the egress node originating that Leaf A-D route does not support that the egress node originating that Leaf A-D route does not support
the LIR-pF flag. the LIR-pF flag. The software at the ingress node MUST detect this,
and MUST have a way of alerting the operator that the deployment is
The software at the ingress node MUST detect this, and MUST have a not properly configured.
way of alerting the operator that the deployment is not properly
configured.
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
skipping to change at page 7, line 26 skipping to change at page 8, line 12
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 present". "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 present", but does not have either LIR or "no tunnel information present" and has neither LIR nor LIR-pF
LIR-pF set. (That is, DO NOT ignore an S-PMSI A-D route that has set. (That is, DO NOT ignore an S-PMSI A-D route that has a PTA
a PTA specifying "no tunnel information present" unless its LIR specifying "no tunnel information present" unless its LIR and
and LIR-pF bits are both clear). Then apply the rules (from LIR-pF bits are both clear). Then apply the rules (from [RFC6625]
[RFC6625] and other documents that update [RFC6625]) for finding and other documents that update [RFC6625]) for finding the "match
the "match for reception". The result (if any) is the match for for reception". The result (if any) is the "match for tracking".
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 present" 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.
skipping to change at page 9, line 9 skipping to change at page 9, line 43
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 information present". 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 information present" unless the ingress node specify "no tunnel information present" unless the ingress node
also originates an A-D route carrying a PTA that specifies the also originates an A-D route carrying a PTA that specifies the
tunnel to be used for carrying (C-S1,C-G1) traffic. Such a route tunnel to be used 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 could be an "Inclusive Provider Multicast Service Interface Auto-
(C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. Discovery route" (I-PMSI A-D route), a (C-*,C-G1) S-PMSI A-D
(There is no point in requesting explicit tracking for a given route, a (C-S1,C-*) S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D
flow if there is no tunnel on which the flow is being carried.) route. (There is no point in requesting explicit tracking for a
given flow if there is no tunnel on which the flow is being
carried.)
Note that if the ingress node originates a wildcard S-PMSI A-D 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 information present"; such a route would not provide any tunnel information present"; such a route would not provide any
additional functionality. additional functionality.
skipping to change at page 10, line 39 skipping to change at page 11, line 29
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 node MUST match for reception, and LIR-pF is set. The egress node follows
follow whatever procedures are required by other specifications, whatever procedures are required by other specifications, based
based on the match for reception. If the egress node supports on the match for reception. However, any Leaf A-D route
the LIR-pF flag, it MUST also follow the procedures of originated by the egress node as a result MUST have the LIR-pF
Section 5.2. flag set in its PTA. The egress node MUST also follow the
procedures of Section 5.2.
4. With regard to a particular (C-S,C-G) or (C-*,C-G) multicast 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 information present", tracking has a PTA specifying "no tunnel information present",
with either LIR or LIR-pF set. In this case, the egress node with either LIR or LIR-pF set. In this case, the egress node
MUST respond, separately, BOTH to the match for tracking and to MUST respond, separately, BOTH to the match for tracking and to
the match for reception. the match for reception.
When responding to the match for reception, the egress node MUST If a Leaf A-D route is originated in response to the match for
ignore the LIR-pF flag. However, the LIR flag is processed reception, the LIR-pF flag in the Leaf A-D route's PTA MUST have
normally per the procedures for the match for reception. the same value as the LIR-pF flag in the match for reception's
PTA. In all other respects, the procedures for responding to the
match for reception are not affected by this document.
If the match for tracking has LIR set and if either (a) the If the match for tracking has LIR set but LIR-pF is not set, then
egress node does not support LIR-pF, or (b) LIR-pF is not set, the behavior of the egress node is not affected by the procedures
then the behavior of the egress node is not affected by the of this document.
procedures of this document.
If the match for tracking has LIR-pF set, and the egress node If the match for tracking has LIR-pF set, the egress node MUST
supports the LIR-pF flag, the egress node must originate one or follow the procedures of 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.
5.2. Responding to the LIR-pF Flag 5.2. Responding to the LIR-pF Flag
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.
skipping to change at page 11, line 43 skipping to change at page 12, line 37
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 node may need the match for tracking for multiple flows, the egress node may need
to originate multiple Leaf A-D routes, one for each such flow. We to originate multiple Leaf A-D routes, one for each such flow. We
say that, from the perspective of a given egress node, a given S-PMSI say that, from the perspective of a given egress node, a given S-PMSI
A-D route tracks the set of flows for which it is the match for A-D route tracks the set of flows for which it is the match for
tracking. Each of the Leaf A-D routes originated in response to that tracking. Each of the Leaf A-D routes originated in response to that
S-PMSI A-D 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 (as defined in Sections 4.4 and 4.3 of
[RFC6514]):
+-----------------------------------+ +-----------------------------------+
| RD (8 octets) | | RD (8 octets) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source Length (1 octet) | | Multicast Source Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Source (Variable) | | Multicast Source (Variable) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group Length (1 octet) | | Multicast Group Length (1 octet) |
+-----------------------------------+ +-----------------------------------+
| Multicast Group (Variable) | | Multicast Group (Variable) |
+-----------------------------------+ +-----------------------------------+
| Ingress PE's IP address | | Ingress PE's IP address |
+-----------------------------------+ +-----------------------------------+
Figure 1: NLRI of S-PMSI A-D Route Figure 1: NLRI of S-PMSI A-D Route
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. Section 2 of [RFC6515] explains how the receiver of a
Leaf A-D route determines the length of this field and the address
family of the PE's IP address.
o The multicast source and 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. In this case, the Leaf A-D
route is known as a "wildcard Leaf A-D route".
o The Route Distinguisher (RD) field is set to the value of the RD 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,
[RFC7524] sets the RD to either 0 or -1; following the procedures of [RFC7524] sets the RD to either 0 or -1; following the procedures of
the present document, the RD will never be 0 or -1. Therefore Leaf the present document, the RD will never be 0 or -1. Therefore Leaf
A-D routes constructed according to the procedures of this section A-D routes constructed according to the procedures of this section
skipping to change at page 12, line 50 skipping to change at page 14, line 5
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 information present", the tracking whose PTA specifies "no tunnel information present", the
Leaf A-D route MUST carry a PTA that specifies "no tunnel information Leaf A-D route MUST carry a PTA that specifies "no tunnel information
present". The LIR-pF flag in 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 If an egress node originates multiple Leaf A-D routes in response to
are the same, the PTA of the match may have both the LIR and the a single S-PMSI A-D route, and that S-PMSI A-D route is later
LIR-pF flags set. This may cause the egress node to originate one withdrawn, then those Leaf A-D routes MUST also be withdrawn.
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 Similarly, a Leaf A-D route needs to be withdrawn (either implicitly
have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that or explicitly) if the egress node changes its Upstream Multicast Hop
when the match for tracking is the same as the match for reception, (UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D
route's NLRI, or if the egress node that originated the route no
longer needs to receive that flow.
It is possible that an egress node will acquire (C-S,C-G) state or
(C-*,C-G) state after it has already received the S-PMSI A-D that is
the match for tracking for that state. In this case, a Leaf A-D
route needs to be originated at that time, and the egress node must
remember that the new Leaf A-D route corresponds to that match for
tracking.
If a particular S-PMSI A-D route is a match for tracking but not a
match for reception, the LIR bit in its PTA is ignored if the LIR-pF
bit is set.
When the match for tracking is the same as the match for reception,
the PTA of the match for tracking/reception will have specified a 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. Some of the rules for constructing the PTA of the Leaf
route is to be constructed: A-D route depend on the tunnel type, and some are independent of the
tunnel type. No matter what the tunnel type is, the LIR-pF flag MUST
be set.
If the match for tracking/reception is a wildcard S-PMSI A-D route,
the egress node may originate a wildcard Leaf A-D route in response,
as well as originating one or more non-wildcard Leaf A-D routes.
Note that the LIR-pF flag MUST be set in the wildcard Leaf A-D route
as well as in the non-wildcard Leaf A-D routes.
This document provides additional rules for constructing the PTA when
the tunnel type is a 6514-tunnel-type (see Section 2).
As discussed in Section 2, if a non-6514-tunnel-type is being used,
then presumably there is a specification for how that tunnel type is
used in MVPN. If it is desired to use that tunnel type along with
the LIR-pF flag, that specification (or a followon specification)
will have to specify the additional rules for constructing the PTA.
As an example, see [BIER-MVPN].
For 6514-tunnel-types, additional rules for constructing the PTA are
as follows:
o If the tunnel type of the PTA attached to the match for tracking/ 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 information zero, or it MAY specify a tunnel type of "no tunnel information
present". In either of these cases, when the ingress PE transmits present". In either of these cases, when the ingress PE transmits
packets of the identified flow to the egress PE, it will use the 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 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 route that it originated in response to the LIR bit of the match
for reception. 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 6514-tunnel-types, the PTA attached
Section 5, the PTA attached to the Leaf A-D route MUST specify a to the Leaf A-D route MUST specify a tunnel type of "no tunnel
tunnel type of "no tunnel information present". information present".
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
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
routes MUST be withdrawn.
Similarly, a Leaf A-D route needs to be withdrawn (either implicitly
or explicitly) if the egress node changes its Upstream Multicast Hop
(UMH) ([RFC6513]) for the flow that is identified in the Leaf A-D
route's NLRI, or if the egress node that originated the route no
longer needs to receive the flow identified in the NLRI of the route.
Note that an egress node may acquire (C-S,C-G) state or (C-*,C-G)
state after it has already received the S-PMSI A-D that is the match
for tracking for that state. In this case, a Leaf A-D route needs to
be originated at that time, and the egress node must remember that
the new Leaf A-D route corresponds to that match for tracking.
Note that if a particular S-PMSI A-D route is a match for tracking It may happen that the tunnel type is a non-6514-tunnel type, but
but not a match for reception, the LIR bit in its PTA is ignored if either (a) there is no specification for how to use that tunnel type
the LIR-pF bit is set. with the LIR-pF flag, or (b) there is such a specification, but the
egress node does not support it. In that case, the egress node MUST
treat the match for tracking/reception as if it had the LIR-pF bit
clear.
5.3. When the Egress Node is an ABR or ASBR 5.3. When the Egress Node is an ABR or ASBR
When segmented P-tunnels are used, the ingress and egress nodes may When segmented P-tunnels are used, the ingress and egress nodes may
be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an
S-PMSI A-D route also forwards that route. If the PTA of an S-PMSI A-D route also forwards that route. If the received PTA of an
installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR
MAY change the PTA to specify a different tunnel type (as discussed MAY change the PTA before forwarding the route, in order to specify a
in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to different tunnel type (as discussed in [RFC6514] and/or [RFC7524]).
originate a Leaf A-D route, as specified in [RFC6514] and/or The egress ABR/ASBR may also need to originate a Leaf A-D route, as
[RFC7524]. specified in [RFC6514] and/or [RFC7524].
Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel, Suppose the S-PMSI A-D route as received has a PTA specifying a
and also has LIR-pF set. The egress ABR/ASBR originates a tunnel, 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 as
"no tunnel information present" but has LIR or LIR-pF set. received specifies "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 received PTA of the installed S-PMSI A-D route specifies "no
information present", the egress ABR/ASBR MUST pass the PTA along tunnel information present", the egress ABR/ASBR MUST pass the PTA
unchanged when it forwards the S-PMSI A-D route. (That is, a PTA along unchanged when it forwards the S-PMSI A-D route. (That is, a
specifying "no tunnel information present" MUST NOT be changed into a PTA specifying "no tunnel information present" MUST NOT be changed
PTA specifying a tunnel.) Furthermore, if the PTA specifies "no into a PTA specifying a tunnel.) Furthermore, if the PTA specifies
tunnel information present", the LIR and LIR-pF flags in the PTA MUST "no tunnel information present", the LIR and LIR-pF flags in the PTA
be passed along unchanged. 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 Point-to-Multipoint (P2MP)
Community ([RFC7524]). Next Hop Extended Community ([RFC7524]). The address from the
Segmented P2MP Next Hop Extended Community is used if that Extended
Community is present; otherwise the address from the next hop field
is used.
This procedure enables the ingress PE to explicitly track the egress 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. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set 6. Ingress Node Handling of Received Leaf A-D Routes with LIR-pF Set
skipping to change at page 15, line 28 skipping to change at page 17, line 6
o L carries an IP-address-specific RT identifying N. 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 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. 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 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. does not cause any MVPN-specific action to be taken by N.
This document modifies those procedures in the case where there is a 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 current wildcard S-PMSI A-D route, originated by N, to which L is a
which L is a valid response according to the procedures of valid response according to the procedures of Section 5.2. In this
Section 5.2. In this case, L MUST be processed by N. 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 present", 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 any other 6514-tunnel-type,
[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
information is for management/monitoring purposes and does not have information is for management/monitoring purposes and does not have
an effect on the flow of multicast traffic. any direct effect on the flow of multicast traffic.
If L's PTA specifies a tunnel type not mentioned above, the If L's PTA specifies a non-6514-tunnel-type not mentioned above,
specification for how MVPN uses that tunnel type must specify the presumably there is a specification for how MVPN uses that tunnel
actions that N is to take upon receiving L. As an example, see type. If the LIR-pF flag is to be used with that tunnel type, that
[BIER-MVPN]. specification must specify the actions that N is to take upon
receiving L. As an example, see [BIER-MVPN]. In the absence of such
a specification, the LIR-pF flag SHOULD BE ignored. See
Section Section 2 for further discussion of non-6514-tunnel-types.
7. Acknowledgments 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 and to thank Stephane Litkowski and Benjamin Kaduk for their thorough
suggestions. reviews and useful suggestions. We would also like to thank Mirja
Kuhlewind for her attention to the Security Considerations section.
8. IANA Considerations 8. IANA Considerations
IANA is requested to add a new entry to the the "P-Multicast Service IANA is requested to add a new entry to the 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 new entry is: defined in [RFC7902]. The new entry is:
o Value: 2 o Value: 2
o Name: LIR-PF o Name: LIR-PF
o Description: Leaf Information Required per-Flow o Description: Leaf Information Required per-Flow
o Reference: this document. o Reference: this document.
9. Security Considerations 9. Security Considerations
The Security Considerations of [RFC6513] and [RFC6514] apply. The Security Considerations of [RFC6513] and [RFC6514] apply.
skipping to change at page 16, line 38 skipping to change at page 18, line 17
o Reference: this document. o Reference: this document.
9. Security Considerations 9. 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. The specification of increase in control plane overhead can result. Properly protecting
counter-measures for this problem is outside the scope of this the control plane should prevent this kind of attack.
document.
In the event such an attack occurs, mitigating it is unfortunately
not very straightforward. The ingress node can take note of the fact
that it is getting, in response to an S-PMSI A-D route that has
LIR-pF clear, one or more Leaf A-D routes that have LIR-pF set. By
default, the reception of such a route MUST be logged. However, it
is possible for such log entries to be "false positives" that
generate a lot of "noise" in the log; therefore implementations
SHOULD have a knob to disable this logging.
In theory, if one or more Leaf A-D routes with LIR-pF set arrive in
response to an S-PMSI A-D route with LIR-pF clear, withdrawing the
S-PMSI A-D route could put a stop to the attack. In practice, that
is not likely to be a very good strategy because:
o Under normal operating conditions, there are some race conditions
that may cause the ingress node to think it is being attacked,
when in fact it is not.
o If some egress nodes have a bug that causes them to set LIR-pF
when it should be clear, withdrawing the S-PMSI A-D route will
stop the flow of multicast data traffic to all the egress nodes,
causing an unnecessary customer-visible disruption.
o The same situation that caused the S-PMSI A-D route to be
originated in the first place will still exist after the S-PMSI
A-D route is withdrawn, so the route will just be re-originated.
In other words, any action that would ameliorate the effects of this
sort of attack would likely have a negative effect during normal
operation. Therefore it is really better to rely on security
mechanisms that protect the control plane generally, rather than
having a mechanism that is focused on this one particular type of
attack.
10. References 10. References
10.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>.
[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>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
Addresses in BGP Updates for Multicast VPN", RFC 6515,
DOI 10.17487/RFC6515, February 2012,
<https://www.rfc-editor.org/info/rfc6515>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [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., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
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>.
 End of changes. 45 change blocks. 
157 lines changed or deleted 255 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/