[168564] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: FW: Updated ARIN allocation information

daemon@ATHENA.MIT.EDU (Mark Tinka)
Thu Jan 30 02:29:06 2014

From: Mark Tinka <mark.tinka@seacom.mu>
To: nanog@nanog.org
Date: Thu, 30 Jan 2014 09:28:22 +0200
In-Reply-To: <20140130051711.986ACE0C64B@rock.dv.isc.org>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

--nextPart2209089.vY3bQtnSF1
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Thursday, January 30, 2014 07:17:11 AM Mark Andrews=20
wrote:

> Or you could just accept that there needs to be more
> routing slots as the number of businesses on the net
> increases.  I can see some interesting anti-cartel law
> suits happening if ISP's refuse to accept /28's from
> this block.

I understand the reasoning behind RIR's (and the community=20
that supports them) not caring about routability, but if=20
there is a lesson we can learn from IPv4, it is that perhaps=20
that divorce is not entirely practical.

It might be a good idea to think about how RIR's (and the=20
community that supports them) "could care" about=20
routability, so we don't end up in the same situation with=20
IPv6, whenever that will be, or if any of us will be alive.=20
It's definitely too late to do anything about it for IPv4,=20
which means there will be even more lessons to learn in the=20
coming months/years...

I know it is a moving target (advances in FIB memory is not=20
something an RIR [and the community that supports them] can=20
depend on, for example), but I also don't think it makes=20
complete sense for the RIR's (and the community that=20
supports them) to be in a utopia about this - that it will=20
all "just sort itself out".

Mark.

--nextPart2209089.vY3bQtnSF1
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAABAgAGBQJS6f8WAAoJEGcZuYTeKm+GcYYP/3YN1n/AiaQzE0pSEo5Hn68M
IuY+9mKG961SSHVo4EwO71VLd8CRRu8DtOD404zs89jIe2EdaHMlRP+rM9CUxUSc
tPOmszHZrHLdyKcslxqOjfJyhZKKud1qJnEzReIR/ItRvqiDehACvyVSbn6xAZCU
BpPgl0oDNuZyLzA+MWzzeX0TKkYKyZcfp94qfPdadUDriag9m3oSWAtJe23e4/GG
ZSxaovquroAHKY8Q8ZOcgFueoxs5+/9fK+NUAnQM6a1QYAQp1Al18S01lfOi/leS
Hc5PZhrGVS4tawEFV0EiM9tByJAlfLV/9CntjP0oTJ7OEv1kaM316/c7IWl0E6IQ
6mUb5jws6CbZM8zS1XaSACBISy+FIk4Id3btcB5SN1WBuS3nKPitu/oleHGAF2lu
NKFcLLi4/4P+l8YH8QMruNWtB7ZLqwZqIeqd3C+HaNrT7DdaRuy564naIQvzzYoh
x/DUpdG3pBHKxXhYzpmxV0qlYdM7/5VRZ9BsK+OB27UhJ6JJ+XL6VaoRQdfjSMpJ
wjaX9QT8nrlGMbxye9Vs0zB4T/gndXOosKAeuX6C5o7RX0klL4klkczbd5SQBFv8
mGavEfLSIdx680Zg7pQGKi/jVQBu8U/ZfPe5O8BZCHgcZZeGFsH+p6ErWzLmh1bH
SZuXjgvL3hgUBHWwFJx8
=7QoN
-----END PGP SIGNATURE-----

--nextPart2209089.vY3bQtnSF1--


home help back first fref pref prev next nref lref last post