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

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

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.

> >  > 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.

> >  > > The host SHOULD also update its Default Router List in the
> >  > > following fashion. If any of the routers returning RAs are
> >  > > already on the default router list, the host SHOULD use the
> >  > > information in the RA to update the Default Route List entry
> >  > > with the new information. The host SHOULD add entries to the
> >  > > Default Router List for any routers returning RAs that are not
> >  > > on the list. The host SHOULD confine selection of a router
> >  > > from the Default Router List to those routers whose Neighbor
> >  > > Cache entries are in the REACHABLE state. Note that the
> >  > > Default Router List SHOULD be updated as described here
> >  > > regardless of whether the RA indicates that the host has
> >  > > changed to a new IP link, since changes in router reachability
> >  > > are possible on some link types even if the host remains on
> >  > > the same IP link.
> >  >
> >  > Would it be possible to adopt a similar behavior for simple DNA?
> >
> > [BA] I think it would be possible (and desirable).
>
> Again, I think this is the same behavior specified by 4861. Should we
> reiterate it here? I have no issues adding text similar to this, but
> I would like to avoid duplication between this document and 4861.

This is different from 4861. RFC 4861 section 6.3.6 only states "Routers 
that are reachable or probably reachable (i.e., in any state other than 
INCOMPLETE) SHOULD be preferred over routers whose reachability is 
unknown or suspect (i.e., in the INCOMPLETE state, or for which no 
Neighbor Cache entry exists).

Since the WG had previously agreed on the above text from DNAv6, IMHO we 
can just take it as is since it solve the problem without 
inconvenience.

--julien

> Thanks
> Suresh