On 25/Jan/16 23:01, Joe Maimon wrote:
Before BFD, we had keepalives right in BGP. Whats wrong with that?
You may want to signal failure more quickly than BGP's own timers can handle.
I suppose you also advocate that each provider use a phy port directly on the ege, no switches in between, so that the full table can be yanked out as quickly as possible and that it be flooded back in as soon as possible, as many times as possible...
Not how I run my network. I aggregate customer ports to a Layer 2 switch, which upstreams to the edge router for service. Router ports are expensive. The only time I'll terminate customer links to a router is if they are buying 100Gbps native services.
The question is whether it is a reality for gear that already cannot support full tables (likely EoS), or that is projected not to support them in the future. And which is practical to obtain and operate.
If your gear does not have the latest capabilities, then using what it has to achieve the best possible outcome is a well understood strategy. What we are talking about here is options in current state-of-the-art that you would want to ignore for older options if you have the opportunity not to. But, your network, your rules.
Further, FIB is one part. Collecting multiple full tables can also impose a dram burden on an edge router.
And churn on its CPU. Crypto, policy, etc.
Lets face it. An edge device control processor and memory is not the ideal location for all this. It does not compare with the GP hardware available for that task and it never will.
Not from what I see in my network. I have virtual routers running on x86_64 servers chugging along just as well as the routing engines on my Juniper and Cisco edge routers. Admittedly, the control planes in those routers are high-end, and I can't expect that everyone can afford them, but to say the brains in modern routers are not up to the task is simply not true. In fact, the control plane on some of these boxes is not yet being fully exploited because code is still slowly evolving to take advantage of multi-core architecture, and 64-bit memory, particularly for routing processes. The headroom and performance on these has been phenomenal, and I can take that to the bank.
Who says it must be that way? You could go the other extreme, it is quite feasible to have multiple RR's per pop (if thats what you want) and you can even segregate each eBGP feed into its own BGP router process, using a fraction of the hardware resources available to you in todays 1U server, available at a fraction of the cost of yesterday's edge.
It is not too hard to see that this approach offers a degree of design freedom that coupling your ebgp directly to your edge does not.
Not the way I'd do it, but like I said, your network, your rules. Mark.