Re: Last call - RSVP problems

[Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>]

Hi Jennifer,

At that i didn't raise this question but today it seems we
don't have a LoL propagation (except in all-optical networks)
so i was surprised that this question raised at the OIF
since dealing with SDH/Sonet UNI. So in most cases today 
"PathTear" is a link-by-link deletion process the LoL won't
propagate faster than the PathTear since you can now control
the signal deletion at each hop. Am i right ?

Notice this does not preclude to generalize the process as
proposed in your suggestion.

- Dimitri.

Jennifer Yates 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
begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard