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. However,
I think this assumption is fairly problematic for the following
reason.

RSVP Hello have dual semantics - (a) liveness of RSVP module of
the control plane, and (b) liveness of data plane between RSVP
neighbors.  While there are better ways to detect liveness of the
data plane than to use RSVP Hellos (BFD is certainly better than
RSVP Hello for that purpose), using RSVP Hellos for detecting
liveness of RSVP module of the control plane seems to be the best
available today.  And running an application that uses RSVP, without
being able to detect the state of the RSVP module of the control
plane of a neighbor seems to be fairly problematic (to say the least).

Yakov.