ok, sounds good to me, which means we have no open issues on the draft. Hesham
> -----Original Message----- > From: Basavaraj Patil [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 01, 2006 2:51 AM > To: ext JINMEI Tatuya / 神明達哉 ; Soliman, Hesham > Cc: ipv6@ietf.org; Thomas Narten > Subject: Re: Last Call: 'Neighbor Discovery for IP version 6 > (IPv6)' to Draft Standard (draft-ietf-ipv6-2461bis) > > > 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
