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]