I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l2vpn-etree-frwk-06
Reviewer: Ben Campbell
Review Date: 2014-07-14
IETF LC End Date: 2014-07-15
Summary: This draft is almost ready for publication as an RFC, but I have a few
minor issues and editorial comments that may be worth consideration prior to
publication.
Major issues:
None
Minor issues:
-- I suggest removing the 2119 language. Ignoring the general controversies
over whether informational RFCs should use 2119 language, I don't think it fits
for _this_ draft. In particular, all the small number of normative language
instances seems to be either statements of fact or restatements of requirements
that are defined elsewhere. These would all be better served with descriptive
language.
-- Section 4, paragraph after Table 1: "If direct Layer 2 Leaf-to-Leaf
communication needs to be prohibited, E-Tree should be used."
That sounds more like advocacy than architecture/framework. Do you mean to
suggest that other potential solutions (if any) should not be used, or that
E-Tree is somehow the best solution? Or did you mean to say "E-Trees are
appropriate for whenever..."?
-- Similarly, 2 paragraphs down: "An E-Tree service can meet these use case
requirements."
That also sounds like advocacy. This draft doesn't seem to do a requirements
analysis for those use cases, beyond an assumption that they need inter-leaf
isolation at Layer 2. Something to the effect of "E-Trees can meet the common
requirement to avoid the exchange of frames between Leaf CAs." would be more
appropriate.
-- 5.1 and 5.2:
5.2 seems like the same "gap" as discussed in 5.1, just from a perspective of
CA role vs forwarding constraint. Handing around constraints vs roles seem more
like solution questions than requirements or architecture questions.
-- 5.3, First sentence:
The first sentence seems like yet a further restatement of the issue from 5.1
and 5.2. (The rest of the section seems reasonably distinct from the others.)
-- Security Considerations:
The security considerations mostly say that e-trees have to act like e-trees. I
think there is room for more discussion. Are the e-tree rules sufficient for
scenarios where inter-leaf isolation is critical for security reasons? Does it
remove needs for higher layer protections? (I hope not.) The guidance to use
IPSec if additional security is required is not entirely satisfying here--how
would an higher layer protocol know whether or not it had a fully protected
path?
Are there trust issues between PEs? Can one PE assume that another will enforce
the leave/root constraints? Can it trust that the other PE has the same idea of
what should be a leaf vs root? Is there a need for one PE to determine if
another supports E-Trees at all?
Nits/editorial comments:
-- 2.2, 4th paragraph: "Furthermore, MEF also defines AC roles. One
role is Root and another is Leaf."
Are these the same usages as defined in this document? If so, it might be
helpful to attribute these in the terminology section.
-- 2.3, 2nd paragraph: "... distinct differentiation for multicast groups in
one VPN."
I suggest "... distinct differentiation among multicast groups in the same VPN."
-- 3: Figure 1
The figure is two pages from the paragraph that describes it. I suggest moving
Figure 1 to either before or after the first paragraph in the section.
-- 3, first paragraph "This implies that an Ethernet frame from CE01, CE02, etc
will be treated as a frame originated from a Root AC; a frame
from CE03, CE04, etc will be treated as a frame originated from a Leaf AC."
Treated by what? (Consider restating in active voice).
-- 3, last paragraph before Figure 1: " A VSI on a PE corresponds to an E-Tree
instance ..."
This can be read to imply a 1-to-1 cardinality between "A VSI on a PE" and "an
E-Tree instance". I don't think that is intended.
Also, is an "E-Tree instance" the same thing as and "E-Tree service instance",
as mentioned elsewhere?
-- Section 4, paragraph after Table 1:
Can you provide a reference and/or expansion for LTE X2? (I think LTE may be
on the well-known abbreviation list, but I'm not sure about X2).
-- Section 4, last paragraph:
Unless you mean to say that broadcast video is a significant driver for this
work, this paragraph seems off topic.
-- Section 5 and subsections
Section 5 needs additional proof reading for missing articles and
singular/plural mismatches.
-- Normative References:
The two IEEE references seem more like informative rather than normative ones.