RE: draft-palanivelan-bfd-v2-gr-08
"Palanivelan A (apvelan)" <apvelan@cisco.com> Tue, 02 November 2010 05:04 UTC
Return-Path: <apvelan@cisco.com>
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 5BC463A679F for <rtg-bfd@core3.amsl.com>; Mon, 1 Nov 2010 22:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 7UvXUN23if6Q for <rtg-bfd@core3.amsl.com>; Mon, 1 Nov 2010 22:04:14 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 11BCE3A6452 for <rtg-bfd@ietf.org>; Mon, 1 Nov 2010 22:04:14 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEABc5z0xAaMHG/2dsb2JhbAChZXGiMZwMhUUEhFWJDQ
X-IronPort-AV: E=Sophos;i="4.58,278,1286150400"; d="scan'208";a="210372195"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 02 Nov 2010 05:04:16 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA252pJj004293; Tue, 2 Nov 2010 05:04:15 GMT
Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 10:34:14 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-palanivelan-bfd-v2-gr-08
Date: Tue, 02 Nov 2010 10:34:12 +0530
Message-ID: <D4A66B38FC6C6E4F820A2470AEEA5CED02D58EB6@XMB-BGL-411.cisco.com>
In-Reply-To: <C789A153-C01A-4D46-9915-D6A01D9EE3E9@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-palanivelan-bfd-v2-gr-08
Thread-Index: Act3i65W1yk6Mk4jT46fkkpkBhpHuACuaQOw
X-Priority: 1
Priority: Urgent
Importance: high
References: <FB649DA20153634794BEBBAB504DA1AD4506130D74@EMBX02-BNG.jnpr.net> <C2E157D9-DB69-43D8-BB86-E148A93BA9EE@juniper.net> <D4A66B38FC6C6E4F820A2470AEEA5CED02D587DF@XMB-BGL-411.cisco.com> <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> <AANLkTik2gL3Cd3jwcifCaQRmrWRWhYSZLoYuPLkb7=tv@mail.gmail.com> <C00F7E81-49DF-4515-85AF-47ED6A0ECB2D@juniper.net> <D4A66B38FC6C6E4F820A2470AEEA5CED02D589FE@XMB-BGL-411.cisco.com> <C789A153-C01A-4D46-9915-D6A01D9EE3E9@juniper.net>
From: "Palanivelan A (apvelan)" <apvelan@cisco.com>
To: Dave Katz <dkatz@juniper.net>
X-OriginalArrivalTime: 02 Nov 2010 05:04:14.0908 (UTC) FILETIME=[6531A7C0:01CB7A4B]
Cc: rtg-bfd WG <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: Tue, 02 Nov 2010 05:04:15 -0000
To get started on this draft, This draft documents two issues with BFD and suggests a single solution to address both. 1) The first one is about the BFD failures during GRs in Planned Restarts, when co-existing with other Process intensive applications. This draft explains on such an issue, when scaled broadband configurations co-exist in the system that has routing protocols enabled with GR and BFD. Here, though the remote system (restarter) signals about the planned restart and the local system does get to know about the restart, during the restart, the local system still looks for BFD packets at the pre-negotiated timer values. Now, we have the tied routing protocol adjusting its timers to wait for an extended time (as negotiated for GR),but BFD still waiting for the originally negotiated timer values. Though this works fine in simple, less intensive environment, in a process intensive scenario, wherein I had given an example of BB configs in the draft, BFD may miss the packets, declare the remote neighbor down to the tied application (routing protocol) and hence bringing down the adjacency. This is also true for a system that has deep-packet inspection application like NBAR enabled in the system. I Have seen this in deployments with the products of the top-2 datacom companies and hence feel there is every reason to document and address this. For BFD to survive in such a scenario, The implementers look to use Flags/Timers or "Flags and Timers" to manage BFD timer values. Here again, though the timers are managed, there is no way of indicating at the local system that, the remote system is (gracefully) restarting. The local system anyway knows that the remote peer is restarting, why not have it in the diag field? And let that be set by the remote peer and why not have a bfd state indicating this state?. These two can be done within the existing framework of bfd (with additions to bfd diag and state). I thought negotiating the GR timers, between the peer makes it a much more standardized way of doing it and hence suggested the same in this draft. Not many would disagree to what I have said here, but whether this can be within the framework or not can be debated and also on whether this can be suggested as a BCP or otherwise. 2) The second one is about unplanned restarts and I see this working group is pretty much convinced that this problem won't be solved with what is suggested in this draft. Though I do think this extension would help solve the problem, I do not have it implemented anywhere to prove that it actually does. Appreciate your comments on my thoughts. Regards, A. Palanivelan -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net] Sent: Friday, October 29, 2010 10:34 PM To: Palanivelan A (apvelan) Cc: rtg-bfd WG Subject: Re: draft-palanivelan-bfd-v2-gr-08 On Oct 29, 2010, at 12:33 AM, Palanivelan A (apvelan) wrote: > My experience with the process is not much to talk about but let me > confirm it is not easy even to get it to Historic :). > I loved to be part of working group in working through this document and > unfortunately it did not happen. > > Any good suggestions in how to go about, I would love to take it Dave. If the group thinks it to be worthwhile (I personally think it would be), it would be quite valuable to discuss the GR issues on this list, particularly any that you've run across that we did not foresee, with the goal of producing a BCP that more thoroughly documents how the various pieces of BFD and the control protocols might be pulled together to achieve GR. If you feel that our technical evaluation of your proposal is in error, or that the existing mechanisms are insufficient and yours adds value, that would be extremely helpful as well. Thanks, --Dave
- draft-palanivelan-bfd-v2-gr-08 Santosh P K
- Re: draft-palanivelan-bfd-v2-gr-08 Dave Katz
- RE: draft-palanivelan-bfd-v2-gr-08 Palanivelan A (apvelan)
- Re: draft-palanivelan-bfd-v2-gr-08 Dave Katz
- Re: draft-palanivelan-bfd-v2-gr-08 Donald Eastlake
- Re: draft-palanivelan-bfd-v2-gr-08 Dave Katz
- Re: draft-palanivelan-bfd-v2-gr-08 Donald Eastlake
- RE: draft-palanivelan-bfd-v2-gr-08 Palanivelan A (apvelan)
- Re: draft-palanivelan-bfd-v2-gr-08 Dave Katz
- RE: draft-palanivelan-bfd-v2-gr-08 Palanivelan A (apvelan)
- RE: draft-palanivelan-bfd-v2-gr-08 Palanivelan A (apvelan)
- Re: draft-palanivelan-bfd-v2-gr-08 Nitin Bahadur
- RE: draft-palanivelan-bfd-v2-gr-08 Jeff Tantsura
- RE: draft-palanivelan-bfd-v2-gr-08 Palanivelan A (apvelan)