Hello,
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
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
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.
Feedback:
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.
Regards
Ravi
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
