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

Request Review of draft-ietf-bess-evpn-etree
Requested rev. no specific revision (document currently at 13)
Type Telechat Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-08-15
Requested 2017-07-25
Requested by Alvaro Retana
Other Reviews 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
Opsdir Telechat review of -13 by Carlos Pignataro
Review State Completed
Reviewer Ravi Singh
Review review-ietf-bess-evpn-etree-12-rtgdir-telechat-singh-2017-08-16
Posted at
Reviewed rev. 12 (document currently at 13)
Review result Has Nits
Last updated 2017-08-16



I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-etree-12
Reviewer: Ravi Singh
Review Date: 08/15/2017
Intended Status: Standards track

Summary: I have some concerns about this document that I think should be resolved before publication.

I've reviewed this draft.
Most of my comments fall under the category of "minor comments" and "nits".
The only major comments pertain to
a.       Sections 5.2/8.1: which appear like an overkill and could be considered for dropping from text.
b.      Need for a new section on the doc:
Include section to address this specifically: "Is (PBB-)EVPN being a *more efficient* implementation of E-Tree functions demonstrated?" This is relevant since the abstract makes a pitch for this draft addressing how PBB(-EVPN) implement E-tree functionality more efficientlky. However, it takes a fine-toothed comb to glean that info. Eg. First para in section 3.1. Nowhere else in the text has the efficiency aspect been explicitly addressed.  This aspect could use a section of its own.

1.       Abstract: very clear
2.       Section1 : Introduction:
a.       How about referring to "[RFC7432] is a solution for multipoint L2VPN services"  as EVPN more directly?
3.       Section 2: E-tree scenarios
a.       Section 2.1: for the sake of terminology clarification, please edit the text to not mention the acronym until the full-expansion has been listed. The draft does list the full-expansion. Just not before first using the acronym.
b.      Section 2.2: "
thus color MAC addresses via a "color" flag in a new extended community as detailed in section 3.1." should be referring to section 5.1 instead.
4.       Section 3: Operation of EVPN
a.       3.1: "Extended Community with a Leaf indication flag is introduced [section5.2]"  ->
"Extended Community with a Leaf indication flag is introduced [section 5.1]"
b.      3.3.1 (& section 5.2 as well): specifying (as this draft does) that the ingress PE X acting for a root entity, be able to dictate to a PE Y acting on behalf of a leaf entity, that PE Y should "ingress replication" or otherwise sounds excessive. Also, this draft does not make a strong enough case for the need for the modification to "PMSI Tunnel Attribute". Even if the foregoing was ignored, the draft does not address how PE X behaves should PE Y choose not to honor the setting of the "composite-tunnel bit".

5.       Section 4: Operation of PBB-EVPN: no specific comments. However, a little more detail would be useful to avoid having the reader repeatedly refer back to the PBB-EPVN RFC7623.

6.       Section 5: BGP encoding
a.       This looks like an unexpected section given the "abstract" and the "introduction" section.
The abstract and the introduction seem to indicate that no signaling changes are needed to make (PBB-)EVPN provide E-tree services. Abstract/introduction could use some rewording on this count.
b.      Minor typo:
5.1: "The received PE" -> "The receiving PE"

5.2: it would enhance readability if the flags were presented as
       0 1 2 3 4 5 6 7
      |C  |reserved  |L|
C = composite-tunnel bit

Anyway, as stated above this draft does not make a strong enough case for the need for the modification to "PMSI Tunnel Attribute". The value added by this modification to the PMSI tunnel-attribute seems marginal. A leaf

7.       Section 8: IANA considerations: it would be useful to include text about the name of "E-Tree Flags" registry in section 5.1 and correlate these 2 sections.
a.       Section 8.1: could be considered for dropping, in view of the previous comments on PMSI etc.
8.       Appendix A: too wordy. Could do with fewer better-chosen words to communicate the same message. Some minor singular/plural typos.