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

[Dave Katz <[e-mail]>]

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

>