[76003] in North American Network Operators' Group
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Nov 29 16:02:41 2004
Date: Mon, 29 Nov 2004 13:00:27 -0800
From: Owen DeLong <owen@delong.com>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Jeroen Massar <jeroen@unfix.org>, Cliff Albert <cliff@oisec.net>,
nanog@merit.edu
In-Reply-To: <Pine.LNX.4.61.0411292137100.13367@netcore.fi>
Errors-To: owner-nanog-outgoing@merit.edu
--==========B806C24CE33E16FE4EBB==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
> Of course, every ASN would not be active. But if we'd have 32 bit ASNs,
> there would be "no need" (or so folks would argue) to be strict in the
> policies -- everyone and their uncle could have one. Folks could even
> get ones for their homes, theis SOHO deployments, or their 3-person,
> on-the-side consulting companies. And logically, each of these should
> have their own PI prefixes and a slot in the global routing table.
>
People might argue it, but, I am not convinced they would succeed in that
argument. If you want an ASN for something other than connecting to the
internet for multihoming or other unique routing policy, then, make one up.
Doesn't matter whether it's 16 or 32 bits. Also, there are a whole slew
of private ASNs reserved for just such a purpose if you want to retain
compatibility with existing ASN numbering.
As such, I think that argument becomes specious in general.
OTOH, I have a SOHO with a legitimate ASN and protable IPv4 space. Who
are you to tell me that it isn't legitimate for me to use it in this =
manner?
Why do you get to decide that my SOHO is less worthy of PI space and the
ability to reliably multihome just because my organization is small?
> Scalable? NO. Not just the number of routes, but also the churn those
> routes would make.. Oh god.
>
So we return to the need to separate the end-point identifier from the=20
routing
identifier and come up with a routing scheme that allows routing =
assignments
to be dynamic and flexible independent of the layer 3/4 endpoint =
identifier.
> It's better to try to stick to 16 bit ASNs for now, and make stricter
> policies and reclaim the space if needed.
No, it's not. It's better to expand to 32 bit ASNs now and realize that
this is really just the most convenient way to get the necessary 20 bit =
ASNs
that will happen whether we reclaim or not. Think about the difference
between coding 20 bit ASNs and 32 bit ASNs and then ask yourself is there
really any legitimate technical reason to code 20 bits instead of 32?
Obviuosly, you don't subscribe to the premise that regardless of=20
reclamation,
we will run out of 16 bit ASNs soon enough. That's fine, you may be right.
However, from where I'm sitting, I think we will. I also think that the
$500 up front cost and $100 annual renewal associated with an ASN are
decent incentive for people not to get them unless they have a legitimate
use for them. Private ASNs are too easy and cost nothing.
Owen
--==========B806C24CE33E16FE4EBB==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFBq43sn5zKWQ/iqj0RAlPlAJ9DZeVCDtQ266AHu7Zyy193lkwmHACffUmW
6p2Bl3Gz8YXmN9AwmtocCPs=
=90I2
-----END PGP SIGNATURE-----
--==========B806C24CE33E16FE4EBB==========--
