Hi Eric, Thanks for comment.
1. For text which talks about how to decode BGP routes back , will it be ok to have common section after BPG encoding (https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-16#section-9) ? which talks about fact that receiving PE need to decode it back and consider it as IGMP membership request and process it ? 2. About number restarting – There was comment by Alvaro where he wanted these numbers to be restarting to differentiate sender and receiver processing 3. SMET, I would take care of it in terminology. Mankamana From: Eric Vyncke (evyncke) <evyn...@cisco.com> Date: Monday, February 7, 2022 at 7:11 AM To: Mankamana Mishra (mankamis) <manka...@cisco.com>, The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT) Hello Mankamana and other authors, Is there a plan to solve my remaining blocking DISCUSS point ? I.e., how can a recipient EVPN speaker can translate back the BGP information into MLD/IGMP packets? Section 4.1 contains " The information is again translated back to IGMP message at the recipient EVPN speaker." But the translation is not specified. This should be required in a proposed standard document. I.e., multiple sections are about MLD/IGMP messages received by a PE, format of the BGP messages, but never how to generate MLD/IGMP from those routes. Even if trivial for the authors, some description, even short, is really required. BTW, in section 4.1.1 of revision -16, I find the numbering of the rules really confusing as it restarts from 1. Strongly suggest adding a preamble between rule 4 and rule 1. BTW2, "SMET" is used in the text before its expansion in section 9.1.1 (first use in section 4.1.1). I still hope that the above email helps improving this document, Regards -éric From: Eric Vyncke <evyn...@cisco.com> Date: Thursday, 28 October 2021 at 13:49 To: "Mankamana Mishra (mankamis)" <manka...@cisco.com>, The IESG <i...@ietf.org> Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "slitkows.i...@gmail.com" <slitkows.i...@gmail.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT) Hello Mankamana, Thank you for your constructive reply, please see below for EV> as I am afraid that your answers do not address completely my concerns. Regards -éric From: "Mankamana Mishra (mankamis)" <manka...@cisco.com> Date: Monday, 25 October 2021 at 20:26 To: Eric Vyncke <evyn...@cisco.com>, The IESG <i...@ietf.org> Cc: "draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org" <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "slitkows.i...@gmail.com" <slitkows.i...@gmail.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT) Hi Eric, Thanks for comment. Please find inline comment for blocking disucss . Mankamana From: Éric Vyncke via Datatracker <nore...@ietf.org> Date: Wednesday, October 20, 2021 at 1:28 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com> Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-bess-evpn-igmp-mld-proxy-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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 ? Mankamana : This draft covers what is EVPN related procedures. IGMP / MLD packets are generated by multicast host. And this document does not define any procedure about what needs to be done at host. Host is not even aware of presense of EVPN EV> AFAIK, MLD/IGMP packets are also generated by routers and not only by hosts, but this is a detail. EV> More important in my eyes: when one MLD/IGMP proxy receives some information via BGP, it also needs to forward the recreated MLD/IGMP locally to the attached hosts in order to be transparent. And I strongly believe that a short section on the document should describe the process. Hence keeping my blocking DISCUSS on this point. Are all multicast group address treated as the same ? I would have appreciated some text about link-local multicast as well as global multicast groups addresses. Mankamana : Since this draft transport all Valid IGMP / MLD join over BGP. It does not differentiate between different group range. All verification and handeling would be still IGMP / MLD router responsibility, so I do not think we would need to mention any of this. EV> thank you for the confirmation, I still believe though that this is worth mentioning in the text in one sentence. EV> I will 'degrade' this blocking DISCUSS into a non-blocking DISCUSS anyway. -- Abstract -- While this point is pretty light for a blocking DISCUSS, let's fix it: - the abstract should also mention MLD and not only IGMP - what are 'the above services' ? -- Section 1 -- In the same vein, is it about IGMP only ? Or does it include MLD as well ? It is really unclear. Mankamana : Added MLD in abstract. But later in terminology, it has been mentioned that even though we have used term IGMP, its valid for MLD too. For better redability, MLD has been not used in rest of document. EV> Thank you for fixing the abstract (I will clear my DISCUSS on this point), but, honestly using "IGMP" rather than "MLD" in 2021... this smells like a museum to my taste. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A very generic comment (but no need to reply): how can an IETF draft still prefers to use "IGMP" rather than "MLD" in the text in 2021 ? ... -- Section 1 -- When reading this section, I really and genuinely wonder what is "distributed anycast multicast router" ? AFAIK "any cast" and "multicast" addresses are vastly different. Anycast multicast is well known , and do not think there is need to mention it more in document about it. EV> rather than assuming that it is well-known, I strongly suggest to add a reference to this term or add it in the terminology section. If well-know, then let's copy and paste. -- Section 3 -- Is there any reason why the terminology is not alphabetically sorted ? Please also add 'BD'. Usually a terminology section is not only about acronym expansions but also about definitions. Done EV> Thanks -- Section 4.1 -- What is the definition of a 'first hop PE'? What is the difference with a EVPN PE ? EVPN PE is PE were EVPN is enabled. Not adding detail for some of obvious terminology. EV> It was not really obvious to me that using "first hop PE" is the same as "PE" which is the same as "EPVN PE". If so, why using different wordings rather than the simple "PE" (even if just to avoid confusing the reader- ? -- Section 4.2 -- May be that I overlooked it, but what is a 'proxy querier' ? IGMP spec defines need for Querier on LAN. EVPN provides mechanism to extend layer-2 network across core. And this draft defines mechanism to convert these local IGMP / MLD join to BGP routes and send it across core. Each of these location should have own Querier configured and refresh joins on behalf of other sites. EV> ok What is the difference between "EVPN core" and "MPLS/IP core" ? EVPN core is generic term, it could be SR / SRv6 / MPLS or IP underlay based. EV> then may I assume that section 4.2 and figures 1 and 2 are not applicable to all EVPN ? Should this be clearly explained in the abstract/introduction that this I-D is mainly about MPLS/IP core and not for all EVPN ? -- Section 5.1 -- What is "viz" ? (Sorry not being a native English speaker) viz introduce examples or further details to illustrate a point EV> Should then probably written as "viz." per wikipedia. I will let the RFC editor check whether this Latin expression is well-known. -- Section 8 -- Is there a difference between (*, G) and (x, G) ? (x,G) is generic term to denote both (S,G) and (*,G). EV> suggest to add something in the terminology section -- Section 9.1 -- Please formally specify "IE" as "include/exclude" (if not mistaken). done EV> thanks I find the description of the bits for MLD confusing, it really appears as a last-minute add-on to the text. Why not describing the MLDv1 in the same bullet as in IGMPv1 for the bit 7 ? IGMP and MLD have historically version number mismatch. So we added it independently to avoid confusion. IGMP has V1, V2, V3 and MLD has only V1 and V2. And for mapping IGMP V1 IGMP V2 ---- MLD V2 IGMP V3 – MLD V3 So I think keeping it independent would be better. EV> up to you Is "SHOULD" the right word for the sender of the reserved bits ? Especially as section 9.1.1. specifies a "MUST". Changed -- Sections 9.1, 9.2 -- The flags description appears to be different in the text while it seems to me that they have the same semantics. 9.2 adds little more text , may not no change needed. == NITS == Is it "ToR" or "TOR" ? ToR EV> then please update section 9.1.1 -- Section 4.1.2 -- Please use a consistent quoting in the document, e.g. in : IGMPv2 Leave Group (Leave) or IGMPv3 "Leave" Removed extra leave for V2 EV> I probably expressed myself badly, but there are double quotes around "Leave" and none around "Leave Group"
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
