draft-ietf-bess-evpn-igmp-mld-proxy-01.txt | draft-ietf-bess-evpn-igmp-mld-proxy-02.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 13 ¶ | skipping to change at page 1, line 13 ¶ | |||
BESS Working Group Ali Sajassi | BESS Working Group Ali Sajassi | |||
Internet-Draft Samir Thoria | Internet-Draft Samir Thoria | |||
Intended Status: Standards Track Cisco | Intended Status: Standards Track Cisco | |||
Keyur Patel | Keyur Patel | |||
Derek Yeung | Derek Yeung | |||
Arrcus | Arrcus | |||
John Drake | John Drake | |||
Wen Lin | Wen Lin | |||
Juniper | Juniper | |||
Expires: September 4, 2018 March 4, 2018 | Expires: December 24, 2018 June 24, 2018 | |||
IGMP and MLD Proxy for EVPN | IGMP and MLD Proxy for EVPN | |||
draft-ietf-bess-evpn-igmp-mld-proxy-01 | draft-ietf-bess-evpn-igmp-mld-proxy-02 | |||
Abstract | Abstract | |||
Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is | Ethernet Virtual Private Network (EVPN) solution [RFC 7432] 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. | |||
This draft describes how to support efficiently endpoints running | This draft describes how to support efficiently endpoints running | |||
skipping to change at page 3, line 9 ¶ | skipping to change at page 3, line 9 ¶ | |||
7.1 Selective Multicast Ethernet Tag Route . . . . . . . . . . . 15 | 7.1 Selective Multicast Ethernet Tag Route . . . . . . . . . . . 15 | |||
7.1.1 Constructing the Selective Multicast Ethernet Tag | 7.1.1 Constructing the Selective Multicast Ethernet Tag | |||
route . . . . . . . . . . . . . . . . . . . . . . . . . 17 | route . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
7.2 IGMP Join Synch Route . . . . . . . . . . . . . . . . . . . 18 | 7.2 IGMP Join Synch Route . . . . . . . . . . . . . . . . . . . 18 | |||
7.2.1 Constructing the IGMP Join Synch Route . . . . . . . . 19 | 7.2.1 Constructing the IGMP Join Synch Route . . . . . . . . 19 | |||
7.3 IGMP Leave Synch Route . . . . . . . . . . . . . . . . . . . 20 | 7.3 IGMP Leave Synch Route . . . . . . . . . . . . . . . . . . . 20 | |||
7.3.1 Constructing the IGMP Leave Synch Route . . . . . . . . 22 | 7.3.1 Constructing the IGMP Leave Synch Route . . . . . . . . 22 | |||
7.4 Multicast Flags Extended Community . . . . . . . . . . . . . 23 | 7.4 Multicast Flags Extended Community . . . . . . . . . . . . . 23 | |||
7.5 EVI-RT Extended Community . . . . . . . . . . . . . . . . . 24 | 7.5 EVI-RT Extended Community . . . . . . . . . . . . . . . . . 24 | |||
8 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 24 | 7.6 Rewriting of RT ECs and EVI-RT ECs by ASBRs . . . . . . . . 26 | |||
9 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 | 8 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 | |||
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
11.1 Normative References . . . . . . . . . . . . . . . . . . . 25 | 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
11.2 Informative References . . . . . . . . . . . . . . . . . . 25 | 11.1 Normative References . . . . . . . . . . . . . . . . . . . 27 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 | 11.2 Informative References . . . . . . . . . . . . . . . . . . 27 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
1 Introduction | 1 Introduction | |||
Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is | Ethernet Virtual Private Network (EVPN) solution [RFC 7432] 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 POD can consist of a collection of servers | In DC applications, a POD can consist of a collection of servers | |||
skipping to change at page 19, line 31 ¶ | skipping to change at page 19, line 31 ¶ | |||
associate IGMP version of receivers participating within the EVPN | associate IGMP version of receivers participating within the EVPN | |||
domain. The include/exclude bit helps in creating filters for a | domain. The include/exclude bit helps in creating filters for a | |||
given multicast route. | given multicast route. | |||
7.2.1 Constructing the IGMP Join Synch Route | 7.2.1 Constructing the IGMP Join Synch Route | |||
This section describes the procedures used to construct the IGMP Join | This section describes the procedures used to construct the IGMP Join | |||
Synch route. Support for this route type is optional. If a PE does | Synch route. Support for this route type is optional. If a PE does | |||
not support this route, then it MUST not indicate that it supports | not support this route, then it MUST not indicate that it supports | |||
'IGMP proxy' in Multicast Flag extended community for the EVIs | 'IGMP proxy' in Multicast Flag extended community for the EVIs | |||
corresponding to its multi-homed Ethernet Segments. An IGMP Join | corresponding to its multi-homed Ethernet Segments. | |||
Synch route is advertised with an ES-Import Route Target extended | ||||
community whose value is set to the ESI for the ES on which the IGMP | An IGMP Join Synch route MUST carry exactly one ES-Import Route | |||
Join was received. | Target extended community, the one that corresponds to the ES on | |||
which the IGMP Join was received. It MUST also carry exactly one | ||||
EVI-RT EC, the one that corresponds to the EVI on which the IGMP Join | ||||
was received. See Section 7.5 for details on how to form the EVI-RT | ||||
EC. | ||||
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. | |||
The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet | The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet | |||
value defined for the ES. | value defined for the ES. | |||
The Ethernet Tag ID MUST be set as follows: | The Ethernet Tag ID MUST be set as follows: | |||
skipping to change at page 22, line 13 ¶ | skipping to change at page 22, line 13 ¶ | |||
not set. | not set. | |||
The Flags field assists in distributing IGMP membership interest of a | The Flags field assists in distributing IGMP membership interest of a | |||
given host/VM for a given multicast route. The version bits help | given host/VM for a given multicast route. The version bits help | |||
associate IGMP version of receivers participating within the EVPN | associate IGMP version of receivers participating within the EVPN | |||
domain. The include/exclude bit helps in creating filters for a | domain. The include/exclude bit helps in creating filters for a | |||
given multicast route. | given multicast route. | |||
7.3.1 Constructing the IGMP Leave Synch Route | 7.3.1 Constructing the IGMP Leave Synch Route | |||
This section describes the procedures used to construct the IGMP Join | This section describes the procedures used to construct the IGMP | |||
Synch route. Support for this route type is optional. If a PE does | Leave Synch route. Support for this route type is optional. If a PE | |||
not support this route, then it MUST not indicate that it supports | does not support this route, then it MUST not indicate that it | |||
'IGMP proxy' in Multicast Flag extended community for the EVIs | supports 'IGMP proxy' in Multicast Flag extended community for the | |||
corresponding to its multi-homed Ethernet Segments. An IGMP Join | EVIs corresponding to its multi-homed Ethernet Segments. | |||
Synch route is advertised with an ES-Import Route Target extended | ||||
community whose value is set to the ESI for the ES on which the IGMP | An IGMP Leave Synch route MUST carry exactly one ES-Import Route | |||
Join was received. | Target extended community, the one that corresponds to the ES on | |||
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 | ||||
Leave was received. See Section 7.5 for details on how to form the | ||||
EVI-RT EC. | ||||
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. | |||
The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet | The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet | |||
value defined for the ES. | value defined for the ES. | |||
The Ethernet Tag ID MUST be set as follows: | The Ethernet Tag ID MUST be set as follows: | |||
skipping to change at page 24, line 21 ¶ | skipping to change at page 24, line 21 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
The low-order bit of the Flags is defined as the "IGMP Proxy Support" | The low-order bit of the Flags is defined as the "IGMP Proxy Support" | |||
bit. A value of 1 means that the PE supports IGMP Proxy as defined | bit. A value of 1 means that the PE supports IGMP Proxy as defined | |||
in this document, and a value of 0 means that the PE does not support | in this document, and a value of 0 means that the PE does not support | |||
IGMP proxy. The absence of this extended community also means that | IGMP proxy. The absence of this extended community also means that | |||
the PE doesn not support IGMP proxy. | the PE doesn not support IGMP proxy. | |||
7.5 EVI-RT Extended Community | 7.5 EVI-RT Extended Community | |||
The 'EVI-RT' extended community is a new EVPN extended community. | In EVPN, every EVI is associated with one or more Route Targets | |||
EVPN extended communities are transitive extended communities with a | (RTs). These Route Targets serve two functions: | |||
Type field value of 6. IANA will assign a Sub-Type from the 'EVPN | ||||
Extended Community Sub-Types' registry. | ||||
A PE that supports IGMP synch procedures for All-Active (or Single- | - Distribution control: RTs control the distribution of the routes. | |||
Active) multi-homed ES, MUST attach this extended community to either | If a route carries the RT associated with a particular EVI, it will | |||
IGMP Join Synch route (sec 7.2) or IGMP Leave Synch route (sec 7.3). | be distributed to all the PEs on which that EVI exists. | |||
This extended community carries the RT associated with the EVI so | ||||
that the receiving PE can identify the EVI properly. The reason | - EVI Identification: Once a route has been received by a particular | |||
standard format RT is not used, is to avoid distribution of these | PE, the RT is used to identify the EVI to which it applies. | |||
routes beyond the group of multihoming PEs for that ES. | ||||
An IGMP Join Synch or IGMP Leave Synch route is associated with a | ||||
particular combination of ES and EVI. These routes need to be | ||||
distributed only to PEs that are attached to the associated ES. | ||||
Therefore these routes carry the ES-Import RT for that ES. | ||||
Since an IGMP Join Synch or IGMP Leave Synch route does not need to | ||||
be distributed to all the PEs on which the associated EVI exists, | ||||
these routes cannot carry the RT associated with that EVI. Therefore, | ||||
when such a route arrives at a particular PE, the route's RTs cannot | ||||
be used to identify the EVI to which the route applies. Some other | ||||
means of associating the route with an EVI must be used. | ||||
This document specifies four new Extended Communities (EC) that can | ||||
be used to identify the EVI with which a route is associated, but | ||||
which do not have any effect on the distribution of the route. These | ||||
new ECs are are known as the "Type 0 EVI-RT EC", the "Type 1 EVI-RT | ||||
EC", the "Type 2 EVI-RT EC", and the "Type 3 EVI-RT EC". | ||||
A Type 0 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xA. | ||||
A Type 1 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xB. | ||||
A Type 2 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xC. | ||||
A Type 3 EVI-RT EC is an EVPN EC (type 6) of sub-type TBD. | ||||
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 | ||||
constructed as follows. Each such route is the result of having | ||||
received an IGMP Join or an IGMP Leave message from a particular BD. | ||||
We will say that the route is associated with that BD. For each BD, | ||||
there is a corresponding RT that is used to ensure that routes | ||||
"about" that BD are distributed to all PEs attached to that BD. So | ||||
suppose a given IGMP Join Synch or Leave Synch route is associated | ||||
with a given BD, say BD1, and suppose that the corresponding RT for | ||||
BD1 is RT1. Then: | ||||
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 of | ||||
the Type 0 EVI-RT EC is identical to the value field of RT1. | ||||
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 of | ||||
the Type 1 EVI-RT EC is identical to the value field of RT1. | ||||
2. If RT1 is a Transitive Four-Octet-specific EC, then the EVI-RT EC | ||||
carried by the route is a Type 2 EVI-RT EC. The value field of the | ||||
Type 2 EVI-RT EC is identical to the value field of RT1. | ||||
3. If RT1 is a Transitive IPv6-Address-specific EC, then the EVI-RT | ||||
EC carried by the route is a Type 3 EVI-RT EC. The value field of | ||||
the Type 3 EVI-RT EC is identical to the value field of RT1. | ||||
An IGMP Join Synch or Leave Synch route MUST carry exactly one EVI- | ||||
RT EC. | ||||
Suppose a PE receives a particular IGMP Join Synch or IGMP Leave | ||||
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 | ||||
than one EVI-RT EC, the PE MUST apply the "treat-as-withdraw" | ||||
procedure of [RFC7606]. | ||||
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 | ||||
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=TBD | 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 | ||||
EVI-RT type 0, 1, 2, or 3 respectively. | ||||
7.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 | ||||
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 | ||||
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 | ||||
with a policy that removes the RTs that are meaningful in AS1 and | ||||
replaces them with the corresponding (i.e., RTs corresponding to the | ||||
same EVIs) RTs that are meaningful in AS2. This is known as RT- | ||||
rewriting. | ||||
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. | ||||
8 Acknowledgement | 8 Acknowledgement | |||
9 Security Considerations | 9 Security Considerations | |||
Same security considerations as [RFC7432]. | Same security considerations as [RFC7432]. | |||
10 IANA Considerations | 10 IANA Considerations | |||
IANA has allocated the following EVPN Extended Community sub-types in | IANA has allocated the following codepoints from the EVPN Extended | |||
[RFC7153], and this document is the only reference for them. | Community sub-types registry. | |||
0x09 Multicast Flags Extended Community [this document] 0x0A | 0x09 Multicast Flags Extended Community [this document] | |||
EVI-RT Extended Community [this document] | 0x0A EVI-RT Type 0 [this document] | |||
0x0B EVI-RT Type 1 [this document] | ||||
0x0C EVI-RT Type 2 [this document] | ||||
This document requests the following EVPN route types from IANA | IANA is requested to allocate a new codepoint from the EVPN Extended | |||
registry. | Community sub-types registry for the following. | |||
+ 6 - Selective Multicast Ethernet Tag Route + 7 - IGMP Join | 0x0D EVI-RT Type 3 [this document] | |||
Synch Route + 8 - IGMP Leave Synch Route | ||||
IANA has allocated the following EVPN route types from the EVPN Route | ||||
Type registry. | ||||
6 - Selective Multicast Ethernet Tag Route | ||||
7 - IGMP Join Synch Route | ||||
8 - IGMP Leave Synch Route | ||||
IANA is requested to create a registry, "Multicast Flags Extended | ||||
Community Flags", in the BGP registry. | ||||
The Multicast Flags Extended Community contains a 16-bit Flags field. | ||||
The bits are numbered 0-15, from low-order to high-order. | ||||
The registry should be initialized as follows: | ||||
0 : IGMP Proxy Support [this document] | ||||
1-15 : unassigned | ||||
The registration policy should be "Standards Action". | ||||
11 References | 11 References | |||
11.1 Normative References | 11.1 Normative References | |||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4360] S. Sangli et al, ""BGP Extended Communities Attribute", | [RFC4360] S. Sangli et al, ""BGP Extended Communities Attribute", | |||
February, 2006. | February, 2006. | |||
End of changes. 13 change blocks. | ||||
41 lines changed or deleted | 152 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |