> > ... 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