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

"George, Wesley" <wesley.george@twcable.com> Wed, 07 September 2011 18:55 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 5F3C021F8CDF for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2011 11:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level:
X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=0.317, 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 kXh9RbTNEfRU for <sidr@ietfa.amsl.com>; Wed, 7 Sep 2011 11:55:32 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B978521F8CDC for <sidr@ietf.org>; Wed, 7 Sep 2011 11:55:32 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.67,493,1309752000"; d="scan'208";a="270830614"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Sep 2011 14:55:03 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 7 Sep 2011 14:57:22 -0400
From: "George, Wesley" <wesley.george@twcable.com>
To: Randy Bush <randy@psg.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Date: Wed, 07 Sep 2011 14:57:21 -0400
Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
Thread-Index: AcxtYzyHBnyJQC9FTH+zb2RjrWNOEQAAVXWA
Message-ID: <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@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>
In-Reply-To: <m2ipp4qxs5.wl%randy@psg.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
Cc: sidr wg list <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: Wed, 07 Sep 2011 18:55:33 -0000

-----Original Message-----
From: Randy Bush [mailto:randy@psg.com]
Sent: Wednesday, September 07, 2011 9:37 AM
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

lots of great opinions, but are there actually any measurements or
models?

WEG] Please be more specific. What other models and measurements than the one already provided by NIST are you asking for? That model already tells me that BGPSec will significantly change the routing table scaling curve from today, with some variation on the steepness of the change possible based on variables and optimization. Your non-response to the concern about whether the situation articulated by 4984, & 6227 has changed in some material way as to make it no longer an issue for BGPSec is telling. Let's keep turning up the heat and hope that the frog doesn't notice until it's too late...

My guess from your response above is that you're looking for some anecdotal evidence of equipment lifetimes in real networks to support Rob's assertion that 5 years may not be a realistic event horizon, so I'll take a stab at that.

There are plenty of 15-year old routing platforms still in service, despite YFV's best efforts to make them obsolete.
Only recently has a combination of End of Support and a need for new features and higher density driven the oldest of the hardware (GSR E0, 1, 2, 4/4+, 10720, the 7200 and 7500 in Ciscoland) out of the network. Some of that stuff dated back to the early 2000s and was just removed in the last 12-24 months. Most accounting still assumes at least a 7-year depreciation cycle, and that seems somewhere between appropriate and optimistic, given that a lot of the gear was closer to 8 or even 10 years old at retirement.
On the route processor side, which is probably most pertinent to this discussion, upgrades were almost exclusively driven by the memory requirements of the routing table + the code footprint. RPs are either purchased with max supported memory so that they don't have to be touched again, (because touches are expensive) or they are upgraded periodically because the max has been increased. So the next replacement-level upgrade happens when the current max (4Gig in the last round of upgrades) isn't enough, which will take a while with just organic DFZ routing growth. My recollection was about a 6 year total replacement cycle. However, in hard-core bellhead beancounter circles, the concept of needing to invest in upgrades to a routing platform beyond adding raw port capacity every few years is totally foreign, because they have DMS-250 and DCS systems that have been in the network since Moses gave them the owner's manual on stone tablets and are still generating revenue with only occasional replacement parts. Something like BGPSec makes the discussion with the finance people all the more fun, because now we're having to justify spending significantly more on gear that does not directly translate to additional revenue port capacity, vs justifying "must do x to keep the network from falling over."
In zero-margin "race to the bottom" networks, that's not trivial.

Thanks,

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.