Subject: IGPs and BFD

From: Chris Nogradi <[email-masked]>
Date: Tue, 1 Mar 2005 13:16:07 -0500

I have a few questions about the new sections (7.4.1 and 7.4.2) that have been 
added to the single hop IP document:

In section 7.4.1

   'OSPF has a "planned" restart mechanism, in which the restarting
   system notifies its neighbors that it is about to perform a restart.
   In this situation, if a BFD session fails while the neighbor is
   performing a graceful restart, the graceful restart SHOULD be allowed
   to complete and the topology change should not be made visible to the
   network as outlined in section 7.3.'

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."?

In section 7.4.2

   'If a planned restart is about to place, the restarting system MAY
   change the BFD timing parameters on a temporary basis in such a way
   as to make the Detection Time greater than or equal to the ISIS
   adjacency timeout.  This will provide the restarting system the same
   opportunity to enter Graceful Restart as it would have without BFD.
   In this case, the restarted system SHOULD avoid sending any BFD
   Control packets until there is a high likelihood that its neighbors
   know it is performing a Graceful Restart, since the neighbors will
   tear down their BFD sessions when those sessions restart.'

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.

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

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,..."

Thanks

---

From: Dave Katz <[email-masked]>
Date: Wed, 2 Mar 2005 13:17:05 -0700

> outlined in section 7.3 should not be made visible to the network."?

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

> 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.

> 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.

> paragraph:  "If a planned restart is about to TAKE place,..."

Noted, thanks.

--Dave