A router that implements BGPSec will *always* use more memory and more CPU that one that doesn't.
CPU --- A router has a powerful CPU mainly to converge when it comes up and when a neighboring router comes up or goes down. During normal operation, it is largely unused. If we reprioritise BGPSec, we could make it work. Sugestion: during bringup, send routes without the BGPSec attribute. Once converged, during low CPU usage, send them again with the BGPSec attribute. Call this the first beacon. When receiving routes, delegate the BGPSec verification to a low priority task. Memory ------ Because BGPSec operations do not affect convergence (we send without BGPSec attribute to achieve convergence), it can use slower, cheaper memory like a hard disk or flash disk. Downside -------- There will be a few minutes after router bringup when unverified routes exist. Unverified routes can be given a lower preference. On Thursday, September 08, 2011 12:13 PM, George, Wesley <> wrote: > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:[email protected]] > Sent: Wednesday, September 07, 2011 5:52 PM > To: George, Wesley; sidr wg list > Subject: RE: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > >> >> As far as where this leaves BGPSec, I don't know. Perhaps a solution >> comes in the form of some of us starting to champion the necessary >> work to move one or more of the better ideas from RRG into >> implementation so that the underlying scaling problem is being >> addressed in parallel. It should be quite possible to incorporate >> improvements to route security into whatever must already be done to >> improve scale, and even if not, these are two things that both share >> a barrier to deployment, especially incrementally, and would >> certainly benefit from being designed and deployed in concert >> instead of in separate silos. > > Wes, > > Sorry for the belated response -- I was away in India on vacation :) > We had some discussion earlier on this list about > BGPSEC in conjunction with an RRG scalability solution (e.g., LISP). > (You might have seen these posts back in May, but just in case.) > > http://www.ietf.org/mail-archive/web/sidr/current/msg02836.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02837.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02847.html > > These posts relate only to the above noted comment from you > (but not directly to a different question you've raised > w.r.t. the concerns in 4984/6227). > > WEG] Sriram - thanks for the pointers, but all this really tells me > is that I'm not the first one to point out a potential problem here. > The issue with making any assumption of a solution means that we're > essentially closing our eyes and hoping that someone else figures > this out before the world ends. My point is that we have to take a > more active role in bringing this back to the forefront of the > discussion in IETF because we stand to be impacted by delays in > finding a solution. If the timing is wrong, it ends up being gating > to deployment of BGPSec. If the timing is right, it probably requires > a lot of redesign work and additional investment, neither of which > are particularly optimal. I'd prefer that we document up-front that > there is a real concern here and that IETF needs to get moving on the > scale problem, in some way other than endless debate over options > within RRG. Even making a decision as to which direction to go (map > and encap vs L/I split) would move a long way to wards allowing other > things like BGPSec to optimize their designs accordingly. > > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr -- Jakob Heitz. x25475. 510-566-2901 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
