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

Thanks
 
Regards... Zafar


>-----Original Message-----
>From: owner-ccamp@ops.ietf.org 
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter
>Sent: Monday, March 15, 2004 4:28 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.
>
>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 :-) The fact of the matter is that RSVP Hellos
are "optional" and an LSR (say LSR-B) may not reply to RSVP Hello
messages unless the LSR-B ALSO thinks that it needs to establish an RSVP
Hello adjacency. In such cases it is even better if the initiating LSR
(LSR-A) knows intent of LSR-B. In other words, the draft in question
does NOT change the equation, but only helps. 

>Yakov.
>