IOS XR OSPF subsecond timer vs BFD

Question

Dear all,
We recently got problem with subsecond OSPF timer on CRS.
On previously, we can configure OSPF hello timer min dead-interval 3 on 7606 router, which mean OSPF hello is at 333 ms.
Unfortunatelly, CRS cannot be configured with 333 ms for hello timer.
And theres some of our TAC case with result that we need configure BFD.
If we configure BFD on top of OSPF, is it recommended ?
Is we got the same behaviour like having 333ms on OSPF, as expected when we configure BFD on top of OSPF at CRS ?
And our network has different router like ASR9000 series, 7600 series router, ME6524 series. Is all has the same behaviour when we config the same BFD configuration and parameter ?
Is it configuring the BFD on routing protocol is recomended ? replacing the sub-second timer configuration ?
Thanks,
Budi L

Answer 1

Hi,
In a general sense, For a network with very low convergence requirements (sub second), choosing the 'right' methods to achieve the optimum network convergence is a long excercise that highly depends on network design and Hardware/Software features. So as a start, make sure you know what your current software and HW can and can not support. Then look at what will be the outcome of combining different fast convergence and High availability features together.
So you have 3x blocks of different ways to enhance fast convergence and high availability:
1- LDP-IGP sync: be careful with LDP-IGP sync as XR has a different behavior than IOS (IGP adj is always build so there is no concept of holddown timer).
2- OSPF process tuning : LSA and SPF throttle tuning
3- Link failure detection tuning : BFD
I would start with LDP-IGP sync and tuning the link failure detection can be done after or before the OSPF protocol tuning.
Example: Making sure that Link failure detection mechanism is compatible with your HA configuration. For example BFD is not handled in Hw on 7600 so you can't use it if you also want SSO/NSF on this box as well. The neighbor will switch to a backup path before OSPF GR has a chance to start.
You have to plan for more 2 different kind of convergence events here, a down convergence event (BFD and protocol timers detect this), and an up convergence event (not timer based, service establish based on what facilities are available). The state between the start of the up convergence and fully converged is a transient state where multiple things start to happen depending on the facilities available (first interface up, then IGP, maybe PIM, maybe BGP, etc). At scale, this state is often very non-deterministic, rarely happens in the same order twice, and requires some amount of system analysis to make sure there are enough resources available to re-establish all the different services without the risk of flapping anything.
The more processes you add to the router (OSPF, BGP, PIM, and now BFD) the more critical it is to pay attention to how much time and resources each process requires. Reducing protocol timers can exaggerate the conditions in the transient state, so there are tradeoffs for having low convergence vs. scale/performance. For instance if BGP is not fully reconverged and a neighbor flaps because the CPU is busy, the whole process may have to start all over again and there is potential that the router may never fully recover if that scenario repeats.
BFD and IGP timers are mutually exclusive, It is always recommended to turn BFD on with IGP. Be sure not to tune OSPF too aggressive. Also to keep in mind that BFD is not SSO aware (Think IOS vs XR), so when there is a SUP fail over, BFD will observe microflaps hence you will see some packet loss. That's why you have to tune the values to an optimum level e.g. for a MAN 200-300ms interval for BFD control packets should be fine but you have to test it.
Thanks,
Ahmed