[bess] Genart telechat review of draft-ietf-bess-evpn-etree-13

[Dale Worley <[e-mail]>]

Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.  Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document:  draft-ietf-bess-evpn-etree-13
Reviewer:  Dale R. Worley
Review Date:  2017-09-12
IETF LC End Date:  2017-08-09
IESG Telechat date:  2017-09-12

Summary:

This draft is basically ready for publication, but has nits that
should be fixed before publication.

There are a few matters that I would like to see amplified in the
Introduction to improve the exposition for readers who aren't familiar
with this area.

1.  Relationship to RFC 7432.  The Introduction now states "Since this
document specifies a solution based on [RFC7432], it requires the
readers to have the knowledge of [RFC7432] as prerequisite."  This is
a significant improvement, but I still find this unsatisfyingly vague
regarding the relationship between the two documents.  Is RFC 7432
only background knowledge, or is this document an
extension/modification of RFC 7432, in which case, some parts of the
technique described in this document are actually defined in RFC 7432?
It seems a minor change of wording of this sentence could make this
clear.

2.  Management:  The document doesn't describe how the EVPN structure
will be set up (e.g., how endpoints are added or deleted from the
structure, what MPLS labels will be used), nor how choice of the many
technology alternatives will be communicated (e.g., 2.1 vs. 2.2
vs. 2.3; approach A vs. approach B).  I suspect that this is normal
for documents defining VPN techniques, but it seems peculiar for me,
as the areas I'm familiar with (SIP and data-center networking) try to
minimize the amount of "configuration" that needs to be done.  It
might help the reader to list in the Introduction what aspects of
set-up are out of scope for the document, and conversely, what aspects
you've arranged for the control plane to handle automatically (which
are benefits of the technique).

3.  Efficiency:  The Abstract and the final paragraph of the
Introduction mention that this technique is more efficient than that
of RFC 7796, and of course that is a major motivation for this work.
But the nature of the improved efficiency is only detailed in section
3.1.  It would help the reader, I think, to mention the nature of the
improved efficiency in the Introduction, and perhaps to mention the
specific traffic patterns where this improved efficiency is
particularly effective.  This helps the reader know when reading the
document will be particularly valuable.

There are a few nits I noticed:

Abstract

   solution based on RFC7432, BGP MPLS Based Ethernet VPN (EVPN), with
   some extensions and how such a solution can offer a more efficient
   implementation of these functions than that of RFC7796, E-Tree
   Support in Virtual Private LAN Service (VPLS). This document makes

In the same way as you quote the title of RFC 76387, it would be more
readable if you quoted the titles of the other two RFCs.

1  Introduction

   Attachment Circuits (AC) (e.g., an Ethernet tag but may also be
   represented by a MAC address) is labeled as either a Root or a Leaf

I assume "tag" means 802.1q VLAN tag, but it would be helpful to spell
that out.

1.2  Terminology

   Ethernet Segment Identifier (ESI): A unique non-zero identifier that
   identifies an Ethernet segment is called an 'Ethernet Segment
   Identifier'.

What universe is the ESI is unique over?

[END]