Keith Moore wrote:
... Finally, if you want
any app - even this "special" app, to be aware of topology,
then the first thing you need is globally scoped labels for
points in the topology - which is exactly what exposing site
locals to applications denies you.
What ??? Yes we need a way to differentiate them, but
eliminating the
local one doesn't accomplish that. The labels FEC0::/10 vs. 2::/3
provide exactly the scoping differentiator this statement claims to
need.
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.
Ambiguity has nothing to do with the address selection problem here.
More below.
the problem here is that an SL address is ambiguous in almost
any context outside of an RA or IP header; so there's simply
no way to be confident that a particular SL belongs to a
particular section of the network.
ambiguous addresses are both the factor that would force
hosts and apps to be more aware of topology AND the factor
that make it intractable for hosts and apps to be aware of
topology. Not only do they cause this problem, they preclude
any solution to the problem.
Making all labels global only works if the routing is in
fact globally
flat.
It's worked in IPv4 for 20+ years. What has been repeatedly
shown to not work well is to try to route on non-global
labels. (anyone remember uucp mail or easynet?)
It has never worked for multi-homed systems when some of the
participants in an app have a different view of the topology.
Yes, we need to complete the work on
making the 38 bits globally unique, but that can't happen
if we start
by eliminating the first 10.
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? That choice could be made strictly on the
basis of compatibility issues with existing hosts, apps, and
routers, once the other technical aspects of GUPIs had been
worked out.
Which is one of my points. There have been several proposals offered to
create probabilistically unique 38 bit values, that are compatible with
shipping code that use that specific /10. In other words we have the
technical means to take the ambiguity issue off the table. Getting rid
of the shipping /10 doesn't accomplish the goal of removing ambiguity,
it only delays getting there.
Your other issue about address selection doesn't go away. IPv6 nodes
will have multiple addresses, therefore a list to select from. With a
distinguishing flag (upper 10 bits), it becomes possible for the
processes that resolve names to topology locators in order to sort it
out. Without that flag there is no consistent way for that process to
know. If that process is the end app (because it doesn't trust any other
process to be fast or reliable enough), then the app needs to know the
topology it explicitly intends to describe. If the app doesn't want to
learn topology, it must choose to hand the task off to a process with
the means to figure it out. The current DNS is not up to the task, so it
either needs to be fixed, or a replacement defined that actually
addresses the issue here.
Tony