BESS Z. Zhang
Internet-Draft R. Kebler
Updates: 6513, 6514 (if approved) W. Lin
Intended status: Standards Track E. Rosen
Expires: January 9, 2017 Juniper Networks
July 8, 2016
MVPN/EVPN C-Multicast Routes Enhancements
draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-00
Abstract
[RFC6513] and [RFC6514] specify procedures for originating,
propagating, and processing "C-multicast routes". However, there are
a number of MVPN use cases that are not properly or optimally handled
by those procedures. This document describes those use cases, and
specifies the additional procedures needed to handle them. Some of
the additional procedures are also applicable to EVPN SMET routes [I-
D.sajassi-bess-evpn-igmp-mld-proxy].
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017.
Zhang, et al. Expires January 9, 2017 [Page 1]
Internet-Draft C-Multicast Enhancements July 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. MVPN C-Bidir Support with VPN Backbone being RPL . . . . 3
1.2.1. C-multicast Routes for the MVPN-RPL Method of C-BIDIR
support . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Optional use of MVPN-RPL RD with mLDP/PIM Provider
Tunnels . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3. MVPN C-ASM Support without CE Routers . . . . . . . . 6
1.3. Inter-AS Propagation of MVPN C-Multicast Routes . . . . . 6
1.4. EVPN Selective Multicast Ethernet Tag (SMET) Routes . . . 8
1.5. Provider Tunnel Segmentation with Explicit-Tracking
C-Multicast Routes . . . . . . . . . . . . . . . . . . . 9
1.5.1. Conventional Tunnel Segmentation . . . . . . . . . . 9
1.5.2. Selective Tunnel Segmentation with Untargeted
Explicit-Tracking C-multicast Routes . . . . . . . . 9
2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. MVPN C-Bidir Support with VPN Backbone being RPL . . . . 10
2.1.1. Constructing C-Multicast Share Tree Join route . . . 10
2.1.2. Setting Up the MVPN-RPL . . . . . . . . . . . . . . . 12
2.2. Inter-AS Propagation of MVPN C-Multicast Routes . . . . . 12
2.2.1. Procedures in Section 11.2 of [RFC6514] . . . . . . . 12
2.2.2. Ordinary BGP Propagation Procedures . . . . . . . . . 13
2.3. Provider Tunnel Segmentation with Explicit-Tracking
C-Multicast Routes . . . . . . . . . . . . . . . . . . . 13
2.3.1. Egress PEs and RBRs . . . . . . . . . . . . . . . . . 14
2.3.2. Transit RBRs . . . . . . . . . . . . . . . . . . . . 15
2.3.3. Ingress RBRs . . . . . . . . . . . . . . . . . . . . 15
2.3.4. Setting Up Forwarding State on RBRs . . . . . . . . . 16
2.3.5. Other Types of Tunnels . . . . . . . . . . . . . . . 16
3. Security Considerations . . . . . . . . . . . . . . . . . . . 16
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
Zhang, et al. Expires January 9, 2017 [Page 2]
Internet-Draft C-Multicast Enhancements July 2016
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Normative References . . . . . . . . . . . . . . . . . . 17
5.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
[RFC6513] and [RFC6514] specify procedures for originating,
propagating, and processing "C-multicast routes". However, there are
a number of MVPN use cases that are not properly or optimally handled
by those procedures. This document describes those use cases, and
specifies the additional procedures needed to handle them.
Some of the additional procedures are also applicable to EVPN SMET
routes [I-D.sajassi-bess-evpn-igmp-mld-proxy]; this is discussed in
Section 1.4.
1.1. Terminology
This document uses terminology from MVPN and EVPN. It is expected
that the audience is familiar with the concepts and procedures
defined in [RFC6513], [RFC6514], [RFC7524], [RFC7432], [I-D.zzhang-
bess-evpn-bum-procedure-updates], and [I-D.sajassi-bess-evpn-igmp-
mld-proxy]. Some terms are listed below for references.
o PMSI: P-Multicast Service Interface - a conceptual interface for a
PE to send customer multicast traffic to all or some PEs in the
same VPN.
o I-PMSI: Inclusive PMSI - to all PEs in the same VPN.
o S-PMSI: Selective PMSI - to some of the PEs in the same VPN.
o C-G-BIDIR: A bidirectional multicast group address (i.e., a group
address whose IP multicast distribution tree is built by BIDIR-
PIM) in customer address space.
o RBR: Regional Border Router. A provider tunnel could be
segmented, with one segment in each region. A region could be an
AS, an IGP area, or even a subarea.
1.2. MVPN C-Bidir Support with VPN Backbone being RPL
In BIDIR-PIM [RFC5015], every group is associated with a "Rendezvous
Point Link" (RPL). The RPL for a given group G is at the root of the
BIDIR-PIM distribution tree. Links of the distribution tree that
lead towards the RPL are considered to be "upstream" links, and links
that lead away from the RPL are considered to be "downstream" links.
Zhang, et al. Expires January 9, 2017 [Page 3]
Internet-Draft C-Multicast Enhancements July 2016
Every node on the distribution tree has one upstream link and zero or
more downstream links.
Data addressed to a BIDIR-PIM group may enter the distribution tree
at any node. The entry node sends the data on the upstream links and
the downstream links. A node that receives the data from a
downstream link sends it on its upstream link and on its other
downstream links. A node that receives the data from its upstream
link sends it on its downstream links. When a node that is attached
to the RPL receives data from a downstream link, it forwards the data
onto the RPL (as well as onto any other downstream links.) When node
attached to the RPL receives data from the RPL, it forwards the data
downstream.
The above is a simplified description, and ignores the fact that
every link except the RPL has a Designated Forwarder (DF). Only the
DF forwards traffic onto the link. However, the RPL has no DF; any
node can forward traffic onto the RPL.
1.2.1. C-multicast Routes for the MVPN-RPL Method of C-BIDIR support
Section 11.1 of [RFC6513] describes a method of providing MVPN
support for customers that use BIDIR-PIM. This is known as "MVPN
C-BIDIR support". In this method of C-BIDIR support, the VPN
backbone itself functions as the RPL. Thus this method is known as
the "MVPN-RPL" method. The RPL is actually an I-PMSI or S-PMSI. The
PE routers treat the I-PMSI or S-PMSI as their upstream link, and
treat their VRF interfaces as downstream links.
If the MVPN-RPL method of C-BIDIR support is being used in a
particlar MVPN, all the PEs attached to that MVPN must be provisioned
to use this method.
In the context of a given VPN, a PE with interest in receiving a
particular C-BIDIR group (call it C-G-BIDIR) advertises this interest
to the other PEs by originating a C-multicast Shared Tree Join route.
When any PE receives traffic for the C-G-BIDIR on its PE-CE
interface, it sends the data to the MVPN-RPL if and only if it has
received corresponding (C-*,C-G-BIDIR) C-multicast Shared Tree Join
route. Other PEs receive the traffic on the MVPN-RPL and forward to
their downstream receviers. However, the procedure for constructing
the C-multicast Shared Tree Join route in this case is not fully
specified in [RFC6513] or [RFC6514]. The proper set of procedures
are specified in Section 2.1.1 of this document.
Compared to other C-Multicast routes specificed in [RFC6514], these
are "untargeted" in that the RT allows all PEs in the same MVPN to
Zhang, et al. Expires January 9, 2017 [Page 4]
Internet-Draft C-Multicast Enhancements July 2016
import them, while those other C-Multicast routes use a RT that
identifies a VRF on a particular Upstream Multicast Hop (UMH) PE.
If a PE wants to use selective tunnel to send traffic to only a
subset of the PEs on MVPN-RPL, i.e., those with downstream
(C-*,C-G-BIDIR) state, per [RFC6513] [RFC6514] the PE needs to
advertise a corresponding (C-*,C-G-BIDIR) S-PMSI A-D route, whose PTA
specifies the tunnel to be used. In case of RSVP-TE P2MP, Ingress
Replication (IR), or BIER tunnel, the Leaf Information Required (LIR)
bit in the S-PMSI route's PTA is set to solicit corresponding Leaf
A-D routes from those PEs with downstream (C-*,C-G-BIDIR) state.
Every PE that wants to use selective tunnel for the (C-*,C-G-BIDIR)
will advertise its own S-PMSI A-D route, each triggering a set of
corresponding Leaf A-D routes.
Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs
all have their own RDs so Route Reflectors (RRs) will reflect every
one of them, and they already serve explicit tracking purpose (the
BGP Next Hop identifies the originator of the route in non-
segmentation case) - there is no need to use Leaf A-D routes
triggered by the LIR bit in S-PMSI A-D routes. In case of RSVP-TE
P2MP tunnel, the S-PMSI A-D routes are still needed to announce the
tunnel but the LIR bit does not need to be set. In case of IR/BIER,
there is no need for S-PMSI A-D routes at all.
1.2.2. Optional use of MVPN-RPL RD with mLDP/PIM Provider Tunnels
When mLDP/PIM tunnels are used, there is no need for explicit
tracking as the leaves will simply send mLDP label Mapping or PIM
Join messages. As a result, it's unnecessary for a PE to retain each
C-Multicast route from each PE for the same C-G-BIDIR. If there is a
Route Reflector (RR) in use, and it is known apriori that all the
PEs/RRs/ASBRs involved in the propagation of the C-Multicast routes
support BGP ADD-PATH [I-D.ietf-idr-add-paths], then the PEs could use
a common RD to contruct the C-Multicast routes. That way, the routes
from different PEs for the same C-G-BIDIR will be considered paths
for the same route and the RRs will reflect N paths to each PE. If N
is significantly smaller than the number of PEs that advertises the
routes, then the burden is significantly reduced for the PEs.
The reason for the need for ADD-PATH is shown with this example: both
PE1 and PE2 advertise the same (C-*,C-G-BIDIR) C-Multicast route and
the RR chooses the one from PE1 as the active path. Without ADD-
PATH, the RR won't reflect any (C-*,C-G-BIDIR) path back to PE1,
causing PE1 to think there is no other PE interested in receiving the
C-G-BIDIR traffic. With ADD-PATH, it is guaranteed that even the
originator of the active path will receive at least one other path.
For this reason, ADD-PATH is needed and N=2 is well enough.
Zhang, et al. Expires January 9, 2017 [Page 5]
Internet-Draft C-Multicast Enhancements July 2016
1.2.3. MVPN C-ASM Support without CE Routers
Current MVPN specifications is based on the fact that CEs are routers
and in case of ASM one or more of the routers in customer address
space, which could be a CE, a PE's VRF, or another non-PE/CE router,
serves as RP. Traffic may be delivered on shared trees, switch to
source specific trees, or switch back to shared trees depending the
situation. There are two modes of MVPN to support ASM, all involving
(C-S,C-G) MVPN Source Active (SA) A-D routes, individial (C-S,C-G)
control/forwarding plane state and procedures that are not needed for
a special scenario where CEs are not routers but just hosts.
From a logical point of view, this special scenario is when a VPN
only involves customer networks directly connected to the PEs and no
customer routers are used.. A practical example is EVPN inter-subnet
multicast [I-D.lin-bess-evpn-irb-mcast], when EVPN is used to connect
only servers and no customer routers are involved. In this case, it
does not make sense to introduce the RP concept into the deployment
and involve the MVPN SA procedures. Rather, this could be modeled as
C-Bidir with MVPN-RPL and all the above discussed optimizations
apply.
1.3. Inter-AS Propagation of MVPN C-Multicast Routes
Section 11.2 of [RFC6514] specifies the procedure used to propagate
C-multicast routes from one AS to another. However, there are a
number of problems with the procedures as specified in that RFC.
RFC6514 presumes that C-multicast routes are propagated through the
ASBRs. This is analogous to RFC 4364's "Inter-AS option b".
However, in some deployment scenarios, the C-multicast routes are
propagated through Route Reflectors, in a manner analogous to RFC
4364's "Inter-AS option c". Strictly speaking, RFC 6514 does not
allow this deployment scenario. This document updates RFC 6514 by
allowing this deployment scenario to be used in place of the
procedures of Section 11.2 of RFC 6514.
In some deployment scenarios, the propagation of C-multicast routes
is controlled by the "Route Target Constraint" procedures of
[RFC4684]. Strictly speaking, RFC 6514 does not allow this
deployment scenario. This document updates RFC 6514 by allowing this
deployment scenario to be used in place of the procedures of
Section 11.2 of RFC 6514.
Per [RFC6514], an MVPN C-Multicast route is targeted at a particular
PE, and its inter-as propagation towards the PE follows a series of
ASBRs (in the reverse order) on the propagation path of one of the
following:
Zhang, et al. Expires January 9, 2017 [Page 6]
Internet-Draft C-Multicast Enhancements July 2016
o The Intra-AS I-PMSI A-D route from the targeted PE, if the
deployment is using non-segmented tunnels. In this scenario, the
IP address of the targeted PE is encoded into the four-octet
"Source AS" field (!) of the C-multicast route's NLRI.
o The Inter-AS I-PMSI A-D route for the AS that the targeted PE is
in, if the deployment is using segmented tunnel. In this
scenario, the AS number of the source PE is encoded into the
"Source AS" field of the C-multicast route's NLRI.
In both cases, the corresponding I-PMSI A-D route is found by looking
for an I-PMSI A-D route whose NLRI consists of the C-multicast
route's RD prepended to the contents of the C-multicast route's
"Source AS" field. If neither Inter-AS nor Intra-AS I-PMSI A-D route
is used, e.g. (C-*,C-*) S-PMSI A-D route is used, then the specified
procedure will not work.
It must be noted that the RFC 6514 Section 11.2 propagation
procedures cannot be applied to untargeted C-multicast routes, and
cannot be applied even to targeted C-multicast routes if the
infrastructure is based on IPv6 rather than IPv4.
This document updates RFC 6514 by declaring that the procedure of
Section 11.2 of that document is only applicable in the case that (1)
the C-multicast routes are being propagated through the ASBRs, AND
(2) the propagation of those routes is not under the control of the
Route Target Constraint procedures. It also updates the procedures
of Section 11.2 of [RFC6514] to allow it to work without relying on
I-PMSI A-D routes, whether IPv4 or IPv6 infrastructure is used.
This document also updates RFC 6514 by declaring that C-multicast
routes MAY be propagated using ordinary BGP propagation procedures,
which do not rely on the presence of I-PMSI A-D routes. For targeted
C-multicast routes, this will result in a less optimal propagation
path, but it does work in all cases. The Route Target Constraint
procedures can always be used to obtain a more optimal path.
The selection of the propagation procedure for C-multicast routes is
determined by provisioning.
In Section 1.2.1, the explicit tracking using C-multicast route
relies on that the route's next hop is not changed so that the next
hop can identify the originator. If the c-multicast routes are
propagated through ASBRs, the next hop will be changed. With tunnel
segmentation, this is not a problem (see Section 1.5) but if non-
segmented tunnels are used, either the C-multicast route propagation
must follow the Optoin C procedures and the next hop is not changed
by the RRs, or the routes must carry an EC to identify the
Zhang, et al. Expires January 9, 2017 [Page 7]
Internet-Draft C-Multicast Enhancements July 2016
originator. Or, the RD of a C-multicast route can be used to locate
an I/S-PMSI route from the same PE, in which the Originator IP
Address can be found.
1.4. EVPN Selective Multicast Ethernet Tag (SMET) Routes
[I-D.sajassi-bess-evpn-igmp-mld-proxy] defines a new EVPN route type
known as an "SMET route".
The EVPN SMET routes are analogous to the MVPN C-muilticast routes,
in that both type of routes are used to disseminate the information
that a particular egress PE has interest in a particular multicast
C-flow or set of C-flows.
An EVPN SMET route contains, in its NLRI, the RD associated with the
VRF from which the SMET route was originated. In addition, it is
disseminated to all PEs of a given EVI. In this way, SMET routes are
analogous to the MVPN C-multicast routes that are used for C-BIDIR
support.
An EVPN SMET route contains, in its NLRI, the IP address of the
originating PE. In this way, they are analogous to the MVPN Leaf A-D
routes (They really combine the function of the MVPN C-multicast
routes and the MVPN Leaf A-D routes). Similarly, they are also
analogous to the C-multicast route for MVPN-RPL that carries an EC
that identifies the originating PE.
In EVPN, as in MVPN, explicit tracking is required when selective
tunnels are realized using IR, BIER, or RSVP-TE P2MP. The EVPN SMET
routes provide this explicit tracking, so in these cases EVPN does
not need explicit Leaf A-D routes. With IR/BIER, there is no need
for S-PMSI route either. However, when SMET routes are used with
segmented IR/BIER tunnels, more procedures are needed, just like the
C-multicast route in MVPN-RPL case (Section 1.5). For that reason,
given the similarity between SMET and C-Multicast routes, in this
document we will use the same term C-Multicast route for EVPN SMET
route as well. The two may be used interchably in case of EVPN.
If selective tunnels are set up using procedures that do not require
explicit tracking, e.g. mLDP or PIM, the following optimization could
be done, similar to MVPN-RPL with mLDP/PIM tunnels (Section 1.2.2):
o When constructing an SMET route, put 0 as the Originator Router
Address.
o When constructing an SMET route in the context of a given EVI,
have all PEs of that EVI set the RD field of the NLRI to the same
Zhang, et al. Expires January 9, 2017 [Page 8]
Internet-Draft C-Multicast Enhancements July 2016
value (This is analogous to "MVPN-RPL RD" discussed in
Section 1.2.2).
o When a Route Reflector distributes the SMET routes, it uses BGP
ADD-PATH to distribute at least two "paths" for a given NLRI.
1.5. Provider Tunnel Segmentation with Explicit-Tracking C-Multicast
Routes
For the above MVPN-RPL and EVPN cases where C-multicast routes are
used for explicit tracking without requiring corresponding S-PMSI A-D
routes in case of IR/BIER selective tunnel, it works well when there
is no tunnel segmentation. With tunnel segmentation [RFC6514]
[RFC7524], [I-D.zzhang-bess-evpn-bum-procedure-updates] additional
procedures are needed.
1.5.1. Conventional Tunnel Segmentation
Multicast forwarding needs to follow a rooted tree. With
segmentation, the tree is devided into segments, with each segment
rooted at either the ingress PE or a Regional Border Router (RBR). A
segment is contained in a region, which could be an AS, an area, or a
sub-area. The root of a segment only needs to track the leaves in
its region, which are PEs or RBRs in that region. With the
traditional PMSI/Leaf A-D procedures, an ingress PE/RBR sends out an
I/S-PMSI route, propagated by RBRs (segmentation points), who change
the tunnel identifier along the way to identify the tunnels for their
segments. The Leaf A-D routes from PEs are not propagated by the
RBRs. Rather, a RBR will proxy the Leaf AD routes it receives from
its downstream towards its upstream RBR or PE, following the I/S-PMSI
A-D routes received in the upstream region, as specified in [RFC6514]
[RFC7524] [I-D.zzhang-bess-evpn-bum-procedure-updates].
1.5.2. Selective Tunnel Segmentation with Untargeted Explicit-Tracking
C-multicast Routes
Without segmentation, the untargeted explicit-tracking C-Multicast
routes are sent to every PE, and each PE adds the originator of the
routes as leaves of the tunnel rooted at the PE.
With segmentation, untargeted explicit-tracking C-Multicast routes
are propagated throught segmentation points towards all ingress PEs
or ASes and are merged along the way. This is like the traditional
PMSI/Leaf A-D procedures but with one difference.
With the traditional PMSI/Leaf A-D procedures, the propagation is
towards the originator of the PMSI A-D route and a single tree is
formed. With untargeted C-Multicast routes, multiple trees are
Zhang, et al. Expires January 9, 2017 [Page 9]
Internet-Draft C-Multicast Enhancements July 2016
formed, each being rooted at the ingress PE (if per-region
aggregation [I-D.zzhang-bess-evpn-bum-procedure-updates] is not used)
or ingress RBR (if per-region aggregation is used). The roots of
those trees are either the ingress PEs or the ingress RBRs,
identified by all the per-PE or per-region I-PMSI A-D routes.
To form those multiple trees without requiring S-PMSI A-D routes from
the ingress PEs/RBRs, this document proposes that the RBRs convert a
C-multicast route originated in its own region to Leaf A-D routes, as
if corresponding S-PMSI A-D routes had been received from ingress
PEs/RBRs. The details are provided in Section 2.2.
2. Specifications
This section provides detailed specifications for the optional
enhancements introduced above.
2.1. MVPN C-Bidir Support with VPN Backbone being RPL
2.1.1. Constructing C-Multicast Share Tree Join route
In the context of a particular VRF, a PE with downstream state for
the group C-G-BIDIR originates a C-multicast Shared Tree Join route,
referred to as "MVPN-RPL C-multicast Join", when the MVPN-RPL method
of C-BIDIR support is being used.
The fields of the route are set as follows:
o RD: See Section 2.1.1.2.
o Source AS: set to zero.
o Multicast Source Length: 4 or 16.
o Multicast Source: set to RPA.
o Multicast Group Length: 4 or 16.
o Multicast Group: BIDIR-PIM group address.
Note that the RD field, and the Route Targets that are attached to
the C-multicast route are different than what is specified in
[RFC6514]. See following two sections.
Zhang, et al. Expires January 9, 2017 [Page 10]
Internet-Draft C-Multicast Enhancements July 2016
2.1.1.1. Setting the Route Targets
Per [RFC6514], when a PE originates a C-multicast route, it "targets"
the route to a specific one of the other PEs attached to the same
VPN. The IP address of the targeted PE is encoded into a Route
Target and attached to the C-mulitcast route. This ensures that the
C-multicast route is processed only by the PE to which it is
targeted.
However, C-multicast routes used by the MVPN-RPL method are not
targeted. Rather, they must be processed by all the other PEs
attached to the same MVPN. Thus we refer to these routes as
"untargeted". The Route Targets attached to these routes must be
such as to cause the routes to be propagated to all the other PEs of
the given MVPN. By default, these will be the same Route Targets
that are attached to the I-PMSI A-D routes of the MVPN.
2.1.1.2. Setting the Route Distinguisher
Per [RFC6514], the RD in a C-multicast Join Route is the RD of a VRF
on the PE to which the route is targeted. However, in an MVPN-RPL
C-multicast Join, the RD is set differently.
If PIM/mLDP provider tunnels are used, and it is known that all the
PEs/RRs/ASBRs involved in the propagation of C-multicast routes
support BGP ADD-PATH, the RD MAY be set to a value that is specially
configured to be used as the RD for MVPN-RPL in a given VPN. Call
this the "MVPN-RPL" RD for that VPN. In that case, all the
C-multicast Joins that are providing C-BIDIR support (for a given
VPN) using the MVPN-RPL method will have the same RD. This MVPN-RPL
RD of a given VPN MUST NOT be used for any other purpose, or by any
other VPN. See Section 1.2.2 for a discussion of when it may be
advantageous to use an MVPN-RPL RD.
For other provider tunnel types, or if the above mentioned MVPN-RPL
RD in case of PIM/mLDP tunnel is not feasible (e.g. BGP ADD-PATH is
not supported), the RD in the C-multicast route is that of the VRF
from which the route is originated.
For Global Table Multicast (GTM) using MVPN procedures [RFC7116], RFC
7116 specifies that MVPN routes use a special 0:0 RD. This document
specifies that GTM use non-0:0 RDs for C-Multicast routes for
C-Bidir, when the backbone is used as RPL and provider tunnels are
not set up by PIM/mLDP.
Zhang, et al. Expires January 9, 2017 [Page 11]
Internet-Draft C-Multicast Enhancements July 2016
2.1.2. Setting Up the MVPN-RPL
By default, the I-PMSI or (C-*,C-BIDIR) S-PMSI plays the role of
MVPN-RPL. When (C-*,C-G-BIDIR) S-PMSI is used for a particular
C-G-BIDIR, the following procedures are followed, depending on the
type of provider tunnel used.
2.1.2.1. Ingress Replication or BIER
If Ingress Replication or BIER is used, there is no need for the
ingress PE to advertise (C-*,C-G-BIDIR) S-PMSI A-D route. The
ingress PE identifies the tunnel leaves to send traffic to by the
C-multicast routes it receives, because each such route has a
different RD and serves explicit tracking purpose. In case of IR,
the label in the Intra-AS I-PMSI A-D route or (C-*,C-*) S-PMSI A-D
route from a leaf is used to send traffic to the leaf. In case of
BIER, the label in the same route from the ingress PE is used to send
traffic.
2.1.2.2. RSVP-TE P2MP
With RSVP-TE P2MP tunnel, the ingress PE advertises (C-*,C-G-BIDIR)
S-PMSI A-D route without setting the LIR bit in the route's PTA. It
identifies the tunnel leaves from the C-multicast routes it receives.
2.1.2.3. PIM/mLDP
With PIM or mLDP P2MP provider tunnel, procedures in [RFC6514] are
followed.
2.2. Inter-AS Propagation of MVPN C-Multicast Routes
This specification allows two methods of Inter-AS propagation for
MVPN C-multicast routes. The choice of which method is used is by
provisioning.
2.2.1. Procedures in Section 11.2 of [RFC6514]
The procedures in Section 11.2 of [RFC6514] are extended with the
following.
The Source AS field in the NLRI of C-multicast route is set to the AS
number of the UMH PE if and only if segmented inter-AS tunnels and
per-AS aggregation (via Inter-AS I-PMSI A-D routes) are used. The
existing procedures are used as is in this case.
Otherwise, when an egress PE constructs a C-Multicast route and the
upstream PE is in a different AS from the local PE, it finds in its
Zhang, et al. Expires January 9, 2017 [Page 12]
Internet-Draft C-Multicast Enhancements July 2016
VRF an Intra-AS I-PMSI A-D route or any S-PMSI A-D route from the
upstream PE (the Originating Router's IP Address field of that route
has the same value as the one carried in the VRF Route Import of the
(unicast) route to the address carried in the Multicast Source
field). The RD of the found I/S-PMSI A-D route is used as the RD of
the advertised C-multicast route. The Source AS field in the
C-multicast route is set to 0. If the Next Hop of the found I/S-PMSI
A-D route is an EBGP neighbor of the local PE, then the PE advertises
the C- multicast route to that neighbor. Otherwise the PE advertises
the C-multicast route into IBGP.
When an ASBR receives a C-multicast route with the Source AS field
set to 0, it uses the RD of the C-multicast route to locate an Intra-
AS I-PMSI A-D route or any S-PMSI A-D route, and propagate the
C-multicast route to the bgp neighbor from which the found I/S-PMSI
A-D route is learned.
2.2.2. Ordinary BGP Propagation Procedures
This document specifies that C-multicast routes MAY be propagated
using ordinary BGP propagation procedures, which do not rely on the
presence of any I/S-PMSI A-D routes. With this method, the Source AS
field in the C-Multicast route SHOULD be set to 0. For targeted
C-multicast routes, this will result in a less optimal propagation
path, but it does work in all cases. The Route Target Constraint
procedures can always be used to obtain a more optimal path.
2.3. Provider Tunnel Segmentation with Explicit-Tracking C-Multicast
Routes
This section applies when IR/BIER are used for MVPN/EVPN selective
tunnels.
If per-region aggregation
[I-D.zzhang-bess-evpn-bum-procedure-updates] is used, this document
specifies that the per-region I-PMSI A-D route MUST carry a VRF Route
Import EC to identif the originator of the per-region I-PMSI A-D
route. Note that, while it borrows "VRF Route Import EC" from the
UMH routes, it is only used to identify the originator.
If per-region aggregation is not used, this document specifies that
either per-PE I-PMSI or (C-*,C-*) S-PMSI A-D routes MUST be
originated by every PE.
Zhang, et al. Expires January 9, 2017 [Page 13]
Internet-Draft C-Multicast Enhancements July 2016
2.3.1. Egress PEs and RBRs
An egress PE originates MVPN C-multicast routes for MVPN-RPL as
specified in previous sections of this document, or EVPN SMET routes
as specified in [I-D.sajassi-bess-evpn-igmp-mld-proxy]. Recall that
EVPN SMET routes may also be referred to C-Multicast routes in this
document.
Explicit-tracking C-multicast routes must be processed by
segmentation points, which are referred to as RBRs. When a RBR
receives a C-multicast route from within its own region, and the
route does not carry a flag bit that indicates the route is converted
from a downstream Leaf A-D route (see descriptions below), it
converts the C-multicat route into one or more Leaf A-D routes, as if
it had received corresponding S-PMSI A-D routes. When a converted
Leaf A-D routes reaches the ingress region, the RBR converts it back
to C-multicast routes.
With per-region aggregation, the RBR in an egress region finds all
active per-region I-PMSI A-D route that the RBR has in the
corresponding VRF. For each of them, it makes up a (C-S,C-G) or
(C-*,C-G) S-PMSI A-D route as following.
o RD: set to the RD from the per-region I-PMSI A-D route.
o Source/Group length/address fields: set according to the received
C-multicast route.
o Originator's IP Address: set according to the VRF Route Import EC
in the per-region I-PMSI A-D route
o Ethernet Tag ID in case of EVPN: set according to the received
SMET route (which is also referred to as C-multicast route).
o Next Hop: set according to the per-region I-PMSI A-D route.
Without per-region aggregation, a RBR finds all active per-PE I-PMSI
or (C-*,C-*) S-PMSI A-D route in the VRF. For each of them it makes
up a (C-S,C-G) or (C-*,C-G) S-PMSI A-D route similar to the per-
region aggregation case. The only difference is that the
Originator's IP Address field is set to the same as in the per-PE
I-PMSI or (C-*,C-*) S-PMSI A-D route.
The made up S-PMSI A-D route is for local use only, and not
propagated anywhere. A corresponding Leaf A-D route is then
generated and propagated to the upstream identified by the BGP next
hop in the made up S-PMSI A-D route, following existing PMSI/Leaf A-D
route procedures.
Zhang, et al. Expires January 9, 2017 [Page 14]
Internet-Draft C-Multicast Enhancements July 2016
2.3.2. Transit RBRs
When an upstream RBR receives a (C-S,C-G) or (C-*,C-G) Leaf A-D
route, It locates the active per-PE/region I-PMSI or (C-*,C-*) S-PMSI
A-D route whose RD matches the received Leaf A-D route. If no such
route exists, the received Leaf A-D route is ignored until such a
route appears later. It also tries to locate a corresponding active
(C-S,C-G) or (C-*,C-G) S-PMSI A-D route, which could be a real one
received from an upstream PE/RBR, or could be a made up one triggered
by a Leaf A-D route from a different downstream. If such route
exists, existing PMSI/Leaf A-D route procedures are followed.
If no such corresponding active (C-S,C-G) or (C-*,C-G) S-PMSI A-D
route exists, and the located active I-PMSI or (C-*,C-*) S-PMSI A-D
route has a next hop different from the Originator IP Address in the
per-PE I-PMSI A-D route or (C-*,C-*) I-PMSI A-D route, or different
from the address in the VRF Route Import EC in the per-region I-PMSI
A-D route, the ingress region corresponding to the I-PMSI or
(C-*,C-*) S-PMSI A-D route has not been reached. The RBR then makes
up a (C-S,C-G) or (C-*,C-G) S-PMSI A-D route. as specified earlier,
and proxies Leaf A-D routes further up.
2.3.3. Ingress RBRs
If the BGP next hop in the located active I-PMSI or (C-*,C-*) S-PMSI
A-D route matches the Originator IP Address in the per-PE I/S-PMSI
A-D route or the IP address in the per-region I-PMSI A-D route's VRF
Route Import EC, it means the ingress region has been reached. If
the corresponding (C-S,C-G) or (C-*,C-G) S-PMSI A-D route is a made
up one and not actually advertised by an ingress PE/RBR, the RBR
reconverts the Leaf A-D route back to C-multicast route, with a CV
("Converted") flag bit indicating that the route is not from local
state learned on PE-CE interface but from state learned further
downstream. The flag bit prevents other RBRs in this region to
trigger Leaf A-D routes from this converted C-multicast route.
The converted C-multicast route is constructed as following:
o RD: set to the RD of the RBR for the related IP/MAC VRF.
o Source/Group length/address fields: set according to the received
Leaf A-D route.
o Ethernet Tag ID in case of EVPN: set according to the received
Leaf A-D route.
o Next Hop: set to the RBR's local IP Address.
Zhang, et al. Expires January 9, 2017 [Page 15]
Internet-Draft C-Multicast Enhancements July 2016
The RT of the converted C-multicast route is set to the RT used for
VRF but the route is only propagated to PEs/RBRs in the local region.
For EVPN SMET routes, the flag bit is part of the existing Flags
field in the NLRI:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|reserved|CV|IE|v3|v2|v1|
+--+--+--+--+--+--+--+--+
The IE/v3/v2/v1 are existing bits and the CV bit is the new bit to
indicate that this is converted from state learned from downstream.
For MVPN C-Multicast route, the CV bit is part of a new MVPN Flag EC,
to be specified in a future revision.
2.3.4. Setting Up Forwarding State on RBRs
As a RBR follows the PMSI/Leaf A-D route procedures (even though the
S-PMSI A-D route may be made up and not real), it sets up forwarding
state accordingly [I-D.ietf-bess-ir] [I-D.ietf-bier-mvpn]. If IR is
used in the upstream region, a downstream allocated label is
advertised in the PTA of the Leaf A-D route sent upstream. If BIER
is used in a region, the root RBR for the segment in that region MUST
advertise an S-PMSI A-D route, whether the route is actually received
from upstream or made up based on received C-multicast route or Leaf
A-D route, with the PTA's label field set to a label upstream-
allocated by the root RBR of the segment. This allows label
switching by the RBR instead of relying on (C-S,C-G) lookup based
forwarding in the VRF.
2.3.5. Other Types of Tunnels
The inter-region segmented tunnel can consists of different types of
tunnels, like PIM/mLDP/RSVP-TE P2MP tunnels that require advertised
S-PMSI A-D routes. This is just like BIER case mentioned in the
above section. The only difference is that in BIER case it is the
upstream allocated label that needs to be advertised by the S-PMSI
A-D routes and in PIM/mLDP/RSVP-TE P2MP case it is the tunnel
identity and optionaly the upstream allocated label that need to be
advertised by the S-PMSI A-D routes.
3. Security Considerations
This document does not seem to introduce new security risks, though
this may be revised after further review and scrutiny.
Zhang, et al. Expires January 9, 2017 [Page 16]
Internet-Draft C-Multicast Enhancements July 2016
4. Acknowledgements
The authors thank Vinay Nallamothu and Kevin Wang for their comments
and suggestions.
5. References
5.1. Normative References
[I-D.ietf-bess-ir]
Rosen, E., Subramanian, K., and Z. Zhang, "Ingress
Replication Tunnels in Multicast VPN", draft-ietf-bess-
ir-03 (work in progress), April 2016.
[I-D.ietf-bier-mvpn]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", draft-ietf-bier-
mvpn-03 (work in progress), June 2016.
[I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-15 (work in progress), May 2016.
[I-D.sajassi-bess-evpn-igmp-mld-proxy]
Sajassi, A., Patel, K., Thoria, S., Yeung, D., Drake, J.,
and W. Lin, "IGMP and MLD Proxy for EVPN", draft-sajassi-
bess-evpn-igmp-mld-proxy-00 (work in progress), October
2015.
[I-D.zzhang-bess-evpn-bum-procedure-updates]
Zhang, Z., Lin, W., Rabadan, J., and K. Patel, "Updates on
EVPN BUM Procedures", draft-zzhang-bess-evpn-bum-
procedure-updates-03 (work in progress), April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>.
Zhang, et al. Expires January 9, 2017 [Page 17]
Internet-Draft C-Multicast Enhancements July 2016
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission
Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
and Bundle Protocol IANA Registries", RFC 7116,
DOI 10.17487/RFC7116, February 2014,
<http://www.rfc-editor.org/info/rfc7116>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>.
5.2. Informative References
[I-D.lin-bess-evpn-irb-mcast]
Lin, W., Zhang, Z., Drake, J., and J. Rabadan, "EVPN
Inter-subnet Multicast Forwarding", draft-lin-bess-evpn-
irb-mcast-02 (work in progress), March 2016.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
EMail: zzhang@juniper.net
Robert Kebler
Juniper Networks
EMail: rkebler@juniper.net
Zhang, et al. Expires January 9, 2017 [Page 18]
Internet-Draft C-Multicast Enhancements July 2016
Wen Lin
Juniper Networks
EMail: wlin@juniper.net
Eric Rosen
Juniper Networks
EMail: erosen@juniper.net
Zhang, et al. Expires January 9, 2017 [Page 19]