bfd-like mechanism for LANPHY connections between providers

Thu Mar 17 01:05:46 UTC 2011

On Wed, Mar 16, 2011 at 8:00 PM, Sudeep Khuraijam
<skhuraijam at liveops.com> wrote:
> There a difference of several orders of magnitude  between BFD keepalive intervals  (in ms) and BGP (in seconds) with generally configurable multipliers vs. hold timer.
> With Real time media and ever faster last miles, BGP hold timer may find itself inadequate, if not in appropriate in some cases.

For eBGP peerings, your router must re-converge to a good state in < 9
seconds to see an order of magnitude improvement in time-to-repair.
This is typically not the case for transit/customer sessions.

To make a risk/reward choice that is actually based in reality, you
need to understand your total time to re-converge to a good state, and
how much of that is BGP hold-time.  You should then consider whether
changing BGP timers (with its own set of disadvantages) is more or
less practical than using BFD.

Let's put it another way: if CPU/FIB convergence time were not a
significant issue, do you think vendors would be working to optimize
this process, that we would have concepts like MPLS FRR and PIC, and
that each new router product line upgrade comes with a yet-faster CPU?
 Of course not.  Vendors would just have said, "hey, let's get
together on a lower hold time for BGP."

As I stated, I'll change my opinion of BFD when implementations
improve.  I understand the risk/reward situation.  You don't seem to
get this, and as a result, your overly-simplistic view is that "BGP
takes seconds" and "BFD takes milliseconds."

> For a provider to require a vendor instead of RFC compliance is sinful.

Many sins are more practical than the alternatives.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts