Skip to main content

Multicast VPN State Damping
RFC 7899

Yes

Alvaro Retana

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Joel Jaeggli)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

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

Alvaro Retana Yes

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -04)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -05)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -05)

                            

(Ben Campbell; former steering group member) No Objection

No Objection (for -04)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2016-05-02 for -04)
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/ ?

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2016-05-04 for -05)
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.

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -05)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -04)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -04)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -05)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-05-03 for -04)


- 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

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -04)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -04)