Re: IGPs and BFD

[Dave Katz <[e-mail]>]

On Mar 1, 2005, at 11:16 AM, Chris Nogradi wrote:
> I am not sure what is meant by the "topology change" as I do not see 
> any
> wording in section 7.3 discussing a topology change that is NOT made 
> visible
> to the network.  Should this instead say: "... and the topology change 
> as
> outlined in section 7.3 should not be made visible to the network."?

Yes, that was what I meant.  I'll rework the language.

>
> If I am understanding this correctly, it would seem that if multiple 
> routing
> protocols are sharing the same BFD session to the peer, the solution
> presented here would not work.

If the control plane is restarting and multiple protocols are relying 
on BFD, those multiple protocols are all either going to have GR 
mechanisms or they are going to suffer adjacency failure.  In the case 
of OSPF and ISIS, when both have GR available, this scheme will work (I 
think) because OSPF will use its GR mechanism and ignore the eventual 
BFD session failure.

>
> I am also confused as to what is meant by "...since the neighbors will 
> tear
> down their BFD sessions when those sessions restart."

Since the restarting system has no BFD state (since it is sharing the 
restarted control plane fate with the protocol), the restarting system 
will cause all of the BFD sessions with its neighbors to fail as soon 
as it sends any packets (since the packets will show that its BFD 
sessions are down.)  By delaying sending any BFD packets until the GR 
mechanism has started, the inevitable BFD session flaps will be 
ignored.

>
> By the way there seems to be a missing word in the beginning of this
> paragraph:  "If a planned restart is about to TAKE place,..."

Noted, thanks.

--Dave