Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 14 Oct 2004 22:33:52 -0700

Thanks Jamal, my responses below. I think we are mostly insync,

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

> 6.2 -> I don't think this Has_to_be removed. We can still use the
format
> similar to what you have suggested with the Query message...Unless we
> think that operations such as GET/SET need to be bundled in a single
> message (which has not been my experience), we can leave the Query
msgs
> in with new format.

Theory is they can be bundled.
Is there a reason you want to keep that type=query?
[HK] The responses will be more involved for query, also the request
<path> might be more involved. The other reason is that I have never
seen query bundled with SET/DEL in practice...Is this a requirement from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

> 6.3 -> looks good...we might still need the Flags, also the Event Type
> is needed since Event Subscribe, UnSubscribe are currently part of
this
> message.

Probably makes sense to keep event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=event in
6.4.
Do we then need operation = Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
 
> 6.4 -> answer to your question is above-subscription is part of Config
> msg currently. I think Event notification is quite different from
Config
> and makes sense to have this separate. For most cases, these are
> asynchronous and do not need a response back either.(The format is
> similar to Config)

Agreed on the config. The notifications sound good for a start; we could
refine later. 

[HK] Yep, our current format for these is similar to what you proposed

> 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB? 

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

> 6.7 -> remains the same (I assume)

I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.

I think that the two FE LFBs deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

Regards
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 15 Oct 2004 14:45:58 -0400

On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote:

> [HK] The responses will be more involved for query, 
> also the request <path> might be more involved. 

This is true. But i dont know how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or 
config. I would think the response will also have a path and the
requested data for that path.

> The other reason is that 
> I have never seen query bundled with SET/DEL in practice...

I dont either; dont wanna rule it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=query.

> Is this a requirement from

I cant remember where it came or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=query i
think that would help. Otherwise we would have an additional unneeded
message.

> you're suggesting seems reasonable.

I think its safer to have the XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation = subscribe; operand = eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
  
> being a LFB. The FE States would be part of the FE object sent in Event

Sounds reasonable.

> confusing this with the FE Protocol Object, that doesn't have any effect

But who is the target for this message now?
Remember, there MUST be an LFB as the end target.

> [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead

We may all have to be involved in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Tue, 19 Oct 2004 22:07:35 +0200

I hope my note makes it before Jamal's noon ... Finally I got a 3 hours 
slot on a train ride (with phone off and no email access) to read the 
threads ...

In summary:

- I think it is good to keep the query separate from config. Reasons 
given by Steve/Zsolt sound very valid to me.

- I am glad to see the "consolidation" into FE Protocol LFB operations 
of FE attributes config, FE events, and association maintenance messages.

- The heartbeat message is currently not "targeted" at the FE protocol 
LFB. It is an exception to the rule. The reasoning was to keep such 
messages as short and simple as possible. Basically, you have the choice 
between a heartbeat to look like this:

main hdr (eg type = heartbeat)
      |
      |
      +--- T = LFBselect
               |
               +-- LFBCLASSID = FE Protocol LFB Class (=0x01)
               |
               |
               +-- LFBInstance = FE Protocol LFB Instance(=0x01)

or like this:

main hdr (eg type = heartbeat)

The difference is only 6-8 bytes (I don't remember what was the final 
consensus for the T in the TLV). But as the values in the LFBSelect TLV 
must ALWAYS be 0x01 and 0x01 (we have statically defined the class and 
instance ID of the FE protocol LFB), it is a waste to transmit them. And 
if you do, then someone might use wrong values and then you have to 
decide how to deal with such cases.

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: 19 Oct 2004 16:21:39 -0400

Robert,
Could someone not send a heartbeat to a specific LFB?
In which case a heartbe to the FE object equates a heartbeat to the FE.

cheers,
jamal

On Tue, 2004-10-19 at 16:07, Robert Haas wrote:
> I hope my note makes it before Jamal's noon ... Finally I got a 3
> hours slot on a train ride (with phone off and no email access) to
> read the threads ...
> 
> In summary:
> 
> messages as short and simple as possible. Basically, you have the
> choice between a heartbeat to look like this:
> 
> consensus for the T in the TLV). But as the values in the LFBSelect
> TLV must ALWAYS be 0x01 and 0x01 (we have statically defined the class
> and instance ID of the FE protocol LFB), it is a waste to transmit
> them. And if you do, then someone might use wrong values and then you
> have to decide how to deal with such cases.
> 
> Regards,
> -Robert
> 
> Jamal Hadi Salim wrote:

---

From: Robert Haas <[email-masked]>
Date: Wed, 20 Oct 2004 09:55:06 +0200

Jamal,
I don't see the point of sending a heartbeat to any LFB other than the 
FE Protocol LFB. Here is why:

The PL-level heartbeat is really about saying: the sender (FE or CE) of 
this hearbeat is alive. FEs will typically be sending this to their CE 
(after the CE has configured in the FE Protocol LFB at what frequency it 
wants to receive heartbeats). Note that in the current draft we have 
explicitely asked to ignore any ACK flag that would be set in the 
hearbeat message header.

If what you want to have is a ECHO-REQUEST/ECHO-REPLY to a particular 
LFB (to check its status, etc), what should be used instead is a Query 
msg with GET(status of the particular LFB instance). Would this answer 
your needs ?

-Robert