Subject: [Forces-protocol] updated notes on BNF and layout

From: Jamal Hadi Salim <[email-masked]>
Date: 07 Oct 2004 12:37:29 -0400

Joel and myself have put an update to the earlier doc. Its now a
singular view. The issue on the tables and attribute update is open
pending on discussions on the table doc currently being discussed.
The decision on how things get laid out is in the hands of the protocol
team although this document bridges a lot of the views between the model
and the protocol side of things and so is a very good start.

Lets please start the ball rolling again on this and discuss.

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

---

From: Steven Blake <[email-masked]>
Date: Fri, 08 Oct 2004 10:45:05 -0400

On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote:

> PL level PDU : = MAINHDR<LFBselect>+ 
> LFBselect := LFBCLASSID<LFBTARGET>+
> LFBTARGET:=LFBInstance<OPER>+
> OPER:= <OPERATION [<path-data>]*>+
>
> - MAINHDR defines msg type, Target FE/CE ID etc.
> - LFBCLASSID is a 32 bit unique identifier per LFB class defined
> at class creation time.
> - LFBInstance is a 32 bit unique instance identifier of an LFB class
> - OPERATION is one of {ADD,DEL,GET, ??}

I suggest that LFBselect and LFBTARGET should be collapsed, like so:

LFBselect := LFBCLASSID:LFBInstance<OPER>+

If you want to target another instance of LFB class W in a PL-level
PDU, just add an additional LFBselect TLV.

I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of
16:16.

> path-data identifies the exact element targeted.
> It may have zero or more data values associated.
>
> In summary the described approach has the following characteristic:
> - there can be one or more LFB Classes targeted in a message (batch)

Ok

> - there can be one or more LFB instanceids per class targetted (batch)

Ok, but I would suggest doing that with another LFBselect TLV

> - There can one or more operation on an addressed LFB instanceid 
>   (batch)

Ok

> - There can be one or more targets per operation (batch)

Shouldn't this be the other way around: one or more operations per
target?

> - paths may have zero or more data values associated (flexibility)

You need this for GET.

[snip]

> path-data
> ----------
> The layout is still under discussion and so is left out from this 
> text.
>
> Each accessible attribute within an LFB is expected to have a 32 bit
> identifier. Attributes that are defined at class definition time 
> and which are immutable are reffered as "static". Attributes created
> at runtime are "dynamic" - example a table row is "dynamic".
>
> The path-data will have a map derived from the static as well as 
> dynamic IDs.

This is the first I've heard of attributes that are "created at
runtime", and not defined in the class definition.  I have no idea how
this would work.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Oct 2004 11:34:08 -0400

> PDU, just add an additional LFBselect TLV.

Its a flexibility issue. You end up wasting more bits for the scenario
of "class A instance 1,2,3,4,5,6,7,8,..x"
imagine X being a large number.
If above is not going a common case then i agree. The danger is assuming
what a common case is at this point in the design.

> I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of

We could do this. 
Note: It would not make any difference in the protocol
layout. 16 bits sounds like a good stick-finger-to-check-wind estimate.
But if we find we needed a little tiny more, we would have to change the
structure of that layout. So after going back and forth we just picked
32 bits.

> Ok, but I would suggest doing that with another LFBselect TLV

Refer to my comments above.

> Shouldn't this be the other way around: one or more operations per

target in this case implies path targets.
So you could have:
ADD { [path1,data}, {path2, data} ..}
GET { path3, path4, etc}
DEL { path7, path 8}

Does that make sense?

> > - paths may have zero or more data values associated (flexibility)

Indeed.

> runtime", and not defined in the class definition.  I have no idea how

This is my fault. But lets see if we can come up with proper wording.
In the simple case of NOOP LFB which has a table of dummy structs; each
dummy struct constituing a u32 foo1 and u32 foo2 then the following is
true of path map:
a) datatable and foo1, foo2 identifiers are defined at class definition
time.
b) table indexes are created post class definition at runtime.

its b) above that is refered to as "dynamic" 

What would be more approriate terminology?

