One document matched: draft-lin-bess-evpn-irb-mcast-02.xml
<?xml version="1.1" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4364 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC6514 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-lin-bess-evpn-irb-mcast-02" ipr="trust200902">
<front>
<title abbrev="evpn-irb-mcast">EVPN Inter-subnet Multicast Forwarding</title>
<author fullname="Wen Lin" initials="W." surname="Lin">
<organization>Juniper Networks, Inc.</organization>
<address>
<email>wlin@juniper.net</email>
</address>
</author>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks, Inc.</organization>
<address>
<email>zzhang@juniper.net</email>
</address>
</author>
<author fullname="John Drake" initials="J." surname="Drake">
<organization>Juniper Networks, Inc.</organization>
<address>
<email>jdrake@juniper.net</email>
</address>
</author>
<author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
<organization>Nokia</organization>
<address>
<email>jorge.rabadan@nokia.com</email>
</address>
</author>
<date year="2016"/>
<workgroup>BESS</workgroup>
<abstract>
<t>This document describes inter-subnet multicast forwarding procedures
for Ethernet VPNs (EVPN).
</t>
</abstract>
<note title="Requirements Language">
<t>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.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
EVPN offers an efficient L2 VPN solution with all-active
multi-homing support for
intra-subnet connectivity over MPLS/IP network.
EVPN also provides an integrated L2 and L3 service.
When forwarding among Tenant Systems (TS) across different IP
subnets is required, Integrated Routing and Bridging (IRB)
can be used [ietf-bess-evpn-inter-subnet-forwarding].
</t>
<t>An network virtualization endpoint (NVE) device supporting IRB is
called a L3 Gateway. In a centralized
approach, a centralized gateway provides all L3 routing functionality,
and even two tenant systems on two subnets connected to the same NVE
need to go through the central gateway, which is inefficient.
In a distributed approach, each NVE has IRB configured,
and inter-subnet traffic will be locally routed without having to
go through a central gateway.
</t>
<t>Inter-subnet multicast forwarding is more complicated and not covered
in [ietf-bess-evpn-inter-subnet-forwarding]. This document describes
the procedures for inter-subnet multicast forwarding.
</t>
<t>For multicast traffic sourced from a TS in subnet 1, EVPN Broadcast,
Unknow unicast, Multicast (BUM) forwarding based on RFC 7432,
will deliver it to all sites in subnet 1. When IRBs in subnet 1 receive
the mulitcast traffic, they deliver to other corresponding IRBs in
other subnets at L3. From L3 point of view, those NVEs are routers connected
to the subnet via the IRB interfaces and the source is locally
attached. Nothing is different from a traditional LAN and regular
IGMP/MLD/PIM procedures kick in.
</t>
<t>If a TS is a multicast receiver, it uses IGMP/MLD to signal its interest
in some multicast flows. One of the gateways is the IGMP/MLD
querier for a given subnet. It sends queries out the IRB for that
subnet, which in turn causes the queries to be forwarded
throughout the subnet following the EVPN BUM procedures. TS's send
IGMP/MLD joins via multicast, which are also forwarded throughout the
subnet via EVPN BUM procedure. The gateways receive the joins via
their IRB interfaces. From layer 3 point of view, again it is nothing
different from a traditional LAN.
</t>
<t>On a traditional LAN, only one router can send multicast to the LAN.
That is either the PIM Designated Router (DR) or IGMP/MLD querier
(when PIM is not needed - e.g., the LAN is a stub network).
On the source subnet, PIM is typically needed so that traffic can
be delivered to other subnets via other routers. For example, in case of PIM-SM, the DR on
the source network encapsulates the initial packets for a particular
flow in PIM Register messages and unicasts the Register messages to
the Rendezvous Point (RP) for that flow, triggering
necessary states for that flow to be built throughout the network.
</t>
<t>That also works in the EVPN scenario, although not efficiently.
Consider the example depicted in Figure 1, where a tenant has two subnets
corresponding to two VLANs realized by two EVPN Instances (EVIs) at three
sites. The VLAN1 and VLAN 2 shown in Figure 1 correspond to
subnet 1 and subnet 2 respectively.
A multicast source is located at site 1 on subnet 1 and
three receivers are located at site 2 on subnet 1, site 1
and 2 on subnet 2 respectively. On subnet 1, NVE1 is the PIM DR
while on subnet 2, NVE3 is the PIM DR. The connection drawn in Figure 1
among NVEs are L3 connections.
</t>
<t>Multicast traffic from the source at site 1 on subnet 1 is forwarded to
all three sites on VLAN 1 following EVPN BUM procedure. Rcvr1 gets the
traffic when NVE2 sends it out of its local Attachment Circuit (AC).
The three gateways for EVI1 also receive the traffic on their IRB interfaces to
potentially route to other subnets. NVE3 is the DR on subnet 2 so it
routes the local traffic (from L3 point of view) to subnet 2 while
NVE1/2 is not the DR on subnet 2 so they don't. Once traffic
gets onto subnet 2, it is forwarded back to NVE1/2 and delivered to
rcvr2/3 following the EVPN BUM procedures.
</t>
<t>Notice that both NVE1 and NVE2 receive the multicast traffic from subnet 1
on their IRB interfaces for subnet 1, but they do not route to
subnet 2 where they are not the PIM DRs. Instead, they wait to receive
traffic at L2 from NVE3. For example, for receiver 3 connected to NVE1 but on different
IP subnet as the multicast source, the multicast traffic from source has to
go from NVE1 to NVE3 and then back to NVE1 before it is being delivered to
the receiver 3. This is similar to the hairpinning issue with
centralized approach, here the multicast forwarding is centralized via the DR,
even though distributed approach is being used for unicast
(in that each NVE is supporting IRB and routing inter-subnet unicast
traffic locally).
</t>
<figure>
<artwork>
site 1 . site 2 . site 3
. .
src . rcvr1 .
| . | .
-------------------------------------------- VLAN 1 (EVI1)
| . | . |
IRB1| DR . IRB1| . IRB1|
NVE1------------NVE2-----------------NVE3---RP
IRB2| . IRB2| . IRB2| DR
| . | . |
-------------------------------------------- VLAN 2 (EVI2)
| . | .
rcvr3 . rcvr2 .
. .
site 1 . site 2 . site 3
Figure 1 - EVPN IRB multicast scenario
</artwork>
</figure>
</section>
<section title="EVPN-aware Solution" anchor="solution">
<t>This multicast hairpinning can be avoided if the following procedures
are followed:
<list style="symbols">
<t>On the IRB interface, the gateway receives multicast traffic from
a source subnet, it sends the traffic on its IRB interfaces to
any other subnets that have receivers for the traffic, regardless
whether the gateway is DR for that subnet or not.
</t>
<t>On the IRB interface, if a gateway receives Membership
Reports from one of its ACs, it sends PIM joins
towards the RP or source regardless if it is DR/querier or not.
</t>
<t>Multicast data traffic sent out of the IRB interfaces
is forwarded to local ACs only and not to other EVPN sites.
</t>
</list>
</t>
<t>Essentially, each router on an IRB interface behaves as a DR/querier
for receivers (but only the true DR behaves as a DR for sources),
and multicast data traffic from IRB interfaces is limited to local
receivers.
</t>
<t>Note that link local multicast traffic (e.g. addressed to
224.0.0.x in case of IPv4)), typically use for protocols,
is not subject to the above procedures and still forwarded to
remote sites following EVPN procedures.
</t>
<t>In the example in Figure 1, when NVE1 gets traffic on its IRB1 interface
it will route the traffic out of its IRB2 and deliver to local rcvr3.
It also sends register messages to the RP, since it is the DR
on the source network. Both NVE2 and NVE3 will receive the traffic
on IRB1 but neither sends register messages to the RP, since they
are not the DR on the source subnet.
NVE2 will route the traffic out of its IRB2 and deliver to local rcvr2.
NVE3 will also route the traffic out of IRB2 even though there is
no receiver at the local site, because the IGMP/MLD joins from rcvr2/3 are
also received by NVE3.
</t>
<section title="IGMP/MLD Snooping Consideration">
<t>In the example in Figure 1, NVE3 receives IGMP/MLD joins from
rcvr2/3 and will route packets out of IRB2, even though there are no
receivers at the local site. IGMP/MLD snooping on NVE3 can prevent the traffic
from actually being sent out of ACs but at L3 there will still be
related states and processing/forwarding (e.g., IRB2 will be in the
downstream interface list for PIM join states and forwarding routes).
</t>
<t>To prevent NVE3 from learning those remote receivers at all, IGMP/MLD
snooping on NVE3 could optionally suppress the joins from remote sites
being sent to its IRB interface. With that, in the example in Figure 1,
NVE3 will not learn of rcvr2/3 on IRB2 and will not try to route packets
out of IRB2 at all.
</t>
</section>
<section title="Receiver sites not connected to a source subnet"
anchor="pim-requirement">
<t>In the example in Figure 1, the source subnet is connected to all NVEs
that has receiver sites, and there are no receivers outside the EVPN
network. As a result, PIM is not really needed and each NVE can just
route multicast traffic locally. In that case, IGMP/MLD querier
will be responsible to send traffic to a subnet.
</t>
<t>If there is a receiver subnet connected to an NVE that is not connected
to the source subnet, then there must exist layer 3 multicast paths
between them. This could be over an L3VPN core (in this revision
it is assumed that the subnets realized by EVPN are stub only and not
transit) and normal PIM and MVPN procedures will be followed.
</t>
<t>The L3VPN routes can be propagated either per RFC 4364 procedures or
per EVPN Type 5 procedures [bess-evpn-prefix-advertisement].
BGP-MVPN [RFC 6514] requires that the routes used for RPF checking
carry two extended communities (ECs) - VRF Route Import EC and
Source AS EC. That must be applied to EVPN Prefix Advertisement
(Type 5) routes as well.
</t>
</section>
<section title="Receiver sites without IRB" anchor="no-irb">
<t>It is possible that a particular NVE may not have an IRB interface
for its l2 domain. In that case, for traffic from another
l2 domain, receivers need to receive from another NVE following
EVPN procedures. The obvious choice is
that it receives from the DR of that subnet. Because an NVE does not
deliver traffic out of IRBs to remote sites with IRB, the DR needs to
use a separate provider tunnel to deliver traffic only to sites
that do not have IRB interfaces.
The tunnel is advertised in new EVPN route type that is analogous to
the MVPN "S-PMSI A-D" route [RFC6514].
This route will carry an EVPN Non-IRB Extended Community, indicating that
a PE attached to the EVI identified in the route should join the
advertised tunnel only if it does not have an IRB for that EVI.
The routes could be either
be a (*,*) wildcard S-PMSI A-D routes if an inclusive tunnel is
used (but only for all sites without IRBs), or individual
(*,g)/(s,*) S-PMSI A-D routes if selective tunnels are used per
[draft-zzhang-bess-evpn-bum-procedure-updates]. The (*,*) wildcard
S-PMSI A-D route may be advertised by the NVE carrying Non-IRB Site
extended community for each of its BD to deliver multicast traffic
routed out of the IRB interface to remote sites that do not have IRBs.
Different RDs MUST be used for this (*, *) S-PMSI A-D route in the
following case: if instead of an inclusive multicast Ethernet tag
route, the NVE also uses (*,*) S-PMSI to deliver BUM traffic received
from local ACs to remote PEs.
</t>
<t>If [draft-sajassi-bess-evpn-igmp-mld-proxy] procedures are used,
then routes from those non-IRB sites MUST also carry the EVPN non-IRB
extended community, so that the DR will only forward traffic to those non-IRB NVEs.
</t>
<t>The EVPN non-IRB Extended Community is a new EVPN extended community. EVPN extended communities
are transitive extended community with a Type field of 6. The subtype of this new
EVPN extended community will be
assigned by IANA, and with the following 8-octet encoding:
<figure>
<artwork>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type TBD | Flag(Octet) | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t> The lower-order bit of the Flag is defined as non-IRB bit.
A value one indicates non-IRB NVE. The rest of the undefined bits
are set to zero.
</t>
</section>
<section title="Multi-homing Support">
<t>The solution works equally well in multi-homing situations, as long as
the multi-homed PEs attached to the same Ethernet segment have the
same IRB capability, which is expected to be the normal deployment.
</t>
<t>As shown in Figure 2, both rcvr4 and rcvr5 are active-active
multi-homed to NVE2 and NVE3. Receiver 4 is on subnet VLAN 1 and receiver
5 is on VLAN 2. When IRBs on NVE1 and NVE2 forward multicast traffic to
its local attached access interface(s) based on EVPN BUM procedure, only
DF for the ES deliveries multicast traffic to its multi-homed receiver.
Hence no duplicated multicast traffic will be forwarded to receiver 4 or
receiver 5.
</t>
<figure>
<artwork>
.
src . +-------- rcvr4-----+
| . | . |
-------------------------------------------- VLAN 1 (EVI1)
| . | . |
IRB1| DR . IRB1| . IRB1|
NVE1------------NVE2-----------------NVE3---RP
IRB2| . IRB2| . IRB2| DR
| . | . |
-------------------------------------------- VLAN 2 (EVI2)
| . | . |
rcvr3 . +-------- rcvr5-----+
.
Figure 2 - EVPN IRB multicast and multi-homing
</artwork>
</figure>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests the following IANA assignments:
<list style="symbols">
<t>A "Non-IRB Site" Sub-Type in
"EVPN Extended Community Sub-Types" registry for the
EVPN Non-IRB Extended Community.
</t>
<t>A "non-IRB" flag bit in the EVPN Non-IRB Extended Community.
</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This document does not introduce new security risks.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors would like to thank Eric Rosen for his detailed review
and valuable comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC7432;
<?rfc include='reference.I-D.draft-zzhang-bess-evpn-bum-procedure-updates-01'?>
<?rfc include='reference.I-D.draft-sajassi-bess-evpn-igmp-mld-proxy-00'?>
</references>
<references title="Informative References">
&RFC4364;
&RFC6514;
<?rfc include='reference.I-D.draft-ietf-bess-evpn-inter-subnet-forwarding-00'?>
<?rfc include='reference.I-D.draft-ietf-bess-evpn-prefix-advertisement-01'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:41:50 |