Re: [RRG] Thoughts on the RRG/Routing Space Problem

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

Hi Jari,

I hadn't considered the cost of equipment.  I figure the ITRs are
paid for, in general, by the ISPs where they are located - tunneling
packets originating from the ISP's customers' hosts.

For an end-user who gains some of the new kind of address space
provided by the ITR-ETR (AKA map&encap) system, the ETR(s) their
traffic flows through would be owned and operated by the ISP(s)
which they connect to the net with.  ETRs are going to be pretty
simple compared to ITRs - they don't need an FIB, a database or a
feed of mapping data (or access to a query server, if they are
caching ITRs).

So the end-user doesn't need to purchase or run ITRs or ETRs in
order to use the new kind of address space.

Their network may well include ITRs - to ensure the tunneling work
on outgoing packets is done locally and doesn't depend on anything
upstream, which is shared by others.  But that would be the case
irrespective of whether the end-user's network uses the new kind of
address space.

It may well be that the new "micronet" type of address space doesn't
cause many of the recent (say 5 years) new end-user networks with PI
space to relinquish that space and use micronet space instead.

In addition to these, hundred thousand or so "large" end-users there
is surely a huge number (millions) of "smaller"  end-users who want,
arguably need, and are keen to pay for multihoming (and in many
cases portability of addresses in the long-term between ISPs) - but
who don't have the resources or sufficient "justification" to get PI
space today.  These end-users are unhappy and not able to use the
Net as reliably as they need.

Without the ITR-ETR scheme, these millions of smaller end-users
generally have to do without multihoming, because they can't afford
the entry costs, in terms of equipment (maybe), expertise (probably)
and effort required to get PI space and to responsibly participate
in the global BGP system.  The current rate of growth in the number
of advertised prefixes would continue - which is not what we want.

With a good ITR-ETR scheme, some of the current "larger" type of
end-users - those currently with PI space and those who would
otherwise get it - would switch over to the new scheme.

The major impact of the ITR-ETR scheme would be on the millions of
"smaller" end-users, who would jump into micronet spaces and (with
suitable economic incentives = costs) fine-tune the amount of
address space they use and the number of micronets and mapping
changes they make, so that the space is used efficiently and without
excessive burden on the ITR system.

The other thing is that, over time, as the number of PI prefixes and
the changes to their advertisements becomes more and more of a pain,
I think there is likely to be some kind of pressure to limit the
number of end-user networks who use this.

Now, the only way of doing this is to tell the end-user they can't
multihome.  But with a good ITR-ETR / map&encap scheme, they will
have a perfectly good alternative.

So I think there will be this additional form of pushback not long
after the ITR-ETR scheme is up and running.

As Tony wrote:

> If we have an architecture in which being multi-homed is no
> longer a sufficient justification for PI allocation, then we
> can further raise this bar.
>
> Effectively, we should be able to drastically limit or even
> eliminate PI allocations.  Yes, I'm talking about making
> fundamental changes to the allocation policies that we have today.
>
> We have to be taking the decision out of the hands of the
> organization and giving them a workable alternative.  If not, then
> everyone ...

Not "everyone" in terms of all the "small" end-users, but certainly
enough end-users of various generally moderate to large sizes.

> will simply continue to use PI addressing and the non-scalability
> of the 'net is assured.

Yes - the future of the Net depends on there being a good ITR-ETR /
map&encap scheme ASAP.  I think the timetable for the RRG is
realistic - not too fast, but we to devise something which can be
deployed around 2011 and widely adopted by 2013.

I think that there won't be much trouble with ISPs providing ETRs.
They shouldn't cost much - they will probably be implemented as
software updates to existing routers.  A software only system for
standard Intel etc. PC-like servers would probably work well in some
settings, assuming it could be robust enough.

I think ITRs are going to be quite tricky. There could be software
updates for existing routers, and some low to moderate volume
software only systems which run on standard servers - and sit next
to a currently installed router, advertising the prefix on IGP or BGP.

Then there is the global query or push network - which is where the
various ITR-ETR schemes differ the most.  This will be challenging too.

As long as there is a reasonably wide distribution of ITRs, enough
to handle the traffic without too much stretch of the path lengths,
then I think ETRs will be installed at many ISPs and the new
micronet style of address space will be rapidly adopted.  Initially
most of it would go to the pent-up demand of the many "small"
end-users who currently can't play the "RIR PI BGP justify /24 or
more" game.

Those who manage the MABs will presumably rent out the space as UABs
(User Address Blocks) to end-users, charging according to the number
of addresses in each UAB, the number of micronets the end-user
configures this space into and the rate of mapping updates.

I figure such MAB operators will probably be able to make money
while financing their own global network of ITRs or participating in
a shared, global system.  Alternatively, they would pay one or more
other ITR operating organisations to run ITRs all over the Net,
catching packets from networks with no ITRs, so their address space
was useful and therefore highly rentable.


  - 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