Subject: [magma] [IGMPv3/MLDv2] Incorrect group membership state expiry on Querier loss

From: "K.Kawaguchi" <[email-masked]>
Date: Fri, 30 Jan 2009 16:24:45 +0900

Hi all,

I investigated the archive mail in magma. And I have some questions.

http://www.ietf.org/mail-archive/web/magma/current/msg00729.html
http://www.ietf.org/mail-archive/web/magma/current/msg00733.html

I think that this gap should not be solved by implementation dependence.
This is an issue of RFC. I think that we need to adopt one specification.
Below has some proposals.

1. It is the method of setting up the response delay time of a query 
   according to the remaining time of MALI by a pre- query.
   - The [Query Response Interval] value set to the router is not respected.
   - Rarely, it becomes small by continuing.

2. A timer is not decreased during general interpellation.
   - This method may have a little heavy processing by implementation.

3. But an easy modification is modifying the definition value of MALI.
   - When B is dynamically modified to large after setting up MALI to timer,
     there is still a gap issue.

RFC3810
---
9.4.  Multicast Address Listening Interval

   The Multicast Address Listening Interval (MALI) is the amount of time
   that must pass before a multicast router decides there are no more
   listeners of a multicast address or a particular source on a link.
   This value MUST be ([Robustness Variable] times [Query Interval])
   plus [Query Response Interval].
---

   ([Robustness Variable] times [Query Interval]) plus [Max Response Delay] plus [Query Response Interval]

   * [Robustness Variable], [Query Interval] and [Max Response Delay] is in Querier's Q(G).
     (Then, a non-querier adopts [Robustness Variable] and [Query Interval].)
   * [Query Response Interval] is in a non-querier.

make sense?

Best Regards
--
Kiyoaki Kawaguchi

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