[ppml] 2005-1 and/or Multi6

[Geoff Huston]

>Interestingly I had an exchange at the microphone during the IAB Plenary 
>open session about this topic.  I pointed that this policy existing and is 
>being considered in the ARIN region and if this policy was implemented the 
>ideas about a very small v6 routing table may go away.  Someone responded 
>with a comment like, that is just fine for the first 65k routes.

There is no need for a 'very small' routing table - there is a need for a 
routing table that is viable within the parameters of the infrastructure 
base that makes up the network. So the objective is to support address 
deployment practices that match deployment models to the extent that the 
resultant network is one that fits efficiently into the deployed 
infrastructure platform. These days its reasonable to suggest that the 
comfort zone is greater than 10**5 entries, and probably around 10**6 
entries. This is of course a little higher than the current IPv6 value of 
some 750 entries. The concern I hear is that in creating this collection of 
unaggregated /48 entries in to the routing table we have no clear idea of 
what mechanism we may use in the future to reclaim these entries when 
routing slots may be under some scarcity pressure. There is the concern 
that this may be an enduring legacy that would be difficult to undo. On the 
other hand we may be placing too much emphasis on strict provider 
aggregation and pressure for very small routing tables in their wake 
creating a different, but equally tough set of issues, such as scoped 
addresses, id/locator split architecture, extended protocol handshakes and 
shared context for session support that may in the long run prove more of 
an intractable  scaleability problem than routing!

As far as I can see part of the problem here is that routing is en 
evironment that has very limited feedback mechanisms for control functions.

   Geoff