Subject: Re: [pim] AD Review of draft-ietf-pim-explicit-tracking

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 19 Jun 2015 04:32:24 +0000

On 5/29/15, 9:57 AM, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi!

I’ll take a closer look at the text when I get a warmer feeling that the original concerns in the IESG have been addressed.

I didn’t get a warmer feeling from the earlier discussion, but I went ahead and read the draft in more detail anyway.  I probably should have done this to start with.

There are several issues with the draft that make me think that it is not ready yet.

In general, the writing style feels tentative and speculative at times.  For example, in the Introduction (see the first bullet below in the Minor section for more details) statements like this are made: “specifications not clearly given” (no specification exists!), “important..and might be widely deployed” (might?), “it could seriously break..wrong implementations..may not work properly” (no details!), “This document aims to get the explicit tracking function correctly”.  This last statement made me stop writing comments below and decide to point out the need for a stronger, assertive voice in writing this document: “This document defines the explicit tracking function, which is very important in the scalability of multicast networks and should be pervasively deployed everywhere!” (Just an example).

The same style continues into what should be the normative sections of the draft, resulting in what seems to be a string of optional suggestions with no guidance.  I’ll talk more about that in a second..  The style/tone should be improved..

If I didn’t miss anything, the explicit tracking mechanism consists of the following:  keeping track of the membership state (Section 3) + query suppression (Section 4) + (robust link state (Section 4) OR shortening leave latency (Section 5)).  Did I miss anything?  I want to specifically talk about each of these components (and the sections in which they are described):

  1.  keeping track of the membership state:  this seems to be the only mandatory to implement part of this draft, and because it describes a data structure, there’s no way to verify that an implementation actually did it as described.
  2.  Query Suppression:  off by default!
     *   “..the default behavior of the router that supports the explicit tracking function SHOULD disable this specific query suppression..”  If specific query suppression is to be disabled by default, what are the guidelines for it to be turned on?
  3.  Robust Link State: optional!
     *   “..MAY define an option called “robust link state”…requires that the router perfectly tracks all member hosts.”  Since robust link state is optional, what are the guidelines of when it should or not be used?  Because in the end tracking the members is all a game of odds (of loosing reports/requests), what conditions lead to “perfectly” tracking membership?
  4.  Shortening Leave Latency: also optional!
     *   "The default values for LMQI/LLQI defined in [2][3] are 1 second, yet, for a router enabling the explicit tracking function, the LMQI/LLQI may be set to 1 second or shorter.”  [2] and [3] already say that reducing these intervals should reduce leave latency.  If enabled, should 1 sec be the default?  Or is that just a suggestion?  Please provide some guidance on the settings; there may be a significant difference in behavior between 1 second and “shorter”.
     *   “…yet the LMQC/LLQC may be set to 1 for the router.”   Is the setting a suggestion (optional) or is it what should be implemented?  When should a router set these intervals to 1?  Please provide some guidance.

The specification of the function then comes down to an internal implementation and some optional actions with no implementation guidance.

It looks like in this paragraph (in Section 5) you are attempting to provide some guidance:

      Furthermore, if operators are confident that their link is fairly
   robust (e.g., the [Robustness Variable] value is appropriately
   configured so that the chances of unsolicited messages being lost are
   sufficiently low), and if the querier router always acts as the
   forwarder router for all multicast channels in the LAN, they will set
   smaller LMQC/LLQC and shorter LMQI/LLQI (and hence shorter LMQT/LLQT)
   with the specific query suppression, or enable the specific query
   suppression with a robust link state (Section 4) for their routers.

If this is the guidance, there is still no clear indication of when..; I have some more questions:

  1.  What does “fairly robust” mean?  Are there guidelines (maybe in a different document) about changing the [Robustness Variable]?  Note that both [2] and [3] say that the [Robustness Variable] "MUST NOT be zero, and SHOULD NOT be one. Default value: 2”.    I’m wondering what the experience with changing this value is, given that the default is pretty much the lowest possible number already.  Does “sufficiently low” mean that the network is “fairly robust” using the default value?
  2.  In this section the language sounds a little stronger than before (“will” instead of “may”).  Is this then a suggestion or what an implementation should do?
  3.  Then there’s that “or” (“..will set smaller..and shorter. .with specific query suppression, or ..specific query suppression with robust link state”).  When should the short leave latency be implemented instead of robust link state?

Note that the following paragraph (in Section 6), which seems to provide guidance form the negative case, doesn’t help either:

   If operators do not believe that their link is fairly robust or that
   they can configure the [Robustness Variable] value appropriately,
   they may configure the LMQC/LLQC value to 2 (the default value of the
   [Robustness Variable] value) or bigger value for their routers.  In
   this case, the routers would enable the explicit tracking function
   but may want to disable the specific query suppression specified in
   Section 4.  Such configurations will not contribute to saving network
   resources, but reduce the risk of the incorrect membership
   expectation.

