Hi Ali, Thanks, LGTM. Regarding my question on "too many extcomms to carry in a single route”, thanks for your answer. I wonder if it would be worth adding that reference (“… as specified in Section 8.2 of [RFC7432]…”). I leave it up to you, though.
—John On Dec 4, 2024, at 12:52 AM, Ali Sajassi (sajassi) <saja...@cisco.com> wrote: [External Email. Be cautious of content] Hi John, Thanks again for your review. I updated the document to rev18 incorporating your comments. Please refer to my resolution inline … From: John Scudder via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Date: Monday, December 2, 2024 at 5:00 PM To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org> <draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Luc Andre Burdet (lburdet) <lbur...@cisco.com<mailto:lbur...@cisco.com>>, Matthew Bocci <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com><laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com>> Subject: John Scudder's No Objection on draft-ietf-bess-evpn-virtual-eth-segment-16: (with COMMENT) 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/<https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!AE_ekWwkvr9azZMEIt_X8lAg9qrliSTUW2mGMZW6pbmtzpc4J7So2dmIQh2VKk-CY2nzUDbYhyO4$> 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/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/__;!!NEt6yMaO-gk!AE_ekWwkvr9azZMEIt_X8lAg9qrliSTUW2mGMZW6pbmtzpc4J7So2dmIQh2VKk-CY2nzUNRok4uV$> ---------------------------------------------------------------------- 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). Ali> Yes, that’s exactly correct. From section 8.2: “This is done by having each PE advertise a set of one or more Ethernet A-D per ES routes for each locally attached Ethernet segment (refer to Section 8.2.1<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7432.html*section-8.2.1__;Iw!!NEt6yMaO-gk!AE_ekWwkvr9azZMEIt_X8lAg9qrliSTUW2mGMZW6pbmtzpc4J7So2dmIQh2VKk-CY2nzUFJ-Fr5S$> below for details on how these routes are constructed). A PE may need to advertise more than one Ethernet A-D per ES route for a given ES because the ES may be in a multiplicity of EVIs and the RTs for all of these EVIs may not fit into a single route. Advertising a set of Ethernet A-D per ES routes for the ES allows each route to contain a subset of the complete set of RTs. Each Ethernet A-D per ES route is differentiated from the other routes in the set by a different Route Distinguisher (RD).” ### 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. Ali> You are correct. The whole procedure is optional (and not the steps within it). So, what I will do is to mention that right up front and remove “SHOULD” from all the step. 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: Ali> Thanks for providing the text. I will incorporate it. 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.) Ali> I am impressed with your level of attention to details ☺ The Priority queuing indeed should remain optional – i.e., “should”. 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. Ali> I agree that it is better to remove RFC2119 language. ## 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? Correct Ali> All done. Cheers, Ali ## 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<https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!AE_ekWwkvr9azZMEIt_X8lAg9qrliSTUW2mGMZW6pbmtzpc4J7So2dmIQh2VKk-CY2nzUGaB6Nk8$> [ICT]: https://github.com/mnot/ietf-comments<https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!NEt6yMaO-gk!AE_ekWwkvr9azZMEIt_X8lAg9qrliSTUW2mGMZW6pbmtzpc4J7So2dmIQh2VKk-CY2nzUH_1QXY-$>
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
