Subject: Re: [forces] comments #6

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 16 Sep 2011 12:24:43 +0800

I think this issue on the array index or the array key is not closed, so I provide more comments also.

Some of my viewpoints: 

Firstly, we may have to distinguish two types of 'array lookups'. 
. one is for CE to look up the array so that CE can query the information inside the array. In this case, we defined things  like index and content keys for this purpose.
. the other is for the document to to define how the array in the LFB acts when processing data. In this case, we can define the arry uses index and any array fields as the lookup keys, while the lookup source data may be from metadata or other LFB components or component fields. In this case, we done have to define these joined lookup fields as 'content keys' in our XML files. Rather, we just need descriptions to clearly state it in the LFB description section.

As a result, I think we now firstly need to make clear what have to be define as 'content keys' for CE to use. These content keys MUST be defined in XML files. 
By now, I only see the necessary 'content key' for CE to look up is in the LPM table array. For other tables like the Vlaninputtable etc, we may dont have to define 'content key's for CE to use, because it is not a large table and if CE need to query, an index may be enough.

Based on this, Chuanhuang, could you provide a clear list on what we should define as content keys for all LFBs defined?

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: [forces] comments #6

Hi Chuanhuang,

On Mon, Aug 22, 2011 at 2:10 AM, Chuanhuang Li
<[email-masked]> wrote:
> Hi,Jamal
> Sorry for the late response.
> I think we need reach an agreement on the meaning of "index".
> "table index" that i have said is just the internal order(entry index) for building the table in >an LFB. This "index" is not a member of the table structure.

Indeed this is the index i was referring to, and as Joel said your understanding
is correct. It is not part of the row content rather it is a position
of where the
content is.

1) The CE knows such an index because it created it or it queried the FE
about it; and can coordinate upstream LFBs to have it as an entry in their
table content, example: LogicalPortID in  upstream EtherDispatchTable
of EtherClassifier LFB.

2) LogicalPortID arrives as metadata at a downstream LFB where is
to be used to index/lookup some (downstream) table.

I am concerned about #2. The text is highly lacking to describe what
metadata is used as an index for the table.
We need to say it clearly in the text for each table.
something like: "Metadata LogicalPortID is used as table index for table blah".
The text for example does a good job to describe that
IPv4Address is used as the content key for the IPv4PrefixTable.

i.e the extra description  would be of the form:
"Table Foo: Table index, goo metadata"

Does this make sense?

On the difference between keys and indices in our terminology:
A key is derived from content and the CE has no control over its value
(IPV4 address
on arriving packet). Table index is configured by the CE.
Index lookup is typical O(1). Content Key lookup is  much more expensive.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Sep 2011 09:49:53 -0400

Content keys are not for the CE to use when looking in its own copy of 
the tables.  In those copies, it can do anything it wants any way it wants.
Similarly, content keys are not for the FE to use for processing packet. 
  The implementation of packet processing is a local matter.
Even the case where a packet uses meta-data to select an entry, and uses 
a piece of content in the table for the matching, is not technically a 
content key, as it is not protocol processing.
It is however a warning of a difficult design.  It is also more likely 
to be a content key, because it makes sense for the CE to provide the 
information using the same keying the FE will use.  And it is the CE-FE 
interaction that requires the declaration of content keying.

Put differently:  declaring content keys is all about a use case where 
the CE can not reasonably specify the array index in its request.

Content keys are specifically for the case where the CE needs to specify 
an entry in the table to the FE, but needs to be able to specify that 
via the content, rather than via the index.
Contents keys are included because the WG asked very strongly for them. 
  It is not clear to me personally that they are necessary at all.

Yours,
Joel

On 9/16/2011 12:24 AM, Wang,Weiming wrote:
> From: "Jamal Hadi Salim"<[email-masked]>
>> "table index" that i have said is just the internal order(entry index) for building the table in>an LFB. This "index" is not a member of the table structure.
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 16 Sep 2011 23:17:38 +0800

