draft-ietf-bess-evpn-igmp-mld-proxy-07.txt   draft-ietf-bess-evpn-igmp-mld-proxy-08.txt 
BESS WorkGroup A. Sajassi BESS WorkGroup A. Sajassi
Internet-Draft S. Thoria Internet-Draft S. Thoria
Intended status: Standards Track M. Mishra Intended status: Standards Track M. Mishra
Expires: October 14, 2021 Cisco Systems Expires: October 21, 2021 Cisco Systems
K. Patel K. Patel
Arrcus Arrcus
J. Drake J. Drake
W. Lin W. Lin
Juniper Networks Juniper Networks
April 12, 2021 April 19, 2021
IGMP and MLD Proxy for EVPN IGMP and MLD Proxy for EVPN
draft-ietf-bess-evpn-igmp-mld-proxy-07 draft-ietf-bess-evpn-igmp-mld-proxy-08
Abstract Abstract
Ethernet Virtual Private Network (EVPN) solution is becoming Ethernet Virtual Private Network (EVPN) solution is becoming
pervasive in data center (DC) applications for Network Virtualization pervasive in data center (DC) applications for Network Virtualization
Overlay (NVO) and DC interconnect (DCI) services, and in service Overlay (NVO) and DC interconnect (DCI) services, and in service
provider (SP) applications for next generation virtual private LAN provider (SP) applications for next generation virtual private LAN
services. services.
This draft describes how to support efficiently endpoints running This draft describes how to support efficiently endpoints running
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 14, 2021. This Internet-Draft will expire on October 21, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 17 skipping to change at page 7, line 17
2. When the first hop PE receives an IGMPv3 Join for (S,G) on a 2. When the first hop PE receives an IGMPv3 Join for (S,G) on a
given BD, it SHOULD advertise the corresponding EVPN Selective given BD, it SHOULD advertise the corresponding EVPN Selective
Multicast Ethernet Tag (SMET) route regardless of whether the Multicast Ethernet Tag (SMET) route regardless of whether the
source (S) is attached to itself or not in order to facilitate source (S) is attached to itself or not in order to facilitate
the source move in the future. the source move in the future.
3. When the first hop PE receives an IGMP version-X Join first for 3. When the first hop PE receives an IGMP version-X Join first for
(*,G) and then later it receives an IGMP version-Y Join for the (*,G) and then later it receives an IGMP version-Y Join for the
same (*,G), then it MUST re-advertise the same EVPN SMET route same (*,G), then it MUST re-advertise the same EVPN SMET route
with flag for version-Y set in addition to any previously-set with flag for version-Y set in addition to any previously-set
version flag(s). In other words, the first hop PE MUST not version flag(s). In other words, the first hop PE MUST NOT
withdraw the EVPN route before sending the new route because the withdraw the EVPN route before sending the new route because the
flag field is not part of BGP route key processing. flag field is not part of BGP route key processing.
4. When the first hop PE receives an IGMP version-X Join first for 4. When the first hop PE receives an IGMP version-X Join first for
(*,G) and then later it receives an IGMPv3 Join for the same (*,G) and then later it receives an IGMPv3 Join for the same
multicast group address but for a specific source address S, then multicast group address but for a specific source address S, then
the PE MUST advertise a new EVPN SMET route with v3 flag set (and the PE MUST advertise a new EVPN SMET route with v3 flag set (and
v2 reset). The include/exclude flag also need to be set v2 reset). The include/exclude flag also need to be set
accordingly. Since source IP address is used as part of BGP accordingly. Since source IP address is used as part of BGP
route key processing it is considered as a new BGP route route key processing it is considered as a new BGP route
advertisement. advertisement.
5. When a PE receives an EVPN SMET route with more than one version 5. When a PE receives an EVPN SMET route with more than one version
flag set, it will generate the corresponding IGMP report for flag set, it will generate the corresponding IGMP report for
(*,G) for each version specified in the flags field. With (*,G) for each version specified in the flags field. With
multiple version flags set, there MUST not be source IP address multiple version flags set, there MUST NOT be source IP address
in the receive EVPN route. If there is, then an error SHOULD be in the receive EVPN route. If there is, then an error SHOULD be
logged . If the v3 flag is set (in addition to v2), then the logged . If the v3 flag is set (in addition to v2), then the
include/exclude flag MUST indicate "exclude". If not, then an include/exclude flag MUST indicate "exclude". If not, then an
error SHOULD be logged. The PE MUST generate an IGMP Membership error SHOULD be logged. The PE MUST generate an IGMP Membership
Report (Join) for that (*,G) and each IGMP version in the version Report (Join) for that (*,G) and each IGMP version in the version
flag. flag.
6. When a PE receives a list of EVPN SMET NLRIs in its BGP update 6. When a PE receives a list of EVPN SMET NLRIs in its BGP update
message, each with a different source IP address and the same message, each with a different source IP address and the same
multicast group address, and the version flag is set to v3, then multicast group address, and the version flag is set to v3, then
skipping to change at page 14, line 22 skipping to change at page 14, line 22
[ES,BD]. If the DF no longer has IGMP Membership Request (x,G) state [ES,BD]. If the DF no longer has IGMP Membership Request (x,G) state
for that BD on any ES for which it is DF, it withdraws its SMET route for that BD on any ES for which it is DF, it withdraws its SMET route
for that (x,G) group in that BD. for that (x,G) group in that BD.
6.3. Mass Withdraw of Multicast join Sync route in case of failure 6.3. Mass Withdraw of Multicast join Sync route in case of failure
A PE which has received an IGMP Membership Request, would have synced A PE which has received an IGMP Membership Request, would have synced
the IGMP Join by the procedure defined in section 6.1. If a PE with the IGMP Join by the procedure defined in section 6.1. If a PE with
local join state goes down or the PE to CE link goes down, it would local join state goes down or the PE to CE link goes down, it would
lead to a mass withdraw of multicast routes. Remote PEs (PEs where lead to a mass withdraw of multicast routes. Remote PEs (PEs where
these routes were remote IGMP Joins) SHOULD not remove the state these routes were remote IGMP Joins) SHOULD NOT remove the state
immediately; instead General Query SHOULD be generated to refresh the immediately; instead General Query SHOULD be generated to refresh the
states. There are several ways to detect failure at a peer, e.g. states. There are several ways to detect failure at a peer, e.g.
using IGP next hop tracking or ES route withdraw. using IGP next hop tracking or ES route withdraw.
7. Single-Active Multi-Homing 7. Single-Active Multi-Homing
Note that to facilitate state synchronization after failover, the PEs Note that to facilitate state synchronization after failover, the PEs
attached to a multihomed ES operating in Single-Active redundancy attached to a multihomed ES operating in Single-Active redundancy
mode SHOULD also coordinate IGMP Join (x,G) state. In this case all mode SHOULD also coordinate IGMP Join (x,G) state. In this case all
IGMP Join messages are received by the DF and distributed to the non- IGMP Join messages are received by the DF and distributed to the non-
skipping to change at page 24, line 33 skipping to change at page 24, line 33
case of IPv6 route, the fourth least significant bit MUST be ignored case of IPv6 route, the fourth least significant bit MUST be ignored
if bit 6 is not set. if bit 6 is not set.
Reserve bit in flag MUST be set to 0. They can be defined in future Reserve bit in flag MUST be set to 0. They can be defined in future
by other document. by other document.
9.3.1. Constructing the Multicast Leave Synch Route 9.3.1. Constructing the Multicast Leave Synch Route
This section describes the procedures used to construct the IGMP This section describes the procedures used to construct the IGMP
Leave Synch route. Support for this route type is optional. If a PE Leave Synch route. Support for this route type is optional. If a PE
does not support this route, then it MUST not indicate that it does not support this route, then it MUST NOT indicate that it
supports 'IGMP proxy' in Multicast Flag extended community for the supports 'IGMP proxy' in Multicast Flag extended community for the
EVIs corresponding to its multi-homed Ethernet Segments. EVIs corresponding to its multi-homed Ethernet Segments.
An IGMP Leave Synch route MUST carry exactly one ES-Import Route An IGMP Leave Synch route MUST carry exactly one ES-Import Route
Target extended community, the one that corresponds to the ES on Target extended community, the one that corresponds to the ES on
which the IGMP Leave was received. It MUST also carry exactly one which the IGMP Leave was received. It MUST also carry exactly one
EVI-RT EC, the one that corresponds to the EVI on which the IGMP EVI-RT EC, the one that corresponds to the EVI on which the IGMP
Leave was received. See Section 9.5 for details on how to form the Leave was received. See Section 9.5 for details on how to form the
EVI-RT EC. EVI-RT EC.
skipping to change at page 27, line 20 skipping to change at page 27, line 20
* Bit 14 (shown as M) defines MLD Proxy Support. Value of 1 for * Bit 14 (shown as M) defines MLD Proxy Support. Value of 1 for
bit 14 means that PE supports MLD Proxy. Value of 0 for bit 14 bit 14 means that PE supports MLD Proxy. Value of 0 for bit 14
means that PE does not support MLD proxy. means that PE does not support MLD proxy.
* Bit 0 to 13 are reserved for future. Sender MUST set it 0 and * Bit 0 to 13 are reserved for future. Sender MUST set it 0 and
receiver MUST ignore it. receiver MUST ignore it.
o Reserved bits are set to 0. Sender MUST set it to 0 and receiver o Reserved bits are set to 0. Sender MUST set it to 0 and receiver
MUST ignore it. MUST ignore it.
If a router does not support this specification, it MUST not add If a router does not support this specification, it MUST NOT add
Multicast Flags Extended Community in BGP route. A router receiving Multicast Flags Extended Community in BGP route. A router receiving
BGP update , if M and I both flag are zero (0), the router MUST treat BGP update , if M and I both flag are zero (0), the router MUST treat
this Update as malformed . Receiver of such update MUST ignore the this Update as malformed . Receiver of such update MUST ignore the
extended community. extended community.
9.5. EVI-RT Extended Community 9.5. EVI-RT Extended Community
In EVPN, every EVI is associated with one or more Route Targets In EVPN, every EVI is associated with one or more Route Targets
(RTs). These Route Targets serve two functions: (RTs). These Route Targets serve two functions:
 End of changes. 9 change blocks. 
9 lines changed or deleted 9 lines changed or added

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