Re: iBGP route oscillation drafts

"John G. Scudder" <jgs@cisco.com> Thu, 30 May 2002 14:44 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23109 for <idr-archive@nic.merit.edu>; Thu, 30 May 2002 10:44:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C16FD9127E; Thu, 30 May 2002 10:41:35 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AB6F91281; Thu, 30 May 2002 10:41:35 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC55E9127E for <idr@trapdoor.merit.edu>; Thu, 30 May 2002 10:41:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5E6AE5DE87; Thu, 30 May 2002 10:41:24 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id C40BB5DDB7 for <idr@merit.edu>; Thu, 30 May 2002 10:41:23 -0400 (EDT)
Received: from [171.69.182.155] (dhcp-171-69-182-155.cisco.com [171.69.182.155]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA14649; Thu, 30 May 2002 10:37:38 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a15b91be5c0027c@[171.69.182.155]>
In-Reply-To: <3CF62B7A.A5C592AF@research.bell-labs.com>
References: <C61C9973831E2949A9AA57F3B03184641DC8AF@exch-srv.CoronaNetworks.com> <3CF62B7A.A5C592AF@research.bell-labs.com>
Date: Thu, 30 May 2002 10:37:10 -0400
To: Anindya Basu <basu@research.bell-labs.com>
From: "John G. Scudder" <jgs@cisco.com>
Subject: Re: iBGP route oscillation drafts
Cc: Brijesh Kumar <Brijesh@coronanetworks.com>, gtw@lucent.com, anindyabasu <anindyabasu@lucent.com>, bshep@lucent.com, idr@merit.edu
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-idr@merit.edu
Precedence: bulk

At 9:39 AM -0400 5/30/02, Anindya Basu wrote:
...
>Brijesh Kumar wrote:
>>2. I am curious to know if the problem is existent in real networks 
>>beyond pathological scenario depicted in the draft as to merit 
>>announcements and storage of multiple routes at the routers. I find 
>>it too drastic a proposal for a problem whose existence/severity 
>>seems to be based on a simple paper scenario (unless I see 
>>reference 5). After all, it proposes to do away the most 
>>stabilizing BGP/distance vector protocol rule that a peer will 
>>advertise only its best route to its neighbour.
>
>in case you have completely missed it (though it is in the references),
>the original problem was outlined in an ID (reference [3]) by McPherson
>et. al. and actually stems from a cisco field report called "Endless BGP
>Convergence Problem in Cisco IOS Software Releases", October 10, 2000.
>is that real enough?

The MED problem is real enough.  However, as we've been discussing in 
a different thread, your proposal is more far-reaching than just 
addressing [3].  Specifically:

At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
>However, our aim was to address the elimination of any possible kind 
>of oscillation in I-BGP, MED-induced or not, persistent or not.

That's laudable in the abstract but inevitably leads to the 
requirement that you advertise more additional routes than required 
to fix specifically [3].

My take on the subject is that while theoretical protocol correctness 
is an admirable goal, it's not more important than scalability. 
Protocol scalability plus _practical_ protocol correctness is more 
important, IMO.

As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
>Admittedly, the configuration in Figure 1 is not likely in a 
>reasonable network.

I think the IDR working group should be primarily concerned with 
reasonable networks.  Fixing problems for unreasonable (or 
hypothetical) networks seems fine as long as it doesn't conflict with 
the operation and scaling of reasonable ones.

Do you disagree?

Regards,

--John