[bess] Issue w/ IGMP and MLD Proxy for EVPN (draft-ietf-bess-evpn-igmp-mld-proxy)

[John E Drake <[e-mail]>]

Hi,

Stephane asked me to send an email to the list describing an issue that the authors of the IGMP and MLD Proxy for EVPN (draft-ietf-bess-evpn-igmp-mld-proxy) have discovered w/ the current design for identifying the [ES, EVI] into which to import a Join/Leave Synch route, describe our proposed fix, and ask if anyone objects to it. 

The current design uses the existing EVPN ES-Import route target to limit the distribution of a Join/Leave Synch route to the PEs attached to a given ES, and it uses an EVI-RT extended community to identify the EVI on that ES into which to import the route.  Unfortunately, the EVI-RT contains the Value field of the EVI-RT but not its Type (two byte AS # (type 0), IP address (type 1), or four byte AS # (type 2)) or Sub-Type, which is 2 in all cases, and without the Type field in particular, the Value field of may be the same for more than one EVI.

The authors' proposal for fixing this is to define multiple versions of the EVI-RT, one for each type and each assigned a different EVPN Extended Community Sub-Type.

We would propose that section 7.5 is updated to describe the three EVI-RT extended communities and section 10, IANA Considerations is updated as follows:

Change the description of the 0x0A Sub-Type from 'EVI-RT Extended Community' to 'EVI-RT Type 0 Extended Community' and add:

0x0B  'EVI-RT Type 1 Extended Community'

0x0C  'EVI-RT Type 2 Extended Community' 

The reference for all three Sub-Types is [draft-ietf-bess-evpn-igmp-mld-proxy].

Yours Irrespectively,

John

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Tuesday, June 5, 2018 11:09 AM
To: John E Drake <[e-mail]>
Subject: RE: IGMP Proxy

Hi John,

Thanks for the information.
It helps.
However, that would have been better to have the discussion on the list (sorry if I have missed it) and update the draft before doing the request for a change.
As this is a WG doc, we need to ensure that we have the consensus to do this change and request new IANA code points.
I'm sure there will be consensus as great active people were involved in your discussion but from a process point of view, that would be wonderful if you publish a revision asap requesting changes to IANA so the WG folks are aware of what is happening.

Brgds,



-----Original Message-----
From: John E Drake [mailto:[e-mail]]
Sent: Tuesday, June 05, 2018 16:07
To: LITKOWSKI Stephane OBS/OINIS
Subject: IGMP Proxy

Stephane,

Here is the background on our EVPN Extended Community Sub-Type request to Amanda, on which you were copied.

Eric and I have had a protracted discussion (since the London IETF) w/ Ali (Cisco) and Jorge (Nokia) regarding Ali's proposal to change the current IGMP proxy design for identifying the [ES, EVI] into which to import a Join/Leave Synch route.  In the end we agreed to keep the current design, but to tweak it as follows. 

The current design uses the existing EVPN ES-Import route target to limit the distribution of a Join/Leave Synch route to the PEs attached to a given ES, and it uses an EVI-RT extended community to identify the EVI on that ES into which to import the route.  Unfortunately, the EVI-RT contains the Value field of the EVI-RT but not its Type (two byte AS # (type 0), IP address (type 1), or four byte AS # (type 2)) or Sub-Type, which is 2 in all cases, and without the Type field in particular, the Value field of may be the same for more than one EVI.

The proposal for fixing this is to define multiple versions of the EVI-RT, one for each type and each assigned a different EVPN Extended Community Sub-Type.  Currently 0x0A is assigned to the EVI-RT and presumably because that's what we currently use and because two byte AS #s are the common (?), it should be re-used for the Type 0 EVI-RT.  We will then assign 0x0B to the Type 1 EVI-RT and 0x0C to the Type 2 EVI-RT.

Yours Irrespectively,

John



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.