Re: [DNA] Possible way forward: combining Link ID and Landmark?

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Pekka and Syam,

I agree that these are potential mechanisms for combining
the systems for link identification.   At this stage,
but without necessarily preempting the consensus call,
the chairs will soon approach people to help move toward
having a single solution, so that if the consensus
is confirmed, we're in a good position to move forward.

Syam's question at the end: are we over engineering?
is probably a relevant one, though.

At this stage there seems to be an agreement that the
actual solution's form isn't as important as the fact
that it does the job well most of the time, and we
move forward with it.

Greg

Syam Madanapalli wrote:
> Hi Pekka,
> 
> We need to use linkid for its robustness against 
> changes in linkid due to prefix addition/deletion,
> landmark to benifit for nodes moving from non-DNA
> to DNA link, complete RA to build the CPL fast for
> fast moving nodes. And also it may be good to use
> Landmark YES answer and to avoid the periodic
> complete RA to save the bandwidth (use linkid).
> 
> So I am thinking about the following solution.
> 
> 1. On DNA links routers advertise linkid in RAs.
> 
> 2. A node with Link_Up sends an RS with landmark,
>    if the landmark presents, the router sends an 
>    RA with linkid.
> 
>    The other alternative is to send YES answer.
> 
> 3. If the Landmark does not present, it sends a
>    complete RA with linkid (i.e. I bit set for one
>    of the prefixes)
> 
> 4. If no linkid present (moving from non-DNA to DNA link)
>    the node picks one of the prefixes as the landmark.
> 
> The complete RA is sent only when there is a link change.
> 
> 
> -Syam
> 
> PS: are we over engineering?
> 
> 
> On 8/8/05, Pekka Nikander <pekka.nikander@nomadiclab.com> wrote:
> 
>>[As I wrote earlier, I haven't been able to follow the ML discussion,
>>and won't.  My sincere apologies.]
>>
>>Based on what I heard during the WG meeting on Thursday and in some
>>discussions afterwards, the following proposal occurred to me.  It
>>may be completely off the mark.  If so, please ignore it.  I am
>>offering this just in the case it might be useful and let the WG to
>>move forward.
>>
>>Would the following work?
>>
>>  1. Define a new Link ID RA option, as in the Link ID draft.
>>
>>  2. Define new Landmark RS and RA options, as in the landmark draft.
>>
>>  3. Routers in a link are encouraged to create a Link ID and
>>announce it, but not required.  [Details need to be filled in, e.g.,
>>if all routers need to agree etc.]
>>
>>  4a. A host that arrives on a link *with* a Link ID picks the Link
>>ID as its landmark.
>>
>>  4b. A host that arrives on a link *without* a Link ID picks one of
>>the prefixes as a landmark, just as in the current landmark draft.
>>
>>  5. When a host detects that it may have changed links, it looks
>>for a landmark (as in the landmark draft) unless it gets a Link ID
>>(as the landmark) very quickly (as in the case of FastRA-like
>>optimisation).
>>
>>Based on my very partial understanding, the above outline might
>>work.  However, it may also be more expensive (in term of bytes or
>>packets) than the current proposals.  On the other hand, it might
>>also be more flexible or robust.
>>
>>Maybe someone could do further thinking and analysis.
>>
>>--Pekka
>>
>>