Last Call Review of draft-ietf-bess-multicast-damping-04
review-ietf-bess-multicast-damping-04-opsdir-lc-wijnen-2016-04-23-00

Request Review of draft-ietf-bess-multicast-damping
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-03
Requested 2016-04-10
Authors Thomas Morin, Stephane Litkowski, Keyur Patel, Zhaohui Zhang, Robert Kebler, Jeffrey Haas
Draft last updated 2016-04-23
Completed reviews Genart Last Call review of -04 by Joel Halpern (diff)
Secdir Last Call review of -04 by Donald Eastlake (diff)
Opsdir Last Call review of -04 by Bert Wijnen (diff)
Assignment Reviewer Bert Wijnen
State Completed
Review review-ietf-bess-multicast-damping-04-opsdir-lc-wijnen-2016-04-23
Reviewed rev. 04 (document currently at 06)
Review result Has Nits
Review completed: 2016-04-23

Review
review-ietf-bess-multicast-damping-04-opsdir-lc-wijnen-2016-04-23

The document is more or less ready for publication I think.

It defines a few knobs that help operators control and
avoid uncontrolled control plane load increase in the core routing infrastructure.

It also defines default and recommended values for operators.
So it does/can have an impact on the operation of the
Internet, but I think it is a positive one.

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/ ? Bert