[RRG] Portability between mapping providers

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

Short version:   Maybe it can be done in the future, or before
                 Ivip or similar is implemented, but I am not
                 planning for an end-user network which leases some
                 space in a MAB (Mapped Address Block) to keep that
                 space and lease it from someone else.

                 However, each MAB itself could be handled directly
                 or indirectly by any one of the multiple competing
                 RUAS companies.  So a MAB is completely portable
                 with no RUAS lock-in.


In http://psg.com/lists/rrg/2008/msg02347.html Tony wrote:

> Again, I'm less concerned about the technical side of things than
> I am about vendor lock vs. the cost of renumbering.  It would seem
> that to prevent vendor lock, there must be a broad market of
> mapping providers.  And to avoid renumbering the identifier prefix
> must be portable across those mapping providers.

In Ivip, mapping of each MAB (Mapped Address Block) is done by a
single RUAS (Root Update Authorisation Server) company.  That
company pumps out one or more packets containing updates for that
MAB, or for other MABs as well, into the Launch Server system, which
fans it out to the Replicators which take those packets to all full
database query servers - QSDs - (and any full database ITRs) all
across the world.

There are technical reasons why the mapping of a MAB must be the
responsibility of one organisation.  Firstly, that one organisation
holds the master copy of the mapping data for that MAB, and it puts
out regular checksums, along with mapping updates, so QSDs can check
their copy of the MAB's mapping is correct.  If not, they download a
snapshot (from that organisation's servers) and patch it with
updates sent since the time of that snapshot.

A MAB could be moved from one RUAS to another, but it really needs
to be administered as a single thing by one RUAS or another.  Of
course, some other organisation could control the mapping for a MAB,
and simply send the snapshots and updates to the RUAS, who would
send it with mapping from other MABs into the Launch Server system.

There shouldn't be too many RUASes - probably no more than a few
dozen at most - since more would be hard to coordinate with the
Launch Servers.  The Launch Servers are run collectively by the
RUASes as a distributed, redundant, highly reliable, system.  The
Launch Servers collectively decide which updates each second every
Launch Server as got, so they can all launch the same data.  There
is more work to do on this, but the outline of it is in:

  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-01

There may well be a better way of fast pushing the mapping updates
to the world's QSDs, but this is the way I am planning it at present.

So there is portability of an entire MAB between RUASes.

Generally, each MAB is run by some company which rents out its space
to multiple end-user networks (but see my next message for a
university or corporation running its own MAB just for itself) -
maybe ten thousand or millions of smaller end-user networks each
with their own space in the single MAB.  Each MAB is advertised in
BGP by the OITRDs which support that MAB, and those OITRDs are run
and paid for directly or indirectly by the company who "owns" the
MAB and who leases out the space.  Revenue for running the OITRDs
comes from monitoring traffic on the OITRDs and charging the
end-user networks for their share of it.

What Ivip does not provide is a way an end-user network with some
space in MAB A can keep their addresses but lease this space from
some company other than the one which "owns" or at least runs MAB A.

I can't see a realistic way of providing such portability.  It would
be nice to have, but I think it would become overly complex and fragile.

There will be quite a few years before any of this has to be set in
stone, so there will be plenty of time to figure out if it can be
made more flexible, but my current plan is that when an end-user
network decides to lease some space in MAB A, from some company
which "owns" or runs MAB A, it checks out the reputation of that
company, because unless the company is sold to someone else, or
unless it sells the MAB to some other company, the end-user is going
to be paying that company, and depending on it to get mapping
updates out to the world, for as long as it has these addresses.

This is nowhere near as bad as depending on a particular ISP,
because it doesn't matter much or at all where the MAB company is
located, and the really expensive thing - connectivity - can be
purchased at any ISP with an ETR.

To completely abstract and generalise the routing and addressing
system so it is scalable and so no-one is tied to anyone else does
not seem to me a realistic goal at this stage of development.

Maybe it could be done, but at what cost in complexity and therefore
interdependence on multiple company's operations?  For instance,
right now, in Australia we can take our cell-phone and POTS numbers
from one mobile carrier to another, but it is a fudge and the whole
thing depends on a fragile arrangement of the original mobile or
POTS carrier which has that number range, and some central database,
technical arrangements with other companies etc.  Technically, we
still depend on the original company, but commercially, we can
ignore them and pay someone else for the cellphone service.

But everyone pays a higher price - including those who never move
their number to another carrier - because all the companies have to
do a lot of work to make this so-called number portability happen.
(The purpose is to aid competition, and that wouldn't work if only
the people to moved their number had to pay . . . so everyone has to
pay to enable competition, and the few who move can do so for free.
 Hopefully the whole competition thing brings down prices for everyone.)

  - 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