Re: [RRG] Renumbering...

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

Short version:  Existing end-user networks on PA space would
                renumber once to get Ivip SPI (Scalable PI) space
                they rent from another organisation.

                End-user networks on PI space could do the same -
                relinquishing their current PI space - which would
                also be a single renumbering event.

                End-user networks with PI space could also keep
                their current prefix and convert it to Ivip
                management.  This involves no renumbering and
                enables them to split the space into as many
                micronets as they like, while their prefix is
                still a single BGP advertise prefix.  So this
                approach also generally routing scaling benefits.

                Once using SPI space, there is no need for
                renumbering.  Moving to a new ISP etc. including
                using a second ISP's ETR because the first ISP's
                ETR is dead or unusable, involves no renumbering
                - just a change in the mapping of one or more
                micronets.


Hi Tony,

You wrote:

> To clarify the issue at hand: we're interested in renumbering of end-user
> sites and changes in the locator namespace.

The idea with Ivip is that large blocks of address space would be
managed by Ivip, with each able to serve the needs of a large number
of end-user networks.

For instance, some ISP, RIR or any other organisation has a /12
(this is an IPv4 example) and makes it into a "Mapped Address Block"
(MAB).  That is a single BGP advertisement, so that all packets
addressed to any end-user network address in this prefix will be
forwarded to the nearest OITRD (Open ITR in the DFZ).

Then this /12 of a million IP addresses can be split up into as many
micronets as are needed to serve the needs of hundreds, thousands or
tens of thousands of end-user networks with the new kind of space:
Ivip-managed micronets of "Scalable PI" (SPI) space.

Some end-user networks will only want a single micronet of 1 IP
address.  Others will want two or more micronets, and each might be
of 2 or more IP addresses.

Each such end-user network would be renting the space from the
company who has the MAB.  Each such end-user network would probably
also be paying for their share of the load on the MAB company's
OITRDs. More on this at:

  Ivip business models: fast push & OITRDs
  http://psg.com/lists/rrg/2008/msg01158.html  2008-04-15

If these end-user networks already have PI space, then they could
give that space up and move to the new space in this MAB.  So that
is a single renumbering event.  After that, they can chose to use
ETRs in one, two or as many as they like, ISPs which provide ETRs.

The SPI space they hire becomes their permanent (as long as they pay
the rent) identifier space for their network.  They can split it
into as many micronets as they like.

If the end-user network is currently on PA space, then this will be
a single renumbering event too - but they already had to renumber
every time they chose a different ISP anyway.

If the end-user network first comes into existence using the new
kind of space, then there is no renumbering.

I think this is the most important class of end-user.

Since we are supposed to be making a system which scales to 10s of
millions of end-user networks (or 100M  or 1B or more?) and since
there are only probably 100k or less such end-user networks, it
follows that the question of existing networks converting to the new
kind of address space is only part of the whole long-term story.


With Ivip, it will also be possible for an existing PA end-user
network to convert their prefix to Ivip management: to turn it into
a MAB so it can all become SPI space.  This would involve no
renumbering.

The end-user network would need to pay an RUAS (Root User
Authorisation Server) company to carry the mapping information for
their MAB to all the world's ITRs.  The end-user network would
either need to run their own OITRDs, or pay someone to do it -
perhaps the same RUAS company.


If the end-user network in question at present has their prefix as a
single advertisement in BGP, then there is no overall benefit to the
scaling problem by them turning the prefix over to Ivip management.

However, if they are, or were going to, split their PI prefix into
longer prefixes for any reason, such as to use the longer prefixes
for two separate sites, for splitting load over two ISPs etc. then
there are routing scaling benefits in having converted the whole
prefix into a single MAB and doing the splitting with the Ivip
mapping system, rather than with additional BGP advertised prefixes.

Once the prefix is a MAB, the end-user network can split it into as
many micronets as they like.  They can also rent out some of that
space to other end-user networks.


Later, as more and more space is converted to MABs, they would start
to adjoin each other in the address space.

So if four end-user networks, currently all with PA /16 prefixes,
were all together in a /14, and if they had all converted their
prefixes individually to MABs, then they could coalesce the four
MABs into a single one.  This would reduce the burden on the BGP
routing system from 4 to 1 advertisement.  They would need to make
joint arrangements regarding a single RUAS and a single OITRD system.

So an existing PI end-user network could benefit from Ivip in two
ways:

  Firstly by converting their current space to a MAB - no
  renumbering.

  Secondly by relinquishing their PI prefix and adopting space they
  rent from some company - one renumbering event.  This is likely to
  be cheaper than either keeping the PI prefix as is, or by keeping
  it but converting it to a MAB.

The latter approach has direct scalability benefits.

The former approach would have direct scalability benefits except
for the unusual case where the end-user network was never going to
split their prefix.

Once an end-user network is using SPI address space, changing to
another ISP simply involves changing the mapping of their one or
more prefixes to a different ETR address - which does not burden the
BGP system at all.  That is changing the locator - not the
"identifier" addresses, which is what are used by the hosts in their
network and by all other hosts.

  - 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