Subject: Re: Comments on framework-12

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 9 Jan 2004 17:14:05 -0800

my reponse in line ... 

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Yang, Lily L
> Sent: Friday, January 09, 2004 4:55 PM
> To: [email-masked]
> Subject: FW: Comments on framework-12
> 
> 
> I received these comments from Avri on the framework...
> 
> -----Original Message-----
> From: avri [mailto:[email-masked]]
> Sent: Thursday, January 08, 2004 12:59 AM
> To: Yang, Lily L
> Subject: Comments on framework-12
> 
> 
> Hi,
> 
> I know this is very late, but decided to reread the whole document as 
> opposed to just the changes.   Apologies.  I am just getting deeply 
> involved in a ForCES project so I am rereading everything with fresh 
> eyes.
> 
> - Definitions
> 
>      Pre-association Phase - The period of time during which an FE
>      Manager (see below) and a CE Manager (see below) are determining
>      which FE and CE should be part of the same network element.
> 
> As I have mentioned in other posting, this phase is likely to 
> last long 
> into the post-association phase.  I think it might be better to cast 
> the definition in terms of a single CE-FE association.
> 
> Suggestion:
> 
>      Pre-association Phase - The period of time during which an FE
>      Manager (see below) and a CE Manager (see below) are determining
>      whether an FE and a CE should be part of the same 
> network element.
>      It is possible for some elements of the NE to be in 
> pre-association 
> phase
>      while other elements are in the post-association phase.
> 
> - section 3
> 
>      There is no
>      defined role for FE Manager and CE Manager in post-association
>      phase, thus these logical components are not considered 
> part of the
>      ForCES NE.
> 
> I think this is misleading for the same reason given above.  The idea 
> of pre and post association belongs to the 2 elements and not 
> to the NE 
> at large.  A dynamic system may have elements in 
> pre-association as it 
> has elements in post-association.  I recommend dropping the sentence.
> 

Good point. I like the idea of tieing pre- and post- association phase with individual CE/FE but not NE. It is conceptually more accurate.

> 
> - section 3.2
> 
>      Instead, FEs
>      accept commands from any CE authorized to control them, and it is
>      up to the CEs to coordinate among themselves to achieve 
> redundancy,
>      load sharing or distributed control.
> 
> I am assuming that the FE accepts commands on a first come 
> first served 
> basis.  If so, this should probably be said.  If not, then 
> the possible 
> existence of a prioritization scheme should be mentioned.

I would argue that such semantic details belong to the protocol, not framework. 

> 
> -section 4.1 Pre-association phase
> 
>      Pre-association phase is the period of time during which an FE
>      Manager and a CE Manager are determining which FE and CE 
> should be
>      part of the same network element.
> 
> Same comments as made above for the definition of the pre-association 
> phase.
> 
> - section 4.1.1
> 
> this section reflects the same notion that the pre-association phase 
> occurs at a singular moment of time in the system.
> 
>      the CE
>      and FE managers communicate to determine which CEs and FEs should
>      communicate with each other.
> 
> suggest:
> 
>      the CE and FE managers communicate to determine whether
>      an individual CE and FE, or a set of CEs and FEs, should be 
> associated.
> 
> - section 4.2.2 - message exchange diagram
> 
> I think that since the delivery of inter-FE toplogy is optional, the 
> diagram should indicate this.

I would just delete the inter-FE topology messages here, since what we show is just a conceptual example. 

> 
> - section 4.2.2.
> 
>     Once FE starts
>     accepting packets for processing, we say the association 
> of this FE
>     with its CE is now established.
> 
> This may be a pedantic point, but I would think that the the 
> association needs to be established before the process of accepting 
> packets for forwarding occurs.
> 
> Suggest:
> 
>     Once the necessary exchange of initial information is exchanged,
>     the process of association can be completed.  Processing packets
>     for forwarding cannot begin until association is established.
> 
> 
> - section 4.2.4
> 
> I think the language  in:
> 
>      In light of the fact that the ForCES protocol is responsible for
>      transporting both the control messages and the data 
> packets between
>      the CE and FE over Fp reference point, it is possible to 
> use either
>      a single protocol or multiple protocols to achieve this.
> 
> can be confusing.  Several times in the document 'protocol' 
> is used to 
> refer both to the ForCES Protocol and to the possible protocols that 
> might comprise the ForCES protocol.  I know what is meant here, but 
> everytime I read it, I need to stop and think. Perhaps some 
> convention 
> of either capitalizing the 'protocol' in ForCES Protocol or 
> using some 
> difficult phrase like component protocol will help with the 
> differentiation.

Yeah, I will clean up the language.

> 
> - section 4.2.5
> 
>      In the case where a physical FE cannot implement (e.g., 
> due to the
>      lack of a general purpose CPU) the ForCES protocol directly, a
>      proxy FE can be used in the middle of Fp reference point.  This
>      allows the CE communicate to the physical FE via the 
> proxy by using
>      ForCES, while the proxy manipulates the physical FE using some
>      intermediary form of communication (e.g., a non-ForCES 
> protocol or
>      DMA).  In such an implementation, the combination of the 
> proxy and
>      the physical FE becomes one logical FE entity.
> 
> I think that the Fp terminates at the proxy as opposed to the proxy 
> being at a midpoint.  This is reinforced by the following 
> sentence that 
> declares that proxy + non forCES FE comprises the FE.

Yes. I will fix that.

> 
> Question:  is ther a one to one mapping between FE and 
> proxies.  Could 
> a Proxy serve several non ForCES FEs and would they be seen 
> as a single 
> FE by the CE.  I think so, but I am not sure.

Yes. I will add a sentence to that effect.

> 
> - section 4.3.1
> 
> This only pertains when the entire CE set falls.  If an individual CE 
> falls then the circumstance may be different.

You are right. Will mention this.

---

From: [email-masked]
Date: Mon, 12 Jan 2004 09:56:21 +0900

> I would argue that such semantic details belong to the protocol, not 

Well while the specific behavior and they way it is negotiated if there 
is an option would be a protocol issue, I think it might be appropriate 
for the framework to assume a default behavior.  And if more behaviors 
are possible then a negotiation of behavior pattern is probably in 
order.

I think this is a more a negotiated (if there are option - and I think 
there will be) behavioral pattern then a semantic issue.

a.