Applicability of EVPN to NVO3 Networks <draft-ietf-nvo3-evpn-applicability>

The ID is an applicability statement describing how to use Ethernet
   Virtual Private Network (EVPN) technology in NVO3 networks.  

Note that while the term NVO3 is widely used in the ID it is never cleanly defined – the closest definition is in section 2 but that actually defines “NVO3 or Overlay tunnels” as “Network Virtualization Over Layer-3 tunnels” but the introduction talks abut “NVO3 networks” not “NVO3 tunnels” – the definitions need to be cleaned up (and as Reese Enghardt points out, should be expanded on first use)

Introduction: 
	The introduction says “In NVO3 networks, Network Virtualization Edge (NVE) 
devices sit at the edge of the underlay network and provide Layer-2 and Layer-3 
connectivity among Tenant Systems (TSes) of the same tenant.  The NVEs need 
to build and maintain mapping tables so that they can deliver encapsulated 
packets to their intended destination NVE(s).”

	The last part confuses me – is the delivery to Network Virtualization Edges or to 
Network Virtualization Edge devices? -If it is to “edges” I do not know what that means. 
Looking at the rest of the text maybe the definition should read “Network Virtualization 
Edge devices (NVEs)” or be referred to as “NVE devices”. Maybe the problem is that to me 
An edge is not a “thing” – instead it is geography – (e.g., the edge of the road)

Section 2:
Under ARP & ND – I’d expand slightly “Address Resolution Protocol (IPv4) and Neighbor Discovery protocol (IPv6). – might save someone a few minutes trying to find ND in IPv4 documentation

The rest of my comments are stylistic based on personal preference and are not suggestions to do a lot of work to change things – I find that using acronyms for common terms makes a document harder to read – for example using BD instead of broadcast domain – e.g. 

“EVPN VLAN-based service model: one of the three service models defined in [RFC7432].  
It is characterized as a BD that uses a single VLAN per physical access port to attach
tenant traffic to the BD.  In this service model, there is only one BD per EVI.”

Would be easier to read if each of the “BD” where just replaced with “broadcast domain”

This ID seems to go out of its way to maximize the number of acronyms where, in my opinion, 
The document would be a lot easier to read if the actual terms were used instead – of course,
Using an acronym for a protocol that is generally known by that acronym is quite reasonable 
Such as ND for neighbor discovery but I do not see that using “ES” instead of “Ethernet Segment” is a net plus for readability and clarity.

Along the same lines – using the number of the row in Table 1 instead of the description is not an advantage – e.g., using “RT-5 routes” instead of “IP Prefix routes” may save a few bytes but is no where as easy to understand.  

Overall - the set of figures and the detailed explanation of each of them provides a great deal 
Of information on how to use Ethernet Virtual Private Network (EVPN) technology in NVO3 
Networks but I find the descriptions hard to follow for someone not deeply involved in the
Technology due to the density of acronyms per square inch of text.