cheers,
jamal

---

From: Steven Blake <[email-masked]>
Date: Fri, 08 Oct 2004 17:39:42 -0400

> what a common case is at this point in the design.

Assuming T:L is 16:16 bits, in your proposal (split LFBCLASSID and
LFBInstance specification into two TLVs) there are 32 wasted bits
every time a new LFBCLASSID needs to be specified (relative to my
proposal), while in my proposal (collapse them into one TLV) there are
32 wasted bits every time a new instance is specified for the same class
(relative to your proposal).  For the case where one class/instance
needs to be specified in the PL message, your proposal has 32 bits of
additional overhead (relative to mine).

My gut feel is that is that my proposal will wind up being more
efficient, but it is noise either way.  Collapsing them into one TLV is
one less TLV to worry about in the spec.

> structure of that layout. So after going back and forth we just picked

And you are worried about overhead?  :)

I'm satisfied either way, but I really think 16:16 is a safe choice.

> ADD { [path1,data}, {path2, data} ..}

Yeah, but I don't like it.  Now you have to have a more complicated OPER
TLV header to specify how many {path, data} sets it contains.  In the
end it will probably be much simpler to stick to one {path, data} set
per-OPER TLV.  

> What would be more approriate terminology?

Yes.  Now I understand.

Regards,

// Steve

---

From: Jamal Hadi Salim <[email-masked]>
Date: 08 Oct 2004 20:33:05 -0400

> On Fri, 2004-10-08 at 11:34, Jamal Hadi Salim wrote:

[..]
> proposal),

yes.

>  while in my proposal (collapse them into one TLV) there are
> (relative to your proposal). 

yes

>  For the case where one class/instance

yes

> one less TLV to worry about in the spec.

The proposal has optimization for _many instances_ in one class.
Your proposal has one less TLV hierachy and uses less bits if there was
one instance per class. I think the breakeven point you start gaining is
at around 1.5 factor. 
Start going into two instances or even more interesting go into 10 (I
have 6 LPM tables in a chip i use which typically are to be updated with
the same data in the brute force scheme) and it clearly becomes
beneficial to have it the way the doc positions it.
(I should say most of the chips I work with tend to have multiple
instances of the same tables for classification efficiency purposes)

OTOH, this may not be a very common case - in which case we should
optimize towards what you propose. 
I am indifferent - I like it the way it is but if people say its not the
common case, we should change it. It is common case for me.

> I'm satisfied either way, but I really think 16:16 is a safe choice.

16:16 sounds like a safe choice.
We could go 16:16; Joel and I doodled on this for a while. The logic is
it is easier to just make it 32 bits now and not worry about extending
it for a lot longer. If people wanna go 16:16 then i am fine with it.
 
> end it will probably be much simpler to stick to one {path, data} set

I dont think it will be that complicated or adds additional compute
cost. If you look at  { pathx, data} as a TLV, then what you have is a
series of TLVs in the same hierachy level. I could enumerate possible
layouts for what you guys proposed for the table index proposal - I was
hoping to do that later.

> > What would be more approriate terminology?

Is the term "dynamic" then acceptable?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 10 Oct 2004 01:13:10 -0400

Just to clarify one aspect, the separation of class and instance into TLVs 
is an idea I can live with, but one I personally do not consider 
necessary.  (Jamal and I went back and forth on that in trying to arrive at 
the compromise he summarized that we both can live with.)

It does seem (from other discussions) that there is rough consensus on 
including the class explicitly in the message, rather than having the 
remote end infer it from other tables.  THis does make debugging easier, 
which is probably enough reason all by itself.

With regard to the sizes of the identifiers, I have a couple of minor comments.
Firstly, with regard to the instance identifier size, even within a class, 
I can imagine an FE with more than 64K worth of LFBs.  FOr a simple, if 
slightly unlikely, case, consider an FE handling an OC48 that is prepared 
to subchannel it down to DS0s.  It may choose to represent each interface 
with its own LFB.  (That is not mandatory, but I can easily imagine it.)
With regard to class identifiers, we need to remmber that we have to allow 
for versioning of classes.  It would be nice if that could be easily 
separated for examination.  Which leads to a byte for version in the class 
id.  And we clearly need more than one byte for classes.

