RE: Last call - RSVP problems

[Vishal Sharma <vsharma87@yahoo.com>]

Jen,

Your points are well taken. My question is: will the carriers be willing to
provide some suggested solutions to both these problems, particularly
the second one.
Perhaps having corresponding IETF documents addressing these
problems and their possible solutions would help to move the
discussion forward.

-Vishal

On Friday, May 25, 2001 11:06 AM, Jennifer Yates [SMTP:jyates@research.att.com] 
wrote:
> 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.
>
> 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.
>
> ****
> 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.
>
> Jen