draft-ietf-bess-mvpn-bidir-ingress-replication-04.txt   rfc7740.txt 
Network Working Group Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Internet-Draft Y. Rekhter Request for Comments: 7740 Y. Rekhter
Intended status: Standards Track Juniper Networks Category: Standards Track Juniper Networks
Expires: April 18, 2016 A. Dolganow ISSN: 2070-1721 A. Dolganow
Alcatel-Lucent Alcatel-Lucent
October 16, 2015 January 2016
Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP)
draft-ietf-bess-mvpn-bidir-ingress-replication-04.txt Provider Tunnels with Ingress Replication
Abstract Abstract
RFC 6513 (Multicast in MPLS/BGP IP VPNs) describes a method to RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to
support bidirectional customer multicast flows using a partial mesh support bidirectional customer multicast flows using a partial mesh
of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies
how a partial mesh of MP2MP tunnels can be simulated using Ingress how a partial mesh of MP2MP tunnels can be simulated using Ingress
Replication. This solution enables a Service Provider to use Ingress Replication. This solution enables a service provider to use Ingress
Replication to offer transparent bidirectional multicast service to Replication to offer transparent bidirectional multicast service to
its VPN customers. its VPN customers.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 18, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7740.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Control State . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Control State . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Forwarding State . . . . . . . . . . . . . . . . . . . . . 7 2.2. Forwarding State . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Normative References . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Informative References . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Section 11.2 of RFC 6513, "Partitioned Sets of PEs", describes two Section 11.2 of RFC 6513 ("Partitioned Sets of PEs") describes two
methods of carrying BIDIR-PIM [RFC5015] C-flow traffic over a methods of carrying Bidirectional PIM (BIDIR-PIM) [RFC5015] C-flow
provider core without using the core as the Rendezvous Point Link traffic over a provider core without using the core as the Rendezvous
(RPL) or requiring Designated Forwarder election. Point Link (RPL) or requiring Designated Forwarder election.
With these two methods, all PEs of a particular VPN are separated With these two methods, all Provider Edges (PEs) of a particular VPN
into partitions, with each partition being all the PEs that elect the are separated into partitions, with each partition being all the PEs
same PE as the Upstream PE with respect to the C-RPA. A PE must that elect the same PE as the Upstream PE with respect to the C-RPA
discard bidirectional C-flow traffic from PEs that are not in the (the Rendezvous Point Address in the customer's address space). A PE
same partition as the PE itself. must discard bidirectional C-flow traffic from PEs that are not in
the same partition as the PE itself.
In particular, Section 11.2.3 of RFC 6513, "Partial Mesh of MP2MP In particular, Section 11.2.3 of RFC 6513 ("Partial Mesh of MP2MP
P-Tunnels", guarantees the above discard behavior without using an P-Tunnels") guarantees the above discard behavior without using an
extra PE Distinguisher label by having all PEs in the same partition extra PE Distinguisher Label by having all PEs in the same partition
join a single MP2MP tunnel dedicated to that partition and use it to join a single MP2MP tunnel dedicated to that partition and use it to
transmit traffic. All traffic arriving on the tunnel will be from transmit traffic. All traffic arriving on the tunnel will be from
PEs in the same partition, so it will be always accepted. PEs in the same partition, so it will be always accepted.
RFC 6514 specifies BGP encodings and procedures used to implement RFC 6514 specifies BGP encodings and procedures used to implement
MVPN as specified in RFC 6513, while the details related to MP2MP Multicast VPN (MVPN) as specified in RFC 6513, while the details
tunnels are specified in [RFC7582]. related to MP2MP tunnels are specified in [RFC7582].
RFC 7582 assumes that an MP2MP P-tunnel is realized either via Bidir- RFC 7582 assumes that an MP2MP P-tunnel is realized either via BIDIR-
PIM [RFC5015], or via MP2MP mLDP [RFC6388]. Each of them would PIM [RFC5015] or via MP2MP mLDP (Multipoint extensions for LDP)
require signaling and state not just on PEs, but on the P routers as [RFC6388]. Each would require signaling and state not just on PEs,
well. This document describes how the MP2MP tunnel can be simulated but on the P routers as well. This document describes how the MP2MP
with a mesh of P2MP tunnels, each of which is instantiated by Ingress tunnel can be simulated with a mesh of P2MP tunnels, each of which is
Replication (IR) [RFC6513, RFC6514]. Different from the procedures instantiated by Ingress Replication (IR) [RFC6513] [RFC6514]. The
in RFC 6514 that are used to set up the mesh of Ingress Replication procedures in this document are different from the procedures that
tunnels, the procedures in this document do not require each PE on are used to set up the mesh of Ingress Replication tunnels as
the MP2MP tunnel to send an S-PMSI A-D route for the P2MP tunnel that described in RFC 6514; the procedures in this document do not require
the PE is the root for, nor does it require each PE to send a Leaf each PE on the MP2MP tunnel to send a Selective P-Multicast Service
A-D route to the root of each P2MP tunnel in the mesh. Interface (S-PMSI) auto-discovery route (A-D route) for the P2MP
tunnel that the PE is the root for, nor do they require each PE to
send a Leaf A-D route to the root of each P2MP tunnel in the mesh.
With the use of Ingress Replication, this scheme has both the Because it uses Ingress Replication, this scheme has both the
advantages and the disadvantages of Ingress Replication in general. advantages and the disadvantages of Ingress Replication in general.
1.1. Terminology 1.1. Terminology
This document uses terminology from [RFC5015], [RFC6513], [RFC6514], This document uses terminology from [RFC5015], [RFC6513], [RFC6514],
and [RFC7582]. and [RFC7582].
2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 2. Operation
In following sections, the originator of an S-PMSI A-D route or Leaf In the following sections, the originator of an S-PMSI A-D route or
A-D route is determined from the "originating router's IP address" Leaf A-D route is determined from the "originating router's IP
field of the corresponding route. address" field of the corresponding route.
3.1. Control State 2.1. Control State
If a PE, say PEx, is connected to a site of a given VPN, and PEx's If a PE, say PEx, is connected to a site of a given VPN and PEx's
next hop interface to some C-RPA is a VRF interface, then PEx MUST next-hop interface to some C-RPA is a VPN Routing and Forwarding
advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether (VRF) interface, then PEx MUST advertise a (C-*,C-*-BIDIR) S-PMSI A-D
it has any local Bidir-PIM join states corresponding to the C-RPA route, regardless of whether it has any local BIDIR-PIM join states
learned from its CEs. It MAY also advertise one or more (C-*,C-G- corresponding to the C-RPA learned from its Customer Edges (CEs). It
BIDIR) S-PMSI A-D route, if selective distribution trees are needed MAY also advertise one or more (C-*,C-G-BIDIR) S-PMSI A-D routes, if
for those C-G-BIDIR groups, and the corresponding C-RPA is in the selective distribution trees are needed for those C-G-BIDIR groups
site that the PEx connects to. For example, the (C-*,C-G-BIDIR) and the corresponding C-RPA is in the site that the PEx connects to.
S-PMSI A-D routes could be triggered when the (C-*, C-G-BIDIR) For example, the (C-*,C-G-BIDIR) S-PMSI A-D routes could be triggered
traffic rate goes above a threshold (this may require measuring the when the (C-*,C-G-BIDIR) traffic rate goes above a threshold (this
traffic in both directions, due to the nature of Bidir-PIM), and fan- may require measuring the traffic in both directions, due to the
out could also be taken into account. nature of BIDIR-PIM), and fan-out could also be taken into account.
The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with
tunnel type set to Ingress Replication, with Leaf Information tunnel type set to Ingress Replication, with the Leaf Information
Required flag set, with a downstream allocated MPLS label that other Required flag set, with a downstream allocated MPLS label that other
PEs in the same partition MUST use when sending relevant C-bidir PEs in the same partition MUST use when sending relevant C-BIDIR
flows to this PE, and with the Tunnel Identifier field in the PTA set flows to this PE, and with the Tunnel Identifier field in the PTA set
to a routable address of the originator. This specification does not to a routable address of the originator. This specification does not
prevent sharing of labels between P-tunnels, such as a label being prevent sharing of labels between P-tunnels, such as a label being
shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route shared by a (C-*,C-*-BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route
originated by a given PE (note that other specs put constraints on originated by a given PE (note that other specifications put
how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet]). constraints on how that can be done, e.g., [MVPN-EXTRANET]).
If some other PE, PEy, receives and imports into one of its VRFs any If some other PE, PEy, receives and imports into one of its VRFs any
(C-*, C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, (C-*,C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel
and the VRF has any local Bidir-PIM join state that PEy has received and the VRF has any local BIDIR-PIM join state that PEy has received
from its CEs, and if PEy chooses PEx as its Upstream PE with respect from its CEs and if PEy chooses PEx as its Upstream PE with respect
to the C-RPA for those states, PEy MUST advertise a Leaf A-D route in to the C-RPA for those states, PEy MUST advertise a Leaf A-D route in
response. Or, if PEy has received and imported into one of its VRFs response. Or, if PEy has received and imported into one of its VRFs
a (C-*,C-*-BIDIR) S-PMSI A-D route from PEx before, then upon a (C-*,C-*-BIDIR) S-PMSI A-D route from PEx before, then upon
receiving in the VRF any local Bidir-PIM join state from its CEs with receiving in the VRF any local BIDIR-PIM join state from its CEs with
PEx being the Upstream PE for those states' C-RPA, PEy MUST advertise PEx being the Upstream PE for those states' C-RPA, PEy MUST advertise
a Leaf A-D route. a Leaf A-D route.
The encoding of the Leaf A-D route is as specified in RFC 6514, The encoding of the Leaf A-D route is as specified in RFC 6514,
except that the Route Targets are set to the same value as in the except that the Route Targets are set to the same value as in the
corresponding S-PMSI A-D route so that the Leaf A-D route will be corresponding S-PMSI A-D route so that the Leaf A-D route will be
imported by all VRFs that import the corresponding S-PMSI A-D route. imported by all VRFs that import the corresponding S-PMSI A-D route.
This is irrespective of whether the originator of the S-PMSI A-D This is irrespective of whether or not the originator of the S-PMSI
route is the Upstream PE or not from a receiving PE's perspective. A-D route is the Upstream PE from a receiving PE's perspective. The
The label in the PTA of the Leaf A-D route originated by PEy MUST be label in the PTA of the Leaf A-D route originated by PEy MUST be
allocated specifically for PEx, so that when traffic arrives with allocated specifically for PEx, so that when traffic arrives with
that label, the traffic can associated with the partition that label, the traffic can associate with the partition (represented
(represented by the PEx). This specification does not prevent by the PEx). This specification does not prevent sharing of labels
sharing of labels between P-tunnels, such as a label being shared by between P-tunnels, such as a label being shared by a (C-*,C-*-BIDIR)
a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) Leaf A-D route originated by and a (C-*,C-G-BIDIR) Leaf A-D route originated by a given PE (note
a given PE (note that other specs put constraints on how that can be that other specifications put constraints on how that can be done,
done, e.g. [I-D.ietf-bess-mvpn-extranet]). e.g., [MVPN-EXTRANET]).
Note that RFC 6514 requires a PE/ASBR take no action with regard to a Note that RFC 6514 requires that a PE or an ASBR (Autonomous System
Leaf A-D route unless that Leaf A-D route carries an IP Address Border Router) take no action with regard to a Leaf A-D route unless
Specific RT identifying the PE/ASBR. This document removes that that Leaf A-D route carries an IP-address-specific Route Target
requirement when the route key of a Leaf A-D route identifies a identifying the PE/ASBR. This document removes that requirement when
(C-*,C-*-BIDIR) or a (C-*,C-G-BIDIR) S-PMSI. the route key of a Leaf A-D route identifies a (C-*,C-*-BIDIR) or a
(C-*,C-G-BIDIR) S-PMSI.
To speed up convergence (so that PEy starts receiving traffic from To speed up convergence (so that PEy starts receiving traffic from
its new Upstream PE immediately instead of waiting until the new Leaf its new Upstream PE immediately instead of waiting until the new Leaf
A-D route corresponding to the new Upstream PE is received by sending A-D route corresponding to the new Upstream PE is received by sending
PEs), PEy MAY advertise a Leaf A-D route even if does not choose PEx PEs), PEy MAY advertise a Leaf A-D route even if it does not choose
as its Upstream PE with respect to the C-RPA. With that, it will PEx as its Upstream PE with respect to the C-RPA. With that, it will
receive traffic from all PEs, but some will arrive with the label receive traffic from all PEs, but some will arrive with the label
corresponding to its choice of Upstream PE while some will arrive corresponding to its choice of Upstream PE while some will arrive
with a different label, and the traffic in the latter case will be with a different label; the traffic in the latter case will be
discarded. discarded.
Similar to the (C-*,C-*-BIDIR) case, if PEy receives and imports into Similar to the (C-*,C-*-BIDIR) case, if PEy receives and imports into
one of its VRFs any (C-*,C-G-BIDIR) S-PMSI A-D route whose PTA one of its VRFs any (C-*,C-G-BIDIR) S-PMSI A-D route whose PTA
specifies an IR P-tunnel, and PEy chooses PEx as its Upstream PE with specifies an IR P-tunnel, PEy chooses PEx as its Upstream PE with
respect to the C-RPA, and it has corresponding local (C-*,C-G-BIDIR) respect to the C-RPA, and it has corresponding local (C-*,C-G-BIDIR)
join state that it has received from its CEs in the VRF, PEy MUST join state that it has received from its CEs in the VRF, PEy MUST
advertise a Leaf A-D route in response. Or, if PEy has received and advertise a Leaf A-D route in response. Or, if PEy has received and
imported into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route imported into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route
before, then upon receiving its local (C-*,C-G-BIDIR) join state from before, then upon receiving its local (C-*,C-G-BIDIR) join state from
its CEs in the VRF, it MUST advertise a Leaf A-D route. its CEs in the VRF, it MUST advertise a Leaf A-D route.
The encoding of the Leaf A-D route is the similar to the (C-*,C-*- The encoding of the Leaf A-D route is similar to the (C-*,C-*-BIDIR)
BIDIR) case. Also similarly, PEy MAY advertise a Leaf A-D route even case. Similarly, PEy MAY advertise a Leaf A-D route even if it does
if it does not choose PEx as its Upstream PE with respect to the not choose PEx as its Upstream PE with respect to the C-RPA.
C-RPA.
Whenever the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is PEy MUST withdraw the corresponding Leaf A-D route if any of the
withdrawn, or if PEy no longer chooses the originator PEx as its following conditions are true:
Upstream PE with respect to C-RPA and PEy only advertises Leaf A-D
routes in response to its Upstream PE's S-PMSI A-D route, or if
relevant local join state is pruned, PEy MUST withdraw the
corresponding Leaf A-D route.
3.2. Forwarding State o the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is
withdrawn.
The following specification regarding forwarding state matches the o PEy no longer chooses the originator PEx as its Upstream PE with
"When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is respect to C-RPA and PEy only advertises Leaf A-D routes in
a 'Match for Reception'" rules for "Flat Partitioning" method in response to its Upstream PE's S-PMSI A-D route.
[RFC7582], except that the rules about (C-*,C-*) are not applicable,
because this document requires that (C-*,C-*-BIDIR) S-PMSI A-D routes o if relevant local join state is pruned.
are always originated for a VPN that supports C-Bidir flows.
2.2. Forwarding State
The specification regarding forwarding state in this section matches
the "When an S-PMSI is a 'Match for Transmission'" and "When an
S-PMSI is a 'Match for Reception'" rules for the "Flat Partitioning"
method in [RFC7582], except that the rules about (C-*,C-*) are not
applicable, because this document requires that (C-*,C-*-BIDIR)
S-PMSI A-D routes are always originated for a VPN that supports
C-BIDIR flows.
For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and
imports into one of its VRFs from its Upstream PE with respect to the imports into one of its VRFs from its Upstream PE with respect to the
C-RPA, or if PEy itself advertises the S-PMSI A-D route in the VRF, C-RPA, if PEy itself advertises the S-PMSI A-D route in the VRF, PEy
PEy maintains a (C-*,C-G-BIDR) forwarding state in the VRF, with the maintains a (C-*,C-G-BIDIR) forwarding state in the VRF, with the
Ingress Replication provider tunnel leaves being the originators of Ingress Replication provider tunnel leaves being the originators of
the S-PMSI A-D route and all relevant Leaf-A-D routes. The relevant the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant
Leaf A-D routes are the routes whose Route Key field contains the Leaf A-D routes are the routes whose Route Key field contains the
same information as the MCAST-VPN NLRI of the (C-*, C-G-BIDIR) S-PMSI same information as the MCAST-VPN Network Layer Reachability
A-D route advertised by the Upstream PE. Information (NLRI) of the (C-*,C-G-BIDIR) S-PMSI A-D route advertised
by the Upstream PE.
For the (C-*,C-*-BIDIR) S-PMSI A-D route that a PEy receives and For the (C-*,C-*-BIDIR) S-PMSI A-D route that a PEy receives and
imports into one of its VRFs from its Upstream PE with respect to a imports into one of its VRFs from its Upstream PE with respect to a
C-RPA, or if PEy itself advertises the S-PMSI A-D route in the VRF, C-RPA, if PEy itself advertises the S-PMSI A-D route in the VRF, it
it maintains appropriate forwarding states in the VRF for the ranges maintains appropriate forwarding states in the VRF for the ranges of
of bidirectional groups for which the C-RPA is responsible. The bidirectional groups for which the C-RPA is responsible. The
provider tunnel leaves are the originators of the S-PMSI A-D route provider tunnel leaves are the originators of the S-PMSI A-D route
and all relevant Leaf-A-D routes. The relevant Leaf A-D routes are and all relevant Leaf A-D routes. The relevant Leaf A-D routes are
the routes whose Route Key field contains the same information as the the routes whose Route Key field contains the same information as the
MCAST-VPN NLRI of the (C-*, C-*-BIDIR) S-PMSI A-D route advertised by MCAST-VPN NLRI of the (C-*,C-*-BIDIR) S-PMSI A-D route advertised by
the Upstream PE. This is for the so-called "Sender Only Branches" the Upstream PE. This is for the so-called "Sender Only Branches"
where a router only has data to send upstream towards C-RPA but no where a router only has data to send upstream towards C-RPA but no
explicit join state for a particular bidirectional group. Note that explicit join state for a particular bidirectional group. Note that
the traffic must be sent to all PEs (not just the Upstream PE) in the the traffic must be sent to all PEs (not just the Upstream PE) in the
partition, because they may have specific (C-*,C-G-BIDIR) join states partition, because they may have specific (C-*,C-G-BIDIR) join states
that this PEy is not aware of, while there is no corresponding that this PEy is not aware of, while there are no corresponding
(C-*,C-G-BIDIR) S-PMSI A-D and Leaf A-D routes. (C-*,C-G-BIDIR) S-PMSI A-D and Leaf A-D routes.
For a (C-*,C-G-BIDIR) join state that a PEy has received from its CEs For a (C-*,C-G-BIDIR) join state that a PEy has received from its CEs
in a VRF, if there is no corresponding (C-*,C-G-BIDIR) S-PMSI A-D in a VRF, if there is no corresponding (C-*,C-G-BIDIR) S-PMSI A-D
route from its Upstream PE in the VRF, PEy maintains a corresponding route from its Upstream PE in the VRF, PEy maintains a corresponding
forwarding state in the VRF, with the provider tunnel leaves being forwarding state in the VRF, with the provider tunnel leaves being
the originators of the (C-*,C-*-BIDIR) S-PMSI A-D route and all the originators of the (C-*,C-*-BIDIR) S-PMSI A-D route and all
relevant Leaf-A-D routes (same as the above Sender Only Branch case). relevant Leaf A-D routes (same as the "Sender Only Branches" case
The relevant Leaf A-D routes are the routes whose Route Key field above). The relevant Leaf A-D routes are the routes whose Route Key
contains the same information as the MCAST-VPN NLRI of the (C-*, field contains the same information as the MCAST-VPN NLRI of the
C-*-BIDIR) S-PMSI A-D route originated by the Upstream PE. If there (C-*,C-*-BIDIR) S-PMSI A-D route originated by the Upstream PE. If
is no (C-*,C-*-BIDIR) S-PMSI A-D route from its Upstream PE either, there is also no (C-*,C-*-BIDIR) S-PMSI A-D route from its Upstream
then the provider tunnel has an empty set of leaves and PEy does not PE, then the provider tunnel has an empty set of leaves, and PEy does
forward relevant traffic across the provider network. not forward relevant traffic across the provider network.
4. Security Considerations 3. Security Considerations
This document raises no new security issues. Security considerations This document raises no new security issues. Security considerations
for the base protocol are covered in RFC6513 and RFC6514. for the base protocol are covered in [RFC6513] and [RFC6514].
5. IANA Considerations
This document has no IANA considerations.
This section should be removed by the RFC Editor prior to final
publication.
6. Acknowledgements
We would like to thank Eric Rosen for his comments, and suggestions
of some texts used in the document.
7. References 4. References
7.1. Normative References 4.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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://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, BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
February 2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://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,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using "Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <http://www.rfc-editor.org/info/rfc7582>. July 2015, <http://www.rfc-editor.org/info/rfc7582>.
7.2. Informative References 4.2. Informative References
[MVPN-EXTRANET]
Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
Work in Progress, draft-ietf-bess-mvpn-extranet-06,
January 2016.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>. <http://www.rfc-editor.org/info/rfc5015>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point- Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<http://www.rfc-editor.org/info/rfc6388>. <http://www.rfc-editor.org/info/rfc6388>.
[I-D.ietf-bess-mvpn-extranet] Acknowledgements
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs", We would like to thank Eric Rosen for his comments and suggestions
draft-ietf-bess-mvpn-extranet-02 (work in progress), for some text used in the document.
May 2015.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
10 Technology Park Dr. 10 Technology Park Dr.
Westford, MA 01886 Westford, MA 01886
US United States
Email: zzhang@juniper.net Email: zzhang@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
Andrew Dolganow Andrew Dolganow
Alcatel-Lucent Alcatel-Lucent
600 March Rd. 600 March Rd.
Ottawa, ON K2K 2E6 Ottawa, ON K2K 2E6
CANADA Canada
Email: andrew.dolganow@alcatel-lucent.com Email: andrew.dolganow@alcatel-lucent.com
 End of changes. 55 change blocks. 
170 lines changed or deleted 169 lines changed or added

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