RE: Last call - RSVP problems

[Jonathan Lang <jplang@calient.net>]

Jennifer,
  Please see inline comments.

Thanks,
Jonathan

> -----Original Message-----
> From: Jennifer Yates [mailto:jyates@research.att.com]
> Sent: Friday, May 25, 2001 11:06 AM
> To: mpls@UU.NET; ccamp@ops.ietf.org
> Subject: Last call - RSVP problems
> 
> 
> A number of potentially major protocol problems have been identified
> within the OIF with the current signaling protocols (focusing 
> on RSVP).
> These problems arise in transport networks because the data plane is
> separate from the signaling plane.
> 
> I don't believe these issues have been addressed on the mailing list -
> if they have, please explain where.
> 
> ****
> Connection (LSP) teardown:
> There is a problem with connection deletion in the current RSVP draft.
> If a PathTear is sent in the forward direction (with say a
> unidirectional connection), the first node (cross-connect) will delete
> the connection and then forward the PathTear to the next cross-connect
> and so on.
> 
> Since loss of light will propagate faster than the PathTears, all
> downstream cross-connects will detect the loss of light and 
> alarm on it, possibly triggering restoration.  This is clearly 
> unacceptable behavior.

If LMP fault management is used, the "multiple alarming" behavior will be
avoided.

> 
> The right solution is that the deletion message in the forward direction
> should inform all of the nodes that the connection is being deleted, and
> the actual deletion should propagate in the *reverse* direction.
> Therefore, additional protocol extensions are needed to get the correct
> behavior on deletion.
> 
> This issue has been already been discussed within OIF documents e.g.,
> OIF2001.200 (RSVP Extensions in support of deletion confirmation and
> maintenance during failure), and in the ITU e.g., "Signal flows during
> exception cases". This issue does not appear to be reflected in the
> GMPLS documents presented for last call.

Please see the LMP document for a description of the fault management
procedure.

> 
> ****
> Signaling channel failure:
> If any element along the RSVP signaling path of an LSP fails, the RSVP
> soft state timer in nodes downstream of the failure will timeout and the
> nodes will delete the LSP, even if the forwarding plane is still
> working! When GMPLS is used to control a transport network, this
> scenario will occur, since the reliability of control planes is likely
> quite a bit lower than the cross-connects themselves.  In transport
> networks, the data plane reliability expectations are very 
> high, and any factor that increases the already steep challenge of meeting
those
> expectations is not acceptable.
> 
> One of the cardinal principles of transport network architecture is that
> control plane failure must *not* cause the data plane to fail.  This
> point has been raised and acknowledged at the OIF, but so far does not
> seem to have been addressed in any of the GMPLS drafts.

  According to rfc2205, the state's lifetime L must satisfy: L>=
(K+0.5)*1.5*R where K is an integer and R is the refresh timer.  My
suggestion to the OIF back in January in Tampa was to use L (or effectively
K*R) to get the operation you are looking for.  I believe this will satisfy
your requirement and does not require any changes to the signaling protocol.

> 
> Jen
>