+ Brian Trammell (the reviewer) On Tue, Oct 19, 2021 at 9:06 AM Mankamana Mishra (mankamis) < [email protected]> wrote:
> 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
