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

[Suresh Krishnan <suresh.krishnan@ericsson.com>]

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.

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

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

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

Thanks
Suresh