On Thu, 1 May 2003 15:58:25 -0500 "Stephen Sprunk" <stephen@sprunk.org> wrote: > Thus spake "Keith Moore" <moore@cs.utk.edu> > > being able to distinguish an ambiguous address from a global address > > doesn't solve the problem of requiring hosts or apps to be aware of > > topology in order to make address selection. > > A host/app needs to be similarly aware of topology (and security > policy) to make any reasonable selection between multiple global > addresses. agree. > Adding non-globals to the mix doesn't make things significantly worse. Disagree. First, it immediately reduces the available choices, and thus, the potential for poor choices (since SLs are more often poor choices than not). Second, it pushes the burden of routing back into the network where it belongs. Third, while it's possible (though unattractive) for the network to supply some topology information to hosts in a world where identifiers for points in the topology are all are taken from the same name space, having ambiguous addresses makes this completely infeasible. > > If we can agree on how to make the first 48 bits globally unique, > > does it really matter what values are assigned to the first 10 bits? > > Yes, it does. Having a common prefix for non-global addresses makes > the job of network managers much simpler Not clear; since it doesn't necessarily give them the flexibility they need. The idea that a network has only one boundary of interest is of fairly limited applicability; it's certainly not something that is general enough to be wired into the addressing architecture. however, I was referring specifically to the prefix FEC0://10. Yes, it's already allocated, but it's also defined in such a way as to be dysfunctional, and too many broken assumptions are wired into existing code. So for the sake of compatibility it seems better to allocate another prefix for GUPIs. > > (yes, GUPIs, NOT SLs. they WILL be routed between sites, for good > > reasons, and we shouldn't try to stop this) > > Since this is the first time I've seen "GUPI" used, should I assume > that means a globally unique provider-independent prefix which isn't > globally routed? yes. > If so, I think you're using that term in the same sense Tony uses SL. IMHO, they shouldn't have any "site" or filtering assumptions wired into them, they're just a set of prefixes that are not dependent on a provider and can't be assumed to be globally routable. But to make them work we'll need a way to transparently map/forward them to routable prefixes. Keith