Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

[Yakov Rekhter <yakov@juniper.net>]

Zafar,

> >> >> SPs don't like to see RSVP Hello running even when there is
> >> >> no application requiring them.
> >> >
> >> >Could you please describe scenario(s) where you would have
> >> >RSVP Hello running "even when there is no application 
> >requiring them".
> >> >
> >> >Yakov.
> >> >
> >> 
> >> Hi Yakov,
> >> 
> >> Here is a scenario:
> >> 
> >> 1. You start without any application that require RSVP Hellos.
> >> --> You will see RSVP Hellos are NOT running.
> >> 
> >> 2. You enable an application (GR/ FRR) requiring RSVP Hellos.
> >> --> You will see RSVP Hellos start running.
> >> 
> >> So far so good :-)
> >> 
> >> 3. You disable application requiring RSVP Hello.
> >> --> One would expect RSVP Hellos to stop but they keeps 
> >running :-( If
> >> one side stops replying to RSVP Hello, it would cause traffic 
> >> disruption for LSPs that depend on the health of the Hello session. 
> >> The only way to get around this limitation is to continue to run 
> >> Hellos.
> >
> >The scenario you described above seems to assume that there 
> >are RSVP applications that do *not* require to run RSVP 
> >Hellos. 
> 
> Yes. Specifically, basic RSVP signaling does NOT require use of RSVP
> Hello to detect liveness of RSVP module at the neighbor and instead uses
> refresh mechanics for this purpose. 

In principle one could use the refresh mechanism as a liveness
detection of the RSVP module of the control plane. However, the
overhead of the refresh mechanism is certainly higher than of Hello.
And that is why using RSVP Hellos for detecting liveness of RSVP
module of the control plane seems to be the best available today
(note that "best" does not imply "the only").

Yakov.