Subject: FW: Comments on framework-12

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 9 Jan 2004 16:54:33 -0800

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.

- 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.

-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.

- 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.

- 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.

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.

- section 4.3.1

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

---

From: Alex Audu <[email-masked]>
Date: Mon, 12 Jan 2004 11:35:28 -0600

I think the mechanism or algorithm of how CEs distribute messages to the FEs

is better left to the implemented policy in effect in the NE.  Definitely it
could be
first-come-first-serve, but if you are running in load shared mode, some
algorithm
should be in place to spread the traffic amongst the FEs.  Is it 50-50
loading, 20-80,..
it just depends on the policy active on the NE.

Regards,
Alex.