This is a well written document with a few issues that are editorial in nature. Firstly id-nits picks up a number of issues that need to be addressed: == Missing Reference: 'RFC4448' is mentioned on line 1115, but not defined == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: * If a network (inclusive of all PE and P nodes) uses entropy labels per [RFC6790] for ECMP load balancing, then the control word MAY NOT be used. -- The draft header indicates that this document obsoletes RFC7432, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8214, but the abstract doesn't seem to mention this, which it should. ======= 1.1. Summary of changes from RFC 7432 I wondered if the authors planned to keep this section or whether it was just used for development purposes? If it is planned to keep it it might be less intrusive to the flow of the text if it were made an appendix with a forward reference. ======== This means that for a given , a given MAC address is only reachable only via the PE announcing the associated MAC/IP SB> too many onlys ======== 18.1. Flow Label SB> There are many flow labels in different IETF protocols and so it took a few moments to figure out what was going on here. I gather that this is essentially a FAT label and given that what follows is a PW structure I wonder why the name was changed. SB> In any case I thing that it would be helpful to the user to include a stack diagram to show how it works rather than requiring the reader to figure it it out form some mildly dense text. ======== IANA has allocated the following EVPN Extended Community sub-types in [RFC7153], and this document is the only reference for them, in addition to [RFC7432]. SB> Given that this RFC obsoletes RFC7432 it seems wrong to call that up in the IANA section as a reference. Once this document is published RFC7432 cases to exist as normative text so it cannot be referred to as a definitive reference. 0x00 MAC Mobility [RFC7432] 0x01 ESI Label [RFC7432] 0x02 ES-Import Route Target [RFC7432] SB> Also the registries are already created so the IANA section of this document should I would have thought be an instruction to change the defining reference from RFC7432 to this document. SB> Again the following language is strange relative to an existing registry and my previous comments apply to this text. This document creates a registry called "EVPN Route Types". New registrations will be made through the "RFC Required" procedure defined in [RFC8126]. The registry has a maximum value of 255. Registrations carried forward from [RFC7432] are as follows: 0 Reserved [RFC7432] 1 Ethernet Auto-discovery [RFC7432] 2 MAC/IP Advertisement [RFC7432] 3 Inclusive Multicast Ethernet Tag [RFC7432] 4 Ethernet Segment [RFC7432] ============ SB> The acknowledgements section is very strange. Appendix A. Acknowledgments for This Document (2022) SB> It is not clear what version this applies to, if you keep it should have an RFC reference Appendix B. Contributors for This Document (2021) In addition to the authors listed on the front page, the following co-authors have also contributed to this document: SB> No names are in this section. Is it needed? Appendix C. Acknowledgments from the First Edition (2015) SB> Why not do the acknowledgements in narrative text rather than a set of appendixes? ======== SB> The way that the previous authors acknowledgements are done is also very confusing making it harder than needed to identify the authors of this text. I am also not sure that their contact details are still needed as this text replaces the previous documents and if they are really needed they are on file in the archived RFCs. SB> Please consider simplifying and possibly using a narrative text approach.