It again talks about “fairly robust” and setting the "[Robustness Variable] value appropriately”..but it is not specific (“2 or bigger”).

On to Section 9.  (Interoperability) and the Intended Status.  I think that this section completely breaks the point of having the behavior in the document be standard because it makes statements such as “..various ways to implement the explicit tracking..and the function or mechanisms described in this document do not break the interoperability between the existing implementations and the implementation based on this specification.”.  If pretty much any implementation is interoperable, then why use this specification? Going back to the mechanism itself, the only mandatory to implement part is the internal piece.

It is clear in the draft that the reason why everything is optional is the risk of wrong membership state.  This is not a risk exclusive to explicit tracking, but a general one.  Unfortunately the result is that nothing is really specified as part of the explicit tracking mechanism and by default we end up with just an internal implementation of a data structure.  And the risk is not reduced and may even be increased if some recommendations are followed (see my comment bellow about Section 6).

In summary, I strongly urge the WG to reconsider the intended status of this draft.  Being clear on guidance and adding implementation status information (rfc6982) may help.  If no specific guidance is possible, then I would suggest considering an Experimental status to collect experience and then opt for a Standard state.

I do have other minor comments (below) and some nits.

Thanks!

Alvaro.

Minor:

  1.  Section 1 (Introduction)
     *   “..provide the ability to keep track of the downstream (adjacent) multicast membership state in multicast routers, yet the specifications are not clearly given.”  I’m not sure what you mean by the last part.  Do you mean that neither MLDv2/IGMPv3 specify how to do it even though they opened the door (by not suppressing listener reports)?  If so, then it is not that the “specifications are not clearly given”, but that the facilities are there.  I like how rfc3810 put it: “..the lack of host suppression in MLDv2 makes possible to implement either proprietary or future standard behavior of multicast routers that would support per-host tracking, while being fully interoperable with MLDv2 listeners and routers that implement the exact behavior described in this specification."
     *   "The explicit tracking function is important for the scalability of multicast networks, and might be widely implemented in modern multicast routers.”  Did you mean “can be widely implemented”, or are you talking about potential existing implementations?
     *   "However, it could seriously break IGMP/MLD communications if not implemented or configured correctly.  For example, the explicit tracking function is useful for shortening leave latency, while wrong implementations or configurations in routers on a LAN may not work properly that the operators expect.”  This part didn’t really provide any insight on the potential problems, it just said that if the implementation is not correct or is misconfigured bad things may occur, but didn’t explain how.  More details come later, but this first part should at least point at the later sections.
     *   "This document aims to get the explicit tracking function correctly.”  It better be correct if it’s going to be a standard! ;-)
     *   ..there are more places where the text shouldn’t be as tentative and speculative as it is..
  2.  Section 3. (Membership State Information) “..if a router receives an (S,G) join/leave request with EXCLUDE filter mode from the downstream hosts..”  rfc5790 says that EXCLUDE (S,G) join is not supported.  Also, what does an EXCLUDE (S,G) leave mean?
  3.  Section 4. (Specific Query Suppression)  “..if the router receives one or more replies from the downstream member(s), it SHOULD stop..”   Before receiving the State-Change Report (at the beginning of the sequence), the router probably knows a set of members already.  Does the “downstream members” refer to known members or any member?
  4.  Section 6. (Risk of Wrong Membership State)  This risk is not specific to explicit tracking, right?  The second case may actually be made worse if the LMQT/LLQT are lowered (from Section 5).  I think it should be made clear that, in general, this risk exists anyway.
  5.  Section 7. (All-Zero and Unspecified Source Addresses) "According to this specification, whether the explicit tracking function is used or not, a router does not deal with a member hosts sending an MLD report message with the unspecified source address.”  Take that sentence out: the behavior is not changed from [3].
  6.  Section 9.  (Interoperability)
     *   “..it is RECOMMENDED to refer and follow this specification as the standard..”  You can’t really specify (using rfc2119 language) that people follow this document.  They will follow if it provides value.
  7.  Section 11. (Security Considerations)  “..to mitigate such threats, ..limit a total amount of membership information the router can store..”.  I understand the potential threat of running out of resources, but limiting the membership that a router can keep track of seems to render the function useless as there might be cases in which the only information (or most) the router keeps track of is the attack itself. :-(

Nits:

  1.  Section 7. (All-Zero and Unspecified Source Addresses)
     *   s/since the host has not yet acquired an IP address/since the host may have not yet acquired an IP address
     *   s/report messages correctly as defined/report messages as defined
     *
"the router SHOULD NOT maintain the host specifying all-zero source address in its membership state information”  Why not “MUST NOT”?