Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types)

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 18 May 2004 11:58:20 -0700

Hi Robert,

I believe we already agreed on these messages. Infact, having Subscribe
part of the Event message was your preference (from the last meetings
minute notes, if you remember). I don't see any scenarios in which both
these have to be combined. Event subscribe will most likely happen as
part of some initialization code on the CE, before you start configuring
the LFB. Also, I think your idea of FE LFB will still work fine with
State Maintenance msgs.

At this point, I think it will be wiser for us to put some text on paper
as we decided on the call, start writing the sections and we can always
revisit them once we have something concrete (I believe we allocated 10
days to reviewing the sections). 
Weiming and myself will be happy to get your input on Protocol Messages
so as to accommodate your idea (FE LFB).

Hope that helps,

regards
Hormuzd

-----Original Message-----
From: Robert Haas [mailto:[email-masked]] 

>
>Here is the summary of the Protocol Messages (Command Types)
>
>1.  Association Setup msg/ Setup Resp/ 
>    Association Teardown (using a flag or just msg type? - Weiming pls
>confirm)
>    
>2. Query / Query resp msg
>    - includes FE capability query, LFB Topology as well as Inter-FE
>Topology query
>
>3. Config / Config resp msg
>
>4. State Maintenance msg/ State Maintenance Resp
>    - includes Activate FE, Deactivate FE, Move Primary CE
>
I'd rather avoid creating new messages for each State Maintenance action

(especially since we don't know all of them yet). Instead, one could 
make use of an FE LFB with attributes sfor each of these actions, and 
use the standard Config messages to act on these attributes. Adding new 
actions will simply translate into new versions of the FE LFB, instead 
of new protocol message types.

>
>5. Event msg / Event Resp
>    - includes Subscribe, Unsubscribe, Report/Notification
>
>6. Packet Redirect msg
>    - includes FE->CE redirect packet as well as CE->FE forward packet
>
>7. Heart Beat msg
>  
>

I want to make sure that we all understand the implications of choosing 
such message types:

For instance, this means that it is not possible to mix in the same PL 
message a Config action as well as an Event Subscribe action for the 
same LFB instance. I find this annoying especially becauseI don't 
understand why we need to differentiate at the Common-Header level 
between a Config and an Event Subscribe, as both are destined to an LFB 
anyway, as opposed to Association Setup or HB messages.

Regards,
-Robert

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

---

From: Robert Haas <[email-masked]>
Date: Wed, 19 May 2004 11:01:08 +0200

Hi Hormuzd,

Khosravi, Hormuzd M wrote:

>Hi Robert,
>
>I believe we already agreed on these messages.
>
I was questioning the current thinking only for the sake of a having a 
solid design. I think the current agreement did not consider the issue I 
raised. I do not necessarily mean that we need to change what we have 
now, but at least think of good reasons why we should keep it as is.

> Infact, having Subscribe
>minute notes, if you remember).
>
True. Further thinking caused me to question this that's why I wanted to 
have the list's opinion.

> I don't see any scenarios in which both
>the LFB.
Here is another example in which I think we may need to dynamically 
subscribe to events:

The CE adds a filtering rule, and at the same time requires event to be 
fired whenever a packet matches this rule. This can be for the purpose 
of DoS detection, for instance.

Let me know if this is a convincing example.

> Also, I think your idea of FE LFB will still work fine with
>State Maintenance msgs.
>

Thanks,
-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