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

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

On Thu, Feb 21, 2008 at 5:20 PM, Brian Dickson <briand@ca.afilias.info> wrote:
>  IMHO, the comparison that needs to be made, is PI vs "foo", for any new
>  thing "foo". Whether "foo" in some way makes use of PA infrastructure
>  is irrelevant, really.
>  It is only that we want to substantially limit the growth of PI space,
>  to those who cannot live without it.

Brian,

It will be hard for any solution we come up with to compare favorably
with $8k/yr worth of free service. That's what BGP PI amounts to.

On the other hand, there are lots of folk today who can't get PI and
want it. For them, our solution doesn't have to compare favorably with
BGP PI; it need only compare favorably with PA.

I make the modest claim that once a non-BGP solution to PI actually
exists, we'll find that the core operators' willingness to tolerate
giving away $8k/yr worth of free service quickly dries up... pushing
the bottom end of existing PI users into a situation where they too
must choose between map-encap PI or BGP PA.



>  DNS lookups will *block* most applications, until the DNS resolution
>  succeeds or fails.
>
>  And that has perception in user-space, but no impact to the underlying
>  protocols.
>
>  However, delays *within* the transport regime, are an entirely different
>  can of worms.
>
>  Unless the transport itself is modified to handle this, I think it's
>  best to see if we can avoid this.
>  I think it is a non-negligible issue.

If I correctly understand your criticism, it's that an ongoing
transport mustn't pause for an expired DNS TTL. I agree and this is
addressed in the TRRP document's section on ITRs.


>  The problem is a spam-like asymmetry.
>
>  The problem with spam is, one party pays (the ISP delivering mail, and
>  the end user ultimately) for the benefit of another party (the spammer).

That is a remarkably insightful description of BGP PI as it exists today.



>  You've lost me. Without an ITR (or equivalent host stack modifications),
>  how do I connect to an EID host?
>
>  And if I'm the server operator, why would I do this (switch to EIDs)
>  unless *everyone* has the same quality of connectivity
>  reaching me?
>
>  The benefit for deployment needs to be universal, and absolute, not gradual.

TRRP's theoretical deployment description starts with two to three
ITRs at one service provider. These ITRs get fed by something along
the lines of a /16 anycast-announced into the existing BGP system.
Folks who can't have PI space now, either they're too small or their
incumbent monopoly telco won't announce their prefix, folks who only
need it for a handful of servers, get /28's and /29's off this ITR.
Their end is simple: a couple DNS entries and a GRE interface on their
Cisco router or Linux server.

If there is no market for this, TRRP dies. But if there is a market,
it grows and a couple other companies sell a similar tunnel service.
Then you get a couple companies who decide that by feeding those
routes into their own ITRs rather than following BGP to someone else's
ITRs they can get a slight edge on their competition.

It grows bit by bit, running as a useful addition to the current BGP
system until, at some point, one of the large backbone providers
decides it's time to stop giving free FIB slots to the /24's. They put
out the word: if you're announcing a /24, implement a TRRP DNS entry
and a GRE ETR or you're off our section of the 'net. These being
ridiculously cheap things to implement (and /24 announcers having a
pretty good idea of the sufferance on which they survive), the
provider doesn't get a lot of pushback.

That provider realizes a cost savings in his router upgrade cycle, an
effect not lost on his competitors.

The long version is at
http://bill.herrin.us/network/trrp-implementation.html . If you have
comments along the lines of, "Where did X come from that you first
mentioned here," or "What advantage does this individual get from
doing the action you state there?" I'd like to hear them. If there is
any step which doesn't represent a realistic possibility given the
ones before then I need to do more work on it.


>  This is a "commons" situation, with our goal being to avert tragedy.
>
>  It is one place where market economies will not do anything to help us,
>  and in fact are likely
>  to be something we need to be keenly aware of - doing good often flies
>  in the face of market pressures.

Counterpoint: The routing table is only a commons because we choose to
treat it so. It's well within our power to assess the cost of a BGP PI
prefix, create a payment clearinghouse and create software tools which
allow folks to automatically filter prefixes from those who don't pay.
Such an approach requires no changes to the routing architecture at
all and it handily solves the RIB/FIB size problem.

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