Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix

[Syam Madanapalli <syam@samsung.com>]

Hi Brett,


> Hi Syam,
>
> Syam Madanapalli wrote:
>> Hi Brett,
>>
>> [cut]
>>
>>>>
>>>> These are my line of thoughts. We can't avoid a temporary flapping for 
>>>> the related set, the set of
>>>> all prefixes
>>>> on a link. In linkid scheme, one item (linkid prefix) of the set 
>>>> matters for DNA
>>>> performance.
>>>> So we designed a few special schemes for the linkid prefix so that
>>>> linkid prefix(es)
>>>> won't give incorrect information about a link change, even under
>>>> temporary flapping.
>>>>
>>>> But for Complete RA or Landmark, IMO, we need to adopt similar schemes 
>>>> such as "Linkid Prefix List" or "Old linkid advertising rule" to all
>>>> prefixes because we
>>>> don't know which prefix will affect DNA decision.
>>>
>>>
>>> For Landmarks:
>>>
>>>    If a prefix is removed, the host will receive a "NO" answer, which
>>>    also include prefixes that are on the link and have been seen by the
>>>    host before so it can see there is no link change and yet will also
>>>    know that the prefix it was using as a landmark is no longer valid.
>>>    (I think we need text to clear that up)
>>
>>
>> A host may get 'YES' answer from a Router (R2) before the 'NO' answer
>> from Router (R1) because the deletion of the prefix (P1) at R1 might not 
>> have
>> propagated to R2 at the time of answering the landmar query for P1.
>
> Yes, and as far as DNA goes that is the correct answer in that there is
> no link change.

What if you get answer 'NO' first?
Will you check with the prefixes received in the RA?
This looks better compared just depending on the
Landmark answer. Otherwise host makes wrong decision.

[cut]

>>
>> As we are not anyway interested in building the complete prefix list,
>> why cannot we just depend on CPL to build. I did not remember
>> the waiting time for building the CPL, but I am sure it will be in few
>> seconds. When a host sends RS with Landmark question, and answer
>> is 'NO' a host can buid the CPL (almost) from the resulting RAs which
>> is sufficient to detect the link change at the new link even if the node
>> moves within few seconds.
>
> Just relying on CPL instead of CompleteRA is a possibility.  Depends if
> folks are willing to have a window of 12 seconds (?) after each link
> change where another link change will not be able to be detect rapidly.
> When we wrote the proposal, we felt that we needed something more.

I think 12 seconds is very small considering mobility  :)

>
>>>
>>> LinkID has a much more complex technique for managing prefix change
>>> involving advertising prefixes for some length of time with short
>>> lifetimes before advertising them with zero lifetimes in order to
>>> avoid confusion.  I don't think this is needed for Landmark/CompleteRA.
>>
>>
>> If we need to have the similar confidence in determining the link change 
>> with
>> graceful prefix addition/deletion, we need similar techniques for all of 
>> the
>> prefixes on the link incase of Landmark/CompleteRA.
>
> I think I've shown that those additional techniques are not needed for
> Landmark/CompleteRA.  It may be that they are not needed for LinkID
> either.  I think the LinkID proposal would need to be modified to allow
> hosts to use the other prefixes in the RA for link identification, not
> just those marked as LinkIDs.

Linkid does allows the checking for the other prefixes in RA, but it checks
with only the linkid list that host maintains.

>
> Brett.
>
>