Yang, Lily L | 10 Jan 2004 01:54
Picon
Favicon

FW: Comments on framework-12

I received these comments from Avri on the framework...

-----Original Message-----
From: avri [mailto:avri <at> psg.com]
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.
(Continue reading)

Yang, Lily L | 10 Jan 2004 02:14
Picon
Favicon

Re: Comments on framework-12

my reponse in line ... 

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:FORCES <at> PEACH.EASE.LSOFT.COM]On Behalf Of Yang, Lily L
> Sent: Friday, January 09, 2004 4:55 PM
> To: FORCES <at> PEACH.EASE.LSOFT.COM
> Subject: FW: Comments on framework-12
> 
> 
> I received these comments from Avri on the framework...
> 
> -----Original Message-----
> From: avri [mailto:avri <at> psg.com]
> 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
(Continue reading)

avri | 12 Jan 2004 01:56
Picon
Favicon
Gravatar

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.
(Continue reading)

Yang, Lily L | 12 Jan 2004 03:26
Picon
Favicon

Re: Comments on framework-12

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:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of avri <at> acm.org
Sent: Sunday, January 11, 2004 4:56 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
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.
(Continue reading)

Jamal Hadi Salim | 12 Jan 2004 04:28

Re: Comments on framework-12

On Sun, 2004-01-11 at 21:26, Yang, Lily L wrote:
> I suppose at the minimum we can mention the default behavior
> (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.

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

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,
(Continue reading)

avri | 12 Jan 2004 05:24
Picon
Favicon
Gravatar

Re: Comments on framework-12

On måndag, jan 12, 2004, at 12:28 Asia/Seoul, Jamal Hadi Salim wrote:

> On Sun, 2004-01-11 at 21:26, Yang, Lily L wrote:
>> I suppose at the minimum we can mention the default behavior
>> (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.

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.

>
(Continue reading)

Jamal Hadi Salim | 12 Jan 2004 16:13

Re: Comments on framework-12

On Sun, 2004-01-11 at 23:24, avri <at> acm.org wrote:
> On måndag, jan 12, 2004, at 12:28 Asia/Seoul, Jamal Hadi Salim wrote:
>
> 
> 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 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. 

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

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.

(Continue reading)

Weiming Wang | 12 Jan 2004 16:34

Re: Comments on framework-12

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: <avri <at> acm.org>
To: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Monday, January 12, 2004 12:24 PM
Subject: Re: Comments on framework-12


On måndag, jan 12, 2004, at 12:28 Asia/Seoul, Jamal Hadi Salim wrote:

> On Sun, 2004-01-11 at 21:26, Yang, Lily L wrote:
>> I suppose at the minimum we can mention the default behavior
>> (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
(Continue reading)

Yang, Lily L | 12 Jan 2004 18:22
Picon
Favicon

Re: ForCES Framework Last Call for Comments (was: ForCES framework: summary of comments from Russ Housley and authors' respond)

Jamal --
See my comments below in line starting with [lily]. I also have further
questions for the last two comments. I would appreciate it if you can
elaborate.

Thanks for taking the time to review the document in full.
Lily

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES <at> PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Saturday, December 20, 2003 12:01 PM
To: FORCES <at> PEACH.EASE.LSOFT.COM
Subject: Re: ForCES Framework Last Call for Comments (was: ForCES
framework: summary of comments from Russ Housley and authors' respond)

Lily et al,

I think this draft is ready. The only issue i have is on section 8.
Could you move section 8.2.1 and make it section 8.1 ?
I think that it makes more sense to talk about NE security admin/config
right at the beggining of section 8 so you can set context for the rest
of the text. You can still point to the DoS concerns at that section as
you do now if you want.

[Lily]: I still prefer the current order because it flows better. 8.1 is
about threats, and 8.2 is about the solution at high level. So moving
8.2.1 in front of threats do not flow naturally. 

Other comments:
(Continue reading)

Alex Audu | 12 Jan 2004 18:35
Picon

Re: FW: Comments on framework-12

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.

"Yang, Lily L" wrote:

> I received these comments from Avri on the framework...
>
> -----Original Message-----
> From: avri [mailto:avri <at> psg.com]
> 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.
>
(Continue reading)


Gmane