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

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

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.  When the subsequent NO answer arrives, the accompanying
prefixes will also show that there has been no link change and the
NO on that particular prefix gives the _additional information_ that it
is no longer valid (though the extra information is not necessary
because the second RA will have that expressed with a P1 PIO with zero
lifetime).  LinkID gives the same result.

>> For CompleteRA (which is proposed as a fallback for when it is not
>> possible to use landmarks):
>>
>>    By its nature it creates overlap between the sets of RAs advertised
>>    by the routers on a link.  It doesn't matter whether the sets
>>    agree completely or not, as long as there's overlap (because link-
>>    change is detected by receiving a RA with a set disjoint from the
>>    set of prefixes the host has seen on the link).  The pathological
>>    case that we may need to take action to avoid is where a router
>>    that is currently configured with all of the prefixes in use on a
>>    link, suddenly has all of them removed and replaced with a new
>>    disjoint set.  We need to add some text to say not to do that.
> 
> 
> 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.

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

Brett.