[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
- To: "zafar ali" <zali@cisco.com>
- Subject: Re: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
- From: Yakov Rekhter <yakov@juniper.net>
- Date: Wed, 17 Mar 2004 12:57:45 -0800
- Cc: "'Rahul Aggarwal'" <rahul@juniper.net>, "'Ina Minei'" <ina@juniper.net>, "'MPLS wg'" <mpls@UU.NET>, tian@redback.com, "'Loa Andersson'" <loa@pi.se>, "'George Swallow'" <swallow@cisco.com>, ccamp@ops.ietf.org, "'Reshad Rahman'" <rrahman@cisco.com>, dprairie@cisco.com
- In-reply-to: Your message of "Wed, 17 Mar 2004 11:45:31 EST." <000901c40c3f$4410c840$0300a8c0@amer.cisco.com>
Zafar,
[clipped...]
> >> >> >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.
Wrt "we don't use a reliable transport mechanics", I assume that
one uses rfc2961 (RSVP Refresh Overhead Reduction Extensions),
which (among other things) supports reliable RSVP message delivery.
Wrt maintaining/refreshing state, we could still rely on RSVP
refresh messages. But wrt detecting liveness of the neighbor's
RSVP module, I think using RSVP Hellos is a better alternative than
relying on on RSVP refresh messages.
More generally, refreshing state and protocol liveness detection
need not be coupled, and should not be coupled. For an example look
at ISIS or OSPF - resending LSAs to refresh state, sending Hellos
to provide protocol liveness detection.
Yakov.