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

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

Tero Kauppinen (JO/LMF) wrote:
> Hi Brett,
> 
> I'm having this endless LinkID v.s. Landmark battle in my head while
> trying to grasp what has been said and written.
> 
> Anyway, I started think the following naïve example:
> 
> R1 : advertising P1               R2 : adverstining P2 thus {adv:P1,
> learned:P2}         thus {adv:P2, learned: P1}
> 
> node H: knows P1, P2 and has chosen P1 as the landmark prefix
> 
> Let's assume that R1 stops advertising P1 and starts advertising a
> new prefix P3. The host doesn't receive RAs and is unaware of the
> change. The node moves to another AP and gets a "no" answer. The
> landmark approach indicates wrongly a link change, but CPL will show
> that there is actually no link change. If I have been able to follow
> the discussion, it has been said that the CPL decision should
> overwrite Landmark's decision in this case.

It doesn't have to be CPL, but the presence of prefixes in the RA that
the host has seen before are a strong indication that link change has
not taken place.  The draft is not clear on this because we still have
it as an open issue (issue 9 - actually dates back to when we had the
"landmark not on link option" but the concept is the same).  I
definitely think that matching prefixes should overrule a "NO" answer.
There were some concerns that the inconsistancy should mean that we
fall back to another means of identifying the link (CPL?) but I think
that means we'll end up with the same result.

> 
> I agree but I guess a lot of fuzz is because this is not clearly
> stated in the draft -- should it or is it still an open issue? This
> would practically mean that every time a "no" answer is received, the
> current list of all known prefixes on the link is checked in order to
> confirm that the RA doesn't contain a prefix which is already known
> to be on the link.
> 
> ...or am I just once again completely lost? :)

No, I think you've pretty much got it.  See above re: the open issue.

> 
> Might also be that we should write down something about the case when
> a node changes the landmark prefix. If the node received a
> zero-lifetime advertisement for the current landmark prefix, it
> should pick another prefix. On the other hand, "5.2.3. The prefix
> MUST have a non-zero valid lifetime" is a way to say it.

I think so.  :)

Cheers,
Brett.