Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 28 Apr 2004 12:18:19 -0700

Thanks a lot, Avri! We all appreciate this effort.

Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 28, 2004 11:17 AM
To: [email-masked]
Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a

On 27 apr 2004, at 22.40, Jamal Hadi Salim wrote:

> I know sooner or later we are going to start editing xml pieces.

Just wanted to let people know that the shell of the draft with all the 
pieces is ready.  So whenever everyone is ready to start dealing with 
it, they can.

a.

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 28 Apr 2004 14:30:23 -0700

Jamal,

My replies below...Thanks !
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

> Non-tech question:
> Where are we going with all the txt that so far you are the serial
> interface to. From the size of it, it seem inadequate to be going into
a
> draft. I know sooner or later we are going to start editing xml
pieces.
> Is this text a lead/summary to that?
> 
> [HK] Sure, you can use it as reference, summary or actually use some
of
> the text if you like (of course, I assume some elaboration will be
> needed in some/most cases)

I can see you are doing this out of necessity; progress is slow around
here. 

[yep]

> [HK] I am fine with this. If the FE already has an ID assigned (e.g.
by
> FEM), it should specify that in the Join Request msg. The CE can
always
> overwrite this value. If an ID has not been assigned for an FE, it
> should have value of 0 for FE ID in Join Request, in which case the CE
> must assign an ID for the FE. Does that sound good ?
> 

I know we had some problem with starting with PID 0 in our
implementation.
I will take a look at the code and my notes to see why. Essentially we
eventually went with PID being known preassociation and overriden post
association. In the long run we found no need for overriding.
I will get back on this.

[Ok, let us know...we can have some other fixed value for the FEID
instead of 0, if that makes sense]

> Hormuzd, can i accuse you of hogging this? ;->
> What text can i write? I asked in the other email
> 
> [HK] That's the nicest accusation I have heard so far :-)) After the
> protocol scenarios, which are mostly diagrams clarifying the messages,
> the next topic 4.c. is the Common Header. We had one main issue on
Type
> ID which needed to be discussed & closed. Feel free to post some text
on
> that.
> Here is the remaining list for your reference,
> 4.c. Common Header
> 5. Support for Vendor functions
> 6. Master-Slave or Peer-to-Peer model

Wheres the discussion on FEM/CEM? 
[HK] That was part of topic 3. I partially covered topic 3 by showing
messages for Capability Exchange, Feel free to post text on FEM/CEM if
you like.

> BTW, even though you may not post text on all issues, I find comments
> from yourself, Weiming and others very useful...that adds a lot of
value
> to the text. In most cases, I try to reuse most of the text in your
> comments.

The problem is people are lined up to write some XML text; however, in
retrospect what you are doing is ok - so continue with the momentum and
on my part i will try to respond ASAP - which should keep the ball
roling faster. I will do something else that is useful when opportunity
presents itself. 

Thanks a lot,
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 28 Apr 2004 23:34:17 -0700

Weiming,

This email is way too long, it seems like you are trying to clarify
multiple topics in this email. One suggestion for the future, break it
into multiple emails and put the appropriate subject headers, that makes
it a lot easier for everyone to promptly respond.

I'll go ahead and split this email into multiple smaller ones and try to
respond to all your comments.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wang,Weiming

Couple of comments...I have categorized the messages in a certain way,
however that is Not important to me at this point. I am fine with
however, you guys would like to categorize this or Not categorize this
at all (?) Also, I have tried to incorporate some of the comments that I
received from Weiming, Jamal, others.

[Weiming] I suggest that we first list out all possible and necessary
messages,
then decide if they should be categorized or not. Therefore, the most
important
for current discussion is not to miss something (messages).
[HK] Agree, that is my thinking as well

