Subject: update section 3 - take 2

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 16 Sep 2005 11:57:03 -0400

As per concal ive made the following changes to clarify.

----
3.2.2.3.  Association Lost state

   In this state, both or either the CE or FE declare the other side is
   no longer associated.  The disconnection could be physically
   initiated by either party for administrative purposes but may also be
   driven by operation reasons such as loss of connectivity.

   It should be noted that loss of connectivity between TMLs is not
   necessarily indictive of loss of association between respective PL
   layers unless the programmed FE Protocol Object is exceeded.  In
   other words if the TML repairs the transport loss before then, the
   association would still be valid.

   ...
   ...

----------

Then next:

3.3.1.1.4.  Recovery

   Any of the participating FEs, or the CE, or the associations between
   them, may fail after the EOT response message has left the FE and
   before it has received all the responses, (possibly the EOT response
   never reached the CE).

   In this protocol revision, for sake of simplicity as indicated in
   Section 3.2.2.3, an FE losing an association would be required to get
   new state from the newly associated CE from scratch upon a
   reassociation.  The decision on what an FE should do after a lost
   association is dicated by the CE Failover policy (refer to Section 8
   and Section 6.2).

   In the case of desire to do HA then multiple associations would exist
   between the FE and multiple CEs although only one of them would be
   the master at any time (as described in Section 8).  The CEs to which
   the FE is associated to would need to be synchronized on the state of
   the FE.  The scheme for such a synchronization is outside the scope
   of ForCES but is mentioned here to indicate that in such a setup, the
   FE would not be re-associating itself to the new CE master and would
   therefore not need to reload its state from scratch.
----

And last:

---
3.3.1.1.7.  Relation to Multipart messages

   Multipart messages after the first one are indicated by the MOT flag
   (Middle of Transaction).  The first message is indicated by SOT and
   the last by EOT.

--------

So in addition to the earlier flags we need this new flag.

Please comment with nay or yay so we can move to the next issues.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 17 Sep 2005 10:50:50 +0800

Jamal,

>    association would still be valid.
I don't know the word 'dicated'. Is it a mistyping?

>    therefore not need to reload its state from scratch.
One more question is, we don't have to have FE to restart when we switch from master CE to backup CE, then, do we need to definitely ask FE to restart if the re-associated CE is still the original master one after the CE is back again?  

Jamal, Thanks for the hard work.

Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 17 Sep 2005 08:23:23 -0400

Hi Weiming,

> I don't know the word 'dicated'. Is it a mistyping?

fixed.

> One more question is, we don't have to have FE to restart when we switch from 
> master CE to backup CE, then, do we need to definitely ask FE to restart if 
> the re-associated CE is still the original master one after the CE is back again?  
> 

In my view, the answer is yes if that is the only association you head;
it probably doesnt make sense to have multiple associations with sane
CE. Other people may have different opinions. We actually havent heard
from Joel on this topic. 
 
> Jamal, Thanks for the hard work.

And thank you for being vigilant and catching all the issues we are
glossing over as you did on this section 3 and others before.

cheers,
jamal