Joel, 

I think I'm on the same page with your ideas. I don't mean that CE will use the content key to look up, for instance, a copy of  routing table in CE. Rather, CE may have to use a content key to query a routing table in FE for some specific information. 

When years ago we asked for a content key based arry lookup, we just thought only index based array lookup may not be sufficient enough. The key useage may be like, we may define a LPM table with a IP address as the content key. Then, we may be able to operate on (query/delete, etc)  routing items with a specific IP address. 

Content keys may be hard for some implementations, so I jsut wound if we need to define an extra capability for content keys the LFB supported.  Of course, with ForCES protocol, if a content key is not supported by an LFB while CE still use it, an error code indicating such errors may be retured to CE. 

thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Sep 2011 11:33:43 -0400

Thanks.  It sounds like we are on the same page.
Joel

On 9/16/2011 11:17 AM, Wang,Weiming wrote:
> From: "Joel M. Halpern"<[email-masked]>

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 17 Sep 2011 16:53:26 +0800

Chuanhuang and Jamal, 

According to the discussion, I think only the following content keys should be defined in XML.  Pls double check it: 

IPv4UcastLPM:
  IPv4PrefixTable, content Key: IPv4Address.

IPv6UcastLPM:
  IPv6PrefixTable, content Key: IPv6Address.

GenericScheduler:
  CurrentQueueDepth, content Key: QueueID.( not sure if it is a must? Because the queue number is not so large, so if  there is no such key, CE may still be able to get queue depth info by query the whole depth table ) 

By defining above content keys, we may also have to consider how the LFB will respond to CE if it can not support the content key.

thanks,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 17 Sep 2011 17:06:13 +0800

In order to avoid confusions, I'm going to change the name of 'content key' that we have used to describe lookups of arrays that are the LFB's own function rather than the CE's requirement function. I thin the 'content key' here may be changed just to 'key' or 'lookup key'. An instance is as below, which is from 5.5.1.1 for describing BasicMetadataDispatch LFB: 

old text: 
... The LFB uses all existing metadata associated with every input packet with their metadata IDs and metadata values as the content keys to look up the table to find out the relevant OutputIndex ...

to change to: 
... The LFB uses all existing metadata associated with every input packet with their metadata IDs and metadata values as the lookup keys to look up the table to find out the relevant OutputIndex ...

pls comment it.

thks,
Weiming

---

From: "Chuanhuang Li" <[email-masked]>
Date: Sat, 17 Sep 2011 17:23:14 +0800

Hi, All

    Exactly, I don't think we need define content key in the table components of IPv4UcastLPM and IPv6UcastLPM. The reason is these tables are all generated on CE itself, and CE needn't lookup them from FE. 
    CurrentQueueDepth in GenericScheduler LFB is generated on FE, so we need define the content key to 
facilitate CE to lookup the content. 
    If user implements the LFB with content key, he should provide the searching function to CE. In case 
user haven't implement the function, i think FE may return "E_UNSPECIFIED_ERROR" error code.

Chuanhuang	

======= 2011-09-17 16:51:32 Wang,Weiming, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 19 Sep 2011 14:04:04 +0800

Hi all,

I'v finally decided using a 'search key' to substitute some 'content key's and some 'index's in the description text where they all mean some search keys that are used by FE ( rather than CE) to look up some tables. 

Now we are closing  to the close of the issue, only with Chuanhuang to check all LFB definitions to decide if some 'Content Key's should be defined in the components.

thnks,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 19 Sep 2011 06:30:13 -0400

Weiming,

This looks reasonable to me.

cheers,
jamal

On Mon, Sep 19, 2011 at 2:04 AM, Wang,Weiming <[email-masked]> wrote:
> Now we are closing  to the close of the issue, only with Chuanhuang to check all LFB definitions to decide if some 'Content Key's should be defined in the >components.