Subject: RE: Last call - RSVP problems

From: Vishal Sharma <[email-masked]>
Date: Fri, 25 May 2001 12:00:19 -0700

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:[email-masked]] 
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

---

From: Guangzhi Li <[email-masked]>
Date: Fri, 25 May 2001 15:10:46 -0400

Vishal:

If mpls WG agrees that these issues are problems in GMPLS and would like to fix
them before last call, there will be some possible solutions from different
contributions.

Jen provides a suggested procedure for the first one. A possible solution for the
second one could be to define an infinite refresh timer (never expires). Another
solution could be time-out without removing states, etc. Details need more work.

Thanks,

Guangzhi

---

From: Jennifer Yates <[email-masked]>
Date: Fri, 25 May 2001 15:45:57 -0400

Hi Suresh,

>
> Ofcourse, (2) & (3) introduces some problems when the control channel
> comes alive. How do two neighboring nodes sync up on what circuits are
> still alive and what is gone? This is kind of addressed in ATM and we could
> borrow ideas from there. If we all agree on above persistency levels or just
> with (3), then I can provide information on how to sync up etc once nodes
> come back alive.

Another option (as Guangzhi pointed out) is that the refresh still be used, but
state NOT removed on timeout. That way, the refreshes can be used for
re-synching the state, but we don't have the problem of connections being
erroneously removed. It may also have a nice side benefit that if we have a
connection that is not torn down completely when it should have been (ie., some
links still remain up, even though the user attempted to remove the connection),
then we can use out-of-band techniques (e.g., network operator) for tearing down
this state rather than having it sit around in the network forever. The
important point is that the connection is not torn down automatically on loss of
refreshes.

Other solutions are to have the refreshes tunneled around failed signaling
channels, or have nodes downstream of a failure detect the failure and then
generate the necessary refreshes to keep the connection alive. I am not fond of
either of these last two solutions.

Finally, we could introduce a new mechanism for the synching up of state after
signaling node failure.
Borrowing ideas from other technologies is always worth investigating.

I think that this issue needs to be solved before we can take these documents to
last call.

Jen

---

From: Yangguang Xu <[email-masked]>
Date: Thu, 31 May 2001 15:13:12 -0400

Hello All,

Where is the wavelength/port label defined for GMPLS RSVP-TE? Should it has a
new C-TYPE?

Thanks,

Yanggunag