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

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

>-----Original Message-----
>From: Rahul Aggarwal [mailto:rahul@juniper.net] 
>Sent: Wednesday, March 10, 2004 8:27 PM
>To: zafar ali
>Cc: '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
>
>
>
>Hi Zafar,
>
>[snipped]
>
>>
>> Thanks for your reply. We have a similar draft in CCAMP that 
>> formalized procedure for disabling RSVP GR (and Hello) (see,
>> 
>http://www.ietf.org/internet-drafts/draft-ali-ccamp-rsvp-hello-gr-admi
>> n-
>> 00.txt for details).
>>
>> The requirements/ motivations for the two drafts in question are 
>> similar.
>
>The difference is that RSVP-TE already supports the ability to 
>toggle the graceful restart capability of a router by 
>including/excluding the restart capability object in RSVP-TE 
>hellos. This can be done without breaking the neighbor 
>relationship between the adjacent routers.
>

Hi Rahul, 

We would not be having "part" of this discussion had there be a
statement stating the same in RFC 3473; a clarification is needed.
Furthermore, SPs have similar motivations for removing RSVP Hello
adjacencies without cause 
triggering FRR or GR. Not to mention due to possible millisecond
interval, SPs don't like to see RSVP Hello running even when there is no
application requiring them. You can argue that one node can back-off
RSVP hello interval, but the Hello frequency depends on min of the Hello
intervals at the peering nodes. 

Thanks

Regards... Zafar

>rahul
>
>>
>> Thanks
>>
>> Regards... Zafar
>>
>> >-----Original Message-----
>> >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Ina 
>> >Minei
>> >Sent: Tuesday, March 09, 2004 6:35 PM
>> >To: zafar ali
>> >Cc: 'MPLS wg'; tian@redback.com; 'Rahul Aggarwal'; 'Loa Andersson'; 
>> >'George Swallow'
>> >Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt
>> >
>> >
>> >
>> >	Zafar,
>> >
>> >	3478 details the procedures for doing graceful restart
>> >in the case where the capability will be used irrespective of the 
>> >cause of the crash.
>> >
>> >	The proposed enhancement deals with a situation where
>> >the operator wants to perform graceful restart only when he 
>is doing 
>> >a planned upgrade. Why? Because a planned upgrade is a controled 
>> >environment. This is mostly a comfort-level issue for the operator 
>> >and a good way to let him convince himself that the feature is 
>> >working as expected. Many operators are wary of graceful 
>restart, but 
>> >would really like to see graceful upgrades.
>> >
>> >				Ina
>> >
>> >On Tue, 9 Mar 2004, zafar ali wrote:
>> >
>> >> Hi Ina, Rahul and Albert,
>> >>
>> >>
>> >>
>> >> I am not sure about motivation behind this draft. Why 
>procedures in 
>> >> RFC 3478 are are NOT enough to address planned outages? This
>> >question
>> >> was also raised at the last MPLS WG meeting but I did not 
>hear any 
>> >> convincing answer.
>> >>
>> >>
>> >>
>> >> Thanks
>> >>
>> >>
>> >>
>> >> Regards... Zafar
>> >>
>> >>
>> >
>>
>>
>