Re: When IGMPv3 router in EXCLUDE(X,Y) state

"Ashish Yadav" <[email protected]> Fri, 14 Mar 2008 18:24:16 +0530
Newsgroups gmane.ietf.magma
Message-ID <[email protected]>
Hi,

 

Whenever, you receive a Group query. Would you not lower down the timers
for all the sources for that particular group?

Otherwise, what are the generic criteria that you will maintain for
choosing which timers to lower?

For picking up on specific sources and lower their timers, you can use
Group and Source specific query and hence lower specific timers as per
your solution, which is being recommended in the RFC.

 

Regards,

Ashish

________________________________

From: [email protected] [mailto:[email protected]] On Behalf
Of ravikumar vj
Sent: Friday, March 14, 2008 8:38 AM
To: Mark Fine
Cc: [email protected]
Subject: Re: [magma] When IGMPv3 router in EXCLUDE(X,Y) state

 

Hello,

      Thanks for the reply.

      Actually I asked this specific question in relation to the
question asked by Rohan Sen.

 

      EXCLUDE (X,Y)  TO_IN (A)    EXCLUDE (X+A,Y-A)       (A)=GMI
 
Send Q(G,X-A)
 
Send Q(G)

 

      If I am implementing this rule, can't I update it as,

 

      EXCLUDE (X,Y)  TO_IN (A)    EXCLUDE (X+A,Y-A)       (A)=GMI
 
(X-A) = LMQT
 
Send Q(G)


      Thanks and Regards

      Ravikumar V J


Mark Fine <[email protected]> wrote:

	There's a single elected querier per subnet, with non-elected
routers 
	ceasing to send queries. The notation Q(G) and Q(G,A) therefore 
	describes Group-Specific and Group-and-Source-Specific queries
(a) 
	sent by the single elected querier OR (b) received by
non-elected 
	routers. The non-elected routers need both Group-Specific and
Group- 
	and-Source-Specific queries to update both their Source timers
and 
	their Group timer, respectively. See 6.6.1.
	
	Rather, the protocol for Group Members handles merging pending 
	responses to Group-Specific and Group-and-Source-Specific
queries. See 
	5.2.
	
	On Mar 12, 2008, at 10:53 PM, ravikumar vj wrote:
	
	> Hi,
	> What is the need of sending 2 queries? Send Q(G,X-A) and Send 
	> Q(G).
	> Instead, cant we update the timer for (X-A) to LMQT and just
send a 
	> group specific query alone?
	>
	> Regards
	> Ravikumar V J
	>
	>
	> [email protected] wrote:
	> Send magma mailing list submissions to
	> [email protected]
	>
	> To subscribe or unsubscribe via the World Wide Web, visit
	> https://www.ietf.org/mailman/listinfo/magma
	> or, via email, send a message with subject or body 'help' to
	> [email protected]
	>
	> You can reach the person managing the list at
	> [email protected]
	>
	> When replying, please edit your Subject line so it is more
specific
	> than "Re: Contents of magma digest..."
	>
	>
	> Today's Topics:
	>
	> 1. When IGMPv3 router in EXCLUDE(X, Y) state receives TO_IN(A)
	> (Rohan Sen)
	> 2. Re: When IGMPv3 router in EXCLUDE(X, Y) state receives
	> TO_IN(A) (Mark Fine)
	>
	>
	>
----------------------------------------------------------------------
	>
	> Message: 1
	> Date: Wed, 12 Mar 2008 15:16:45 +0530
	> From: "Rohan Sen"
	> Subject: [magma] When IGMPv3 router in EXCLUDE(X, Y) state
receives
	> TO_IN(A)
	> To: [email protected]
	> Message-ID:
	> <[email protected]>
	> Content-Type: text/plain; charset="iso-8859-1"
	>
	> Hi,
	>
	> RFC 3376 Section 6.4.2 change state record handling router
state 
	> machine
	> last line mentions about sending a group specific query in
addition 
	> to the
	> source specific query.
	> I am not very sure if I am able to understand the necessity of
this 
	> group
	> specific query. Usually a TO_IN(A) message is received from a
