[members-discuss] RIPE NCC Charging Scheme 2025 Open House: Recording and Slides Available

Yes, by all means. Let's stop all research and development globally, 
because we already know every possible further development will fail 
because of previous failures, therefore any attempts for further 
development on anything would be futile and fruitless.

-- That logic does not compute, sorry.

Do you know how many attempts Edison had to do to make the first light 
bulb? Maybe he should've just stopped after a couple of attempts and 
deem it impossible?

Just because prior proposals/methods/ideas didn't work, doesn't mean a 
new one wouldn't or that all avenues have been explored.
Like i stated earlier, all the prior proposals i have seen are 
convoluted and complicated, mixing up things that don't belong there.


So what's the complete unworkable thing on this?
It requires zero network upgrades, only end points need to understand 
this. Therefore, adept coder makes a patch, it gets included in Linux 
kernel after a while of testing, and just couple years down the line you 
have what 90-95% of servers supporting it already?

Please by all means, show how this would not work.
I am curious as to why?


Br,
  Aleksi
  Magna Capax Finland Oy

On 01/04/2024 16.38, Q Misell wrote:
> >  "IPv4e" -- You probably missed the point about it not needing 
> hardwareupdates initially at all?
>
> Can we please stop discussing upgrades to IPv4. Every single 
> suggestion that anyone has presented in recent years has been proven 
> entirely unworkable.
> It's not worth even discussing them at this point.
> ------------------------------------------------------------------------
>
> Any statements contained in this email are personal to the author and 
> are not necessarily the statements of the company unless specifically 
> stated. AS207960 Cyfyngedig, having a registered office at 13 
> Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca 
> Digital, is a company registered in Wales under № 12417574 
> <https://e.as207960.net/w4bdyj/LMqmSZRX>, LEI 875500FXNCJPAPF3PD10. 
> ICO register №: ZA782876 <https://e.as207960.net/w4bdyj/AmZwGXyq>. UK 
> VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. 
> South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a 
> registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, 
> Lossi tn 1, 46001, trading as Glauca Digital, is a company registered 
> in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca 
> Digital and the Glauca logo are registered trademarks in the UK, under 
> № UK00003718474 and № UK00003718468, respectively.
>
>
>
> On Mon, 1 Apr 2024 at 13:54, Aleksi <aleksi at magnacapax.fi> wrote:
>
>     Hi,
>
>       "IPv4e" -- You probably missed the point about it not needing
>     hardware
>     updates initially at all?
>     Only software. Routing etc. would all remain identical, those
>     extra bits
>     would be in the packet header and only end points need to understand
>     those headers.
>
>     52% is not sufficient IPv6 connectivity, even 100% would not be -- It
>     needs to match or exceed IPv4 performance. ie. routing has to be
>     better.
>     Unfortunately, due to design, i don't think that's feasible ever
>     either
>     because the routing tables will grow exponentially larger than IPv4.
>     Right now, IPv6 route is often weaker than IPv4 to my experience.
>
>     IPv6 OpEx is much higher than IPv4, to our experience as well.
>     It's not
>     even a competition.
>
>     Br,
>       Aleksi
>       Magna Capax Finland Oy
>
>
>     On 01/04/2024 15.37, ivaylo wrote:
>     >
>     > The subject of this discussion go a lot ofside. I dont know why you
>     > bloat the theme (maybe it is intensionly ?) leading it to IPV4
>     > holding. Our main focus _SHOULD_ be RIPE budget and financing +
>     > sustainabla operation in the next year and in the future at all.
>     This
>     > of course is related with the members fee.
>     >
>     > I done a little research and calculations, to tune my initial
>     > propousal so: By IANA public documents current delegated
>     resources to
>     > RIPE are:
>     >
>     > 86016     IPV4 /19 blocks
>     > 66624     IPV6 /27 blocks
>     > 42882     ASN
>     >
>     > If we have a hard coded limits for each LIR, equal steps up, and
>     > member fee of 750 EURO per year, each LIR can hold up to:
>     >
>     > 1 x /19 IPV4 BLOCK (sumary = 32 x /24 networks)
>     > 1 x /27 IPV6 BLOCK (sumary = 32 x /32 networks)
>     > 16 ASN numbers
>     >
>     > After pass one of the above parameters even with one /24 IPV4, /32
>     > IPV6, or ASN, +750 euro (1500 euro RIPE fee) up to the next
>     > proporcional limit:
>     >
>     > 2 x /19 IPV4 BLOCK (sumary = 64 x /24 networks)
>     > 2 x /27 IPV6 BLOCK (sumary = 64 x /32 networks)
>     > 32 ASN numbers
>     >
>     > and so on...
>     >
>     > This will generate 64 512 000 euros annual budget for RIPE which is
>     > absolutely enough for normal operations in each of the next 10
>     years,
>     > without need to increse members fee each year.
>     >
>     > If somebody is afraid, that other RIRs will not keep going with
>     RIPE
>     > fees, and there will be posibly leave of the big resource holders,
>     > keep in mind that all small members from the other RIRs will
>     move to
>     > RIPE. Also good luck moving to ARIN db mess, the risk to lost
>     route of
>     > your prefixes is nearly 90%.
>     >
>     > ----------
>     > Off topic: About IPV4/IPV6 resources, it is imposible to create
>     kind
>     > of ipv4 adress space extension. Many hardware do lookup over the ip
>     > header, it is not only software related. Even somebody develope a
>     > public standart about that, will take decades before all replacing
>     > equipment all over the world and another decades all to be
>     workable.
>     > We have working IPV6, right now more than 52% has IPV6
>     connectivity.
>     > Biggest EU access operator already
>     > give dual stack IPV4/IPV6 even to their end users, and activlly
>     deploy
>     > IPV6 stack into their networks. It is much more cheaper in long
>     > perspective than to buy/rent IPV4 (NAT/proxy your clients/services
>     > over IPV4 and give them IPV6 real addresses). After 2-3 years
>     the core
>     > of the Internet will be over IPV6, yes we will need to support IPV4
>     > for the next 10-15 years to provide backward connectivity, but
>     it is a
>     > dead end. All who thinks they will do a big profit from IPV4
>     adresses
>     > they hold, do seriously mistake in their logic, but anyway it is
>     their
>     > problem. Those who dont implement IPV6 because "yay it is so
>     scary and
>     > not working" in one moment will have to do this fast without
>     > experience, because will have seroius troubles with IPV4
>     connectivity.
>     >
>     >
>     >
>     >
>     > Ivaylo Josifov
>     > VarnaIX / Varteh LTD
>     > +359 52 969393
>     > Varna, Bulgaria
>     >
>     > _______________________________________________
>     > members-discuss mailing list
>     > members-discuss at ripe.net
>     > https://mailman.ripe.net/
>     <https://e.as207960.net/w4bdyj/JqounabO>
>     > Unsubscribe:
>     >
>     https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi
>     <https://e.as207960.net/w4bdyj/bXMhzevz>
>
>     _______________________________________________
>     members-discuss mailing list
>     members-discuss at ripe.net
>     https://mailman.ripe.net/
>     <https://e.as207960.net/w4bdyj/Z54J0XCc>
>     Unsubscribe:
>     https://lists.ripe.net/mailman/options/members-discuss/q%40as207960.net
>     <https://e.as207960.net/w4bdyj/koxbybwf>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20240404/1e84e759/attachment.html>