Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Jakob Heitz <jakob.heitz@ericsson.com> Thu, 08 September 2011 19:44 UTC
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F8C21F869C for <sidr@ietfa.amsl.com>; Thu, 8 Sep 2011 12:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.141
X-Spam-Level:
X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqhdp1gSI1Hw for <sidr@ietfa.amsl.com>; Thu, 8 Sep 2011 12:44:41 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A455521F8686 for <sidr@ietf.org>; Thu, 8 Sep 2011 12:44:41 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p88JkTpW018189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sidr@ietf.org>; Thu, 8 Sep 2011 14:46:34 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 8 Sep 2011 15:46:29 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: sidr wg list <sidr@ietf.org>
Date: Thu, 08 Sep 2011 15:46:28 -0400
Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Thread-Index: AcxXlRYzx19OWW9WR+qLPmTOJN+B3gAtymVABVV7wuAAKuVRUAADmgJw
Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A2F61F34@EUSAACMS0701.eamcs.ericsson.se>
References: <A37CADA4-F16D-4C01-8D9C-D01001C4EFE4@tcb.net> <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <B92913D1-AB82-4D9F-B8A9-F8F4F99713D6@tcb.net> <p06240803ca685bff5443@[128.89.89.43]> <D6D12861-412E-4A65-B626-B627449981B8@tcb.net> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <D7A0423E5E193F40BE6E94126930C49308D36D8383@MBCLUSTER.xchange.nist.gov> <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com>
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 19:44:42 -0000
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:kotikalapudi.sriram@nist.gov] > 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Jakob Heitz. x25475. 510-566-2901
- [sidr] beacons and bgpsec Danny McPherson
- Re: [sidr] beacons and bgpsec George Michaelson
- Re: [sidr] beacons and bgpsec Danny McPherson
- Re: [sidr] beacons and bgpsec George Michaelson
- Re: [sidr] beacons and bgpsec Danny McPherson
- Re: [sidr] beacons and bgpsec George Michaelson
- Re: [sidr] beacons and bgpsec Randy Bush
- Re: [sidr] beacons and bgpsec Danny McPherson
- Re: [sidr] beacons and bgpsec Paul Hoffman
- Re: [sidr] beacons and bgpsec Danny McPherson
- Re: [sidr] beacons and bgpsec Montgomery, Douglas
- Re: [sidr] beacons and bgpsec Jakob Heitz
- Re: [sidr] beacons and bgpsec Stephen Kent
- Re: [sidr] beacons and bgpsec Stephen Kent
- Re: [sidr] beacons and bgpsec Sandra Murphy
- Re: [sidr] beacons and bgpsec Sandra Murphy
- Re: [sidr] beacons and bgpsec Stephen Kent
- Re: [sidr] beacons and bgpsec Danny McPherson
- Re: [sidr] beacons and bgpsec Jakob Heitz
- Re: [sidr] beacons and bgpsec Sandra Murphy
- Re: [sidr] beacons and bgpsec Jakob Heitz
- Re: [sidr] beacons and bgpsec Geoff Huston
- [sidr] BGPSec scaling (was RE: beacons and bgpsec) George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Rob Shakir
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Jakob Heitz
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Rob Shakir
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… t.petch
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Smith, Donald
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Robert Raszuk
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Sriram, Kotikalapudi
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Shane Amante
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… t.petch
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Rob Shakir
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Jakob Heitz
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Robert Raszuk
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Sriram, Kotikalapudi
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Sriram, Kotikalapudi
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Russ White
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Russ White
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Jakob Heitz
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Russ White
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Christopher Morrow
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Jakob Heitz
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Sriram, Kotikalapudi
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Sriram, Kotikalapudi
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Sriram, Kotikalapudi
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Jakob Heitz
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Randy Bush
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Robert Raszuk
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… George, Wesley
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Christopher Morrow
- Re: [sidr] BGPSec scaling (was RE: beacons and bg… Rob Shakir