[Idr] draft-chen-bgp-avoid-transition-00.txt
Tom Barron <tbarron@cisco.com> Mon, 10 November 2003 17:47 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02932; Mon, 10 Nov 2003 12:47:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJG8N-0001Dw-00; Mon, 10 Nov 2003 12:47:27 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJG8N-0001Dr-00; Mon, 10 Nov 2003 12:47:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJG7y-00059i-9c; Mon, 10 Nov 2003 12:47:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJG7C-00057R-Pi for idr@optimus.ietf.org; Mon, 10 Nov 2003 12:46:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02826 for <idr@ietf.org>; Mon, 10 Nov 2003 12:46:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJG7B-0001CO-00 for idr@ietf.org; Mon, 10 Nov 2003 12:46:13 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AJG7A-0001BQ-00 for idr@ietf.org; Mon, 10 Nov 2003 12:46:12 -0500
Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAAHjdDM013806 for <idr@ietf.org>; Mon, 10 Nov 2003 12:45:40 -0500 (EST)
Received: (from tbarron@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA11950; Mon, 10 Nov 2003 11:45:39 -0600 (CST)
From: Tom Barron <tbarron@cisco.com>
To: idr@ietf.org
Cc: Thomas P Barron <tbarron@cisco.com>
Message-ID: <20031110174539.GA166@cfcentral.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Subject: [Idr] draft-chen-bgp-avoid-transition-00.txt
Sender: idr-admin@ietf.org
Errors-To: idr-admin@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 10 Nov 2003 11:45:39 -0600
Enke, Srihari, et. al: I have some questions about draft-chen-bgp-avoid-transition-00.txt. I'm glad to see this draft since there are implementations out there using the route-selection algorithm this draft proposes, and since the proposed algorith is not what is documented in RFC1771 or in draft-ietf-idr-bgr4-22.txt section 9.1.2.2. First, is it the intent of this draft that the proposed algorithm should *replace* the algorithm currently documented, or just that it be added as an option? Second, while I think the claim in 5.1 that the proposed algorithm avoids an unnecessary best path transition is quite straightforward, there ought to be some discussion of concerns that have been expressed about the consequent lack of determinism in route selection. See for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt and appendix A of "Guidelines for Interdomain Traffic Engineering" by Feamster, Borkenhagen, and Rexford. I'm not personally convinced that this local indeterminism is a real big deal, but I do think it needs some discussion in your draft. Third, I found the argument at 5.2 to the effect that the proposed algorithm reduces route oscillation a bit unclear. Maybe just a bit more text is needed, but it seems to me that the really essential ingredient in your setup in figure 1 and figure 2 is not the router ID, but the high intracluster IGP metric. Indeed, though you cite RFC3345, that work focuses on IGP metrics, not router ID, as a critical factor for "type 1" oscillation scenarios (yours appears to be a type 1 variant.) If adjusting IGP metrics is sufficient to fix both your oscillation scenario and other type 1 scenarios, but shifting from Router ID selection to the proposed time-of-arrival algorithm is not sufficient for type 1 scenarios in general, then the contribution of the proposed algorithm to the route oscillation problem does not seem very decisive. On the other hand, if using the proposed time-of-arrival algorithm yields a general solution to oscillation problems, then this reader at least did not get that from the draft as currently written. I'm glad you folks wrote this draft. I hope it's clear that I'm not against your proposal, but rather want to address some gaps in my own understanding of the issues that surround it. - Tom Barron _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr
- draft-chen-bgp-avoid-transition-00.txt Enke Chen
- [Idr] draft-chen-bgp-avoid-transition-00.txt Tom Barron