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

Daniel Walton dwalton at cumulusnetworks.com
Wed Oct 15 03:20:46 BST 2014

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? 

Can you elaborate on the possible issues? 

Well, the selection mechanism for choosing groups of prefixes to advertise 
together under one Add-Path mechanism needs to be somewhat consistent 
across an AS, doesn't it? In particular, what if one speaker sent all 
paths (e.g. through a misconfig), but another is expecting only active, 
FIB paths? 

Hey Paul, 
Grouping the paths could make the add-path encoding get messy, some NLRI might belong to 1 group, some to 2, what if the groups change? That's a lot of state to keep and add-path already requires the implementation to keep a great deal more state than before. At one point addpath had a flag so we could indicate which of the paths was the current bestpath but even that got ugly and we had to simplify things. 

All that said, I haven't seen a feature that utilizes addpath that needs to tag/group the paths like this. That's not to say there couldn't be one but so far this hasn't been a requirement. Even then I think it would be better to use communities for this. 

It might be nice to have some way to signal these kinds of obvious 
incompatibilities, and avoid giving admins yet more ways to accidently 
screw up their network. BGP is already a config-intensive protocol. 

Perhaps the Add-Paths guideline draft should specify a distinct capability 
for each type of grouping. Be a bit more than a guideline? Or a rev on the 
add-path draft to specify a capability and a registry? 

the following need to do capability exchange but these are some features 
that use add-path: 


[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 

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

Ah, if these different uses are planned to have distinct capabilities, 
that's great! 

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. 


Then, for BGP ECMP, what happens if a speaker wants to describe an ECMP 
path to a non-Add-Path speaker? 

In that scenario you would need to create the AS_SET with all of the 
ASNs that you are multipathing over. 


AS_SET is deprecated though: 


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. 


And incompatible with SIDR. I guess now Add-Path just has to get 
sufficiently widely deployed before SIDR for this not to matter. 

Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A 
When you're ready to give up the struggle, who can you surrender to? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20141014/66fdef87/attachment-0001.html>

More information about the Quagga-dev mailing list