Date: Thu, 21 Jun 2012 10:20:57 +0100 From: Bruce Simpson <bms@fastmail.net> To: Rui Paulo <rpaulo@felyko.com> Cc: freebsd-net@freebsd.org, bms@freebsd.org, GuYong <guyong1978@hotmail.com> Subject: Re: Question about MLDv2 implemenation in Kernel Message-ID: <4FE2E779.9040009@fastmail.net> In-Reply-To: <36507982-766F-4AD3-96A3-6872B9F32793@felyko.com> References: <SNT112-W22EEF8BF50EB9EA8A845ADC5FE0@phx.gbl> <36507982-766F-4AD3-96A3-6872B9F32793@felyko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
All, I'm working on something new just now,and am in a conference, but here is my 2p. On 20/06/12 22:20, Rui Paulo wrote: > On 20 Jun 2012, at 01:12, GuYong <guyong1978@hotmail.com> wrote: >> 1. RFC3810 clause 6.1 mentions there is a Source Retransmission Counter associated to each source, so that the merged report could contain the content that is interrupted by a new state change report BUT, I didn't see this is implemented currently! > I think this is stored in the mli_rv variable and decremented accordingly. Merging of pending state-changes is performed by mld_v2_merge_state_changes() and runs on a per-group basis for the end-station. mli_rv controls the retransmission report count. > I think you're right and it should be divided by MLD_TIMER_SCALE. ENOTIME to look into this further, but if someone sends me a working patch, I will review and commit. > My reading of it suggests that we are doing the right thing. We do > accept it and process it, but, like the text implies, we shouldn't > take any action. I concur. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FE2E779.9040009>