... 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. 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?)
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.
(yes, GUPIs, NOT SLs. they WILL be routed between sites, for good
reasons, and we shouldn't try to stop this)
Keith