Subject: [magma] Destination address in v2 leave message

From: Indranil Bhattacharya <[email-masked]>
Date: Thu, 13 Oct 2011 23:00:27 +0530

Hi,

    Can anyone please tell me the disadvantage of using queriers address as
destination address in v2 leave message? Is there any advantage of sending
it to 224.0.0.2? Non-querier never processes leave message anyway.

Thanks,
Indranil

---

From: Kunal Shah <[email-masked]>
Date: Thu, 13 Oct 2011 14:18:17 -0400

Non-querier does process the leave message. On receiving a leave the non-querier is going to reduce the group timer to [Max Response Time] in the packet * [Last Member Query Count] but will not send the leave. Please refer to section 7 of RFC 2236.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Indranil Bhattacharya
Sent: Thursday, October 13, 2011 10:30 AM
To: [email-masked]
Subject: [magma] Destination address in v2 leave message

Hi,

    Can anyone please tell me the disadvantage of using queriers address as destination address in v2 leave message? Is there any advantage of sending it to 224.0.0.2? Non-querier never processes leave message anyway.

Thanks,
Indranil

---

From: Indranil Bhattacharya <[email-masked]>
Date: Fri, 14 Oct 2011 02:05:43 +0530

Hi Kunal,

            Non-queriers lower the group timers upon receiving
group-specific query from querier. They always ignore leave messages. Please
refer the last state diagram in section 7 which is for non-querier.

Thanks,
Indranil

On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah <[email-masked]>wrote:

> **
> Non-querier does process the leave message. On receiving a leave the
> non-querier is going to reduce the group timer to [Max Response Time] in
> the packet * [Last Member Query Count] but will not send the leave. Please
> refer to section 7 of RFC 2236.
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Indranil Bhattacharya
> *Sent:* Thursday, October 13, 2011 10:30 AM
> *To:* [email-masked]
> *Subject:* [magma] Destination address in v2 leave message
>
>   Hi,
>

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 14 Oct 2011 07:23:31 +0530

Hi Kunal/Indranil,

         Leave message is sent to ALL-Routers address because host does not keep track of the querier.

         If host needs to keep track of querier, it will have to implement querier election algorithm and maintain a state with querier-timeout etc. which is unnecessary.

Regards,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Indranil Bhattacharya [[email-masked]]
Sent: Friday, October 14, 2011 2:05 AM
To: Kunal Shah
Cc: [email-masked]
Subject: Re: [magma] Destination address in v2 leave message

Hi Kunal,

            Non-queriers lower the group timers upon receiving group-specific query from querier. They always ignore leave messages. Please refer the last state diagram in section 7 which is for non-querier.

Thanks,
Indranil

On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah <[email-masked]<mailto:[email-masked]>> wrote:
Non-querier does process the leave message. On receiving a leave the non-querier is going to reduce the group timer to [Max Response Time] in the packet * [Last Member Query Count] but will not send the leave. Please refer to section 7 of RFC 2236.

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Indranil Bhattacharya
Sent: Thursday, October 13, 2011 10:30 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [magma] Destination address in v2 leave message

Hi,

Thanks,
Indranil

**************** 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: Indranil Bhattacharya <[email-masked]>
Date: Fri, 14 Oct 2011 08:43:04 +0530

Thanks Bharat.

- Indranil

On Fri, Oct 14, 2011 at 7:23 AM, Bharat Joshi <[email-masked]>wrote:

>         If host needs to keep track of querier, it will have to implement
> querier election algorithm and maintain a state with querier-timeout etc.
> which is unnecessary.
>
> Regards,
> Bharat
> From: [email-masked] [[email-masked]] On Behalf Of
> Indranil Bhattacharya [[email-masked]]
> non-querier is going to reduce the group timer to [Max Response Time] in the
> packet * [Last Member Query Count] but will not send the leave. Please refer
> to section 7 of RFC 2236.
>
> From: [email-masked]<mailto:[email-masked]> [mailto:
> [email-masked]<mailto:[email-masked]>] On Behalf Of
> Indranil Bhattacharya

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 14 Oct 2011 12:30:05 +0900 (JST)

Hi,

>          If host needs to keep track of querier, it will have to
> implement querier election algorithm and maintain a state with
> querier-timeout etc. which is unnecessary.

And also, querier is not always forwarder.

Regards,
--
Hitoshi Asaeda

---

From: "Kudachi, Deepak S" <[email-masked]>
Date: Fri, 14 Oct 2011 03:56:37 +0000

Hi kunal,

If you are tracking querier's then I guess there should not be any issue in sending it
Towards querier only.

Again it is implementation dependent.

Thanks and Regards
Deepak

From: [email-masked] [mailto:[email-masked]] On Behalf Of Indranil Bhattacharya
Sent: Friday, October 14, 2011 2:06 AM
To: Kunal Shah
Cc: [email-masked]
Subject: Re: [magma] Destination address in v2 leave message

