[Babel-users] Porting awesome features from Babel to BGP? [was: Ability to work with massive number of routes? (global full-table)]

[StarBrilliant]

On Sun, Sep 23, 2018 at 2:10 AM StarBrilliant <coder at poorlab.com> wrote:
>
> Hi everyone,
>
> Thank you for your replies.
>
> On Sat, Sep 22, 2018 at 6:49 PM Juliusz Chroboczek <jch at irif.fr> wrote:
> > Well, that's a lot.  BGP is designed with that in mind -- it uses
> > incremental updates layered over a reliable protocol, and therefore scales
> > beautifully in a stable network.  Babel uses unreliable updates, on the
> > assumption that it is used in an unstable network.
>
> Yes. I agree.
>
> > I don't think that Babel is the right tool for dealing with such large
> > numbers of routes.
>
> Agree.
>
> > > And here are the things Babel currently lacks:
> > > - Capability of handling 785k в 3 routes
> > > - An extension to preserve AS Path
> >
> > It really looks like you want BGP.  Why don't we work together on adding
> > SADR to BGP?
>
> Actually I want three features that Babel has and BGP doesn't:
> 1) RTT based routing decision
> 2) Packet loss based routing decision
> 3) SADR
>
> I fully support your suggestion to add features to BGP. But I am
> afraid it is too hard to add RTT based routing decision.
> How do you think about it?

I realized that I had to add something to the topic, thus started a new thread.

1) SADR is easy to implement but does not scale globally

BGP is a TLV protocol, and also supports extension negotiating. So
it's easy to add SADR to BGP.

But if we really added SADR to BGP, we will want to restrict to iBGP
or small scale.
First, we already have 785k routes worldwide.
Second, people easily abuse SADR as an ACL.
Third, global SADR may affect global connectivity for its ability of
blocking certain source addresses.

Anyway we can learn some experience from BGP flowspec. They share some
common attributes, I think.

2) Why RTT based routing decision is important?

BGP does not have a metrics system, only the len(AS_Path) counts. When
two Tier-3 ISPs have transit to a common Tier-1 ISP, (very common case
for current global IPv6 deployment,) thus len(AS_Path) == 3, usually
less than a better, optimized route.

Some ISPs developed a system of BGP Community to prevent
cross-continent hops being used, while others uses AS Path prepending
to increase the "metrics". But that's only a workaround, not a
protocol extension. (In fact, "such common Tier-1 ISP" supports
neither BGP Community nor AS Path prepending, making things really
worse.)

3) Problem would rise if BGP has metrics

Some would make it multiples of 10, some 100, eventually causing
metrics bloat. We need to give guidelines on the unit of metrics. We
might come up with some solution to

Additionally, metrics for a distance-vector protocol require to be
addable: len(AS_Path) is, len(hops) is, RTT is, but packet loss is
not, monetary cost is not.
These nonlinear factors would be a tough problem.

We would also need to consider compatibility and scalability issues.


Actually I am very willing to work with the community to improve these
routing protocols. There might be a lot of real-world problems ahead,
though.

Best regards,
StarBrilliant