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

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Dale,

Please refer to my replies inline marked with ³Ali>².

On 9/11/17, 4:51 AM, "Dale Worley" <[e-mail]> wrote:

>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.

Ali> Modified the 1st sentence of the last paragraph in section 1 for
better clarity.
>
>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).

Ali> Since this solution is an extension of EVPN (RFC7432 or RFC7623), the
PE configuration follow that of those RFCs. The configuration for the
scenarios 2.1 to 2.3 are implied in those paragraphs - i.e., 2.1 talks
about using (configuring) two Route Targets (which is well understood in
VPN community), section 2.2 recommends using a single RT and a given AC to
be colored (configured) by ³leaf² or ³root², and section 2.3 talks about
coloring specific MAC addresses.
>
>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.

Ali> Added the following sentence to the introduction section:
Ali> ³This efficiency is achieved by performing filtering of unicast
traffic on ingress PE nodes as opposed to egress filtering where the
traffic is sent through the network and gets filtered and discarded at the
egress PE nodes. The details of this ingress filtering is described in
section 3.1.²

>
>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.

Ali> The text that comes right after the RFC number is the title of that
draft. 
>
>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.

Ali> Done.
>
>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?

Ali> Its structure and its uniqueness is described extensively in RFC 7432.

Cheers,
Ali
>
>[END]
>
>