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

"George, Wesley" <wesley.george@twcable.com> Mon, 12 September 2011 14:38 UTC

Return-Path: <wesley.george@twcable.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 8A87A21F853E for <sidr@ietfa.amsl.com>; Mon, 12 Sep 2011 07:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.166
X-Spam-Level:
X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 bu4E2dldOcf6 for <sidr@ietfa.amsl.com>; Mon, 12 Sep 2011 07:38:07 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D131321F851A for <sidr@ietf.org>; Mon, 12 Sep 2011 07:38:06 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.67,514,1309752000"; d="scan'208";a="272352081"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Sep 2011 10:37:42 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 12 Sep 2011 10:40:09 -0400
From: "George, Wesley" <wesley.george@twcable.com>
To: Russ White <russw@riw.us>, Jakob Heitz <jakob.heitz@ericsson.com>
Date: Mon, 12 Sep 2011 10:40:08 -0400
Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Thread-Index: AcxvD4UVOvAgTuWsSVOwGDihofgevgCSS6iw
Message-ID: <34E4F50CAFA10349A41E0756550084FB0E26AD5B@PRVPEXVS04.corp.twcable.com>
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> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <m2ipp4qxs5.wl%randy@psg.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <D4059E53-6EEC-4F66-9E1E-B96675182F22@rob.sh> <m2wrdhvjpe.wl%randy@psg.com> <4E6A2CD0.1010305@riw.us> <m2pqj9vgc8.wl%randy@psg.com> <4E6A3D30.9030605@riw.us> <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com> <4E6A420C.1020203@riw.us>
In-Reply-To: <4E6A420C.1020203@riw.us>
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
Cc: "sidr@ietf.org" <sidr@ietf.org>
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: Mon, 12 Sep 2011 14:38:07 -0000

-----Original Message-----
From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Russ White
Sent: Friday, September 09, 2011 12:43 PM
To: Jakob Heitz
Cc: sidr@ietf.org
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

You could make it cheaper by moving
specific things off the router and onto auxiliary boxes, but the point
of inline authentication is _not_ to move anything onto boxes outside
the router (or even onto line cards within the router) --this is the
reason all overlay proposals were rejected up front.

WEG] I think that this looks at the separation between forwarding and compute resources a bit too narrowly. As Shane pointed out in an earlier thread, there are some implementations where the forwarding hardware and the routing/general compute hardware are far too closely linked together in the way that they grow and scale. Perhaps the solution is to stop trying to cram new magic into RP slots and start pushing the external processing model where the compute resources are physically, but not logically separate (eg a blade center with a fabric interface, not a standalone route server) so that computing (routing) and forwarding can scale independently. It still ends up with a model where you're throwing more CPU resources at the problem instead of fixing the underlying internet routing scale problem, but perhaps that kicks the can far enough down the road to be acceptable because it puts things back on a commodity PC hardware growth and cost curve.

Wes

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.