[ppml] ppml 2002-7

[Steve Kent]

On Tue, 11 Feb 2003, Forrest wrote:

> It seems like a lot of the people announcing /24's are not doing it to
> provide redundancy, but rather to load balance between their two circuits.
> I can completely understand filtering these /24's, but in the process it
> hurts the small organization that wants to multi-home for redundancy but
> isn't large enough to qualify for a /20.  In reality, the current AKIN
> allocation policy actually seems to encourage the wasting of IP address
> space just to be able to qualify for a /19, when perhaps only a /22 would
> be more than plenty.  You only have to look at some of these web hosting
> companies to see evidence of wasting IP addresses.  I've seen a whole /25
> assigned to ONE single webserver before, even when virtual hosting would
> have worked just fine.

We deal with a number of clients who have decided to multi-home -- mainly
for redundancy. A number of enterprise managers have expressed
concerns about the stability of some providers, and thus want to announce
their own blocks. I would rather see them given a /24 or /23; otherwise,
it is likely they will try to pump their numbers for a /22. This just wastes
addresses.

>
> >
> I don't see anything necessarily bad with a new swamp if all of the
> addresses in it are used to multihome.  It would be silly to assign a /24
> to someone that only connects to one provider, since you could just give
> them a /24 from the provider's larger aggregate.  If you quit multihoming,
> you return your addresses back to the "multihome swamp".  This would allow
> providers to filter out the useless /24's (like the /18 being announced as
> 64 /24's, yet allow them to accept somewhat more important small
> multihoming blocks).

I agree completely. I would like to see new swamp space make a bit more
sense though -- /24s out of a single larger block. This will make
filtering and aggregation potentially easier. Networks who cease
multi-homing should, of course, be required to give up their block.

Perhaps, I am not fully grasping the ramification of this, but I don't see
this increasing routing tables more substantially then the current system.
Under the current system, for instance, as a small provider I would
announce a /19 -- now a customer who wants to multi-home get assigned a
/24. Of course that assigned block is out of my /19 announcement -- but
the second peer he announces to will only get the /24. That peer would
only be able to forward the /24 -- thus no aggregation and an increase in
table size.


--Steve

_____________________________________
Steven Kent
Senior Network Engineer
onShore, Inc.
http://www.onshore.com