Subject: [magma] Question about Building and Sending Group and Source Specific Queries ( RFC 3376, section 6.6.3.2)

From: "李忠炘" <[email-masked]>
Date: Mon, 30 Jun 2008 17:36:56 +0800

HI,
In the paragraph of the section 6.6.3.2, when building a group and
source specific query, two separate query messages are sent for the
group, the first one has the "suppress router-side processing" bit
set, and the second one has the bit clear.

My question is that if the first query's S bit is set, then the
non-querier router would not lower its source timer to LMQT, and the
source timer in the querier router equals to LMQT, so when the querier
timer expires, the non-querier timer is still running, this would make
the inconsistence between the non-querier and querier.

Can someone give me some suggestion.

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

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 30 Jun 2008 19:59:10 +0530

Hi,

> the inconsistence between the non-querier and querier.

First group and source specific query's S bit will never be set. This is mentioned for the subsequent queries where a response might have been received. In that case, it generates two queries, one with the sources for which it does not want non-querier to reduce its timers and another with those for which it wants the non-querier to reduce their timers.

This is done for those sources for which are heard in the responses.

Thanks,
Bharat

> Can someone give me some suggestion.

**************** 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***
_______________________________________________
magma mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/magma

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 1 Jul 2008 09:22:08 +0530

Hi,

> Sorry, I still have some questions about it.

It is fine.

>    The RFC 3376 says that "The first one has the "Suppress Router-Side
> Processing" bit set and contains all the
>    sources with retransmission state and timers greater than LMQT."
> 
>    So I guess that the first query's S bit will always be set.
>   But I think that the first query's S bit should not be set, and the
> second query's S bit should be set, and I think it's more reasonable.

I think the confusion is coming when you look only at this text. But if
you also keep in mind when the query will have "Suppress Router-Side
Processing" bit set, things will be clearer.

As RFC 3376 says:

<< 

When transmitting a group specific query, if the group timer is larger
than LMQT, the "Suppress Router-Side Processing" bit is set in the query
message.

So for first query, we would have lowered down group timer to LMQT for
all groups being queried so that can not be larger than LMQT and so
"Suppress Router-Side Processing" can not be set.

So now when will group timer be larger than LMQT when generating a
group-source specific query? Only when router has received a report for
a specific group. So in that case, it creates two queries, one with 'S'
Bit flag set and list of group-source which has timer higher than LMQT
and another one with 'S' bit unset and list of group-source which has
timer lower than LMQT.

I hope this is clear now.

Thanks,
Bharat

>   Any response will be highly appreciated
> 
>   kuzi
> 
> 2008/6/30 Bharat Joshi <[email-masked]>:
> 
> >