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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 20 Oct 2004 10:56:22 -0700

Ram,
 
I don't think this is related to command bundling...we will still support cmd bundling especially for Config (Add/Del/Update, etc...)
Pls refer to all the emails posted on this topic and it will be clear.
 
Thanks
Hormuzd

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 20, 2004 2:30 AM
To: [email-masked]; [email-masked]; Khosravi, Hormuzd M
Cc: [email-masked]
Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks

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: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 20 Oct 2004 12:36:28 -0700

Jamal,
 
I am not sure if you recall, but we had a ton of discussion on HBs during the last protocol draft before we decided to support them as minimal msgs (only header) with least possible overhead. Let me know if you would like me to forward you some of the emails (I will do so privately if needed), but I hope this issue doesn't take up a lot of our bandwidth again.
 
regards
Hormuzd

From: Robert Haas [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2004 12:55 AM
To: [email-masked]
Cc: Khosravi, Hormuzd M; [email-masked]
Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks

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

Jamal Hadi Salim wrote:

	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:
		
		- 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)
		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: 

			      

			      

				The other reason is that 

			      

				        

			      

				this

					message.

			      

				?

				        

			Sounds reasonable.

			      

				        

			
			
			cheers,
			jamal

---

From: [email-masked]
Date: Thu, 21 Oct 2004 08:18:26 -0400

Hello Jamal,
 
I agree to Robert statement, I though we had an agreement on that. As far as ForCES protocol goes the FE and CE are ForCES endpoints, if we limit our HB interactio to these two endpoints that should  be fine. LFB interaction with FE is internal to FE and it may be propriety also. 

Robert also pointed out that query can be an alternative approach to do for each LFB.
 
Regards
Ramg
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Khosravi, Hormuzd M
Sent: Wednesday, October 20, 2004 3:36 PM
To: Robert Haas; [email-masked]
Cc: [email-masked]
Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks

Jamal,

regards
Hormuzd

  _____  

Jamal,

-Robert

Jamal Hadi Salim wrote:

Robert,

cheers,

jamal

read the threads ...

In summary:

messages.

      |

      |

      +--- T = LFBselect

               |

               |

               |

or like this:

Regards,

-Robert

Jamal Hadi Salim wrote: 

  

        

  

The other reason is that 

        

  

missed it.

message.

          

this

message.

6.4.

event.

        

like:

  

          

?

msgs.

Sounds reasonable.

          

on this msg.

  

on defining this

cheers,

jamal

[email-masked]

  

-- 

Robert Haas

Säumerstrasse 4

  

-- 

Robert Haas

Säumerstrasse 4