[j-nsp] graceful failover and software upgrades

[Roberts, Michael J. (IATS)]

Okay.  I have read through a number of very informative emails and I
appreciate everyone's input.  

Does anyone know if hitless upgrades are even on the roadmap for JUNOS?

-mike

-----Original Message-----
From: daniel [mailto:daniel at claudius.demon.nl] 
Sent: Tuesday, March 22, 2005 3:58 PM
To: Pekka Savola
Cc: Roberts, Michael J. (IATS); juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] graceful failover and software upgrades

Hi Pekka,

On Mon, 2005-03-21 at 20:13, Pekka Savola wrote:
> On Sat, 19 Mar 2005, daniel wrote:
> > On Sat, 2005-03-19 at 00:07, Pekka Savola wrote:
> > ..
> >> According to a couple of notes, GRES should be usable also w/o
> >> graceful restart just fine, it'll just result in some minor routing
> >> flaps.  But that's probably OK.
> 
> One additional note, from the online documentation:
> 
> =====
> Note:
> [...]
> You must enable graceful restart on all the protocols you have 
> configured at the [edit protocols] hierarchy level. If you have 
> configured a protocol that does not support graceful restart, graceful

> switchover might not work. For information about graceful restart, see

> the JUNOS Routing Protocols Configuration Guide.
> =====
> 
> This does not guarantee anything, because the documentation is wrong 
> more often that it's not... 

well; perhaps you're being a little to harsh now :) I know the doc folks
take pride in what they do. So for anything that slipped through that is
incorrect or not clear enough JTAC would be happy to take DOC PRs and
relay it to the appropriate doc group.

> but I wonder what this "might not work" 
> means, for example:
> 
>   a) "unless the protocols support graceful-restart, the routing 
> protocols will flap, possibly reducing the usefulness of graceful 
> switchover",

that's the one.

> 
>   b) "unless the protocols support graceful-restart, [something really

> bad could happen, e.g. an adjacency might not come up at all, and we 
> don't support this kind of configuration]"
>   c) something else..
> 
> I guess the documentation means a) but it's generic enough that it 
> could be interpreted in any way you want..

I'll take the action on this one and get it better clarified going
forward. 

Cheers,
-Daniel (dderksen at juniper.net ..)