Thus, I am concluding that 32:32 may be what we need, even though it is 
ugly.  (We could probably do 24:24, but I don't think anyone really wants 
to go there.)

Yours,
Joel

---

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

> the compromise he summarized that we both can live with.)

I am also indifferent to whether class and instance identifiers are in
two different TLV or the same one. What would be nice however is to do a
technical evaluation and explore the pros/cons of each scheme.

To remind people, the pros/cons:
1) Both items in one TLV
Has advantage if the common case is going to be one of PL message
constituting a target of _one Class and one instance of that class_.
2) Items on two different TLVs
Has advantage if #1 above is not true.

My thinking is we dont know the answer to the above, hence #2 is safer.

Again lets evaluate, hopefuly without reasons which sound like "we have
done it like this before" - that does not fit as a technical evaluation.
Its an excuse.

> I can imagine an FE with more than 64K worth of LFBs.  

did you mean 64K instances of a LFB class?

> FOr a simple, if 

Thanks for bringing this example. 

Again iam also indifferent on the size. I prefer to err by increasing
the bit sizes to 32 from 16. 

cheers,
jamal

---

From: Zsolt Haraszti <[email-masked]>
Date: Mon, 11 Oct 2004 11:12:47 -0400

> common case, we should change it. It is common case for me.

The primary purpose of the currently proposed 
[<class-id>:<instance-id-within-that-class>] tuple is to provide an
FE-unique identifier for each LFB instance of the FE.

Strictly speaking, we do not need a structured address (tuple) just
for that.  A flat numbering schema would suffice.  Assuming flat, a
32-bit id would be clearly sufficient (as it is unlikely we will need
more than 4 billion LFB instances per FE).

(I know that you may compare this to IPv4 and may say "remember?", but
this is a different story; the number of LFB instances in an FE should
not grow proportionally with the speed or # of users of the Internet.)

Structuring the address into a 
[<class-id>:<instance-id-within-that-class>] serves only a secondary
purpose: diagnostics.  I think it is a good purpose.  I do not really
like to bloat the id to 64-bit just for that purpose, but I can live
with that, AS LONG AS THE ID APPEARS AS ONE 64-BIT BLOCK IN THE
PROTOCOL.  I think it is a very bad idea to split the 64-bit id into 2
separate TLVs.  Many entities involved in the ForCES protocol handling
will not care about the class and would like to treat the LFB instance
ID as a flat logical address.  For these, it is a benefit if the id is
in one continuous block in the PL payload.

> <SNIP>

Not for attributes.  In the terminology used in the model, attribute
refers to the top-level attributes of the class (thinks about these
as the local variables of a C++ class).  These are defined in the
class specification, hence are static.

Attributes may include tables with variable content.  Yes, entries in
such tables are typically dynamic.  But we should not call these
table entries attributes, to avoid confusion.  

/zsolt

---

From: Jamal Hadi Salim <[email-masked]>
Date: 11 Oct 2004 13:05:03 -0400

> in one continuous block in the PL payload.

Ok, folks - how about we move forward assuming the two are in the same
TLV. There are bigger issues to be tackled and i think time spent on
this has exceeded its value threshold(I am using the term "I" since i am
the only one it seems arguing for the separation). 
I will update the doc.
So 32 bit (16:16) or 64 bit (32:32)?
 
> table entries attributes, to avoid confusion.  

I cant think of anything other than tables that will have variable
elements - so you may be right;  need to think

cheers,
jamal

---

From: [email-masked]
Date: Tue, 12 Oct 2004 00:35:45 -0400

i have been following along without saying much, and believe this is 
the the right alternative for the reasons you give.  I also agree that 
the version byte should be in the class id.

a.

On 10 okt 2004, at 01.13, Joel M. Halpern wrote:

> Thus, I am concluding that 32:32 may be what we need,