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