Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Joe Maimon <jmaimon () ttec com>]

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