Hello VJnetwork
I labbed this up too, to do some more experimentation, and I have replicated your results. It seems that when you remove the BFD configuration, either by removing the bfd interval command from the interface or by removing the neighbor fall-over bfd command from the BGP configuration, the BGP peering and the resulting routing remains intact.
Now I notice the following. When I disable BFD using one of those methods, I take a look at the syslogs on the other router and I see this:
*Oct 7 06:24:00.698: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: RX ADMINDOWN
However, if I shut down the interface instead, the syslog on the other router displays the following:
*Oct 7 06:29:50.303: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: ECHO FAILURE
*Oct 7 06:29:50.309: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed, ld:1 neigh proc:BGP, handle:1 act
Notice in the first case, the reason code is RX ADMINDOWN while in the second case, the reason is ECHO FAILURE. We also get an additional syslog in the second case that states that the BFD session is destroyed, something we don’t see in the first case.
From this info, we can conclude that when you disable BFD, the router informs the BFD neighbor that the action taken was an administrative action, and does not constitute a failure. When the interface is shutdown, that is detected as an echo failure, which is interpreted as a failure on the link, so the BGP session fails too.
(Note that the BGP session, in this case, will fail anyway because the interface goes down, but the exercise does demonstrate how BFD handles an administrative change compared to a real network failure.)
Thus, BFD configurations can be safely removed without the fear of causing a failure or a disruption on a production network.
I hope this has been helpful!
Laz