Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18: (with DISCUSS and COMMENT)

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

Hi,

Comments inline below.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Eric Vyncke (evyncke) <[e-mail]>
> Sent: Friday, March 4, 2022 10:30 AM
> To: John E Drake <jdrake=[e-mail]>rg>; The IESG
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18:
> (with DISCUSS and COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> Hello John,
> 
> Thanks for your quick reply, even if I am unsure how to read " Yours
> Irrespectively," as I am not an English-native person.

[JD]  I have an odd sense of humor 

> 
> Thank you for pointing me to the new sections 9.1.2 & others => I will update my
> DISCUSS on this point w/o sending another email.
> 
> But section 1 still mentions only IGMP and never MLD except for "IGMP/MLD"
> proxy, this is trivial to fix, so I suggest to the authors to update the draft.

[JD]  We will update the introduction to use both throughout.  I will send proposed text this afternoon  

> 
> Regards
> 
> -éric
> 
> -----Original Message-----
> From: iesg <[e-mail]> on behalf of John E Drake
> <jdrake=[e-mail]>
> Date: Friday, 4 March 2022 at 15:01
> To: Eric Vyncke <[e-mail]>om>, The IESG <[e-mail]>
> Cc: "[e-mail]" <draft-ietf-bess-evpn-igmp-
> [e-mail]>gt;, "[e-mail]" <[e-mail]>om>,
> "[e-mail]" <[e-mail]>rg>, "[e-mail]"
> <[e-mail]>
> Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-18:
> (with DISCUSS and COMMENT)
> 
>     Hi,
> 
>     Snipped, comments inline
> 
>     Yours Irrespectively,
> 
>     John
> 
> 
>     Juniper Business Use Only
> 
>     > -----Original Message-----
> 
>     > DISCUSS:
>     > ----------------------------------------------------------------------
>     >
>     > As Martin Vigoureux's term is near its end, I took the liberty to re-evaluate
> the
>     > ballot status of this document and clearing parts of my original block
> DISCUSS
>     > points and many of my original non-blocking COMMENT points.
>     >
>     > See below this line for updated version
>     > ----------------------------------------------
>     >
>     > Thank you for the work put into this document. I have to state that I am
> neither
>     > a EVPN expert not a multicast one.
>     >
>     > Please find below some blocking DISCUSS points (probably easy to address),
>     > some non-blocking COMMENT points (but replies would be appreciated
> even if
>     > only for my own education), and some nits.
>     >
>     > Special thanks to Stéphane Litkowski for his shepherd's write-up about the
> WG
>     > consensus.
>     >
>     > I hope that this helps to improve the document,
>     >
>     > Regards,
>     >
>     > -éric
>     >
>     > == DISCUSS ==
>     >
>     > The text covers in details how to map MLD/IGMP into BGP routes but does
> not
>     > say a word on how to recreate the MLD/IGMP packets. Should there be any
> such
>     > specification (e.g., in section 4.1) ?
> 
>     [JD]  We added:
> 
>     9.1.2.  Reconstructing IGMP / MLD Membership Reports from Selective
> Multicast Route
> 
>     9.2.2.  Reconstructing IGMP / MLD Membership Reports from Multicast
> Membership Report Sync Route
> 
>     9.3.2.  Reconstructing IGMP / MLD Leave from Multicast Leave Sync Route
> 
>     >
>     > -- Section 1 --
>     > In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is
>     > really unclear.
> 
>     [JD]  The Abstract states:   This document describes how to support efficiently
> endpoints running IGMP
>     (Internet Group Management Protocol) or MLD (Multicast Listener  Discovery)
> for the multicast services
>     over an EVPN network by incorporating IGMP/MLD proxy procedures on EVPN
> (Ethernet VPN) PEs.
> 
>     We also added this paragraph to section 3 at Ben's behest:
> 
>     It is important to note when there is text considering whether a PE indicates
> support for IGMP proxying,
>     the corresponding behavior has a natural analogue for indication of support
> for MLD proxying, and the
>     analogous requirements apply as well.