- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by Hamed Shafaghi 05 May '11

05 May '11

I agree with this proposal. Best Regards -- I Hamed Shafaghi I I Managing Director I I Skydsl® Telecom I hamed(a)skydsl.ir I www.skydsl.ir I

1 0

RE: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by melchior.aelmans＠kpn.com 05 May '11

05 May '11

Dear Emilio, We support this proposal from Erik and Jordi. Thanks and regards, Melchior Aelmans KPN Mobile CARE Continuity Core Data From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Emilio Madaio Sent: Friday, April 15, 2011 11:23 AM To: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Dear Colleagues, A proposed change to the RIPE Document ripe-512,"IPv6 Address Allocation and Assignment Policy", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-02 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 05 May '11

05 May '11

On 05/04/2011 11:55 AM, poty(a)iiat.ru wrote: > Why then you should apply for PI? In case of problems RIPE (for example) would speak with a single LIR, not with thousands of widespread customers. RIPE is always speaking with the LIR, in accordance to 2007-01 policy. All new PI users are always connected with some LIR. If you want obtain PI directly from RIPE, you'll pay additional money for the contract with RIPE, it's documented on the website. ----------------- Yes, but it means that RIPE is not always "speak" exclusively with LIRs. More than that, the "customer" has rights to change the hosting LIR in every moment. It further complicates things. //////////// And generally, I don't prefer crapping PA space with such deaggregation caused just by the PI-blocking policy. ----------------- It was my idea behind the lines. Most Internet players are not so bad to do illegal and harmful things. It's not only money matters.

1 0

Removal of multihomed requirement for IPv6 PI
by Kovac, Pavol 04 May '11

04 May '11

Hi, what is the current status for this topic ? Best regards _____________________________________ Pavol Kovac

2 2

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

On 05/04/2011 10:25 AM, poty(a)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.

3 3

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

On 05/04/2011 11:06 AM, poty(a)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... ----------------- Both "sides" doesn't have arguments and reasons, just predictions. PI in IPv4 was a long developed decision, with a lot of restrictions from the beginning, several tuning across its life. So IPv6 PIs will not have the same curve definitely. You have ignored all other my arguments. \\\\\\\\\\\\\\\\\\\\\\\\\\\\ On 05/04/2011 11:10 AM, poty(a)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(a)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. ------------------------- To HAVE the interface doesn't mean to USE it fully. Routing 8Gbps on a PC is unrealistic definitely, even in theory. Many people (try to) pass the desirable for reality. You can certainly incorporate some hardware port accelerators in a PC, additional interfaces, make a cluster... But it seems it would be not cheap at first and claim a competence which small ISPs can't afford at second. It is not a cheap PC with common OS we are speaking about. ///////////////////////////////// > 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)... ------------------- If it is so easy - use it! Why then you should apply for PI? In case of problems RIPE (for example) would speak with a single LIR, not with thousands of widespread customers. Regards, Vladislav

2 1

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

> Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. Don't worry about computing power, small ISPs usually are less than 200Mbit/s total upstreams, to even if they handle 1G with today's CPUs it is not a big deal (rather stability can be a problem). More, probably within 1-2 years there will be a set of drivers/kernel support of handling packets by high efficients processors from... graphics ;) ------------------ I'm waiting for the event some 10 years by now. Until now it is only bad predictions. Even at 200Mbit|s with 2 upstreams it is almost impossible to deal with full table. Regards, Vladislav Potapov IIAT, Ltd.

1 0

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

Hay, Am 03.05.2011 um 15:37 schrieb <poty(a)iiat.ru> <poty(a)iiat.ru>: >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Sascha Lenz [SLZ-RIPE] ---------------------- Small companies start with small routers, PC based Linux Quagga Boxes, or Routerboards, or Juniper J-Series or whatever - not really much costs here (see other replies). -------------- They will not be able to "start with small routers", because calculating constantly changing routes (presumable from several sources) costs processing power, routing decisions with huge routing table cost processing power, even receiving and sending plain packets costs processing power. And all this costs money. PC-based routers are not able to do all of this at once and in this anount. The "selfish" small ISPs could easily drive himself into trap of trouble when they have to spent much more money for equipment (and made all others do it) rather than using PA from LIR.

3 2

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

[...] > Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. > > do you have any numbers on that? because i don't see it. Even my old Pentium4 route servers do very nicely with that. --------------------- With what? My company is very small and even currently used hardware routers can't handle 3-4 (1Gbit|sec) upstream connections efficiently (doing BGP in addition of course). 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. > Sascha Lenz [SLZ-RIPE] ------------------------ And look at the processing power of the Route Engines of the hardware routers... wow are they slow! ------------------------ 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. The widespread PI will definitely adds significant amount to the number of routes, so your forwarding problem will be much worse. Regards, Vladislav Potapov IIAT, Ltd. P.S. Sorry for some earlier messages without signature.

2 1

getting second IPv6 PA as a LIR
by Marcin Kuczera 04 May '11

04 May '11

hello, Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ? The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers. However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes. For SponsorLIR agreement customers - little ISPs, willing to advertise their i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA (not advertised as whole by LIRs ASes) would be great... Regards, Marcin

18 60