> > if the architecutral guidance were crisp it certainly > > wouldn't be asking the DNS related WGs to discuss those > > issues. DNS cannot solve this problem. > > I agree all infrastructure & components that pass around topology > information need work, but DNS is one of those, so it is a good place to > start. disagree. "starting" to work on this within DNS would be a distraction at best. > > > As long as the handle stays contained within the machine you are fine. > > > The problem arises when the app passes that handle to another node, > > > believing that the topology specific information is already there. If > > > the blob passed were the same as what the app used to acquire the local > > > handle, the other nodes would acquire appropriate local handles. > > > > this presupposes that the blob that is passed is precisely > > and reliably bound to the specific host or process that the > > app wants to refer to, and also that the lookup process that > > maps blobs to locators and/or identifiers is sufficiently > > fast and robust. often neither of these conditions holds. > > If the first one doesn't hold, the origin node can't use it so the whole > app is broken. false. it happens all the time. a function that converts a service name to an address doesn't have to produce identical results each time to be useful. and yet, if two separate processes need to connect to the exact same process, the service name alone may not be sufficient to allow them to do that. > Speed is an implementation issue, not a spec issue. false. depending on how you architect a service there can be fundamental and/or practical limits to speed. > In any case, it is much faster to pass a blob that can be mapped into > useful topology information, than it is to pass around useless topology > information. it's even faster if the network provides uniform addressing; then the addresses are no longer useless. why do you keep trying to force useless addresses on us when we can have useful ones at less cost? > > heaven forbid that apps would assume the same thing that the > > IP network was designed to assume - that there is a uniform > > address space across the entire network. but you want to > > change this fundamental architectural design point at layer 3 > > and then claim that the resulting problems are caused by > > inappropriate assumptions at layer 7. some would say this is > > layering violation, but the sharing of identifiers between > > layer 7 and layer 3 is another fundamental architectural design point. > > I am not saying that. From day one, a host that had one interface where > the address prefix was not passed widely in the routing system, and > another where the prefix was passed globally would have exactly the same > issues you are complaining about. it's hardly relevant, since that's not the way things happened. > This says nothing about firewalling, > qos, ambiguous addresses, etc. This is simply about a host having > multiple addresses, where different points in the network have different > perceptions about the viability of those. yup. and the realization that this is a lousy way to design a network > The fact that over the years a > simplification was done through the assumption that there was only a > single view is a failure. and in fact it's a very useful and compelling simplification. > > But it's not clear that SL was actually intended to solve any > > of these problems. Rather, it seems to me that somebody > > thought SL was a good idea, and put it into the v6 > > architecture. And then various people started saying "hey, > > we can use SL for X", and nobody bothered to examine whether > > there were conflicts between those various peoples' > > assumptions (whether specifically about SL or not), or even > > whether SL was worth the cost, until recently. > > Fine, we need to create the list, figure out alternatives and as you > said in SF, push SL into the corner cases, if we still need it. Getting > rid of SL first does not solve the problems. we've tried going on the assumption that SL will work, and we've not been able to resolve the conflicts and problems that result from that assumption. now we need to try the assumption that we can do without SL, and see where that leads. perhaps we will find that we can do without SL, or perhaps we will still need SL for a couple of corner cases. we won't know for sure until we try to work out the details, and we won't have completely decided for sure until we actually approve a specification that incorporates those details. but that's the direction that the WG has decided to pursue, and I think it's the right one. Keith