[j-nsp] RE2/RE3 and unwarranted reboots

[Hannes Gredler]

On Thu, Jun 30, 2005 at 06:04:03PM +0300, Pekka Savola wrote:
| 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.

that a bit too much of assumption:
supporting two REs with a different clockspeed opens up two dozens of
testcases [ =! "some testing"] just for e.g. graceful RE switchover.
  it is not _just_ the change in CPU speed ...
  you change a variable in a complex system interaction -
  so you either have to fully test it or don't support it;
 
| >|   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.

i do sense again your perception that we are doing this out of
pure evilness:
  reality is that every modern business does not build
  up big stocks but rather contracts just-in-time delivery; - assuming
  that we would warrant RE2.0 [read 333 MHz PII CPU] up until 2009 and
  requiring our supplier to maintain that stock for us probably would bump up
  prices for REs in a way that you even would dislike more ...

| >| 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,

we are leaving the thread here - recall: we were talking about models
with redundant REs; - single-RE models you can run with either RE2 or RE3
- dep. whats available in your next depot;

|  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

for REs there is an avg. new-product cycle of 2 years where a router system
sometimes has to last 5+ years; those are the rules of the PC industry and
there is not much that we can do about that ... so more and more we are forced
to introduce several generations of REs in the lifespan of a router at
comparable cost [read COG, regression-testing, supportability cost];

--

wrt to the negative sentiments presumption:
  i can assure you that the people who are making these calls
  are not the "squeezing the last $$$ out of you" type of person
  but rather want to make sure that you receive a well engineered
  product with a competetive pricing;

  i am deeply convinced that a honest "this is not supported" decision
  is better than broken, half-hearted regressed software or
  extra $$$ on the pricetag to support PC hardware that is
  not available on the open market anymore;


/hannes