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

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 02 May 2013 17:55:36 +0900 (JST)

Hi Bharat,

Thanks for your review.

> 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).

> 2. In second para of section 1, can we also mention that to avoid
> loss of unsolicited reports, each unsolicited report is sent out at
> least robustness count times. After this, we can talk about queries
> as mentioned in this para.

Ok, I'll add the sentense.

> 3. In third par of section 1, first sentence seems complex to me.
> 
> Multicast routers are capable of periodically maintaining the
> multicast membership state of downstream hosts attached to the same
> link by acquiring unsolicited report messages and synchronizing the
> actual membership state within the General Query timer interval
> (i.e., [Query Interval] value defined in [1][2].) 
> 
> Can we reword the above to as mentioned below or something on these lines:
> 
> Multicast routers learn multicast membership state of 
> downstream hosts by unsolicited report messages. Multicast
> routers send periodic queries to keep the membership state
> synchronized by solicited report messages.

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.

> 4. As its mentioned that 'explicit tracking function does not
> guarantee that the membership state will always be perfectly
> synchronized', should the task 'Per-host accounting' using this
> function be really done? It may give incorrect results and to some
> providers, accounting is very important. Right?

Although the explicit tracking function will contribute to accounting,
it is not the scope of this draft. It is just a use case.

In fact, in the previous version, we said something like,

   "where this document mainly focuses on the above first and second
   bullets in the following sections."

in the same paragraph, but removed as it's obvious. If it's better to
mention it, I'll move it back again.

Or shall I remove the third and fourth lines? I don't mind either.

> 5. Can you please elaborate on 'Maintaining multicast channel
> characteristics'? What channel characteristics we are referring
> here? Also how does explicit tracking function helps in this?

It is not the scope of this document, too. It is one of the use cases
as well.

While I wrote these two lines to show the potential use cases of this
function, if just removing these two lines is preferable, I'll remove
it.

(But if no strong opinion, I prefer to keep these use cases as is with
the above "where" clause. Opinion?)

> 6. In section 3.1, I did not get the need of "If there are no more
>    receivers maintained,
>    the router may keep the membership state information with an empty
>    receiver list.". Does this for any specific purpose? If so, can
>    we add this in the draft.

Allocating memory for membership state information is a cost. But I
agree removing this sentence is reasonable as it is an implementation
specific issue.

> 7. Should not 'Membership State Information' be deleted when the
> corresponding multicast channel times out in the router? The router
> should not be maintaining this multicast channel state information
> forever. For example: if the last hosts who had joined a channel
> goes down without sending a leave request.

It's up to the implementation as above. I'll remove such
implementation dependent statement.

> 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.

No. The original sentence is correct. That behevior is defined in [1]
and [2] as the standard behavior (without the explicit tracking
function enabled).

> Please also note the change of 'is' to 'was' in the last part of the sentence.
> 
> 9. In section 3.2, in para 3, "This is in order to confirm whether
> or not the host is the sole member."
> -> "This is in order to confirm whether or not the host was the sole member."

I don't think "is" is wrong.

> 10. In section 3.3, second para, what I infer from the first
> sentence is that router prunes the channel after LMQI and LLQI. This
> does not look correct. Later in the same para, last sentence correct
> this by mentioning LMQT and LLQT is the total time router wait after
> the first query is sent, to prune the channel. Can we fix the first
> sentence here?

Ok, I'll remove the sentence, "before the router prunes the channel
from the network", for LMQI/LLQI explanation.

> 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.

> 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.

> 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.

> 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.

> 15. In section 4, last para seems to explain how to fix the outdated
> membership state that is introduced because of explicit tracking
> function in a router while the section header seems to suggest that
> explicit tracking function can lower the possibility of outdated
> membership state.

No, as I said above, this document does not say that the explicit
tracking function lowers that possibility.

> 16. In section 5, in first para, we established that a MLD report
> received with unspecified source address is discarded then in second
> para, we mention that no membership-state information is created for
> such a request. So should we reword this to talk about only IGMP
> case here.

I agree. I'll remove the case of using MLD's unspecified address.

> 17. In section 6, in first para, its mentioned that explicit
> tracking does not work with older version of protocol. If I am not
> mistaken, fast/immediate leave implemented by some vendors do
> explicit tracking of the host. While I agree that hosts does report
> suppression but that happens only in case its a solicited
> report. First few (robustness count) unsolicited reports are usually
> enough to track the host.

I don't deny a router only speaks the older version protocols can
track the membership state only with unsolicited reports, but it has
more risk for the router to have the outdated membership state as it
cannot confirm the state with solicited reports.
Moreover, switching the tracking mechanism "only with uncolicited
reports (i.e. older version)" to "both with solicited and unsolicited
reports (i.e. current version)" would give complexities.
Therefore I proposed to disable the function in the older version's
router.

