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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 15 Oct 2004 13:58:54 -0700

Jamal, 

I think we are mostly insyc, the only issue seems to be whether to
combine GET/SET in a single message. I will post an email to the model
team and try to get their explicit opinion on this.

Regarding HB msgs, these have been discussed a lot last time. I don't
think these are affect by FE Object, etc...but this is a minor one, I
think.

Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Friday, October 15, 2004 11:46 AM
To: Khosravi, Hormuzd M
Cc: [email-masked]
Subject: RE: sync with BNF as discussed with model folks

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 15 Oct 2004 20:12:50 -0400

> team and try to get their explicit opinion on this.

I just clarified the real contention in this is whether we should keep
query message or the GET.

> think these are affect by FE Object, etc...but this is a minor one, I

I think its minor for deadline purpsoses. However, as is noted
everything MUST target an LFB. This message also applies.

cheers,
jamal