RE: Last Call: 'Neighbor Discovery for IP version 6 (IPv6)' to Draft Standard (draft-ietf-ipv6-2461bis)

["Soliman, Hesham" <hsoliman at qualcomm.com>]

ok, sounds good to me, which  means we have no open issues on the draft. 

Hesham

 > -----Original Message-----
 > From: Basavaraj Patil [mailto:basavaraj.patil at nokia.com] 
 > Sent: Wednesday, November 01, 2006 2:51 AM
 > To: ext JINMEI Tatuya / ¿ 癆 明達哉 ; Soliman, Hesham
 > Cc: ipv6 at 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 / ¿ 癆 明達哉"
 > <jinmei at isl.rdc.toshiba.co.jp> wrote:
 > 
 > >>>>>> On Fri, 27 Oct 2006 11:54:49 -0700,
 > >>>>>> "Soliman, Hesham" <hsoliman at qualcomm.com> 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.
 > > jinmei at isl.rdc.toshiba.co.jp
 > 
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------