Keith Moore wrote: > 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. > > > 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. Speed is an implementation issue, not a spec issue. 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. > > > The problems arise from the > > mismatched interpretation by the apps, that all 'handles' will be > > treated equally by the network, > > 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. 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. The fact that over the years a simplification was done through the assumption that there was only a single view is a failure. > > > I agree to a point. My button is pushed by those that claim a > > technology 'creates more problems than it solves', when they > > simultaneously admit they don't have a clue what problems need > > solving. > > I do have an idea about what problems need solving, but I > don't claim to be able to make a list that satisfies everyone > at the drop of a hat. I don't have a list either, but we need to collectively create that list. > > 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. > The problem with trying to make a list of "SL-related > problems" is that there is also a set of problems that don't > directly involve SL but also need to be solved, and SL > precludes solving those problems. I agree there are several problems to be solved, but don't agree that the existence of SL precludes solving anything. If we try to claim that we don't need to work on solving problem X because SL solves it, then I would agree, but so far I haven't heard anyone claim that we shouldn't work on solving the problems. The only thing I have heard is that we have found no use for SL (despite the shipping code that uses it), without the list of basic requirements to judge which problems it does solve. Tony