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? 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? 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? 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. 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. 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. Thanks, Rob _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
