[RRG] Map-encap space only for small end-users? PI space prices

[Robin Whittle <rw@firstpr.com.au>]

Hi Bill,

In "Re: [RRG] Map-encap space for 'server' vs. 'client' end-users?",
you wrote:

>> If the entire Net changed to add some small delay, then this
>> would not be a barrier to adoption of the new map-encap scheme.
>> However, as I and others have written, if the new address space
>> performs worse, in a way which really matters to end-users or
>> which could be construed by marketing people as such, then it
>> will be very hard to get widespread adoption of the map-encap
>> scheme.
>
> Robin,
>
> In the unlikely event that marketing folk convince users that a
> slice of PA space is better than map-encap PI space, the RIB
> scalability problem is solved and our job is done. The reason
> we're having this discussion is that folks -aren't- satisfied
> with slices of PA space and have been impinging on the RIB in any
> way they can connive.

I was referring to an end user such as a hosting company having to
choose between conventional BGP-managed PI space and the new
map-encap space.  Marshall Eubanks makes the same argument:

  http://psg.com/lists/rrg/2008/msg00381.html

Conventional PA space is not part of the picture, since these are
end-users who need multihoming, probably portability and probably TE.


>> TRRP has a similar delay problem, which would occur frequently
>> enough to be significant.  The ITR has to sequentially query
>> and get responses from several DNS-like servers in order to
>> find the authoritative server with the mapping information.
>> Unless you anycast those intermediate servers (which does not
>> scale well) then there will be significant delays in quite a
>> few circumstances.
>
> Few if any of which will have a more meaningful impact than a DNS
>  query today. The users have spoken clearly on pull-style lookup
> delays. Given a choice between reference by name and reference by
> IP address, they have consistently favored convenience over the
> extra edge in speed.

> While none of us has collected direct data on this point, the
> circumstantial data is not the slightest bit ambiguous. According
> to users' behavior with the DNS, brief lookup delays solely at
> the front of a series of transactions are A-OK.

Sure, but if a new kind of address space involves a new kind of
delay, and you have the choice between this and the original kind of
address space which has no such delays, then it is going to be hard
to get many or most people to adopt the new kind.

  cf. the Eubanks Doctrine on technologies which have a failing
  which, while minor, can easily be trumped up by marketing
  folks to scare off most potential customers.


>> I argue that the new map-encap space must be equally attractive
>> to large and small end-users, including those with current
>> BGP-managed PI space:
>
> Nonsense. The map-encap scheme must be sufficiently attractive to
> a large enough subset of the user base that they're willing to
> pay for it to be deployed. No more and no less.

Yes, but if the address space gives slower performance, or is
perceived or widely portrayed as doing so, then it is going to be a
very hard sell.

I think that if the initial packet delay problem can be removed, or
made small enough that most folks will realise it really doesn't
matter, then any of the map-encap schemes would produce address
space which is more useful than current PI space, for end-users of
all sizes.

If, for some reason or other, the new space is genuinely less
suitable for "the big boys", then many smaller end-users who want
(or expect, no matter how foolishly) to be one of the "big-boys"
will insist on building their budding network good-ol 1950s style V8
BGP-managed address space, not the 70% plastic, electronic fuel
injected, high-revving, 4 cylinder map-encap address space which
really isn't going to last the long road trip they are embarking on.


> I argue that if you avoid schemes which disrupt "everybody else,"
>  you'll get much further with a map-encap scheme that
> well-accommodates a small subset of the users than you will with
> one that poorly accommodates a wide swath.

A map-encap scheme which is not encumbered by initial packet delays
or anything else - apart from the basic restrictions on its use such
as not to be used for ETRs - will be more attractive to many big
end-users than the ordinary PI space they already have.  They could
convert their space to be managed by the map-encap space, and then
slice and dice it far finer than they could with BGP, without
placing extra burdens on all the folks who run DFZ routers.

This does not forcibly disrupt anyone with conventional PI space.
It gives them an option to turn their whole prefix into a single BGP
advertisement, replacing their multiple longer prefixes with as many
EIDs as they like.


>>> I can tell you without reservation that one-size-fits-all
>>> never does.
>>
>> Ah yes, but many folks are establishing their nook in the Net
>> with the intention of growing enormously.  We need them to
>> adopt map-encap space - which means they need to be confident
>> it will still the best arrangement when they are bigger.
>
> No fundamental character of map-encap requires this. TRRP has no
> such requirement inherent in its architecture. It doesn't require
> wide adoption to begin delivering valuable results. Indeed, the
> theoretical deployment timeline shows it producing valuable
> results with only a handful of users.

It may make a handful of end-users happy if only a handful adopt it,
but that is not going to solve the routing scaling problem.

I think what we are trying to foist a solution to the routing
scaling problem onto as many current and future end-users as
possible, by ensuring the new kind of address space provides them
with direct benefits.

There won't be the desired impact on the routing scalability problem
if we only get half the end-users on map-encap space, because the
other half will be proliferating their pesky prefixes all over the
DFZ.  All that would achieve is haling the problem, when we really
need to knock it on the head to a much greater degree, like 90 to 95%.


>>> I would put it differently. Just 'cause I can't afford a
>>> Porsche doesn't mean I care to ride the bus. Bare BGP
>>> prefixes for those who cough up the cash. Map-encap for those
>>> who value it less but still want something that isn't as
>>> ghetto as slices of PA space.
>>
>> This might work to some extent, but not if the price of
>> BGP-managed PI space comes down.
>
> If the price of BGP-managed PI space comes down, the problem is
> solved and we can all go home.

This would be the case if the only goal was to provide multihomable
space to more end-users.

However, our task is to solve the routing scaling problem, which
means lower prices for conventional PI space would be disastrous,
due to the rapid growth in the number of BGP advertised prefixes.

I think we can create a map-encap scheme which solves the routing
scaling problem by providing a form of address space which is really
attractive to large and small end-users alike:

  Multihoming and TE without BGP

  Cheaper for this reason, and because it can be given out in
  small slices.

That would do the trick, but I think we can also make the new space
support a powerful new kind of mobility.

By doing this, we will also contribute to the better utilisation of
IPv4 address space, which most people think is a very good thing.


> The assumption we're working
> under, correct or not, is that fundamental limitations in the
> technology will cause the cost of BGP-managed prefixes to level
> off in a log-normal fashion at some price which is still too high
> for the kind of granular multihoming and mobility that you and I
> desire.

Yes, I think they will still be too high for large numbers of
end-users - but any reduction would mean more and more BGP
advertised prefixes in the DFZ: which is the problem we are trying
to solve.

 - Robin


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