Hello, this is the first time i do a RTG-DIR review using the new interface. I hope all the fields are properly filled automatically and mails sent accordingly.

Please note that the draft in in WG last call and an early review was requested. I'll assume this is a WG last call review.

All in all the document is almost ready for being progressed. I just suggested few improvements for better readability and understanding.

Here are my findings:

- Abstract: 
1) I would suggest rephrasing into:
"The existing EVPN multi-homing load-balancing modes do not adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. This document defines a new multi-homing mechanism to support these loop-preventing Layer-2 protocols"

2) My MPLS-TP is a bit rusty, but can it be considered a layer 2 protocol? and is it loop-preventing?

- Introduction: 
1)" Existing EVPN Single-Active and All-Active redundancy modes" add a reference to where they are defined.
2) you should also add a reference to G.8032, (M)STP, REP etc
3) same comment to MPLS-TP
4) the rest of the section is well written and understandable. It would be nice to have a small description of what a VLAN flow is to better explain why the need to have a flow active on a PE only but not all on the same.

- 2. Requirements
1) Again references to EVPN L2GW would help. Where do the "following rules" come from?
2) missing ESI expansions

- Section 3
1)i'd suggest finding a better way to show that the loop is open between CE4 and CE2. On first look i thought the simbol meant that the can be there many other nodes between CE4 and CE2.
2) it would be nice if the part of section 3 that comes before 3.1 introduced not only the example network but also the components of the solution. i.e the single-flow-active redundancy mode, fast convergenge etc

- Section 3.1
1)"Additionally, the reachability between CE1/CE4 and CE2 is achieved with the forwarding path through the EVPN MPLS/IP core side" does it mean via PE1-PE2?
2)"Therefore, aliasing of [RFC7432] Section 8.4 cannot be performed by PE3." suggest to rephrase in: Therefore the Aliasing procedure, described in Section 8.4 of [RFC7432] cannot be performed by PE3.

- Section 3.3
I dont' understand why an alternative solution (3.3.1) is described in the backwards compatibility section. Why not pulling it out from 3.3 and describing it as an alternative solution with limitations?

- Section 4
This section needs to be alaborated a bit more. As is, it is saying the same things as the IANA considerations. in addition to that if the document defines RED 10, why in the IANA considerations you have 00, 01 and 10?