Hi Akisada-san,
According to the RFC, the retransmission must be limited to at most 1
per retrans time. Considering most implementations probably run in 1
second timer, I think 1-2 seconds between NS should be tolerated.
Thanks,
Yinghui Yao
Alcatel-Lucent.
Yukiyo Akisada wrote:
> Hi, Yao.
>
> ND #8 and #9 for the router is Test v6LC.2.1.5.
> Please don't believe filename.
>
> Inconveniently,
> the actual test title (Test v6LC.X.X.X) was renumberd
> in the past update of specification.
>
> You can see the actual test title
> in <report.html> generated by the tester.
> It's the right side of the HTML frame.
>
> Anyway,
> our tester already incerted plus-minus 0.5 sec margin.
> It means half adjust.
> Totally 1 sec margin is enough for approximately, I think.
> Half adjust is commonly used to know approximately velue, isn't it?
>
> Conformance tester only knows the external behavior.
> And the tester couldn't support
> every internal behaviors of implementation in the world.
>
> How do you think?
>
> One of solutions is that you submit the logo application including FAILs.
> Your reason can be good reason to omit SHOULD.
> If IPv6 Ready Logo Committee accept it, you get the logo.
> But in this case,
> this behavior will be described on Latest approved list.
>
> Logo ID 02-C-000213 is the good case at
> <http://www.ipv6ready.org/logo_db/approved_list_p2.php>.
> The behavior is also described on their site.
>
> Thanks,
>
>
> On Tue, 05 Feb 2008 10:44:23 -0700
> Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
>
>
>> Hi Yukiyo,
>>
>> I disagree to the "judgment"s TAHI uses in these two tests (V6LC.2.1.6).
>>
>> I assume the test is based on the statement in RFC 4861, section 7.2.2
>>
>> "
>> While awaiting a response, the sender SHOULD retransmit Neighbor
>> Solicitation messages *approximately* every RetransTimer milliseconds,
>> even in the absence of additional traffic to the neighbor.
>> Retransmissions MUST be rate-limited to at most one solicitation per
>> neighbor every RetransTimer milliseconds.
>>
>> "
>>
>> Could you let me know how TAHI defines "approximately" in your tests? We
>> observe 1.3 second between NS will pass and 1.6 would fail.
>>
>> Our router has to handle large number of NDs, so our ND timer only runs
>> every 1 second. Depending on when the echo request comes into the NUT,
>> the time gap between our first and second NS can be anywhere between 1-2
>> seconds. However the time gap between 2nd NS and 3rd NS is always 1
>> second. So we could have
>>
>> NS(at 0 second) - NS (at 1.6 second) - NS (at 2.6 second) (retrans = 1s)
>>
>> NS(at 0 second) - NS (at 5.5 second) - NS (at 10.5 second) (retrans = 5s)
>> We think these two packet sequences do satisfy the above RFC requirement
>> and should pass. However TAHI are failing both. We think it's wrong.
>>
>> Could you let me know if my argument is valid and if you are willing to
>> make changes to accommodate our scenarios in TAHI code?
>>
>> Thanks,
>> Yinghui Yao
>> Alcatel-Lucent
>>
>>
>
>
> ------------------------------------------------------------------------
> Yukiyo Akisada <akisada@tahi.org>
>