Subject: [Forces-protocol] RE: Section 6 update

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 22 Oct 2004 09:20:45 -0700

Yes, having a new section for FE LFB, etc is a good idea.
Also, we can have a new section for the protocol State Machine (after Protocol Messages)
 
regards
Hormuzd

________________________________

From: Robert Haas [mailto:[email-masked]] 
Sent: Friday, October 22, 2004 2:33 AM
To: Wang,Weiming
Cc: Khosravi, Hormuzd M; Ligang Dong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Section 6 update

Weiming.
I suggest we make a  new section "FE LFB and FE Protocol LFB" just before Section 5 "Common Header", instead of leaving this to section 3.3.2. This will reflect the importance of those two LFBs in the operation of the protocol.

I'll post my text when ready, please do the same, and we'll merge.

-Robert

Wang,Weiming wrote:

	Robert, 
	 
	Don't worry too much about the FE LFB and Protocol LFB, I think it can be fit it well in the sections.
	 
	Actually I can do something for Protocol LFB and FE LFB if you think possible.
	 
	Regards,
	Weiming
	 
	----- Original Message ----- 

		From: Khosravi, Hormuzd M <mailto:[email-masked]>  
		To: Robert Haas <mailto:[email-masked]>  
		Cc: Ligang Dong <mailto:[email-masked]>  ; [email-masked] ; [email-masked] ; [email-masked] ; Weiming Wang <mailto:[email-masked]>  ; [email-masked] 
		Sent: Friday, October 22, 2004 4:35 PM
		Subject: Section 6 update

		Hi Robert, All

		Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly used the text that Jamal sent out wherever applicable.

		You can update sections 6.2, 6.4, 6.5 -> however, I would check with Weiming first as courtesy since he is working on these sections.

		BTW, there were lots of things in the todo list I sent out...

		Header Section - Jamal/Robert/Weiming?

		Protocol LFB - Robert/Others?

		FE LFB - Robert/Others?

		CE LFB - ?

		State Machine for Protocol - Ligang (taken)

		Will you be working on any of these ??

		Pls do let us know...I will start working on whatever hasn't been claimed by tomorrow morning my time.

		Thanks

		Hormuzd

________________________________

		From: Robert Haas [mailto:[email-masked]] 
		Sent: Friday, October 22, 2004 12:39 AM
		To: Khosravi, Hormuzd M
		Cc: Ligang Dong; [email-masked]; [email-masked]; [email-masked]; Weiming Wang; [email-masked]
		Subject: Re: Applying changes to Section 6 (Protocol Messages)

		Hormuzd,
		Could you please pass the token on section 6 together with your latest version so I can start editing it ?
		Thanks,
		-Robert
		
		Khosravi, Hormuzd M wrote:

		Robert,

		As I said, your note mostly looks...I have put some more comments below...

		(It would help a lot if you start defining the FE, Protocol LFBs...)

________________________________

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

		All: below is a rough list of changes and pending issues regarding section 6. Please review.
		
		 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, this would be part of ProtocolLFB even if it is in this message] 
		
		 6.1.2 How has the srcID=0 case been handled in the interop tests ? Is this really feasible ?  [Yes it worked fine during Interop] 
		
		 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.  [Agreed it would be in some LFB, but not sure which LFB this would be part of...?] 
		
		 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB.  [Sure, why dont you start defining some of these objects...then we can discuss more in detail] 
		
		 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB.  [Yes, these messages will be part of Events or Config...we need to specify this] 
		
		 6.7 HB remains as is.  [Agreed] 
		
		In summary, we have the following operations defined for each message type ( I broke the table into 3 parts):
		 [looks good!] 
		OPERATION       APPLICABLE MESSAGE TYPES
		
		                Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat
		
		no operations
		defined

		                Query  Query-Resp  Config  Config-Resp
		SET, DEL, UPDATE                     x          x
		GET               x         x
		EV_S, EV_U                           x          x
		
		(for event subscribe/unsubscribe)

		                Packet-Redir
		
		PAYLOAD            x

		                Event-Notif  Event-Notif-Resp
		EVENT              x                x
		
		Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ?  [These are all very different, lets leave them as is, its not necessary to have multiple operations in all messages] 
		
		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 <http://www.zurich.ibm.com/%7Erha> 

-- 
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: Fri, 22 Oct 2004 18:31:21 +0200

Hormuzd,
Do you have the xml for the update you posted ?
Thanks,
-Robert

Khosravi, Hormuzd M wrote:

> ------------------------------------------------------------------------
> Cc: Khosravi, Hormuzd M; Ligang Dong; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> I suggest we make a  new section "FE LFB and FE Protocol LFB" just 
> before Section 5 "Common Header", instead of leaving this to section 
> 3.3.2. This will reflect the importance of those two LFBs in the 
> operation of the protocol.
>
>>     Cc: Ligang Dong <mailto:[email-masked]> ; [email-masked]
>>     <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ;
>>     [email-masked] <mailto:[email-masked]> ; Weiming Wang
>>     <mailto:[email-masked]> ; [email-masked]
>>     <mailto:[email-masked]>
>>     Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7
>>     (same). I have directly used the text that Jamal sent out
>>     wherever applicable.
>>
>>     You can update sections 6.2, 6.4, 6.5 -> however, I would check
>>     with Weiming first as courtesy since he is working on these sections.
>>
>>      
>>
>>     ------------------------------------------------------------------------
>>
>>     Cc: Ligang Dong; [email-masked]; [email-masked];
>>     [email-masked]; Weiming Wang; [email-masked]
>>     Could you please pass the token on section 6 together with your
>>     latest version so I can start editing it ?
>>     Thanks,
>>     -Robert
>>
>>     ------------------------------------------------------------------------
>>
>>      6.1.1 Association: The CE could obtain the HBI with a
>>     Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc
>>     msg strcutrue, we have to remove HBI from the Assoc Setup msg. 
>>     [Agreed, this would be part of ProtocolLFB even if it is in this
>>     message] 
>>
>>      6.1.2 How has the srcID=0 case been handled in the interop tests
>>     ? Is this really feasible ?  [Yes it worked fine during Interop] 
>>
>>      6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes
>>     into the FEProtocolLFB.  [Agreed it would be in some LFB, but not
>>     sure which LFB this would be part of...?] 
>>
>>      6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB.
>>     Note that for the sake of symmetry, we should introduce a
>>     CEProtocolLFB.  [Sure, why dont you start defining some of these
>>     objects...then we can discuss more in detail] 
>>
>>      6.6 State Maintenance: FE Activate/Deactivate/Shutdown become
>>     settable attributes in the FEProtocolLFB.  [Yes, these messages
>>     will be part of Events or Config...we need to specify this] 
>>
>>     In summary, we have the following operations defined for each
>>     message type ( I broke the table into 3 parts):
>>      [looks good!] 
>>     Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp),
>>     we have each time only one operation. Looks a bit redundant.
>>     Ideas ?  [These are all very different, lets leave them as is,
>>     its not necessary to have multiple operations in all messages] 
>>
>>     Regards,
>>     -Robert
>>
>>
>>
>>-- 
>>
>>Robert Haas
>>