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

[Jakob Heitz <[e-mail]>]

> From: George, Wes [mailto:[e-mail]]
> 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:[e-mail]]
> > 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.