Could we not use current ipv4 deaggregation + growth to make some estimations about what could happen with ipv6? For instance, you may have a common trend of people carving up /23s into a pair of /24s (this is quite common with PI) , representing the fact that they have two sites that they wish to provide some Traffic-engineered failover scenario for. You could use ipv4 deaggregation profiles such as this to model what may happen if you did the same with v6 (sadly one-to-one mapped and not taking into account fully using the address space), this could be based on common mindset of people (e.g turning up, asking for PI, but knowing they want it split between two sites, a /47 in this case to produce two /48s) So, really, what I'm asking in a long-winded way, is about the worth of looking at ipv4 deaggregation, normalising it as best we can and then using it to model ipv6 deaggregation trends... Dave. On 27/04/2010 11:21, "Nick Hilliard" <nick@inex.ie> wrote:
On 27/04/2010 03:18, Philip Smith wrote:
Anyway, the doc would just be recommendations, along the lines of RIPE-399 being no more than recommendations. If folks think we are wasting our time putting together an IPv6 equivalent, let us know, and we can stop here. ;-)
... which gets back to the issue of vapour. We have no viable, clever multihoming mechanism in ipv6, but rely purely on the tricks that we used in ipv4. And the requirement traffic engineering hasn't gone away.
The problem we face today is that if we make a recommendation to say that deaggregation is permissible on TE grounds, then we don't know what the consequences of this decision are going to be several years down the line. On the one hand, we lack a crystal ball to peer into the future; on the other, we have no theoretical models for ipv6 prefix announcements. All we have is some idea about how ipv4 prefix announcements have worked out over the last number of years, and also a list of differences between the ipv4 and ipv6 addressing models.
Which brings us back to vapour: we need to make a decision on this, because deaggregation levels will have a dramatic effect on the future requirement for large quantities of TCAM and related lookup. Unfortunately, we have no basis on which to make this decision other than opinions and gut feeling. If we rely on the latter, then a highly conservative approach would be well advised.
Nick
------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net