Section 19:  Both RFC7432 and RFC 7623 are referenced, however RFC 7623 security considerations merely points to RFC 7432 and RFC4761, since RFC 7432 also points to RFC 4761, it is unclear why referencing RFC 7623 is necessary.

# Internet AD comments for draft-ietf-bess-evpn-virtual-eth-segment-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* It's not clear to me why this isn't just Informational.

### S3.3

* I get that this functionality is highly desirable, but is there some loss
  of interoperability among vendor equipment if it's not present?  In other
  words, why is this a MUST as opposed to SHOULD?

  Seems like the alternative is that the switching among neighbor EVCs is
  definitely less efficient, but could nevertheless be made to work.

### S3.4

* These don't seem like "requirements" to me, just service descriptions.

### S3.5

* R5a does not seem like a requirement.

# 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

I read the document but I surely didn't grasp a lot of things in there. The Security Considerations seem sane.

I don't understand why Section 9 is needed, and whether it adds or conflicts with the Copyright Notice. I suggest it be removed entirely.

Thank you to the authors for addressing my DISCUSS position so quickly and painlessly!


Also, thank you very much for writing this document.

# Éric Vyncke, INT AD, comments for draft-ietf-bess-evpn-virtual-eth-segment-18
CC @evyncke

Thank you for the work put into this document even if *it took 10 years* to get to the IESG evaluation stage ;-). John Scudder wrote a leading text that I fully share: `I found this document hard to review, for various reasons, so I don't really consider this a complete review.`.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Luc André Burdet for the shepherd's write-up including the WG consensus *and* the justification of the intended status. 

Other thanks to Brian Haberman, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-virtual-eth-segment-13-intdir-telechat-haberman-2023-09-06/ (and I have read Ali's reply)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)


### Abstract and section 1

It looks more like an acronym soup (i.e., difficult for me to understand what it is about) with a commercial ad twist `introduce a comprehensive suite of solutions`and `These solutions offer advanced features`.

s/This draft outlines/This document specifies/ as it is a proposed standard (similar cases happen through the whole document)

### Section 1.2

Once vES acronym is introduced, then there is no need to re-expand it multiple times.

### Section 3.5

This section is more on monitoring than OAM. Suggest renaming the section.

## NITS (non-blocking / cosmetic)

### Use of SVG

Suggest trying the "aasvg" tool to have nicer graphics in HTML/PDF rendering (worth a try).

I have serious readability concerns, but the RFC Editor will catch a lot of it. I'd like to focus on the problems that limited my understanding of this document.

The abstract is nearly impenetrable, thanks to dense acronyms and grammar mistakes. The verbiage is repeated in the Introduction. In particular

OLD
These solutions introduce Single-Active and All-Active for an Ethernet Segment (ES),
NEW
These solutions introduce Single-Active and All-Active redundancy modes for an Ethernet Segment (ES),

(S1.2) 
"In some cases, this aggregation of PWs that share the same LSP pair may not be possible. For instance, if PW3 were terminated into a third PE, e.g. PE3, instead of PE1, the vES would need to be defined on a per individual PW on each PE, i.e. PW3 and PW5 would belong to ES-1, whereas PW4 and PW6 would be associated to ES-2."

"defined on a per individual PW on each PE" is grammatically incorrect, but I think you mean that each PW gets its own vES. But that would mean that you need four ESs, not two.

(S2) Please add EVI and Ethernet A-D to the glossary