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

Thanks
 
Regards... Zafar

>-----Original Message-----
>From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf 
>Of Yakov Rekhter
>Sent: Monday, March 15, 2004 2:31 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,
>
>> >> 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. Furthermore, RFC3209 says that "The
Hello Message is completely OPTIONAL". 

>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. 

Agreed! And I did not say that. Yes, RSVP/ GR is one such application
that makes use of RSVP Hello for this purpose. 

> 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).

Yes, I agree. I think your and my definition of "application" is
different. Nonetheless, do you agree that basic RSVP signaling can work
without RSVP Hello? Otherwise I would expect your implementation starts
sending RSVP Hellos as soon as RSVP is configured on an interface, is
this the case? Please advise. 

>
>Yakov.
>