Re: [DNA] Sending RS probe after link-change in simple DNA

[Julien Laganier <julien.IETF@laposte.net>]

Hi Suresh,

Thanks for adopting the changes I suggested.

--julien

On Friday 07 March 2008, Suresh Krishnan wrote:
> Hi Julien,
>    Thanks for the comments. Please see responses inline.
>
> Julien Laganier wrote:
> > On Wednesday 05 March 2008, Suresh Krishnan wrote:
> >> Hi Bernard,
> >>    Please find comments inline.
> >>
> >> Bernard Aboba wrote:
> >>>  > Thus since a SLLAO is present but router2 has no existing NCE
> >>>  > for the host, router 2 will create a NCE for the global
> >>>  > unicast address prefix1::iid although prefix1 is not on-link
> >>>  > and not advertized on link2 by router2.
> >>>  >
> >>>  > Isn't that a problem?
> >>>  >
> >>>  > If it is that could be avoided by specifying that a simple DNA
> >>>  > host MUST source its RS probes from one of its link-local
> >>>  > addresses.
> >>>
> >>> [BA] I think that makes sense.
> >>
> >> This problem does not arise since the RS will use the tentative
> >> option instead of the SLLAO.
> >
> > Ah, ok, missed that. However if the RS is sourced from a link-local
> > we don't even need to rely on the tentative option.
> >
> > Why would it be useful to source the RS from a global unicast as
> > opposed to a link-local address? In other word what would we loose
> > by restricting the source address to a link-local? That seems like
> > an easy and cheap fix.
>
> Sounds like a good idea. I will make the change as you suggest.
>
> >>>  > 2. Problem of default router selection when moving in a NETLMM
> >>>  > domain.
> >>>  >
> >>>  > As you might know, when a host moves within a NETLMM domain,
> >>>  > although it may change attachment link, it will consistently
> >>>  > receive the same router advertisement in RAs sent by the
> >>>  > NETLMM MAGs acting as default router.
> >>>  >
> >>>  > Let's suppose a host change from link1 to link2 served by MAG1
> >>>  > and MAG2. With the currently specified behavior of a simple
> >>>  > DNA host, if the prefix is the same then the host should
> >>>  > conclude it hasn't changed
> >>>  >
> >>>  > link:
> >>>  > > On reception of a Router Advertisement which contains
> >>>  > > prefixes which intersect with those previously advertised by
> >>>  > > a known router, the host utilizes the configuration
> >>>  > > associated with the detected network.
> >>>
> >>> [BA] This is wrong.  Previous configuration should only be reused
> >>> if the RA originates from a router corresponding to a valid
> >>> address.  An RA originating from another router should be
> >>> processed normally.
> >>
> >> I agree with you. That is why the text mentions "known router".
> >> Perhaps the term requires more clarification?
> >
> > Then at minimum the text should have "On reception of a Router
> > Advertisement from a *known* router...".
> >
> > But that wouldn't be necessary if we adopt the text coming from
> > DNAv6 spec regarding default router selection (copied below).
> >
> >>>  > Thus after the link change the host will continue to use the
> >>>  > configuration valid on link1 where the default router is MAG1.
> >>>  > However, it is now attached to link2, where MAG2 should be the
> >>>  > default router. Since MAG2 and MAG1 might well have different
> >>>  > link-local addresses and MAC addresses. Thus, MAG2 will be
> >>>  > added to the default router list but won't be selected as
> >>>  > default router instead of MAG1. This is going to be a problem
> >>>  > since host won't be able to send packets to its default router
> >>>  > MAG1. Thus connectivity for the host will be disabled until
> >>>  > NUD concludes MAG1 isn't reachable causing MAG2 to be selected
> >>>  > as a new default router.
> >>>  >
> >>>  > The DNAv6 protocol had the following provision in section
> >>>  > 5.2.6.3 "Router Reachability Detection and Default Router
> >>>  > Selection" to
> >>>  >
> >>>  > make it work well with NETLMM:
> >>>  > > Prior to sending a DNA RS in response to an indication of
> >>>  > > link change, the host SHOULD set all Neighbor Cache entries
> >>>  > > for routers on its Default Router List to STALE. When the
> >>>  > > host receives an RA in reply to the RS, the host SHOULD mark
> >>>  > > that router's Neighbor Cache Entry [3] as REACHABLE, or add
> >>>  > > a Neighbor Cache Entry in the REACHABLE state if one does
> >>>  > > not currently exist.
> >>>
> >>> [BA] I agree that something along these lines should be included
> >>> in the Simple DNA spec.  I would also suggest that a router
> >>> responding to a unicast NS be marked as REACHABLE.
> >>
> >> I can add this text, but is this any different from 4861 behavior?
> >
> > Yes it is. According to RFC4861 Section 6.3.4 "Default router
> > selections are made whenever communication to a destination appears
> > to be failing", i.e. when NUD concludes the previous router is no
> > longer reachable, that is after a timeout. The above text from the
> > DNAv6 spec would allow to start to use the router that send the RA
> > immediately.
>
> Aah, OK. I see the issue now. So the bone of contention is that we
> will differentiate between REACHABLE and STALE while 4861 will not
> (it will differentiate between INCOMPLETE and non-INCOMPLETE only). I
> agree with you and I will adopt the text from the DNA solution.
>
> Thanks
> Suresh