But if BFD detected a failure in end-to-end forwarding, this could signal protocol down on the interface, and not actually take the link down, right?
On 10/24/07, Arie Vayner (avayner) <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/