Re: [sidr] Burstiness of BGP updates

Eric Osterweil <eosterweil@verisign.com> Thu, 17 November 2011 06:04 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583A111E80EF for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 22:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level:
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi6aAW+RdhHd for <sidr@ietfa.amsl.com>; Wed, 16 Nov 2011 22:04:18 -0800 (PST)
Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id F0A5711E80D1 for <sidr@ietf.org>; Wed, 16 Nov 2011 22:04:16 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKTsSjvu7K9vFd3+SIGGCKssYg5Px6xRB3@postini.com; Wed, 16 Nov 2011 22:04:17 PST
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAH63fQ3025035; Thu, 17 Nov 2011 01:03:41 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 01:03:40 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <4EC48834.9060805@riw.us>
Date: Thu, 17 Nov 2011 14:03:30 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A0FB7C4-47D0-4E95-A209-BC0DE87DB501@verisign.com>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <E2D346C7800D704DB41ED19D90434DA6320C15DF93@ESESSCMS0358.eemea.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <CAL9jLabyymUZJRk44Z00UeQsxinN5D-05-7_htmRanYwi7ysvQ@mail.gmail.com> <4EC462E9.7090103@riw.us> <m2wraz4j68.wl%randy@psg.com> <4EC4684B.3030204@riw.us> <m2ty634ie7.wl%randy@psg.com> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <m2k46z4f1d.wl%randy@psg.com> <4EC48834.9060805@riw.us>
To: Russ White <russw@riw.us>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 17 Nov 2011 06:03:41.0745 (UTC) FILETIME=[A82ACA10:01CCA4EE]
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2011 06:04:19 -0000

On Nov 17, 2011, at 12:06 PM, Russ White wrote:

> 
>>> Maybe this discussion could be viewed as a good motivation for
>>> revisiting the requirements draft.
>> 
>> don't require what you have no solid idea of how to achieve.
> 
> Maybe if someone actually laid out real requirements, someone,
> someplace, could determine how to achieve most (if not all) of them. The
> process SIDR has used is backwards --choose a solution, then build the
> requirements around that solution. When problems arise, just change the
> requirements so it's no longer a problem.


Totally agree w/ u here, Russ...

Randy, we are all arguing over what we think a secure routing system should do... It sounds like you (and your team?) have already decided what you think everyone's requirements are, but it's pretty plain to all that a fair number of people here in the wg do not agree.  One of the main reasons software systems begin with requirements analysis is precisely so that we can know if our solution meets our needs.  As I said before, if we wind up needing to rework our collective requirements, then so be it, but this process needs to be followed, not skipped.  Even your above comment has taken this out of order (skipping a requirement because you think you can't do it implies a design attempt); requirements come first... ;)

Eric