On Thu, 22 Oct 2015, Chris Hall wrote:
Add-Path should deal with the per-client selection cost... but complicates the tracking of outbound routes (of course). Unless, that is, there is a limit on the number of outbound routes (for a given prefix) that a given client will accept -- in which case Add-Path appears to suddenly makes things even harder :-(
Add-Path tries to shoe-horn flooding semantics into UPDATE messages, while (last time I read the draft at least) deliberately leaving crucial parts of the flooding semantics undefined and application specific.
I'd be tempted to just create an extension to Quagga: a new BGP flooding message with simple, clear semantics to do just that. Messages identified by (originator ID, instance ID, sequence number). On receipt, flood to all neighbours. Keep a cache of the identifier for pruning duplicates out (no need to store all the messages).
You can then create contiguous flooding domains - a 'fabric' between speakers. Speakers can then originate their own UPDATEs into this fabric, and UPDATEs 'external' to the fabric, and they'll flood around. Every member of the fabric will automatically get a full view of the UPDATEs, as if they were fully meshed. However, the UPDATEs can be 'classic' UPDATEs and processed as such into the LocRIB - no need to hack UPDATE to bits.
You can build route-servers on that fabric and scale out the load of maintaining per-client/group-RIBs. Solves oscillation problems too (least, due to partial views).
You could use it to flood other info too (flooding is the most robust and fastest way to get data around - at the cost of O(# links) of messages of course, but BGP can be much worse at message efficiency, so..).
regards, -- Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A Fortune: A reverend wanted to telephone another reverend. He told the operator, "This is a parson to parson call." _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
