The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
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.
|
|