[AfriNIC-rpd] Opposition to AFPUB-2010-v4-005-draft-01

[Andrew Alston]

I also need to raise my voice in opposition to clause 3.5.2 of the soft
landing proposal (in addition to other objections I've raised)

 

Let's look at a couple of facts around /24s vs /27s

 

5 years ago, the routing table was at < 200k routes in the DFZ, today,
we're at around 340k.

 

Most people are currently filtering anything smaller than /27 other than
POSSIBLY from their direct customers.  If we were to allow routes as
small as a /27 and IF the rest of the internet would accept these
routes, which I SERIOUSLY doubt, we are looking at a potential for the
routing table to rise to over the 500k mark.

 

Now, for anyone carrying a full routing table, this could be a major
problem.  The fact is, there are a LOT of people running hardware that
would simply not function on full table if the v4 routing table grew to
this size.

 

Please note the following taken off a 7600 with a SUP720-3bxl engine:

 

Module              FIB TCAM usage:                     Total
Used     %Used

   5                     72 bits (IPv4, MPLS, EoM)      524288
344998     66%

                        144 bits (IP mcast, IPv6)      262144
4977      2%

 

Off a RSP720-3cXL engine:

 

L3 Forwarding Resources

Module              FIB TCAM usage:                     Total
Used     %Used

   5                     72 bits (IPv4, MPLS, EoM)      524288
346496     66%

                        144 bits (IP mcast, IPv6)      262144
4998      2%

 

These routers are not old ancient routers out of the dim and distant
past, these are currently in production, on sale routers, that people
are actively buying today.  The routing table grows to much bigger, and
a LOT of people are going to hit a MAJOR problem.  In the same way
people running non-XL versions of these stopped being able to carry full
table a while back.  The difference there was, there was an XL upgrade
you could get, in this case, replace your whole router.

 

And before people say that I'm purely fighting this from a Cisco stance,
this has nothing to do with Cisco vs any other vendor, this has to do
with what hardware is currently out there and heavily deployed and the
issues the policy could cause on active in use hardware irrespective of
the vendor.

 

The second major problem with this clause is the simple fact that if we
start issuing /27s, we are going to be issuing blocks which will be
filtered by the majority of the world.  This is kind of senseless, and
that filtering by the rest of the world, is unlikely to change,
particularly considering the issues highlighted above.   

 

I also need to point out that there is currently a proposal before RIPE
as well to make minimum allocation sizes of /24. In this proposal it
specifically states under the supporting arguments:

 

"Removal of discrimination: prefixes of /25 and longer are routinely
filtered by many network service providers on the Internet. As many End
Users who apply for PI assignments do so for the purposes of small-scale
multi-homing, in practice the current assignment policies discriminate
against these End Users."

 

Thanks

 

Andrew Alston

 

 

From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf
Of Stacy Hughes
Sent: Monday, February 28, 2011 11:07 PM
To: rpd at afrinic.net
Subject: [AfriNIC-rpd] Opposition to AFPUB-2010-v4-005-draft-01

 

Esteemed Colleagues,

I must speak in opposition to this proposal.  

First, I am philosophically opposed to soft landing proposals in
general.  When the party is over, it's time to go home.  We don't get 5
more minutes or more birthday cake.  Incorporation of and transition to
IPv6 is the way forward, and necessary for all of us.

 

I especially disagree with direct assignments or allocations of IPv4
space in subnets of longer prefix lengths than /24.  It is pointless to
assign blocks that a significant portion of the Internet will not see,
and harmful to bloat the routing table.

Thank you,

Stacy Hughes

(speaking only for myself and not for my affiliations)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20110228/c8ac5cd2/attachment.html>