On Sunday 13 December 2009 05:00:01 am Gert Doering wrote: > We never reload anything, unless a *specific* reason > exists - e.g. "software update unavoidable" or "device > misbehaving and we can't find any non-reload way to > mitigate".
Same here.
In most cases, for us, reasons for reload will be driven by
software upgrades. These software upgrades would be driven
by needing to support:
* new hardware, e.g., newer line cards, newer optical
modules, e.t.c.
* fixing terrible bugs for features that we have turned on
(if a bug exists for a feature we haven't enabled or
don't plan to enable, and the bug doesn't "play" when
the affected feature is disabled, we don't upgrade).
* introducing new features, although for this, we'd
normally prefer to wait at least for another 2 or 3
rebuilds of the code base following the initial release
of the feature, just to work out any issues that could
have arisen from early deployment of the feature.
Apart from that, we're happy. For instance, we run SXI2a on
our 6500's, and that's fine with us, even though SXI3 is
out. With just Layer 2 Ethernet switching going on, we don't
need much else, unless of course, SXI5 fixes something
really terrible in a core function.
However, we've seen a number of upgrades in the past year
going on for IOS 12.2(33)SRC due to bugs, as well as JUNOS
9.x due to bugs also. But this seems to be stabilizing now,
on both fronts.
One reason where I'll see most (if not all) service
providers needing to upgrade code is to introduce 4-byte ASN
support. Yes, you could work around it by supporting
AS23456, but if you're looking to keep the NOC folk happy,
we may not be able to run away from moving some or all of
our boxes to later code just for this.
Cheers,
Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
