Re: [Gen-art] Genart telechat review of draft-ietf-bess-evpn-etree-13

Thanks for the review. I agree and updated my ballot to point to your review comments as well!

> Am 11.09.2017 um 13:51 schrieb Dale Worley <worley@ariadne.com>:
> 
> 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]
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art