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

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
session.

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: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] 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.
> http://bgpupdates.potaroo.net/instability/bgpupd.html
> 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 [brian.peter.dickson@gmail.com]
> >
> >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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr