Reviewer: Antoine Fressancourt Review result: Ready with Nits 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
