[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [magma] magma Digest, Vol 46, Issue 2

To: Rajib Karmakar <rajibkit at gmail.com>
Subject: Re: [magma] magma Digest, Vol 46, Issue 2
From: Mark Fine <mark.fine at alcatel-lucent.com>
Date: Tue, 27 May 2008 10:25:43 -0700
Cc: magma at ietf.org
Delivered-to: ietfarch-magma-web-archive at core3.amsl.com
Delivered-to: magma at core3.amsl.com
In-reply-to: <db17ab530805262213m46f7ba20o62b9889a6bc7b456@mail.gmail.com>
List-archive: <https://www.ietf.org/mailman/private/magma>
List-help: <mailto:magma-request@ietf.org?subject=help>
List-id: Multicast and Anycast Group Membership <magma.ietf.org>
List-post: <mailto:magma@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
References: <mailman.7.1211828402.11557.magma@ietf.org> <db17ab530805262213m46f7ba20o62b9889a6bc7b456@mail.gmail.com>
Sender: magma-bounces at ietf.org
Section 6.6.1 "Timer Updates" explains that timers are updated on the  
sending or receiving of a query. A non-querier does not update timers  
when it receives reports -- it updates timers when it receives group- 
specific or group-and-source-specific queries from the elected querier.

As alluded to, routers in a network (querier and non-queriers) can be  
configured with different LMQI and LMQC values, so having non-querier  
routers update timers when they receive reports will lead to  
inconsistent aging out of membership records. Rather, non-queriers  
should only update timers on reception of group-specific or group-and- 
source-specific queries -- LMQI and LMQC can be calculated from the  
queries Max Resp Code and QRV fields, respectively.

On May 26, 2008, at 10:13 PM, Rajib Karmakar wrote:

> There will be no variation in the behaboiur between a querier and  
> non-querier except that queiriers will send quieries. Both will  
> follow the IGMP router functionality.Whenever a router (Querier or  
> non-querier) recieves a report it should process it and do whatever  
> is required (setting the group-source state and updating timers) and  
> if it is a queroer then it will also send the queries whenever  
> required. So, in this scenario the non-querier will also update the  
> timer at the same time when the querier does. Also the value of LMQT  
> will be same as the value of LMQI is known to the non-quirer at the  
> time of Querier Election and all the systems in a IGMP network  
> should be configured with same Robustness value which is in terms  
> been used as LMQC.
>
> On Tue, May 27, 2008 at 12:30 AM, <magma-request at ietf.org> wrote:
> Send magma mailing list submissions to
>        magma at ietf.org
>
> 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
>        magma-request at ietf.org
>
> You can reach the person managing the list at
>        magma-owner at ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of magma digest..."
>
>
> Today's Topics:
>
>   1. Re: Non-Querier behaviour on receiving grp specific or
>      grp-and-src specific queries (ravikumar vj)
>   2. Re: Non-Querier behaviour on receiving grp specific
>      orgrp-and-src specific queries (Suvendu Mozumdar)
>   3. Re: Non-Querier behaviour on receiving grp specific
>      orgrp-and-src specific queries (Bharat Joshi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 25 May 2008 21:27:46 -0700 (PDT)
> From: ravikumar vj <ravikumarvj at yahoo.co.in>
> Subject: Re: [magma] Non-Querier behaviour on receiving grp specific
>        or      grp-and-src specific queries
> To: magma at ietf.org
> Message-ID: <514382.85935.qm at web38805.mail.mud.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Bharat,
>            Why the non-querier have to wait till it receives a grp  
> specific or grp-and-src specific query? Why cant the non-querier  
> update the timers on receiving the reports it-self.
>            As per given in the example when the Querier receives the  
> BLOCK (S1), he updates the timer of S1 to LMQT and sends a Grp-and- 
> src specific query for S1. Why can the non-qurier update the timer  
> of S1 to LMQT as well (and DONT send query), when he receives the  
> report. Why the non-querier have to wait till he receives the Grp- 
> and-src specific query to update his timers?
>
>  Thanks and Regards
>  Ravikumar V J
>
> Message: 1
> Date: Fri, 23 May 2008 01:25:57 -0700
> From: "Suvendu Mozumdar"
> Subject: [magma] Non-Querier behaviour on receiving grp specific or
> grp-and-src specific queries
> To:
> Message-ID:
> <4C3C777A1128A74BA27FECF4E421BCBE0261077F at IXCA-EXCHANGE.ixiacom.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> I have an issue for which the RFC 3376 does not suggest anything.
> Lets say in a Lan there are two igmpv3 routers and one igmpv3 host
> present. Lets say Q1 is querier and Q2 is non-querier. Now Host1 sends
> include s1 for grp G1. Both Q1 and Q2 will have an entry in their
> respective database. Now Host1 sends a report block s1 for grp G1.  
> Q1 on
> receipt of this block report will start LMQT timer, set the source  
> timer
> of s1 to LMQT and start sending group and source specific queries for
> G1/s1. After LMQT expires Q1 will delete the entry of G1/s1 from its
> database. Now what will be the non-querier's behaviour. Will it also
> start LMQT, in that case Querier's LMQT and non-querier's LMQT  
> (which is
> LMQC*LMQI) may differ based on different LMQC values. Non-querier  
> comes
> to know about the querier's LMQI from the Max Response Code in the
> specific query pkt but what about querier's LMQC, non-querier has no  
> way
> to know about the querier's LMQI.
>
>
>
> Can anyone throw some light on this?
>
>
>
> Thanks
>
> Suvendu.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: https://www.ietf.org/mailman/private/magma/attachments/20080523/7da46ef7/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 May 2008 14:07:00 +0530
> From: Bharat Joshi
> Subject: Re: [magma] Non-Querier behaviour on receiving grp specific
> or grp-and-src specific queries
> To: Suvendu Mozumdar
> Cc: "magma at ietf.org"
> Message-ID: <1211531820.22712.19.camel at magadha>
> Content-Type: text/plain; charset=
>
> Suvendu,
>
> >
> > I have an issue for which the RFC 3376 does not suggest anything.
> > Lets say in a Lan there are two igmpv3 routers and one igmpv3 host
> > present. Lets say Q1 is querier and Q2 is non-querier. Now Host1  
> sends
> > include s1 for grp G1. Both Q1 and Q2 will have an entry in their
> > respective database. Now Host1 sends a report block s1 for grp G1.  
> Q1
> > on receipt of this block report will start LMQT timer, set the  
> source
> > timer of s1 to LMQT and start sending group and source specific
> > queries for G1/s1. After LMQT expires Q1 will delete the entry of
> > G1/s1 from its database. Now what will be the non-querier's  
> behaviour.
> > Will it also start LMQT,
>
> Please look at section 6.6.1. When a non-querier receives a query, it
> reduces its corresponding timer to LMQT which can be derived from
> max-response code.
>
> > in that case Querier's LMQT and non-querier's LMQT (which is
> > LMQC*LMQI) may differ based on different LMQC values. Non-querier
> > comes to know about the querier's LMQI from the Max Response Code in
> > the specific query pkt but what about querier's LMQC, non-querier  
> has
> > no way to know about the querier's LMQI.
>
> Non-querier does not need to know LMQC as it is not required. LMQC is
> required for a querier to generate number of queries.
>
> Also most of the times, it is expected that all routers are configured
> with same values but things should still work if they are not.
>
> Hope this helps.
>
> Thanks,
> Bharat
>
>
> **************** 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
> magma at ietf.org
> https://www.ietf.org/mailman/listinfo/magma
>
>
> End of magma Digest, Vol 46, Issue 1
> ************************************
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: https://www.ietf.org/mailman/private/magma/attachments/20080525/fbf8d95e/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Sun, 25 May 2008 22:17:46 -0700
> From: "Suvendu Mozumdar" <smozumdar at ixiacom.com>
> Subject: Re: [magma] Non-Querier behaviour on receiving grp specific
>        orgrp-and-src specific queries
> To: "Bharat Joshi" <bharat_joshi at infosys.com>
> Cc: magma at ietf.org
> Message-ID:
>        <4C3C777A1128A74BA27FECF4E421BCBE02693CEF at IXCA-EXCHANGE.ixiacom.com 
> >
> Content-Type: text/plain;       charset="us-ascii"
>
> Hi Bharat, please see inline :
>
> -----Original Message-----
> From: Bharat Joshi [mailto:bharat_joshi at infosys.com]
> Sent: Friday, May 23, 2008 2:07 PM
> To: Suvendu Mozumdar
> Cc: magma at ietf.org
> Subject: Re: [magma] Non-Querier behaviour on receiving grp specific
> orgrp-and-src specific queries
>
> Suvendu,
>
> >
> >      I have an issue for which the RFC 3376 does not suggest  
> anything.
> > Lets say in a Lan there are two igmpv3 routers and one igmpv3 host
> > present. Lets say Q1 is querier and Q2 is non-querier. Now Host1  
> sends
> > include s1 for grp G1. Both Q1 and Q2 will have an entry in their
> > respective database. Now Host1 sends a report block s1 for grp G1.  
> Q1
> > on receipt of this block report will start LMQT timer, set the  
> source
> > timer of s1 to LMQT and start sending group and source specific
> > queries for G1/s1. After LMQT expires Q1 will delete the entry of
> > G1/s1 from its database. Now what will be the non-querier's  
> behaviour.
> > Will it also start LMQT,
>
> Please look at section 6.6.1. When a non-querier receives a query, it
> reduces its corresponding timer to LMQT which can be derived from
> max-response code.
> Suvendu : As per section 8.10, LMQT = LMQC*LMQI, I agree that LMQI is
> the max-response code in the specific query, but LMQC is configurable
> and MAY differ in querier and non-querier. That's where my doubt  
> arises.
>
> > in that case Querier's LMQT and non-querier's LMQT (which is
> > LMQC*LMQI) may differ based on different LMQC values. Non-querier
> > comes to know about the querier's LMQI from the Max Response Code in
> > the specific query pkt but what about querier's LMQC, non-querier  
> has
> > no way to know about the querier's LMQI.
>
> Non-querier does not need to know LMQC as it is not required. LMQC is
> required for a querier to generate number of queries.
> Suvendu : Not only that, LMQC is used in calculating LMQT, pl refer
> section 8.10.
>
> Also most of the times, it is expected that all routers are configured
> with same values but things should still work if they are not.
>
> Hope this helps.
>
> Thanks,
> Bharat
>
>
> **************** 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***
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 May 2008 19:59:22 +0530
> From: Bharat Joshi <bharat_joshi at infosys.com>
> Subject: Re: [magma] Non-Querier behaviour on receiving grp specific
>        orgrp-and-src specific queries
> To: Suvendu Mozumdar <smozumdar at ixiacom.com>
> Cc: "magma at ietf.org" <magma at ietf.org>
> Message-ID:
>        <31D55C4D55BEED48A4459EB64567589A0B27DD9479 at BLRKECMBX02.ad.infosys.com 
> >
>
> Content-Type: text/plain;       charset="us-ascii"
>
> Hi Suvendu,
>
> > >      I have an issue for which the RFC 3376 does not suggest  
> anything.
> > > Lets say in a Lan there are two igmpv3 routers and one igmpv3 host
> > > present. Lets say Q1 is querier and Q2 is non-querier. Now Host1  
> sends
> > > include s1 for grp G1. Both Q1 and Q2 will have an entry in their
> > > respective database. Now Host1 sends a report block s1 for grp  
> G1. Q1
> > > on receipt of this block report will start LMQT timer, set the  
> source
> > > timer of s1 to LMQT and start sending group and source specific
> > > queries for G1/s1. After LMQT expires Q1 will delete the entry of
> > > G1/s1 from its database. Now what will be the non-querier's  
> behaviour.
> > > Will it also start LMQT,
> >
> > Please look at section 6.6.1. When a non-querier receives a query,  
> it
> > reduces its corresponding timer to LMQT which can be derived from
> > max-response code.
> > Suvendu : As per section 8.10, LMQT = LMQC*LMQI, I agree that LMQI  
> is
> > the max-response code in the specific query, but LMQC is  
> configurable
> > and MAY differ in querier and non-querier. That's where my doubt  
> arises.
>
> Non-querier need not use LMQT in turn LMQC at all. They can simply  
> lower down their group/source timer to LMQI calculated based on Max- 
> Response-Code and they do it for each group/group-source specific  
> query.
>
> > > in that case Querier's LMQT and non-querier's LMQT (which is
> > > LMQC*LMQI) may differ based on different LMQC values. Non-querier
> > > comes to know about the querier's LMQI from the Max Response  
> Code in
> > > the specific query pkt but what about querier's LMQC, non- 
> querier has
> > > no way to know about the querier's LMQI.
> >
> > Non-querier does not need to know LMQC as it is not required. LMQC  
> is
> > required for a querier to generate number of queries.
> > Suvendu : Not only that, LMQC is used in calculating LMQT, pl refer
> > section 8.10.
>
> Please see above.
>
> Thanks,
> Bharat
>
> **************** 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
> magma at ietf.org
> https://www.ietf.org/mailman/listinfo/magma
>
>
> End of magma Digest, Vol 46, Issue 2
> ************************************
>
> _______________________________________________
> magma mailing list
> magma at ietf.org
> https://www.ietf.org/mailman/listinfo/magma

_______________________________________________
magma mailing list
magma at ietf.org
https://www.ietf.org/mailman/listinfo/magma
Follow-Ups:
- Re: [magma] magma Digest, Vol 46, Issue 2
  - From: Suvendu Mozumdar
References:
- Re: [magma] magma Digest, Vol 46, Issue 2
  - From: Rajib Karmakar
Prev by Date: Re: [magma] magma Digest, Vol 46, Issue 2
Next by Date: Re: [magma] magma Digest, Vol 46, Issue 2
Previous by thread: Re: [magma] magma Digest, Vol 46, Issue 2
Next by thread: Re: [magma] magma Digest, Vol 46, Issue 2
Index(es):
- Date
- Thread