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>