Re: [pim] Please respond! Re: draft-ietf-pim-explicit-tracking pim 2nd wglc

[Stig Venaas <[e-mail]>]

Hi

On 5/13/2013 10:40 PM, Hitoshi Asaeda wrote:
>>     Specific or Group-and-Source Specific Query messages transmitted from
>>     a router, and reduce the number of Current-State Report messages
>>     transmitted from member hosts.  If a router enables the explicit
>>     tracking function with "specific query suppression", it suppresses
>>     specific query transmission and transmits specific query messages
>>     only when the router expects that the State-Change Report sender is
>>     the sole member of the channel, based on its membership state
>>     information (expressed in Section 3.1).
>>
>> I believe it is fairly common to also suppress specific query when the
>> last member is leaving, in order to do "fast-leave". Basically
>> stopping
>> forwarding without having to wait for responses to specific queries.
>>
>> I vaguely remember we discussed this a couple of years ago...
>>
>> I was thinking of this when I wrote "fast-leave" above. If you can
>> expect the robustness to be tuned appropriately, this should be
>> fairly safe. See what I wrote regarding tradeoff above.
>
> Ok, so how about the following text added at the last part of the
> section titled "Lowering the Risk of Wrong Membership State"?
> (Do you have any suggestion of "may", "will", etc. in this para, too?)

Is this text replacing the one above?

>    In order to reduce the possibility of the incorrect membership
>    expectation and keep the up-to-date membership state information,
>    operators may configure the LMQC/LLQC value to 2 (the default value
>    of the [Robustness Variable] value) or bigger value for their
>    routers enabling the explicit tracking function with specific query

OK so far I think, but it might be better to restructure the paragraph.

>    suppression. However, if operators believe that their link is fairly
>    robust or that they can configure the [Robustness Variable] value
>    appropriately so that the chances of unsolicited messages being lost
>    are sufficiently low, they will enable specific query suppression
>    and configure both or either of the LMQC/LLQC value and the
>    [Robustness Variable] value to 1 for their routers.

This doesn't read well. First you say they can configure the robustness
value appropriately, and at the end you say it can be set to 1.

If you don't do last member queries, then I would think you probably
want it to be default or higher. It depends though.

I think we need perhaps a paragraph by itself explaining that when
Specific Query Suppression is enabled, implementations may skip doing
a specific query when the last known member leaves. This should add
some text saying that this assumes that the robustness variable is
configured appropriately so that the risk of the router missing the
unsolicited membership reports from a host is very low. Basically that
the unsolicited reports by themselves are sufficient for the router to
keep track of all the receivers.

This text probably belongs in 3.2? In 3.3 you could then refer to 3.2
and say that one way of shortening the latency is not to do specific
queries at all when last member is leaving. If specific queries are
sent, then LMQC/LLQC etc. matters.

Stig

> Regards,
> --
> Hitoshi Asaeda
>