Folks, 

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. 

Please let me know if the suggestions above are flawed or if you have
another option to include. Otherwise, please express your opinions as to
whether we should choose 1) or 2) above. 

Personally I have no problem with 1). 

Hesham


 > -----Original Message-----
 > From: Basavaraj Patil [mailto:[EMAIL PROTECTED] 
 > Sent: Saturday, October 28, 2006 4:24 AM
 > To: iesg@ietf.org
 > Cc: Syam Madanapalli; Soliman, Hesham; Thomas Narten
 > Subject: Re: Last Call: 'Neighbor Discovery for IP version 6 
 > (IPv6)' to Draft Standard (draft-ietf-ipv6-2461bis) 
 > 
 > 
 > Comment about the MaxRtrAdvInterval value specified in this I-D:
 > 
 > The I-D specifies 1800 seconds as the maximum interval 
 > between sending
 > unsolicited periodic RAs. This value can be an impediment in 
 > some network
 > deployments (eg. Cellular networks). The maximum interval should be a
 > configurable value which can be set to the order of several 
 > hours (6~12
 > hours) as needed.
 > Periodic RAs every 30 minutes can be disruptive in certain 
 > networks and
 > hence the value should be modified.
 > 
 > An I-D proposing the revision of this value and the 
 > reasoning behind it is:
 > draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
 > 
 > -Basavaraj
 > 
 > On 10/27/06 1:06 PM, "ext The IESG" <[EMAIL PROTECTED]> wrote:
 > 
 > > The IESG has received a request from the IP Version 6 Working Group
 > > to consider the following document:
 > > 
 > > - 'Neighbor Discovery for IP version 6 (IPv6) '
 > >    <draft-ietf-ipv6-2461bis-09.txt> as a Draft Standard
 > > 
 > > The IESG plans to make a decision in the next few weeks, 
 > and solicits
 > > final comments on this action.  Please send any comments to the
 > > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-11-10.
 > > 
 > > The file can be obtained via
 > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-09.txt
 > > 
 > > Implementation Report can be accessed at
 > > http://www.ietf.org/IESG/implementation.html
 > > 
 > > 
 > > 
 > --------------------------------------------------------------------
 > > IETF IPv6 working group mailing list
 > > ipv6@ietf.org
 > > Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 > > 
 > --------------------------------------------------------------------
 > 
 > 

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

Reply via email to