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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 8 Oct 2004 21:49:36 -0700

Steve,

What you have proposed below is exactly what we already have in the
protocol today i.e. LFBCLASSID:LFBInstance<OPER>+, with
LFBCLASSID:LFBInstance be 16:16. It almost seems like we are going in
circles at this point. I had the impression that the model team was
proposing this different scheme for some reasons...may be not?

In any case, what youre suggesting is definitely the more common case
i.e. 1 LFB instance is all I have seen in most implementations. Also, 16
bits is quite sufficient. The important thing at this point is we should
atleast get a single recommendation from the model team, the protocol
team will eventually decide the no of bits, etc but it would help if we
don't keep going back and forth on these issues.

regards
Hormuzd

-----Original Message-----
From: Steven Blake [mailto:[email-masked]] 
Sent: Friday, October 08, 2004 7:45 AM
To: [email-masked]
Cc: Joel M. Halpern; [email-masked]; [email-masked];
[email-masked]; Khosravi, Hormuzd M; [email-masked];
Yang, Lily L; [email-masked]; Alan DeKok; Deleganes, Ellen M;
[email-masked]; Robert Haas
Subject: Re: updated notes on BNF and layout

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

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 10 Oct 2004 16:19:10 +0800

Hi,

Actually I'm not very sure if it will be extremely important and affect the
protocol greatly in terms of things like where to put the LFBtype ID and
Instance ID. Although number of bits for the ids are important,  they are still
quntitative issue instead of qunlitative one, and I think we can  have it open
for a long period while currently just choose one scheme (16 or 32 bits) ,
before we can gain experience more and then decide it.

I  personally think if we should instead pay more attention to issues like below
so that we can roll forth more quickly:

1. If such a scheme of LFBClassID:LFBInstanceID is enough to include all cases
for LFB addressing.
One thing I'v thought of is we may need to do some operations between LFBs.  For
instance, we may need to establish a datapath between LFBs, and also we may very
often need to setup Metadata along two connected LFBs. These all imply it may be
much more efficient to address more than one LFB or LFB instances at a time
using current scheme (LFBaddressing followed by Op), or to use other scheme like
(OpTLV followed by LFBTLVs). For datapath setup, I even cannot think of other
way if we address one LFB at a time using current scheme.

2. The Index issue.
I'v been trying to understand Joel's idea on the advantage ( easy management )
of Index  used at the protocol layer, but based on my testbed implementation, I
just find it seems not an easy thing as we may think to do this. I have to do
extra things like matching and managing the Index in CE to protocol application
layer and matching and managing the Index in FE protocol terminator to base in
LFB. Without using this Index, I don't need to pay these extra attentions, just
let the protocol application layer directly manage the LFB base.

Although I think the above issues worth discussing, I agree with Hormuzd that we
protocol team may need to begin the paper work now for the new version protocol
draft right now, therefore I can currently live with current scheme, which
actually quite the same as we'v had in the current draft, while leaving the
above issues for more discussion.

Thank you.
Weiming

BTW, I don't oppose to use concall to solve issues moer quickly, but the list
may be more fit for my group to do.

----- Original Message -----
From: "Khosravi, Hormuzd M" <[email-masked]>
Subject: [Forces-protocol] RE: updated notes on BNF and layout

Steve,

regards
Hormuzd

-----Original Message-----
From: Steven Blake [mailto:[email-masked]]
Sent: Friday, October 08, 2004 7:45 AM
To: [email-masked]
Cc: Joel M. Halpern; [email-masked]; [email-masked];

Ok

Ok

You need this for GET.

[snip]

Regards,

// Steve

---

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

My current view (and I could be mistaken) is that this will generally 
actually be easier by addressing specific LFBs.
Setting up a data path segment is done by updating tables in the FE object.
For metadata to be passed between LFBs there are actually potentially two 
different operations.  One (which may already be done for receiving data 
from some third LFB) to set up the receive processing, typically creating a 
table entry, and one on the sending LFB to fill in what metadata to 
send.  These are different updates and we ought not combine them into a 
single operation.

Note that it is valid using this identification scheme and the generally 
proposed protocol structure,  to include updates to multiple LFBs in the 
same request.  I would expect that to be common. would however expect those 
to be different updates to the different LFBs, not a single update to 
multiple LFBs in the FE.  There are some cases where multiple LFBs may need 
changing (for example if the CE decides to change a configuration timer 
that is used in multiple places in the FE.)  I do not see this as the 
common case.

