[bess] AD Review of draft-ietf-bess-spbm-evpn

["Alvaro Retana (aretana)" <[e-mail]>]

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