IGPs and BFD

Chris Nogradi <cnogradi@laurelnetworks.com> Tue, 01 March 2005 18:21 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24419; Tue, 1 Mar 2005 13:21:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6C0a-00022s-I2; Tue, 01 Mar 2005 13:22:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ByH-0003Ge-Pb; Tue, 01 Mar 2005 13:19:49 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ByG-0003GZ-UI for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 13:19:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24337 for <rtg-bfd@ietf.org>; Tue, 1 Mar 2005 13:19:45 -0500 (EST)
Received: from staple.laurelnetworks.com ([63.94.127.68] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6BzE-00020w-Gh for rtg-bfd@ietf.org; Tue, 01 Mar 2005 13:20:50 -0500
Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by staple.laurelnetworks.com (Laurel/Laurel) with ESMTP id j21IGdGJ025712; Tue, 1 Mar 2005 13:16:39 -0500
Received: from cnogradi-linux.dhcp.pit.laurelnetworks.com (cnogradi-linux.dhcp.pit.laurelnetworks.com [10.0.19.158]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id j21IGcFS027970; Tue, 1 Mar 2005 13:16:39 -0500
From: Chris Nogradi <cnogradi@laurelnetworks.com>
Organization: Laurel Networks
To: Dave Katz <dkatz@juniper.net>, David Ward <dward@cisco.com>
Date: Tue, 01 Mar 2005 13:16:07 -0500
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200503011316.07593.cnogradi@laurelnetworks.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: IGPs and BFD
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit

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