Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

[Robert Raszuk <[e-mail]>]

Hi Arnold,

vast majority run BIRD as RS and it is BCP to do per client (ASN) best path


​Perhaps it is a Common Practice but it is hardly "​Best" one. That must be
why so many folks already complain today about their RS scaling issues.

Copying OPEN policy nets and paths to individual per client views seems
very suboptimal for RS design. Well you get what you paid for :).

To contrast that let me remind everyone that Route Server design in Cisco
IOS XE keep all common policy paths in single global BGP "view" and only
when there is static or dynamic (by communities) policy moves subject to
policy paths to individual views. So clients get sigma of per view + global
updates. And you can run on your existing x86 RS blade too.

The draft under discussion breaks this design and its scaling properties.

Now to someone who mentioned that this is all about weak client routers
let's face the numbers.

The data from various route servers (two in Asia, one in EU and one in US)
I have captured recently show:

IX1 - 250K IPv4 total paths
IX2 - 167K IPv4 total paths
IX3 - 50K IPv4 total paths
IX4 - 30K IPv4 total paths

So with 120 bytes per path (this is size of BGP path data structure in
efficient BGP code base) even if you send all clients all paths with
add-paths you need on client control plane total RAM of:

IX1 -  30 MB RAM
IX2 -  20 MB RAM
IX3 -  6 MB RAM
IX4 - 3.5 MB RAM

​So what problem is this draft trying to solve ? Save max 10s of ​MB of RAM
on the client ?

Note also that even add-paths is optional. Most IX already today have two
Route Servers. So it is trivial to have such one route-server to act as
primary sending overall best path and second one acting as backup sending
2nd best. (The IOS XE definition of second best mandates different next hop
then overall all best).

All what is needed is few implementation twicks in your RS code vendor to
address the problem at hand.

Cheers,
Robert.