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

Hi

Some comments on this (as an individual contributor).

On 5/7/2013 12:44 AM, Bharat Joshi wrote:
> Hi Hitoshi,
>
>       Please see my responses in line.
>
> Regards,
> Bharat
>
>>>> 1. In Abstract, can we remove the usage of 'fast leave' and just
>>>>> keep 'shortening leave latency'. A quick google search on 'fast
>>>>> leave' shows that it is a known term in the context of IGMPv2 where
>>>>> a router does not send the group specific query and stops
>> forwarding
>>>>> multicast traffic for the group on that interface. As here 'fast
>>>>> leave' is not referring to a similar behavior, I suggest to use
>>>>> 'shortening leave latency' instead.
>>>>
>>>> Fast leave itself is a general terminology. It does not specific only
>>>> for the IGMPv2's procedure. For example, see rfc3810 (MLDv2).
>>>
>>> RFC 3810 defines a normal leave in IGMP term as fast leave. I am not
>>> sure why that term was used in MLDv2 RFC. If someone on the list
>>> knows, I would want to know.
>>>
>>> As this draft talks about both IGMP/MLD, and as 'Fast leave' is
>>> known as two different things in IGMP and MLD, to keep abstract
>>> protocol independent, I would suggest to not use 'Fast leave' in
>>> this draft.
>>
>> RFC3376 also says;
>>        Routers may want to track per-host membership status on an
>>        interface.  This allows routers to implement fast leaves (e.g.,
>>        for layered multicast congestion control schemes) as well as track
>>        membership status for possible accounting purposes.
>>
>> First leave is common terminology, not dedicated for IGMPv2.
>> (BTW, also you can see the word, "accounting", here as the potential
>> use case.)
>
> Ok.

Even though I'm fine with the term "fast leave", I think the abstract
reads better if it just says:

    This document describes the IGMP/MLD-based explicit membership
    tracking function for multicast routers supporting IGMPv3/MLDv2.  The
    explicit tracking function contributes to saving network resources
    and shortening leave latency.

There is no need to introduce any terms in the abstract, the main thing
is that the leave latency is shorter.

>>>>> 3. In third par of section 1, first sentence seems complex to me.
>>>>>
>>>> Ok, I'll simplify the sentence to the following;
>>>>
>>>>     Multicast routers send periodic queries within the General Query
>>>>     timer interval (i.e., [Query Interval] value defined in [1][2]) to
>>>>     keep the membership state up to date.
>>>
>>> I am fine with this text. But are you sure you do not want to
>>>   mention solicited reports in and around this sentence. Previous
>>>   sentence was trying to bring out that synchronization happens
>>>   because general query triggers solicited reports.
>>
>> Use of solicited reports is mentioned in the second paragraph, so it's
>> Ok.
>
> Ok.
>
>>> So I think it would be better to explain this in couple of sentences
>>> if you want to keep them in the draft. I understand that this may be
>>> out-of-scope of this draft but as this draft is suggesting that
>>> explicit tracking function is helpful in these two cases, it is
>>> better to explain how.
>>
>> Giving too much explanation for out-of-scope topics leads confusion.
>> As rfc3376 does, this draft should simply show the potential use
>> cases.
>> Let's keep them as is, and if I get the similar concern from others,
>> I'll remove these use cases.
>>
>
> I was not suggesting to add too much explanation. But it will be better if you can add some details or refer to another document/draft.
>
>>>>> 8. In section 3.2, in first sentence,
>>>>>
>>>>> In accordance with [1] and [2], whenever a router receives the
>> State-
>>>>> Change Report, it sends the corresponding Group-Specific or Group-
>>>>> and-Source Specific Query messages to confirm whether or not the
>>>>> report sender is the sole member host.
>>>>>
>>>>> Can we reword the above because router does not always send
>>>>> Group-Specific or Group-and-Source Specific Query messages whenever
>>>>> it receives a State-Change Report? We can reword it to:
>>>>>
>>>>> In accordance with [1] and [2], whenever a router receives the
>> State-
>>>>> Change Report, it might send the corresponding Group-Specific or
>>>> Group-
>>>>> and-Source Specific Query messages to confirm whether or not the
>>>>> report sender was the sole member host.
>>>
>>> What I was trying to point out is that when a router receives
>>>   State-Change report, it does not always send a specific
>>>   query. Please refer to the table in section 6.4.2 in RFC 3376. So
>>>   the above statement is not fully correct. A router sends specific
>>>   query in only few cases.
>>
>> Ok, I understand your point.
>> I'll slightly change the sentence as follows;
>>      ... whenever a router receives the State-Change Report messages
>>      and changes its router state, it sends the corresponding
>>      Group-Specific or Group-and-Source Specific Query messages to
>>      confirm whether or not the report sender is the sole member host.
>
> The point I was trying to put across is that "router might send" as it depends upon the state of that channel so the updated sentence still says 'it sends the corresponding' which I feel is not correct.

