Hi Martin, Thanks for comment, please find inline comment . Mankamana
From: Martin Duke via Datatracker <[email protected]> Date: Monday, October 11, 2021 at 4:15 PM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Martin Duke's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT) Martin Duke has entered the following ballot position for draft-ietf-bess-evpn-igmp-mld-proxy-13: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - It does not appear that you have fully addressed the TSVART comments (thanks Brian Trammell). Specifically, the (S,G) (*,G) definition is still not there. Mankamana : I looked at mVPN RFC (6513) , PIM RFC (7761) . all of them do use these terminology. But I could not find definition in either of them. Do we really need to define it ? want to make sure we do not put some definition which restricts the meaning of these generic terminology used in multicast across different documents. Will this be ok to add ? (*,G) – Any source multicast flow (S,G) – Multicast flow with source S and group G. Please advice. - In the abstract, it refers to "the above services" and I have no idea what that is referring to. Mankamana : Will change it to multicast service - Please expand MLD, NLRI, and DF on first use or in the glossary. Mankamana : will update (4.1.1) 1. When the first hop PE receives several IGMP Membership Reports (Joins), belonging to the same IGMP version, from different attached hosts for the same (*,G) or (S,G), it SHOULD send a single BGP message corresponding to the very first IGMP Membership Request (BGP update as soon as possible) for that (*,G) or (S,G). This is confusingly phrased, enough that I think it threw off the TSVART reviewer. There is no delay waiting for multiple joins; the PE just sends BGP for the first and ignores the rest. Or perhaps I've misunderstood? Please rephrase. Mankamana: Membership request are going to be received by IGMP (host protocol). If there are multiple ports locally, we may receive joins in each of the port. But BGP update is going to be done once. And it should be done ASAP . please let me know if this is still not clear. - Relatedly, if a PE receives (S, G) and later (*, G), should it withdraw the (S, G), since the latter join is a superset of the former? Mankamana: IGMP V3 RFC defines the group state in case of different joins being received on port. This draft does not change the base behavior. Rather let IGMP host protocol change the group state based on different joins. (9) It appears most of the fields in 9.1 through 9.3 are identical; it would shorten things dramatically if you either had a common section defining them or simply referred to Sec 9.1. Moreover, as this appears to be cut-and-paste, there are mistakes like 9.3 referring to "joins" when it's talking about leaves. These section Mankamana- Though content of these section are looking like identical, but they talk about different routes. * Selective multicast (routes needs to be processed by each supporting PE participating in same EVPN instance) * Multicast join sync (limited to multi-home peer only) * Multicast leave sync (limited to multi-home peer only) Making one common section would lead to too much of confusion for implementation. Thanks for catching typo, will change the join to leave. (9) as you observe that the Source Length can be zero-length for (*,G) routes, it would be useful to say that the group length can also be zero for (*,*) joins. (it might also to constrain it so that if the group length is zero, the source length MUST also be zero, unless (S, *) joins are possible). Mankamana – For IGMP driven join we would never have (*,*) join. But only for selective multicast we can have (*,*). I would update the selective multicast section.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
