[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