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: [email protected] [mailto:[email protected]] 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 [[email protected]] > > > >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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
