Re: Why need single hop BFD? Does single Hop BFD requires to travese all possoble links beween the two neighbors?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why need single hop BFD? Does single Hop BFD requires to travese all possoble links beween the two neighbors?




On Nov 8, 2009, at 6:10 AM, Linda Dunbar wrote:

Dave and David,
 
Forgive me for not aware of the history of the BFD development. Reading through the “BFD for IPv4 and IPv6 (Single Hop)” (draft-ietf-bfd-v4v6-1hop-10.txt), I am not clear why single hop BFD is needed, especially for two immediately connected neighbors. There is Hello message between two immediate neighbors.

Of course, the entire point of 1hop is to run on immediately connected neighbors.

If two immediate neighbors need logical layer to detect any failure between the two immediate neighbors, they can use the Hello message to achieve this purpose. Even though Hello message is from control Plane, it would be much less work for routers/LSRs to monitor the Hello messages than creating a new BFD session.

(a)  There may not be any Hello protocol running between adjacent nodes.  (A number of folks are using BFD to protect static routes.)
(b)  The existing Hello protocols in IGPs have a number of failings, which are spelled out elsewhere.
(c)  BFD is modeled to run in the data plane (though of course implementors can put it wherever they want.)  In particular, it's a goal to make it possible to continue to forward traffic (and thus to protect the forwarding path with BFD) even when the control plane is resetting or having other issues.

 
Any physical media, like 802.3, SONET, DWDM wavelength all have physical failure indication. Each neighbor can also use the physical failure indication to declare the connectivity between two immediate neighbors, which is much faster than a BFD session, isn’t it? It also needs less processing on the router/LSR, there won’t be any proactive periodical sending BFD over the link anymore.  

There is no system-to-system failure indication in Ethernet, particularly when switches are involved (which is *always* at this point, unless you know someone still using yellow hose and vampire taps) which was a driving reason for doing BFD in the first place.  Those of us in the Big Iron business saw lots of Ethernet showing up in POP interconnects, and waiting for IGPs to time out was causing huge traffic losses.

 
Can you explain (or add to the document) what is the reason for having single hop BFD?
Is single Hop BFD only for the Tunnel scenario?

From the spec:

   One very desirable application for BFD [BFD] is to track IPv4 and
   IPv6 connectivity between directly-connected systems.  This could be
   used to supplement the detection mechanisms in routing protocols, or
   to monitor router-host connectivity, among other applications.
...
   This application of BFD can be used by any pair of systems
   communicating via IPv4 and/or IPv6 across a single IP hop that is
   associated with an incoming interface.  This includes, but is not
   limited to, physical media, virtual circuits, and tunnels.

It's primarily for router interconnection, which given the authors' employers makes sense.  But it can be used in any single-hop scenario that fits the deployment requirements.

 
In Section 2 (Application and Limitation), the last paragraph does indicate that the transmitted packets are immediately routed back towards the sender on the interface over which they where sent if BFD Echo function is used. But when Link Aggregation is used to bundle the multiple parallel links between two neighbors, how does the network layer enforce which link to send back the “echo” message?

It can't, obviously.  There's no magic.  One could argue that it shouldn't, as it is monitoring the liveness of the L3 path, not the individual links.  The theory at the time was that BFD could be used at L2 across the individual links if someone wanted to do that, but the Ethernet folks wanted to roll their own OAM or somesuch.

 
Even if BFD ECHO can be enforced to be sent back on the same interface port so that the individual link’s failure can be detected, what can this fault do when this fault can’t affect the connectivity between the two immediate neighbors in control plane’s view?  All the links are bundled and two immediate neighbors are still connected?

See above.  The 1hop spec is explicitly an L3 play;  aggregate links are just single links in that case, so from BFD's standpoint the failure of an individual link will be invisible.

--Dave



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.