[ppml] RIR Shopping, Table Growth x5?

[Jeroen Massar]

Leo Bicknell wrote:
[..]
> If you're a global company though, it would seem the current policies
> in all of the regions lead us down a path to 5 prefixes per ASN.
> That is, each company would get a prefix from each RIR.

The problem with having 1 prefix globally is that you might get the
following scenario (not an issue if you have great connectivity
worldwide of course like most transit providers hopefully have*):

Big Office in Beijing, 10GE
Small Office in New York, 100mbit
Small Office in Amsterdam, 100mbit

Now actually most of your clients (lets say you made the new cool
YouTube incarnation and doing loads of traffic) are in the US and
Europe, but your actual hardware is mostly in Beijing.

This will result you into having to either:
 - announce your /32 in all three locations
   => and thus having to backhaul all that traffic to Beijing
      yourself which might just clog up your 100mbit link and
      the 10GE is never used
      ('locally announcing BGP' might help a wee bit)

 - announcing the /32 only in Beijing
   => Having to backhaul 200mbit, with extra latency.

 - splitting the /32 into a /33 (Beijing) and two /34's (NY+Ams)
   => avoiding the above problems totally

As the first situation is totally undesired, you will end up in having 3
prefixes for this company anyway. As such, if that company decided to
justify a /48 from ARIN for NY, a /48 from RIPE for Ams and a /40 for
Beijing it has exactly the same effect, except that the prefixes are
separate and they have to configure 3 lines in their firewall instead of
one global well defined prefix.

> The question is, with IPv6 is this a good thing?  That's a very
> loaded question of course, and the answer may depend a bit on the
> structure of the company (single global ASN, multiple ASN's, single
> corporate structure, multiple affiliates) and has implications on
> mergers and divestitures down the road.

The real answer probably lies in a solution like id/loc or shim6 etc.
Having ISP's with PA prefixes in the core and having the 'more
specifics' and 'PI prefixes' using such a mechanism that doesn't fill up
the DFZ. By keeping separate blocks for PI prefixes and also special
sizes >/32 these can at one day in the future easily be weeded out.

> Should RIR's consider in more detail what has been allocated by other
> RIR's?  Is IPv6 different from IPv4 in that respect?

No, I don't think that has to be done. Though at the part where the
requester justifies the address space, they should only either justify
the requirements for address space in the requesting region, when going
for multiple prefixes, or globally/multi-region when doing that.

Greets,
 Jeroen

* = though, for instance (!random example grabbing!) UUNET/MCI has
already received about 8 /32's for different purposes globally. The
space is easily justified by them and each /32 only covers a country,
but I would not be surprised that they did this simply because of the
above described problem: keeping traffic local.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070627/711de717/attachment.sig>