Subject: Re: [issue 7] All PL messages addressed to only LFBs?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 8 Dec 2004 15:18:46 -0800

Jamal, 

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

> I think we may need to add text that when the message comes from the
> FE->CE that infact the LFB selector refers to the source LFB+instance
> and not destination.  Would this help?
>
> [HK] Yes, this would clear up the confusion. We should also add text
> stating that for CE->FE msgs the LFB selector refers to the
destination
> LFB, we don't have any text which states that either...but you had
> assumed this, thus there was the confusion about FE->CE msgs

Ok. I have opened ID#8 on the tracker. 

[HK] As far as I am concerned, this is resolved. 
I will send some text to Avri to clarify this in the draft.

> [HK] The only exception is for HB msg, which we have discussed in
great
> detail before.
<
> We have probably exchanged a dozen emails on the protocol
> list and even discussed it in one of our conf calls, so if you refer
to
> those or recall the discussion (it was done for efficiency reasons in
> this case), it will be pretty clear.
>

Which i disagree on - I suppose thats why we are having this discussion
to
begin with.
I oppose any exceptions. I have stated my reasons why i oppose this in
most of my previous emails on the subject (I could repeat them if
needed).

[HK] Actually this is a separate issue (HB msg) in my opinion, my
original issue has been resolved as I said in my comment above. The HB
msgs has been well discussed by the protocol team and the consensus is
already reflected in the draft since rev-00. If you want to reopen this,
you can do that...just call it a different issue... #9, for eg.

Regards
Hormuzd
P.s. Attached a few emails that I could find on this one (HB msg), there
are more but hopefully this will help you recall. Robert's email
explains all the reasoning as well.

Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks
From: <[email-masked]>
To: "Khosravi, Hormuzd M" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 21 Oct 2004 04:18:26 -0800

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,
 
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)
                      |
                      |
                      +--- 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

          

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

Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks
From: "Robert Haas" <[email-masked]>
To: <[email-masked]>
Cc: "Khosravi, Hormuzd M" <[email-masked]>, <[email-masked]>
Date: Tue, 19 Oct 2004 23:55:06 -0800

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

          

-- 
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: Wed, 8 Dec 2004 22:56:15 -0500

> I will send some text to Avri to clarify this in the draft.

Please do - When the text is agreeable i will close that item.
The main reason it is captured in the database is to ensure that the
issue is remembered and draft doesnt get released unless appropriate
text is in.

> you can do that...just call it a different issue... #9, for eg.

Do you agree with Roberts view below in which he states the heartbeat
going to the FE protocol Object? If yes, that would be fine for me to
move on since LFBselector would have to exist (even if the CE protocol
object is not used) and there would be a consistent grammar.

cheers,
jamal

PS:- Note in the text you quoted my contention is that i dont see
anything speacial to desire a "heartbeat to a FE or CE" - since all we
have to do is direct it to some LFB - I argue in that text that
heartbeats may be directed at other LFBs other than the FE protocol
object - to which there is disagreement from Robert and Ram. I dont wish
to bring that discussion up, at least not at this stage. And if we agree
targeting an LFBselector, it wouldnt matter anyways.