Multicast VPN State Damping
draft-ietf-bess-multicast-damping-06

[Ballot comment]
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.

[Ballot comment]



- 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

[Ballot comment]
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/ ?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-bess-multicast-damping-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: aretana@cisco.com, martin.vigoureux@nokia.com, bess-chairs@ietf.org, draft-ietf-bess-multicast-damping@ietf.org, bess@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multicast VPN state damping) to Proposed Standard


The IESG has received a request from the BGP Enabled Services WG (bess)
to consider the following document:
- 'Multicast VPN state damping'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-04-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes procedures to damp multicast VPN routing
  state changes and control the effect of the churn due to the
  multicast dynamicity in customer sites.  The procedures described in
  this document are applicable to BGP-based multicast VPN and help
  avoid uncontrolled control plane load increase in the core routing
  infrastructure.  New procedures are proposed inspired from BGP
  unicast route damping principles, but adapted to multicast.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-bess-multicast-damping-03 ===

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.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard is requested and indicated in the title page header.
This type of RFC is consistent with the body of the specification.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes procedures to damp multicast VPN routing
  state changes and control the effect of the churn due to the
  multicast dynamicity in customer site.  The procedures described in
  this document are applicable to BGP-based multicast VPN and help
  avoid uncontrolled control plane load increase in the core routing
  infrastructure.  New procedures are proposed inspired from BGP
  unicast route damping principles, but adapted to multicast.

Working Group Summary

  This Document has been presented several times before the WG at IETF meetings.
  There was good support to adopt it as a WG Document.
  There have been fewer opinions expressed at the time of WG Last Call,
  however the specification was already quite stable at the time of its adoption as WG Document

Document Quality

  The Document is of good quality, clearly written and easy to understand.
  There are no known implementation at that time but it is on the roadmap of at least one vendor.

Personnel

  Martin Vigoureux is the Document Shepherd
  Alvaro Retana is the Responsible AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd has done a detailed review of the Document,
which is now ready for Publication request.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concern

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No portion of the Document needs a particular review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have stated that they are not aware of any relevant IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure exists against this Document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No such threat

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID nits result is clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No need for such formal review.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No such Normative reference

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No Downward Normative reference

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The publication of this Document will not change the status of any existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The Document makes no request to IANA which is consistent with the body of the Document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registry requested.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No need to validate any specific section