Re: [DNA] linkid [Was: Couple of points ondraft-jinchoi-dna-soln-frame-00.txt]

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

Hi Erik, 


----- Original Message -----
From: Erik Nordmark <Erik.Nordmark@sun.com>
Date: Tuesday, August 3, 2004 4:52 pm
Subject: Re: [DNA] linkid [Was: Couple of points on draft-jinchoi-dna-soln-frame-00.txt]

> 
> > Really I was talking about a common (explicit)
> > linkID, which could be configured on all
> > routers. 
> > 
> > The existing 2461 statements about disjoint prefixes
> > being allowed on a subnet would indicate that 
> > routers will not be able to always agree on a 
> > prefix which they can all advertise.
> 
> No matter how the linkid is picked (some local ID, a large random
> number, or an existing prefix) the routers on a link would need to
> agree on which number they advertise. Thus unless
> you do manual config or the routers, there needs to be a router-to-
> routerprotocol to agree on the number to advertise. (And DET also 
> needs a 
> router-to-router protocol for agreement about something else, so
> one can probably do this in the same exchange.)

Agreed,

In fact that's what linkID-02 does now.
(it was updated before the -XX drafts cutoff)

> > If they did so, one or more routers would be
> > advertising a global prefix they have no
> > existing configuration knowledge of...
> 
> Yes, but that is true for a linkid which is a random number as well.

Indeed.

Please note that I was talking explicitly about 
Prefix Information Options (PIOs),
rather than prefixes though.

> > This may be misleading or inappropriate
> > when dealing with non-DNA ipv6 hosts.
> 
> I'm confused. I'm assuming there will be a new linkid option in the
> RA with the semantics know to the host that "this uniquely 
> identifies a link".
> Thus non-DNA hosts would silently ignore that option.

That's correct.

Once again, I think I was trying to argue against
something you weren't proposing.

I was saying: Global may be OK, reusing the 
ND prefix information option is not.

> Further, whether the number in the linkid option is a random number 
> (whichthe routers on the link agreed on), or a global prefix 
> assigned to the link
> (which the routers on the link agreed on) doesn't even have any impact
> on DNA aware hosts. The only issue is whether
> - the probability of random numbers colliding should be of concern
> - the need to change a prefix-based linkid when the link is 
> renumbered   is of concern

It makes the selection slightly more difficult
than a meaningless number.

Not much.

I think the big issue with global identifiers
is that they're >= 64 bits... (and fit
into >=128 bit options).

If we want to send LinkID always, this may be
a big consideration.

 
> > If we have a separate option which has
> > a globally unique identifier (or even a locally
> > unique one), then the information will have
> > different semantics not tied to existing 
> > prefix information option semantics.
> 
> Ah - you thought I wanted to use the prefix information option to 
> carrythe linkid. I don't. But that explains the confusion.

Indeed.

Actually I was trying to indicate why you don't
want to do that.
 
> > This may lead to additional information being
> > transmitted in RAs though (the explicit 
> > link identifier option).
> 
> Yes, but if we have a random number as the source for the linkid,
> it might make sense to make that as large as 128 bits as well.
> So the size of the linkid option might be the same whether random
> or prefix-based.

Well, there are tradeoffs with size.
THe collision probability and failure cases
are sufficiently mild to not worry too much.

If we make the linkID >=64 bits, we may as well 
use the lowest guaranteed unique prefix (or 
address), regardless of the overall option size. 

Greg