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

[Shane Amante <[e-mail]>]

Wes,

Excellent points, which I agree with.  One additional point below.

On Sep 7, 2011, at 12:57 PM, George, Wesley wrote:
> -----Original Message-----
> From: Randy Bush [mailto:[e-mail]]
> 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.

Let's also not forget that all routing platforms deployed in the field /ARE NOT/ created "equal" with respect to the _potential_ for just Routing Engine upgrades, just to gain more CPU and/or DRAM.  Specifically, I'm referring to Router HW architectures where the Routing Engine is co-resident on the same physical LC, (sometimes the RE is a daughtercard, other times it is not), on a centralized Switch Fabric Module.  Up until now, the upgrade strategy to get faster CPU or more DRAM, from the vendors who have shipped these platforms, is to replace the entire LC (that means: CPU, DRAM (RE) _and_ the SFM) ... even if the chassis/system did not require the additional forwarding capacity offered by the new SFM.  Or, worse, sometimes said fabric upgrades cause "legacy" LC's to no longer be supported!!! -- hello whole chassis upgrade ...  Of course, this could change for future generations of platforms, but it doesn't solve for what's already deployed and continues to be deployed, today, in the field.

-shane


> 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.
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr