Hi John, Thank you for your review and comments. A new revision will be posted after the pre-IETF119 quiescence period.
Please see zzh> below. -----Original Message----- From: John Scudder via Datatracker <nore...@ietf.org> Sent: Wednesday, March 6, 2024 8:08 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-bess-evpn-irb-mc...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; manka...@cisco.com; manka...@cisco.com Subject: John Scudder's No Objection on draft-ietf-bess-evpn-irb-mcast-11: (with COMMENT) [External Email. Be cautious of content] John Scudder has entered the following ballot position for draft-ietf-bess-evpn-irb-mcast-11: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!A78Ta3ONdPXEoLQIN_Gt40k6a96liTui1TPt4pd7phW8_rrv8UPDH6pB3ufNR90lr3bDTnxSm3NQbOQ$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/__;!!NEt6yMaO-gk!A78Ta3ONdPXEoLQIN_Gt40k6a96liTui1TPt4pd7phW8_rrv8UPDH6pB3ufNR90lr3bDTnxSbovfttY$ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. Although dense and slow going, I appreciated the thoroughness and precision and have confidence that the dedicated reader who makes it all the way through will be able to implement this specification. I have some minor comments below that I hope might be of use. - I continue to find the profligate use of acronyms and initialisms that characterizes so many bess documents to be an unnecessary, not to say gratuitous, impediment to readability, but so it goes. (If the authors are open to what might be an extensive revision to address this, I'm willing to dig in and provide more detailed feedback. But I don't expect it, at this late stage, especially since as noted above, I do think the document is usable, my complaint notwithstanding. If I'm mistaken, let me know and we can work on it.) Zzh> Let me work with you separately on addressing this problem going forward in general. - I agree with Éric Vyncke that there are several places where the text could easily be elucidated with the use of a diagram. Essentially, any of the many (very welcome!) examples seems like an easy candidate, one instance being “Suppose a given Tenant Domain contains three BDs (BD1, BD2, BD3) and two PEs (PE1, PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.” Zzh> I added the following for the example you give: SBD SBD / \ / \ +---+ +---+ |PE1+----------------------+PE2| +---+ +---+ | \ / | BD1 BD2 BD2 BD3 Zzh> I had to change the format of this email from plain text and use Courier New font. Hopefully it comes out aligned. - I'm sure the RFCEd will flag this, but consider replacing the pronoun "he" in Section 1.3 with something not gender-specific. Zzh> I changed it to “it”. I suppose we can use “it” for a “tenant” because we’re talking about an organization not a person. - In Section 1.5.2 you mention an “attachment AC”, which expands as "attachment attachment circuit". Probably drop "attachment" or (better still in my view, see my first bullet) spell out "attachment circuit". Zzh> I spelled it out. - In Section 2.5 you have “This does assume that source S does not send the same (S,G) datagram on two different BDs, and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP "anycast" addresses is outside the scope of this document?” I tried to puzzle out what the consequence would be if that situation arose, but failed. Can you comment? Zzh> Let me quote the context below. If all the sources and receivers for a given (*,G) are in the Tenant Domain, inter-subnet "Any Source Multicast" traffic will be properly routed without requiring any Rendezvous Points, shared trees, or other complex aspects of multicast routing infrastructure. Suppose, for example, that: * PE1 has a local receiver, on BD1, for (*,G) * PE2 has a local source, on BD2, for (*,G). PE1 will originate an SMET(*,G) route for the SBD, and PE2 will receive that route, even if PE2 is not attached to BD1. PE2 will thus know to forward (S,G) traffic to PE1. PE1 does not need to do any "source discovery". (This does assume that source S does not send the same (S,G) datagram on two different BDs, and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP "anycast" addresses is outside the scope of this document.) zzh> If the source host is also connected to another BD3 that is attached to PE2 and it is sending to both BD2 and BD3, then both copies will be switched to PE1 via the SBD. Zzh> Thanks! Zzh> Jeffrey Juniper Business Use Only
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
