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

Jakob Heitz <jakob.heitz@ericsson.com> Tue, 15 November 2011 04:54 UTC

Return-Path: <jakob.heitz@ericsson.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 8B7B11F0C5E for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 20:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.213
X-Spam-Level:
X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 WHq4nwmred18 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 20:54:05 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 775E51F0C4F for <sidr@ietf.org>; Mon, 14 Nov 2011 20:54:04 -0800 (PST)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAF4s2k9028088; Mon, 14 Nov 2011 22:54:03 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 Nov 2011 23:53:58 -0500
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: "George, Wes" <wesley.george@twcable.com>, Randy Bush <randy@psg.com>
Date: Mon, 14 Nov 2011 23:51:51 -0500
Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQAACGhYAAApkZwAAAhpQA
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se>
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>
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD4656937791452387978@PRVPEXVS03.corp.twcable.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 04:54:06 -0000

> From: George, Wes [mailto:wesley.george@twcable.com]
> Sent: Monday, November 14, 2011 7:04 PM
> To: Jakob Heitz; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
> 
> > 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.

Great, so you don't disagree that beacons mostly cause no change.
That should cover the bulk of BGPSEC updates.

That brings us a long way down from 2X.

Now, for a regular update that changes the bestpath, the signature
will likely come later (in my proposal). If it replaces an existing
valid path, the bestpath will not change until the signature arrives.
If it replaces no path, then the regular update will produce a bestpath
change, but the signature will not.

In the unlikely event that the signature arrives first, the bestpath
may change twice.

> 
> Wes George

--
Jakob Heitz.