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

From: [email-masked]
Date: Wed, 20 Oct 2004 05:30:19 -0400

Hello,
 
Agree. Keeping config and query makes simpler.

But another point is forces is mostly going to be used as configuration protocol, in may case GET/(and SET) as automatic 
may be ideal one.(SET operation is optional). Are we are not going to accommodate command bundling, this discussion thread is converging well, may its a correct place to 
resolve that also.

If if I recollect correctly, in one of the teleconference - the issue of command this issue was popped and was didn't got time to resolve.

regards
ramg
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Robert Haas
Sent: Tuesday, October 19, 2004 4:08 PM
To: [email-masked]
Cc: Khosravi, Hormuzd M; [email-masked]
Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks

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

Jamal Hadi Salim wrote: 

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

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. 

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

Joel or the Model team ? I didn't get that impression, but I might have

missed it.

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.

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.

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

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.

Sounds reasonable.

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.

But who is the target for this message now?

Remember, there MUST be an LFB as the end target.

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

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

_______________________________________________

Forces-protocol mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/forces-protocol

-- 

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
_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Robert Haas <[email-masked]>
Date: Wed, 20 Oct 2004 13:53:05 +0200

Ram,
Not sure what you mean by "automatic" ?
Bundling of GETs and SETs in the same message is somehow similar to 
command compounds in NFSv4. I am forwarding the note again FYI.
But at this point I don't think the group is willing to support this 
kind of compound commands.

Regards,
-Robert

[email-masked] wrote:

> But another point is forces is mostly going to be used as 
> configuration protocol, in may case GET/(and SET) as automatic
> may be ideal one.(SET operation is optional). Are we are not going to 
> accommodate command bundling, this discussion thread is converging 
> well, may its a correct place to
> resolve that also.
>  
>  
>  
> If if I recollect correctly, in one of the teleconference - the issue 
> of command this issue was popped and was didn't got time to resolve.
>  
>  
> regards
> ramg
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of ext Robert Haas
> 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:
>
> 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
>
> Jamal Hadi Salim wrote:
>