Subject: Re: [issue65] TLV Clarification

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 3 Feb 2006 23:51:17 +0800

The issue is closed as being rejected.

Thanks,
Weiming

----- Original Message -----
From: "Wang,Weiming" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 25, 2006 2:43 PM
Subject: Re: [issue65] TLV Clarification

> I think 'extensive use of TLVs' has quite accurately described the use of
> TLV as well as ILV. No more text is needed as in the Introduction section.
>
> I suppose this issue can be closed in one week if theres no further
> comments.
>
> Thanks,
> Weiming
>
> David Says:
> In the Introduction section it says "Information exchanged between FEs and
> CEs
> makes extensive use of TLVs."
>
> Doesn't *all* control information use TLVs in ForCES?
>
> Jamal replied:
> We need to be more explicit:
>
> We have two types of TLVs: 16 bit T, 16bit L and then
> We have ILVs which use elementID for T ...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Feb 2006 15:22:22 -0500

Interesting looking.  A few comments...

The use of content keying for the IPv4 table runs right into the 
limitations that are deliberately in place.
I wonder how often a requestor will really want to fetch the 
content-info knowing the address, prefix-length, and source?
I could imagine needing to search based on part of that.  But that 
should be done by the CE on the CEs table.

Was there a problem that forced you to include the base element 
properties, arrayElementProperties, eventProperties, accessRights, 
etc into this file?  We don't want to duplicate stuff from the model 
document itself.

I notice that a lot of elements are missing their synopsis.  This 
sometimes makes it hard for me to determine what the intent of parts 
of this are.  Making it diffficult to provide useful comments. For 
example, there is an eventNode data type defined, with callback 
information.  I doubt that the FE should have callback IDs for the 
CE.  But I can not be sure how you are using that because it has no 
synopsis and is never referenced.

You have a mac-alias-table fo 8 MAC addresses.  I can imagine many 
uses for a MAC alias table.  I have harder time imagining that we 
should restrict it to 8 entries.  But without a synopsis or any use, 
it is hard to say.

You have a classification table, with an opcode.  Without a 
definition of opcode, or of classrule, or a synopsis of what this 
data type is for, I am left unable to comment as to the structuring.

As a guideline, I doubt if we want to require that every LFB keep 
statistics.  Each variable update is going to take processing.  I 
well understand the temptation to want to know what each LFB has 
done.  But if we require that, we will make this a performance disaster.

In the IPv4 LPM table, you have a directed broadcast table.  It is an 
array.  It has numbers in it.  I have no idea what the LFB will do 
with this table.  Presumably, it will take something from the packet, 
use it as an index, and get a result.  What will it use from the 
packet as the index, and what will it do with the result.
(Note that we should also specify that the IPv4 prefix table is used 
to look up the destination IP address from the packet.)
We have to specify the full semantics of the LFB in the english.

The DSCP classifier has output dedicated to different next 
hops.  There is no need for that.  We just need an output, with the 
meta data.  That output can be connected to whatever the CE decides 
it wants connected there.  The LFB definition should not constrain 
where the output goes.  (After all, folks may come up with more 
interesting behaviors and structures than the inventors imagine.)
It is possible the QueueController confused you about this.  The 
queue controller has different inputas and output because it expects 
different things (packets vs meta-data only) on those inputs.  Also, 
the control (meta-data only) ports are really fictions to represent a 
control relationship.  I had to bend the topology structure to get 
the right meaning.  I thought this bending was better than simply 
storing a reference to the other LFB ina variable.  And no one has 
yet complained on the list.  So I might not be wrong.

I suspect that the NextHop Applicator ought to have a meta-data 
output "encapsulation-required" which it picks up from its data 
table.  It should have a single output.  Then, wherever the right 
branch point is, the CE can insert a meta-data brancher to get to the 
encapsulator.  Remember that the encapsulator might not be the very 
next element in the LFB path.

I don't know if I caught all my questions, but that is a start.
Thank you very much for working on this.
Joel

At 06:18 AM 2/16/2006, ligang dong wrote:
>Joel,
>
>During our implementation of ForCES-based router, we summarize the 
>definition of some LFBs, including IPv4LPMClassifier LFB, 
>DSCPClassifier LFB, NextHopApplicator LFB, GenericConnectivity LFB, 
>MetaDataMarker LFB, Scheduler LFB, and QueueManagement LFB. This 
>file also defines data types and metadata that are related to the 
>LFBs. This definition file is enclosed in this email.
>Our work needs much improvement. We believe your comments will help 
>improve it.
>
>regards
>Dong, Ligang