draft-ietf-bess-evpn-igmp-mld-proxy-05.txt   draft-ietf-bess-evpn-igmp-mld-proxy-06.txt 
BESS WorkGroup A. Sajassi BESS WorkGroup A. Sajassi
Internet-Draft S. Thoria Internet-Draft S. Thoria
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 30, 2020 K. Patel Expires: July 26, 2021 K. Patel
Arrcus Arrcus
J. Drake J. Drake
W. Lin W. Lin
Juniper Networks Juniper Networks
April 28, 2020 January 22, 2021
IGMP and MLD Proxy for EVPN IGMP and MLD Proxy for EVPN
draft-ietf-bess-evpn-igmp-mld-proxy-05 draft-ietf-bess-evpn-igmp-mld-proxy-06
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 43 skipping to change at page 1, line 43
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 30, 2020. This Internet-Draft will expire on July 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 2, line 45 skipping to change at page 2, line 45
6.3. Mass Withdraw of Multicast join Sync route in case of 6.3. Mass Withdraw of Multicast join Sync route in case of
failure . . . . . . . . . . . . . . . . . . . . . . . . . 14 failure . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Single-Active Multi-Homing . . . . . . . . . . . . . . . . . 14 7. Single-Active Multi-Homing . . . . . . . . . . . . . . . . . 14
8. Selective Multicast Procedures for IR tunnels . . . . . . . . 14 8. Selective Multicast Procedures for IR tunnels . . . . . . . . 14
9. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 15 9. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Selective Multicast Ethernet Tag Route . . . . . . . . . 15 9.1. Selective Multicast Ethernet Tag Route . . . . . . . . . 15
9.1.1. Constructing the Selective Multicast Ethernet Tag 9.1.1. Constructing the Selective Multicast Ethernet Tag
route . . . . . . . . . . . . . . . . . . . . . . . . 17 route . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1.2. Default Selective Multicast Route . . . . . . . . . . 18 9.1.2. Default Selective Multicast Route . . . . . . . . . . 18
9.2. Multicast Join Synch Route . . . . . . . . . . . . . . . 19 9.2. Multicast Join Synch Route . . . . . . . . . . . . . . . 19
9.2.1. Constructing the Multicast Join Synch Route . . . . . 21 9.2.1. Constructing the Multicast Join Synch Route . . . . . 20
9.3. Multicast Leave Synch Route . . . . . . . . . . . . . . . 22 9.3. Multicast Leave Synch Route . . . . . . . . . . . . . . . 22
9.3.1. Constructing the Multicast Leave Synch Route . . . . 24 9.3.1. Constructing the Multicast Leave Synch Route . . . . 23
9.4. Multicast Flags Extended Community . . . . . . . . . . . 26 9.4. Multicast Flags Extended Community . . . . . . . . . . . 25
9.5. EVI-RT Extended Community . . . . . . . . . . . . . . . . 27 9.5. EVI-RT Extended Community . . . . . . . . . . . . . . . . 26
9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs . . . . . . . 29 9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs . . . . . . . 28
9.7. BGP Error Handling . . . . . . . . . . . . . . . . . . . 29
10. IGMP/MLD Immediate Leave . . . . . . . . . . . . . . . . . . 29 10. IGMP/MLD Immediate Leave . . . . . . . . . . . . . . . . . . 29
11. IGMP Version 1 Membership Request . . . . . . . . . . . . . . 30 11. IGMP Version 1 Membership Request . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Ethernet Virtual Private Network (EVPN) solution [RFC7432] is Ethernet Virtual Private Network (EVPN) solution [RFC7432] is
becoming pervasive in data center (DC) applications for Network becoming pervasive in data center (DC) applications for Network
Virtualization Overlay (NVO) and DC interconnect (DCI) services, and Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
in service provider (SP) applications for next generation virtual in service provider (SP) applications for next generation virtual
private LAN services. private LAN services.
In DC applications, a point of delivery (POD) can consist of a In DC applications, a point of delivery (POD) can consist of a
skipping to change at page 8, line 35 skipping to change at page 8, line 35
2. When a PE receives an EVPN SMET route for a given (*,G), it 2. When a PE receives an EVPN SMET route for a given (*,G), it
compares the received version flags from the route with its per- compares the received version flags from the route with its per-
PE stored version flags. If the PE finds that a version flag PE stored version flags. If the PE finds that a version flag
associated with the (*,G) for the remote PE is reset, then the PE associated with the (*,G) for the remote PE is reset, then the PE
MUST generate IGMP Leave for that (*,G) toward its local MUST generate IGMP Leave for that (*,G) toward its local
interface (if any) attached to the multicast router for that interface (if any) attached to the multicast router for that
multicast group. It should be noted that the received EVPN route multicast group. It should be noted that the received EVPN route
SHOULD at least have one version flag set. If all version flags SHOULD at least have one version flag set. If all version flags
are reset, it is an error because the PE should have received an are reset, it is an error because the PE should have received an
EVPN route withdraw for the last version flag. Error MUST be EVPN route withdraw for the last version flag. Error MUST be
considered as BGP error and SHOULD be handled as per [RFC7606]. considered as BGP error and the PE MUST apply the "treat-as-
withdraw" procedure of [RFC7606].
3. When a PE receives an EVPN SMET route withdraw, it removes the 3. When a PE receives an EVPN SMET route withdraw, it removes the
remote PE from its OIF list for that multicast group and if there remote PE from its OIF list for that multicast group and if there
are no more OIF entries for that multicast group (either locally are no more OIF entries for that multicast group (either locally
or remotely), then the PE MUST stop responding to queries from or remotely), then the PE MUST stop responding to queries from
the locally attached router (if any). If there is a source for the locally attached router (if any). If there is a source for
that multicast group, the PE stops sending multicast traffic for that multicast group, the PE stops sending multicast traffic for
that source. that source.
4.2. Proxy Querier 4.2. Proxy Querier
skipping to change at page 12, line 7 skipping to change at page 12, line 7
for (x,G), it determines the BD to which the IGMP Membership Report for (x,G), it determines the BD to which the IGMP Membership Report
belongs. If the PE doesn't already have local IGMP Join (x,G) state belongs. If the PE doesn't already have local IGMP Join (x,G) state
for that BD on that ES, it MUST instantiate local IGMP Join (x,G) for that BD on that ES, it MUST instantiate local IGMP Join (x,G)
state and MUST advertise a BGP IGMP Join Synch route for that state and MUST advertise a BGP IGMP Join Synch route for that
[ES,BD]. Local IGMP Join (x, G) state refers to IGMP Join (x,G) [ES,BD]. Local IGMP Join (x, G) state refers to IGMP Join (x,G)
state that is created as a result of processing an IGMP Membership state that is created as a result of processing an IGMP Membership
Report for (x,G). Report for (x,G).
The IGMP Join Synch route MUST carry the ES-Import RT for the ES on The IGMP Join Synch route MUST carry the ES-Import RT for the ES on
which the IGMP Membership Report was received. Thus it MUST only be which the IGMP Membership Report was received. Thus it MUST only be
sent to the PEs attached to that ES and not any other PEs. imported by the PEs attached to that ES and not any other PEs.
When a PE, either DF or non-DF, receives an IGMP Join Synch route it When a PE, either DF or non-DF, receives an IGMP Join Synch route it
installs that route and if it doesn't already have IGMP Join (x,G) installs that route and if it doesn't already have IGMP Join (x,G)
state for that [ES,BD], it MUST instantiate that IGMP Join (x,G) state for that [ES,BD], it MUST instantiate that IGMP Join (x,G)
state - i.e., IGMP Join (x,G) state is the union of the local IGMP state - i.e., IGMP Join (x,G) state is the union of the local IGMP
Join (x,G) state and the installed IGMP Join Synch route. If the DF Join (x,G) state and the installed IGMP Join Synch route. If the DF
did not already advertise (originate) a SMET route for that (x,G) did not already advertise (originate) a SMET route for that (x,G)
group in that BD, it MUST do so now. group in that BD, it MUST do so now.
When a PE, either DF or non-DF, deletes its local IGMP Join (x, G) When a PE, either DF or non-DF, deletes its local IGMP Join (x, G)
skipping to change at page 13, line 20 skipping to change at page 13, line 20
3. It initiates the Last Member Query procedure described in 3. It initiates the Last Member Query procedure described in
Section 3 of [RFC2236]; viz, it sends a number of Group-Specific Section 3 of [RFC2236]; viz, it sends a number of Group-Specific
Query (x,G) messages (Last Member Query Count) at a fixed Query (x,G) messages (Last Member Query Count) at a fixed
interval (Last Member Query Interval) to the attached CE. interval (Last Member Query Interval) to the attached CE.
4. It advertises an IGMP Leave Synch route for that that [ES,BD]. 4. It advertises an IGMP Leave Synch route for that that [ES,BD].
This route notifies the other multihomed PEs attached to the This route notifies the other multihomed PEs attached to the
given multihomed ES that it has initiated an (x,G) leave group given multihomed ES that it has initiated an (x,G) leave group
synchronization procedure; i.e., it carries the ES-Import RT for synchronization procedure; i.e., it carries the ES-Import RT for
the ES on which the IGMP Leave Group was received. It also the ES on which the IGMP Leave Group was received. It also
contains the Maximum Response Time and the Leave Group contains the Maximum Response Time.
Synchronization Procedure Sequence number. The latter identifies
the specific (x,G) leave group synchronization procedure
initiated by the advertising PE, which increments the value
whenever it initiates a procedure.
5. When the Maximum Response Timer expires, the PE that has 5. When the Maximum Response Timer expires, the PE that has
advertised the IGMP Leave Synch route withdraws it. advertised the IGMP Leave Synch route withdraws it.
6.2.1. Remote Leave Group Synchronization 6.2.1. Remote Leave Group Synchronization
When a PE, either DF or non-DF, receives an IGMP Leave Synch route it When a PE, either DF or non-DF, receives an IGMP Leave Synch route it
installs that route and it starts a timer for (x,G) on the specified installs that route and it starts a timer for (x,G) on the specified
[ES,BD] whose value is set to the Maximum Response Time in the [ES,BD] whose value is set to the Maximum Response Time in the
received IGMP Leave Synch route. Note that the receipt of subsequent received IGMP Leave Synch route. Note that the receipt of subsequent
skipping to change at page 18, line 20 skipping to change at page 18, line 20
document. document.
IGMP is used to receive group membership information from hosts/VMs IGMP is used to receive group membership information from hosts/VMs
by TORs. Upon receiving the hosts/VMs expression of interest of a by TORs. Upon receiving the hosts/VMs expression of interest of a
particular group membership, this information is then forwarded using particular group membership, this information is then forwarded using
SMET route. The NLRI also keeps track of receiver's IGMP protocol SMET route. The NLRI also keeps track of receiver's IGMP protocol
version and any source filtering for a given group membership. All version and any source filtering for a given group membership. All
EVPN SMET routes are announced with per- EVI Route Target extended EVPN SMET routes are announced with per- EVI Route Target extended
communities. communities.
When a router that receives a BGP Update that contains the Selective
Multicast Route flag with its Partial bit set (Not following this
specification) determines that the route is malformed, the router
SHOULD treat this Update as malformed . Error MUST be considered as
BGP error and SHOULD be discarded as per [RFC7606]. An
implementation SHOULD provide debugging facilities to permit issues
caused by a malformed join sync route to be diagnosed. At a minimum,
such facilities MUST include logging an error when such an route is
detected.
9.1.2. Default Selective Multicast Route 9.1.2. Default Selective Multicast Route
If there is multicast router connected behind the EVPN domain, the PE If there is multicast router connected behind the EVPN domain, the PE
MAY originate a default SMET (*,*) to get all multicast traffic in MAY originate a default SMET (*,*) to get all multicast traffic in
domain. domain.
+--------------+ +--------------+
| | | |
| | | |
| | +----+ | | +----+
skipping to change at page 22, line 37 skipping to change at page 22, line 12
The Originator Router Address is the IP address of Router Originating The Originator Router Address is the IP address of Router Originating
the prefix. the prefix.
The Flags field indicates the version of IGMP protocol from which the The Flags field indicates the version of IGMP protocol from which the
membership report was received. It also indicates whether the membership report was received. It also indicates whether the
multicast group had INCLUDE or EXCLUDE bit set. multicast group had INCLUDE or EXCLUDE bit set.
Reserve bit MUST be set to 0. They can be defined in future by other Reserve bit MUST be set to 0. They can be defined in future by other
document. document.
When a multihomed router that receives a BGP Update that contains the
Multicast Join Sync Route flag with its Partial bit set (Not
following this specification) determines that the route is malformed,
the router SHOULD treat this Update as malformed . Error MUST be
considered as BGP error and SHOULD be discarded as per [RFC7606]. An
implementation SHOULD provide debugging facilities to permit issues
caused by a malformed join sync route to be diagnosed. At a minimum,
such facilities MUST include logging an error when such an route is
detected.
9.3. Multicast Leave Synch Route 9.3. Multicast Leave Synch Route
This EVPN route type is used to coordinate IGMP Leave Group (x,G) This EVPN route type is used to coordinate IGMP Leave Group (x,G)
state for a given BD between the PEs attached to a given ES operating state for a given BD between the PEs attached to a given ES operating
in All-Active (or Single-Active) redundancy mode and it consists of in All-Active (or Single-Active) redundancy mode and it consists of
following: following:
+--------------------------------------------------+ +--------------------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+--------------------------------------------------+ +--------------------------------------------------+
skipping to change at page 25, line 49 skipping to change at page 25, line 16
the reserved field to Zero , the receiver SHOULD ignore it and if it the reserved field to Zero , the receiver SHOULD ignore it and if it
needs to be propagated, it MUST propagate it unchanged needs to be propagated, it MUST propagate it unchanged
Maximum Response Time is value to be used while sending query as Maximum Response Time is value to be used while sending query as
defined in [RFC2236] defined in [RFC2236]
The Flags field indicates the version of IGMP protocol from which the The Flags field indicates the version of IGMP protocol from which the
membership report was received. It also indicates whether the membership report was received. It also indicates whether the
multicast group had INCLUDE or EXCLUDE bit set. multicast group had INCLUDE or EXCLUDE bit set.
When a multihomed router that receives a BGP Update that contains the
Multicast Leave Sync Route flag with its Partial bit set (Not
following this specification) determines that the route is malformed,
the router SHOULD treat this Update as malformed . Error MUST be
considered as BGP error and SHOULD be discarded as per [RFC7606]. An
implementation SHOULD provide debugging facilities to permit issues
caused by a malformed join sync route to be diagnosed. At a minimum,
such facilities MUST include logging an error when such an route is
detected.
9.4. Multicast Flags Extended Community 9.4. Multicast Flags Extended Community
The 'Multicast Flags' extended community is a new EVPN extended The 'Multicast Flags' extended community is a new EVPN extended
community. EVPN extended communities are transitive extended community. EVPN extended communities are transitive extended
communities with a Type field value of 6. IANA will assign a Sub- communities with a Type field value of 6. IANA will assign a Sub-
Type from the 'EVPN Extended Community Sub-Types' registry. Type from the 'EVPN Extended Community Sub-Types' registry.
A PE that supports IGMP proxy on a given BD MUST attach this extended A PE that supports IGMP proxy on a given BD MUST attach this extended
community to the Inclusive Multicast Ethernet Tag (IMET) route it community to the Inclusive Multicast Ethernet Tag (IMET) route it
advertises for that BD and it MUST set the IGMP Proxy Support flag to advertises for that BD and it MUST set the IGMP Proxy Support flag to
skipping to change at page 29, line 44 skipping to change at page 29, line 10
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
from AS1 to AS2, an ASBR at the AS1/AS2 border may be provisioned from AS1 to AS2, an ASBR at the AS1/AS2 border may be provisioned
with a policy that removes the RTs that are meaningful in AS1 and with a policy that removes the RTs that are meaningful in AS1 and
replaces them with the corresponding (i.e., RTs corresponding to the replaces them with the corresponding (i.e., RTs corresponding to the
same EVIs) RTs that are meaningful in AS2. This is known as RT- same EVIs) RTs that are meaningful in AS2. This is known as RT-
rewriting. rewriting.
Note that if a given route's RTs are rewritten, and the route carries Note that if a given route's RTs are rewritten, and the route carries
an EVI-RT EC, the EVI-RT EC needs to be rewritten as well. an EVI-RT EC, the EVI-RT EC needs to be rewritten as well.
9.7. BGP Error Handling
If a received BGP update contains Flags not in accordance with IGMP
version-X expectation, the PE MUST apply the "treat-as-withdraw"
procedure as per [RFC7606]
If a received BGP update is malformed such that BGP route keys cannot
be extracted, then BGP update MUST be considered as invalid.
Receiving PE MUST apply the "Session reset" procedure of [RFC7606].
10. IGMP/MLD Immediate Leave 10. IGMP/MLD Immediate Leave
IGMP MAY be configured with immediate leave option. This allows the IGMP MAY be configured with immediate leave option. This allows the
device to remove the group entry from the multicast routing table device to remove the group entry from the multicast routing table
immediately upon receiving a IGMP leave message for (x,G). In case immediately upon receiving a IGMP leave message for (x,G). In case
of all active multi-homing while synchronizing the IGMP Leave state of all active multi-homing while synchronizing the IGMP Leave state
to redundancy peers, Maximum Response Time MAY be filled in as Zero. to redundancy peers, Maximum Response Time MAY be filled in as Zero.
Implementations SHOULD have identical configuration across multi- Implementations SHOULD have identical configuration across multi-
homed peers. In case IGMP Leave Synch route is received with Maximum homed peers. In case IGMP Leave Synch route is received with Maximum
Response Time Zero, irrespective of local IGMP configuration it MAY Response Time Zero, irrespective of local IGMP configuration it MAY
be processed as an immediate leave. be processed as an immediate leave.
11. IGMP Version 1 Membership Request 11. IGMP Version 1 Membership Request
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
skipping to change at page 30, line 15 skipping to change at page 29, line 37
Implementations SHOULD have identical configuration across multi- Implementations SHOULD have identical configuration across multi-
homed peers. In case IGMP Leave Synch route is received with Maximum homed peers. In case IGMP Leave Synch route is received with Maximum
Response Time Zero, irrespective of local IGMP configuration it MAY Response Time Zero, irrespective of local IGMP configuration it MAY
be processed as an immediate leave. be processed as an immediate leave.
11. IGMP Version 1 Membership Request 11. IGMP Version 1 Membership Request
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 above for IPv6. IGMP V1 routes MUST be considered as invalid and the
handled as per [RFC7606] PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606]
12. Security Considerations 12. Security Considerations
Same security considerations as [RFC7432] ,[RFC2236] ,[RFC3376] , Same security considerations as [RFC7432] ,[RFC2236] ,[RFC3376] ,
[RFC2710], [RFC3810]. [RFC2710], [RFC3810].
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 registry.
 End of changes. 17 change blocks. 
55 lines changed or deleted 32 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/