-------- Original Message --------
> From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
>>> Number portability, after all, only requires a layer of indirection.
>>> We can certainly engineer that!
>> And we have. It's called the DNS.
> no it's not. DNS sucks for that. it's too slow, too likely to be out
> of sync. DNS names are the wrong kinds of names for this.
Pardon me, but my bogometer just pinned. You keep bitching about the DNS,
and a lot of your complaints have a point, but this one is too much.
The whole effing point of the DNS is to translate from 'service-names' (to
coin a term) to addresses. If the DNS can't do that, what the hell is the
point of it?
'service-name' is a pretty vague term. what one person means by that
term might not be the same as what a different person means by that
term. also, while DNS might be used for mapping service names to
addresses, that (in my understanding) is not quite the same thing as
what it was designed to do - DNS has become the proverbial hammer that
has been used to drive all kinds of things that only vaguely resemble nails.
what I want is a layer of indirection that
(a) accepts things that look like IPv6 addresses (so that the host to
network and the API doesn't change, and also so that it's possible to
send traffic directly to a locator using the same interface on the
occasions where that is appropriate)
(b) is highly likely to be in sync with reality, in that it's inherently
maintained by the same people who maintain routers and network links and
advertise BGP locator prefixes. DNS is sometimes maintained by these
folks, sometimes not, as it's really more of an application layer
concern, though it has often been corrupted by tying it to DHCP. but I
digress.
(c) is coarse (meaning that it doesn't try to provide indirection on a
per-identifier or per-locator basis, because that would impair the next
goal)
(d) provides fast lookups (meaning that the indirection data is
replicated so widely that in most, maybe all, cases there's no need for
a lookup to an external host - the router that adds the forwarding
header already has that redirection information on hand). in other
words, the data is flooded, not merely cached.
(e) supports multihoming
> we can build indirection into the routing infrastructure.
Can I get you to be a little more precise in terminology here? Are you
talking about putting indirection into the "routing" (i.e. path-finding,
including databases and algorithms), or into the "forwarding"?
by 'infrastructure' what I mean is that this is a new service that would
be provided by augmenting the functions that routers currently perform.
From your later message it seems you visualize more the latter? And you do
not seem to be visualizing doing this mapping at every hop?
correct. I want to do the mapping on the periphery of the network, at
what I think of as "border routers" but at any rate no later than the
boundary of the default-free zone.
part of this stems from a desire to avoid having to do wire-line speed
lookups in portions of the network where the wires are so fast that
memory lookups are too slow (though I don't pretend I can avoid all of
those cases).
more generally I think there's an inevitable trend towards "state at the
edge of the network" (rather than just state at the endpoints) and I
think it makes architectural sense to try to collect that state in one
place for better fate sharing. so I can imagine that the same box that
adds the outer header on transmission and strips it on receipt also
implements a firewall and a home agent for mobile IP.
In other words, architecturally speaking, you're proposing jacking up the
current 'internetwork' layer and putting a new, second, 'internetwork' layer
underneath it? In other words, you'd be creating a new name-space *below* the
current 'addresses', which would become mostly just identifiers? Shortly
after being emitted, packets would be wrapped up in a lower-layer, but still
internetwork-wide header, which contained the 'locator' of their destination?
in a nutshell, yes. I don't pretend it's that simple - in particular I
think that having different zones of the network (one where identifiers
are used, another where locators are used) would have 'interesting'
ripple effects on the architecture, and that it would take some time to
understand those and to minimize the worst effects. for instance, I
doubt that we can cleanly separate the two zones. but that's the basic
idea.
> identifer to locator mappings that is distributed via BGP.
BGP has a hard enough time as it is. You complain about people wanting to
dump the kitchen sink of functionality into DNS, because it's there, but
you're happy to commit the same sin yourself, elsewhere...
fair point. But I don't see BGP as doing anything other that carrying
the data. in other words I don't think that this should affect
forwarding table computations or interact with routing policy (much).
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf