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

"George, Wes" <wesley.george@twcable.com> Tue, 15 November 2011 01:37 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 75A7221F8E80 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 17:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.765
X-Spam-Level:
X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=0.471, 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 uijBEtISNqDq for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 17:37:03 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E381F21F8E7F for <sidr@ietf.org>; Mon, 14 Nov 2011 17:37:02 -0800 (PST)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,511,1315195200"; d="scan'208";a="297386228"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Nov 2011 20:32:32 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 14 Nov 2011 20:37:00 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>, Randy Bush <randy@psg.com>
Date: Mon, 14 Nov 2011 20:37:24 -0500
Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQ
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791452387941@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>
In-Reply-To: <CCE759E6-BEA6-433B-957A-6559C67BAD52@ericsson.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 01:37:03 -0000

> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Jakob Heitz
>
> The difference is that today's updates all have the same urgency.
> BGPSEC is not urgent. It doesn't matter if you don't receive a
> signature for a few minutes.
> An UNREACH is not signed.

[WEG] I don't totally agree with this characterization. If the BGPSec info triggers a recalculation of bestpath from what was chosen when the unsigned update came through, this has the potential to drive 2x the work, essentially take 2x longer for convergence, plus push another round of updates to downstream neighbors, another reprogram of the FIB, etc. Seems to me by the time we've gained any benefit of saving updates for later because the box is busy, we've triggered a far worse potential death spiral on a busy box. Processing a few additional updates is rather pale in comparison to having to consistently recalculate a non-trivial percentage of the table when the box gets "busy."
Similar to buffering and QoS, you can't get something for nothing here, and there are limits to where deferred processing can help to smooth out peaks vs. simply throwing more capacity at the problem, especially in the land of often underutilized multi-core systems.

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.