John Scudder has entered the following ballot position for draft-ietf-bess-evpn-virtual-eth-segment-16: 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/about/groups/iesg/statements/handling-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-virtual-eth-segment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # John Scudder, RTG AD, comments for draft-ietf-bess-evpn-virtual-eth-segment-16 CC @jgscudder Thanks for all your work on revising the document. I have moved to a NO OBJECTION position. I do have a few remaining questions/comments. ### Section 4.2.1, too many extcomms to carry in a single route In a reply to my earlier review, Patrice and Ali said, <PATRICE> There is a limited amount of BGP extcomm which can be carry by a single route. When that limit is exceeded, more routes are required. Ali> This is the same as RFC7432 where we need to send multiple “Ethernet A-D per ES routes” if we have a lot of Route Targets (more than 500 – e.g., 4k/8 = 500) Can one of you point me to the place in RFC 7432 where it explains when/how to do this? I tried looking for it and came up empty-handed, but RFC 7432 is long and I could easily have missed it. I'm guessing, in any case, that the trick to originating multiple A-D routes is to use a different RD per route (I see that the RD includes "a number unique to the PE" so I suppose that could be used). ### Section 5.5, are all the steps of the procedure really severable? This procedure is written such that each step is presented as independently optional. I suspect this is not your intention and that you mean for the procedure to be either entirely implemented or entirely not implemented. That is, the procedure as a whole is optional, but the steps aren't independent of one another. In my earlier review, we had this exchange: ``` Similar to the previous two sections, everything in the procedures is MAY, which means the procedures are completely optional and in fact, that it would be technically permissible to implement (for example) only points 2 and 5 and not points 1, 3, 4, and 6. Is this intended? What is the result if some or all of the MAY are disregarded by an implementation? <PATRICE> Same answer again, the mass-withdraw optimization won't happens.. vES is an "add-on" on top of RFC7432 and to avoid any current implementation breakage, MAY is being used. ``` I see the current version makes all the MAY into SHOULD. I think the question stands, though, and I'm afraid I don't find Patrice's previous answer comforting. I can see why you'd make the entire procedure, items 1-6, collectively optional, and that's what I understand Patrice to be saying. The problem is, the way the procedure is written now, I could legally implement some steps and ignore others. To repeat: Is this intended? So far, I think it is not. One way to change this might be something like, NEW: As discussed in [Section 3.7] it is highly desirable to have a mass‑withdraw mechanism similar to the one in [RFC7432]. Although such an optimization is desirable, it is OPTIONAL. If the optimization is implemented, the following describes the procedure: Followed by the list of steps 1-6, but with s/SHOULD/MUST/g... unless some steps truly are optional even in the context of "I have decided to implement mass-withdraw". (For example, I suspect the second SHOULD in step 4, for priority queuing Grouping route withdrawal messages, is truly optional.) Probably the NEW text above isn't 100% right, but I hope it communicates the idea, which is to factor out the OPTIONAL nature of the procedure such that implementing the procedure is an all-or-nothing affair. By the way, I think it would also be fine as part of the refactoring to remove all the RFC 2119 keywords from the procedure instead of turning them to MUST, for example, "Additionally, the PE SHOULD advertise a Grouping Ethernet A-D per ES" could become "Additionally, the PE advertises a Grouping Ethernet A-D per ES". That might assuage any worries about the top-level OPTIONAL conflicting with the individual step MUSTs. But this is just a matter of style and if you are attached to the RFC 2119 keywords I don't mind, as long as we're being clear about what, specifically, is optional/required. ## NITS: - s/one ore more/one or more/ - s/excludeds/excludes/ - s/virtual vES/virtual ES/ or s/virtual vES/vES/ ... no? It's not a virtual-virtual ES, right? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
