RE: [address-policy-wg] getting second IPv6 PA as a LIR
On 05/04/2011 10:25 AM, poty@iiat.ru wrote:
When we add several hundred thousands IPV6 routes we are going to extremely upgrades our infrastructure, but smaller ISP (business...) which can't pay $100/month will not be able to do so definitely.
You know - they are different. :) Mostly they have distributed computing environment and hardware programmed to do specific operations, huge backbones and many-many other things which PC lacks.
Not really. BGP table calculation isn't distributed (you need single place for this calculation final table). If we imagine your hundred thousands IPV6 routes scenario, CPU on these "hardware" routers will have troubles, too. --------------- I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too. But BGP table calculation is only one process in the router. As Sascha Lenz have pointed out - the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact. ///////////////////////////
The widespread PI will definitely adds significant amount to the number of routes, so your forwarding problem will be much worse.
Deaggregation of PA address space causes similar problems and nobody really can do anything with this. And routers aren't making difference between PI and PA. Look into IPv4 routing table, what mess is here caused not by PI assignments, but by announced /24 from aggregatable /20, /19, from PA blocks... same thing is already happening in IPv6, where're more specifics than /32 announced from PA blocks. With blocking PI you cause only one thing - people will start deaggregation of PA space more widely. And any kind of (RIPE) policy cannot forbid this. For each restriction in RIPE policy people discover some policy-conforming workaround... PI vs PA separation is just administrative thing for RIPE NCC evidence. It's impossible to force network operators filter some prefixes, just because prefix is deaggregated. You can filter in your own network, but probably nobody will filter his paying customer - money are on the first place... --------------------- While I could agree with you in some point I cannot agree fully. We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs). On the other hand: if the problem arises in the future the more organized (and less in numbers) LIRs can come to agreement easier than much more "independent" crowd of PI-holders which are even now deaf to any arguments, just claiming "independence" for any cost. Of course some "clever people" will break the rules in some "smart" ways, but I don't think it would be so widespread comparing to the "get as much as you want for free" paradigm. Regards, Vladislav Potapov IIAT, Ltd.
On 05/04/2011 11:06 AM, poty@iiat.ru wrote:
I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too.
I don't expect any huge explosion. Reasons was described already in the list. Growth will copy current IPv4 curve... On 05/04/2011 11:10 AM, poty@iiat.ru wrote:
Even at 200Mbit|s with 2 upstreams it is almost impossible to deal with full table. On 05/04/2011 11:06 AM, poty@iiat.ru wrote: the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact.
With proper hardware not really. It's not a problem handle 10Gbps interface on PC these days. And I know about real deployment, where PC is used for routing >8Gbps of traffic.
We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs).
Minimum PI assignment in IPv6 is /48 - see RIPE 512. Also assigned anycasts in IPv6 are /48 - i expect, that /48 for IPv6 becames similar well-know minimum rule as /24 in IPv4 world. There're legal operational /48 assignments these days - for anycasted TLD-DNS, for example. And /48 can be assigned from /32 PA easily, there's lot of space available. And then easily announced into the BGP and almost nobody will filter it (see current IPv6 table)... Daniel
On Wed, 4 May 2011, Daniel Suchy wrote:
And /48 can be assigned from /32 PA easily, there's lot of space available. And then easily announced into the BGP and almost nobody will filter it (see current IPv6 table)...
Currently, yes. Long-term, no. There are plenty of ISPs who do not filter on /24 IPv4 either, but a lot do. I expect in a few years that most will filter on /32 for PA space and /48 for PI space. The only reason it's not done today is that people haven't made it a priority because there are so few IPv6 routes. So advising subnetting /32 further and announcing them in the DFZ might work short-term, but you do it at your own risk long-term. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 05/04/2011 12:21 PM, Mikael Abrahamsson wrote:
Currently, yes. Long-term, no. There are plenty of ISPs who do not filter on /24 IPv4 either, but a lot do. I expect in a few years that most will filter on /32 for PA space and /48 for PI space. The only reason it's not done today is that people haven't made it a priority because there are so few IPv6 routes.
Similar thing can be done on IPv4 these days. You can filter on PA minimal assignments to LIRs too - RIRs in general documents that and public examples of these filters are also available. But this expect, that you'll mantain this kind of filter - this is nothing like setup & forget. If network operators aren't filtering routing mess in IPv4 (even they can), they generally will not magically change their mind for IPv6. Filtering in IPv4 isn't happening, even you can reduce table by ~40% of prefixes - and this is not small number within >350000 IPv4 prefixes announced. Transit customers also expect this number on their peers, if you reduce your table in such manner, they'll complain to you, because your competitor will not filter and they expect similar number of prefixes on both their transit peers...
So advising subnetting /32 further and announcing them in the DFZ might work short-term, but you do it at your own risk long-term.
I'm not advising that. I'm just talking about something I already see in the global routing table. Deaggregation is a risk in both IPv4 and IPv6. Hohever, deaggregation works, in both worlds... And we cannot change minds of the operators by any policy. Keep in mind, that not so many comercial ISPs are involved in these policy discussions. They'll just setup their networks in accordance to customer needs, regardless of the policy made here. Daniel
participants (3)
-
Daniel Suchy -
Mikael Abrahamsson -
poty＠iiat.ru