[184479] in North American Network Operators' Group
Re: /27 the new /24
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Oct 3 23:01:32 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPkb-7BF_VVAXNonVV-o6o+c3nrHxk7nwaMBm_eE-S2tShWObQ@mail.gmail.com>
Date: Sat, 3 Oct 2015 20:00:19 -0700
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
The race is on=E2=80=A6
One or more of these things will be the death of IPv4:
1. Not enough addresses
2. Routing Table Bloat due to one or more of:
A. Traffic Engineering
B. Stupid configuration
C. Address Fragmentation through transfers and =
microallocations of =E2=80=9CTransition space=E2=80=9D
D. Stupid network designs (where the physical =
deployment forces something like B rather than just software stupidity)
3. Some highly desirable feature or application which =
simply can=E2=80=99t be implemented effectively on IPv4.
As such, I say go ahead and route whatever. ARIN provides a nice =
constrained prefix for these transitional allocations
so you can at least limit the bloat from that factor, but even at the =
/24 level, we=E2=80=99re faced with upwards of 16 million routes
that we are nowhere near ready to handle.
In case you haven=E2=80=99t been paying attention for the last 25 years, =
there are a number of ways in which IPv4 DOES NOT SCALE.
We=E2=80=99ve been keeping it alive on life support for a VERY LONG =
time. As with all patients on life support, the longer it continues,
the more it becomes a losing battle and the harder (and more resource =
intensive and more expensive) it becomes to keep
the patient alive.
Fortunately, in this case, we have a nice new body that we can =
transplant the internet into that has many fruitful years ahead
of it. So=E2=80=A6 Do whatever you have to to survive in the meantime, =
but focus on getting your stuff onto the IPv6 internet so that
we can all let IPv4 go gently into that good night and have it=E2=80=99s =
well deserved final rest.
Owen
> On Oct 3, 2015, at 06:18 , Baldur Norddahl <baldur.norddahl@gmail.com> =
wrote:
>=20
> Except we might very well reach 1+ million routes soon without =
accepting
> longer prefixes than /24. Also route updates is a concern - do I =
really
> need to be informed every time someone on the other end of the world =
resets
> a link?
>=20
> On 3 October 2015 at 12:57, William Waites <wwaites@tardis.ed.ac.uk> =
wrote:
>=20
>> On Sat, 3 Oct 2015 12:42:01 +0200, Baldur Norddahl <
>> baldur.norddahl@gmail.com> said:
>>=20
>>> 2 million routes will not be enough if we go full /27. This is
>>> not a scalable solution. Something else is needed to provide
>>> multihoming for small networks (LISP?).
>>=20
>> It's not too far off though. One way of looking at it is, for each
>> extra bit we allow, we potentially double the table size. So with =
500k
>> routes and a /24 limit now, we might expect 4 million with /27. Not
>> exactly because it depends strongly on the distribution of prefix
>> lengths, but probably not a bad guess.
>>=20
>> Also there are optimisations that I wonder if the vendors are doing =
to
>> preserve TCAM such as aggregating adjacent networks with the same =
next
>> hop into the supernet. That would mitigate the impact of wanton
>> deaggregation at least and the algorithm doesn't look too hard. Do =
the
>> big iron vendors do this?
>>=20
>> -w
>>=20
>> --
>> William Waites <wwaites@tardis.ed.ac.uk> | School of Informatics
>> http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh
>> https://hubs.net.uk/ | HUBS AS60241
>>=20
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>=20
