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
- IGPs and BFD Chris Nogradi
- Re: IGPs and BFD Dave Katz