BTW, this document does not prohibit to keep enabling the explicit
tracking function in the older version's router, as it says "SHOULD
disable", not "MUST disable". But if people prefer "MAY disable", I'd
change "SHOULD" to "MAY" for it. Opinion?

> 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".

> 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).

Thank you.

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 2 May 2013 14:52:12 +0000

Hi Hitoshi,

    Thanks for your response. Please see my replies in line for few points.

Regards,
Bharat

> 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.

> Ok, I'll add the sentense.

Ok.

>    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.
 
> Or shall I remove the third and fourth lines? I don't mind either.

Just see below.

> the above "where" clause. Opinion?)

I am not sure how the above two use cases uses explicit tracking function?

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.

> agree removing this sentence is reasonable as it is an implementation

Ok.
 
> implementation dependent statement.

Ok.
 
> and [2] as the standard behavior (without the explicit tracking

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.
 
> 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'.

> from the network", for LMQI/LLQI explanation.

Ok.

> 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.
 
> 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?

> 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.

> 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.

Second issue is that the section also does not clarify this clearly.

> tracking function lowers that possibility.

Ok.

> I agree. I'll remove the case of using MLD's unspecified address.

Ok.
 
> change "SHOULD" to "MAY" for it. Opinion?

I think a 'SHOULD' is fine here.

> If so, I could agree. I'll change "MAY NOT" to "may not".

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?

> specific query suppression" as you see in section 3.2).

I think its not protocol tuning.

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 would also like to see what others think about this in the working group.
**************** 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***

---

From: Stig Venaas <[email-masked]>
Date: Mon, 06 May 2013 14:49:15 -0700

On 4/29/2013 9:07 PM, Hitoshi Asaeda wrote:
> Hi Stig,
>
>> The document looks good, but I see two possible issues.
>
> Thanks for your review.
>
>> Section 3.1 seems to talk too much about implementation details. In
>> particular the sentence "In order to simplify the implementation, the
>> explicit tracking function MAY NOT keep the state of (S,G) joined with
>> EXCLUDE filter mode."
>>
>> I think it's wrong here to say what the implementation MAY NOT do, in
>> particular if it is just a simplification. Advice is OK, but not
>> strict requirements for an internal implementation detail.
>
> I understand.
> I'd replace "MAY NOT" to "may not".

Are you trying to say "MAY NOT" as in strictly forbidden. Or just saying
that it does not necessarily keep the state?

>> The security considerations could be improved a bit. Potential issues
>> of
>> maintaining state are discussed, and a rate limit on membership
>> information. First of all, I don't think it is a rate limit, it's
>> should
>> be a limit on the maximum amount of memberships at any time. I think.
>
> I agree.
> I'd change the sentence in the security section as follws.
>
>     In order to prevent
>     abuse, a router enabling the explicit tracking function may need to
>     limit a total amount of membership information the router can
>     store and an amount of membership information the router can store
>     per host.

Fine.

>> Further, it should be pointed out that an attack could either cause
>> some
>> members to not be tracked, or some members to not be able to join and
>> receive.
>
> Whether report senders are malicious or not, the router can track
> their IP addresses (of course it assumes no address spoofing here,
> though).
>
> I'd say what the router should do is rate-limiting IGMP/MLD report
> transmissions per host. Do you agree on adding the following paragraph
> in the security section?
>
>     A router may rate-limit State-Change Report messages per host. When
>     the router enables rate-limiting per host, the router MAY ignore
>     the received State-Change Report messages to minimize the
>     processing overhead or prevent DoS attacks. The rate limit is left
>     to the router's implementation.
>
> BTW, while the rate limit itself is left to the router's implementation,
> is it better to specify the default timer value for the rate-limiting
> function? Or it is not necessary to specify it (as it depends on the
> implementation)?

I don't think you should specify it. That is implementation dependent.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 07 May 2013 11:26:33 +0900 (JST)

> 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.)

> 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.

> 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.

> 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 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.

> 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.

> 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.

> 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.

> 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"?

> 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?

> 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?

> 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.
> 

I agree such discussion is interesting, but it is beyond the scope of
this document.
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'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.)

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 07 May 2013 11:33:09 +0900 (JST)

> that it does not necessarily keep the state?

While I agree detailing the implementation specs is not needed in this
doc, I believe "the explicit tracking function may not keep the state
of (S,G) joined with EXCLUDE filter mode" is an important advice or
guideline for its implementation. So, I keep this statement without
RFC2119's words.

> I don't think you should specify it. That is implementation dependent.

Got it.
Thanks.

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 7 May 2013 07:44:37 +0000

Hi Hitoshi,

     Please see my responses in line.

Regards,
Bharat

Ok.

Ok.

> 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.

>     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.
 
> >> > Please also note the change of 'is' to 'was' in the last part of
> the
> >> > sentence.
> >> 

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.
> >> 

Ok. I was just trying to avoid little confusion with the above sentence.

