Subject: [bess] Martin Duke's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 11 Oct 2021 16:15:08 -0700

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.

- In the abstract, it refers to "the above services" and I have no idea what
that is referring to.

- Please expand MLD, NLRI, and DF on first use or in the glossary.

(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.

- 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?

(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.

(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).

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 19 Oct 2021 16:02:33 +0000

Hi Martin,
Thanks for comment, please find inline comment .

Mankamana

From: Martin Duke via Datatracker <[email-masked]>
Date: Monday, October 11, 2021 at 4:15 PM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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

- 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.

Mankamana : Will change it to multicast service

Mankamana : will update

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.

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.

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.

---

From: Martin Duke <[email-masked]>
Date: Wed, 20 Oct 2021 14:15:43 -0700

+ Brian Trammell (the reviewer)

On Tue, Oct 19, 2021 at 9:06 AM Mankamana Mishra (mankamis) <
[email-masked]> wrote:

> *From: *Martin Duke via Datatracker <[email-masked]>
> *Date: *Monday, October 11, 2021 at 4:15 PM
> *To: *The IESG <[email-masked]>
> *Cc: [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>
> *Subject: *Martin Duke's No Objection on
> draft-ietf-bess-evpn-igmp-mld-proxy-13: (with COMMENT)
>
> 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 ?
>
> 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.
>
>
>
> 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.
>
>
>
>    - 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)
>
> 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.
>