With apologies for not doing this soon after the meeting in Lisbon, attached is a slight revision of the IPv6 routing recommendations document. If I missed any suggested changes from the meeting, let me know. I will not go through it in detail in Prague as we have limited time, instead I would like the discussion at the meeting and here on the list to focus on two items. (1) Is there a need for this document? We've heard a couple of voices on this list suggesting it is. (2) Is /36 the correct *example* of "prudent subdivision?" There has been one suggestion recently to increase it to /40, is that the way to go? Or would it be abused? Regards, Rob -- Rob Evans JANET(UK) Development Team Twitter: https://twitter.com/JANETDev/team Work tweets: https://twitter.com/internetplumber JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG RIPE Routing Working Group Recommendations on IPv6 Route Aggregation ==================================================================== Rob Evans Philip Smith Introduction ============ Recent discussion has shown there is a limited requirement to be able to advertise more specific prefixes from an IPv6 Provider Aggregatable (PA) allocation where a Local Internet Registry (LIR) contains several networks which are not interconnected, or for traffic engineering purposes. This document recommends such advertisements are limited in both length and scope. It is intended to supplement the working group's Recommendations on Route Aggregation [RIPE-399]. Background ========== The IPv6 address allocation and assignment policy for the RIPE region [V6-ALLOC] only allows LIRs to obtain more than the minimum PA allocation if they can demonstrate address utilisation that requires it. This fits with the address space management principle of conservation. However, as understood in the RIPE Routing Working Group's Recommendations on Route Aggregation [RIPE-399], there are occasionally requirements for the advertisement of more specific routes from within an allocation. With many ISPs currently filtering at the minimum PA allocation (/32) within the relevant address ranges, this can cause difficulties for some networks wishing to deploy IPv6. Some reasons for wanting to advertise multiple prefixes from a PA allocation could be: - The LIR has several networks that are not interconnected. - Traffic engineering: A single prefix that covers an LIR's entire customer base may attract too much traffic over a single peering link This document is only concerned with IPv6 Provider Aggregatable (PA) allocations, and does not discuss Provider Independent (PI) prefixes. Recommendation ============== It is suggested that prefix filters allow for prudent subdivision of an IPv6 allocation. For example, the advertisement of prefixes up to at least four bits longer than the minimum PA prefix -- this would mean up to a /36 with the current allocation policy. Obviously longer prefixes can be exchanged with mutual agreement between neighbouring autonomous systems, and the operator community will ultimately decide what degree of subdivision is supportable. Advertisement of more specific prefixes should not be used unless absolutely necessary and, where sensible, a covering aggregate should also be advertised. Further, LIRs should use BGP methods such as NO_EXPORT [RFC-1997], [AS-PATHLIMIT], or provider-specific communities, as described in [RIPE-399] to limit the propagation of more specific prefixes in the routing table. The recommendation that a /36 be the minimum size routed is not to be used for any other purpose -- such as address allocation for multihomed customers. Customers of LIRs must still be able to justify address requirements in line with current RIPE policy. Discussion ========== There is a valid need for some LIRs to advertise more than one IPv6 PA prefix. As either obtaining more address space and advertising more /32 prefixes, or advertising more specific prefixes within an already allocated /32 have the same impact on the routing table, it is suggested that the latter approach is taken to prevent address space wastage. The prefix length of /36 has been chosen as it falls on the next 'nibble' boundary which aids readability of addresses and DNS delegation, whilst not allowing uncontrolled growth of the routing table. This figure is, however, somewhat arbitrary and the level of deaggregation that is supportable will be determined by best current practices that emerge from the operator community as IPv6 deployment increases. It is understood that this will not cover all possibilities, and where widely deployed filters prohibit a requirement to advertise longer prefixes, sites may have to consider the suitability of Provider Independent addresses, or LIRs may have to consider mechanisms of obtaining more than a /32 of Provider Aggregatable space. References ========== [V6-ALLOC] http://www.ripe.net/ripe/docs/ipv6policy.html [RIPE-399] http://www.ripe.net/ripe/docs/ripe-399.html [RFC-1997] http://www.rfc-editor.org/rfc/rfc1997.txt [AS-PATHLIMIT] http://tools.ietf.org/html/draft-ietf-idr-as-pathlimit-03 Work in Progress.
we tell people to use provider space. we tell providers to allocate /48 to a customer. we tell people ipv6 allows multi-homing. then we smoke some strange stuff, and tell people not to route the result. what am i not understanding here? randy
On 26/04/2010 13:32, Randy Bush wrote:
we tell people ipv6 allows multi-homing.
Do we? Which particular vapour are you referring to here? Nick
Nick Hilliard said the following on 27/04/10 07:57 :
On 26/04/2010 13:32, Randy Bush wrote:
we tell people ipv6 allows multi-homing.
Do we? Which particular vapour are you referring to here?
I suppose the question Rob and I are trying to address is, do we want to encourage ISPs to take their /32 and announce all 65536 /48s in an effort to do some kind of amazing traffic engineering act by juggling all 65k prefixes at once? Or do we want to encourage ISPs to think aggregation, and only leak the subprefixes that they need to leak to support their multihoming customers and traffic engineering requirements? 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. ;-) philip --
Hi Philip,
Nick Hilliard said the following on 27/04/10 07:57 :
On 26/04/2010 13:32, Randy Bush wrote:
we tell people ipv6 allows multi-homing.
Do we? Which particular vapour are you referring to here?
I suppose the question Rob and I are trying to address is, do we want to encourage ISPs to take their /32 and announce all 65536 /48s in an effort to do some kind of amazing traffic engineering act by juggling all 65k prefixes at once?
Or do we want to encourage ISPs to think aggregation, and only leak the subprefixes that they need to leak to support their multihoming customers and traffic engineering requirements?
I want to emphasize that this came up because of LIRs that had multiple distinct networks that they couldn't announce (ok, nothing is impossible, but it would be awkward) their PA /32 prefix in one part. Possible solutions were to give them multiple /32 prefixes or to write a recommendation that a bit of de-aggregation should be permitted. At the time the latter was felt to be a better solution :) It can of course be abused for traffic engineering...
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. ;-)
The routing stuff was taken out of the address policies to be moved to a separate routing recommendations document. I think this is important, so please continue :-) Thanks, Sander
the idea here is twofold: 1) to take routing policy out of addressing policy. That part was done 2) make people aware that while de-aggregation is possible, it has its costs, for everyone, not just the de-aggregator, and therefore one should think a bit before splitting an allocation down into atoms. Because a lot of people find it good to have some recommendation describing this thought process, this document is being written and sent for consideration to the working group. Joao On 27 Apr 2010, at 11:25, Sander Steffann wrote:
Hi Philip,
Nick Hilliard said the following on 27/04/10 07:57 :
On 26/04/2010 13:32, Randy Bush wrote:
we tell people ipv6 allows multi-homing.
Do we? Which particular vapour are you referring to here?
I suppose the question Rob and I are trying to address is, do we want to encourage ISPs to take their /32 and announce all 65536 /48s in an effort to do some kind of amazing traffic engineering act by juggling all 65k prefixes at once?
Or do we want to encourage ISPs to think aggregation, and only leak the subprefixes that they need to leak to support their multihoming customers and traffic engineering requirements?
I want to emphasize that this came up because of LIRs that had multiple distinct networks that they couldn't announce (ok, nothing is impossible, but it would be awkward) their PA /32 prefix in one part. Possible solutions were to give them multiple /32 prefixes or to write a recommendation that a bit of de-aggregation should be permitted. At the time the latter was felt to be a better solution :)
It can of course be abused for traffic engineering...
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. ;-)
The routing stuff was taken out of the address policies to be moved to a separate routing recommendations document. I think this is important, so please continue :-)
Thanks, Sander
On Tue, 27 Apr 2010, João Damas wrote:
the idea here is twofold: 1) to take routing policy out of addressing policy. That part was done
This strikes me as a bad idea. If you can't aggregate a set of addresses into a single announcement, then the best way to keep the number of prefixes in the global tables down is to have people get another block. That way you can have a strict filtering policy, and noone tries to get away with deaggregation because: i) It won't work ii) It isn't needed This is a little extra work for the RIRs - each new non aggregatable block needs another resource request, but it means that we avoid the mess that we've already got in IPv4 where things tend to work as /24s anywhere, so why bother aggregating beyond that. In other words, if an organisation can't announce its address space in a single aggregatable block, then give it multiple blocks - a new block for each disconnected network, rather than force it to deaggregate the block and announce it in little pieces (and thus opening the door for everyone to deaggregate their blocks unnecessarily).
2) make people aware that while de-aggregation is possible, it has its costs, for everyone, not just the de-aggregator, and therefore one should think a bit before splitting an allocation down into atoms.
The problem is not that organisation don't know, it's that they don't care, and there's little reason for them to care! If someone were to deaggregate a /32 into 256 /40s, it doesn't cost them - it costs everyone else. It costs in router FIBs, RAM, and convergence time. Does their deaggreation harm themselves specifically? As long as it seems to work, no. Making people aware it has costs (for everyone else) doesn't stop it happening. Having a recommendation paper isn't going to be enough - it didn't work for IPv4, there's no reason to expect it will work for IPv6. It's also solvable fairly easily as described above. What we do now (potentially opening the door for orders of magnitude of deaggregation) could have rather large consequences in future - even if RAM, TCAM, FIB, etc are orders of magnitude larger in future, convergence time is still increased proportionally (or worse?). Regards James
Sander Steffann wrote: [....]
The routing stuff was taken out of the address policies to be moved to a separate routing recommendations document. I think this is important,
So do I, my feeling is that this is a matter of overall consistency.
so please continue :-)
Indeed.
Thanks, Sander
Wilfried.
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
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
On 27/04/2010 11:29, David Freedman wrote:
Could we not use current ipv4 deaggregation + growth to make some estimations about what could happen with ipv6?
we could - we just haven't. And I'm concerned at what the ipv4 deaggregation frequency looks like: http://twinkie.foobar.org/~nick/ipv4-freq-linear-axis.png http://twinkie.foobar.org/~nick/ipv4-freq-log-axis.png Same data in both cases - just different axis scaling. /24 was noted retrospectively in ripe-399 - it had been a de-facto standard for a very long time. We don't have this convention in ipv6. Nick
Nick Hilliard said the following on 27/04/10 21:27 :
/24 was noted retrospectively in ripe-399 - it had been a de-facto standard for a very long time. We don't have this convention in ipv6.
Well, RIPE-399 came out of us wanting to document what had been our long term "good practices" for the benefit of newcomers to the industry. Hindsight is easy - but IPv6 recommendations are more challenging. If we pick a number, as suggested in the current iteration of the draft, we might well regret it in the future. Which is why perhaps a message saying "aggregate wherever possible" might be all we can do now. (I've already had questions similar to 'how do I do traffic engineering with my /56'.) philip --
On Tue, Apr 27, 2010 at 11:29:52AM +0100, David Freedman wrote:
Could we not use current ipv4 deaggregation + growth to make some estimations about what could happen with ipv6?
Yes, and it has been done at least once, about 4 years ago; here's a presentation, developed by Jason Schiller and me for NANOG in June, 2006 given again again by me at RIPE in October, 2006: http://www.vaf.net/prezos/ripe53.ppt a shorter and more recent version that I gave at the NORDUNET conference in September, 2009, is also available at: http://www.vaf.net/prezos/nordunet2009-vaf.ppt The first presentation explains more about how we determined the current deaggregation rate (intentional vs. ignorance) and what assumptions we made about projecting that forward. The second presentation is a little more up-to-date, though some of the numbers in both of them lag the real-world observations on both global and large-ISP-local routing table prefix counts; it's probably safe to assume that the real-world numbers for IPv4 are higher than the projections while those for ipv6 are lower than the projections (for example, the predicted number of IPv4 routes for June, 2011 was 285,064; the actual number from last week's CIDR report was 321,746). These presentations stress that projections, by nature, are somewhat speculative. The also stress that the only way out of this mess is a change in the Internet addressing and routing architecture, probably involving some sort of identifier/locator separation. Sure, you can try to influence behavior through address allocation policies and maybe doing so can help mitigate the short-term problem while a long-term solution is pursued, but that approach is doomed to failure in the face of customer demand for multi-homing, traffic engineering, and address space portability. --Vince
Hi Nick,
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.
What would you suggest as a conservative approach? I4 bits of de-aggregation (/36)? - Sander
On 27/04/2010 17:13, Sander Steffann wrote:
What would you suggest as a conservative approach? I4 bits of de-aggregation (/36)?
42? Pulling a figure out of the hat is the Wrong Approach. If we make a decision about this, the decision is going to affect routing de-aggregation for the lifetime of ipv6. If we're going to choose a figure, at least let's do it on the basis of some form of modelling which we can mull over and come to some form of consensus on. Nick
Nick Hilliard wrote: [...]
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.
I think that the magic number which will get consensus, eventually (I hope) is important, but
Nick
the really crucial issue, imho, is to also invent and install a magic stick which motivates people to respect the recommendations in reality. A brief peek into the most recent CIDR report for IPv4 on my disk gives me a certain "gut feeling" about what will happen without such a mechanism - (randomly picking out some "worst" offenders): --- 23Apr10 --- ASnum NetsNow NetsAggr NetGain % Gain Description AS6389 4001 301 3700 92.5% BELLSOUTH-NET-BLK AS22773 1141 76 1065 93.3% ASN-CXA-ALL-CCI-22773-RDC AS18566 1059 33 1026 96.9% COVAD - Covad Communications AS22047 549 50 499 90.9% VTR BANDA ANCHA S.A. So - a ratio of roughly 1:10 to be expected, from the most "liberal" or most "creative" parties doing de-aggregation? Wilfried
I suppose the question Rob and I are trying to address is, do we want to encourage ISPs to take their /32 and announce all 65536 /48s in an effort to do some kind of amazing traffic engineering act by juggling all 65k prefixes at once?
no
Or do we want to encourage ISPs to think aggregation, and only leak the subprefixes that they need to leak to support their multihoming customers and traffic engineering requirements?
yes
Anyway, the doc would just be recommendations
and how many years did it take to clean up the ripe docco on route flap dampening recommendations? randy
Randy Bush said the following on 28/04/10 08:03 :
and how many years did it take to clean up the ripe docco on route flap dampening recommendations?
Worse than that, there still are a significant subset of newcomers who switch on their favourite vendor recommended values for flap damping because they read old versions of their vendor documentation. :-( philip --
and how many years did it take to clean up the ripe docco on route flap dampening recommendations? Worse than that, there still are a significant subset of newcomers who switch on their favourite vendor recommended values for flap damping because they read old versions of their vendor documentation. :-(
moral of story: we need to be careful what we recommend i can see an isp refusing to route a multi-homed content site because ripe docco 666 says no prefix longer than /36. randy
On 28 Apr 2010, at 01:32, Randy Bush wrote:
and how many years did it take to clean up the ripe docco on route flap dampening recommendations? Worse than that, there still are a significant subset of newcomers who switch on their favourite vendor recommended values for flap damping because they read old versions of their vendor documentation. :-(
moral of story: we need to be careful what we recommend
indeed!
i can see an isp refusing to route a multi-homed content site because ripe docco 666 says no prefix longer than /36.
that's why a number, any prefix length, would be wrong, imho and one should stick to the principles and give people an idea of costs of the options (to everyone). Basically create an atmosphere that makes normal people feel this is not a decision without impact. Joao PS: do you want to have that RIPE doc # reserved in advance for this doc? ;)
====BT: Hi, the 20th email on this topic ... May I suggest an "horrible" idea ? here it is in 2 points : #1- Keep the recommendation as "/32 prefix length is recommended to exchange routes in BGP peerings" #2- Accept on a "case by case situation" some (whatever the length ?) exceptions well justified (as we have today for IXPs, name root servers, ...) This way, there is no acceptable reason to deaggregate massively. It remains the common rule to advertise /32 prefixes (or shorter). The main points of discussion are now : #A- what an acceptable exception could be (or how it can be defined) ? #B- which maximum length the prefix of this exception must be (/48, longer or shorter) ? These were my pence, feel free to comment ... gently, since I'm just back from vacations ;) +Bernard T. --- João Damas a écrit :
On 28 Apr 2010, at 01:32, Randy Bush wrote:
and how many years did it take to clean up the ripe docco on route flap dampening recommendations? Worse than that, there still are a significant subset of newcomers who switch on their favourite vendor recommended values for flap damping because they read old versions of their vendor documentation. :-(
moral of story: we need to be careful what we recommend
indeed!
i can see an isp refusing to route a multi-homed content site because ripe docco 666 says no prefix longer than /36.
that's why a number, any prefix length, would be wrong, imho and one should stick to the principles and give people an idea of costs of the options (to everyone). Basically create an atmosphere that makes normal people feel this is not a decision without impact.
Joao PS: do you want to have that RIPE doc # reserved in advance for this doc? ;)
Joao, On Wed, 2010-04-28 at 10:32 +0200, João Damas wrote:
i can see an isp refusing to route a multi-homed content site because ripe docco 666 says no prefix longer than /36.
that's why a number, any prefix length, would be wrong, imho and one should stick to the principles and give people an idea of costs of the options (to everyone). Basically create an atmosphere that makes normal people feel this is not a decision without impact.
Perhaps people should be encouraged to search recent routing-wg archives for latest discussions, or to ask the working group for recommendations if there are none that seem to apply? -- Shane
Shane, all,
Perhaps people should be encouraged to search recent routing-wg archives for latest discussions, or to ask the working group for recommendations if there are none that seem to apply?
Thanks for providing me with a link to fill in my interpretation of the discussion last Wednesday. :) The summary is that Philip and myself will scrap this document and work to revise RIPE-399 with more IPv6 examples and ensure use of routing registries is stressed. A slightly longer description (and I hope this matches what shows up in the minutes, but my memory isn't what it used to be) is that it would be foolhardy, and the document admits to the difficulties, to try and document any specific prefix-length based filter. Instead, the general principles of good aggregation should be stressed whilst admitting there are occasions that you may need to advertise longer prefixes. Existing filters of /32 may have to go the ways of IPv4 filters that were based on registry allocation sizes, but that is something that the network operator community will decide -- again, something that is already mentioned in the discussion part of the document. More discussion is of course welcome on the list. Rob -- Rob Evans JANET(UK) Development Team Twitter: https://twitter.com/JANETDev/team Work tweets: https://twitter.com/internetplumber JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
Dear all, At the moment the FIBs shown on route servers show /32 and /48 make up 85% of the routes. In terms of router processing efficiency are there specific prefix lengths that are "better" health-wise, e.g. should we encourage routes on 4/8/16-bit boundaries? Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Ltd M: 07795 840385 jamie.stallwood@imerja.com NIC: uk.imerja.JS7259-RIPE -----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net] On Behalf Of Rob Evans Sent: 10 May 2010 12:11 To: Shane Kerr; routing-wg@ripe.net Subject: Re: [routing-wg] IPv6 Routing Recommendations Shane, all,
Perhaps people should be encouraged to search recent routing-wg archives for latest discussions, or to ask the working group for recommendations if there are none that seem to apply?
Thanks for providing me with a link to fill in my interpretation of the discussion last Wednesday. :) The summary is that Philip and myself will scrap this document and work to revise RIPE-399 with more IPv6 examples and ensure use of routing registries is stressed. A slightly longer description (and I hope this matches what shows up in the minutes, but my memory isn't what it used to be) is that it would be foolhardy, and the document admits to the difficulties, to try and document any specific prefix-length based filter. Instead, the general principles of good aggregation should be stressed whilst admitting there are occasions that you may need to advertise longer prefixes. Existing filters of /32 may have to go the ways of IPv4 filters that were based on registry allocation sizes, but that is something that the network operator community will decide -- again, something that is already mentioned in the discussion part of the document. More discussion is of course welcome on the list. Rob -- Rob Evans JANET(UK) Development Team Twitter: https://twitter.com/JANETDev/team Work tweets: https://twitter.com/internetplumber JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated.
On Mon, May 10, 2010 at 12:20:22PM +0100, Jamie Stallwood wrote:
In terms of router processing efficiency are there specific prefix lengths that are "better" health-wise, e.g. should we encourage routes on 4/8/16-bit boundaries?
Surely not. I can remember lingo in the IPv6 spec that specifically advised vendors to NOT make any assumptions about specific prefix lengths and base performance optimizations on those. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Surely not. I can remember lingo in the IPv6 spec that specifically advised vendors to NOT make any assumptions about specific prefix lengths and base performance optimizations on those.
I remember that text. Do you think they listened? ;) Sander
participants (14)
-
Bernard Tuy -
Daniel Roesen -
David Freedman -
James A. T. Rice -
Jamie Stallwood -
João Damas -
Nick Hilliard -
Philip Smith -
Randy Bush -
Rob Evans -
Sander Steffann -
Shane Kerr -
Vince Fuller -
Wilfried Woeber, UniVie/ACOnet