Subject: Q: IGMPv2 leave message processing?

From: "Danny J. Mitzel" <[email-masked]>
Date: Sun, 25 Feb 1996 18:12:49 -0800

I have a question regarding the processing of IGMPv2 leave messages.
I am assuming that an mrouter should maintain active group state for 
each interface, even if it's not the querier.  is this correct?

when an IGMPv2 leave message is received the subnet querier is required
to send out a couple group directed membership queries and sets its
group expire timer very short [3s in mrouted-3.8].  now, a non-querier
mrouter should not send out any queries, but shouldn't it set its group
expire timer to the very short interval also, to stay in synch with the
queriers database?  I ask this because the mrouted-3.8
accept_leave_message() seems to return immediately if it's not the
querier for the interface, this could lead to the active group database
being inconsistent for nearly a GROUP_EXPIRE_TIME period.  maybe this
doesn't cause any problems if IGMP and multicast routing use the same
designated router / querier election algorithm for each subnet, but I
don't know if this is guaranteed in the future?  is this a bug?

thanks,
danny

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Sun, 25 Feb 1996 19:05:07 -0800

I think I found the answer to my earlier question on IGMPv2 leave message
processing in a footnote on page 15 of the IGMPv2 draft #2; 
    ``when a non-querier router receives a group specific query in the
    members present state, is sets its group membership timer to a
    multiple [last member query count] of the max response time in the
    group specific query.''
so, the processing should be in the accept_membership_query() routine,
by checking for a group specific query?  this is still a bug in mrouted-3.8?

another questions...
1. I see reference to a ``other querier present timer'' that tells an
IGMPv2 non-querier to transition to querier state if no membership
requests have been seen from the elected querier.  does anyone know
what this value should be?  I don't it listed in the 'list of timers
and default values' section.  I would think it must be greater than the
'query interval' to allow some variations in request times, but less
than 'group membership timer' to avoid group membership timeouts.

thanks again for your time and any info.
danny
--------------------
On Sunday, February 25th 1996 at 18:12 PST,
in message <[email-masked]>

---

From: Bill Fenner <[email-masked]>
Date: Mon, 26 Feb 1996 09:38:23 PST

In message <[email-masked]> Danny Mitzel wrote:
>this is still a bug in mrouted-3.8?

Correct; this is an mrouted bug.

>and default values' section.

Thanks for pointing out this ommision; it should be twice the Query
Interval plus half of the Query Response Interval.  I will put that
into the next version of the draft.

  Bill

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Mon, 26 Feb 1996 10:58:51 -0800

On Monday, February 26th 1996 at 09:38 PST,
in message <[email-masked]>

>> into the next version of the draft.

maybe I can slip in one more question while I've got your attention...
`Group Membership Timer' is defined as `Twice the Query Interval plus
one Query Response Interval.'  I interpret this as 
'(2 * Query Interval) + Query Response Interval' (260s using defaults);
mrouted seems to interpret as '2 * (Query Interval + Query Response Interval)'
(270s using defaults).  which interpretation is correct?

similarly, `Other Querier Present' timer could be interpretted as
'(2 * Query Interval) + (0.5 * Query Response Interval)' vs.
'2 * (Query Interval + (0.5 * Query Response Interval))'?

thanks for any clarifications,
danny