Hi Kunal,

Thanks,
Indranil

Thanks,
Indranil

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 14 Oct 2011 10:14:01 +0530

Hi Hitoshi,

         Yes. Querier need not be a multicast data forwarder. But are you suggesting that a forwarder who is not a IGMP querier process the leave message? If yes, what action do they take?

         As per RFC 2236, non-querier should be using group specific queries to lower down the group timer instead of leave messages.

Regards,
Bharat

PS: Sorry for not able to reply inline.
________________________________________
From: Hitoshi Asaeda [[email-masked]]
Sent: Friday, October 14, 2011 9:00 AM
To: Bharat Joshi
Cc: [email-masked]; [email-masked]
Subject: Re: [magma] Destination address in v2 leave message

Hi,

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 16 Oct 2011 01:48:57 +0900 (JST)

Hi Bharat,

>          Yes. Querier need not be a multicast data forwarder. But
> are you suggesting that a forwarder who is not a IGMP querier
> process the leave message? If yes, what action do they take?

If non-querier on the link has the forwaring state for the
corresponding channels, it should be able to hear IGMP report and
proceed to change its state if needed, while it does not send any IGMP
query. The action on the router whether sending prune or not is
coordinated by the routing protocol, PIM.
This is my understanding.

>          As per RFC 2236, non-querier should be using group specific
> queries to lower down the group timer instead of leave messages.

It seems not very precise. RFC2236 says;

   When a non-Querier receives a Group-Specific Query message, if its
   existing group membership timer is greater than [Last Member Query
   Count] times the Max Response Time specified in the message, it sets
   its group membership timer to that value.

BTW, I found the following statements in RFC2236;

   Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD
   ignore Leave Group messages for which there are no group members on
   the reception interface.

But I don't think above "ignore" is appropriate.
I interpret "Non-Queriers MUST ignore Leave Group messages" to mean
"Non-Queriers MUST NOT respond IGMP queries when it receives Leave
Group messages". (If I'm wrong, please correct me.)
Anyway, we should refer RFC3376.

Regards,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 17 Oct 2011 12:21:06 +0530

Hi Hitoshi,

> This is my understanding.

Though I understand what you are suggesting. But a router that is non-querier won't be able to take a decision of pruning a multicast path with just a leave message. There may be others who are still interested in this group on that LAN and until that is made sure, non-querier cannot prune the multicast path. This is done by lowering the group timer when non-querier sees a group specific query from querier and once it expires, non-querier can prune the multicast path.

There may be one case where this non-querier router can prune on its own and in that case this router will have to keep track of all hosts who had subscribed to this group. Once the last host sent a leave message, non-querier need not wait for the group-specific query or group timeout.

I remember seeing a draft for explicit tracking in PIM working group sometime back so until this functionality is available, non-querier cannot prune on their own.
 
> Group messages". (If I'm wrong, please correct me.)

I think with 'ignore' also things work pretty much fine as I explained above.

> Anyway, we should refer RFC3376.

To me RFC 3376 also looks pretty much same. Do you see any difference in processing for the above case in RFC 3376?

Regards,
Bharat

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 17 Oct 2011 16:17:16 +0900 (JST)

Hi Bharat,

> Though I understand what you are suggesting. But a router that is
> non-querier won't be able to take a decision of pruning a
> multicast path with just a leave message. There may be others who
> are still interested in this group on that LAN and until that is
> made sure, non-querier cannot prune the multicast path. This is
> done by lowering the group timer when non-querier sees a group
> specific query from querier and once it expires, non-querier can
> prune the multicast path.
> 
> There may be one case where this non-querier router can prune on its
> own and in that case this router will have to keep track of all
> hosts who had subscribed to this group. Once the last host sent a
> leave message, non-querier need not wait for the group-specific
> query or group timeout.

Yes, your description is correct. I didn't mean different things.

> I remember seeing a draft for explicit tracking in PIM working group
>  sometime back so until this functionality is available, non-querier
>  cannot prune on their own.

The explicit tracking contributes to the first leave, but the draft
does not mention that last member query count should be 0.
This means, whether the explicit tracking function is enabled or not,
group(-and-source)-specific query for the channel should be sent when
the router thinks the report sender is the last member according to
its member record, and a router having the routing state for the
channel will coordinate prune for that channel if the router confirms
the report sender is the last member.

> I think with 'ignore' also things work pretty much fine as I explained above.

I still don't think "ignore" is appropriate here.

> To me RFC 3376 also looks pretty much same. Do you see any
> difference in processing for the above case in RFC 3376?

RFC3376 does not say "Non-Queriers MUST ignore Leave Group messages or
other IGMP messages".
If a non-querier router has some routing states, it must also
recognize IGMP messages. This is what I understand.

Regards,
--
Hitoshi Asaeda