IETF Logo Mail Archive

Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)

"George, Wes" <wesley.george@twcable.com> Tue, 15 November 2011 05:46 UTC

Return-Path: <wesley.george@twcable.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 19A6811E817A for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 21:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.783
X-Spam-Level:
X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
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 fHBCk9q7yQbT for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 21:45:58 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5E11E809C for <sidr@ietf.org>; Mon, 14 Nov 2011 21:45:51 -0800 (PST)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,512,1315195200"; d="scan'208";a="297417091"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Nov 2011 00:41:21 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 15 Nov 2011 00:45:49 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Date: Tue, 15 Nov 2011 00:46:13 -0500
Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
Thread-Index: AcyjVZuiqzXhBLugQpm8ls4lPTtADQAA0NRA
Message-ID: <DCC302FAA9FE5F4BBA4DCAD46569377914523879C5@PRVPEXVS03.corp.twcable.com>
References: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov> <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <m2fwhqeq5i.wl%randy@psg.com> <CCE759E6-BEA6-433B-957A-6559C67BAD52@ericsson.com> <DCC302FAA9FE5F4BBA4DCAD4656937791452387941@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@PRVPEXVS03.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <CAH1iCioH+c1AY61wEByYzG9TOPiqOExAoo9W2vtuT+Bpnor58Q@mail.gmail.com>
In-Reply-To: <CAH1iCioH+c1AY61wEByYzG9TOPiqOExAoo9W2vtuT+Bpnor58Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
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: Tue, 15 Nov 2011 05:46:12 -0000

> From: Brian Dickson [mailto:brian.peter.dickson@gmail.com]
> Sent: Tuesday, November 15, 2011 12:16 AM

> Sorry to jump in here, but I think that there is a drifting into
> conjecture...
>
> It would be best to stay within the realm of facts.

[WEG] To clarify, the issue got conflated between the impact of simple beacon updates and the case where an actual route update comes in, but the signature is processed after the update is processed, potentially triggering a route recalc.
Route recalc does mean 2x the processing, WHEN it happens, but it will not happen in all cases. My apologies for being unclear.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

v2.27.8 | Report a Bug | By Email | System Status