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

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

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