[j-nsp] RE2/RE3 and unwarranted reboots

[Pekka Savola]

On Thu, 30 Jun 2005, Hannes Gredler wrote:
> | Hi,
> |
> | If you have RE 3.0 in M20 running in slot 1, and insert RE2 in slot 0
> | (e.g., maintenance), RE 3.0 reboots.
> |
> | So, who's bright idea was it to:
> |
> |   1. make the code so fragile so that RE 2.0 / RE 3.0 combination does
> |      not work properly;
>
> i read between the lines that you assume bad intention -
> reality is that this RE combination is not part of the regression
> testbed; not supporting the combination is simply a tradeoff call
> that limits the testcases;

This is good to know, but instead of ruling out RE-2.0 / RE-3.0
interaction completely, it shouldn't take *all that much* resources to 
do at least _some_ testing.

Based on the technical specs, 2.0 is for most purposes equivalent to 
3.0.  Users don't expect to see a difference, and frankly, I don't 
think they should.


> |   2. stop selling RE 2.0's, so folks who would want to keep running
> |      RE-2.0's can't continue using them; and
>
> we do not manufacture RE's but rather buy it from one of our suppliers;
> if that supplier discontinues a certain model we do not have
> much choice, don't we ?

The easiest path would be making different RE's interoperable, so that 
the customers don't need to care if they have 3.0 or 2.0 as long as it 
fulfills their technical specifications.

If you have not either secured a sufficient supply prior to 
discontinuation, or made a deal that when they discontinue, you'll get 
a sufficient supply to last for a while.

I guess it would be too expensive for you to keep a supply, but 
instead of using the costs saved from not keeping the supply on extra 
regression testing between the RE versions, you just put it in the 
pocket.

> | It seems completely unacceptable to require having a spare part supply
> | of _both_ RE-2.0 and RE-3.0's, or doing a very disruptive (and costly)
> | throughout upgrade to RE-3.0 just to get around that particular
> | problem.
>
> sorry, i cannot follow that logic:
>
> if the deployed base is big then there is not that much extra cost
>  of sparing 1-2 extra RE's of a certain type.
>
> if the deployed base is small then it should not be that expensive
>  upgrading to the latest RE model;

You make the assumption that the backup RE's would be stored in one or 
a couple of geographical locations.  That does not need to hold.  For 
example, imagine an ISP has a 1-3 PoPs in 100 cities.  Each PoP has 
1-2 Juniper routers, with different RE versions.  Some of these may 
not have dual REs.  To decrease downtime, a backup supply of 
most-breaking components (like REs) may be stored in each city.

So, you'd require that
  a/ all the routers must be dual-RE (this isn't even possible with 
M10) so that the downtime is minimized,
  b/ all the routers must have uniform RE version numbers (meaning 
upgrading hundreds of REs.  Juniper would probably like that, but that 
would be a non-trivial opex and capex exercise), or
  c/ all the "backup depots" must have all the RE versions handy 
(meaning e.g., hundred or half a hundred extra copies, quite costly)