Re: question about transaction operation in ForCES protocol draft!

[Jamal Hadi Salim <[e-mail]>]

On Sun, 2007-23-12 at 21:03 +0800, Chuanhuang Li wrote:
> 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.

If i am not mistaken you are not arguing against the case of more than
one FE  in the NE (in which case one FE may fail but N others succeed).
You are just saying that for a case of a single FE on the NE, the TRCOMP
is redundant.
Which brings up my concern on consistency:
How do i (as FE) know you that in certain cases you are not going to
send me a TRCOMP (when there is only one FE in the NE)? remember the CE
is the smarter of the two; as an FE i am dumb. The CE knows there is
only one FE in the NE; but how does such knowledge get propagated to
tell the FE "please purge state on failure without waiting for TRCOMP".
We could introduce additional signaling, but that is unnecessary for a
corner case (of only one FE in an NE).

cheers,
jamal