>    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.

Ok.

> Ok, then how about, "Lowering the Risk of Wrong Membership

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

>    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.

> remove the statements starting from "On the other hand" in section 6.

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.

> I agree such discussion is interesting, but it is beyond the scope of

I am not sure I understand.

> 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?

---

From: Stig Venaas <[email-masked]>
Date: Tue, 07 May 2013 09:27:55 -0700

We believe we have sufficient support for this document to move it
forward to the IESG. We will however need a new document that addresses
comments made during the WGLC. Once we have a new version addressing the
comments we'll give the WG a few days to comment on the new version, and
unless issues are raised, send it off to the IESG.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 08 May 2013 09:57:14 -0700

Hi Hitoshi

>> that it does not necessarily keep the state?

MAY NOT is not defined in RFC 2119, so I think you need to change the
other occurrences as well. Also it is not clear what the meaning is I
think. MAY NOT could be read as MUST NOT. I suspect that the places
where it says "MAY NOT" can be "may not", but it depends on what you're
trying to say.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 08 May 2013 13:46:41 -0700

Hi

Some comments on this (as an individual contributor).

>> (BTW, also you can see the word, "accounting", here as the potential

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.

> 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 cor…

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.

> 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"?

>>>> 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 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

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 09 May 2013 10:55:21 +0900 (JST)

> is that the leave latency is shorter.

Ok, if it is the consensus, I'll just remove that common terminology.

>> 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.
> 

Ok, I understand. How about;
    when a router receives the State-Change Report and needs to
    confirm whether or not the report sender is the sole member host,
    it sends the corresponding Group-Specific or Group-and-Source
    Specific Query messages.

>> It still does not indicate that we are talking about this when
>> explicit tracking function is enabled. I would like to see something
>> like:
>>

I can live with that.

> whatever we do, all the occurrences of "MAY NOT" need to be replaced

Ok, only these two parts use MAY NOT. I'll change them to "may not".

> fast-leave is important as well.

I completely agree to this explanation.
I'll add some text. Thanks.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 09 May 2013 11:01:22 +0900 (JST)

>     it sends the corresponding Group-Specific or Group-and-Source

A little change.
   when a router receives the State-Change Report and needs to confirm
   whether or not the report sender is the sole member host for the
   received record(s), it sends the corresponding Group-Specific or
   Group-and-Source Specific Query messages.

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Wed, 08 May 2013 20:35:29 -0700

> Ok, if it is the consensus, I'll just remove that common terminology.

I don't know if it is consensus and it doesn't really matter to me. But
I think it reads better this way. If you prefer having "fast leave"
there, that is fine with me too.

Your proposed change regarding State-Change in the email you sent after
this one looks good to me.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 09 May 2013 13:37:50 +0900 (JST)

> there, that is fine with me too.

I've thought "fast leave" is easy for readers to recognize the benefit
of this function and can become the index of this doc, but if no
preference, I'll remove it.

> this one looks good to me.

Thanks for your input.

Regards,
--
Hitoshi Asaeda

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 May 2013 07:09:27 -0700

While we're nitpicking

 ...
 contributes to saving network resources, shortening leave latency and
 enables operators to see which downstream routers(s) on a LAN are
 joined to which multicast tree.

Just saying. ;-)

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Stig Venaas <[email-masked]>
Date: Fri, 10 May 2013 10:31:56 -0700

On 5/8/2013 6:55 PM, Hitoshi Asaeda wrote:
[...]
> I'll add some text. Thanks.

I have one concern here. I noticed that the specific query suppression
text says:

    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.

I think Bharat was mentioning this as well, although I'm not quite sure
if I got his point.

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 13 May 2013 03:11:03 +0000

Hi Stig,

      Thanks for the clarification. Yes. This is what I have been trying to point out. It seems I was not clear enough.

Regards,
Bharat
________________________________________
From: Stig Venaas [[email-masked]]
Sent: Friday, May 10, 2013 11:01 PM
To: Hitoshi Asaeda
Cc: Bharat Joshi; [email-masked]
Subject: Re: [pim] Please respond! Re: draft-ietf-pim-explicit-tracking pim 2nd wglc

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 14 May 2013 14:40:03 +0900 (JST)

> 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?)

  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
  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.

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Tue, 14 May 2013 10:04:56 -0700

Hi

> (Do you have any suggestion of "may", "will", etc. in this para, too?)

Is this text replacing the one above?

>    routers enabling the explicit tracking function with specific query

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

>    [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

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 14 May 2013 17:18:28 +0000

Hi Hitoshi,

         Please see in line.

Regards,
Bharat

>  [Robustness Variable] value to 1 for their routers.

I am looking for one things for this particular comment. 

Somewhere we need to mention that how explicit tracking function works if network robustness makes sure that at least one unsolicited report message will reach router. I think we need to add a separate section for this. If you want, I can send you some text I am looking for.