I agree this text needs to change. It says "whenever a router receives
the State-Change Report messages and changes its router state", which
means that for any such change a specific query is sent. But there are
state changes where you do not send a specific query. E.g. if a host
adds a new source (top row in the table in RFC 3376 section 6.4.2), a
specific query is not sent.

>>>>> Please also note the change of 'is' to 'was' in the last part of
>> the
>>>>> sentence.
>>>>
>>>> I don't think "is" is wrong.
>>>
>>> The host had sent a state-change report because the host does not
>>> want traffic for the channel. Router sends a specific query. Router
>>> needs to confirm whether there is any more members for this
>>> channel. So router is confirming whether the host was the last
>>> member or not. That is why I suggested to use 'was'.
>>
>> I understand your thought, but still I prefer to use "is" here,
>> because the router needs to confirm the current state, not the
>> previous state the report sender sent the report.
>> Let's see IESG reviewer's comment.
>
> Ok. I will leave this to the working group and IESG.
>
>>>>> 11. A similar issue exist when LMQC and LLQC is explained in the
>> above
>>>>> para.
>>>>
>>>> I don't think so, because this sentence comes from rfc3810.
>>>
>>> I think my comment was not clear here. What I was saying about the
>>> following sentence was:
>>>
>>> The [Last Member Query Count] (LMQC) and [Last
>>> Listener Query Count] (LLQC) are the number of Group-Specific Queries
>>> or Group-and-Source Specific Queries sent before the router assumes
>>> there are no local members.
>>>
>>> The last part of the sentence mention that router assumes there are
>>>   no local members after sending these many queries while router
>>>   assumes there are no local members only when LMQT expires. I was
>>>   trying to point out this difference.
>>
>> Your understanding is correct, and the original statement is also
>> correct.
>> The router sends specific queries these times before it assumes there
>> are no local members. This statement is described in both rfc3376 and
>> 3810. Also, this statement does not inconsistent the statement, "the
>> router assumes there are no local members when LMQT/LLQT expires",
>> what you said.
>
> Ok. I was just trying to avoid little confusion with the above sentence.
>
>>>>> 12. Last para of section 3.3 tries to describe how a lower values
>> of
>>>>> LMQI/LMQC then the default suggested, can shorten the leave
>>>>> latency. But it does not clearly articulate how explicit tracking
>>>>> function helps if the two parameters are configured to the lower
>>>>> values. Can we add some details on that here?
>>>>
>>>> LMQI/LLQI are the standard values defined in rfc3376 and 3810. All
>> the
>>>> details and configurations are mentioned in them, and I believe
>>>> repeating these descriptions in this document wouldn't be needed.
>>>
>>> I think you did not get my question. Let me rephrase this.
>>>
>>> Without explicit tracking function, if we lower the LMQI or LMQC or
>>> both, leave latency can be reduced.
>>>
>>> With explicit tracking function also, if we lower the LMQI or LMQC
>>> or both, leave latency can be reduced. So what is the
>>> differentiation explicit tracking function is bringing in here?
>>
>> Comparing with no tracking condition, the explicit tracking function
>> lowers the risk of wrong membership expectation. Therefore with the
>> explicit tracking function, LMQI/LLQI can be shorter and LMQC/LLQC can
>> be smaller than both default values.
>> This is the reason that this doc says;
>>     the LMQI/LLQI MAY be set to 1 second or shorter. The LMQC/LLQC
>>     values MAY be set to 1 for the router, whereas their default values
>>     are the [Robustness Variable] value whose default value is 2.
>
> I am not sure if I follow you. Explicit tracking function might be lowering the risk of wrong membership expectation but is not eliminating it.
>
> So from a real would perspective, why would an administrator would lik to reduce leave latency if he is not sure about something.
>
>>>>> 13. In section 4, in 3rd para, in following sentence:
>>>>>
>>>>> The second case occurs when a router sends a specific query but
>> does
>>>>> not receive a State-Change Report from a downstream host within an
>>>>> LMQT or LLQT period.
>>>>>
>>>>> I think when a host receives specific query, it generates a
>>>> current-state
>>>>> report. Right?
>>>>
>>>> Right.
>>>> As the document says "membership expectation will be inconsistent due
>>>> to an outdated membership state", this section describes the
>> situation
>>>> in which report messages sent by downstream members are not reached
>> to
>>>> the router due to some trouble.
>>>
>>> What I was trying to point out is that the sentence mention the
>>> 'State-change' report while a host generates 'Current-state' report
>>> when it receives a specific query so should the sentence be using
>>> 'Current-state' report.
>>
>> Oh, good catch. It's typo. Thanks.
>
> Ok.
>
>>>>> 14. As host membership protocols are unreliable, there will always
>>>>> be a possibility of outdated membership state as packets may get
>>>>> lost. I am not sure how does explicit tracking function lowers this
>>>>> possibility.
>>>>
>>>> This document does not say that the explicit tracking function lowers
>>>> that possibility. This section discusses how to lower the
>> possibility.
>>>> If people misunderstand the point, I'll clearly say,
>>>>      Regardless whether the explicit tracking function is enabled or
>>>>      not, there are possibilities that a router's membership
>>>>      expectation is inconsistent due to an outdated membership state.
>>>> at the beginning of this section.
>>>
>>> I think there are two issues here:
>>>
>>> The section title is misleading. When I was reading the draft, I got
>>> an impression that explicit tracking function is lowering the
>>> possibility of outdated membership.
>>
>> Ok, then how about, "Lowering the Risk of Wrong Membership
>> Expectation"?
>
> It still does not indicate that we are talking about this when explicit tracking function is enabled. I would like to see something like:
>
> Lowering the Risk of Wrong Membership Expectation with Explicit Tracking function enabled

