[quagga-dev 11580] Re: [PATCH] BGP: add aspath_aggregate_mpath that preserves path length
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,
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,
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...
More information about the Quagga-dev