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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 4 May 2004 13:02:52 -0700

Hi All

Here is the list of Protocol Messages based on final comments made by
Jamal.

Association Setup, Setup Resp msg
Association Teardown msg

Query/Query Resp msg (including Capability query)

Config/Config Resp msg

Subscribe/Unsubscribe msg

State Maintenance msg (includes, Activate, Deactivate, MovePrimaryCE,
etc)

Event Notification msg (includes, Heartbeats (?), FE UP/DOWN, etc)

Packet Redirect msg

Regards
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

> > 2. I suppose Syn msg is one msg, with the flag in the msg body (or
> TLV) to
> > notarize if it's Join or leave, and as you mentioned using Src/Dst
ID
> (even  by
> > context, as Jamal mentioned) to notarize that of CE or FE (There is
no
> any
> > specific join msg then). Want Jamal to verify it.
> 
> probably same context as subscribe above. A command maybe called
> synchronize with a flag to distinguish diffrent things.
> We need to show a state machine for a FE joining/leaving.
> [HK] I don't like the term SYN or synchronize, since it is used by
TCP.
> May be we can use names like "Association Setup/teardown" or
> "Bind/Unbind" which are more ForCES specific ? 

setup/connect etc should be fine. I do find SYN confuses a lot of
people;  TCP seems to have taken a monopoly there ;->

> Let me know which one you
> like. Also, I am fine with having a single message such as Association
> with a flag to indicate whether it is setup or teardown, although I
> think it would be cleaner to have them as separate messages.

Either is fine.

> Also i mentioned an idea we implemented which was to allow the CE to
> send a broadcast SYN messages to reset the FEs.
> Even if we dont do it this way, i think we need to have forced
restarts.
> 
> [HK] Yes, I agree we need to have forced restarts. I think the
> Maintenance message with a command/flag such as FE DOWN would be more
> suitable for this.
> 

Put something out and lets discuss it. What you suggest above sounds
reasonable.

cheers,
jamal

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 5 May 2004 12:10:39 +0800

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
Hi All

Association Setup, Setup Resp msg
Association Teardown msg
[Weiming] I agree to use the name 'Association'. But I can not find where Jamal
disagree to use only one msg approach, that is 'association msg'. Again, I have
to say a flag is definitely enough to indicate the command 'setup' 'setup resp',
and 'teardown'. Can you give reasons why they should be two msgs?

Config/Config Resp msg

Subscribe/Unsubscribe msg
[Weiming] This is a little ridiculous msg. Do you mean 'event sub/unsub' ? I
don't think Jamal agrees this also.  A config or a Event msg can do this well.

[Weiming] I suggest just an 'Event msg' may be better.

Packet Redirect msg

Regards
Hormuzd

Best regards,
Weiming

---

From: Robert Haas <[email-masked]>
Date: Wed, 05 May 2004 15:55:40 +0200

All,
I've seen some interesting ideas floating around regarding the number of 
messages needed. Let me illustrate the kind of messages I think we need 
with two scenari:

Usual scenario:
CE sends a Config message to FE. FE applies it and sends an appropriate 
response (ACK if successful or NACK otherwise). This can be the same 
message type with a flag that indicates the result.

Batching scenario with 2-phase commit:
CE sends a serie (batch or bundle, as you prefer) of Config messages to 
the FE, followed by a Commit message (which could be signalled with a 
flag in the last Config message). The FE returns a serie of responses to 
indicate that it got the messages, but DOES NOT apply them until the 
Commit comes. The Response to the Commit indicates if the batch of 
Config messages was successfully applied or not.

Conclusion:
You need a Config message type.
You may use a flag to indicate whether it's the message itself, an ACK, 
or an NACK.
You may use a flag to indicate if the message is one of a batch, or the 
last of the batch (i.e., the Commit).

In the Query case, as there is no 2-phase commit necessary:
You need a Query message type.
You may use a flag to indicate whether it's the message, an ACK, or an NACK.

I'd like to know more about the type of actions that can be performed on 
the LFBs according to the model. Maybe a Config and a Query are enough. 
But I don't know how the Event Generation is handled in the model. Can 
someone explain ?

For FE UP and DOWN, I'd rather include this in existing message types. 
For instance, define an FE LFB that can be acted upon, and events such 
as UP and DOWN may be subscribed to. Use the same messages and semantics 
as the one used for other LFBs.

You may apply the same reasoning to a Packet Redirect LFB, which 
produces packets as events.

Regards,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: Jamal Hadi Salim <[email-masked]>
Date: 05 May 2004 09:52:44 -0400

Olla,

> and 'teardown'. Can you give reasons why they should be two msgs?

We need to have a setup and teardown. The setup can be either accepted
or rejected. Thats the general concept - and i dont think anyone
disagrees with that. I personally dont care what you end up calling such
messages. 
Theres two ways to represent the messages:
1) A command for both.
2) A single command with flags differentiating the two.

The first scheme has more commands being used.
The second scheme indicates we need flags in the common header. I think
we will have flags regardless: I know Hormuzd has tried to pinpoint
where flags on the main header could be moved to be only specific to a
message but i would violently disagree with such a move at this stage.

I would prefer #2, but i wont fight over it.

> don't think Jamal agrees this also.  A config or a Event msg can do this well.

Again this relates to the peer discussion going on. I will move this
under that subject.

> [Weiming] I suggest just an 'Event msg' may be better.

Event maybe insufficient if you need to have a response to a heartbeart.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 05 May 2004 09:59:00 -0400

> don't think Jamal agrees this also.  A config or a Event msg can do this well.

I think we need config messages going from FE to CE informing it of
events as well. Not all events fit under this message, but a subset
does.
Is this what you are refering to Weiming? Just remember that not all
events fit in that model. Also the subscription is needed otherwise the
default should be you get no events.

cheers,
jamal