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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 27 Oct 2006 11:54:49 -0700

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-masked]] 
 > Sent: Saturday, October 28, 2006 4:24 AM
 > To: [email-masked]
 > 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-masked]> 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
 > > [email-masked] or [email-masked] 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
 > > [email-masked]
 > > Administrative Requests: 
 > https://www1.ietf.org/mailman/listinfo/ipv6
 > > 
 > --------------------------------------------------------------------
 > 
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pars MUTAF <[email-masked]>
Date: Sat, 28 Oct 2006 15:09:23 +0200

> Personally I have no problem with 1).

Hello,
I am also OK with 1)

Regards,
pars

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 29 Oct 2006 08:18:22 +0200 (EET)

> the AdvDefaultLifetime is 3 * MaxRtrAdvInterval and it must be < 9000

I don't think we need to change 1).  IMHO, the difference between 1800 
seconds and 2999 (or whatever new maximum we'd specify) seems 
irrelevant.  30 vs 49 minutes requires special cases in cellular and 
similar deployments in any case, so raising the default only that much 
isn't going to change anything.

On the other hand, I have seen numerous cases where solicited 
multicast RAs haven't worked for various reasons (such as, being sent 
too early and no network connectivity, not being sent when resuming 
from suspend, etc.), and you've only obtained RA information from the 
next unsolicited RA.  Hence, unsolicited RAs do seem to have a place.  
But if we're going to change the spec, I'd even go as far as suggest 
lowering the default to say 60 or 100 seconds.

I suggest we stay with the current text.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pars MUTAF <[email-masked]>
Date: Sun, 29 Oct 2006 20:36:43 +0100

> lowering the default to say 60 or 100 seconds.

Hi,
I personally agree with you, but in this particular network
(cellular as you know) this is too costly. Signaling cost I mean.

It looks like cellular folks don't like that. In fact, I don't
understand why they are asking IETF approval. My personal interpretation
is that they have some solutions in mind. For some reason they
depend on increasing the value of the MaxRtrAdvInterval.

So, I'm OK. Because I have nothing against,
and perhaps we can talk about something more exciting? ;-)
A new draft for example.. :-)

Regards,
pars

ps: Theoretically speaking, we don't know currently how to design
a paging protocol that is as reliable as ND. On the other hand,
ND wasn't designed for paging support (which is currently the most
efficient dormant mode).

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 31 Oct 2006 14:53:35 +0900

>>>>> On Fri, 27 Oct 2006 11:54:49 -0700, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> 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-masked]

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 31 Oct 2006 09:51:29 -0600

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