Subject: Re: First draft of ForCES protocol from the protocol design team

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 28 Jun 2004 17:10:15 -0700

Alex,
 
Thanks for your comments. Pls see my reply below.

________________________________

From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Alex Audu

6) Section 6.1.3 Association Teardown Message
 
I cringed when I read the following in the draft:
........................................................................
.........
   Message Header:
   The Message Type in the header is set MessageType= 'Asso.
   Teardown'(TBD?).  The ACK flag in the header is always ignored,
   because the teardown message will never expect to get any response
   from the message receiver.
........................................................................
...........................
Now, a protocol designed this way will NEVER work.  The ACK is very much
needed when
tearing down an association.  Consider the following scenario:
 
                                 +------------------FE1
                CE ------------|
                                 +------------------FE2
 
CE is the contol active control element with FE1 the active FE and FE2
the standby unit.
 
    1) FE1 is now sent a command to go down (by craft person via
management interface).
    2) FE1 sends association-teardown request to CE.
    3) CE gets this important information and quickly activates FE2 to
assume FE1's 
         responsibilities.
    4) FE2 acknowledges this activation to CE.
    5) CE can then acknowledge FE1's request to leave or go down.
    6) FE1 leaves, and FE2 assumes FE1's traffic duties.  Hurray!,.. NO
TRAFFIC OUTAGE.
 
Now, if we take away steps 3,4, and 5, then FE1 can just leave at will,
and the result WILL
BE AN OUTAGE. At least until an alternative FE becomes the active one.
This is not 
a 5-9's reliability compliant protocol.
 
[HK] You are assuming here that the FE sending the Teardown message is
actually in a state where it can wait for an acknowledgment from the CE
before going down. This is not always the case, the more common case
would be that the FE or CE crashes and the error handling code in the
FE/CE will send a Teardown message to the other entity (CE in your eg).
In this case, the acknowledgment is useless. Also, a lot of FE
redundancy mechanisms are built into actual hardware using FE-FE
communication mechanisms to provide 5-9's reliability.
 
Anyways, you have made an interesting point here and we will definitely
give it due consideration in our team discussions.
 
regards
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 29 Jun 2004 16:58:49 -0700

Hi Alex,
 
Yes, I received your email twice. As I said, we will definitely discuss
this in our team meetings.
 
Thanks for your input,
Hormuzd

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 29, 2004 4:44 PM
To: Khosravi, Hormuzd M; [email-masked]
Subject: Re: First draft of ForCES protocol from the protocol design
team

Hi Hormuzd,
 
I replied to this e-mail earlier, but for some reasons I didn't get an
echo on the list. So, I'll
try again.
 
It is not true that CEs and FEs crashing will be "the more common case"
of association
teardown.  Crashes are an exception condition, and should occure very
rearly.  The more
common scenario resulting in association teardown will be
management/craft related
activities (e.g. software/hardware upgrades, testings, and other general
maintenance).
 
Even for a catastrophic event like a crash, the protocol should be
designed to prevent 
minimize packet loss. We have such a mechanism in
draft-audu-forces-pl-00.txt and also
in FACT.  
 
Regards,
Alex.
 
In a message dated 6/28/2004 7:59:42 PM Central Standard Time,
[email-masked] writes:

        Alex,

         
	
........................................................................
.........
           Message Header:
           The Message Type in the header is set MessageType= 'Asso.
           Teardown'(TBD?).  The ACK flag in the header is always
ignored,
           because the teardown message will never expect to get any
response
           from the message receiver.
	
........................................................................
...........................
        Now, a protocol designed this way will NEVER work.  The ACK is
very much needed when
        tearing down an association.  Consider the following scenario:
         
                                         +------------------FE1
                        CE ------------|
                                         +------------------FE2
         
        CE is the contol active control element with FE1 the active FE
and FE2 the standby unit.
         
            1) FE1 is now sent a command to go down (by craft person via
management interface).
            2) FE1 sends association-teardown request to CE.
            3) CE gets this important information and quickly activates
FE2 to assume FE1's 
                 responsibilities.
            4) FE2 acknowledges this activation to CE.
            5) CE can then acknowledge FE1's request to leave or go
down.
            6) FE1 leaves, and FE2 assumes FE1's traffic duties.
Hurray!,.. NO TRAFFIC OUTAGE.
         
        Now, if we take away steps 3,4, and 5, then FE1 can just leave
