Subject: [pim] Few questions/suggestions on Explicit Membership Tracking Function

From: Bharat Joshi <[email-masked]>
Date: Wed, 24 Jul 2013 09:42:05 +0000

Hi Hitoshi,

      As promised, I read through the updated draft today. I have few more questions/suggestions on this.

Regards,
Bharat

PS: I lost the mail we exchanged last-to-last week so I do not know if you had replied with some justifications for some of these suggestions in that mail.

• In Abstract, it is mentioned that explicit tracking enables operators to see which downstream routers(s) on a LAN are joined to which multicast tree. But as we are talking about IGMP/MLD, should not this be hosts, switches and/or routers that does IGMP/MLD proxy? So I still feel we should not call this just routers. I think we should reword it such that it says that explicit tracking enables operators to see which downstream network elements is interested in which multicast group.

• In introduction, can we reword:

Therefore, a router even enabling the function may need to send periodic IGMPv3/MLDv2 General Query messages and solicit IGMPv3/MLDv2 report messages from downstream member hosts to maintain an up-to-date membership state, while the function contributes to saving network resources by tuning query timers or values.

to

Therefore, a router that uses this function, may still need to send periodic IGMPv3/MLDv2 General Query messages to maintain an up-to-date membership state.

• It seems there is some text missing from section 3. In last revision, this section mentioned report sender's IP address to be maintained as records but that text is removed.

• In section 4, "Query messages along with the definition of Section" -> "Query messages as defined in Section"

• In section 4, in following sentence:

With the specific query suppression, regardless of the LMQC/LLQC values, if the router receives one or more replies from the downstream member(s), it can stop (i.e., cancel) retransmitting the specific query message(s) and lower the corresponding source/group timers.

     What do you mean by the 'lower the corresponding source/group timers' in this sentence?

• In section 5, para 2 is describing each parameter on how it is used. Would not it be better to just reference to corresponding RFCs instead of this?

• 'Hard state' does not look the right term for explaining the query suppression if network robustness is known.

• In section 7, if router do not track but join a group, until the sender gets an IP address and reply to query messages, there is a risk of router not knowing the actual number of receivers.

**************** 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: Hitoshi Asaeda <[email-masked]>
Date: Thu, 25 Jul 2013 23:54:42 +0900 (JST)

Bharat,

> • In Abstract, it is mentioned that explicit tracking enables
> operators to see which downstream routers(s) on a LAN are joined to
> which multicast tree. But as we are talking about IGMP/MLD, should
> not this be hosts, switches and/or routers that does IGMP/MLD proxy?
> So I still feel we should not call this just routers. I think we
> should reword it such that it says that explicit tracking enables
> operators to see which downstream network elements is interested in
> which multicast group.

The explicit tracking function is enabled on multicast routers or
IGMP/MLD proxy devices, not on hosts.
I would reword such as;
  "the IGMP/MLD-based explicit membership tracking function for
  multicast routers and IGMP/MLD proxy devices supporting
  IGMPv3/MLDv2."

> Therefore, a router even enabling the function may need to send
> periodic IGMPv3/MLDv2 General Query messages and solicit
> IGMPv3/MLDv2 report messages from downstream member hosts to
> maintain an up-to-date membership state, while the function
> contributes to saving network resources by tuning query timers or
> values.
> 
> to
> 
> Therefore, a router that uses this function, may still need to send
> periodic IGMPv3/MLDv2 General Query messages to maintain an
> up-to-date membership state.

Ok, I'd say;
  "Therefore, a router enabling the function may still need to send
  periodic IGMPv3/MLDv2 General Query messages and solicit
  IGMPv3/MLDv2 report messages from downstream member hosts to
  maintain an up-to-date membership state."

> • It seems there is some text missing from section 3. In last
> revision, this section mentioned report sender's IP address to be
> maintained as records but that text is removed.

I did enbug in the last revision. Move the text back to the revised
one.

> • In section 4, "Query messages along with the definition of
> Section" -> "Query messages as defined in Section"

Ok.

