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").
> >> 
> >> So we are in agreement :-)
> >
> >So you agree that (a) RSVP Hello should be used to detect 
> >liveness of RSVP module, and (b) any use of RSVP should 
> >include (among other
> >things) the ability to detect liveness of the RSVP module of a 
> >neighbor. Correct ?
> >
> 
> No, unless you can please point me to a place where such use of RSVP
> Hello is documented. What you wanted to do can ONLY be achieved if RSVP
> Hello protocol is mandatory. The fact remains that RSVP Hellos are
> "optional" and standard RSVP (RFC2205) "IS" required to maintain state
> via the generation of RSVP refresh messages. 

And what is wrong with making RSVP Hellos mandatory, and use it as
*the* mechanism to determing the state of the RSVP module on a neighbor ?

Yakov.