With regard to the table structuruing, I suspect I am misreading your note, 
so I am having trouble responding in a helpful clarifying fashion.  The 
only thing I can think to articulate at this point (which is probably not 
the aspect you don't see in your code) is that I assume that the CE is 
maintaining a set of tables that mirror the FE state.  It is the presence 
of those tables that make the indexing practical.

Yours,
Joel

---

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

>From Weimings posting, something else that is probably related (since he
mentions inter LFB metadatum):
LFB dependencies. 
As an example (not sure if its a good example) consider a LPM/NH LFB may
require that a port LFB being in existence and probably both admin&oper
up before it can consider whatever state it is being populated with is
valid. I dont think the LFB topology layout is sufficient.
Is this something expected in the xml template for the LFB? 

I am just recovering from a bad flu - brain a little slow so i may be
asking the obvious.

cheers,
jamal

---

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

Actually, I would hope that two other aspects will prevent this from being 
an issue.
Firstly, I would expect that usually, the processing LFB can be populated / 
established / activated with the processing data, with its operation 
controlled by either the data path sending packets or by packets arriving 
with the relevant meta-data.   Then the access port can be enabled by the CE.
Secondly, if we really need to have disabled table entries, I would expect 
the table entry to have an "enable" flag.  Then when it is ready the CE can 
send a set to the two related LFBs, enabling the related entries.  (This is 
related to why, at least within an FE, one may need atomicity.)

Yours,
Joel

---

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

> related to why, at least within an FE, one may need atomicity.)

So things like atomicity and possibly 2pc may answer this; 
But what about runtime events - example a link (port LFB entity) going
down and affecting 10 other LFBs?
Clearly one could offload these dependency resolutions to the FE, but
you seem to be hinting at CE (the all-knower) to be in charge.

BTW, "enable" flag is something that needs to be defined at class
definition time in all LFBs then?

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 12 Oct 2004 10:42:00 +0800

Joel,

thank you for reply.

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>

> Setting up a data path segment is done by updating tables in the FE object.
Maybe it's possible to do this in the FE object, I'm not very sure currently.
Another reason I think to address multipul LFB(or instances) I though is just
from your example. I.e., to use thousands of LFBs for OC-48 demux to DSx. In
this case, to address one LFB at one time may make things even impossible.
Remember that I mentioned in my LfbTLV scheme, we can just use a range of LFB
instance addressing to solve this very easily. This actually means multipul LFB
addressing is more flexible for users. I can also think of other duplicate
configuration case where multipule LFB addressing is much more efficient.

> send.  These are different updates and we ought not combine them into a
I just think of Metadata setup may be also some kind of duplicate setup process,
therefore multipul LFB addressing may greatly ease the operation.

> that is used in multiple places in the FE.)  I do not see this as the
As mentioned above, my view different from you is this may be a very common
case.

> of those tables that make the indexing practical.
I agree CE will maintain these FE mirrored tables. The difference between us is
I think it then dos not mean the protocol layer should be responsible to keep
the index so as to maintain the tables.  Without the protocol layer index and
with the index defined by FE data model, this can be maintianed well. Actually I
don't agree with your idea that the index defined by protocol and by FE model
will lead to difference of Index based searching and content based searching,
while content based searching is less efficient. I just think  Index defined by
FE data model will also lead to index searching and will not lessen efficiency.

I see some disadvanges of index defined by protocol is:

1. Sometimes, especially for some very small tables, we do needn't  index, but
if we use protocol index, we then have to use it.
2. Make the index definition quite limited and inflexible.
For instance, I'm not sure if the protocol index is global in all FEs or not. If
not, then form the case where there is a main table in CE while scattered tables
in FEs, the maintainance of Index may become very complicated. On contrary, if
the index is defined by FE data model or even by users, we may have more
flexible scheme to deal with this, e.g., using segmented Index.
3. Complicate the definition of protocols greatly.

> >way if we address one LFB at a time using current scheme.

BTW, I'm quite busy these days till next monday, so please excuse me if I can
not reply to you very on time.

Thank you.

Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Oct 2004 23:09:47 -0400

I suspect I am missing some useful ideas you are trying to communicate, 
because I am not following the items you list.

With regard to item 1, indices are needed for small tables and for big 
tables.  The appropriateness of direct indexing versus content indexing is 
quite independent of table size.

With regard to item 2, my point is hat in order for the CE to be able to go 
through and extract the contents of the table, there must be direct 
(non-content) indices.  This extraction is necessary since the FE may 
initially have created table entries for any tables, and the CE needs to 
know about these.  (It becomes even more important in failover scenarios, 
but since we have not spelled those out, I want to be cautious about using 
those to justify anything.)
In some sense, these tables are limited.  In order to avoid needing to 
create the equivalent of SNMP get next, we need something whose behavior is 
more predictable than arbitrary indices.

With regard to item 3, I believe that if we just use 32 bit indices, the 
protocol can be greatly simplified.  We simply include the index in the 
appropriate position in the element selector.
So if item 1 of an LFB is a table, then 1.7 is the 7th entry in the 
table.  If the table includes a strucutre, which is an item 2, then 1.7.2 
is the element selected by tag 2 from th structure at the seventh position 
of the array selected by tag 1.  And so on.
This allows a single, simple mechanism to reference any element within an 
LFB, no atter how many arrays or structures it is nested within.
Assuming we can assign suitable identifiers for the related properties of 
an array (which I believe is also easy) we can get away with a small number 
of operations for the entire LFB element operation suite (GET, SET, CREATE 
and DELETE for array entries).

Yours,
Joel M. Halpern