Thanks for the discussion so far, there seem to be a number of suggestions from the emails. First are a couple of comments that we go ahead with the document largely as-is. Second is the suggestion that we should keep a figure, but try and base it on a bit more science than "/36 sounds better than /40." Third is that any specific figure should be removed as it won't cover all cases. The third way is easy, and if consensus went in that direction, I am happy to cut the /36 figure out of the document, but then I'm struggling to understand why we would need a separate document to RIPE-399, which recommends aggregation, but accepts there are reasons you may have to advertise more specific prefixes. Would a modification to RIPE-399 that just expands on the cursory mention of "this all applies to IPv6 too," e.g. by adding a few IPv6 examples in the text, be sufficient? The reason the document was originally written was that once the routing requirement was removed from the IPv6 address policy document, there was pressure for the group to come up with a number that people could put in filters that allowed some flexibility with announcements of more specific routes within their /32, with a fair chance of those prefixes getting propagated widely, but limited the potential for abuse. If there is still need for a document separate to RIPE-399 (and of course that question is still open, but there have been some strong suggestions on the list that there should be), that brings us back to the first and second options. The first is a simplification of the second, so lets think about the second. Studying the IPv4 routing table may lead us to a potential number of more specific routes, but would it lead us to any conclusions about their length? The Swiss example shows that the routes may not be subdivided from the most significant bits of the prefixes, so how do we do the analysis? Remember, if this is to be a WG document, I'd like to attempt to reach consensus in the group (and I suspected that would never be easy), so all input is welcome! Looking forward to an interesting 20 minute discussion in Prague, Rob
Studying the IPv4 routing table may lead us to a potential number of more specific routes, but would it lead us to any conclusions about their length? The Swiss example shows that the routes may not be subdivided from the most significant bits of the prefixes, so how do we do the analysis?
(Alas, I will not be making ap-wg, so here is something to think about)... I think, in order to come up with a normal figure, we need to normalise the data as best we can. Taking the average number of deaggregates per v4 allocation size should give us an idea of how much people may want to deaggregate their v6 allocation (which in this region is likely to be /32), Am in full acceptance of the fact that some people deaggregate for either other TE reasons (e.g high localpref and lack of community support by expensive upstream) or no good reason at all (i.e ignorance / assumptions about the way the internet works) This could lead us back to the /36 choice if , for instance, we found that on average there four v4 deaggregates (since deaggregating the standard v6 allocation of /32 to 4 deaggregates produces this). However, I do feel we need a model more comprehensive than this, I'd like to see not only a maximum length, but for this to be applied proportionately to the size of the allocation, I'm not comfortable allowing bigger folk to pollute by allowing them to deaggregate a larger allocation up to a fixed deaggregate size. Dave.
Remember, if this is to be a WG document, I'd like to attempt to reach consensus in the group (and I suspected that would never be easy), so all input is welcome!
Looking forward to an interesting 20 minute discussion in Prague, Rob
------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net
I think, in order to come up with a normal figure, we need to normalise the data as best we can. Taking the average number of deaggregates per v4 allocation size should give us an idea of how much people may want to deaggregate their v6 allocation (which in this region is likely to be /32),
Am in full acceptance of the fact that some people deaggregate for either other TE reasons (e.g high localpref and lack of community support by expensive upstream) or no good reason at all (i.e ignorance / assumptions about the way the internet works)
you may find an upcoming JSAC paper somewhat interesting http://archive.psg.com/jsac-deag.pdf randy
On 03/05/2010 08:39, "Randy Bush" <randy@psg.com> wrote:
I think, in order to come up with a normal figure, we need to normalise the data as best we can. Taking the average number of deaggregates per v4 allocation size should give us an idea of how much people may want to deaggregate their v6 allocation (which in this region is likely to be /32),
Am in full acceptance of the fact that some people deaggregate for either other TE reasons (e.g high localpref and lack of community support by expensive upstream) or no good reason at all (i.e ignorance / assumptions about the way the internet works)
you may find an upcoming JSAC paper somewhat interesting
Interesting paper indeed. To sum this up for people who haven't read, the conclusion states "According to our results, there is no trend towards more aggressive prefix deaggregation or traffic engineering over time", does this mean we shouldn't bother? I did a quick check against the RIPE allocations file for created route objects per allocation which are not the same size (i.e smaller) and summarised based on the CIDR bits of the allocation, here are the results for those that are interested: Bits Average (mean) Deaggs ------------------------ 9: 16 10: 14 11: 24 12: 73 13: 43 14: 31 15: 40 16: 19 17: 19 18: 12 19: 8 <--- Modal average alloc size 20: 6 21: 3 Method was simply to query the database for each allocation and look for smaller routes, take the mean and round down. As you can see, the mean is skewed as the number of bits decreases (and the number of smaller bit allocations is of course reduced due to the number of organisations able to justify that size) The modal average of allocation size is /19 according to the file (followed closely by /20), I guess this tells me that, on average, people are allocated /19s and when they deagg, they create on average 8 deaggregated route objects... (so would likely do so in a uniform fashion with /37s) What it certainly does say is that /36 would be too harsh a limit to impose based on what people appear to be doing now, assuming the deaggs happen as a result of sites (i.e multihoming) Dave.
randy
------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net
The third way is easy, and if consensus went in that direction, I am happy to cut the /36 figure out of the document, but then I'm struggling to understand why we would need a separate document to RIPE-399, which recommends aggregation, but accepts there are reasons you may have to advertise more specific prefixes. Would a modification to RIPE-399 that just expands on the cursory mention of "this all applies to IPv6 too," e.g. by adding a few IPv6 examples in the text, be sufficient?
yep. 96 more bits, no magic. randy
participants (3)
-
David Freedman -
Randy Bush -
Rob Evans