Note to Weiming: The reason for not categorizing these messages as "FE
messages" is so that they can be used by the CEs also in the future. For
e.g., the Leave message can be used by the CE also to leave a ForCES
association with a FE (actually this is a requirement as well but I wont
mention the RFC here, don't want to piss off my friend(Jamal) :-)).
Also, the State messages such as UP/DOWN can be used by CEs also thus
making the protocol future-proof in a way & simplifying some of the HA
schemes.

[Weiming] From my viewpoint, this (for future use) may actually become a
reason
why we need to explicitly indicate the message functioning direction.
I'm sure
in many cases, the operation toward FE is different from that toward CE
even if
they have the same operation name, e.g., if we allow FE to query CE in
the
future, the message formats for CE->FE and FE->CE are surely different
because CE
does not have sth like CE model, LFB. I'm also sure we will have
messages that
can only be allowed functioning in one direction, e.g., config. msg.
which is
only allowed  from CE->FE. Unless we decide that our model is purely
peer-to-peer instead  mainly Master-slave based. (Jamal, Avri:
we may need to lunch this master-slave issue discussion right now along
with the
protocol message discussion).  Back to Hormuzd's question, another
reason to use
the FE/CE prefix is it may be more clear in the meaning and may be
easier for
customers to use.
[HK] I don't believe we need to use FE/CE prefixes for all messages. I
agree that messages such as Configuration Req are only from CE to FE.
However, messages such as Join, leave can be used from FE->CE or CE->CE
(in the future) or CE->FE (only leave).  We should just be able to use
FEID/CEID for clarifying the direction, see Jamal's email on this.

Talking about the join message, I think the meaning FE uses is different
for
that CE (in the future?) uses. A FE actually sends join request message
to ask
to join, while a CE sends (if needed) only join command to inform the FE
of its
joining.
[HK] A Join message from a CE will not be sent to another FE, but to
other CEs only to try to join a NE (association of CEs & FEs). Hope this
clarifies your doubt. The Reqs/framework also mention this I believe.

Besides the join req/resp message, I also have more thinking on the
proposed
Req/Resp message action mode:

1. I think in a mainly Master-Slave based model, the Req/Resp mode
should mainly
be used by messages from FE->CE, while for CE->FE msgs, most of them are
commands, therefore I think of if it is proper to use word "Request" in
this
case. They are just commands, therefore it may be more comfortable to
say
'config message' instead of 'config request' message.
[HK] This is a terminology issue. We have been using Request messages to
carry Commands. There isn't much to this. Req/Resp is pretty easy
terminology, used in a lot of different protocols.

2. In many cases, Respose msgs are not so necessarily needed, too much
use of
them may unnecessarily  consume more resources. Also, remember we even
have ACK
mechanism to do the same thing. Even if in some cases we need to define
response
messages, I have a suggestion that we use a flag in the header or body
to allow
customers to have a choice whether or not to ask responses.
One more thing for response msg to use is we should note the "command
result"
format (as used in FACT) in the resp msg will eventually
be defined by our protocols instead by FE model, I'm just afraid FE
model will
not be able to define such things.
[HK] Responses are needed for most messages to give the Status of a
request and to the meet the timeliness requirement. You can call this an
ACK, but the difference is that a Status or command result is included
in Responses as opposed to ACKs, which is just like an echo of the
original msg. BTW, I believe the FE Model is already defining or soon
going to define these "command results" as you call it.

Jamal: I'm afraid what I here talked about the msg direction is a little
different from what you may mean. I just mean that we may need to tell
customers
sth like 'this message can only be sent from CE to FE, and not allowed
from FE
to CE'. 
[HK] We will need to put text in the message explanation to take care of
this anyway. A FE/CE prefix doesn't necessarily solve this problem.

I see what you mean may be for those msgs that can be sent in either
directions and you propose that the direction can be implicitly defined
by
defining the Src ID and Dest ID. I agree that in this case, we may only
need to
define one msg for both directions, while let the FEid and CEid to
decide the
direction. And I even think that such direction is very obvious during
implementation, because we may never expect a FE will get messages from
other
FEs.

[HK] Sure, this is the same point I was making before. So we agree on
this (using CEID, FEID) then ?

Talking about this, I have to mention our old drafts again. I think the
Netlink2
addressing scheme can tell wether the message is from CE or FE,  because
the PID
is universal and the 'Src PID' "Dest. PID' can either be FE or CE, but
FACT and
GRMP schemes can not. Therefore, I'm afraid here we also have to discuss
the
common header and addressing mode first. I think we need now decide if
we use
static field in the header for CE id or FE id, or we just use 'Src. ID'
and
'Dest. ID'. In the latter mode, we need to define the address space
separately
for FEid and CEid.
[/Weiming]
[HK] I see your point, I think :) If we call them Src ID, Dest ID,
(instead or CEID, FEID) they can be used by the CE to send a message to
another CE,...right ? Just as they can be used by a FE to send message
to a CE. I am fine with this, I don't think its more than a terminology
change in the header (replace CEID, FEID with SrcID, DestID). We don't
need any additional address space as you are suggesting.

Hope this helps,

Thanks
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 28 Apr 2004 23:37:49 -0700

Weiming,

