[RRG] Re: Map-encap space for "server" vs. "client" end-users?

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

On Feb 15, 2008 10:18 PM, Robin Whittle <rw@firstpr.com.au> wrote:
> I am not sure what you mean by "hybrid", but I think you mean some
> end-users are better off with the current BGP-managed approach to PI
> space while others are better off, or will be encouraged/forced to
> use map-encap space.

Hi Robin,

By hybrid, I mean a system where the shorter, typically PA prefixes
continue to be routed via BGP as they are today while the longer,
frequently PI or TE prefixes are shifted to map-n-encap as driven by
the system's economics.


> I am sure there are many end-users, large and small, who want
> stable, portable, multihomable address space to run both servers and
> client hosts on.  So trying to decide which end-users are "server"
> end-users and which are "clients" would be difficult or impossible.

That's exactly my point: the choice should (and ultimately will) be
made by the folks purchasing Internet service. Our job shouldn't be
trying to figure out what they should or must do; it should be giving
them as many quality parallel options as we reasonably can so that
they can select the best fit.


> For web servers, game servers etc. having a bunch of
> these, especially for a bunch of customers, would be extremely
> disruptive and expensive for the end user - the hosting or
> self-managed server company - and their customer end-users.

I disagree and I'll tell you why: given the option to reference
subservers by DNS name or by IP address, web site designers have
overwhelmingly chosen to reference them by name and accept the extra
lookup delay. This is the preference that the operations folk have
clearly demonstrated to us with their actions - that on initial access
to a server, a mild lookup delay is acceptable for the sake of
convenience.


> I assume that by "Fast space" you mean the map-encap type of space.

The opposite. "Fast" space is highly aggregated PA space which runs as
bare IP over the backbone without going through a man-n-encap scheme
and thus suffering no lookup delays or slow initial pathing.


> I think most existing and
> new "server hosting" companies would avoid the new system like the
> plague.  Competitors with the original, authentic, good-ol-days RLOC
> space would be pointing out the superior responsiveness of their
> servers compared to the slower nature of the new-fangled plastic
> map-encap space.

What's wrong with that? If you're placing a /18 on the 'net, we can
easily accommodate you with the hardware that's already deployed, let
alone with hardware currently shipping.

I'm more interested in the guy who has 5 servers he wants to put on
the 'net and he never wants to have to deal with renumbering.
Map-n-encap would give him an option he doesn't have today, an option
he wants to have. That's where the initial market for map-n-encap is:
PI space for guys that are otherwise too small to have it.

Once map-n-encap exists, the definition of "too small" grows until it
correctly balances with the needs of the folks operating the DFZ.


>   TRRP       http://bill.herrin.us/network/trrp.html
>              Pull via a DNS-like global distributed query server
>              network.  Instead of ALT's circuitous path problem,
>              TRRP has more direct paths to the query servers - but
>              a similar delay problem arises due to the likely need
>              for multiple recursive queries to find the
>              authoritative query server.

I think ALT is actually pretty clever. Following that idea, its
possible to create a mechanism in TRRP to route initial packets while
waiting for the lookup to complete. That could strongly mitigate that
lookup delay. Unfinished work (read at your own risk) here:
http://bill.herrin.us/network/trrp-aapip.html

Another interesting point, which didn't make it to in the unfinished
document, is that this alternate initial route rather lends itself to
an accompanying classic BGP route which greatly eases the transition
from the current BGP-only system to a hybrid BGP+map-n-encap system.

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