host 
	> that
	> underwent a state change from EXCLUDE(A) to INCLUDE(A) which
means the
	> router already had a state of EXCLUDE(X,Y) where A is a subset
of Y. 
	> The
	> router then tries to find out if there is any host which still
has 
	> interest
	> in receiving traffic for the sources already having source
timer > 
	> 0. I do
	> not understand what is the use of sending a group specific
query in 
	> this
	> case since the group specific query has a wider scoped purpose
than 
	> the
	> source specific query.
	>
	> Could it be that since for other cases no query is sent if
sources 
	> to be
	> queried is NULL set, for this case only (since TO_IN(NULL) is
the 
	> IGMPv3
	> translation for IGMPv2 Leave when older version host for that
group is
	> present) a group specific query has to be sent regardless of
whether 
	> the to
	> be queried source set is NULL or not.
	>
	> Any help on these lines would be highly appreciated.
	>
	> -- 
	> thanks,
	> Rohan Sen
	> -------------- next part --------------
	> An HTML attachment was scrubbed...
	> URL:
http://www.ietf.org/pipermail/magma/attachments/20080312/39d7ef63/attach
ment.htm
	>
	> ------------------------------
	>
	> Message: 2
	> Date: Wed, 12 Mar 2008 11:03:48 -0700
	> From: Mark Fine
	> Subject: Re: [magma] When IGMPv3 router in EXCLUDE(X, Y) state
	> receives TO_IN(A)
	> To: "Rohan Sen"
	> Cc: [email protected]
	> Message-ID:
	> Content-Type: text/plain; charset=US-ASCII; format=flowed;
delsp=yes
	>
	> The Group-Specific query is to find out if there are any hosts
which
	> still have EXCLUDE state -- the Group-Specific query will
lower the
	> router's Group Timer to LMQT, and if no hosts respond with
IS_EX
	> Current-State records, the Group Record will switch to INCLUDE
filter-
	> mode if there are still Source Records with timers running.
	>
	> On Mar 12, 2008, at 2:46 AM, Rohan Sen wrote:
	>
	> > Hi,
	> >
	> > RFC 3376 Section 6.4.2 change state record handling router
state
	> > machine last line mentions about sending a group specific
query in
	> > addition to the source specific query.
	> > I am not very sure if I am able to understand the necessity
of this
	> > group specific query. Usually a TO_IN(A) message is received
from a
	> > host that underwent a state change from EXCLUDE(A) to
INCLUDE(A)
	> > which means the router already had a state of EXCLUDE(X,Y)
where A
	> > is a subset of Y. The router then tries to find out if there
is any
	> > host which still has interest in receiving traffic for the
sources
	> > already having source timer > 0. I do not understand what is
the use
	> > of sending a group specific query in this case since the
group
	> > specific query has a wider scoped purpose than the source
specific
	> > query.
	> >
	> > Could it be that since for other cases no query is sent if
sources
	> > to be queried is NULL set, for this case only (since
TO_IN(NULL) is
	> > the IGMPv3 translation for IGMPv2 Leave when older version
host for
	> > that group is present) a group specific query has to be sent
	> > regardless of whether the to be queried source set is NULL
or not.
	> >
	> > Any help on these lines would be highly appreciated.
	> >
	> > --
	> > thanks,
	> > Rohan Sen _______________________________________________
	> > magma mailing list
	> > [email protected]
	> > https://www.ietf.org/mailman/listinfo/magma
	>
	>
	>
	> ------------------------------
	>
	> _______________________________________________
	> magma mailing list
	> [email protected]
	> https://www.ietf.org/mailman/listinfo/magma
	>
	>
	> End of magma Digest, Vol 44, Issue 7
	> ************************************
	>
	>
	> Looking for last minute shopping deals? Find them fast with
Yahoo! 
	> Search._______________________________________________
	> magma mailing list
	> [email protected]
	> https://www.ietf.org/mailman/listinfo/magma

 

  

________________________________

Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
<http://us.rd.yahoo.com/evt=51734/*http:/tools.search.yahoo.com/newsearc
h/category.php?category=shopping> 


Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer **************************** 

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." 

********************************************************************** 

---------------------------------------------------------------------

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