[quagga-dev 11559] Re: [PATCH] BGP: add aspath_aggregate_mpath that preserves path length
paul at jakma.org
Tue Oct 7 15:54:54 BST 2014
On Wed, 20 Aug 2014, Boian Bonev wrote:
> Hi Daniel,
> This change is only relevant when "bgp bestpath as-path multipath-relax"
> is active; else it behaves exactly like the old code.
> The idea have been proposed long ago by Paul Jakma (
> The RFC describes path aggregation in terms of few constraints and this
> way does not violate them. The current way of creating aggregate path
> may produce shorter path (in case of multipath-relax) which violates the
> length constraint from the RFC. See the example in the commit message.
I find it interesting you're working on this. I'm wondering why you're
looking at this, what problems you've had and why you're going with this
ahead of, e.g., Add-Path.
I did some work on a BGP ECMP multipath draft with Manav Bhatia and Joel
Halpern, which took the approach of providing an extended NEXT_HOP
attribute, along with specifying how multiple UPDATEs could carry and
withdraw an ECMP route. See
For interoperation with non-ECMP capable peers, we specified how to
combine AS_PATHs using AS_SETs to allow an ECMP route to be advertise to a
non-ECMP-capble peer, such that the the length and ASN information (though
obv not the exact sequence) across all the constituent routes of the ECMP
route could still be passed onto the ECMP peer.
With respect to how to advertise ECMP routes, IDR went with a different
approach, the "Add-Path" approach, that left internal UPDATE semantics
mostly unchanged, instead adding an opaque identifier to the NLRI to allow
multiple UPDATEs to be considered as a collective set of paths for an
The base IDR proposal unfortunately didn't cover some key details, like
how to choose this identifier, or what constitutes a group of paths that
can be advertised together. Details that are critical to interoperability.
It also didn't consider how this extension might work once non-ADD_PATH
peers are involved.
This choice was I think deliberate, as I think the intention was that
Add-Path would be a bit of a swiss-army knife and cover any use-case for
advertising groups of paths. The bhatia draft was more focused on solving
ECMP (and hence RR-route-oscilllations) in a simple and interoperable way,
while still being applicable to route-server use (these are the 2 most
important use cases, perhaps the only notable ones).
I'm not sure what state things are in now on ECMP and multiple-paths in
BGP. I havn't kept up with things the last few years.
I see there is a longer guidelines draft now. At a glance it still looks a
bit complicated, and it still doesn't look like it's easy for any two
Add-Path supporting implementations to be able to tell if they actually
are interoperable (?). There have also been academic studies on how to
best choose Add-Path identifiers I think. I don't know what deployment
Add-Path has to date either - as I havn't followed.
Interestingly, I still don't see either of the Add-Path drafts addressing
how to advertise an ECMP route to non-Add-Path peers in a way that
preserves AS_PATH properties such that routing loops are avoided.
It's worth noting that IDR has also deprecated the aggregation features in
BGP, including AS_SET. If AS_PATH combination using AS_SET is needed for
ECMP-non-ECMP interoperability, then such deprecation is problematic.
However, I couldn't get IDR to see merit in that point.
So, what's interesting here is that people, such as yourself, as still
working on BGP multi-path, apparently outside of Add-Path. I'm curious
why that is? I know a few years ago there were issues still to be worked
out with Add-Path, and I'm curious if these are still at play?
What are those issues? Do we need to go back to IDR and try work those
out? Is it just Add-Path interoperability that needs to be fixed (e.g.
adding capabilities)? ??
I think there at least one of the 2 Add-Path draft's authors might be
active on this list too (even Cc'ed ;) ), if they know. ?
It's kind of sad that, more than 10 years since Manav's draft, and 6 odd
since the Add-Path, that it seems there still isn't any (AFAIK) easy,
interoperable solution to solve the iBGP route-reflector oscillation
problems, or eBGP route-server scaling issues.
I'd be happy to get stuck in to help with fixing that.
Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A
Linux is obsolete
More information about the Quagga-dev