< draft-ietf-bess-evpn-igmp-mld-proxy-13.txt   draft-ietf-bess-evpn-igmp-mld-proxy-14.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: March 18, 2022 Cisco Systems Expires: April 28, 2022 Cisco Systems
K. Patel K. Patel
Arrcus Arrcus
J. Drake J. Drake
W. Lin W. Lin
Juniper Networks Juniper Networks
September 14, 2021 October 25, 2021
IGMP and MLD Proxy for EVPN IGMP and MLD Proxy for EVPN
draft-ietf-bess-evpn-igmp-mld-proxy-13 draft-ietf-bess-evpn-igmp-mld-proxy-14
Abstract Abstract
This document describes how to support efficiently endpoints running This document describes how to support efficiently endpoints running
IGMP for the above services over an EVPN network by incorporating IGMP(Internet Group Management Protocol) or MLD (Multicast Listener
IGMP proxy procedures on EVPN PEs. Discovery) for the multicast services over an EVPN network by
incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 18, 2022. This Internet-Draft will expire on April 28, 2022.
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 3, line 12 skipping to change at page 3, line 13
14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
In DC applications, a point of delivery (POD) can consist of a In DC applications, a point of delivery (POD) can consist of a
collection of servers supported by several top of rack (TOR) and collection of servers supported by several top of rack (ToR) and
spine switches. This collection of servers and switches are self spine switches. This collection of servers and switches are self
contained and may have their own control protocol for intra-POD contained and may have their own control protocol for intra-POD
communication and orchestration. However, EVPN is used as standard communication and orchestration. However, EVPN is used as standard
way of inter-POD communication for both intra-DC and inter-DC. A way of inter-POD communication for both intra-DC and inter-DC. A
subnet can span across multiple PODs and DCs. EVPN provides a robust subnet can span across multiple PODs and DCs. EVPN provides a robust
multi-tenant solution with extensive multi-homing capabilities to multi-tenant solution with extensive multi-homing capabilities to
stretch a subnet (VLAN) across multiple PODs and DCs. There can be stretch a subnet (VLAN) across multiple PODs and DCs. There can be
many hosts (several hundreds) attached to a subnet that is stretched many hosts (several hundreds) attached to a subnet that is stretched
across several PODs and DCs. across several PODs and DCs.
skipping to change at page 4, line 19 skipping to change at page 4, line 22
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
o POD: Point of Delivery o AC: Attachment Circuit.
o ToR: Top of Rack
o NV: Network Virtualization o All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode.
o NVO: Network Virtualization Overlay o BD: Broadcast Domain. As per [RFC7432], an EVI consists of a
single or multiple BDs. In case of VLAN-bundle and VLAN-aware
bundle service model, an EVI contains multiple BDs. Also, in this
document, BD and subnet are equivalent terms.
o EVPN: Ethernet Virtual Private Network o Ethernet Segment (ES): When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links.
o IGMP: Internet Group Management Protocol o Ethernet Segment Identifier (ESI): A unique non-zero identifier
that identifies an Ethernet Segment.
o MLD: Multicast Listener Discovery o Ethernet Tag: It identifies a particular broadcast domain, e.g., a
VLAN. An EVPN instance consists of one or more broadcast domains.
o EVI: An EVPN instance spanning the Provider Edge (PE) devices o EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN participating in that EVPN
o EVPN: Ethernet Virtual Private Network
o IGMP: Internet Group Management Protocol
o IR: Ingress Replication
o MAC-VRF: A Virtual Routing and Forwarding table for Media Access o MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE Control (MAC) addresses on a PE
o IR: Ingress Replication o MLD: Multicast Listener Discovery
o Ethernet Segment (ES): When a customer site (device or network) is o NV: Network Virtualization
connected to one or more PEs via a set of Ethernet links.
o Ethernet Segment Identifier (ESI): A unique non-zero identifier o NVO: Network Virtualization Overlay
that identifies an Ethernet Segment.
o OIF: Outgoing Interface for multicast. It can be physical
interface, virtual interface or tunnel.
o PE: Provider Edge. o PE: Provider Edge.
o BD: Broadcast Domain. As per [RFC7432], an EVI consists of a o PMSI: P-Multicast Service Interface - a conceptual interface for a
single or multiple BDs. In case of VLAN-bundle and VLAN-aware PE to send customer multicast traffic to all or some PEs in the
bundle service model, an EVI contains multiple BDs. Also, in this same VPN.
document, BD and subnet are equivalent terms.
o Ethernet Tag: It identifies a particular broadcast domain, e.g., a o POD: Point of Delivery
VLAN. An EVPN instance consists of one or more broadcast domains.
o S-PMSI: Selective PMSI - to some of the PEs in the same VPN.
o Single-Active Redundancy Mode: When only a single PE, among all o Single-Active Redundancy Mode: When only a single PE, among all
the PEs attached to an Ethernet segment, is allowed to forward the PEs attached to an Ethernet segment, is allowed to forward
traffic to/from that Ethernet segment for a given VLAN, then the traffic to/from that Ethernet segment for a given VLAN, then the
Ethernet segment is defined to be operating in Single-Active Ethernet segment is defined to be operating in Single-Active
redundancy mode. redundancy mode.
o All-Active Redundancy Mode: When all PEs attached to an Ethernet o ToR: Top of Rack
segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode.
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 S-PMSI: Selective PMSI - to some of the PEs in the same VPN.
o AC: Attachment Circuit.
o OIF: Outgoing Interface for multicast. It can be physical
interface, virtual interface or tunnel.
This document also assumes familiarity with the terminology of This document also assumes familiarity with the terminology of
[RFC7432]. Though most of the place this document uses term IGMP [RFC7432]. Though most of the place this document uses term IGMP
Membership Report (Joins), the text applies equally for MLD Membership Report (Joins), the text applies equally for MLD
Membership Report too. Similarly, text for IGMPv2 applies to MLDv1 Membership Report too. Similarly, text for IGMPv2 applies to MLDv1
and text for IGMPv3 applies to MLDv2. IGMP / MLD version encoding in and text for IGMPv3 applies to MLDv2. IGMP / MLD version encoding in
BGP update is stated in Section 9 BGP update is stated in Section 9
4. IGMP/MLD Proxy 4. IGMP/MLD Proxy
skipping to change at page 8, line 14 skipping to change at page 8, line 14
PE does not receive an IGMP Join from the host it will not PE does not receive an IGMP Join from the host it will not
forward multicast data to it. In other words, an IGMPv2 Join forward multicast data to it. In other words, an IGMPv2 Join
MUST NOT be sent on an AC that does not lead to a CE multicast MUST NOT be sent on an AC that does not lead to a CE multicast
router. This message suppression is a requirement for IGMPv2 router. This message suppression is a requirement for IGMPv2
hosts. This is not a problem for hosts running IGMPv3 because hosts. This is not a problem for hosts running IGMPv3 because
there is no suppression of IGMP Membership Reports. there is no suppression of IGMP Membership Reports.
4.1.2. IGMP/MLD Leave Group Advertisement in BGP 4.1.2. IGMP/MLD Leave Group Advertisement in BGP
When a PE wants to withdraw an EVPN SMET route corresponding to an When a PE wants to withdraw an EVPN SMET route corresponding to an
IGMPv2 Leave Group (Leave) or IGMPv3 "Leave" equivalent message, it IGMPv2 Leave Group or IGMPv3 "Leave" equivalent message, it follows
follows the following rules: the following rules:
1. When a PE receives an IGMPv2 Leave Group or its "Leave" 1. When a PE receives an IGMPv2 Leave Group or its "Leave"
equivalent message for IGMPv3 from its attached host, it checks equivalent message for IGMPv3 from its attached host, it checks
to see if this host is the last host that is interested in this to see if this host is the last host that is interested in this
multicast group by sending a query for the multicast group. If multicast group by sending a query for the multicast group. If
the host was indeed the last one (i.e. no responses are received the host was indeed the last one (i.e. no responses are received
for the query), then the PE MUST re-advertises EVPN SMET for the query), then the PE MUST re-advertises EVPN SMET
Multicast route with the corresponding version flag reset. If Multicast route with the corresponding version flag reset. If
this is the last version flag to be reset, then instead of re- this is the last version flag to be reset, then instead of re-
advertising the EVPN route with all version flags reset, the PE advertising the EVPN route with all version flags reset, the PE
skipping to change at page 16, line 31 skipping to change at page 16, line 31
(S,G) information carried within the route-type is of an Include (S,G) information carried within the route-type is of an Include
Group type (bit value 0) or an Exclude Group type (bit value 1). Group type (bit value 0) or an Exclude Group type (bit value 1).
The Exclude Group type bit MUST be ignored if bit 5 is not set. The Exclude Group type bit MUST be ignored if bit 5 is not set.
o This EVPN route type is used to carry tenant IGMP multicast group o This EVPN route type is used to carry tenant IGMP multicast group
information. The flag field assists in distributing IGMP information. The flag field assists in distributing IGMP
Membership Report of a given host for a given multicast route. Membership Report of a given host for a given multicast route.
The version bits help associate IGMP version of receivers The version bits help associate IGMP version of receivers
participating within the EVPN domain. participating within the EVPN domain.
o The include/exclude 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 SHOULD be set to 0 by sender. And receiver SHOULD o Reserved bits MUST be set to 0 by sender. And receiver SHOULD
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 25, line 25 skipping to change at page 25, line 25
replicate the multicast traffic to the egress PEs that don't replicate the multicast traffic to the egress PEs that don't
advertise such capability even if they don't have any interests in advertise such capability even if they don't have any interests in
that (x,G). that (x,G).
A Multicast Flags extended community is encoded as an 8-octet value, A Multicast Flags extended community is encoded as an 8-octet value,
as follows: as follows:
0 1 2 3 0 1 2 3
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 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=0x09| Flags (2 Octets) |M|I| | Type=0x06 |Sub-Type=0x09 | Flags (2 Octets) |M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The low-order (lease significant) two bits are defined as the "IGMP The low-order (lease significant) two bits are defined as the "IGMP
Proxy Support and MLD Proxy Support" bit. The absence of this Proxy Support and MLD Proxy Support" bit. The absence of this
extended community also means that the PE does not support IGMP extended community also means that the PE does not support IGMP
proxy. where: proxy. where:
o Type is 0x06 as registered with IANA for EVPN Extended o Type is 0x06 as registered with IANA for EVPN Extended
skipping to change at page 27, line 11 skipping to change at page 27, line 11
2. A Type 1 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xB. 2. A Type 1 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xB.
3. A Type 2 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xC. 3. A Type 2 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xC.
4. A Type 3 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xD 4. A Type 3 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xD
Each IGMP Join Synch or IGMP Leave Synch route MUST carry exactly one Each IGMP Join Synch or IGMP Leave Synch route MUST carry exactly one
EVI-RT EC. The EVI-RT EC carried by a particular route is EVI-RT EC. The EVI-RT EC carried by a particular route is
constructed as follows. Each such route is the result of having constructed as follows. Each such route is the result of having
received an IGMP Join or an IGMP Leave message from a particular BD. received an IGMP Join or an IGMP Leave message from a particular BD.
The route is said to be associated associated with that BD. For each The route is said to be associated with that BD. For each BD, there
BD, there is a corresponding RT that is used to ensure that routes is a corresponding RT that is used to ensure that routes "about" that
"about" that BD are distributed to all PEs attached to that BD. So BD are distributed to all PEs attached to that BD. So suppose a
suppose a given IGMP Join Synch or Leave Synch route is associated given IGMP Join Synch or Leave Synch route is associated with a given
with a given BD, say BD1, and suppose that the corresponding RT for BD, say BD1, and suppose that the corresponding RT for BD1 is RT1.
BD1 is RT1. Then: Then:
o 0. If RT1 is a Transitive Two-Octet AS-specific EC, then the EVI- o 0. If RT1 is a Transitive Two-Octet AS-specific EC, then the EVI-
RT EC carried by the route is a Type 0 EVI-RT EC. The value field RT EC carried by the route is a Type 0 EVI-RT EC. The value field
of the Type 0 EVI-RT EC is identical to the value field of RT1. of the Type 0 EVI-RT EC is identical to the value field of RT1.
o 1. If RT1 is a Transitive IPv4-Address-specific EC, then the EVI- o 1. If RT1 is a Transitive IPv4-Address-specific EC, then the EVI-
RT EC carried by the route is a Type 1 EVI-RT EC. The value field RT EC carried by the route is a Type 1 EVI-RT EC. The value field
of the Type 1 EVI-RT EC is identical to the value field of RT1. of the Type 1 EVI-RT EC is identical to the value field of RT1.
o 2. If RT1 is a Transitive Four-Octet-specific EC, then the EVI-RT o 2. If RT1 is a Transitive Four-Octet-specific EC, then the EVI-RT
skipping to change at page 28, line 6 skipping to change at page 28, line 6
Synch route, say R1, and suppose that R1 carries an ES-Import RT that Synch route, say R1, and suppose that R1 carries an ES-Import RT that
is one of the PE's Import RTs. If R1 has no EVI-RT EC, or has more is one of the PE's Import RTs. If R1 has no EVI-RT EC, or has more
than one EVI-RT EC, the PE MUST apply the "treat-as-withdraw" than one EVI-RT EC, the PE MUST apply the "treat-as-withdraw"
procedure of [RFC7606]. procedure of [RFC7606].
Note that an EVI-RT EC is not a Route Target Extended Community, is Note that an EVI-RT EC is not a Route Target Extended Community, is
not visible to the RT Constrain mechanism [RFC4684], and is not not visible to the RT Constrain mechanism [RFC4684], and is not
intended to influence the propagation of routes by BGP. intended to influence the propagation of routes by BGP.
1 2 3 1 2 3
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 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=n | RT associated with EVI | | Type=0x06 | Sub-Type=n | RT associated with EVI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RT associated with the EVI (cont.) | | RT associated with the EVI (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the value of 'n' is 0x0A, 0x0B, 0x0C, or 0x0D corresponding to Where the value of 'n' is 0x0A, 0x0B, 0x0C, or 0x0D corresponding to
EVI-RT type 0, 1, 2, or 3 respectively. EVI-RT type 0, 1, 2, or 3 respectively.
9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs 9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs
There are certain situations in which an ES is attached to a set of There are certain situations in which an ES is attached to a set of
PEs that are not all in the same AS, or not all operated by the same PEs that are not all in the same AS, or not all operated by the same
provider. In some such situations, the RT that corresponds to a provider. In some such situations, the RT that corresponds to a
particular EVI may be different in each AS. If a route is propagated particular EVI may be different in each AS. If a route is propagated
skipping to change at page 29, line 15 skipping to change at page 29, line 15
be processed as an immediate leave. be processed as an immediate leave.
11. IGMP Version 1 Membership Report 11. 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. Multicast working group are in process of deprecating uses of IGMPv1.
Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and
above for IPv6. IGMP V1 routes MUST be considered as invalid and the above for IPv6. IGMP V1 routes MUST be considered as invalid and the
PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606]. PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606].
Initial version of document did mention use of IGMPv1 and flag had Initial version of document did mention use of IGMPv1 and flag had
provision to support IGMPv1. There may be an implemention which is provision to support IGMPv1. There may be an implementation which is
deployed as initial version of document, to interop flag has not been deployed as initial version of document, to interop flag has not been
changed. changed.
12. Security Considerations 12. Security Considerations
TThis document does not add any new security considirattions, Same This document describes a means to efficiently operate IGMP and MLD
security considerations as [RFC7432], [RFC2236], [RFC3376], on a subnet constructed across multiple PODs or DCs via an EVPN
[RFC2710], [RFC3810], [RFC6513], [RFC6514] are applicable. solution. The security considerations for the operation of the
underlying EVPN and BGP substrate are described in [RFC7432], and
specific multicast considerations are outlined in [RFC6513] and
[RFC6514]. The EVPN and associated IGMP proxy provides a single
broadcast domain so the same security considerations of IGMPv2
[RFC2236], [RFC3376], MLD [RFC2710], or MLDv2 [RFC3810] apply.
13. IANA Considerations 13. IANA Considerations
IANA has allocated the following codepoints from the EVPN Extended IANA has allocated the following codepoints from the EVPN Extended
Community sub-types registry. Community Sub-Types sub-registry of the BGP Extended Communities
registry.
0x09 Multicast Flags Extended Community [this document] 0x09 Multicast Flags Extended Community [this document]
0x0A EVI-RT Type 0 [this document] 0x0A EVI-RT Type 0 [this document]
0x0B EVI-RT Type 1 [this document] 0x0B EVI-RT Type 1 [this document]
0x0C EVI-RT Type 2 [this document] 0x0C EVI-RT Type 2 [this document]
IANA is requested to allocate a new codepoint from the EVPN Extended IANA is requested to allocate a new codepoint from the EVPN Extended
Community sub-types registry for the following. Community sub-types registry for the following.
0x0D EVI-RT Type 3 [this document] 0x0D EVI-RT Type 3 [this document]
skipping to change at page 32, line 10 skipping to change at page 32, line 19
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-bess-evpn-bum-procedure-updates] [I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- Sajassi, "Updates on EVPN BUM Procedures", draft-ietf-
bess-evpn-bum-procedure-updates-08 (work in progress), bess-evpn-bum-procedure-updates-11 (work in progress),
November 2019. October 2021.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
Authors' Addresses Authors' Addresses
Ali Sajassi Ali Sajassi
 End of changes. 29 change blocks. 
65 lines changed or deleted 71 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/