Hesham, I like Jinmei's proposal of rejecting the issue as far as changing 2461bis value goes. Because even the Max value of 2999 seconds is still not good enough for some links.
So I think it is best to let IPv6 over foo specific documents specify what router configuration variables are modified or over-ridden (from the default 2461bis). -Basavaraj On 10/30/06 11:53 PM, "ext JINMEI Tatuya / 神明達哉" <[EMAIL PROTECTED]> wrote: >>>>>> 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 [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
