at the last mum someone said the next release will be v8 ; )

The next release will be 7. 8 can come just after that. And 9 then... So what?

The release dates will be Q2/Q3 20xx, approximately.

Don't worry, it will be real soon now...

does the number really matter?

does the number really matter?

Right, the number doesn't matter...
the date could matter....

Davide

I guess you are waiting for some specific feature, not the number or the date.

I guess you are waiting for some specific feature, not the number or the date.

multi-threaded bgp seems to be at the top of the list...

Fix for muticore packet reordering comes to mind, if this isn't already silently fixed.
I didn't have the motivation of retesting this since a few months. Last time I stumbled upon this(6.34 I think) I disabled one core of the RB850Gx2 under test.
Im referring to viewtopic.php?t=102252 where someone tripped over this with IPTV and was put off to v7 and "maybe"

I guess you are waiting for some specific feature, not the number or the date.

multi-threaded bgp seems to be at the top of the list...

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..

does the number really matter?

number no longer relevant since free lifetime upgrade

Right. But they don't run bgp and ospf and fib updates and filtering and xxxxxxx under the same process. That's why a dual core major brand router can handle several hundred peers with convergence times 5x faster than 2 peers on a mikrotik.

I guess you are waiting for some specific feature, not the number or the date.

multi-threaded bgp seems to be at the top of the list...

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..

does the number really matter?

No at all, as much as ROS and SWOS get more improvements and more features thats matter, just a suggestion its a time to add one important feature, let's encrypt, its now necessary for https, ikev2, sstp, ... hope see it in next RC release.

Thanks.

we should stop to annoy normis, I guess he hates openvpn and udp since to many poke for it.

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..

Juniper to my understanding now has multithreaded quite a bit starting with JUNOS 15. JUNOS 16 and past that are apparently introducing a multithreaded RPD as well. Now I do not know if the BGP portion within RPD is multithreaded but I was under the understanding that on JUNOS 17 that it's basically going to be a complete out and about rewrite of the entire routing stack to be more scalable and threaded. Granted this is what I was told in behind closed doors from Juniper so....not sure of the time frames.

That being said, I agree completely with you that it's incredibly difficult and generally not really all that worth it to do it at a super in depth level. Intra-process multithreading is too much in most cases and the benefit is very small most of the time. Unless the work is embarrassingly parallel, it's generally not that worth it.

Here's a link giving an outline:

https://books.google.com/books?id=SVvnD ... gp&f=false

I guess you are waiting for some specific feature, not the number or the date.

multi-threaded bgp seems to be at the top of the list...

+1000

does the number really matter?

Only bugs really matters. Finish and polish existing features - this will be the best way.

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..

Juniper to my understanding now has multithreaded quite a bit starting with JUNOS 15. JUNOS 16 and past that are apparently introducing a multithreaded RPD as well. Now I do not know if the BGP portion within RPD is multithreaded but I was under the understanding that on JUNOS 17 that it's basically going to be a complete out and about rewrite of the entire routing stack to be more scalable and threaded. Granted this is what I was told in behind closed doors from Juniper so....not sure of the time frames.

That being said, I agree completely with you that it's incredibly difficult and generally not really all that worth it to do it at a super in depth level. Intra-process multithreading is too much in most cases and the benefit is very small most of the time. Unless the work is embarrassingly parallel, it's generally not that worth it.

Here's a link giving an outline:

https://books.google.com/books?id=SVvnD ... gp&f=false

Multi-threaded BGP might be hard, but it's necessary; and, here's the thing: it's already a solved problem. I'm using this in production: https://github.com/osrg/gobgp.

• I've verified it's multi-threaded.
• Takes about 1GB for full Internet BGP table
• Has lots of kick-ass modern features
• Built for SDN from the ground up

1GB for just one BGP feed that's a lot.

1GB for just one BGP feed that's a lot.

I agree, that is a lot.

1GB for just one BGP feed that's a lot.

Just wait till you see some of the L3VPN/L2VPN NLRI on a service provider on a route reflector. It's far more than that.....

1GB for just one BGP feed that's a lot.

Just wait till you see some of the L3VPN/L2VPN NLRI on a service provider on a route reflector. It's far more than that.....

Full table doesn't fit in 1GB anymore.

BGP != Forwarding. BGP is a routing protocol.

Multi-threaded BGP is hard, really hard. Juniper do not do it, Cisco IOS/IOS-XE do not do it. Processing the prefixes against all the filters, accross multiple cores and coming out with a result "in order" is very complex.

This is purely speculation, but it is more likely that Mikrotik will run BGP multi-threaded, with a thread per peer and/or per instance. This means processing of route updates for a peer would happen on a single core to maintain order, and that the post-processed routes would then be sent to another process that handles the RIB/FIB for that instance.

Outside of these improvement, there are likely to be big improvements in processing speed and the way the RIB's/FIB are stored in memory.

Mikrotik already discussed early results of the improvements that are coming, around 10x improvement in processing speed. See https://www.youtube.com/watch?v=ML0tr-9zTw0 at 2:57 mark..

Juniper to my understanding now has multithreaded quite a bit starting with JUNOS 15. JUNOS 16 and past that are apparently introducing a multithreaded RPD as well. Now I do not know if the BGP portion within RPD is multithreaded but I was under the understanding that on JUNOS 17 that it's basically going to be a complete out and about rewrite of the entire routing stack to be more scalable and threaded. Granted this is what I was told in behind closed doors from Juniper so....not sure of the time frames.

That being said, I agree completely with you that it's incredibly difficult and generally not really all that worth it to do it at a super in depth level. Intra-process multithreading is too much in most cases and the benefit is very small most of the time. Unless the work is embarrassingly parallel, it's generally not that worth it.

Here's a link giving an outline:

https://books.google.com/books?id=SVvnD ... gp&f=false

Multi-threaded BGP might be hard, but it's necessary; and, here's the thing: it's already a solved problem. I'm using this in production: https://github.com/osrg/gobgp.

• I've verified it's multi-threaded.
• Takes about 1GB for full Internet BGP table
• Has lots of kick-ass modern features
• Built for SDN from the ground up

+1 for GoBGP. How expensive is RAM today? I dont think it matter for a router that must handle full BGP tables.