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