Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

["George, Wesley" <[e-mail]>]

-----Original Message-----
From: Sriram, Kotikalapudi [mailto:[e-mail]]
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 towards 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.