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