[quagga-dev 11578] Re: [PATCH] BGP: add aspath_aggregate_mpath that preserves path length
paul at jakma.org
Tue Oct 14 14:03:52 BST 2014
On Mon, 13 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?
> 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,
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
Ah, if these different uses are planned to have distinct capabilities,
>> 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:
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?
More information about the Quagga-dev