[RRG] Renumbering once might be OK when converting to Scalable PI (SPI space)

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

Short version:  Technical and business plans for adopting the new
                kind of space provided by a core-edge separation
                system, such as a map-encap system.  I am calling
                this SPI (Scalable Provider Independent) space.


                Current PA users will need to renumber once, but it
                will be the last time - and with conventional PA
                space, they needed to renumber any time they wanted
                to change ISP.

                Some (generally smaller) PI users will relinquish
                their PI space, renumber once and adopt different
                SPI space - probably less space than they got from
                an RIR to be a conventional PI end-user network.

                The remaining (generally larger) PI users which
                adopt SPI space can do so by converting their
                current PI space into SPI space as an entire
                Ivip-mapped MAB (Mapped Address Block). They don't
                have to renumber.

                They get the SPI benefits, need to pay an RUAS
                company to handle their mapping and they need
                to run OITRDs for their MAB - or have someone
                else run them.  However, for many such larger
                PI users who are based in a single country,
                it will be relatively easy for them to run their
                own OITRDs.

               (Most SPI end-user networks in the long-term
                future won't need to renumber, because they
                will be established for the first time on SPI
                space.)


Networks currently on PA space will obviously need to renumber once
when adopting SPI space - but that is not a serious impediment to
their adopting it, since they have to renumber anyway if they change
to another ISP.  Changing over to some SPI space and being able to
slice it up into as many micronets as they like - and then being
free to choose any ISP which has an ETR for each micronet . . . it
is pretty good deal, and I don't think they would mind renumbering
for the last time like this.

I think there are two approaches by which existing end-user networks
with PI space could adopt SPI space.

One is to give up their BGP-advertised PI prefix, get whatever SPI
space they need and renumber just once to that SPI space.  The
benefits include:

  1 - They don't need to pay for PI prefixes.  SPI space will be
      generally cheaper.

  2 - They don't need BGP expertise or BGP routers any more.

  3 - They can get whatever amount of space they need with SPI
      space, which will often be less than the minimum they got as
      PI space from an RIR - so again the ongoing costs will
      generally be less.

  4 - They can easily get more SPI space.  It won't be contiguous,
      but it will be space.  Networks are going to have to get used
      to running with more smaller chunks of disparate space - it is
      impossible with IPv4 at least to give everyone a big slab of
      space in case they need it one day.

  5 - Perhaps most importantly, they can slice their space into as
      many micronets as there are IPv4 addresses, or IPv6 /64s.
      Then they can map each micronet however they like, to any ETR,
      in any country, or some mix of local ISP's ETRs to load
      balance their links to these ISPs.  There is no /24
      granularity restriction as there is with conventional
      BGP-managed PI space.  This means that if they have 32
      IPv4 addresses and want to run 32 offices in 32 cities,
      they can do this, with each office on a single, potentially
      multihomed, IPv4 address.  (Or /64 for IPv6.)


However, they do need to renumber once, and they have ongoing costs
directly or indirectly involving:

  1 - To the MAB (Mapped Address Block) company who leases them a
      portion of a MAB - rent for the space.

  2 - The MAB company either is an RUAS (Root Update Authorisation
      Server) company or it pays a RUAS company to put the mapping
      updates into the global mapping system.  There will be some
      small charge per update, probably with a simple billing system
      of a flat rate for less than X per month.  Without fees per
      updates, some end-users could change their mapping every
      few seconds, without properly contributing to the RUAS costs
      via their MAB company.

  3 - The MAB company either runs its own OITRDs (Open ITRs in the
      DFZ) or pays some other company to do so.  Again, the
      end-users need to pay their MAB company in proportion to
      the traffic on those OITRDs for each end-user network.

This obviously aids scalability.  The end-user gave up a PI prefix
it may have advertised as one, two or more separate prefixes and
instead uses just part of a MAB, which has a single advertisement in
the DFZ.


Here is the other approach, which would probably suit larger PI
users, such as universities, corporations etc.  No renumbering is
required, and they are still getting SPI space and in general aiding
scalability.