-----Original Message-----
reason
> > why we need to explicitly indicate the message functioning
direction. I'm
sure
> > in many cases, the operation toward FE is different from that toward
CE even
if
> > they have the same operation name, e.g., if we allow FE to query CE
in the
> > future, the message formats for CE->FE and FE->CE are surely
diffrent
because CE
> > does not have sth like CE model, LFB. I'm also sure we will have
messages
that
> > can only be allowed functioning in one direction, e.g., config. msg.
which
is
> > we may need to lunch this master-slave issue discussion right now
along with
the
> > protocol message discussion).  Back to Hormuzd's question, another
reason to
use
> > the FE/CE prefix is it may be more clear in the meaning and may be
easier
for
> > customers to use.
>
> To take from netlink2 experience: The important piece is the end
> processor of the "command".
> If direction is CE->FE thats a config. If direction is FE->CE
typically
> CE would intepret that to be an event.
>
[Wweiming]I think this approach (we may also call it implicit approach)
may be
quite different from that Hormuzd proposed. Could you try to list more
msgs
based on this idea to ease our discussion? I think it is also a feasible
approach. My idea was actually moer based on Hormuzd's proposal, that
is, the
config msg is only allowed from CE->FE. In this case, I think to mark
the
direction that is to mark as 'FE config' is necessary.
Because the following discussion is more related to this base, therefore
I also
just stop here to let us decide this first. Hormuzd, could you have some
of your
idea? Thank you.

[HK] I agree with Jamal, I think we are both saying the same thing.
Adding FE/CE prefixes isnt necessary and actually doesn't solve the
problem that you are stating, we need to add text to clarify this in the
draft anyways.

Thanks
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 29 Apr 2004 11:56:35 -0700

Jamal,

I agree with your comments below. I hope this helps clarify Weiming's
doubts.

-----Original Message-----

typically
> [Wweiming]I think this approach (we may also call it implicit
approach) may be
msgs
is, the
the
> Because the following discussion is more related to this base,
therefore I also
> just stop here to let us decide this first. Hormuzd, could you have
some of your
> idea? Thank you.

Lets assume a node (CE or FE) receives a message destined to its ID;
such a node will have to intepret and may execute the message - its like
opening a letter with your name(ID) on the envelope.  
The execution could be noop such as silently discarding it or returning 
"please reset your brain" (as in the case of TCP RST) in a response. 

Defining the name of the address to be FEid or CEid doesnt add any
value. Defining the execution of a message when it is received by FE or
CE is valuable. And i think this is done in the protcol description
text.
[HK] Exactly, this is the same point that I am making to Weiming.

Lets take the case of FE->CE in which case CE is receiving the same or
similar message

2a) It could be used as a subset (not full set) of Event Notification
Messages. This is what netlink2 did. i.e instead of viewing it the way
FE did as a command, you view it as something that has already happened.
A message of "update table X (for LFB Y) with config Z" as in #1a has a
different interpretation at the CE. CE now sees the same message as
"table X (on LFB Y) was updated with config X".  

2b) You could choose to ignore the message from CE unless it has a
speacial tag to it. Hormuzd refers to it as Event Notification Messages;
i am indiferent and would like to wait until i see his posting of the
Event notification message.
[HK] I would like to do this soon as well, but I am spending too many
cycles on clarifying doubts right now.

So summary of above:
- we dont need to have FEid/CEid - srcID and dstID are sufficient. In
otherwords there are no ambiguities that need to be resolved.
- #2a and #2b are not very different - the message is the same only
difference is in what color of envelope(header) you use to deliver the
Event Notification Messages; 

[HK] I completely agree on this. I hope this clarifies Weiming's doubts.

Thanks,
Hormuzd

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 30 Apr 2004 13:28:09 -0700

BTW, we need a Join Resp as well. Sorry I forgot to mention this before.

Thanks
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Khosravi, Hormuzd M
Sent: Friday, April 30, 2004 11:18 AM
To: Weiming Wang; [email-masked]
Subject: RE: [Forces-protocol] Protocol Messages: topic 3 & 4a

Hi Weiming,

Thanks for this list! I am mostly fine with it except a few things..
I think we need Event Reg/De-reg messages, these are very different
semantically from Config.
Also, just a Join msg, instead of FE,CE Join if we use Src/Dst ID in the
header.
That's all.

Thanks again,
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Weiming Wang
Sent: Friday, April 30, 2004 9:57 AM
To: [email-masked]
Subject: Re: [Forces-protocol] Protocol Messages: topic 3 & 4a

Hi Hormuzd,

Ok, then, following compromise scheme may be acceptable to me, and
should let it
as our initials and open for changes if we enconter some difficulty when
we
actually begin writing  the text:

1.  Syncronization msg
    - for FE join, Leave, CE join, leave
2. Query / Query resp msg
    - include to query the capability
3. Config / Config resp msg

4. State Maintenance msg

5. Event Notification msg

6. Redirect msg

We do not need to categorize them.

Best regards,
Weiming