On vrijdag, aug 29, 2003, at 23:06 Europe/Amsterdam, Keith Moore wrote:
It's not uncommon to see a FQDN point to several IP addresses so that
the service identified by the FQDN can be provided either by
(a) multiple hosts, or
(b) a host with multiple addresses.
No. A client can't tell whether multiple addresses associated with an
DNS name indicate multiple hosts or multiple addresses for the same
host.
Right. And a session can't jump from one address to another either. So
when we implement the latter, we also address the former.
As a member of the multi6 design team that works on a (b) solution I'm
convinced that such a solution will provide many benefits and should
be developed and implemented.
And I'm equally convinced that a solution that assumes (b) is a
nonstarter. There is already too much practice that conflicts with
it.
To be more precise: the idea is to have transport sessions move from
one address to another when there is a rehoming event. Obviously there
will be changes to the process of publishing additional addresses.
It would make sense to
create something new that sits between the transport(s) and the
application, and delegate some tasks that are done by applications
today, most notably name resolution. This allows us to implement new
namespaces or new address formats without any pain
No it doesn't. What it allows "us" to do is impose subtle changes in
the behavior of lower layers, and introduce new failure modes, without
giving applications any way to deal with them.
Well if we make a new API that allows applications to set up sessions
based on FQDNs, and then later we decide that the next version of IP
really needs variable length addresses where the address length in bits
is a prime number, existing applications _should_ continue to work.
Experience shows there are always cases where things aren't as simple
as all this in practice, but I don't see how this can be worse than
being 100% positive that the applications won't work and must be
changed to support the new address format.
But the real question here is: does this new "thing" have to be a
layer?
It depends on which "thing" you are talking about.
New API and/or mechanisms to distribute operations over multiple hosts.
For the L3-L4 thing, it's either a new layer or a change to an
existing layer.
Agree: both ends must cooperate, so a layer (new or modifications to an
existing one) makes sense.
If you have both the L4-L7 thing and the L3-L4 thing, the former is
either a new layer or (my personal opinion) a new API that
knowledgable apps
call explicitly.
Right, and API != layer.