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 comments in-line. 

Thanks
 
Regards... Zafar

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Yakov Rekhter
>Sent: Wednesday, March 17, 2004 3:58 PM
>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,
>
>[clipped...]
>
>> >> >> >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 ?
>> 
>> Are you saying that just because RSVP control plan at the 
>neighbor is 
>> up means that it's in-sync, given that we don't use a reliable 
>> transport mechanics? We still need to rely on RSVP refresh messages 
>> for maintaining states; this is just "HOW" RSVP protocol is defined. 
>> And NOT to mention about existing implementations and deployments.
>
>Wrt "we don't use a reliable transport mechanics", I assume 
>that one uses rfc2961 (RSVP Refresh Overhead Reduction 
>Extensions), which (among other things) supports reliable RSVP 
>message delivery.

Yes, I wanted to imply that RSVP requires refresh mechanics. 

>
>Wrt maintaining/refreshing state, we could still rely on RSVP 
>refresh messages.  But wrt detecting liveness of the 
>neighbor's RSVP module, I think using RSVP Hellos is a better 
>alternative than relying on on RSVP refresh messages.
>

For what you are saying, why would someone not use RSVP/ GR? IMO the
best thing to do is to use RSVP GR procedure. If RSVP/ GR is NOT
enabled, what actions you expect a node to take when it detects failures
at the neighbor's RSVP module. Are such actions documented and agreed
upon some where? No matter what your answer would be, my question will
remain, "in such case, why would someone not use RSVP/ GR?". 

Thanks

Regards... Zafar