## COMMENT

### Section 1

   Some service providers have very large number of ACs (in millions)
   that need to be back hauled across their MPLS/IP network.  These ACs
   may or may not require tag manipulation (e.g., VLAN translation).
   These service providers want to multiplex a large number of ACs
   across several physical interfaces spread across one or more PEs
   (e.g., several Ethernet Segments) onto a single VPWS service tunnel
   in order to a) reduce number of EVPN service labels associated with
   EVPN-VPWS service tunnels and thus the associated OAM monitoring, and
   b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is
   the case in [RFC8214]).

As far as I can tell, (b) isn't satisfied by the "VLAN-Signaled Flexible Xconnect" mode, because in that mode "the PE sends a single Ethernet A-D per EVI route for each AC that is configured".

I don't have a problem with you providing a menu of different options to meet different operators' needs, but I think the Introduction should be clearer about this. 

As an aside, I found the "some service providers... these service provider" writing style of the Introduction to be unusual and a little distracting. 

### Section 1.1, terms that aren't needed here

These terms are defined, never referenced:

- CE
- EPL

These terms are defined, only used once, so you might as well just expand them in-line:

- EVPL (already expanded in-line)
- L2 (your single use is in a diagram, so if you don't want to clutter it, OK, 
  though the expansion would fit. But unlike many of the abbreviations in this 
  document, I don't think this one actually needs definition.)
- MTU (same comment as for L2. This one is starred as "well-known" on the RFCEd 
  list of abbreviations. I've asked the RFCEd why "L2" isn't starred.)
- VCCV

PW is used twice but really, there is no savings in time, space, or readability, from defining and then using an initialism. I suggest just writing out "pseudowire" those two places. One of them precedes the definition anyway.

RT is used 3x but defined in-line each time so you don't need a definition here.

VRF has a typo. You've called it "Virtual Route Forwarding". But https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list says it is "Virtual Routing and Forwarding". Although RFC 4364 is the authority AFAICT and it says "VPN Routing and Forwarding table" which I think is better -- "table" is important.

### Section 3.1, VLAN-Aware bundle

I can't understand what this means:

   *  VLAN-Aware Bundle : a unique value for individual VLANs, and is
      considered same as the normalised VID.

I was hoping it would become clear as I read the rest of the document, but it didn't. Indeed this is the only place "VLAN-Aware Bundle" is mentioned.

### Section 3.1, ASBR

Please expand ASBR on use.

### Section 3.2, how do PEs know about VLAN mappings?

   Regarding the data-plane aspects of this solution, both imposition
   and disposition Provider Edge (PE) devices MUST be aware of the VLANs
   as the imposition PE performs VID normalization and the disposition
   PE carries out VID lookup and translation.
   
I guess the assumption is that this is done through configuration, hopefully through a management system. I think the document really has to say this somewhere, even if the precise means of doing it is out of scope. It seems like a fundamental assumption, but it's never spelled out.

### Section 3.2, SHOULD ideally

                                               There SHOULD ideally be a
   single point-to-point (P2P) EVPN VPWS service tunnel between a pair
   of PEs for a specific set of Attachment Circuits (ACs).

It's hard for me to understand this use of RFC 2119 SHOULD. Normally RFC 2119 keywords tell the protocol implementor what to do. I don't see how an implementor could do anything with this, though. Sometimes, RFC 2119 keywords are (ab)used to tell operators how to deploy a solution. I *think* that's what you're doing here, but if so I think at a minimum, you have to be much clearer about that, something like, "When deploying the solution, the operator SHOULD ideally provision a single..." I also encourage you to drop the RFC 2119 keyword, and just use "should".

### Section 3.2 VID-VRF

I think you need to put "VID-VRF" in your Terminology section, or otherwise define it.

### Section 5, VCCV-BFD

You mention VCCV-BFD, but you don't have a reference for it. Please add one.

### Section 5, switchover procedure

                                                                the
   switch over procedure to the backup S-PE is the same as the one
   described above.
   
I don't see any switchover procedure described above. What am I missing?

## NITS

- In Section 3.2, "The generated EVPN route is an Ethernet A-D per EVI route with and ESI of 0" should be "The generated EVPN route is an Ethernet A-D per EVI route with an ESI of 0" ("an" not "and").