Re: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

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

Hi Rob,
Thanks for comment. Sorry, some how my outlook messed and this email was lost. Please find inline.  There is one modification based on your comment. Please let me know if change text looks ok to you. I will push the new revision.

Mankamana

From: Robert Wilton via Datatracker <[e-mail]>
Date: Thursday, October 28, 2021 at 7:16 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Robert Wilton's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I have to say that I found that the heavier use of
acronyms made this document somewhat harder to read.  I'm also not an expert in
these technologies.

My main question isn't directly actionably on this document, but I wanted to
check whether any updates to the EVPN YANG module are required to support this
functionality, and if so, is that work in progress, or planned?
Mankamana : Yang work in BESS working group are paused for now. So if there is any config change, it would be addressed once Yang model resumes.


Otherwise, I just had a couple of minor comments:

On 4.1.1.  IGMP/MLD Membership Report Advertisement in BGP

   When a PE wants to advertise an IGMP Membership Report (Join) using
   the BGP EVPN route, it follows the following rules (BGP encoding
   stated in Section 9):

   1.  ....  This is because BGP is a stateful protocol and
       no further transmission of the same report is needed.  If the
       IGMP Membership Request is for (*,G), then multicast group
       address MUST be sent along with the corresponding version flag
       (v2 or v3) set.

This implies to me that either the v2 or v3 flag is exclusively set, but
presumably it could also be both.  Would "add/or" be better than or?
Mankamana: in case of membership report with source filter, it would not be possible to set both version in same route. Later in document it has been mentioned that if (*,G) join for different version are received, we can set both flag.


Does OIF need to be an acronym, it doesn't seem worth it, and makes the text
harder to parse.  Is this a standard term used in other related docs?

Mankamana :  There was comment from IESG to better mention what OIF is, so it was added.

5.  Operation

In the paragraph of text above the diagram, perhaps more clearly indicate that
S1, S2 indicate multicast sources and R1 indicates a multicast router, and Hx
indicates hosts.
Mankamana:
Modified as “
                                      Consider the EVPN network of Figure-1, where there is an EVPN
                                                   instance configured across the PEs shown in this figure (namely PE1,
                                                   PE2, and PE3). Let's consider that this EVPN instance consists of a
                                                   single bridge domain (single subnet) with all the hosts, sources, and
                                                   the multicast router connected to this subnet. PE1 only has hosts(host denoted by Hx)
                                                   connected to it. PE2 has a mix of hosts and a multicast source. PE3
                                                   has a mix of hosts, a multicast source (source denoted by Sx), and a multicast router (router denoted by Rx).
                                                   Furthermore, let's consider that for (S1,G1), R1 is used as the
                                                   multicast router. The following subsections describe the IGMP proxy
                                                   operation in different PEs with regard to whether the locally
                                                   attached devices for that subnet are:”


9.1.  Selective Multicast Ethernet Tag Route

Rather than writing things like "second least significant bit", just writing
"bit 6" would seem to be clearer.
Mankamana :  I see similar terminology used even in base RFC7432. So may be it would be ok to keep it consistent.


9.1.1.  Constructing the Selective Multicast Ethernet Tag route

I was surprised that the lengths are specified in bits, not bytes.  I presume
that bits are used for consistency with other encodings.

Mankamana : Yes

Thanks,
Rob