Multicast VPN State Damping
draft-ietf-bess-multicast-damping-06

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana Yes

(Jari Arkko) No Objection

Comment (2016-05-04 for -05)
No email
send info
Perhaps Joel Halpern's comment from the Gen-ART review might be something to consider as an edit:

>   Given that section 6.2 says that this applies to Ethernet VPNs [RFC7117], it would seem useful to mention this in the introduction.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2016-05-02 for -04)
No email
send info
Some questions from Bert, part of the OPS directorate review.


Question(s):
- top of page 11:

         The choice to implement damping based on BGP routes or the procedures described in Section 5.1, is
         up to the    implementor, but at least one of the two MUST be implemented. In the perspective of
         allowing damping to be done on RRs and ASBRs, implementing the BGP approach is recommended.

  Did you mean RECOMMENDED uppercase, or is the lower case intentional?
  I would think uppercase because in setion 7.1 it is stated/claimed that
  these procedures can be enabled on ASBRs and Route Reflectors.

  And in order to make this claim, the better be implemented, no?

- section 7.3 2nd para:      This section proposes default and maximum values, conservative so as to not significantly impact network dimentioning but still prevent I tried to find the work "dimentioning". But difficult to find. Does it mean the same as "domensioning"? From some description I get that  impression, but I am not sure. Maybe it is just my poor command of English that causes me troubles here?

nits: - page 3 towards bottom:

   of C-multicast routes".  This specification provides appropriate
   detail on how to implement this approach and how to provide control
   to the operator, and for this reason, in an update to [RFC6514].

   I guess s/in/is/ ?

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-05-03 for -04)
No email
send info


- A nit in section 3: just because simulations show X does
not mean that X will happen in the real world - is there
any other evidence that "using this technique will
efficiently protect..."? I don't mind if there isn't but
perhaps s/will/is hoped to/ or similar might be a good
idea if not.

- The secdir review [1] called out a few more nits.

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg06533.html

(Joel Jaeggli) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection