[IGMPv3/MLDv2] Incorrect group membership state expiry on Querier loss
"K.Kawaguchi" <[email protected]> Fri, 30 Jan 2009 16:24:45 +0900
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
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