I am curious if your implementation of bgp will be one core per bgp session or if it will truly be multi-threaded with one bgp session using multiple cores.

All I can say is tht it will not be multithreaded. AFAIK none of currently existing implementations are fully multithreaded.

So what is the BGP improvement on v7.0?

Load distribution between cores can be done without multithreading.
https://www.youtube.com/watch?v=NbfKplzda7I

Load distribution between cores can be done without multithreading.
https://www.youtube.com/watch?v=NbfKplzda7I

Yes, I have seen that video. It appeared to me that it was one core per session which will help but with the growing routing tables sizes I think it would be a game changer to have multi-threaded BGP because of improved convergence time. My CCR1036-12G-4S with one session to another provider using a Juniper MX80 takes about 3 minutes to converge 808,000 routes. When I was lucky enough watch his routers converge down in our local IX the convergence times were happening in under 15 seconds. I know that I'm not spending Juniper money on my CloudCore here but I think it would definitely give Mikrotik a very competitive advantage to have this functionality. I understand that your development for BGP is completely in-house and with this pandemic going on a lot of things have been delayed. To what extent I am not sure. I am more curious if you think that it is possible based on other research I have posted below to have this functionality in the future if not in ROS7 then later in the development cycle. I am hoping that just having 1 cpu per session will at least enable me to share full BGP tables between my core routers so I can blend all my connections fully without routers locking up as that is what happened in the past when trying this. I know there are x86 options to get around the CloudCore limitations I would just prefer to use the full power available in the CloudCore platfor if possible. Thank you for taking the time to look at this and take community feedback.

https://www.semanticscholar.org/paper/A ... 27f0d22f69
https://www.researchgate.net/publicatio ... ion_Router
https://www.quora.com/What-is-multi-thread-BGP-access

What about if you have more than two or tree full table BGP peers ?

For example :
> ip route print count-only
5127833

> ipv6 route print count-only
338525

Quagga based linux server can manage route changes real time without any problem. CCR1036-8G-2S+ needs 1/2 hour to process changes at just one peer...

Whole BGP processing must be multi-tread with no doubt.

p.s. not talking about something elementary as to get basic routing info needed on daily base:
>ip route print detail where 8.8.8.8 in dst-address
answer about a hour....

The time needed to download the routing table is quite fast already. The huge problem is that it takes 20 minutes or so to install the routes (and make them active). It seems that the process that executes this task is always only one.

It might be possible in v7 right now to use /routing/fantasy to load up a routing table with enough fictitious routes to simulate multiple full BGP tables and then check to see how long it takes to perform operations on those routes. At least I suspect that is what /routing/fantasy is meant for - a fake dynamic routing protocol designed to load randomized routes into the routing table to facilitate load and performance testing.

Yup, I figured out routing fantasy - that's exactly what it does.

I don't fully understand the syntax, but:

/routing fantasy
add comment=test count=1000 dealer-id=1000 dst-address=12.0.0.0/8 gateway=192.168.88.1 instance-id=1 name=fantasy-test prefix-length=32 \
priv-offs=1000 priv-size=100 seed=mducharme use-hold=no

creates 1000 random /32 routes within 12.0.0.0/8 all of which have gateway 192.168.88.1

Here is exactly how Juniper does it. It's definitely parallel execution of BGP route processing. I have "no dog in this fight" but as a developer I always lean towards "nothing is impossible".

https://www.juniper.net/documentation/e ... arding.pdf

I know it's not a simple checkbox and magic happens and there's multi-threadded BGP, but someone has figured out the logistics and thread control algorithm (Juniper), and I presume it's not novel enough to be patented, so it's possible to just implement the same type of algorithm on the Mikrotik hardware (given enough time, interest, and investment).

I read the "Run to completion" argument, and it's not really something that applies because you ARE running to completion, you are just running it on several cpu's at the same time and the main "thread" will wait for this to complete. Does it matter if route 887,123 gets processed before route 123? I don't know, but it seems Juniper has figured out how to deal with it, so it's not "impossible"