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

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 66

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

04 May '11

-----Original Message----- From: Martin Millnert [mailto:millnert@gmail.com] Sent: Tuesday, May 03, 2011 6:23 PM To: Potapov Vladislav Cc: slz(a)baycix.de; address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] getting second IPv6 PA as a LIR On Tue, May 3, 2011 at 9:37 AM, <poty(a)iiat.ru> wrote: >>> 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... Not really; normal PC RAM is pretty cheap. 16GB ECC/REG ~400 EUR. /M -------- It's not about storing, it's all about using. And here we get to the problem.

1 0

help
by Kovac, Pavol 03 May '11

03 May '11

Dear RIPE wg, I would like to ask you about present proposal "Removal of Multihomed requirement for IPv6 PI" version 1.0 12 April 2011. I see Current Phase Ends: 13 May 2011. What will happened after 13rd May ? I registered as a subscriber of this mailing list. Will I receive any info about changes on this proposal ? Thank you Pavol Kovac

2 1

Re: [address-policy-wg] 2008-08 (Initial Certification Policy
by Sascha Luck 03 May '11

03 May '11

Hi ap-wg, I do NOT support this proposal for the very same reasons that Malcolm so eruditely laid out in his post. All that's left for me is to state that, in this case, the cure is infinitely worse than the disease. Kind Regards, Sascha Luck

1 0

2006-05 New Draft Document Published (PI Assignment Size)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

10 16

2008-08 Last Call for Comments (Initial Certification Policy in the RIPE NCC Service Region)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, The proposal described in 2008-08 is now at its Concluding Phase, as per decision of the Address Policy WG Chairs. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 24 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-01 Discussion Period extended until 19 May 2011 (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, The Discussion Period for the global policy proposal 2011-01 has been extended, in agreement with the proposer, until 19 May 2011. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1