[j-nsp] RE2/RE3 and unwarranted reboots

[Pekka Savola]

Thanks for your constructive mail, Hannes.

On Fri, 1 Jul 2005, Hannes Gredler wrote:
> | 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;

I'm not sure if I understand this.  Basically what might change is the 
amount of memory, CPU speed, HDD space, and similar factors.  Both 
would still be the same hardware, externally visible the same way, and 
run the same kernel and software.

In the next mail, you mentioned issues wrt. kernel nexthops etc. -- as 
above, I can't figure out how these should be a factor here.  The 
master RE reboots immediately, even before the slave has been halfway 
to booting up (I recall it wasn't even done with BIOS yet).  This 
makes me *really* wonder what the logical interface between the REs 
is..

The only scenario with potential problems I can think of is the case 
where the faster CPU would be maxed out, and the slower couldn't keep 
up with graceful switchover data replication.  As the protocols are 
not active on the slave CPU, however, I can't see how the slower CPU 
could be maxed out because it has basically nothing to do in any case.

> |  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];

Exactly.  Because the cycle is so short, I think this is significant 
argument in favor of supporting at least some transition scenarios 
between the versions.  Phasing in and out in a controlled manner, not 
having to obtain and field hundreds of new REs when they hit the 
market (and previous ones become unavailable).

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

I wonder if there has been a consideration of getting older RE models, 
but with a higher pricetag -- for those that think really need them, 
so they could evaluate the impact of the pricetag themselves.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings