[ppml] ppml 2002-7

[Steve Rolapp]

>
snip

To me, it seems that the biggest issue that 2002-7 seems to address is 
trying to multihome small blocks that aren't located in the old Class C 
space.  It seems that most providers that do filtering, they filter on
the 
old Class boundries.  In the old Class C space, they'll accept /24's 
because of people using old swamp space.  So suppose you have block 
192.0.0.0/23, your block won't likely get filtered, but suppose you have

12.100.100.0/23, what good is it to multihome if nobody would accept
your 
small route?  Basically it makes sense to allocate a specific block just

for small organizations that want to multihome, that providers will 
accept /24's and shorter from (allocate it from the old Class C range
and 
I doubt anyone will have to adjust their filters).  I just don't see
this 
causing the routing table to explode in size.  What's exploding the 
routing table is stuff like someone announcing a /18 as 64 /24's (look
at 
205.145.0.0).

Forrest
>

This is essentially one of my points. The whole idea of aggregating only
works well for the provider that "owns" the base block.  As an example,
there are many /24 that I see from old class A's.  They may be
aggregated by the base providers but the other providers can't aggregate
unless other adjoining bit wise networks are also present.  Upstreams
can't filter without potentially blackholing traffic (something I have
observed more then once much to the chagrin of that provider). So in
practice what it comes down to is that the /24 is seen by the world.

So I go back. Aggregation can't be an issue. What is the real issue with
allowing small (or otherwise) multi-homed organizations to have assigned
a single /24 (or even smaller) of their own?  

It really sounds like the reason to deny is based on address space.
Again if the Network/AS pair is being seen by the world anyway why set
an arbitrary /24.  As was commented already, I have also seen single
digit usage of a /24 because the /24 was all that could be announced.

Steve