Subject: Re: Comments on framework-12

From: "Yang, Lily L" <[email-masked]>
Date: Sun, 11 Jan 2004 18:26:30 -0800

I suppose at the minimum we can mention the default behavior 
(first come first served) in the framework. 
One exception is command bundling, meaning all or nothing. 

By prioritization, did you mean prioritization between the control msg and data packets, or prioritization among the control msgs? The former is most likely needed, but I am not so sure about the latter. Maybe the protocol people can comment on this what is the current thinking on this?

-----Original Message-----
From: Forwarding and Control Element Separation [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, January 11, 2004 4:56 PM
To: [email-masked]
Subject: Re: Comments on framework-12

On lördag, jan 10, 2004, at 10:14 Asia/Seoul, Yang, Lily L wrote:

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

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.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sun, 11 Jan 2004 22:28:27 -0500

> (first come first served) in the framework.

Unfortunatly that would be defining one way to do it.
Another scheme is to make it totaly tranparent for the FE.
In other words if the FE got the illusion it was receiving
commands from a single CE, then the goal is also achieved.
So i would have to go with your former assertion that this is
a protocol semantic issue.

> By prioritization, did you mean prioritization between the
> control msg and data packets, or prioritization among the control msgs?
> The former is most likely needed, but I am not so sure about the latter.
>  Maybe the protocol people can comment on this what is the current thinking
>  on this?
>

I believe she meant that in a scheme where the FE is aware of the
multiple CEs controlling say the same LFB, then something would
have to be built into the protocol to prioritize which of the
multiple CEs (controling an LFB) should take precedence when they issue
conflicting commands.
Given that this is not the only mechanism possible, i would suggest we
leave the details out or talk about both known possibilities of
operation.

cheers,
jamal

---

From: [email-masked]
Date: Mon, 12 Jan 2004 13:24:42 +0900

> a protocol semantic issue.

I am not looking to define what the relation should be, though i did 
assume a default behavior.

What I am looking for is that we acknowledge that if there is more then 
one behavior then the framework should indicate that  there needs to be 
exchange between the CE and FE about the behavior to be applied.

I also think it reasonable that there be a default behavior established 
in the Framework, and that then the semantics of the protocol can 
include a method for negotiation of a different behavior.

As for how a 'first come first served' was done, i don't think it makes 
a great deal of difference.  From the FE.  perspective.  Whether there 
is a Unified CE or many cooperating CEs sending the FE still processes 
first come first served.

> leave the details out or talk about both known possibilities of

Or just talk about the fact that this needs to be established soon 
after an association is established.

I also think we have to determine if this is a system wide behavior, 
i.e. all FEs in the NE behave in the same manner for each instance of 
an established NE (being an NE with at least one established CE-FE 
association) or whether it is specific to each CE-FE association or, 
something I had not thought of, specific to a single LFB.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 12 Jan 2004 10:13:31 -0500

> exchange between the CE and FE about the behavior to be applied.

I agree it is a good idea to describe the possible ways to achieve the
end goal since the protocol talks only about requiring mechanisms to be
provided. 
What you refer to above will be needed if the scheme is not transparent
to the FE (which is achievable if you use a multicast or broadcast wire).
In the couple of non-transparent schemes i could think of,
the FE will have to be involved in migrations and may need to be
explicitly told to do so. 

> include a method for negotiation of a different behavior.

If you assumed the non-transparent scheme then it will be fair to make
such a default specification.

Could we instead of having it as part of the protocol have this be left 
to xEM (x= F or C)interface? I am just worried about christmas treeing.
That doesnt mean it shouldnt be in the draft.

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Mon, 12 Jan 2004 23:34:06 +0800

Hi,

Talking about proxy FE, I think of a possibility to allow a CE proxy to support control for multihop case.
A CE proxy is put locally with a bunch of FEs (even in one chasis), while an actual CE is multihops away.
This seems make multihop case more like a local case.  The possible benifits may be that like making securiy
consideration for multihops simpler and making secure broadcast/multicast  for ForCES protocol possible. 

Regards,

Weiming

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 12, 2004 12:24 PM
Subject: Re: Comments on framework-12

a.