Hi. I recently read an interesting research paper that I don’t think has been shared here yet: https://www.usenix.org/system/files/usenixsecurity25-stoeger.pdf I would throw out two additional thoughts related to "Partial Mitigations"(6.1): 1. Usage of modern, multi-threaded routing daemons which are able to take advantage of multi-core control plane CPUs. 2. Control plane CPU usage monitoring. BGP per-neighbor sent and received UPDATE messages rate monitoring. For example, Junos supports this via SNMP, telemetry or RPC. In the "Safe BGP Communities"(6.2) paragraph the paper advises networks to cease the support of "Lower Local Pref Below Peer" community. As the BGP vortex forms only when both the "Lower Local Pref Below Peer" and "Selective NOPEER" communities are present, then perhaps alternative approach would be to cease the support of those two communities together. In other words, both communities would still be allowed separately, but not together. I did a brief analysis on RIPE RIS data for NTT, GTT and Sparkle "Lower Local Pref Below Peer" and "Selective NOPEER" type communities and the combination where both types are attached to the prefix are rare. Finally, I wonder if or how much the attack is amplified if the adversary ensures(for example, using communities) that each announced prefix has unique path attributes and thus there is an UPDATE message per prefix. Martin