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 <nore...@ietf.org> Date: Thursday, October 28, 2021 at 7:16 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org <draft-ietf-bess-evpn-igmp-mld-pr...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.i...@gmail.com <slitkows.i...@gmail.com> 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
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