> With the specific query suppression, regardless of the LMQC/LLQC
> values, if the router receives one or more replies from the
> downstream member(s), it can stop (i.e., cancel) retransmitting the
> specific query message(s) and lower the corresponding source/group
> timers.
> 

Lowering the corresponding source/group timers to zero is the way to
stop query retransmission. It is the standard router-side
implementation. However, precisely because it is the standard
behavior, I think I can omit to say this exlicitly here. I'll remove
it.

> • In section 5, para 2 is describing each parameter on how it is
> used. Would not it be better to just reference to corresponding RFCs
> instead of this?

This short explanation will reminds readers of the standard
values/timers, LMQI/LLQI, LMQC/LLQC, and LMQT/LLQT, and help readers
understanding the story of this section. I think just referring
rfc3367/3810 here is not helpful. This is the reason I put this short
para.

> • 'Hard state' does not look the right term for explaining the query
> suppression if network robustness is known.

Maybe. "Stable state"?
Naming is always difficult. I'll ask in the meeting.

> • In section 7, if router do not track but join a group, until the
> sender gets an IP address and reply to query messages, there is a
> risk of router not knowing the actual number of receivers.

Yes, there is a risk. That's why the second para explaining all-zero
source says, "the router will maintain its membership state
information by checking Current-State reports as ordinary routers do".

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 26 Jul 2013 10:33:50 +0000

Hi Hitoshi,

       Please see few replies in line with 'Bharat>'

Regards,
Bharat

________________________________________
From: Hitoshi Asaeda [[email-masked]]
Sent: Thursday, July 25, 2013 8:24 PM
To: Bharat Joshi
Cc: [email-masked]
Subject: Re: [pim] Few questions/suggestions on Explicit Membership Tracking Function

Bharat,

Bharat> Explicit tracking function tracks the end hosts, switches or proxy devices. So I am still not convinced why it should mention multicast routers and not hosts. Please talk to some other person as well to get his views on this.

Ok, I'd say;

Bharat> I think the second part of the statement is implicit. I am fine with it if you want to add this.

Bharat> Did not get your response. Are you planning to put this back?

Ok.

Bharat> Ok.

Bharat> I am not sure I understand. Lowering of source/group timer is usually done when a router is sending a group/group-source specific query. Currently there is no way to cancel the remaining queries. In my opinion, it will be better to remove this sentence.

Bharat> Ok.

Maybe. "Stable state"?

Bharat> Its something to do with the robust network. So maybe we can call 'robust network state'. But yes please do ask in the meeting for others feedback as well.

Bharat> But can we also mention about the risk here?

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 27 Jul 2013 00:07:05 +0900 (JST)

Bharat,

> Bharat> Explicit tracking function tracks the end hosts, switches or
> proxy devices. So I am still not convinced why it should mention
> multicast routers and not hosts. Please talk to some other person as
> well to get his views on this.

This function tracks member hosts, but it is enabled by
routers/proxies, not by hosts.
Can you understand if I replace it to the following statement?
  "the IGMP/MLD-based explicit membership tracking function enabled by
  multicast routers and IGMP/MLD proxy devices supporting
  IGMPv3/MLDv2."

> Bharat> Did not get your response. Are you planning to put this back?

I meant I rewrote this section but put wrong statement here. I'll
modify the text of the same section of the previous draft and put it
in the next revision.

> Bharat> I am not sure I understand. Lowering of source/group timer
> is usually done when a router is sending a group/group-source
> specific query. Currently there is no way to cancel the remaining
> queries. In my opinion, it will be better to remove this sentence.

Yes, I'm saying the same thing.

> Bharat> Its something to do with the robust network. So maybe we can
> call 'robust network state'. But yes please do ask in the meeting
> for others feedback as well.

Ok, how about "robust link state"?

> Bharat> But can we also mention about the risk here?

