On Thu, 1 May 2003 15:58:25 -0500
"Stephen Sprunk" <stephen(_at_)sprunk(_dot_)org> wrote:
Thus spake "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)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