[DNA] Re: Comments on draft-jinchoi-dna-cpl-00.txt

[Samita Chakrabarti <Samita.Chakrabarti@eng.sun.com>]

Hi JinHyoeck,

Sincerely sorry for the late response and long absence in this list.

Please see my comments below.

> >  A slightly alternate proposal that Hari and I have been discussing with the
> >  authors :
> >     
> >    On a new link initially:
> >    
> >   - MN link up - does send RS
> >   - receives RAs 
> >   - builds prefix and corresponding IPv6 link-local address of the router
> >   - caches the information with periodic updates
> >   
> >    MN moves to a different link
> >    - receives link up for wireless link, for wired it may be optional
> >    - sends RS and receives RAs [ to make it more efficient, it might
> >      be useful to send unicast router soliciation ]
> >    - compares the prefix and the corresponding Ipv6 link-local address
> >      of the router match with the cached information.
> >      if any one response matches with the any pair in the cache - it
> >      is still on-link (Link-local-addr confirms the link, prefix confirms
> >      the uniqueness of the link)
> >    - if the set is disjoint it has moved.
> 
> I am afraid the above results in incorrect detection. 
> 
> Assume a router has two interfaces attached to two different links. Also 
> suppose two interfaces advertise two different prefixes but have the same link 
> local address. Then if a host adopt the above scheme, it would not detect link 
> change when it moves from one link to another. 
>

As per the above proposal, it compares the old-prefix  && link-local address
with the new prefix and link-local address. Thus if the two link-local
address happen to be the same, then it would have to fall back to complete
prefix list. But in other cases, comparing both prefix and link-local
address may provide optimization over building a complete prefix list.

I agree that the complete prefix list is more accurate and it will work fine if
there is not too many RAs on the same link.  But I was wondering if this
approach would optimize the detection time in most of the cases.

      
> >  Apparently, it seems it might be faster because it stops the comparison
> >  until it finds the first match. 
>  
> In case there is no match, hosts have to make one more comparison. 

Correct.  In worst case, it is no different than building a complete
prefix list.


Thanks,
-Samita