The MPLS WG Archive

[Guangzhi Li <gli@research.att.com>]

Dimitri:

Comments in line.

> At that i didn't raise this question but today it seems we
> don't have a LoL propagation (except in all-optical networks)

GMPLS was clained to work 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 ?

Even on a link, it is possible that the downstream node will delect LoL before
receiving the PathTear message. If the downstream node was engineered with
fault detection, some faked actions will happen, such as alarm or restoration.
Still, this is a problem.

- Guangzhi

> 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