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

["Mankamana Mishra (mankamis)" <[e-mail]>]

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) <[e-mail]>
Date: Monday, February 7, 2022 at 7:11 AM
To: Mankamana Mishra (mankamis) <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>
Date: Thursday, 28 October 2021 at 13:49
To: "Mankamana Mishra (mankamis)" <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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)" <[e-mail]>
Date: Monday, 25 October 2021 at 20:26
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]>
Date: Wednesday, October 20, 2021 at 1:28 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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"