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. 

>-----Original Message-----
>From: Yakov Rekhter [mailto:yakov@juniper.net] 
>Sent: Wednesday, March 17, 2004 11:30 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.
>
>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. 

Thanks

Regards... Zafar

>Yakov.
>