[quagga-dev 11566] Re: [PATCH] BGP: add aspath_aggregate_mpath that preserves path length

Daniel Walton dwalton at cumulusnetworks.com
Wed Oct 8 15:09:22 BST 2014

Look for DW# inline... 

-----Original Message----- 
From: "Paul Jakma" <paul at jakma.org> 
To: "Boian Bonev" <bbonev at ipacct.com> 
Cc: "Daniel Walton" <dwalton at cumulusnetworks.com>, "David Lamparter" <equinox at opensourcerouting.org>, "Quagga Devel" <quagga-dev at lists.quagga.net> 
Sent: Tuesday, October 7, 2014 10:54:54 AM 
Subject: Re: [quagga-dev 11449] Re: [PATCH] BGP: add aspath_aggregate_mpath that preserves path length 

Hi Boian, 

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 ( 
> http://patchwork.quagga.net/patch/417/). 
> 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. 


Some background: 

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. 

DW# The ID doesn't matter as long as it is unique...no ID coordination is required between two add-path capable speakers. 
The ID is just there to make a NLRI unique so that advertising an additional NLRI doesn't implicitly withdraw the previous advertisement. 

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. 

DW# Cisco has it in ios and ios-xr, not sure about nx-OS. Juniper has it. I've done RX support in quagga (will post the patch soon). TX support in quagga is on our todo list. 

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? 

DW# addpath is pretty stable at this point, hopefully the next draft will be the last. It has been a very long process though, I submitted the first copy of the draft 12 years ago. I have the revised text, just need to sit down and submit it. 


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 
(Andrew Tanenbaum) 

More information about the Quagga-dev mailing list