Hi!
I think the general readability of the document could improve. See below for
some suggestions. While that is not a showstopper, I would like to see my
comments about the Security Considerations (see below) addressed before
starting the IETF Last Call.
Thanks!
Alvaro.
Major:
1. Security Considerations.
* The first two paragraphs talk about incorrectly connecting islands
together, due to misconfiguration (in what looks like two different causes).
While probably nothing can be done from the "EVPN core" point of view, it would
be a good idea to recommend potential actions to be taken to prevent further
problems; for example, you already say that the identifiers are "only policed
in the SPBM domains” — maybe try rewording that as a recommendation (“care
should be taken at the SPBM domains, etc.”). This is important because the
privacy of the users information could be compromised if the frames are
delivered to the wrong place.
* The last paragraph says “most of the issues”. What issues are not
reflected in rfc4761?
* What about considerations related to other pieces of the solution?
Why aren’t they mentioned? Are they covered somewhere else?
Minor:
1. Please expand EVPN and ECT. PBB (and other acronyms) are in the list of
well-known abbreviations. I know that there is a Terminology section, but we
still should expand of first use specially in the Abstract/Introduction and
Tittle. BTW, ECT is not listed in the Terminology.
[https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt]
* There’s a mixture of acronyms that are defined in-line (e.g.
"Shortest Path Source ID (SPSourceID)”), acronyms not defined (DA), expansions
used without the acronym (e.g. "designated forwarder”) and a whole slew of
others where the reader is expected to check the Terminology section out. It
would be nice if there was some consistency in the treatment.
2. The References need to be re-formatted. One case (for rfc7432) it is
referenced as "IETF work in progress”.
3. Section 4.8 says that multicast support is not addressed. However,
Section 5.1 talks about multicast.
Nits:
1. Introduction s/permit both past, current and emerging future
versions/permit past, current and emerging future versions
2. Section 1.1. Authors is not needed.
3. Section 3
* s/to be seamlessly communicate/to seamlessly communicate
* The formatting (spacing) needs some work.
* Figure 1 is nice, but there’s no text referring to/explaining it.
4. IANA considerations. Use "This document has no IANA actions."
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
