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

Paul Jakma paul at jakma.org
Tue Oct 21 10:09:26 BST 2014

Hi Daniel,

Interesting info, thanks :)

On Tue, 14 Oct 2014, Daniel Walton wrote:

> The selection mechanism I think could have interoperability / routing
> consistency issues I think. I'm curious why there isn't some
> capabilities defined to explicitly signal which path-grouping selection
> mechanism is used?

So this is mine but wasn't reply-quoted, and I'd used confusing language 
here. I meant which mechanism is used to select the set of paths to 
advertise. Those paths then each have to have a distinct Add-Path ID, of 

Just to clarify, as I used "grouping" again later. Doh.

> [snip v useful features
> note: solving RR induced iBGP oscillations on nexthop grouping requires
> not modifying the nexthop, might be a bit more robust to group on
> RR-client-RIDs]

(Above me, with confusing use of "grouping" :) )

> For MED churn you can solve it by advertising the bestpath plus the 
> bestpath-per-neighbor-AS.

I think that only solves it if there's one connection to a neighbour AS. 
Otherwise it'd need to be bestpath-per-eBGP-nexthop?

At least, MED oscillation arises when different speakers have a view of 
only a subset of the paths out of the AS. The pair-wise preferences of 
paths can be non-transitive: A < B, B < C, C < A can be true. So if a 
speaker has just a subset of these, and another peer a different subset - 
oscillation is possible.

If bestpath-per-neighbour-as could cause some speakers to have just a 
subset view again, then it allows for MED oscillation again.

(This could also be fixed by ensuring that the preference of routes in BGP 
increases monotonically with propagation, e.g. considering CLUSTER_LIST 
above MED could fix that).

> Sorry, there are no plans to advertise a distinct capability for these 
> features :( Each of these features use addpath but the features 
> themselves do not change the formatting of the messages exchanged 
> between speakers so a new capability isn't needed.

They do have significantly different (incompatible) semantics. It'd be 
nice for speakers to know that not just encoding but meaning is 

> Hmmm, that's a best practices RFC though, it isn't actually removing 
> AS_SET from the protocol. I wouldn't call that deprecated...just not 
> recommended :) So while not recommended you could still use it in a 
> pinch if you have a peer that doesn't support addpath.

As long as Add-Path is fully rolled out before SIDR is, sure! Otherwise...

Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
#undef THISSUCKS /* Only for 2.2 */
#include <linux/pipe_fs_i.h>

 	- from include/linux/jffs2_fs_i.h

More information about the Quagga-dev mailing list