[RRG] Large companies with PI, small with map-encap space?

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

Short version:

   I think we should ensure the new map-encap address space will not
   viewed a second rate by most end-users.  Then we won't have
   much trouble having it widely adopted, since it will generally
   be more flexible, cheaper and much more available than PI space.

   If the new kind of space is perceived to be second-rate, but
   we say "Its not that bad, the larger companies don't use it
   and many customers have their services provided by computers
   run at these larger companies", then we impose a two-tier
   system which places smaller companies, (who we want to use
   the map-encap space) at a disadvantage.


In "Re: [RRG] Why delaying initial packets matters" Kevin Loch wrote
a bunch of stuff which I tend to agree with, to the extent that:

Today's big hosting companies have their own AS numbers, PI space
etc.  so there's probably no reason they would migrate this space to
the map-encap system, or switch over to some other space which was
managed by the map-encap system.

As far as this goes, then it wouldn't matter if the map-encap scheme
produced second-rate delay or reliability results, because all these
companies wouldn't be affected, and the end-users who are the
customers of these larger companies likewise wouldn't be affected by
 the limitations of the map-encap scheme.


I am pretty sure this doesn't apply to small hosting companies.  By
small, I mean someone who rents a bunch of servers from a big
dedicated server company and sublets space on them for individuals
and small companies who want a web site, mail server etc.

Each such small company gets a set of IP addresses from the big
company, and can't easily use the servers somewhere else, due in
part to the disruption which would affect all their customers when
changing over to servers with different IP addresses.

These small web hosting companies may seem insignificant, but I
think a large number of websites are hosted on them - because they
are cheap.  (They may have lousy reliability - putting their two
name servers on the same network, or the same machine - and be
unprofessional, but really big hosting companies are not necessarily
very responsive or able to help ordinary folks who want to run a
website.)

Also, I think these small hosting companies form a part of the food
chain which makes up a significant proportion of the customers of
the larger hosting (dedicated server) companies.


More generally, assuming the map-encap type of address space is
widely perceived as being second-rate, due to delay of initial
packets sent to that address or for some other reason:

1 - If all companies which provide some kind of hosting service
    to end-users in general (not just end-users who want a
    multihomed network) are of a sufficient size to have ordinary
    PI space, then it doesn't matter if the map-encap scheme
    delays initial packets.

However, this would require:

2 - That the number of such large companies is sufficiently small
    not to cause the bloat in the number of BGP advertised
    prefixes we are trying to prevent.

and

3 - That it is OK to put smaller versions of such companies at
    a disadvantage, due to the smaller ones being expected to
    use map-encap space.

and

4 - Similarly, that it would be OK to expect these smaller companies
    when they grow to be "big" and want space with no delay of
    initial packets, to have to renumber and get an AS number,
    and their own slab of PI space.  (An EID in LISP or a micronet
    in Ivip will be part of a larger block of addresses which are
    advertised as a prefix in BGP and all handled by the map-encap
    scheme - so there's no way of making those addresses into PI
    space outside the map-encap scheme).


In summary, assuming we expect all small end-users who need address
space to use the map-encap space and assuming the map-encap space is
perceived as being second rate in terms of delay, reliability etc.
then if we say:

   End user companies of type X are generally big enough and
   few enough in number that either:

     1 - They already have PI space (and we think it is OK for
         them to keep it forever)

   or

     2 - That in the future, companies which attain such a size
         will abandon map-encap space and adopt different PI
         space

then I think we would be imposing a two-tier system which puts small
companies at a disadvantage.  This includes companies who start
small and grow larger, but have to either stick with their existing
    map-encap space or make the expensive, disruptive, jump to
conventional PI space, if they want to have address space with the
same low delay and high reliability etc. as their established larger
competitors.

I don't think we can expect this.

If the new address space sucks, in terms of delay or reliability,
then smart end-users won't want it.  They will want to establish
themselves with some address space which will still suit them when
they grow immensely.

Yet we want pretty much all end-users including hosting companies
(at least those which are established in the future) - anyone who is
not selling connectivity - to be happy about adopting the new kind
of address space.

If we have to herd these people to adopt it, induce or force them,
then there will be a slow and partial adoption.

If we make the new type of address space have no significant
problems with delay, or reliability, then it will be relatively easy
to have most new end-users and some established larger end-users,
adopt it.

The new type of space will generally be cheaper than ordinary PI
space, because it can be sliced and diced into smaller pieces than
with BGP without placing any burden on the BGP "global routing
table".  It will be portable to any ISP which runs an ETR (and they
all will, before long).  Also, it can be subdivided into many
micronets by the one end-user, without much fuss or cost.

In addition, there may be advantages in terms of traffic engineering
in a lightweight but effective manner which are not available via
current BGP techniques.

 - 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