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

[Yakov Rekhter <yakov@juniper.net>]

Zafar,

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

Perhaps running RSVP Hellos as millisecond interval is not a wise 
idea in the first place. 

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