>>>>> On Fri, 27 Oct 2006 11:54:49 -0700,
>>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> This issue was discussed some time ago and we didn't officially resolve
> it on the list.
> Basavaraj is suggesting that the hard limit of 1800 seconds is
> restrictive to some deployments (cellular) and suggests that we increase
> it.
> Here is how it is currently defined:
> MaxRtrAdvInterval
> The maximum time allowed between sending
> unsolicited multicast Router Advertisements from
> the interface, in seconds. MUST be no less than 4
> seconds and no greater than 1800 seconds.
> Default: 600 seconds
> Realistically there are two possible options to handle this:
> 1. Accept the issue: Increase the value of the MaxRtrAdvInterval. It
> seems that in order to do this in a backward compatible way, we can't
> increase it beyond 2999 seconds. That's because the default value for
> the AdvDefaultLifetime is 3 * MaxRtrAdvInterval and it must be < 9000
> seconds.
> 2. Reject the issue.
My short answer is I support option 2.
I do not necessarily object to raising MaxRtrAdvInterval for some
types of links per se, but I think it's outside the scope of 2461bis.
In general, the goal of 2461bis is (as far as I understand it) to fix
specification bugs and to clarify confusing points, but this issue
does not seem to belong to either of them. Also, I think it's risky
to raise one particular parameter without understanding the
rationale. For example, with max of MaxRtrAdvInterval = 1800 and max
of AdvDefaultLifetime = 9000, we can allow (about) 4 consecutive
losses of RAs in some worst case scenarios. Raising the former
without leaving the latter will change this dependency, and although
this should be a minor difference, I basically don't think we're
willing to introduce such a change when recycling a spec at the DS
status.
BTW, the current specification already allows per-link
optimizations/customizations in a different document, e.g.:
6.2.1. Router Configuration Variables
[...]
The default values for some of the variables listed below may be
overridden by specific documents that describe how IPv6 operates over
different link layers. This rule simplifies the configuration of
Neighbor Discovery over link types with widely differing performance
characteristics.
I believe this issue well falls into this case.
In summary, I suggest keeping the current text of 2461bis, and, if
necessary, writing a separate document that specifies link-specific ND
parameters for cellular links (or links with similar properties).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
