Selon Pekka Savola <[EMAIL PROTECTED]>: > On Fri, 27 Oct 2006, Soliman, Hesham wrote: > > 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. > > 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.
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). > 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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
