[1579] in North American Network Operators' Group
Re: Policy Statement on Address Space Allocations
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Fri Jan 26 15:48:28 1996
From: Iljitsch van Beijnum <iljitsch@unix1.bart.nl>
To: smd@cesium.clock.org (Sean Doran)
Date: Fri, 26 Jan 1996 21:31:09 +0100 (MET)
Cc: Daniel.Karrenberg@ripe.net, smd@sprint.net, cidrd@iepg.org, iab@isi.edu,
iana@isi.edu, iesg@isi.edu, local-ir@ripe.net, nanog@merit.edu
In-Reply-To: <96Jan26.090917pst.5568@cesium.clock.org> from "Sean Doran" at Jan 26, 96 09:09:04 am
> We just have some differences of philosophy -- you think
> that RIPE really can persuade people into having only
> 1024 announements (preferably far fewer) in 195/8, and
> I don't. That's all.
> The compromise we could find would involve a practicable
> method by which we don't have to put a prefix-length-floor
> in place, but at the same time don't have to spend enormous
> amounts of (unavailable) CPU time filtering based on what's
> in the RIPE database.
So how is this for a compromise:
If there actually _are_ more announcements than 1024 in any particular /8
under the control of the RIPE NCC, you implement filtering in such a way
that it gets down below 1024 again.
In this scenario, as long as the NCC can persuade it's customers to
aggregate, there are no problems. And if problems arise, it is extremely
likely that they can be fixed by filtering /20 and longer. That way, only
the offenders suffer and not the people who aggregate as RIPE tells them
to do.
A weekly check to see if the number of announcements stays below 1024
would be quite adequate and not unduly machine or manpower intensive, in
my opinion.
