Telechat Review of draft-ietf-bess-evpn-mh-pa-11
review-ietf-bess-evpn-mh-pa-11-intdir-telechat-fressancourt-2024-11-27-00

I am an assigned INT directorate reviewer for
draft-ietf-bess-evpn-mh-pa-11.txt. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as YES.

Overall, I found the document written in a clear way. Yet, the following are
issues I found with this document that SHOULD be corrected before publication:

- For people that have not read RFC 7432 or RFC 8584 recently, the document
starts rather abruptly. In particular, I was astonished that the PE, CE and
LACP acronyms are used in the document without a single mention of the name of
the entities they designate in full. I would either use the full name of those
entities in the text first to introduce the acronyms, or add a short
Terminology section to remind the reader about their meaning.

- I think the document would benefit a dedicated section giving an overview /
description of the principle of the Port-Active Redundancy mode. Indeed, in the
text, the principle of this mode is given with very little details as an
explanation of figure 1 at the end of section 2, and Section 3 starts with a
presentation of the overall advantages of the Port-Active Redundancy mode
without properly introducing it.

- I would present the overall advantages of the Port-Active Redundancy mode
after the description of the protocol's operations because, when you read
section 3.1 before learning about the way this redundancy mode is working, it
looks like a promotional pitch rather than a set of benefits one can assess. I
would rather place this text around the Applicability section.

- In section 3.2., paragraph c, the behavior associated with the MAY should be
clarified: what is happening if the PEs are exchanging other types of route? if
one PE tries to advertise another type of route?

- At the beginning of section 4, I think the authors should remind that the
selection of the DF algorithm is the result of a selection procedure for which
the DF Election Extended Community is used. Of course, it is clearly mentioned
in RFC 8584, but a short text reminding that would add clarity.