Telechat Review of draft-ietf-bess-evpn-etree-13

Request Review of draft-ietf-bess-evpn-etree
Requested rev. no specific revision (document currently at 14)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-09-12
Requested 2017-08-30
Authors Ali Sajassi, Samer Salam, John Drake, Jim Uttaro, Sami Boutros, Jorge Rabadan
Draft last updated 2017-09-11
Completed reviews Rtgdir Telechat review of -12 by Ravi Singh (diff)
Genart Last Call review of -12 by Dale Worley (diff)
Opsdir Last Call review of -12 by Carlos Pignataro (diff)
Genart Telechat review of -13 by Dale Worley (diff)
Opsdir Telechat review of -13 by Carlos Pignataro (diff)
Assignment Reviewer Dale Worley
State Completed
Review review-ietf-bess-evpn-etree-13-genart-telechat-worley-2017-09-11
Reviewed rev. 13 (document currently at 14)
Review result Ready with Nits
Review completed: 2017-09-11


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

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


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

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:


   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

What universe is the ESI is unique over?