Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Here are my comments:

1. There are many different uses of multi-homing or the like in the draft, e.g., "multi-homing", "multihoming", "multihome", "multi-homed", "multihomed"; "non multihoming" vs "non-multihome", etc. The author needs to check through the document to make the usage consistent. There is a similar issue to "Broadcast Domain" vs "broadcast domain", "all-active" vs "all active", "Attachment Circuit" vs "attachment-circuit",etc.

2. For unwell-known acronyms, it's better to expand them upon their first use. This helps readers understand the context and prevents confusion.

3. There is a concept: multi-homed EVPN peers, but lack of definitions, some places in the draft also use "multi-homed PEs", "multihomed peers", "multihome peers", "peering PE", etc. I guess that they are the same meaning and should be used consistently through the document.  

4. 
Section 1.1
s/BD-1 has.../In Figure 1, BD-1 has...
s/belongs too/belongs to

5. 
Section 1.2
s/forearded to proper AC/forwarded to the proper AC

6. Section 3
1) I assume that the "service interface" is the new defined service interface in this document, am I right? If so, a "new" should be added before the "service interface", just as the requirements 5, 6 do.
2) Requirement 1 seems self-contridiction, multiple VLAN configured on an attachement-circuit, but each VLAN is represented by a different AC, how to understand this? Rewording or some clarification needed here.
3) Not sure the intention/meaning of requirement 2, clarification needed here.
4) Requirement 3 has been stated in the introduction section, IMHO, the entire section can be removed and put some of the requirement to other places (e.g., the introduction seciton, the place where the New service interface is defined.

7. 
Section 4.1.1.1 
s/PEs where.../At those PEs where...
s/An attach Attachment.../An Attachment...
s/MAC/IP route.../The MAC/IP Advertisement route
s/to EVPN RT-2/to EVPN Route Type 2 (RT-2)

8. 
Section 4.1.1.2
s/to attach remote MAC address to appropriate AC/to associate the remote MAC address to the appropriate AC

9. 
Section 4.1.2.1
Should the "local multihomed AC" be "local multihomed PE"?
s/must/MUST, same usage at other places, it needs to check through the whole document.

10. 
Sectionn 4.1.2.2
"route MUST be programmed to correct subnet", what's the meanning of this sentence? Rewording/clarification needed here.

11
Section 5
The current description looks like a general requirement, but does not define how to achieve this. IMHO, it'e better to move this section Section 6, as sub-section, and define the details on to detect this error with the BGP protocol processing. 

12.
Section 6.1
s/A new EVPN BGP Extended Community/A new BGP Extended Community
s/...called Attachment Circuit ID/...called Attachment Circuit ID Extended Community
Given the Sub-Type is allocated by the INNA, the "TBD" in the text and Figure should be update to specific value.

13.
There are 6 authors listed in the front page, according to the IESG/IETF policy, no more than 5 authors should be listed on the front page unless there is reasonable cause.