Hi Jakob,
If we reprioritise BGPSec, we could make it work. Sugestion:
during bringup, send routes without the BGPSec attribute.
I think there is a significant risk that this would cause unnecessary
Internet wide churn.
I would propose and alternative approach. To send the routes with
whatever attributes sender decides to send then with and do it only once.
Up-on reception if indeed inline CPU processing is an issue on given
platform store the BGPSec related attributes without any processing then
when CPU get's idle .. verify them.
Hoping that only small fraction of all routes could be considered
invalid you may later withdraw them.
Of course this only attempts to fix inbound processing issue. You can
not do the same when signing the routes outbound.
---
It keeps me puzzled why sidr is so stuck on BGP inbound solution as
opposed on number of proposals which deliver the same results using out
of BGP bound control plane verification.
Cheers,
R.
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
