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

["zafar ali" <zali@cisco.com>]

Hi Yakov, 

Please see my response in-line. 

>-----Original Message-----
>From: owner-ccamp@ops.ietf.org 
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter
>Sent: Wednesday, March 17, 2004 10:15 AM
>To: zafar ali
>Cc: 'Rahul Aggarwal'; 'Ina Minei'; 'MPLS wg'; 
>tian@redback.com; 'Loa Andersson'; 'George Swallow'; 
>ccamp@ops.ietf.org; 'Reshad Rahman'; dprairie@cisco.com
>Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & 
>draft-ali-ccamp-rsvp-hello-gr-admin-00.txt 
>
>
>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. 

Thanks

Regards... Zafar 

>Yakov.
>