Re: [RRG] Mobility considerations in proposal evaluation

["William Herrin" <bill@herrin.us>]

On Tue, Feb 26, 2008 at 12:34 PM, Tony Li <tli@cisco.com> wrote:
>  exploring.  The input that we've seen from Mark Handley suggests that
>  we've been thinking very much inside of our box and that there are
>  alternatives.

Hi Tony,

Lets step outside the box for a moment. Suppose we organize our
network by hostname instead of by network address? We don't want to
lose any of the hostname's functionality when we do this; the hostname
should still be a logical organization outside the scope of the
network location. So we aren't going to route by hostname; we'll still
have some sort of address under the hood. What would that imply for
the routing and addressing system?

Lets do two things to the network address:

1. Let's make it strictly ephemeral. It can change at any time, even
in the middle of communications. Only the hostname is sure to stay the
same.

2. Each machine gets multiple addresses, at least one for each
upstream. This means that the routers need to propagate addressing
information downwards so that each client picks up a reasonable set of
addresses.

Since these addresses are ephemeral and the machine is expected to
manage multiple addresses, they need only be carved from each
provider's PA space. What's more, direct allocations from the
authorities can be reserved for only those providers are have more
than a couple upstreams themselves. So, you get near the optimal
hierarchical aggregation of address space.

Now each of the top-level transit AS's needs an address block which it
has to propagate much like BGP does now, but when that address block
needs to expand it can automatically get a larger one from the
addressing authority and then expire and return the old smaller one.
Subsets of that address block propagate downward to anyone who isn't
big enough to have more than half a dozen upstreams or big peers. This
is a fully automated process. When more addresses are needed, the
request bubbles up, the new larger block is sent down and the prior
block is expired, all over the course of a few minutes. The same thing
happens between the top tier providers and the address authority.

The biggest challenge with this model is that routing largely becomes
a client-side responsibility. The two communicating endpoints have to
select and migrate between various currently-assigned addresses. This
will require some sort of formal routing policy language that can be
pushed down so that they know which routes their advised to use.

Stop.

The most critical problem with all this is that we'd have to rip out
and replace the guts of the Internet to attempt it. Like with IPv6,
this system would have to operate dual-stack for a decade. Like with
IPv6 there would be billions of dollars of extra cost with little or
no benefit until deployment was ubiquitous enough that we could start
withdrawing the current IP system from use.

If you have a notion for an out-of-the-box approach that doesn't
suffer from this problem, I'm all ears. I note that we just went
through a decade's worth of research on IPv6 and didn't find one. For
better or for worse, IPv4 bounds the box we're stuck with.


>  Even within the routing area, I don't believe that we've fully
>  explored the solution space in either the mapping area or in the
>  actual relaying mechanism.
>
>  On the relaying front today, we have encapsulation and translation.
>  What else is there?

Good question. We've known about encapsulation and translation in the
IP world for at least 15 years now in various applications like GRE
and NAT. There's not a lot of mystery about how they work or what the
pitfalls are.

There are also various incarnations of loose source routing which
we've discussed.

Is there anything else? Do you have an inkling what it might look
like? I'd hate for history to look back and say we suffered a failure
of imagination but it's also possible that there isn't a fourth avenue
to explore that's achievable from where we are today.


>  On the mapping area, we have push systems and pull systems.  Both
>  have substantial drawbacks.  Are there better hybrids?  Are there
>  alternatives?

Better hybrids is an engineering question. Ain't nothin' but a theory
until we build a few prototypes and try them out.

Alternatives? Information theory has some useful things to say about
information flow but the last I heard there are really only five ways
to get information:

1. You're told (unsolicited).
2. You seek and find out (solicited).
3. You're born with it (instinctual).
4. You extrapolate it from information you already have (deduction).
5. Divine inspiration.

Push and pull correspond to the first two. If someone has a lead on
routing protocols that work using the last three, I'm all ears.

Perhaps the Angelic Routing Protocol where at each router the packet
briefly stops and prays for guidance. Loss only occurs when packets of
insufficient faith are tempted down the wrong path. Verily I tell
thee, all DFZ scalability problems can be solved with with ARP.

Regards,
Bill Herrin


-- 
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
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