Subject: Re: [lisp] ALT structure, robustness and the long-path problem

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Dec 2009 15:59:52 -0500 (EST)

> From: Robin Whittle <[email-masked]>

    > I understand that LISP-ALT has been proposed as the best solution for
    > the routing scaling problem

LISP, or ALT? They are not the same thing. ALT is one option for a
_component_ of the overall LISP architecture.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Dec 2009 20:36:17 -0500 (EST)

> ALT can be made to perform well by the use of "replication".

I didn't say that it could be made to perform well by use of replication. I
said it could be made more reliable in the face of failure through use of
replication. Big difference.

    > with no caches in the ALT network itself.

Yet. (The whole LISP system is work in progress, including the ALT.)

    > Mobility along the lines of LISP-MN, with the MN being its own ETR,
    > won't be practical for IPv4 since the MN can't be behind NAT. 

There are working examples of such. (All it needs is a way to find the
external address of the NAT.)

    > I don't see what "replication" means in the ALT network if it is
    > different from caching. Can you give some examples?

"Replication" means 'duplicated nodes', i.e. alternate paths through the ALT.
This is trivial to do, since the ALT is based on BGP, which was designed to
handle connectivity graphs with cycles. I had originally investigated this
for other reasons (to minimize delays), but it's equally effective in
producing a system which is robust against node failures.

    > Ease of design is an important factor when testing and prototyping.

I didn't say "design", I said 'implemention and deployment'.

    > It is pretty much irrelevant when considering how best to modify the
    > Internet on a permanent basis to solve the scalable routing problem

If we had a large budget and lots of available programmers, no, it woulnd't
be that important. Do you have a source for such? When one has to operate on
a shoestring, as the current LISP effort does, one has to take a different
path.

You know, the current Internet, crappy as it is, is still a lot more advanced
than the earliest system that was used for actual usage. The Internet circa
1980 had no DNS, no ICMP, no BGP, no DHCP, 8-bit network numbers only, no
congestion control, the list goes on and on. Does that mean that because it
used primitive kludges for most of these functions that it was a bad idea to
do it without those being completed? No, because if we'd had to wait until
all the pieces were in place, we'd still be waiting.

    > the enthusiasm for LISP is because people believe it will be the
    > optimal solution

Not in my case, because to me it is merely the first step on the best path.
("A journey of a thousand miles starts with a single step", and all that.)

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 8 Dec 2009 20:42:41 -0500 (EST)

> From: Sam Hartman <[email-masked]>

    > it would be great to see someone working on testing a non-alt mapping
    > system. I realize it's out of scope for this WG, but it's still very
    > interesting.

I agree very strongly, because it would teach us a lot about what we need to
see in the ITR<->MR and ETR<->MS interfaces. The thing is that the details
will vary, depending on the exact details of the mapping system (e.g. if we
add more caching, inside the distribution network).

I've been thinking about a number of changes (e.g. caching in the MR's), and a
different mapping system (and did a lot of work on CONS in the past), and all
of them show that the current interfaces aren't quite general enough to be
what we really probably ought to have.

wSo I personally would just love to see us design interfaces to a couple of
different mapping-resolution systems, and use that to see what the 'envelope'
of those client/system interfaces needs to look like.

	Noel