Mark Tinka wrote:
On 25/Jan/16 20:13, Joe Maimon wrote:
Maybe not for some people, but I have a hard time understanding why one extra ebgp session is such a novel concept for all you networking folk.
It's not that novel - I share my view of the Internet with various industry initiatives this way.
It appears that to route on the edge with multihop is viewed as novel. And going further, multihop is quite novel to BGP Engineers in many a location, as per personal experience.
But for a commercial service, the decoupling between the state of the physical link and the control plane in this case creates an opportunity for various forwarding issues that are avoidable. The BFD argument could be made, but it is not yet a basic feature one can expect with one's customers.
Before BFD, we had keepalives right in BGP. Whats wrong with that? 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...
I know you know better. What does this have to do with tunnels? Or how centralized your network is built or not?
Not everyone has the luxury of carrying a full table at the edge, for various reasons, and I get that (even though in 2016, selective BGP FIB downloads is a reality).
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. 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.
But if you can avoid it, determining one or two boxes in your core that are your full BGP table reference puts a great deal of burden on those devices to run and maintain routability for and within your network. If I had the ability not to do this, I would, despite how sexy eBGP Multi-Hop might be.
Mark.
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. Joe