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 Former IESG member
Yes
Yes
(for -04)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -04)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -05)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2016-05-02 for -04)
Unknown
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 IESG member
No Objection
No Objection
(for -04)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2016-05-04 for -05)
Unknown
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 IESG member
No Objection
No Objection
(for -05)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -04)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -04)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -05)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-05-03 for -04)
Unknown
- 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 IESG member
No Objection
No Objection
(for -04)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -04)
Unknown