BESS Workgroup J. Rabadan, Ed.
Internet Draft J. Kotalwar
Intended status: Standards Track S. Sathappan
Nokia
Z. Zhang
Juniper
A. Sajassi
Cisco
Expires: January 4, 2018 July 3, 2017
PIM Proxy in EVPN Networks
draft-skr-bess-evpn-pim-proxy-00
Abstract
Ethernet Virtual Private Networks [RFC7432] are becoming prevalent in
Data Centers, Data Center Interconnect (DCI) and Service Provider VPN
applications. One of the goals that EVPN pursues is the reduction of
flooding and the efficiency of CE-based control plane procedures in
Broadcast Domains. Examples of this are [EVPN-PROXY-ARP-ND] for
improving the efficiency of CE's ARP/ND protocols, and [EVPN-IGMP-
MLD-PROXY] for IGMP/MLD protocols. This document complements the
latter, describing the procedures required to minimize the flooding
of PIM messages in EVPN Broadcast Domains, and optimize the IP
Multicast delivery between PIM routers.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 1]
Internet-Draft EVPN PIM Proxy July 3, 2017
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 4, 2018.
Copyright Notice
Copyright (c) 2017 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
2. PIM Proxy Operation in EVPN Broadcast Domains . . . . . . . . . 4
2.1. Multicast Router Discovery Procedures in EVPN . . . . . . . 5
2.1.1. Discovering PIM Routers . . . . . . . . . . . . . . . . 5
2.1.2. Discovering IGMP Queriers . . . . . . . . . . . . . . . 7
2.2. PIM Join/Prune Proxy Procedures . . . . . . . . . . . . . . 7
2.3. PIM Assert Optimization . . . . . . . . . . . . . . . . . . 10
2.3.1 Assert Optimization Procedures in Downstream PEs . . . . 11
2.3.2 Assert Optimization Procedures in Upstream PEs . . . . . 12
2.4. EVPN Multi-Homing and State Synchronization . . . . . . . . 12
2.5. PIM Bootstrap and RP Discovery . . . . . . . . . . . . . . 13
2.6. PIM-DM (Dense Mode) Proxy Procedures . . . . . . . . . . . 13
3. Interaction with IGMP-snooping and Sources . . . . . . . . . . 13
4. BGP Information Model . . . . . . . . . . . . . . . . . . . . . 14
4.1 Multicast Router Discovery (MRD) Route . . . . . . . . . . . 15
4.2 Selective Multicast Ethernet Tag Route for PIM Proxy . . . . 16
4.3 PIM RPT-Prune Route . . . . . . . . . . . . . . . . . . . . 18
4.4 IGMP/PIM Join Synch Route for PIM Proxy . . . . . . . . . . 19
4.5 IGMP/PIM RPT-Prune Synch Route for PIM Proxy . . . . . . . . 20
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Conventions used in this document . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
9. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 2]
Internet-Draft EVPN PIM Proxy July 3, 2017
10.1 Normative References . . . . . . . . . . . . . . . . . . . 22
10.2 Informative References . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
Ethernet Virtual Private Networks [RFC7432] are becoming prevalent in
Data Centers, Data Center Interconnect (DCI) and Service Provider VPN
applications. One of the goals that EVPN pursues is the reduction of
flooding and the efficiency of CE-based control plane procedures in
Broadcast Domains. Examples of this are [EVPN-PROXY-ARP-ND] for
improving the efficiency of CE's ARP/ND protocols, and [EVPN-IGMP-
MLD-PROXY] for IGMP/MLD protocols.
This document focuses on optimizing the behavior of PIM in EVPN
Broadcast Domains and re-uses some procedures of [EVPN-IGMP-MLD-
PROXY]. The reader is also advised to check out [VPLS-PIM-PROXY] to
understand certain aspects of the procedures of PIM Join/Prune
messages received on Attachment Circuits (ACs).
Section 2 describes the PIM Proxy procedures that the implementation
should follow, including:
o The use of EVPN to suppress the flooding of PIM Hello messages in
shared Broadcast Domains. The benefit of this is twofold:
- PIM Hello messages will be ONLY flooded to Attachment Circuits
that are connected to PIM routers, as opposed to all the CEs and
hosts in the Broadcast Domain.
- Soft-state PIM Hello messages will be replaced by hard-state BGP
messages that don't need to be refreshed periodically.
o The use of EVPN to discover IGMP Queriers, while avoiding the
flooding of IGMP Queries in the core.
o The procedures to proxy PIM Join/Prune messages and replace them by
hard-state EVPN routes that don't need to be refreshed
periodically. By using BGP EVPN to propagate both, Hello and
Join/Prune messages, we also avoid out-of-order delivery between
both types of PIM messages.
o This document also describes an EVPN based procedure so that the
PIM routers connected to the shared Broadcast Domain don't need to
run any PIM Assert procedure. PIM Assert procedures may be
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 3]
Internet-Draft EVPN PIM Proxy July 3, 2017
expensive for PIM routers in terms of resource consumption. With
this procedure, there is no PIM Assert needed on PIM routers.
o The use of procedures similar to the ones defined in [EVPN-IGMP-
MLD-PROXY] to synchronize multicast states among the PEs in the
same Ethernet Segment.
Section 3 describes the interaction of PIM Proxy with IGMP Proxy PEs
and Multicast Sources connected to the same EVPN Broadcast Domain.
Section 4 defines the BGP Information Model that this document
requires to address the PIM Proxy procedures.
This document assumes the reader is familiar with PIM and IGMP
protocols.
2. PIM Proxy Operation in EVPN Broadcast Domains
This section describes the operation of PIM Proxy in EVPN Broadcast
Domains (BDs). Figure 1 depicts an EVPN Broadcast Domain defined in
four PEs that are connected to PIM routers. This example will be used
throughout this section and assumes both R4 and R5 are PIM Upstream
Neighbors for PIM routers R1, R2 and R3 and multicast group G1. In
this situation, the PIM multicast traffic flows from R4 or R5 to R1,
R2 and R3. The PIM Join/Prune signaling will flow in the opposite
direction. From a terminology perspective, we consider PE1 and PE2 as
egress or downstream PEs, whereas PE3 and PE4 are ingress or upstream
PEs.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 4]
Internet-Draft EVPN PIM Proxy July 3, 2017
J(*,G1,IP5)
+--+
|R1+------> XXXXXXXX
+--+ +-----+ XXXX XX XXXXX +-----+ +--+
| PE1 |XXXXX XXXX XX| PE3 +----> |R4|
+--+ | | | | +--+
|R2+-----> +-----+ +-----+ <----
+--+ X XX multicast
J(*,G1,IP5) X XXX (S1,G1)
XXX EVPN Broadcast XX
X Domain X
+--+ +-----+ X RP
|R3+---> | PE2 | XX+-----+ +--+
+--+ | | XXXX | PE4 +--> |R5|
+-----+XXXX XXXXX | | +--+
J(S1,G1,IP4) X X X +-----+
XX XXX XX XXX
XXXXXX XXXXX XXX
Figure 1 - PIM Routers connected by an EVPN Broadcast Domain
It is important to note that any Router's PIM message not explicitly
specified in this document will be forwarded by the PEs normally, in
the data path, as a unicast or multicast packet.
2.1. Multicast Router Discovery Procedures in EVPN
The procedures defined in this section make use of the Multicast
Router Discovery (MRD) route described in section 4 and are OPTIONAL.
An EVPN router not implementing this specification will transparently
flood PIM Hello messages and IGMP Queries to remote PEs.
2.1.1. Discovering PIM Routers
As described in [RFC4601] for shared LANs, an EVPN Broadcast Domain
may have multiple PIM routers connected to it and a single one of
these routers, the DR, will act on behalf of directly connected hosts
with respect to the PIM-SM protocol. The DR election, as well as
discovery and negotiation of options in PIM, is performed using Hello
messages. PIM Hello messages are periodically exchanged and flooded
in EVPN Broadcast Domains that don't follow this specification.
When PIM Proxy is enabled, an EVPN PE will snoop PIM Hello messages
and forward them only to local ACs where PIM routers have been
detected. This document assumes that all the procedures defined in
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 5]
Internet-Draft EVPN PIM Proxy July 3, 2017
[VPLS-PIM-PROXY] to snoop PIM Hellos on local ACs and build the PIM
Neighbor DB on the PEs are followed. PIM Hello messages MUST NOT be
forwarded to remote EVPN PEs though.
Using Figure 1 as an example, the PIM Proxy operation for Hello
messages is as follows:
1) The arrival of a new PIM Hello message at e.g. PE1 will trigger an
MRD route advertisement including:
o The IP address and length of the multicast router that issued
the Hello message. E.g. R1's IP address and length.
o The DR Priority copied from the Hello DR Priority TLV.
o Q flag set (if the multicast router is a Querier).
o P flag set that indicates the router is PIM capable.
2) All other PEs import the MRD route and do the following:
o Add the multicast router address to the PIM Neighbor Database
(PIM Nbr DB) associated to the Originator Router Address.
o Generate a PIM hello where the IP Source Address is the
Multicast Router IP and the DR Priority is copied from the
route. This PIM hello is sent to all the local ACs connected to
a PIM router. For example, PE3 will send the generated hello
message to R4.
3) Each PE will build its PIM Nbr DB out of the local PIM hello
messages and/or remote MRD routes. The PIM hello timers and other
hello parameters are not propagated in the MRD routes.
o The timers are handled locally by the PE and as per [RFC4601].
This is valid for the hold_time (when a PIM router or PE
receives a hello message, resets the neighbor-expiry timer), and
other timers.
o The Generation ID option is also processed locally on the PE, as
well as the Generation ID changes for a given multicast router.
It is not propagated in the MRD route.
o Procedures described in [RFC4601] are used to remove a local AC
PIM router from the PIM Nbr DB. When a local router is removed
from the DB, the MRD route is withdrawn. If the local router is
still sending Queries, the route is updated with flags P=0 and
Q=1. Upon receiving the update, the other PEs will remove the
router from the PIM Nbr DB but not from the list of queriers.
4) Based on regular PIM DR election procedures (highest DR Priority
or highest IP), each PE is aware of who the DR is for the BD. For
more information, refer to section "3. Interaction with IGMP-
snooping and Sources".
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 6]
Internet-Draft EVPN PIM Proxy July 3, 2017
2.1.2. Discovering IGMP Queriers
In (EVPN) Broadcast Domains that are shared among not only PIM
routers but also IGMP hosts, one or more PIM routers will also be
configured as IGMP Queriers. The proxy Querier mechanism described in
[EVPN-IGMP-MLD-PROXY] suppresses the flooding of queries on the
Broadcast Domain, by using PE generated Queries from an anycast IP
address.
While the proxy Querier mechanism works in most of the use-cases,
sometimes it is desired to have a more transparent behavior and
propagate existing multicast router IGMP Queries as opposed to
"blindly" querying all the hosts from the PEs. The MRD route defined
in section 4 can be used for that purpose.
When the discovered local PIM router is also sending IGMP Queries,
the PE will issue an MRD route for the multicast router with both Q
(IGMP Querier) and P (PIM router) flags set. Note that the PE may set
both flags or only one of them, depending on the capabilities of the
local router.
A PE receiving an MRD route with Q=1 will generate IGMP Query
messages, using the multicast router IP address encoded in the
received MRD route. If more than one IGMP Queriers exist in the EVI,
the PE receiving the MRD routes with Q=1 will select the lower IP
address, as per [RFC2236]. Note that, upon receiving the MRD routes
with Q=1, the PE must generate IGMP Queries and forward them to all
the local ACs. Other Queriers listening to these received Query
messages will stop sending Queries if they are no longer the selected
Querier, as per [RFC2236].
This procedure allows the EVPN PEs to act as proxy Queriers, but
using the IP address of the best existing IGMP Querier in the EVPN
Broadcast Domain. This can help IGMP hosts troubleshoot any issues on
the IGMP routers and check their connectivity to them.
2.2. PIM Join/Prune Proxy Procedures
This section describes the procedures associated to the PIM Proxy
function for Join and Prune messages. This document assumes that all
the procedures defined in [VPLS-PIM-PROXY] to build multicast states
on the PEs' local ACs are followed. Figure 2 illustrates an scenario
where PIM Proxy is enabled on the EVPN PEs.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 7]
Internet-Draft EVPN PIM Proxy July 3, 2017
J(*,G1,IP5)
+--+ J(*,G1,IP5)
|R1+------> XXXXXXXX P(S1,G1,IP5,rpt)
+--+ +-----+ XXXX XX XXXXX +-----+ +--+
| PE1 |XXXXX XXXX XX| PE3 +----> |R4|
+--+ | | SMET | | +--+
|R2+-----> +-----+ (*,G1,IP5) +-----+
+--+ X +---------> XX
J(*,G1,IP5) X XXX
XX XX
X X J(*,G1,IP5)
+--+ +-----+ SMET X P(S1,G1,IP5,rpt)
|R3+---> | PE2 | (S1,G1,IP5,rpt) XX+-----+ +--+
+--+ | | +--------> XXXX | PE4 +--> |R5|
+-----+XXXX XXXXX | | +--+
P(S1,G1,IP5,rpt) X X X +-----+ RP
XX XXX XX XXX
XXXXXX XXXXX XXX
Figure 2 - Proxy PIM Join/Prune in EVPN
PIM J/P messages are sent by the routers towards upstream sources and
RPs:
o (*,G) is used in Join/Prune messages that are sent towards the RP
for the specified group.
o (S,G) used in Join/Prune messages sent towards the specified
source.
o (S,G,rpt) is used in Join/Prune messages sent towards the RP. We
refer to this as RPT message and the Prune message always precedes
the Join message. The typical sequence of PIM messages (for a
group) seen in a BD connecting PIM routers is the following:
a) (*,G) Join issued by a downstream router to the RP (to join the
RP Tree).
b) (S,G) Join issued by a downstream router switching to the SPT.
c) (S,G,rpt) Prune issued by a downstream router to the RP to prune
a specific source from the RPT.
d) (S,G) Prune issued by a downstream router no longer interested
in the SPT.
e) (S,G,rpt) Join issued by a downstream router interested (again)
in the RPT for (S,G).
The Proxy PIM procedures for Join/Prune messages are summarized as
follows:
1) Downstream PE procedures:
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 8]
Internet-Draft EVPN PIM Proxy July 3, 2017
o A downstream PE will snoop PIM Join/Prune messages and won't
forward them to remote PEs.
o Triggered by the reception of the PIM Join message, a downstream
PE will advertise an SMET route, including the source, group and
Upstream Neighbor as received from the PIM Join message. A
single SMET route is advertised per source, group, with the P
flag set. As an example, in Figure 2, PE1 receives two PIM Join
messages for the same source, group and Upstream Neighbor,
however PE1 advertises a single SMET route.
o When the last connected router sends a PIM Prune message for a
given source, group and Upstream Neighbor and the state is
removed, the PE will withdraw the SMET route (note that the
state is removed once the prune-pend timer expires).
o SMET routes must always be generated upon receiving a PIM Join
message, irrespective of the location of the Upstream Neighbor
and even if the Upstream Neighbor is local to the PE.
o A downstream PE receiving a PIM Prune (S,G,rpt) message will
trigger an RPT-Prune route for the source and group.
Subsequently, if the downstream PE receives a PIM Join (S,G,rpt)
to cancel the previous Prune (S,G,rpt) and keep pulling the
multicast traffic from the RPT, the downstream PE will withdraw
the RPT-Prune route.
o PIM Timers are handled locally. If the holdtime expires for a
local Join the PE withdraws the SMET route.
3) Upstream PE procedures:
o A received SMET route with P=1 will add state for the source and
group and will generate a PIM Join message for the source, group
that will be forwarded to all the local AC PIM routers.
o A received SMET route withdrawal will remove the state and
generate a PIM Prune message for the source, group and upstream
neighbor that will be forwarded to all the local AC PIM routers.
o A received RPT-Prune route for (S,G) will generate a PIM Prune
(S,G,rpt) message that will be forwarded to all the local AC PIM
routers.
o A received RPT-Prune withdrawal for (S,G) will generate a PIM
Join (S,G,rpt) message that will be forwarded to all the local
AC PIM routers.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 9]
Internet-Draft EVPN PIM Proxy July 3, 2017
It is important to note that, compared to a solution that does not
snoop PIM messages and does not use BGP to propagate states in the
core, this EVPN PIM Proxy solution will add some latency derived from
the procedures described in this document.
2.3. PIM Assert Optimization
The PIM Assert process described in [RFC4601] is intense in terms of
resource consumption in the PIM routers, however it is needed in case
PIM routers share a multi-access transit LAN. The use of PIM Proxy
for EVPN BDs can minimize and even suppress the need for PIM Assert
as described in this section.
As a refresher, the PIM Assert procedures are needed to prevent two
or more Upstream PIM routers from forwarding the same multicast
content to the group of Downstream PIM routers sharing the same
(EVPN) Broadcast Domain. This multicast packet duplication may happen
in any of the following cases:
o Two or more Downstream PIM routers on the BD may issue (*,G) Joins
to different upstream routers on the BD because they have
inconsistent MRIB entries regarding how to reach the RP. Both paths
on the RP tree will be set up, causing two copies of all the shared
tree traffic to appear on the EVPN Broadcast Domain.
o Two or more routers on the BD may issue (S,G) Joins to different
upstream routers on the BD because they have inconsistent MRIB
entries regarding how to reach source S. Both paths on the source-
specific tree will be set up, causing two copies of all the traffic
from S to appear on the BD.
o A router on the BD may issue a (*,G) Join to one upstream router on
the BD, and another router on the BD may issue an (S,G) Join to a
different upstream router on the same BD. Traffic from S may reach
the BD over both the RPT and the SPT. If the receiver behind the
downstream (*,G) router doesn't issue an (S,G,rpt) prune, then this
condition would persist.
PIM does not prevent such duplicate joins from occurring; instead,
when duplicate data packets appear on the same BD from different
routers, these routers notice this and then elect a single forwarder.
This election is performed using the PIM Assert procedure.
The issue is minimized or suppressed in this document by making sure
all the Upstream PEs select the same Upstream Neighbor for a given
(*,G) or (S,G) in any of the three above situations. If there is only
one upstream PIM router selected and the same multicast content is
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 10]
Internet-Draft EVPN PIM Proxy July 3, 2017
not allowed to be flooded from more than one Upstream Neighbor, there
will not be multicast duplication or need for Assert procedures in
the EVPN Broadcast Domain.
Figure 3 illustrates an example of the PIM Assert Optimization in
EVPN.
J(*,G1,IP5)
+--+ J(*,G1,IP5)
|R1+------> XXXXXXXX J(S1,G1,IP4)
+--+ +-----+ XXXX XX XXXXX +-----+ +--+
| PE1 |XXXXX XXXX XX| PE3 +----> |R4|
+--+ | | SMET | | +--+
|R2+-----> +-----+ (*,G1,IP5) +-----+
+--+ X +---------> XX
J(*,G1,IP4) X XXX
XX XX
X X J(*,G1,IP5)
+--+ +-----+ SMET X J(S1,G1,IP4)
|R3+---> | PE2 | (S1,G1,IP4) XX+-----+ +--+
+--+ | | +--------> XXXX | PE4 +--> |R5|
+-----+XXXX XXXXX | | +--+
J(S1,G1,IP4) X X X +-----+ RP
XX XXX XX XXX P(S1,G1,IP5,rpt)-->
XXXXXX XXXXX XXX
Figure 3 - Proxy PIM Assert Optimization in EVPN
2.3.1 Assert Optimization Procedures in Downstream PEs
The Downstream PEs will trigger SMET routes based on the received PIM
Join messages. This is their behavior when any of the three
situations described in section 2.3 occurs:
o If the Downstream PE receives two local (*,G) Joins to different
Upstream Neighbors, the PE will generate a single SMET route,
selecting the highest IP address. In Figure 3, if we assume R1
issues J(*,G1,IP5) and R2 J(*,G1,IP4), PE1 will advertise an SMET
route for (*,G,IP5). If PE1 had already advertised (*,G1,IP4), it
would have sent an update with (*,G1,IP5). Note that the Upstream
Router IP address is not part of the SMET route key, hence there is
no need to withdraw the previous (*,G1,IP4).
o In the same way, if the Downstream PE receives two local (S,G)
Joins to different Upstream Neighbors, the PE will generate a
single SMET route, selecting the highest IP address.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 11]
Internet-Draft EVPN PIM Proxy July 3, 2017
o If the Downstream PE receives a local (S,G) and a local (*,G) Joins
for the same group but to different Upstream Neighbors, the PE will
generate two different SMET routes (since *,G and S,G make two
different route keys), keeping the original Upstream Neighbors in
the SMET routes.
2.3.2 Assert Optimization Procedures in Upstream PEs
Upon receiving two or more SMET routes for the same group but
different Upstream Neighbors, the Upstream PEs will follow this
procedure:
1) The Upstream PE will select a unique Upstream Neighbor based on
the following rules:
a) The Upstream Neighbor encoded in a (S,G) SMET route has
precedence over the Upstream Neighbor on the (*,G) SMET route
for the same group. This is consistent with the Assert winner
election in [RFC4601]. In the example of Figure 3, PE3 and PE4
will select IP4 as the Upstream Neighbor for (S1,G1) and (*,G1).
b) In case the SMET routes have the same source (* or S), the
higher Upstream Neighbor IP Address wins.
2) After selecting the Unique Upstream Neighbor, the PE will instruct
the data path to discard any ingress multicast stream that is
coming from an interface different than the selected Upstream
Neighbor for the multicast group. In the example in Figure 3, PE4
will not accept G1 multicast traffic from R5.
3) Then the PE will generate the corresponding local PIM messages as
usual. In the example, PE3 and PE4 generate PIM Join messages for
(S1,G1,IP4) and (*,G1,IP5).
4) The PE connected to the non-selected Upstream Neighbor will issue
a PIM (S,G)/(*,G) Prune or a PIM (S,G,rpt) Prune to make sure the
non-selected Upstream Router does not forward traffic for the
group anymore. In the example, PE4 will issue a local (S1,G1,rpt)
Prune message to R5, so that R5 does not forward G1 traffic.
In case of any change that impacts on the Upstream Neighbor selection
for a given group G1, the upstream PEs will simply update the
Upstream Neighbor selection and follow the above procedure. This
mechanism prevents the multicast duplication in the EVPN Broadcast
Domain and avoids PIM Assert procedures among PIM routers in the BD.
2.4. EVPN Multi-Homing and State Synchronization
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 12]
Internet-Draft EVPN PIM Proxy July 3, 2017
PIM Join/Prune States will be synchronized across all the PEs in an
Ethernet Segment by using the procedures described in [EVPN-IGMP-MLD-
PROXY] and the IGMP/PIM Join Synch Route with the corresponding Flag
P set. This document does not require the use of IGMP Leave Synch
Routes.
In the same way, RPT-Prune States can be synchronized by using the
PIM RPT-Prune Synch route. The generation and process for this route
follows similar procedures as for the IGMP/PIM Join Synch Route.
In order to synchronize the PIM Neighbors discovered on an Ethernet
Segment, the MRD route and its ESI value will be used. Upon receiving
a Hello message on a link that is part of a multi-homed Ethernet
Segment, the PE will issue an MRD route that encodes the ESI value of
the AC over which the Hello was received. Upon receiving the non-zero
ESI MRD route, the PEs in the same ES will add the router to their
PIM Neighbor DB, using their AC on the same ES as the PIM Neighbor
port. This will allow the DF on the ES to generate Hello messages for
the local PIM router.
A PE that is not part of the ESI would normally receive a single non-
zero ESI MRD route per multicast router. In certain transient
situations the PE may receive more than one non-zero ESI MRD route
for the same multicast router. The PE should recognize this and not
generate additional PIM Hello messages for the local ACs.
2.5. PIM Bootstrap and RP Discovery
This section will be covered in future revisions of this document.
2.6. PIM-DM (Dense Mode) Proxy Procedures
This section will be covered in future revisions of this document.
3. Interaction with IGMP-snooping and Sources
Figure 4 illustrates an example with a multicast source, an IGMP host
and a PIM router in the same EVPN BD.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 13]
Internet-Draft EVPN PIM Proxy July 3, 2017
XXXXX J(*,G1)
XXXXXXX +-----+ +--+
XXXX | PE3 | <---+H3|
X | | +--+
+------+ X +--------> +-----+ +--->
|Source| +-----+ | S1,G1 X S1,G1 mcast
| S1 +---> | PE1 | + mcast XX
+------+ | | XX Hello
G1 +-----+ + S1,G1 X <---+
XX | mcast +-----+ +--+
X +---------> | PE4 +--> |R4|
X | | +--+
XX XXX +-----+ DR
XXX XXX XXX
XXXXXXX S1,G1, mcast
Figure 4 - Proxy PIM interaction with local sources and hosts
When PIM routers, multicast sources and IGMP hosts coexist in the
same EVPN Broadcast domain, the PEs supporting both IGMP and PIM
proxy will provide the following optimizations in the EVPN BD:
o If an IGMP host and a PIM router are connected to the same BD on a
PE, the PE will advertise a single SMET route per (S,G) or (*,G)
irrespective of the received IGMP or PIM message. The IGMP flags
can be simultaneously set along with the P flag.
o In the same way, if IGMP hosts and PIM routers are connected to the
same MAC-VRF and Ethernet Segment, the IGMP/PIM Join Synch route
can be shared by a host and a router requesting the same multicast
source and group.
o A PE connected to a Source and using Ingress Replication will
forward a multicast stream (S1,G1) to all the egress PEs that
advertised an SMET route for (S1,G1) and all the egress PEs that
advertised an MRD route for the EVPN BD.
4. BGP Information Model
This document defines the following additional routes and requests
IANA to allocate a type value in the EVPN route type registry:
+ Type TBD - Multicast Router Discovery (MRD) Route
+ Type TBD - PIM RPT-Prune Route
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 14]
Internet-Draft EVPN PIM Proxy July 3, 2017
+ Type TBD - PIM RPT-Prune Join Synch Route
In addition, the following routes defined in [EVPN-IGMP-MLD-PROXY]
are re-used and extended in this document's procedures:
+ Type 6 - Selective Multicast Ethernet Tag Route
+ Type 7 - IGMP Join Synch Route
Where Type 7 is requested to be re-named as IGMP/PIM Join Synch
Route.
4.1 Multicast Router Discovery (MRD) Route
Figure 5 shows the content of the MRD route:
+-------------------------------------------------+
| RD (8 octets) |
+-------------------------------------------------+
| Ethernet Segment ID (10 octets) |
+-------------------------------------------------+
| Ethernet Tag ID (4 octets) |
+-------------------------------------------------+
| Originator Router Length (1 octet) |
+-------------------------------------------------+
| Originator Router Address (Variable) |
+-------------------------------------------------+
| Mcast Router Length (1 octet) |
+-------------------------------------------------+
| Mcast Router Address 1 (variable) |
+-------------------------------------------------+
| Secondary Address List Length (1 octet) |
+-------------------------------------------------+
| Secondary Mcast Router Address 1 (variable) |
+-------------------------------------------------+
| . |
| . |
| Secondary Mcast Router Address n (variable) |
+-------------------------------------------------+
| DR Priority (4 octets) |
+-------------------------------------------------+
| Flags (1 octet) |
+-------------------------------------------------+
Figure 5 Multicast Router Discovery Route
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 15]
Internet-Draft EVPN PIM Proxy July 3, 2017
The support for this new route type is OPTIONAL. Since this new route
type is OPTIONAL, an implementation not supporting it MUST ignore the
route, based on the unknown route type value, as specified by Section
5.4 in [RFC7606].
The encoding of this route is defined as follows:
o RD, ESI and Ethernet Tag ID are defined as per [RFC7432] for MAC/IP
routes.
o The Originator Router Length and Address encode and IPv4 or IPv6
address that belongs to the advertising PE.
o The Multicast Router Length and Address field encode the Primary IP
address of the PIM neighbor added to the PE's DB.
o The Secondary Address List Length encodes the number of Secondary
IP addresses advertised by the PIM router in the PIM Hello message.
If this field is zero, the NLRI will not include any Secondary
Multicast Router Address. All the IP addresses will have the same
Length, that is, they will all be either IPv4 or IPv6, but not a
mix of both.
o DR Priority is copied from the same field in Hello packets, as per
[RFC4601].
o Flags:
- Q: Querier flag. Least significant bit. It indicates the encoded
multicast router is an IGMP Querier.
- P: PIM router flag. Second low order bit in the Flags octet. It
indicates that the multicast router is a PIM router.
- Q and P may be set simultaneously.
For BGP processing purposes, only the RD, Ethernet Tag ID, Originator
Router Length and Address, and Multicast Router Length and Address
are considered part of the route key. The Secondary Multicast Router
Addresses and the rest of the fields are not part of the route key.
4.2 Selective Multicast Ethernet Tag Route for PIM Proxy
The extended SMET route used in this document is shown in Figure 6.
NOTE: this route may use the SMET route type, or may be a different
route type PIM SMET route. This is TBD.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 16]
Internet-Draft EVPN PIM Proxy July 3, 2017
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| Multicast Source Length (1 octet) |
+---------------------------------------+
| Multicast Source Address (variable) |
+---------------------------------------+
| Multicast Group Length (1 octet) |
+---------------------------------------+
| Multicast Group Address (Variable) |
+---------------------------------------+
| Originator Router Length (1 octet) |
+---------------------------------------+
| Originator Router Address (variable) |
+---------------------------------------+
| Flags (1 octets) (optional) |
+---------------------------------------+
| Upstream Router Length (1B)(optional)|
+---------------------------------------+
| Upstream Router Addr (variable)(opt) |
+---------------------------------------+
Flags:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| | | P|IE|v3|v2|v1|
+--+--+--+--+--+--+--+--+
Figure 6 Selective Multicast Ethernet Tag Route and Flags
As in the case of the MRD route, this route type is OPTIONAL.
This route will be used as per [EVPN-IGMP-MLD-PROXY], with the
following extra and optional fields:
o Upstream Router Length and Address will contain the same
information as received in a PIM Join/Prune message on a local AC.
There is only one Upstream Router Address per route.
o Flags: This field encodes Flags that are now relevant to IGMP and
PIM. The following new Flag is defined:
- Flag P: Indicates the SMET route is generated by a received PIM
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 17]
Internet-Draft EVPN PIM Proxy July 3, 2017
Join on a local AC. When P=1, the Upstream Router Length and
Address fields are present in the route. Otherwise the two fields
will not be present.
Compared to [EVPN-IGMP-MLD-PROXY] there is no change in terms of
fields considered part of the route key for BGP processing. The
Upstream Router Length and Address are not considered part of the
route key.
4.3 PIM RPT-Prune Route
The RPT-Prune route is analogous to the SMET route but for PIM RPT-
Prune messages. The SMET routes cannot be used to convey RPT-Prune
messages because they are always triggered by IGMP or PIM Join
messages. A PIM RPT-Prune message is used to Prune a specific (S,G)
from the RP Tree by downstream routers. An RPT-Prune message is
typically seen prior to an RPT-Join message for the (S,G), hence it
requires its own BGP route.
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| Multicast Source Length (1 octet) |
+---------------------------------------+
| Multicast Source Address (variable) |
+---------------------------------------+
| Multicast Group Length (1 octet) |
+---------------------------------------+
| Multicast Group Address (Variable) |
+---------------------------------------+
| Originator Router Length (1 octet) |
+---------------------------------------+
| Originator Router Address (variable) |
+---------------------------------------+
| Upstream Router Length (1B) |
+---------------------------------------+
| Upstream Router Addr (variable) |
+---------------------------------------+
Figure 7 PIM RPT-Prune Route
Fields are defined in the same way as for the SMET route.
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 18]
Internet-Draft EVPN PIM Proxy July 3, 2017
4.4 IGMP/PIM Join Synch Route for PIM Proxy
This document renames the IGMP Join Synch Route as IGMP/PIM Join
Synch Route and extends it with new fields and Flags as shown in
Figure 8:
NOTE: this route may use and extend the IGMP Join Synch Route, or may
turn out to be a different route type in future revisions. This is
TBD.
+----------------------------------------------+
| RD (8 octets) |
+----------------------------------------------+
| Ethernet Segment Identifier (10 octets) |
+----------------------------------------------+
| Ethernet Tag ID (4 octets) |
+----------------------------------------------+
| Multicast Source Length (1 octet) |
+----------------------------------------------+
| Multicast Source Address (variable) |
+----------------------------------------------+
| Multicast Group Length (1 octet) |
+----------------------------------------------+
| Multicast Group Address (Variable) |
+----------------------------------------------+
| Originator Router Length (1 octet) |
+----------------------------------------------+
| Originator Router Address (variable) |
+----------------------------------------------+
| Flags (1 octet) |
+----------------------------------------------+
| Upstream Router Length (1B)(optional) |
+----------------------------------------------+
| Upstream Router Addr (variable)(opt) |
+----------------------------------------------+
Flags:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| | | | P|IE|v3|v2|v1|
+--+--+--+--+--+--+--+--+
Figure 8 IGMP/PIM Join Synch Route and Flags
This route will be used as per [EVPN-IGMP-MLD-PROXY], with the
following extra and optional fields:
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 19]
Internet-Draft EVPN PIM Proxy July 3, 2017
o Upstream Router Length and Address will contain the same
information as received in a PIM Join/Prune message on a local AC.
There is only one Upstream Router Address per route.
o Flags: This field encodes Flags that are now relevant to IGMP and
PIM. The following new Flag is defined:
- Flag P: Indicates the Join Synch route is generated by a received
PIM Join on a local AC. When P=1, the Upstream Router Length and
Address fields are present in the route. Otherwise the two fields
will not be present.
Compared to [EVPN-IGMP-MLD-PROXY] there is no change in terms of
fields considered part of the route key for BGP processing. The
Upstream Router Length and Address are not considered part of the
route key.
4.5 IGMP/PIM RPT-Prune Synch Route for PIM Proxy
This new route is used to Synch RPT-Prune states among the PEs in the
Ethernet Segment.
+----------------------------------------------+
| RD (8 octets) |
+----------------------------------------------+
| Ethernet Segment Identifier (10 octets) |
+----------------------------------------------+
| Ethernet Tag ID (4 octets) |
+----------------------------------------------+
| Multicast Source Length (1 octet) |
+----------------------------------------------+
| Multicast Source Address (variable) |
+----------------------------------------------+
| Multicast Group Length (1 octet) |
+----------------------------------------------+
| Multicast Group Address (Variable) |
+----------------------------------------------+
| Originator Router Length (1 octet) |
+----------------------------------------------+
| Originator Router Address (variable) |
+----------------------------------------------+
| Upstream Router Length (1B)(optional) |
+----------------------------------------------+
| Upstream Router Addr (variable)(opt) |
+----------------------------------------------+
Figure 9 IGMP/PIM RPT-Prune Synch Route
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 20]
Internet-Draft EVPN PIM Proxy July 3, 2017
The RD, Ethernet Segment Identifier and other fields are defined as
for the IGMP/PIM Join Synch Route. In addition, the Upstream Router
Length and Address will contain the same information as received in a
PIM RPT-Prune message on a local AC. The Upstream Router points at
the RP for the source and group and there is only one Upstream Router
Address per route.
The route key for BGP processing is defined as per the IGMP/PIM Join
Synch route.
5. Conclusions
This document extends the IGMP Proxy concept of [EVPN-IGMP-MLD-PROXY]
to PIM, so that EVPN can also be used to minimize the flooding of PIM
control messages and optimize the delivery of IP multicast traffic in
EVPN Broadcast Domains that connect PIM routers.
This specification describes procedures to Discover new PIM routers
in the BD, as well as propagate PIM Join/Prune messages using EVPN
SMET routes and other optimizations.
6. Conventions used in this document
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 RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
7. Security Considerations
This section will be added in future versions.
8. IANA Considerations
This document requests IANA to allocate a new EVPN route type in the
corresponding registry:
+ Type TBD - Multicast Router Discovery (MRD) Route
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 21]
Internet-Draft EVPN PIM Proxy July 3, 2017
+ Type TBD - PIM RPT-Prune Route
+ Type TBD - PIM RPT-Prune Join Synch Route
In addition, the following route defined in [EVPN-IGMP-MLD-PROXY]
should be renamed as follows:
+ Type 7 - IGMP/PIM Join Synch Route
9. Terminology
o EVI: EVPN Instance.
o EVPN Broadcast Domain: it refers to an EVI in case of VLAN-based
and VLAN-bundle interfaces. It refers to a Bridge Domain identified
by an Ethernet-Tag (in the control plane) in case of VLAN-Aware
Bundle interfaces.
o AC: Attachment Circuit.
o PIM-DM: Protocol Independent Multicast - Dense Mode.
o PIM-SM: Protocol Independent Multicast - Sparse Mode.
o PIM-SSM: Protocol Independent Multicast - Source Specific Mode.
o S: IP address of the multicast source.
o G: IP address of the multicast group.
o N: Upstream neighbor field in a Join/Prune/Graft message.
o PIM J/P: PIM Join/Prune messages.
o RP: PIM Rendezvous Point.
o MRD route: Multicast Router Discovery.
o PIM Nbr: PIM Neighbor.
10. References
10.1 Normative References
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 22]
Internet-Draft EVPN PIM Proxy July 3, 2017
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet
VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <http://www.rfc-
editor.org/info/rfc7432>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August
2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997, <http://www.rfc-
editor.org/info/rfc2236>.
[VPLS-PIM-PROXY] Dornon, O. et al, "Protocol Independent Multicast
(PIM) over Virtual Private LAN Service (VPLS)", June 2017, work-in-
progress, draft-ietf-pals-vpls-pim-snooping-06.
[EVPN-IGMP-MLD-PROXY] Sajassi, A. et al, "IGMP and MLD Proxy for
EVPN", March 2017, work-in-progress, draft-ietf-bess-evpn-igmp-mld-
proxy-00.
10.2 Informative References
[EVPN-PROXY-ARP-ND] Rabadan, J. et al, "Operational Aspects of Proxy-
ARP/ND in EVPN Networks", April 2017, work-in-progress, draft-ietf-
bess-evpn-proxy-arp-nd-02.
11. Acknowledgments
12. Contributors
13. Authors' Addresses
Jorge Rabadan
Nokia
777 E. Middlefield Road
Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com
Senthil Sathappan
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 23]
Internet-Draft EVPN PIM Proxy July 3, 2017
Nokia
701 E. Middlefield Road
Mountain View, CA 94043 USA
Email: senthil.sathappan@nokia.com
Jayant Kotalwar
Nokia
701 E. Middlefield Road
Mountain View, CA 94043 USA
Email: jayant.kotalwar@nokia.com
Zhaohui Zhang
Juniper Networks
EMail: zzhang@juniper.net
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Kotalwar,Sathappan,Rabadan et al.Expires January 4, 2018 [Page 24]