Supernet block sizes - recommendations?

  > Vince Fuller <vaf at Valinor.Stanford.EDU> writes:
  >     Same here. For large chunks of class C's, we send the end site directly
  >     to the NIC.
  > 
  > This somewhat defeats the goal of using CIDR to reduce routing table
  > explosion, since if the block comes directly from the NIC, no
  > aggregation can be done by the service provider which connects the site.

Well it depends. If the chunks are large, reasonable aggregation
still happens. No offence to Vince but we should concentrate on the
lower levels of aggregation. That's where it matters most and where
entropy is hopefully going to be less of a factor in the future.

I have discussed this recently with some fairly senior people and
to my big surprise and dismay they really thought the (achievable) 
object of the exercise was one supernet route per continent! :-) :-(  

Let me explain a little the strategy we recommend here:


	1) Allocate a conservative(!) chunk size as most requestors
           have a tendency to stockpile. So unless they provide
	   a good justification, they will be allocated less than
	   requested.

	2) To prevent low level entropy, "reserve" a contiguous chunk
           for the same requestor. Usually this is the same size as
           the chunk allocated. Tell the requestor that they can get
	   (part of this) contiguous address space upon presenting 
	   documentation on how they use the first chunk.
	   After about a year we have seen that only a small part comes
	   back for more.

	3) We plan to recycle the reserved space after 12-18 months.

If we err very low in the first assignment we will have to open a new
discontiguous chunk for the same organisation.  So we have created two
supernet routes instead of one.  How big a deal is this if it happens
occasionally?  I deem this and acceptable tradeoff between address space
usage and routing table size. 

Example: If we get a request for 64 Cs which is not very well
substantiated we will allocate 16 or 32 and reserve the same amount. 



And now for something completely different.....


Ways to convince people to let go of a "class" B request:

Take their projected host and subnet numbers.  Compute the address space
usage factor and tell them: "Your own projections show that you will use
only x% of the address space you request.  By the Internet community's
standards this too wasteful." We regularly get requests that lie in the
low single digits by this standard. 

Of course you have to consider the proposed subnetting scheme.  If they
propose lots of 8-bit subnets with less than 10 hosts on them, we do
suggest a different subnet size or in extreme cases even subnetting Cs. 

Tell them: "A scheme for classless inter-domain routing is coming.  This
means classes will no longer be visible soon.  So why bother."

Tell them that the procedure for getting Bs takes longer and requires
them to provide more information to justify the request....  and keep
that promise. 

Refer really notorious cases to the next higher level Internet Registry.
They have more experience and a much thicker skin.  We have been sitting
on some bogus requests for a long time and I expect IANA to just sit on
some indefinitely.  This is really convincing and sometimes the only
escape! 


Hope this helps some of you. Comments welcome.

Daniel