[bess] AD Review of draft-ietf-bess-multicast-damping-03

["Alvaro Retana (aretana)" <[e-mail]>]

Hi!

I think that the title of this document clearly reflects what you want to do — which may be one of the reasons there was virtually no discussion about it (or any of its predecessors) on the list.  However, I think the contents leave many open doors that need to be closed before this document can be published.

I put more detailed comments below, but my main concerns are here:

  1.  The Abstract says that the procedures are "inspired from BGP unicast route damping".  It seems to me that the intent is in fact to adopt the algorithm from RFC2439.  However, the text is not explicit/clear about that.
  2.  As you all know, the history behind BGP damping has not been without it being considered useless and even having recommendations (from RIPE, for example) not to use it.  How did you arrive at the default and maximum values?  It concerns me that there are no known implementations (from the Shepherd's report).  Because of that, I think this document would be better suited as an Experimental RFC, with the explicit purpose of gaining experience with the values and determine the impact in live deployments (which then could support a standard version).  Please consider changing the intended Status.

According to the e-mail archive, it looks like an early presentation of this work happened in an mboned meeting, but I didn't find discussion on the pim or idr lists.  Once the comments below are addressed I will want to forward the document to pim/idr for their review.

Thanks!

Alvaro.


Major:

  1.  There are 6 authors listed on the front page.  According to RFC7322, the total number is generally limited to 5.  Please work among yourselves to cut the number of authors.  Alternatively, we can just list an Editor (there's one already identified)..or you can produce a justification detailing the contributions of each author to consider an exception.
  2.  Replace the reference to RFC4601 with a reference to draft-ietf-pim-rfc4601bis.  Note that the section numbers have changed slightly!
  3.  Are you adopting the exponential decay algorithm from RFC2439?  That seems to be what's happening because you are not explicitly defining a new algorithm, but some of the text leave doubts.  For example:
     *   "inspired from BGP unicast route damping"  I know the application is different, but if the algorithm is the same then please say it.
     *   Section 5.1. (PIM procedures)
        *   "updating the *figure-of-merit* based on the decay algorithm must be done prior to this increment"  This statement seems to directly imply that the algorithm is used.  Please reorder the steps to explicitly call this one out, instead of plugging it in as an afterthought.  BTW, should the "must" be "MUST"?  Ordering should help you not having to deal with that last question.
        *   "Same techniques as the ones described in [RFC2439] can be applied…"   "Can be"?  This sentence seems to imply that what is described in RFC2439 is optional.  Are there other ways of determining the same thing?  What about the exponential decay algorithm?
        *   It would also help if the terminology was consistent.  For example, instead of "damping becomes active" use "suppressed".  I can see how "suppressed" may give the wrong impression as only the propagation of state is affected.  Explaining then how the terminology applies would make it easier to reuse, avoid confusion and be clear.  Note that there's no mention of RFC2439 in the terminology section.
  4.  Section 3. (Overview): "…it is expected that this technique will allow to meet the goals of protecting the multicast routing infrastructure control plane without a significant average increase of bandwidth".  In general, I want to make sure that the qualities of the solution and the expected results are properly reflected in the document. [I'm using the text above as the base for my comment, but the impact is larger.]  Some questions:
     *   "…it is expected that this technique will…"  I wonder why an assertion can't be made that this technique can (vs just expecting that it will) address specific problems.  Is it the case that experience is needed to make a stronger assertion?  Are the goals the same (or at least similar) in every network?  Are there implementations available?  If so, please consider an "Implementation Status" section (see rfc6982).  What has been the deployment experience?  This goes back to my comment above about the Intended Status of this document.
     *   What specifically are the goals?  In a couple of places the text points back at Section 1. (Introduction), but I'm not sure exactly what the goals are.  Of special interest for understanding the goals is the part in Section 4.2. (Existing PIM, IGMP and MLD timers) where other solutions are discarded for not meeting them.
        *   There is scattered text that talks about "…ensure that the load put on the BGP control plane, and on the P-tunnel setup control plane, remains under control…", "protecting these control planes…avoiding negative effects…although at the expense of a minimal increase in average of bandwidth use…".   However, the description is too vague to point at what can satisfy these goals and what can't.
     *   Section 4.1. (Rate-limiting of multicast control traffic) mentions the "risk described in Section 1", which does mention "risks of denial of service attacks".  Is that the risk you're referring to, or something else?
     *   Section 4.3. (BGP Route Damping) mentions "the principle described in this document", which I thought was related to the goals, but Section 1 says that  the "base principle is described in Section 3".  I'm assuming the "principle" in question is such that a "network operator…can delay the propagation of multicast state prune messages between PEs, when faced with a rate of multicast state dynamicity exceeding a certain configurable threshold".  That sounds like a potential goal to me.
  5.  Section 5.2. (Procedures for multicast VPN state damping)
     *   In the Introduction you write that "Section 16 of [RFC6514] specifically spells out the need for damping the activity…"  I think that RFC6514 does a lot more than that:  Section 16.1. (Dampening C-Multicast Routes) "proposes OPTIONAL route dampening procedures similar to what is described in [RFC2439]."   Those procedures look very similar to the ones in this document.  What is the difference?  Is the intent of this document to complement, replace or maybe update what is already specified in RFC6514?
     *   There's an rfc2119 conflict.   "…then the withdrawal of a C-multicast route…SHOULD NOT be damped.  An implementation of the specification in this document MUST whether, not damp these withdrawals by default, or alternatively provide a tuning knob to disable the damping of these withdrawals."  s/whether/either   The "MUST..not damp" and "SHOULD NOT be damped" are in conflict.    I think that eliminating the last sentence would fix the problem and still allow an implementation to put in any knobs that it wants.
  6.  Section 7.3. (Default and maximum values) lists values that are "RECOMMENDED to adopt as default conservative values".  Any guidance about when and/or how an operator should consider changing the recommended defaults?  What does "conservative" mean in this context?  What if the operator wants to be more aggressive?


Minor:

  1.  In 4.2
     *   s/prune override interval/J/P_Override_Interval
     *   Reference for explicit tracking..??  BTW, how would the mechanism in this document interact with explicit tracking?
  2.  Section 5.1. (PIM procedures):
     *   "…a router implementing these procedures MUST…apply unchanged procedures for everything…".  I guess that these "unchanged procedures" are the ones in rfc4601bis, right?  In other words, what you seem to want is that, in addition to what rfc4601bis specifies, for the other steps defined in this document to happen.  If that is correct, please reword the description to make it clear — at least put a reference so that there is no question about which procedures are left unchanged.
     *   "…freeze the upstream state machine…and setup a trigger to update it…"  Maybe a word like "hold" or "maintain" might be better.  In fact, even better would be an explicit indication that "events that may result in the state changing [rfc4601bis] SHOULD be ignored until the reuse threshold is reached", or something along those lines.  What should the state be updated to when the reuse threshold is reached?
     *   I had some trouble parsing this text: "When the recompilation is done periodically, the period should be low enough to not significantly delay the inactivation of damping on a multicast state beyond what the operator wanted to configure (i.e. for a *decay-half-life* of 10s, recomputing the *figure-of-merit* each minute would result in a multicast state to remained damped for a much longer time than what the parameters are supposed to command)."    I think I got it…but what I don't get (based on my understanding of RFC2439) is that the figure-of-merit should decay according to the half-life, so I don't get why its value would be adjusted at a period that is not related to the half-life.
  3.  Section 5.2. (Procedures for multicast VPN state damping)
     *   There are several places in this section where rfc2119 language is used to describe what an implementation should do that sound to me as an attempt to define functionality that is mandatory to implement (MTI).  I find that hard/impossible to enforce and would like to see the rfc2119 language removed.  Please see below..
     *   The text says that an "implementation of [RFC6513] relying on the use of PIM to carry C-multicast routing information MUST support this technique."  That "MUST" is really strong and it makes me think that this document should then be marked as an update to RFC6513.  Is that the intent?  Reading through it again, is the intent MTI?
     *   "…the following procedure is proposed as an alternative to the procedures in Section 5.1…"  "proposed"??  Does this mean that 5.1 is also applicable in this case (when "BGP is used to distribute C-multicast routing information")?   It sounds like the operator would have an option — if so, when should each be considered?
        *   Later in the same section you wrote: "…choice to implement damping based on BGP routes or the procedures described in Section 5, is up to the implementor, but at least one of the two MUST be implemented."  I think it should be section 5.1.  Do you really mean the "implementor", or are you referring to the operator of the network?  The "MUST" sounds too strong for me because it is not needed for interoperability (rfc2119) -- or is this an attempt at MTI?
        *   Same question/observation for "In the perspective of allowing damping to be done on RRs and ASBRs, implementing the BGP approach is RECOMMENDED."  Maybe s/RECOMMENDED/recommended
     *   "…it can be considered useful to also be able to apply damping on RRs as well."  When is it considered useful?
        *   Note that later you also write: "…in such a context, it is RECOMMENDED to not enable any multicast VPN route damping on RRs…"   This partially answers the question.  It would be nice to put the guidance together.
     *   "…damping SHOULD NOT be applied to BGP routes of the following sub-types…"  Are there cases when it is ok?  In other words, why is the "SHOULD NOT" not a "MUST NOT"?
  4.  Section 6.1. (Damping mVPN P-tunnel change events) "Possible ways to do so depend on the type of P-tunnel, and local implementation details are left up to the implementor.     The following is proposed as example of how the above can be achieved."  Either you leave it as an implementation detail or you provide guidance.  If this document was Experimental, then providing guidance it great!


Nits:

  1.  Please put references on first appearance.  For example, IGMP and MLD are mentioned in the introduction, but no reference is made until the 5th mention.  The same for BGP route damping…
     *   You also need a reference to route reflectors.
  2.  "these control planes"  Which control planes?  Please be specific.   There are other places where "these" is uses that may not be completely clear..please take a look.
  3.  s/these specifications/this specification
  4.  s/when enabled /when enabled,
  5.  "PIM-SM specifications [RFC4609]"   RFC4609 is not the PIM spec.
  6.  Section 6.2. (Procedures for Ethernet VPNs)  "…an implementation of these procedures MUST follow the procedures described in Section 6.1."  It is not completely clear which "these procedures" are.  I'm guessing RFC7117.