Subject: RE: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic 3 & 4a]

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 6 May 2004 19:38:24 -0700

Hi Robert,
 
I like this concept, however there are couple of issues I can think
of...
One, I wouldn't call it an LFB, that is very confusing to me.
Two, are you suggesting that this should be defined by the Model team
instead of this team ? I don't think so but again, if you call this LFB
we might run into that issue.
 
I think if we define the a TLV for addressing this, we can achieve the
same flexibility that you are talking about. That TLV could be carried
in whatever msg makes sense, e.g. Event msg or State Maintenance msg,
etc.
 
Does that help ? Let me know what you think.
 
Thanks again for this posting,
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Haas
Sent: Thursday, May 06, 2004 8:15 AM
To: [email-masked]
Subject: [Fwd: Re: [Forces-protocol] Summary : Protocol Messages: topic
3 & 4a]

Maybe my last message on that topic went unnoticed, so I wanted to again
stress the possibility to create an FE LFB (call it meta LFB, control
LFB, etc) that can be configured, events can be subscribed to, etc. The
difference between the FE LFB and the other "regular" LFBs is that no
data packet traverses the FE LFB. The purpose of the FE LFB is to
facilitate the control of the FE:

Examples:

- FE UP and DOWN don't need to be special ForCES messages. Instead, they
can be events originated by the FE LFB.
- Configuring the interval timer for heartbeats messages can be done
using a Config message to the hearbeat interval attribute of the FE LFB.

The reason to introduce this LFB versus creating specific ForCES
messages is flexibility: at some point in time, if we need to enhance
the ForCES protocol, we don't necessarily need to change the protocol
itself. Instead, we can create a new version of the FE LFB that supports
new features.

I'd like to have your comments on such an FE LFB.

Regards,
-Robert

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 10 May 2004 11:32:58 -0700

Weiming, Jamal, All

-----Original Message-----
I'm afraid our discussion has come to the same point. Actually my idea
is a
little different from Robert's in that, i would not call the 'thing' a
LFB,
because many of its functions actually have to be ready there even
before the
ForCES protocol begin to run, e.g., the protocol version information,
the TML
capability. While for a LFB, I more think it should be lunched by our
protocol,
that is, should work only after the protocol core runs. 

[HK] This is the dynamic LFB scenario, however the more common scenario
is the static LFB topology which everyone agrees is the default and must
be supported by the protocol.

I agree with Robert in
that, we do have such a 'thing' in the protocol, which I'm afraid not
included
in our current protocol contents. The 'thing' has its attributes,
capabilities,
evnets, which we need to describe in our protocol text.
To be more presie, I just think we need to define some attributes,
capabilities,
events by ourselves in our protocol, which can not be defined by FE
model.

[HK] I agree with this sentiment, we need to define this like FE States,
etc in the protocol and need to make it extensible. I do have similar
concerns as Jamal regarding the naming of this 'thing' :)

Regards
Hormuzd

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