The current second para (the following one) does not fulfill your
comment?

  "When a router enabling the explicit tracking function receives IGMP
  report messages with an all-zero source address, it deals with the
  IGMP report messages correctly as defined in [2] and continuously
  keeps track of the membership state. However, the router SHOULD NOT
  maintain the host specifying all-zero source address in its
  membership state information. The router will maintain its
  membership state information by checking Current-State reports as
  ordinary routers do."

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Sat, 27 Jul 2013 06:38:58 +0000

Hitoshi,

       Please see my response in line with 'Bharat>'

Thanks,
Bharat
________________________________________
From: Hitoshi Asaeda [[email-masked]]
Sent: Friday, July 26, 2013 8:37 PM
To: Bharat Joshi
Cc: [email-masked]
Subject: Re: [pim] Few questions/suggestions on Explicit Membership Tracking Function

Bharat,

Bharat> I think I am not able to convey my concern correctly. I will make one last attempt. Here is the text for which I am asking this:

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

This statement is written from the multicast router perspective because explicit tracking function is implemented in them. From that perspective if you read this statement, saying that 'operators can see which downstream router(s) on a LAN are joined' does not look correct. As you agreed above that the function tracks member hosts so should not this statement mention that instead of 'downstream router(s)' in this sentence.

Bharat> I had couple of question on this. I will look at the updated one and see if my suggestions are taken care.

Bharat>: Somehow I did not get this from your reply. In any case if you are removing that statement, I think things should be fine.

Bharat> This may be fine. I am not sure. If required, you can define this in terminology section with details.

Bharat> I saw this. What I am trying to point out is that as it does not maintain the receiver record with 0.0.0.0 address the router state is not in sync and so there is a risk.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 29 Jul 2013 10:32:16 +0200 (CEST)

Bharat,

> Bharat> I think I am not able to convey my concern correctly. I will
> make one last attempt. Here is the text for which I am asking this:
>
> This statement is written from the multicast router perspective
> because explicit tracking function is implemented in them. From that
> perspective if you read this statement, saying that 'operators can
> see which downstream router(s) on a LAN are joined' does not look
> correct. As you agreed above that the function tracks member hosts
> so should not this statement mention that instead of 'downstream
> router(s)' in this sentence.

Ok, so how about;
  "This document describes the IGMP/MLD-based explicit membership
  tracking function for multicast routers and IGMP/MLD proxy devices
  supporting IGMPv3/MLDv2. The explicit membership tracking function
  contributes to saving network resources and shortening leave latency."

> Bharat> This may be fine. I am not sure. If required, you can define
> this in terminology section with details.

I think this kind of explanation should be in the main section, not in
the terminology section, beause it is necessary to explain various
backgrounds to make readers understand and the backgrounds are
mentioned in several sections.

> Bharat> I saw this. What I am trying to point out is that as it does
> not maintain the receiver record with 0.0.0.0 address the router
> state is not in sync and so there is a risk.

I may not understand your point.
Isn't it sufficient to say that all-zero source is not maintained by
the routers? Obviously it is because there is a risk of wrong
membership state.

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 29 Jul 2013 10:24:51 +0000

Hitoshi,

Regards,
Bharat
________________________________________
From: Hitoshi Asaeda [[email-masked]]
Sent: Monday, July 29, 2013 2:02 PM
To: Bharat Joshi
Cc: [email-masked]
Subject: Re: [pim] Few questions/suggestions on Explicit Membership Tracking Function

Bharat,

Ok, so how about;

Bharat>. Looks better to me.

Bharat> Ok. You decide. I was just suggesting that the definition of this term is something new and should come out correctly.

Bharat> I understand what you are mentioning here. I agree that it implicitly suggest that there is a risk here. My only question is that should we explicitly suggest that there is a risk here and then suggest something that reduces this risk. Question is that is there a way to figure out that a given host which joined a group with source address 0.0.0.0 has now got an IP address and so the router can move to actively tracking this group as well.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 29 Jul 2013 13:09:38 +0200 (CEST)

Bharat,

Thanks for your comments.
I believe we got concensus and it's time for submitting the revison.
Whenever the ietf submission page resumes, I'll submit it.
I hope the revised draft would go for the WGLC then.

Regards,
--
Hitoshi Asaeda