Re: DNA and using 3*MaxRtrAdvInterval [Re: [16NG] Re: Review of the ipv6-over-ipv6cs draft]

Pekka

> >> >  DNA for example. For DNA, a host relies on prefixes which were received
> >> >  within 3 * Maximum of MaxRtrAdvInterval.
> >>
> >>  Such behaviour would be incorrect, as RFC2461 says:
> >>
> >>        AdvDefaultLifetime
> >>                       The value to be placed in the Router Lifetime field
> >>                       of Router Advertisements sent from the interface,
> >>                       in seconds.  MUST be either zero or between
> >>                       MaxRtrAdvInterval and 9000 seconds.  A value of
> >>                       zero indicates that the router is not to be used as
> >>                       a default router.
> >>
> >>                       Default: 3 * MaxRtrAdvInterval
> >>
> >>  So it is legitimate to have:
> >>
> >>   3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000
> >>
> >>  If what you say is true, DNA specification is incorrect.
> >
> > I'm not sure why that's incorrect.
> >
> > First take notice that it is NOT MaxRtrAdvInterval BUT Maximum of
> > MaxRtrAdvInterval. (This distinction is sometimes confusing, at least
> > to me.) According to RFC 2461, Maximum of MaxRtrAdvInterval is 30 min
> > but MaxRtrAdvInterval may differ from router to router.
> >
> >        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.
> >
> > Second a host simply stops using for DNA operation a prefix which was
> > not received within 3 * Maximum of MaxRtrAdvInterval but can keep
> > using the prefix as of RFC 2461.
> >
> > This 3 * Maximum of MaxRtrAdvInterval rule is to remove the stale
> > prefix information quickly  because prefix lifetime can be quite long,
> > days or even weeks, for DNA operation.
>
> OK, it is "correct" in the sense that DNA can certainly, at 3*
> Max_MaxRtrAdvInterval decide that the default router is rather stale
> (at 60% of its maximum lifetime) and stop using it, but Neighbor
> Discovery itself specifies the maximum as
> max{Max_MaxRtrAdvInterval,9000}.
>
> Hence if 3*Max_MaxRtrAdvInverval is felt to be too short a time to
> wake up a dormant host, but 9000 seconds would not be, DNA could be
> fixed to use the rest of the 9000 seconds the same way as ND is
> already using using it.

I am a little confused. First, 3 * Max_MaxRtrAdvInterval rule only
prevents a host from using old prefixes for DNA operation, i.e. link
identification. It doesn't mandate the host stop using any router.
Second, since Max_MaxRtrAdvInterval is 1800 secs,
max{Max_MaxRtrAdvInterval,9000} is simply 9000 sec.

> >> > >  Even if a default route would be lost while in suspend, I don't see
> >> > >  this as an issue as immediately when the host gets woken up, the
> >> > >  default route could be re-obtained by a) specific RA (if wake up call
> >> > >  was sent by the AR -- at the same time or 20ms later) or b) a RS (if
> >> > >  host decided to wake up).  Later you also said that when a host gets
> >> > >  paged it needs to establish the link, implying that in fact there is
> >> > >  some delay before link can be used after paging.
> >> >
> >> >  Well... If the AR is configured to send periodic RAs at regular
> >> >  intervals (MaxRtrAdvInterval), the AR would end up paging the host and
> >> >  waking it up to deliver an RA which is essentially not very useful
> >> >  to the host.
> >>
> >>  If this approach were to be chosen, MaxRtrAdvInterval would be set to
> >>  something like 1800 seconds, but for example BS could filter out 80%
> >>  of messages, so an RA would only be sent to MS every 8000 seconds.
> >>  From the perspective of MS, filtering out RAs is indistinguishable
> >>  from it packets getting lost in the network, so this would require no
> >>  host modifications.
> >
> > As you wrote above, assume MaxRtrAdvInterval is set to 1800 secs
> > (which happens to be also the Maximum of MaxRtrAdvInterval) and BS
> > filters out to deliver RA every 8000 secs.
> >
> > Then after 5400 secs, from the lack of RAs within 3 * Maximum of
> > MaxRtrAdvInterval, hosts can deduce that it has missed at least 3 RAs
> > and stop using advertised prefix for DNA operation.
>
> And that is very much due to the way how DNA has been specified, not
> how ND has been specified.  Perhaps DNA should change to look at
> 5*Max_MaxRtrAdvInterval (or in other words: 9000 seconds) rather than
> just 60% of the maximum.

It depends on how many lost RAs would constitute prefix invalidation.
Maybe we'd better discuss this further in DNA WG ML. By chance, Sathya
happened to submit an updated DNAv6 draft today. Your feedback on DNA
solution would be appreciated.

> > If MaxRtrAdvInterval is very close to Maximum of Max RtrAdvInterval,
> > filtering out some RAs may give hosts the wrong impression that there
> > is something wrong on the router/link.
>
> That's correct in a way, if the hosts are (too) "smart" and e.g.,
> report that something odd is going on if there is no RA seen in 30
> minutes.  A dumb host doesn't even need to know what
> Max_MaxRtrAdvInterval and don't care though.

Right, we were concerned that MIPv6 hosts may be such a smart ones
because RFC 3775 recommends mobile nodes to interpret the lack of RAs
as an L3 handoff indication.

                   the mobile node needs to perform Router Discovery
   to discover routers and prefixes on the new link, as described in
   Section 6.3.7 of RFC 2461 [12].

   o  If Router Advertisements that the mobile node receives include an
      Advertisement Interval option, the mobile node may use its
      Advertisement Interval field as an indication of the frequency
      with which it should expect to continue to receive future
      Advertisements from that router.  This field specifies the minimum
      rate (the maximum amount of time between successive
      Advertisements) that the mobile node should expect.  If this
      amount of time elapses without the mobile node receiving any
      Advertisement from this router, the mobile node can be sure that
      at least one Advertisement sent by the router has been lost.  The
      mobile node can then implement its own policy to determine how
      many lost Advertisements from its current default router
      constitute an L3 handover indication.

Thanks for your kind consideration.

Best Regards

JinHyeock

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng