Re: [Idr] Revised proposed IDR charter

"John G. Scudder" <jgs@juniper.net> Wed, 03 February 2010 11:40 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2001228C148 for <idr@core3.amsl.com>; Wed, 3 Feb 2010 03:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599]
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 mSA8Z2vDV1Qx for <idr@core3.amsl.com>; Wed, 3 Feb 2010 03:40:49 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3249C3A6C2B for <idr@ietf.org>; Wed, 3 Feb 2010 03:40:46 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKS2lg583b4IDWEx7B03aHsY8kOKc5IFkw@postini.com; Wed, 03 Feb 2010 03:41:31 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 3 Feb 2010 03:40:46 -0800
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 03:40:46 -0800
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 03:40:46 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 03:40:45 -0800
Received: from sa-nc-apg-236.static.jnpr.net (sa-nc-apg-236.static.jnpr.net [172.23.2.236]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o13Beej06143; Wed, 3 Feb 2010 03:40:41 -0800 (PST) (envelope-from jgs@juniper.net)
MIME-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <1D51EAE9-FBFC-450A-9F95-9932086A667C@tcb.net>
Date: Wed, 03 Feb 2010 13:40:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <D6FF49CD-02A5-41ED-9533-2633419E593A@juniper.net>
References: <52635EAD-5E0B-4975-BFA5-B315036F59C8@juniper.net> <1D51EAE9-FBFC-450A-9F95-9932086A667C@tcb.net>
To: Danny McPherson <danny@tcb.net>
X-Mailer: Apple Mail (2.1077)
X-OriginalArrivalTime: 03 Feb 2010 11:40:46.0005 (UTC) FILETIME=[B96EF650:01CAA4C5]
Cc: idr List <idr@ietf.org>, "idr-chairs@tools.ietf.org" <idr-chairs@tools.ietf.org>, "idr-ads@tools.ietf.org" <idr-ads@tools.ietf.org>
Subject: Re: [Idr] Revised proposed IDR charter
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 11:40:50 -0000

On Feb 1, 2010, at 9:58 AM, Danny McPherson wrote:
>> - Advertisement of the best external route in BGP to assist with
>> resolution of the next hop in the chosen data plane.
> 
> Any chance we could add something here about minimizing BGP state, 
> everyone one of the options above aims to expand the number of 
> unique routes, whereas RRG and all the rest of the world are working
> on scalability - all of this stuff seems to only lead to additional 
> state and churn to me.

One more thing -- you say "all of this stuff seems to only lead to additional state and churn".  I would say rather, that state and churn are to some extent two different axes of the optimization space.  You can reduce state (imagine a route reflector hierarchy with no redundancy) but at the cost of greater churn (many messages exchanged both through that hierarchy and externally while converging to a new best path).  Or you can accept additional state (think of a flat IBGP mesh) which reduces churn because backup paths may already be present.  The challenge would seem to be finding the sweet spot in the optimization space.  Analysis on this has been presented at IDR, as recently as last meeting (the add-path mode analysis).  

In general, a lot of work I'm aware of (in IDR and elsewhere) on maximizing connectivity trades state for stability or restoration time.  If you have some analysis which supports the counterproposal that state and churn are positively coupled (either in general, or in specific proposals) it would be great if you wrote a draft laying out the details.

I'd also like to propose that as a basic goal, "maximizing global connectivity" is more fundamental than "reducing churn".  One may imply the other, but you know what they say about unquestioned assumptions.

--John