Re: [RAM] Number of DFZ routers

[Robert Raszuk <raszuk at juniper.net>]

Hello Heiner,

> BGP needs to be replaced, not repaired. 

/* I would recommend to start replacing it today and the best place to 
start is your own AS. */

Seriously even if we would have a new protocol to replace BGP call it 
PGB all defined and it's RFC ready it will take years to implement and 
years^years to deploy.

I would therefor recommend not to cross the option to repair BGP.

> A 200 k FIB should be proof 
> enough that this is the wrong way to go.  2k should be sufficient for a 
> 100 times bigger internet. It's the basic concept of BGP which is 
> totally wrong.

Number of FIB entires have nothing to do with the protocol.

Please observe that BGP uses recursion. Most often it recurses to an IGP 
next hop, but it can also recurse to BGP itself then to IGP or something 
else. We could introduce hierarchy with BGP protocol as is without any 
changes to the protocol or existing and deployed routers. Your FIB could 
shrink tomorrow if we would have an agreement between operators to use 
tunneling for forwarding. I think this is the biggest obstacle today. We 
don't have a way to tunnel interdomain.

I see all proposals today are moving the issue and if during such move 
the handling of 10^7-10^9 number of prefixes get's solved it would only 
benefit everyone.

I am quite convinced that if we would just do two steps:

* Mark BGP next hops with some community
* Do not change nhs on EBGP boundaries

So the recursion would be:

Dst -> BGP NH -> IGP NH to BGP NH

Encapsulation end point would be to original BGP NH. All destinations 
would not be present in all transit ASBRs as long as the LTR was there 
somewhere on the packet's way.

The FIB size in most transit ASBR routers would shrink immediately. I am 
assuming that we are not worrying about P routers which can be BGP free 
today.

> Other, secondary parts (Hello's etc.) can be re-used of course.

I wouldn't be so convinced about that one actually.

Cheers,
R.

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram