[c-nsp] BFD feedback?

[Tim Durack]

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) <avayner at cisco.com> 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: 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/
> _______________________________________________
> 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/
>