On Fri, Oct 23, 2015 at 4:57 AM, Paul Jakma <[email protected]> wrote: > 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 have to disagree with you here. AddPath simply provides an encoding mechanism that allows you to send more than one path for a prefix. What additional paths are TXed (ie the flooding mechanism) is up to the BGP feature that is using addpath. This was very much intentional as the details of the features that use addpath should be done via separate standards documents.
> 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. > They aren't classic updates though, you've added (originator ID, instance ID, sequence number) to create a unique identifier to avoid the implicit withdraw problem. This is the same thing addpath does, it just encodes the unique ID as part of the NLRI so as to not kill update packing efficiency. Daniel
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