at will, and the result WILL
        BE AN OUTAGE. At least until an alternative FE becomes the
active one.  This is not 
        a 5-9's reliability compliant protocol.
         
        [HK] You are assuming here that the FE sending the Teardown
message is actually in a state where it can wait for an acknowledgment
from the CE before going down. This is not always the case, the more
common case would be that the FE or CE crashes and the error handling
code in the FE/CE will send a Teardown message to the other entity (CE
in your eg). In this case, the acknowledgment is useless. Also, a lot of
FE redundancy mechanisms are built into actual hardware using FE-FE
communication mechanisms to provide 5-9's reliability.
         
        Anyways, you have made an interesting point here and we will
definitely give it due consideration in our team discussions.
         
        regards
        Hormuzd

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 1 Jul 2004 08:38:47 +0800

From: "Wang,Weiming" <[email-masked]>

> Hi Sridhar,
>
> Yes, it is an editorial error made by my carelessness. It  should be
> . Inter FE topology
> . Intra FE topology, i.e., LFB topology.
> I'm sorry for the carelessness,  and will correct it.
>
> Thank you so much.
> Weiming
>
> ----- Original Message -----
> From: "T. Sridhar" <[email-masked]>
> To: "Khosravi, Hormuzd M" <[email-masked]>; "Wang,Weiming"
> <[email-masked]>
> Sent: Tuesday, June 29, 2004 2:22 PM
> Subject: RE: [FORCES] First draft of ForCES protocol from the protocol design
> team
>
>
> > Yes, Hormuzd & Weimang,  they are primarily editorial.
> >
> >  I thought that the Intra FE Topology is really the LFB topology, so it
> > looks like an editorial problem. Same with Packet Redirect - my nit is that
> > CE to FE traffic for packets to be sent out of the NE are not really
> > redirects. However, it is a nit and I am OK if it stays the same.
> >
> > Thanks,
> > Sridhar
> >
> >
> > -----Original Message-----
> > From: Khosravi, Hormuzd M [mailto:[email-masked]]
> > Sent: Monday, June 28, 2004 9:27 PM
> > To: Wang,Weiming; [email-masked]
> > Subject: RE: [FORCES] First draft of ForCES protocol from the protocol
> > design team
> >
> >
> > Weiming,
> >
> > I think these are just editorial comments or typos. It seems like you
> > are reading a bit more into these. Sridhar, could you pls clarify ?
> >
> > Thanks
> > Hormuzd
> >
> > -----Original Message-----
> > [mailto:[email-masked]] On Behalf Of Wang,Weiming
> >
> > 4. Section 6.2 - the bullet items under "FE (coarse layer) information".
> > The
> > second bullet states "Inter-FE topology, that is, LFB topology"
> > -shouldn't
> > that be "Intra-FE topology"?
> >
> > [Weiming] We also had some doubt on this at first.  But later we just
> > realized that it may be more reasonable to the LFB topology as FE coarse
> > layer info because it is actually the property of the whole FE rather
> > than individual LFBs, i.e., attributes(capability) of individual LFBs
> > may not be able to tough the whole LFB topology except to know the
> > topology of itself to others.
> >
> > Intra-FE topology is sure belongs to the FE (coarse layer) information,
> > and it has been listed in.
> > [/Weiming]
> >
> > 5. Section 6.5 - A nit - since Packet Redirect messages also involve
> > CE-FE
> > messages (which is not really a redirect) , should we look at calling it
> > something else, e.g. Packet Transfer message?
> > [Weiming] I agree it is more like a transfer than a redirect operation,
> > but to uniformly give a redirect name may greatly easy the construction
> > and use of the messages, i.e., with only one type of message. And also
> > the redirect op for CE-FE and FE-CE is quite symmetrical.
> > [/Weiming]
> >
> >
> >
> >
> >
> > ***************************************************************************
> > This message is proprietary to FutureSoft and is intended solely for the use
> of the individual to whom it is addressed. It may contain  privileged or
> confidential information and should not be circulated or used for any purpose
> other than for what it is intended.
> >
> > If you have received this message in error, please notify the
> > originator immediately. If you are not the intended recipient,
> > you are notified that you are strictly prohibited from using,
> > copying, altering, or disclosing the contents of this message.
> > FutureSoft accepts no responsibility for loss or damage arising from
> > the use of the information transmitted by this email including
> > damage from virus.
> > ***************************************************************************
> >
>
>