If the large PI user only currently advertises their space as a
single whole prefix AND if they were going to do this into the
indefinite future anyway, then this approach does not aid
scalability.  Nor does it hurt scalability.

In this case the end-user retains their PI prefix, but makes it a
MAB under Ivip.  This means a number of things:

  1 - They still need to pay an RIR for their PI prefix.

  2 - They still need some BGP expertise, although they won't
      be running a BGP router themselves (except as noted below for
      OITRDs).

  3 - They can always add to the space they have with SPI space from
      a MAB company.

  4 - They could also rent out some of their MAB to other end-users.
      However, this would means they needed to take on some
      customer-facing  responsibilities different from their
      ordinary line of business.  A university or a corporation
      probably has better things to be doing than renting out
      address space.

      If they find they have more space than they need once it is
      SPI space (which may well be the case, since it can so easily
      be divided into small pieces and mapped to any ETR in the
      world), then they might consider doing the Right Thing (IPv4
      space is assumed here) and renumbering part of their network
      into the lower half of their prefix so they can return the
      upper half to the RIR.

      Relinquishing some of their currently assigned space may well
      save them money.  It should, because the IPv4 space is worth
      a lot to other potential end-users, including indirectly via
      a company which wants lots of space to turn into MABs so it
      can lease the space out as SPI space.

  5 - Perhaps most importantly, they can slice their space into as
      many micronets as there are IPv4 addresses, or IPv6 /64s.
      See point 5 above.

  6 - They now need to pay an RUAS company directly, or through
      some intermediary, to get the mapping for their MAB out to
      the QSDs and ITRDs of the world.  This would involve having
      the contracted company handle all the updates from each
      end-user within the end-user's network.  So a university would
      contract some company to run this system, taking update
      commands from assigned people in its various departments (each
      with its own micronets) or from the multihoming monitoring
      companies who have been given the authority to change the
      mapping of these micronets.

  7 - The end-user now needs to run their own OITRDs or pay some
      other company to do so.  That company will charge according
      to how many OITRDs there need to be, where they are located
      and what volume of data flows through them for this end user
      network.  But see notes below on how this could be simpler
      than it seems.


Previously, I assumed OITRDs would be all over the world.  If the
ETRs for the micronets in a MAB are all over the world, and the
hosts in non-upgraded networks which are sending packets to these
micronets are also all over the world, then the OITRDs need to be
all over the world too.

But let's say a university in Melbourne decided to take this path of
converting its current PI prefix into a MAB.  All its sites are in
Australia.  Most of them are in the state of Victoria, but there
will be a few outrigger sites for research stations or offices in
other states.

The hosts in upgraded networks will be all over the world, but all
the ETRs will be in Australia.  So it would suffice to run a few
OITRDs around Australia in order to ensure generally optimal path
lengths.   This is a lot easier than trying to run OITRDs all over
the world.  Probably some open source code on a few COTS servers
sitting in data centres would do the trick.

Each department or branch could multihome via two or more local
ISPs, and freely change those ISPs according to local conditions -
only needing to change the mapping of their micronet.

So this is a way of moving to SPI space for the larger current PI
end-user networks, without renumbering.  Assuming the organisation
was already splitting their prefix into multiple advertisements, or
was going to, it is a net gain for scalability since their entire
prefix is now advertised as a single MAB.

Meanwhile, they can get generally cheaper connectivity to outlying
places, by not needing to install or lease fibre links, radio links
or whatever, but simply using one or more likely two local ISPs.
(This does not work so well for large volumes of data flowing
between the sites - since it has to go through local ISPs and the
inter domain routing system.)

In the long-term future, as more and more prefixes become MABs, it
will be possible to amalgamate adjacent prefixes into a single MAB.
 The assignees of these prefixes will need to agree on a single
company to handle the mapping for the entire MAB, and to run OITRDs
for them as well.  However, there could be a handy little business
doing just that, and it would relieve the end-user networks of some
stuff which is not their core business activity.


 - 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