[RRG] Re: [RAM] dns discover in map-and-encaps schemes

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Russ White <riw@cisco.com>

    > What happens if I "ping <id>," and the LISP server is down?

Umm, pretty much the same thing that happens when you click on a URL and the
DNS server(s) for that domain are down/unreachable... :-) But to be serious
about it:

    > Is it okay for the network to fail when some set of network reachable
    > servers, or some network accessible service, fails? ...
    > Consider the problem of reachability being predicated on a service.
    > This is a fundamental change in architecture

Here is a slightly extended design-philosophical soliloquy on this general
topic (and maybe some of this was already in your mind when you sent that
message out...):


It is certainly true that systems which i) don't modify the hosts at all and
ii) introduce a new location-namespace underneath the current internetwork
layer, thereby iii) turning the current internetwork "addresses" into names
which are basically purely identity, and therefore iv) require mapping into
location-names to be usable for forwarding traffic, are a significant
architectural change - and one with new failure modes.

I don't necessarily consider the extra complexity (and *necessarily*
consequent extra potential failure modes) to be necessarily bad. Abraham
Lincoln was once asked how long a man's legs should be; his reply was "long
enough to reach the ground". So too with complexity in large information
systems. You need as much as you need.

And you need more complexity as the system gets bigger. [Anyone who doubts
that this is a general law should consider, for example, the anatomy of a
single-celled organism versus your average mammal: the mammal has all sorts
of specialized sub-systems - e.g. the circulatory system, which has its own
specialized failure modes such as blockages caused by a variety of buildups -
which the smaller - and simpler - organism lacks. (And no matter which side
of the evolution/design split you fall on, you have to agree that something
pretty intense decided it *really needed* that extra complexity! :-)]


So the questions really are:

- Do we need this extra complexity (and necessarily consequent new failure
modes), and
- If so, how do we deal with the problems this extra complexity brings,
e.g. how to protect against those failure modes, how to make sure we
can debug/fix failures (i.e. operations/maintainence issues), etc.

If our goals are i) to not modify hosts, and ii) add another namespace -
both goals which I think are reasonable - then *necessarily*, something out
there is going to have to do mappings. So now the only question left is "how
to deal with the problems this inventably brings, such as new failure modes".

Now, that's a reasonably well-understood field. Systems designers have been
dealing with these issues for many decades now. Some of the tools we use
to do this are:

- a) Make sure we don't have any dependency loops (i.e. subsystem A depends
on subsystem B which depends on subsystem A)
- b) Make sure our debugging tools for debugging system Y (which depends on
X and below) only depend on X and below, and make sure we have direct
access to X and below, without going through Y
- c) In a distributed system, use replication to ensure availability

These are tools we already use - e.g. when you type IP addresses directly
into a tool, without using DNS, you're doing b); and DNS itself uses c) to
increase its robustness. And there are more techniques, I won't go into a
long spiel on them - the point is we know how to do this.


And while I'm in this general area, I'd like to rant a bit about people who
assume addresses, and routing (path-selection) mechanisms, are somehow
fundamentally different - more reliable, more trustworthy, more available,
more *special* - from every other mechanism (e.g. mapping services).

They aren't.

It kind of drives me batty when people assume raw IPvN-style addresses are
somehow fundamentally different from all other possible mechanisms, that they
have some ethereal quality which necessarily makes them more reliable, more
dependable, than all other mechanisms.

They aren't.

Path-selection and forwarding are also complex distributed system with all
sorts of failure modes. The people who designed them are fully aware of how
critical they are, and have used a lot of ingenuity, and in many cases some
pretty complex and heavy-weight mechanisms (try read the IS-IS or OSPF specs)
to make sure they *are* reliable and dependable. But they accepted that
complexity to make the *overall* operation one that one can rely on.


So, circling back to where we started, given a certain goal-set (not modify
hosts, and add another namespace) then something out there is going to have to
do mappings; and we'll just have to deal with the problems this inventably
brings: but I think we know how.


    > this brings up a fundamental point we need to consider in all cases of
    > locator/id split ...
    > ... reachability being predicated on a service ... one of the possible
    > negative side effects, of a locator/id split of any type.

If you get to change the hosts, you can avoid this problem in a number of
ways. One is to say that *all* DNS entries have to contain both location and
identity names, and the lookup returns them both, and they travel around
forever thereafter as a tuple (unless the binding is modified in some
suitably-secure way). Another is to keep the existing DNS (returns
location-name only), and pass identities in the connection-open packets in
each direction. Etc, etc...

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg