[c-nsp] BFD feedback?

[Arie Vayner (avayner)]

Actually, dropping the link is sometimes wrong, as you sometimes have
point to point link that have different layer 2 "legs" (for example
Ethernet over SDH).
The end to end connectivity would fail, but the local link to the local
SDH node has to stay up...

Thanks
Arie 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Chris Woodfield
Sent: Wednesday, October 24, 2007 16:47 PM
To: Sam Stickland
Cc: cisco-nsp List
Subject: Re: [c-nsp] BFD feedback?

I wasn't advocating that BFD *only* work at the link level, but for
point-to-point links it's a feature I'd like to have as an option.  
There would obviously need to be some mechanism by which BFD packets
would continue to be sent and received despite the interface protocol
being shut down, but that's an implementation detail. My pain point is
exactly what I described - ensuring proper and timely failover of
point-to-point MAN access circuits that don't lose link state when a
metro switch in the middle goes belly-up. If we could do this with BFD
*instead* of, instead of an top of, a routing protocol between ourselves
and our customers, that's a big win.

Having BFD trigger the withdrawal of a static route would be a nice
interim step here. Did cisco ever put this on their feature timetable?

-C

On Oct 24, 2007, at 5:48 AM, Sam Stickland wrote:

> Chris Woodfield wrote:
>> BFD is a lifesaver where you have circuits such as metro ethernet   
>> links that don't lose link state when something in the middle blocks

>> connectivity. It's less useful across WAN links that depend on 
>> end-to- end connectivity to maintain line protocol.
>>
>> As Arie, said, the hardest part of implementation is the timer   
>> tuning, to get the best balance of response time vs. CPU utilization

>> as well as preventing false timeouts, another side effect of setting

>> the timers too low.
>>
>> That said, I do feel that tying BFD to routing protocol events only  
>> is a bit shortsighted - why not have an option to just change line  
>> protocol to down in a case of BFD timeout failure, and let the  
>> routing protocols react the that naturally?
>>
> Surely this wouldn't work on multi-access networks (e.g.  
> ethernet ;) )? BFD forms adjacencies according to the routing protocol

> neighbors, not according to the physcial links. Consider the 
> followinng topology:
>
> R1 ----- SW1 ---- R2
>                 |
>                R3
>
> R1, R2 and R3 share a broadcast domain via SW1 and each one has formed

> an OSPF adjacency with each other (full mesh). This means that there 
> is a full mesh of BFD neighbors also. If the link from
> SW1 to R3 goes down BFD will detect this and take down the appropiate 
> OSPF neighbors. If BFD shut the interface down instead it would also 
> sever the communication between R1 and R2, which isn't want you want.
>
> Sam
>

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/