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

Tue Jan 26 05:44:25 UTC 2016

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.