Subject: RE: [Forces-protocol] Notes from ForCES protocol meeting call

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 12 May 2004 11:50:19 -0700

Ok, I am fine with #2 below since it seems to be the preference of most
of you guys.
I guess our definition of cleaner is very different :)
Anyways, we can close on this one for now (atleast from my side)

Jamal, to address your last questions...I don't see any events from CE
to FE, other than CE State changes which are part of the State
Maintenance msgs (I think). So an Event msg from CE to FE is implicitly
a Event Subscribe msg, in my opinion. Other thoughts on this ?

BTW, have we decided on separate messages for HBs or is it part of
events ? If this is part of event then this might be another Event msg
from CE to FE.

Regards
Hormuzd

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

> 
>               cmd type    operation type
>     CE    ---------------------------------->    FE
> 
> 
>               subscribe        -
>           ----------------------------------> (Hormuzd's preference)
> 
> 
>                event        subscribe
>           ---------------------------------->  (Weiming+Robert)
> 
> 
>                config      event-subscribe
>           ---------------------------------->  (Weiming)
> 

I dont see any difference vetween the last two. They seem cleaner than
the first one, but i cant really conclude that until i see how the
message body looks like. 
Seems to me like you need to specify which is/are the event(s) of
interest. Also you should be able to subscribe to multiple events in one
PL message. 

Lets also discuss the events being sent from CE->FE while we are talking
about this.

cheers,
jamal

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

---

From: "Weiming Wang" <[email-masked]>
Date: Thu, 13 May 2004 23:09:45 +0800

Hormuzd, Jamal as well,

Comments inline.

Thank you.

Weiming

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

[Weiming]Sure.

[Weiming] I suggest to treat HB as an event. In this way, we then can start (by
subscribe) or stop (unsubscribe) it very easily. And moreover, we may even set
parameters to the HB such as the HB interval. Talking about this, I actually
have another thought that, HB is not the only event that need to setup
parameters before we start them, therefore, apart from 'subscribe' and
unsubscribe' for events, we may also need operations such as 'config'. Pls allow
me to use PDU to explain this more,  and also try to response to Jamal on the
possible event msg format ask.

EventMsg = CommonHeader(MsgType = 'Event') : TLV : TLV : ...  : TLV
TLV = Type : Length : Value
Type = EventFlag(1bit) : 'Subscribe' | 'Unsubscribe' | 'Report' | 'Config'
EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) '
Value (with EventFlag = 'LFBEvent') = LFBtypeID : LFBInstanceID :
EventDescription
Value (with EventFlag = 'NonLFBEvent') = EventDescription
EventDescription for 'Subscribe' / 'Unsubscribe' =  EventType(XML or ID, to be
decided?)
EventDescription for 'Report' = EventType : [Length] : EventValue(XML?)
EventDescription for 'Config' = EventType : [Length] :
EventParameterDescription(XML?)

Hope it helps to get to know each other's thoughts more.

[/Weiming]

Regards
Hormuzd

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

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Fri, 14 May 2004 01:03:50 +0200

Hormuzd,

>events ? If this is part of event then this might be another Event msg
I would regards this as an event also.
-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: 13 May 2004 20:02:05 -0400

> I guess our definition of cleaner is very different :)

We can always revisit later if we find what you propose makes more sense
The hard part is since the message types etc are not available sometimes
it is hard to visualize the benefits of a proposal.

> a Event Subscribe msg, in my opinion. Other thoughts on this ?

Sorry, typo. I meant FE->CE.
In other words can the response actually be exactly the same message as
that was sent from CE->FE and if so whether it becomes an event or a
config from FE->CE being intepreted as an event? We touched briefly on
this.

> events ? If this is part of event then this might be another Event msg

It does seem to make sense to have heartbeat a a separate message. But 
let me read on to see both arguements.

cheers,
jamal

> --Original Message--
> >     CE    -->    FE
> >           --> (Hormuzd's preference)
> > 
> > 
> >                event        subscribe
> >           -->  (Weiming+Robert)
> > 
> > 
> >                config      event-subscribe
> >           -->  (Weiming)
> > 
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 13 May 2004 21:06:19 -0400

> possible event msg format ask.

i think theres value in HB being able to be subscribed and unsubcribed
for; not sure though if it fits here in general. What if CE wants to
"ping"/hearbeat a LFB or FE?
You seem to indicate direction is FE->CE

> EventFlag = 'LFBEvent' | 'NonLFBEvent (or called FEEvent) '

Hormuzd posted some extra flags field in the TLV in the message body.
Should we shoot for consistency or do you think flags belong in the T
part?

> EventParameterDescription(XML?)

So what is the event value for config? Is it a config message that was
sent by CE to FE?

I think you have a good start above.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 14 May 2004 15:20:48 +0800

Hi Jamal, Hormuzd as well,

Thanks for the comments.

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
> You seem to indicate direction is FE->CE
[Weiming]I'm actually quite sure HB can be fit in the general Event Msg, even
for the case that you mentioned for LFB HB. First, I should say the direction
for Event Msg can be either FE->CE, CE->FE, just as you and Hormuzd earlier
proposed to indicate it by protocol text. The possible description for direction
may be as:
For Sub/Unsub ops, usually the event is from CE->FE
For Report(or Notification), either direction is possible.
For Configure parameters, the direction is CE->FE.

To subscribe an HB in a LFB, we just treat the HB as an event in a LFB, and
follow the general LFBEvent subscription ops.

> Should we shoot for consistency or do you think flags belong in the T
[Weiming]After I posted this, I realized that it may result in some confusion.
Here I set the EventFlag(1bit) in the Type field is only for the classification
of the Types, because I just realize there may be mainly two kind of Types here,
one for LFB ops, another for non LFB (or called FE (coarse layer) Event) ops. We
need to classify them because the followed Value format for them are quite
different.
To summarize, we may need not to use the EventFlag, instead, just have following
Types:

Type = 'LFBEventSub' | 'LFBEventUnsub' | 'LFBEventReport' | 'LFBEventConfig' |
       'FEEventSub'  | 'FEEventUnsub'  | 'FEEventReport'  | 'FEEventConfig';

Of course, the flag to indicate the LFB ops and NonLFB ops can also be put in
the TLV's V part, I'm also trying to see which is more precise in description.
Moreover, I think msgs like Query, Config, State maintenance as well as Event
msgs all have the problems to distinguish the ops between LFBs and NonLFBs(FE
Coarse layer), therefore, I agree we need to have a consistency between these
msgs regarding the description.

I'm also going to make a comments on Hormuzd's config msg format, where I try to
explain more of my thoughts on other extra flags there. So could you follow my
more reply there?
[/Weming]