nanog mailing list archives
Re: bfd-like mechanism for LANPHY connections between providers
From: Sudeep Khuraijam <skhuraijam () liveops com>
Date: Wed, 16 Mar 2011 17:00:20 -0700
Correct me if I am wrong but to detect a failure by default BGP would wait the "hold-timer" then declare a peer dead and converge. Hence the case for BFD. 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 a provider to require a vendor instead of RFC compliance is sinful. Sudeep On Mar 16, 2011, at 1:42 PM, Jensen Tyler wrote: Correct me if I am wrong but to detect a failure by default BGP would wait the "hold-timer" then declare a peer dead and converge. So you would be looking at 90 seconds(juniper default?) + CPU bound convergence time to recover? Am I thinking about this right? -----Original Message----- From: Jeff Wheeler [mailto:jsw () inconcepts biz] Sent: Wednesday, March 16, 2011 1:55 PM To: nanog () nanog org<mailto:nanog () nanog org> Subject: Re: bfd-like mechanism for LANPHY connections between providers On Wed, Mar 16, 2011 at 2:33 PM, Jensen Tyler <JTyler () fiberutilities com<mailto:JTyler () fiberutilities com>> wrote: We have many switches between us and Level3 so we don't get a "interface down" to drop the session in the event of a failure. This is often my topology as well. I am satisfied with BGP's mechanism and default timers, and have been for many years. The reason for this is quite simple: failures are relatively rare, my convergence time to a good state is largely bounded by CPU, and I do not consider a slightly improved convergence time to be worth an a-typical configuration. Case in point, Richard says that none of his customers have requested such configuration to date; and you indicate that Level3 will provision BFD only if you use a certain vendor and this is handled outside of their normal provisioning process. For an IXP LAN interface and associated BGP neighbors, I see much more advantage. I imagine this will become common practice for IXP peering sessions long before it is typical to use BFD on customer/transit-provider BGP sessions. -- Jeff S Wheeler <jsw () inconcepts biz<mailto:jsw () inconcepts biz>> Sr Network Operator / Innovative Network Concepts ____________________________________________ Sudeep Khuraijam | I speak for no one but I
Current thread:
- Re: bfd-like mechanism for LANPHY connections between providers, (continued)
- Re: bfd-like mechanism for LANPHY connections between providers Jeff Wheeler (Mar 16)
- Re: bfd-like mechanism for LANPHY connections between providers Richard A Steenbergen (Mar 16)
- RE: bfd-like mechanism for LANPHY connections between providers Jensen Tyler (Mar 16)
- Re: bfd-like mechanism for LANPHY connections between providers Jeff Wheeler (Mar 16)
- Simple Low Cost WAN Link Simulator Recommendations Loopback (Mar 17)
- Re: Simple Low Cost WAN Link Simulator Recommendations Sergey Voropaev (Mar 17)
- Simple Low Cost WAN Link Simulator Recommendations Loopback (Mar 17)
- Re: Simple Low Cost WAN Link Simulator Recommendations Mike Callagy (Mar 18)
- Re: Simple Low Cost WAN Link Simulator Recommendations Matthew Petach (Mar 20)
- Re: Simple Low Cost WAN Link Simulator Recommendations Tim Durack (Mar 20)
- Re: bfd-like mechanism for LANPHY connections between providers Sudeep Khuraijam (Mar 16)
- Re: bfd-like mechanism for LANPHY connections between providers Jeff Wheeler (Mar 16)
- Message not available
- Message not available
- Re: bfd-like mechanism for LANPHY connections between providers Sudeep Khuraijam (Mar 16)