I think it should be something else. Wrong Membership Expectation sounds
like someone (a person) is expecting the membership to be wrong.

How about say "Lowering the Risk of Wrong Membership State"?

>>> Second issue is that the section also does not clarify this clearly.
>>
>> So as I said how about adding the followin sentence at the beginning
>> of this section?
>>
>>     Regardless whether the explicit tracking function is enabled or
>>     not, there are possibilities that a router's membership
>>     expectation is inconsistent due to an outdated membership state.
>
> Ok. With the above suggested type of title and your suggested text, things will be far more clearer.
>
>>>>> 18. In section 6, should not we talk about how the membership state
>>>>> information is deleted when the version is lowered and the channel
>>>>> is no more required.
>>>>
>>>> Do you mean the following "MAY NOT" is not suitable for this document
>>>> as it's implementation dependent?
>>>> "the router MAY NOT flush the maintained membership state
>> information"
>>>> If so, I could agree. I'll change "MAY NOT" to "may not".

As I wrote in another email today, "MAY NOT" is not defined in 2119, so
whatever we do, all the occurrences of "MAY NOT" need to be replaced
with something else.

>>> I think you did not get my question. Let me rephrase it.
>>>
>>> This draft suggest that router create a new state to explicitly
>>> track the host that are joining a channel. Let us assume that the
>>> host crashed before sending a leave. How and when this new state
>>> maintained in the router is removed?
>>
>> Maybe I don't still understand your question.
>> If you are talking about outdated membership status due to the
>> maintained host crash, the membership status will be updated by
>> general query as mentioned in section 4.
>> If you are talking about the statement of flushing the maintained
>> membership state information in the older version compatibility mode,
>> if you think this behavior is implementation dependend, I'm Ok to
>> remove the statements starting from "On the other hand" in section 6.
>> Or other way you prefer?
>
> I was talking about the first case. I am into implementation. Let me tell you what I think:
>
> 1. The router create this new membership state and keep it updated when it receives reports. The router probably aggregate these reports to create forwarding state.
> 2. This new membership state gets removed if the last host sends a state-change report to leave this channel.
>
> What I am asking is that when is this new membership state removed if the last host has crashed and did not send this state-change report.
>
> Will not we need to link this membership state to the forwarding state router maintains. This way when the group or source timer fires apart from the forwarding state this membership state is also removed. Does this make sense?
>
> The reason for asking this question is that no timer is maintained for this new membership state so there is no way to time out only memership state.
>
>>>>> 19. If we can assume that the robustness count configured in a
>>>>> router truly represents the robustness of that network and if a
>>>>> packet is sent this many times, the intended destination will
>>>>> receive the packet at least once, this whole draft can be
>> simplified
>>>>> a lot. There is no need to generate group or group-source specific
>>>>> queries even when all the hosts have left that channel. I am sure
>>>>> there is something I have missed because this is how fast/immediate
>>>>> leave is implemented for older version of protocols.
>>>>
>>>> I tend to agree, but such protocol tuning is beyond the scope of this
>>>> document.
>>>> Also, we had discussions about specific query suppression in the
>>>> meetings several times. Our consensus was that the specific query
>>>> suppression should be the option (i.e. saying "SHOULD disable this
>>>> specific query suppression" as you see in section 3.2).
>>>
>>> I think its not protocol tuning.

I agree that there is an expectation in the design of IGMP/MLD that
the robustness variable is set appropriately so that unsolicited
reports will make it through. There is always a risk that they won't
though. But one of the benefits of explicit tracking is "fast leave"
which means that you do not need to spend time on a specific query
before you stop forwarding. I don't think the text needs to change
though. It only says that this shouldn't be the default behavior. I
think of this as safety measure, but if you as an operator believe
that your link is fairly robust or that you can configure the
robustness count appropriately so that the chances of unsolicited
messages being lost is sufficiently low, then enabling specific-query
suppression make sense. It depends on the environment whether
fast-leave is important as well.

Stig

>>> A network admin should always know its robustness against unreliable
>>> protocols. So the unsolicited messages should always reach the
>>> router. If we say that there are chances that unsolicited reports
>>> won't reach the router which are sent in multiple than in my
>>> opinion, there is no guarantee that solicited messages will reach
>>> the router.
>>>
>>> This whole concept of explicit tracking function becomes easier if
>>> we follow the above logic.
>>>
>>> Do you see an issue with the above logic?
>>
>> I agree such discussion is interesting, but it is beyond the scope of
>> this document.
>
> I am not sure I understand.
>
>> The solution regarding how the protocol robustness is improved and how
>> the message transmission is guaranteed is not simple. It is not solved
>> only with the explicit tracking function.
>
> I was not talking about how to improve the protocol robustness here.
>
> What I am suggesting is that, with robustness count, things have been working in the field for so many years. So why not make the whole explicit tracking functionality easier by assuming that unsolicited reports are not lost, than what is proposed in this draft?
>
>> I'm happy to work on this topic, but it is not a good idea to discuss
>> such solution in this document.
>> (Note that the IGMP/MLD protocol tuning mainly for wireless and mobile
>> environment is issued in rfc6636 and the more general protocol
>> modification discussion is on going in the Mike's I-D.)
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>