Skip to main content

Last Call Review of draft-ietf-bess-multicast-damping-04

Request Review of draft-ietf-bess-multicast-damping
Requested revision 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 (Jeffrey) Zhang , Robert Kebler , Jeffrey Haas
I-D last updated 2016-04-23
Completed reviews Genart Last Call review of -04 by Joel M. Halpern (diff)
Secdir Last Call review of -04 by Donald E. Eastlake 3rd (diff)
Opsdir Last Call review of -04 by Bert Wijnen (diff)
Assignment Reviewer Bert Wijnen
State Completed Snapshot
Review review-ietf-bess-multicast-damping-04-opsdir-lc-wijnen-2016-04-23
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 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

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.

- 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

  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