[bess] Re: John Scudder's No Objection on draft-ietf-bess-evpn-virtual-eth-segment-16: (with COMMENT)

["Ali Sajassi (sajassi)" <[e-mail]>]

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 <[e-mail]>
Date: Monday, December 2, 2024 at 5:00 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Luc Andre Burdet (lburdet) <[e-mail]>, Matthew Bocci <[e-mail]>, [e-mail] <[e-mail]>
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/
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).

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://www.rfc-editor.org/rfc/rfc7432.html#section-8.2.1> 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
[ICT]: https://github.com/mnot/ietf-comments