The problem with that isn't so much the lenght of the number (that's just "linear memory waste"), the problem that I see is that the number of ASes actually in use reflect the complexity of the overall topology - and *that* goes into BGP convergence times much stronger than linearily.
Agreed. It was merly a joke. Personally I think that most customers asking for multihoming is actually asking for something completly different. But we have been down that discussion before...
Not all of the /32s might even necessarily be visible globally, upstream could go through the /28.
Well, in our case they would. Problem is that we do not have a /28. My point was to some extent that we should define this better. It's is a single LIR, but the question is what the allocation should be for routing purposes.
The new policy (effective next monday) will permit this - if you come up with good reasons and some thought about addressing plans and hierarchy, getting something "large enough" should not be a unsolveable problem. At least that was the intention - the address space is large enough so that haggling over "we need a /28" - "no you can only get a /31 plus a /32" should not occur (unless the "need" for a /28 really isn't justificable).
I agree, but RIPE NCC have said we will only get the /35. Best regards, - kurtis -