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

Paul Jakma paul at jakma.org
Tue Oct 7 15:54:54 BST 2014


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

https://tools.ietf.org/html/draft-bhatia-ecmp-routes-in-bgp-02
https://tools.ietf.org/html/draft-bhatia-bgp-multiple-next-hops-01

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 
NLRI.

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.

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.

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?

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.

regards,
-- 
Paul Jakma	paul at jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
Linux is obsolete
(Andrew Tanenbaum)




More information about the Quagga-dev mailing list