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

"George, Wes" <wesley.george@twcable.com> Tue, 15 November 2011 03:03 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 CE1E11F0D92 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 19:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.774
X-Spam-Level:
X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=0.462, 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 uPwrAhBiBsqw for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 19:03:33 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0B41F0D8E for <sidr@ietf.org>; Mon, 14 Nov 2011 19:03:33 -0800 (PST)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,511,1315195200"; d="scan'208";a="297399594"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Nov 2011 21:58:56 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 14 Nov 2011 22:03:24 -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 22:03:49 -0500
Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQAACGhYAAApkZwA==
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@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>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se>
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 03:03:34 -0000

> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]
> Sent: Monday, November 14, 2011 8:47 PM
> To: George, Wes; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-
> sidr-bgpsec-reqs)
>
> I can not believe that it will be 2X.

[WEG] the objective amount of impact is probably not the important bit here.

>
> First case: A beacon will very rarely cause a different bestpath.
[WEG] True. However... your comment was not specific to beacons. Also when it does, it makes the load problem you're trying to solve worse.
>
> Second case: There is actually a changed route being updated.
> You will receive both a regular update and a signature.
> Only one of those will casue a new bestpath in the great majority of
> cases.
>
> Basically, in the large majority of cases, a signature does not change
> the bestpath.
>
[WEG] Not true. Bestpath in BGPSec land is chosen based on policy informed by the difference between valid, invalid and unknown. Even if the absence or presence of the signature only toggles the route between valid and unknown, given that those have a defined policy action (eg raise or lower local pref, etc), the only way to ensure that receiving a signature later than the initial route update does not trigger a change of best path (let alone a recompute that doesn't trigger a change, which probably has nearly the same impact) is to set ones policy such that unknown and valid are the same preference. While that may be reasonable in early incremental deployment, eventually I don't think that's a safe assumption, and really eventually is when we have a scaling problem, not in early deployment.

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.