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

Jakob Heitz <> Mon, 14 November 2011 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6A5311E8086 for <>; Mon, 14 Nov 2011 04:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.186
X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OrsYpUgPNJa7 for <>; Mon, 14 Nov 2011 04:25:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D674521F8D6D for <>; Mon, 14 Nov 2011 04:25:55 -0800 (PST)
Received: from ([]) by (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAECPpck009210; Mon, 14 Nov 2011 06:25:53 -0600
Received: from ([]) by ([]) with mapi; Mon, 14 Nov 2011 07:25:47 -0500
From: Jakob Heitz <>
To: "Sriram, Kotikalapudi" <>, Brian Dickson <>
Date: Mon, 14 Nov 2011 07:25:45 -0500
Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
Thread-Index: AQHMor5xosDF2n1HPkGttBtzThsGyZWsRYYQ
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sidr wg list <>
Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2011 12:25:56 -0000

It will be as bursty as the sender of the bursts pleases.

A great way for the receiver of those non-urgent bursts
to insulate itself is to send them in a different tcp
session than regular BGP updates. It can then throttle
the BGPSEC bursts without affecting regular BGP.

If you consider a BGPSEC update only to be a signature
for a regular update, then there is no race condition.

In other words, to advertise a route, BGP needs
to send an unsigned update in the regular session,
as well as a signed one in the non-urgent BGPSEC

An unsigned route is still useable in the absence of
a signed one. It is simply "NotFound" instead of "Valid".

If you put the BGPSEC traffic into a separate non-urgent
session, this spruce goose might just get off the ground.

Jakob Heitz.

> -----Original Message-----
> From: [] On Behalf
> Of Sriram, Kotikalapudi
> Sent: Monday, November 14, 2011 3:14 AM
> To: Brian Dickson
> Cc: sidr wg list
> Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
> Brian,
> For BGP-4 updates, Geoff does provide the peak numbers observed for
> prefix updates in 1 second intervals.
> For example:
> Peak Prefix Update Rate per second:  1539
> while
> Average Prefix Updates per second:  2.76 I suspect the peak perhaps
> corresponds to BGP session reset events when updates are generated
> back-to-back.
> If you exclude those reset events, then BGP-4 chattiness will have
> low variance.
> Since we do not have operational BGPSEC yet, we cannot obtain
> similar measurements at present. But I am confident that if you
> focus on BGPSEC chattiness only due to beaconing (i.e., exclude BGP
> session resets events), then the burstiness (of BGPSEC beacons
> alone) will be low.
> Bear in mind that the protocol recommends beacons should be jittered
> in time, and when thousands of prefixes are beaconed in a time-
> jittered fashion from distributed sites, they smooth out and the
> resulting beacon arrival process at a router would be a rather
> smooth Poisson process (variance/mean = 1).
> So the peak # beacons in n-second intervals (for n>=1) will likely
> be a small multiple of the mean # beacons in n-second intervals.
> Again mind you, on the otherhand, if BGPSEC session resets occur,
> then that would be quite different -- thousands of BGPSEC updates
> (not beacons) would be sent back-to-back in that case between the
> two affected peers.
> It may be noted that operators are anyway used to allowing 10s of
> seconds for table convergence after session resets.
> (You will see an analysis of convergence following BGPSEC session
> reset
> in the presentation that Randy and I have in the SIDR WG meeting
> tomorrow.)
> Sriram
> ________________________________________
> >From: Brian Dickson []
> >
> >Hi, Sriram,
> >
> >Could you supply similar kinds of numbers, but with "peak" instead
> of
> >"average", esp. 50%ile, 75%ile,  and 95%-ile levels for "peak"?
> >
> >Average is much less important than peak, in my experience.
> >Steady-state is easy.
> >
> >Also, in noisy/spiky data, mean != median typically. BGP is
> noisy/spiky.
> >
> >(Also when doing percentiles, it is essential to say, "95%ile on
> >5-minute samples, over a period of 1 week" for instance - and those
> >would be the customary sample windows to use.)
> >
> >Thanks,
> >Brian
> _______________________________________________
> sidr mailing list