[ppml] 2005-1 and/or Multi6

[Michel Py]

>> Michael Dillon wrote:
>> We have to allocate PI addresses to these so-called 
>> end-sites because to do otherwise is restraint of trade.
>> However, it is unwise and imprudent to offer them /48
>> prefixes which are highly wasteful of global router capacity

> Thomas Narten wrote:
> I would like to hear from router vendors that they actually
> do intend to do this sort of optimization.

Ditto.

> The reason I ask is that even if 99% of the routes one
> deals with are short prefixes (e.g., /32) there will
> always be a need to deal with longer ones too. E.g.,
> for routes within your AS, etc. So I'm not sure the above
> arguement actually holds water at the end of the day.

On the two implementations I have seen (not recently), one uses a fixed
64-bit number to store the routing prefix and the other a fixed 128-bit
number (in order to allow things such as /127 ptp links to work). It
takes more CPU to store and sort a table composed of variable length
elements than it takes with a table of fixed-length elements, and it is
more difficuly to design hardware to do so as well; not to mention more
opportunities for bugs. Variable-length elements are a valid option for
text fields, not for routing prefixes. Speed and robustness vs. storage
efficiency, speed wins especially when it allows your favorite vendor to
sell you memory at outrageous prices :-)

Michael, at the end of the day your 48-bit prefix takes the same amount
of RAM than the 32-bit prefix: 64 and possibly 128 bits anyway. The
justification to allocate shorter prefixes is valid only when
organizations begin to need more than one. Given that 64k subnets is
enough for most and that allocations made using RFC3531 will extend the
initial /48 to a /47 for the few large organizations that require it, I
don't see any advantages in giving /32s away to sites.

Michel.