[bess] AD Review of draft-ietf-bess-mvpn-bidir-ingress-replication-02

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

Hi!

I just finished reading this document.  In general I think that there are some things that could be done to improve the readability/clarity.

While the authors address the items below, I’ll start he IETF Last Call and put the document on the IESG Agenda (probably for Oct/15).  Please post an update before Oct/8.

Thanks!

Alvaro.


Major:

  1.  I-D.ietf-bess-ir and I-D.ietf-bess-mvpn-extranet should be Normative References.

Minor:

  1.  Update to rfc6514:  Please include a short paragraph (or a couple of sentences) explaining how this document updates rfc6514 (maybe in the Introduction).
  2.  Even though the text says that terminology is somewhere else, please expand the acronyms on first use.  Also, some of the text ("C-G-BIDIR refers to a C-G where G is a Bidir-PIM group”, for example) may not be accesible to the average reader, even if extensions are in place — you already included some background in the Introduction  and I’m not sure we want to rehash everything again..just something to think about.  You might want to refer to the RFC Editor’s list of well known abbreviations: https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
  3.  I think there are some references missing, for example: "Bidir-PIM, or via MP2MP mLDP”
  4.  Section 3.1. (Control State):
     *   What do you mean by "just like how any other S-PMSI A-D routes are triggered”?  I’m thinking that at least a reference is needed.  Later is the same paragraph you include an example as well.  Please clarify what you’re referring to.
     *   Do we really need this text 3 times in the section?  "The label may be shared with other P-tunnels, subject to the anti-ambiguity rules for extranet [I-D.ietf-bess-mvpn-extranet].  For example, the (C-*,C-*-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can optionally share a label."
     *   The paragraphs that start with "The encoding of the Leaf A-D route…” are also duplicates.
  5.  Section 4. (Security Considerations)  Are there really no security considerations?
     *   Section 3.1. (Control State)   Says that: "To speed up convergence…PEy MAY advertise a Leaf A-D route even if does not choose PEx as its Upstream PE…With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of Upstream PE while some will arrive with a different label, and the traffic in the latter case will be discarded.”  I’m assuming that all the traffic (specially the discarded one) belongs to the same VPN, so there’s no danger of leaking information, right?  It might be worth including something in the Security Consideration so that it’s easier for the readers (Security Directorate, for example) to grasp the context.

Nits:

  1.  Abstract  s/These specifications/This specification
  2.  s/wrt/with regards to
  3.  Introduction: s/Ingress Replication,this/Ingress Replication this