The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2004-Mar> msg00067



[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

  • From: neil.2.harrison@bt.com
  • Date: Wed, 17 Mar 2004 23:06:58 -0000
  • Cc: <rahul@juniper.net>, <ina@juniper.net>, <mpls@UU.NET>, <tian@redback.com>, <loa@pi.se>, <swallow@cisco.com>, <ccamp@ops.ietf.org>, <rrahman@cisco.com>, <dprairie@cisco.com>
  • Thread-Index: AcQMYrpKMH9CZZ39RIeP39zZHgWS+AAC/QJQ
  • Thread-Topic: draft-minei-mpls-ldp-planned-restart-00.txt & draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id i2HNNxn00421
  • X-OriginalArrivalTime: 17 Mar 2004 23:06:59.0287 (UTC) FILETIME=[8CE67670:01C40C74]

Yakov/Zafar,

<snipped? 
> > 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.
NH=> I have to say I tend to agree with Yakov's view here.  The 'hello' function is a basic OAM connectivity verification of networking protocols.  It should not be proxied by other functions of those protocols.  It also reminds me of the case of trying to use a networking protocol's 'hello' OAM capability to proxy for the traffic's data data-plane OAM.  This is also wrong.  In some network modes there are logically (and in some cases physically) disjoint data-planes for customer traffic and control/management-plane traffic.  In summary:
-	each networking protocol needs its own OAM....and more generally needs its own exception-handling for the protocol (the 'hello' function is a basic connectivity verification exception handling capability)
-	network protocol OAM (eg in control/management-plane protocols) should in general not be used to proxy for traffic data-plane OAM

regards, Neil
>