Re: question about transaction operation in ForCES protocol draft!

Jamal Hadi Salim <> Sun, 23 December 2007 12:21 UTC

Message-Id: <SUN.23.DEC.2007.072120.0500.>
Date: Sun, 23 Dec 2007 07:21:20 -0500
From: Jamal Hadi Salim <>
Organization: ZNYX Networks
Subject: Re: question about transaction operation in ForCES protocol draft!
Comments: To: Chuanhuang Li <>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2007-23-12 at 19:12 +0800, Chuanhuang Li wrote:
> Hi:
>     we are implementing the ForCES protocol,I have one question in the
> Transaction Protocol part.
> in the draft:
>    1: TRCOMP is sent by the CE to signal the FE(s) that the
>    transaction they have COMMITed is now over.  This allows the FE(s)
> an
>    opportunity to clear state they may have kept around to perform a
>    rollback (if it became necessary). (page 22)
>    2: The FE MUST respond to the CE's EOT message.  (page 22)
>    If all participating FE(s) respond with a success indicator within
>    the expected time, then the CE MUST issue a TRCOMP operation to all
>    participating FEs.  An FE MUST NOT respond to a TRCOMP. (page 23)
> question:
>    We assume that the transaction operation is occured between CE and
> one FE,

Note: Transactional operation is used for the case where you have to
transfer state to _more than one_ FE and where such state has to be
consistent (eg adding a single route on more than one FE).

> if there is failure when FE executes the full transaction, and it
> tells the result to CE through sending COMMIT-RESPONSE message.
> Whether FE should clear state they have kept still after it received
> the TRCOMP message?

It should wait for TRCOMP.

> or CE shouldn't send the TRCOMP message in this case,and FE will clear
> the information once there is error?

This would be inconsistent. If you use transaction, then the state
machine says you have to wait for TRCOMP.

> I think the latter may be a better solution,but the draft hasn't
> explained it clearly.

If you have a single FE and dont want to incur the extra overhead of
transactional procedure, then dont use transacational messaging.

>     Hope your answers!!

Hope above is helpful.