Reviewer: Scott Bradner
Review result: Has Nits
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
