Re: question about transaction operation in ForCES protocol draft!

[Chuanhuang Li <[e-mail]>]

Thanks for your answers!

We are implementing ForCES protocol as the general protocol stack,so we should consider all the possible situations.

First,there have transaction operation between CE and one FE,and we shouldn't limit user use it since the Protocol supported.
in draft:(page 21)   As defined above, a transaction is always atomic and MAY be
   a.  Within an FE alone       Example: updating multiple tables that are dependent on each       other.  If updating one fails, then any that were already updated       must be undone.   b.  Distributed across the NE       Example: updating table(s) that are inter-dependent across       several FEs (such as L3 forwarding related tables).

Sencod,You said:it would be inconsistent if CE don't send the TRCOMP message in that case.I don't agree.Exactly,it lied on the user's implementation of the protocol.Also,i think it is a redundant operation for CE to send TRCOMP,if the CE received the COMMIT-RESPONSE message which indicated the transaction failed.


                                                                                   Chuanhuang Li                                                                         Zhejiang Gongshang University                                                                                    12/23/2007

> Date: Sun, 23 Dec 2007 07:21:20 -0500> From: [e-mail]> Subject: Re: question about transaction operation in ForCES protocol draft!> To: [e-mail]> > 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: Tr
 ansactional 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.> > cheers,> jamal
 >
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/