< draft-ietf-bess-evpn-igmp-mld-proxy-19.txt   draft-ietf-bess-evpn-igmp-mld-proxy-20.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: September 5, 2022 Cisco Systems Expires: September 22, 2022 Cisco Systems
K. Patel K. Patel
Arrcus Arrcus
J. Drake J. Drake
W. Lin W. Lin
Juniper Networks Juniper Networks
March 4, 2022 March 21, 2022
IGMP and MLD Proxy for EVPN IGMP and MLD Proxy for EVPN
draft-ietf-bess-evpn-igmp-mld-proxy-19 draft-ietf-bess-evpn-igmp-mld-proxy-20
Abstract Abstract
This document describes how to support efficiently endpoints running This document describes how to support efficiently endpoints running
IGMP(Internet Group Management Protocol) or MLD (Multicast Listener IGMP(Internet Group Management Protocol) or MLD (Multicast Listener
Discovery) for the multicast services over an EVPN network by Discovery) for the multicast services over an EVPN network by
incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs. incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 5, 2022. This Internet-Draft will expire on September 22, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 18, line 21 skipping to change at page 18, line 21
o The include/exclude (IE) bit helps in creating filters for a given o The include/exclude (IE) bit helps in creating filters for a given
multicast route. multicast route.
o If route is used for IPv6 (MLD) then bit 7 indicates support for o If route is used for IPv6 (MLD) then bit 7 indicates support for
MLD version 1. The second least significant bit, bit 6 indicates MLD version 1. The second least significant bit, bit 6 indicates
support for MLD version 2. Since there is no MLD version 3, in support for MLD version 2. Since there is no MLD version 3, in
case of IPv6 route third least significant bit MUST be 0. In case case of IPv6 route third least significant bit MUST be 0. In case
of IPv6 routes, the fourth least significant bit MUST be ignored of IPv6 routes, the fourth least significant bit MUST be ignored
if bit 6 is not set. if bit 6 is not set.
o Reserved bits MUST be set to 0 by sender. And receiver SHOULD o Reserved bits MUST be set to 0 by sender. And receiver MUST
ignore the Reserved bits. ignore the Reserved bits.
9.1.1. Constructing the Selective Multicast Ethernet Tag route 9.1.1. Constructing the Selective Multicast Ethernet Tag route
This section describes the procedures used to construct the Selective This section describes the procedures used to construct the Selective
Multicast Ethernet Tag (SMET) route. Multicast Ethernet Tag (SMET) route.
The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The
value field comprises an IP address of the PE (typically, the value field comprises an IP address of the PE (typically, the
loopback address) followed by a number unique to the PE. loopback address) followed by a number unique to the PE.
skipping to change at page 21, line 5 skipping to change at page 21, line 5
Consider the EVPN network of Figure-2, where there is an EVPN Consider the EVPN network of Figure-2, where there is an EVPN
instance configured across the PEs. Let's consider that PE2 is instance configured across the PEs. Let's consider that PE2 is
connected to multicast router R1 and there is a network running PIM connected to multicast router R1 and there is a network running PIM
ASM behind R1. If there are receivers behind the PIM ASM network the ASM behind R1. If there are receivers behind the PIM ASM network the
PIM Join would be forwarded to the PIM RP (Rendezvous Point). If PIM Join would be forwarded to the PIM RP (Rendezvous Point). If
receivers behind PIM ASM network are interested in a multicast flow receivers behind PIM ASM network are interested in a multicast flow
originated by multicast source S2 (behind PE1), it is necessary for originated by multicast source S2 (behind PE1), it is necessary for
PE2 to receive multicast traffic. In this case PE2 MUST originate a PE2 to receive multicast traffic. In this case PE2 MUST originate a
(*,*) SMET route to receive all of the multicast traffic in the EVPN (*,*) SMET route to receive all of the multicast traffic in the EVPN
domain. To generate Wildcards (*,*) routes, the procedure from domain. To generate Wildcards (*,*) routes, the procedure from
[RFC6625] SHOULD be used. [RFC6625] MUST be used.
9.2. Multicast Membership Report Synch Route 9.2. Multicast Membership Report Synch Route
This EVPN route type is used to coordinate IGMP Membership Report This EVPN route type is used to coordinate IGMP Membership Report
(x,G) state for a given BD between the PEs attached to a given ES (x,G) state for a given BD between the PEs attached to a given ES
operating in All- Active (or Single-Active) redundancy mode and it operating in All- Active (or Single-Active) redundancy mode and it
consists of following: consists of following:
+--------------------------------------------------+ +--------------------------------------------------+
| RD (8 octets) | | RD (8 octets) |
skipping to change at page 32, line 26 skipping to change at page 32, line 26
MLD version-X expectation, the PE MUST apply the "treat-as-withdraw" MLD version-X expectation, the PE MUST apply the "treat-as-withdraw"
procedure as per [RFC7606] procedure as per [RFC7606]
If a received BGP update is malformed such that BGP route keys cannot If a received BGP update is malformed such that BGP route keys cannot
be extracted, then BGP update MUST be considered as invalid. be extracted, then BGP update MUST be considered as invalid.
Receiving PE MUST apply the "Session reset" procedure of [RFC7606]. Receiving PE MUST apply the "Session reset" procedure of [RFC7606].
10. IGMP Version 1 Membership Report 10. IGMP Version 1 Membership Report
This document does not provide any detail about IGMPv1 processing. This document does not provide any detail about IGMPv1 processing.
Multicast working group are in process of deprecating uses of IGMPv1. Implementations are expected to only use IGMPv2 and above for IPv4
Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and and MLDv1 and above for IPv6. IGMPv1 routes are considered invalid
above for IPv6. IGMP V1 routes MUST be considered as invalid and the and the PE MUST apply the "treat-as-withdraw" procedure as per
PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606]. [RFC7606].
Initial version of document did mention use of IGMPv1 and flag had
provision to support IGMPv1. There may be an implementation which is
deployed as initial version of document, to interop flag has not been
changed.
11. Security Considerations 11. Security Considerations
This document describes a means to efficiently operate IGMP and MLD This document describes a means to efficiently operate IGMP and MLD
on a subnet constructed across multiple PODs or DCs via an EVPN on a subnet constructed across multiple PODs or DCs via an EVPN
solution. The security considerations for the operation of the solution. The security considerations for the operation of the
underlying EVPN and BGP substrate are described in [RFC7432], and underlying EVPN and BGP substrate are described in [RFC7432], and
specific multicast considerations are outlined in [RFC6513] and specific multicast considerations are outlined in [RFC6513] and
[RFC6514]. The EVPN and associated IGMP proxy provides a single [RFC6514]. The EVPN and associated IGMP proxy provides a single
broadcast domain so the same security considerations of IGMPv2 broadcast domain so the same security considerations of IGMPv2
skipping to change at page 33, line 25 skipping to change at page 33, line 25
IANA has allocated the following EVPN route types from the EVPN Route IANA has allocated the following EVPN route types from the EVPN Route
Type registry. Type registry.
6 - Selective Multicast Ethernet Tag Route 6 - Selective Multicast Ethernet Tag Route
7 - Multicast Membership Report Synch Route 7 - Multicast Membership Report Synch Route
8 - Multicast Leave Synch Route 8 - Multicast Leave Synch Route
The Multicast Flags Extended Community contains a 16-bit Flags field. The Multicast Flags Extended Community contains a 16-bit Flags field.
The bits are numbered 0-15, from high-order to low-order. The bits are numbered 0-15, from high-order to low-order.
The registry should be initialized as follows: The registry should be initialized as follows:
Bit Name Reference Bit Name Reference Change Controller
---- -------------- ------------- ---- -------------- ------------- ------------------
0 - 13 Unassigned 0 - 13 Unassigned
14 MLD Proxy Support This document 14 MLD Proxy Support This document. IETF
15 IGMP Proxy Support This document 15 IGMP Proxy Support This document IETF
The registration policy should be "First Come First Served". The registration policy should be "First Come First Served".
13. Acknowledgement 13. Acknowledgement
The authors would like to thank Stephane Litkowski, Jorge Rabadan, The authors would like to thank Stephane Litkowski, Jorge Rabadan,
Anoop Ghanwani, Jeffrey Haas, Krishna Muddenahally Ananthamurthy, Anoop Ghanwani, Jeffrey Haas, Krishna Muddenahally Ananthamurthy,
Swadesh Agrawal for reviewing and providing valuable comment. Swadesh Agrawal for reviewing and providing valuable comment.
14. Contributors 14. Contributors
Derek Yeung Derek Yeung
 End of changes. 9 change blocks. 
21 lines changed or deleted 17 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/