Re: More LinkIDs (was Re: [DNA] 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 6:01 pm
Subject: Re: More LinkIDs (was Re: [DNA] Couple of points on draft-jinchoi-dna-soln-frame-00.txt)

> 
> > Well, we really only need to keep track of the
> > links which are immediately adjacent to 
> > the MN, so we can discard knowledge of 
> > all but the current link ID.
> > 
> > The lifetime of the link ID knowledge is then
> > tied to the mobility of the MN, rather than
> > the duration.
> 
> Yes, but as I said in some other email, this
> notion of adjacency is a function of how "far" the host can
> move while it retains information about the old linkid.
> And since it can move between different operator's networks
> in milliseconds, clearly you would need to make sure that
> all operators that cover the same geography use distinct link IDs.
> 
> Furthermore, I think there are some performance benenefits for a host
> to be able to cache information (prefixes, default routers, DHCP 
> leases, DNS
> info, all subject to their respective lifetimes) for links it has 
> recentlyvisited. Thus it might make sense to look at the case when 
> the linkID
> is retained for at least a few minutes.
> 
> > The chance of collision is also much smaller,
> > even if there's 100000 (even potentially) 
> > reachable networks, we're only interested in them.
> > We're not interested in any transitivity to these
> > networks' neighbours.
> > 
> > This is about 3.5*10^-5 collision probability
> > by birthday problem for a 48 bit (truly) random
> > identifier space.  Links with routers which are
> > incorrectly judged as reachable will time out
> > after about 47 seconds though (30 reachable +
> > 5 delay + 12 NUD) seconds.
> 
> What can't information be cached about a linkID longer than 47 
> seconds?

Well, it could be (especially in the 
globally unique case), but it's not necessary
to identify that there's been link change.

(which is the minimum sufficient goal for DNA).

If it's  important to store cached information
about links, we're likely to be just as well
served by keeping our L2 segment identity 
cached, since this will uniquely look up 
a set of router prefixes on a link.

If linkID is not tied to any information about
the network, then that's a less stable thing
to tie the router identity to.
> > I think that for particular link types we should
> > not correlate the link ID's seen between the 
> > interfaces.
> 
> I don't see how using the link type helps; my employer can run a
> 802.11 network and the cafe downstairs runs a separate 802.11 
> network (with
> overlapping coverage). Thus we still need to worry about multiple 
> operators 
> not picking conflicting link IDs.

Yes. 

These are "Adjacent networks" in my definition.

they'll be visible through the same interface.

> > I believe that the number spaces for a WLAN
> > and an Ethernet Interface on a host are thus
> > independent, since they're identified by a host unique interface 
> index.> 
> > This isn't necessarily explicitly stated anywhere, 
> > but follows if we believe that DNA is per-interface,
> > and that interfaces are identifiable within the
> > host.
> > 
> > The WLANs may each be reachable from each other,
> > but the GPRS isn't from the WLAN's host interface
> > perspective.
> 
> I think there isn't any harm in treating the linkIDs for different 
> interfacesas different, but I don't see how it helps disambiguate 
> things due to
> different providers (that can overlap) for 802.11 as well as for GPRS.

Well I guess that I'm assuming that different
operators can be adjacent
(any wlan site nearby, or even not nearby). 

There was a reason I chose 100000, not 100.

Greg
> 
>