MPLS TE FRR & some BFD

[dknov]

Hi,

I have a few questions:

1. If you have TE tunnel with FRR configured for it, what will trigger the switchover to backup tunnel?

In my mind:

a. Link Protocol down on the interface

b. RSVP signalling

Now two other problematic ones are:

c. IGP neighbor down over a protected link (will it trigger TE reroute WITHOUT using FRR, so IGP neighbors and FRR would be two completely different approaches?)

d. BFD. Is it activated on a specific protected link or on the LSP headend (tailend) to "test" the end-to-end LSP? It is mentioned in BFD docs that when used with TE FRR it can report tunnel down BEFORE the tunnel having sufficient time to be rerouted (because BFD would be acting so fast). Does this mean BFD allows end-to-end LSP testing?

2. More about BFD. The docs say that BFD itself just reports to the protocol employing its services (like IGPs and maybe TE) that the connectivity betweem two points BFD is responsible for is down. If BFD is configured over an interface, does this mean that when BFD senses lack of reachability but Link Protocol stays up (like Ethernet), will it actually bring down the Link Protocol on that particular interface?

If not, it is unclear why would docs also say that BFD is best deployed with Interface Dampening. Interface dampening would work in case Link Protocol flaps...

Thanks!

David

[mheusinger]

Hi David,

I try to give some answers, though I am also pretty new to BFD. With my current understanding I give the following answers:

A1) a. and b. are true

A1) c. IGP neighbor down will afaik not trigger FRR. The tunnel headends will however learn about it through LSAs and trigger a new tunnel path selection.

A1) d. BFD (Bidirectional Forwarding Detection) It can be activated - among other things - on a LSP to test end to end connectivity. More precisely it is activated between two routers and can be configured to use a MPLS TE tunnel between them.

A2) Afaik BFD is not more and not less than UDP packets sent at a specified interval between two hosts configured for BFD. When a configured number of BFD packets are missing an action can be triggered. F.e. BGP supports BFD now to detect neighbor connectivity. Session tear down can be triggered by BFD, thus allowing for much faster detection than the default BGP keepalive mechanism.

The link protocol on an interface will not go down and this is good as it is. Assume a router connected through Ethernet into one VLAN. BFD is configured to check with unicast packets the connectivity to one neighbor. Assume this neighbor is disconnected. It does not mean other hosts in the VLAN are not reachable anymore. So the Ethernet of the router should stay up/up (and it does).

Interface dampening and BFD together will allow you to react flexible f.e. for BGP sessions. With "fast-external-fallover" a link flap would tear down the session immediately, which is not desired for BGP stability. On the other hand without it BGP would rely on BGP hello timers and thus a real interface failure remain "undetected" (for BGP) for 180 seconds per default. BFD allows you to choose a timeout suitable for your environment. You might f.e. have some redundancy built into your transmission path (like APS or card redundancy) which could lead to a 1 second interface flap. BFD can be adjusted so that a 1 second timeout does not affect BGP, whereas anything longer than 2 seconds indicates a real connectivity problem and leads to terminating the BGP session.

Hope this helps! Please rate all posts.

Regards, Martin

[mheusinger]

What also could help you is additional information from http://www.ietf.org/html.charters/bfd-charter.html

Regards, Martin

P.S.: Maybe it BFD should be renamed in PIKE = Protocol Independant KEepalives? :-)

[swaroop.potdar]

Hi David,

Pls see my what i feel inline...

a. Link Protocol down on the interface

b. RSVP signalling

////

1(a,b)

Here again RSVP hellos are used as a trigger to achieve the FRR rather than relying on the line protocol to go down.

Which provides us fast upto 50msec protection.

Afaik TE FRR can utilize BFD as its relatively less resource intensive than generating RSVP hellos.

////

c. IGP neighbor down over a protected link (will it trigger TE reroute WITHOUT using FRR, so IGP neighbors and FRR would be two completely different approaches?)

////

1(c)

Without using FRR the TE reroute would be pure Tunnel Reoptimization based on your IGP convergence towards your Tunnel TailEnd.

////

d. BFD. Is it activated on a specific protected link or on the LSP headend (tailend) to "test" the end-to-end LSP? It is mentioned in BFD docs that when used with TE FRR it can report tunnel down BEFORE the tunnel having sufficient time to be rerouted (because BFD would be acting so fast). Does this mean BFD allows end-to-end LSP testing?

////

1(d)

"BFD can help test end-to-end data plane only just like LSP ping, but there is currently no integration of the results and mapping of the same to control plane in MPLS. hence BFD with LSP ping is being preached. More details can be found at http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-03.txt."

////

2. More about BFD. The docs say that BFD itself just reports to the protocol employing its services (like IGPs and maybe TE) that the connectivity betweem two points BFD is responsible for is down. If BFD is configured over an interface, does this mean that when BFD senses lack of reachability but Link Protocol stays up (like Ethernet), will it actually bring down the Link Protocol on that particular interface?

If not, it is unclear why would docs also say that BFD is best deployed with Interface Dampening. Interface dampening would work in case Link Protocol flaps...

////

2.

No BFD would not involve itself into getting the link down, it will only enable the protocol bootstrapping or using it to declare a failure.

Now assume if the link is bouncing up and down, or there are intermittent losses because of link intergity. Then BFD would keep sending up down messages to the protocol employing it. Hence if the integration is with Dampening, then such UP or DOWN messages can be considered as flaps in the configured interval and the interface can be dampened. The Dampening as a process would utilize BFD triggers for calculating flaps rather than the Line protocol based UP or DOWN triggers. Thus enabling us to achieve the upto 50ms recovery time which is generally provided by POS/SONET with APS.

////

HTH-Cheers,

Swaroop