IETF Logo Mail Archive

draft-palanivelan-bfd-v2-gr-08

Santosh P K <santoshpk@juniper.net> Wed, 27 October 2010 15:12 UTC

Return-Path: <santoshpk@juniper.net>
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD66F3A6961 for <rtg-bfd@core3.amsl.com>; Wed, 27 Oct 2010 08:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCmQeOZGuqif for <rtg-bfd@core3.amsl.com>; Wed, 27 Oct 2010 08:12:42 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 93BCE3A6A03 for <rtg-bfd@ietf.org>; Wed, 27 Oct 2010 08:12:26 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTMhBxzSiaN8GxjxYNBNLKysaPosNV/8F@postini.com; Wed, 27 Oct 2010 08:14:17 PDT
Received: from p-emfe01-bng.jnpr.net (10.211.204.19) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Oct 2010 08:10:45 -0700
Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe01-bng.jnpr.net ([::1]) with mapi; Wed, 27 Oct 2010 20:40:43 +0530
From: Santosh P K <santoshpk@juniper.net>
To: "apvelan@cisco.com" <apvelan@cisco.com>
Date: Wed, 27 Oct 2010 20:40:42 +0530
Subject: draft-palanivelan-bfd-v2-gr-08
Thread-Topic: draft-palanivelan-bfd-v2-gr-08
Thread-Index: Act16R878vL0wuexT5a1DPZtS7wjiA==
Message-ID: <FB649DA20153634794BEBBAB504DA1AD4506130D74@EMBX02-BNG.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FB649DA20153634794BEBBAB504DA1AD4506130D74EMBX02BNGjnpr_"
MIME-Version: 1.0
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Oct 2010 15:12:51 -0000

Hello Palanivelan,

     I have couple of doubts on this draft. Under section 6.2. Remote Neighbor Restart and Recovery, it's mentioned that.



   "When the set of systems had their BFD sessions established, with GR

   support as described in this document, when the remote neighbor

   restarts it will set the BFD diagnostics field to a value of 9

   (Neighbor Restarting) in the control packet to its neighbor (local

   system)."



  This draft is trying to address the unplanned restart of protocols using BFD, as the planned outage is handled today anyway.



1.    How BFD would determine that protocol using BFD has gone for graceful restart (in case of unplanned outage), to send BFD packet with BFD diagnostics field set to 9?

2.    If BFD can determine that protocol using BFD has restarted with GR enabled and that's not planned outage then can't we increase BFD session timers instead of having MyRestartInterval and yourRestartInterval fields?

3.    In case we miss out initial couple of BFD packets with diagnostics field set to 9 due to BFD not having enough CPU slice on restarting router, then at local router (helper) are we not bringing down the session?

....................................

Thanks and regards
Santosh P K

v2.23.0 | Report a Bug | By Email