Subject: Re: [forces] comments #6

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 12 Aug 2011 22:55:35 +0800

Hi,Jamal
   Thanks! We'll modify the draft according your comments. 
Some technical issues, please see the inline. 

Yours,
Chuanhuang
======= 2011-08-12 17:19:27 Jamal Hadi Salim, wrote: =======

>iv) "In order for downstream LFBs to use, a bunch of metadata is produced
> to associate with every output packet. The medatdata, which may be
>used by downstream LFBs for packet processing, contains the PHYPortID
>and it also contains information on Ethernet type, source MAC address,
>and destination MAC address of its original Ethernet packet. Moreover,
>it contains information of logical port ID assigned by this LFB. Lastly,
>it may conditionally contain information like VlanID and VlanPriority
>with the condition that the packet is a VLAN packet."
>to:
>"Metadata to be carried along with the packet data is produced at this
>LFB for consumption by downstream LFBs. The metadata passed downstream
>includes PHYPortID, as well as information on Ethernet type, source
>MAC address, destination MAC address and the logical port ID. If the
>original packet had a VLANID then that is also carried downstream as
>metadata (otherwise a VLANID of 0 is assumed)."
When the original packet had a VLAN tag, the VlanID would be zero or non-zero. If VlanID 
was zero, the VlanPriority would be non-zero. 
When the packet hadn't VLAN tag, the output metadatas VlanID and VlanPriority should all be zero.

>13) 5.1.3.2
>i) typo "strcut"
>ii) this section doesnt talk about what the key or index is used to
>lookup the table EtherDispatchTable or VLANInputTable. I think it helps
>to understand those details
>---
There are some indications in the text. I also think hey are obscure and need some modification:
 EtherDispatchTable: "An EtherDispatchTable array component is defined in the LFB to
   dispatch every Ethernet packet to the output group according to the
   logical port ID assigned by the VLANInputTable to the packet and the
   Ethernet type in the Ethernet packet header."
VLANInputTable: "Every input packet is assigned with a new LogicalPortID according to the packet
   incoming port ID and the VLAN ID. "

I have one question about the key. Do we need define the key in the LFB XML file?
The following is my understanding:
If the table contents are generated by CE, key need not be defined. 
If they are generated by FE , they need be defined in some cases.

In RFC5812:
   In addition to their subscripts, arrays MAY be declared to have
   content keys.  Such a declaration has several effects:

   o  Any declared key can be used in the ForCES protocol to select a
      component for operations (for details, see the ForCES protocol
      [RFC5810]).

   o  In any instance of the array, each declared key MUST be unique
      within that instance.  That is, no two components of an array may
      have the same values on all the fields that make up a key.

So i think the key definition in XML is just for CE to implement search function.
And when the table is dispathed by CE, CE needn't perform the search operation 
on FE.

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 12 Aug 2011 12:54:52 -0400

Chuanhuang,

> When the packet hadn't VLAN tag, the output metadatas VlanID and VlanPriority should all be zero.

I think thats what i am saying as well in the text above.

>   incoming port ID and the VLAN ID. "

We need to be clear. No need to be too chatty - just get to the point. The text
has to be somehow formal. "For table blah, the table is searched using
metaIndexfoo".
The more obscure this information is and requiring the user to lookup somewhere
else to find information, the longer the process of publication will take.
It has to be clear to the reader.

> And when the table is dispathed by CE, CE needn't perform the search operation

I dont see anything that requires a content key - all seem to require
subscripts.
The only thing that requires such a thing is the LPM; i believe we need
to define a content key. Search RFC5812 for keyID.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 16 Aug 2011 11:17:12 +0800

I think I'v fixed all editorial nits. 

Chuanhuang, pls provide text changes propose to me  for the left technical issues.

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
To: "Chuanhuang Li" <[email-masked]>
Cc: "forces" <[email-masked]>; "Wang,Weiming" <[email-masked]>; "Haleplidis Evangelos" <[email-masked]>; "Joel M. Halpern" <[email-masked]>; "Kentaro Ogawa" <[email-masked]>; "Wang Weiming" <[email-masked]>
Sent: Saturday, August 13, 2011 12:54 AM
Subject: Re: comments #6

Chuanhuang,

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Wed, 17 Aug 2011 11:02:17 +0800

Hi, all
    I list all index/key used in looking up the tables defined in LFBs. Text can be modified selectively.

EtherClassifier:
 EtherDispatchTable, Key: LogicalPortID, this key is generated from VlanInputTable.
 VlanInputTable, Key:IncomingPortID.
 EtherClassifyStats, CE use index to query.

IPv4UcastLPM:
  IPv4PrefixTable, Key: IPv4Address.

IPv6UcastLPM:
  IPv6PrefixTable, Key: IPv6Address.

IPv4NextHop:
  IPv4NextHopTable, using index to look up, the index value is the value of expected metadata HopSelector. 

IPv6NextHop:
  IPv6NextHopTable, using index to  look up, the index value is the value of expected metadata HopSelector.  

EtherEncapsulator:
  EncapTable, using index to  look up, the index value is the value of expected metadata MediaEncapInfoIndex.

GenericScheduler:
  CurrentQueueDepth, Key: QueueID.

BasicMetadataDispatch :
  MetadataDispatchTable: MetadataID and MetadataValue. 	

Yours,
Chuanhuang

======= 2011-08-16 11:16:35 Wang,Weiming, wrote: =======

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 17 Aug 2011 05:07:36 -0400

Hi Chuanhuang,

Please also dont forget to comb the text and make sure that in the
data handling section we describe what happens when the table
lookup succeeds and when it fails. I still have some confusion
with your text, more below:

>  VlanInputTable, Key:IncomingPortID.

I think those two should be "index" not "key" as we use the term "key" to mean
content key in the document.

>  EtherClassifyStats, CE use index to query.

Which index?

>  IPv6PrefixTable, Key: IPv6Address.

Above two looks ok.

>  IPv4NextHopTable, using index to look up, the index value is the value of expected metadata HopSelector.

What about:
"incoming metadata HopSelector is used as the lookup index for this table".

>  IPv6NextHopTable, using index to  look up, the index value is the value of expected metadata HopSelector.

Same comment as above.

>  EncapTable, using index to  look up, the index value is the value of expected metadata MediaEncapInfoIndex.

Same comment as above.

>  CurrentQueueDepth, Key: QueueID.

Again, not key but index - Are you implying two indices?
Be explicit - which is the index used to lookup?

>  MetadataDispatchTable: MetadataID and MetadataValue.

Do you mean to have two indices? i.e is it MetadataID or
MetadataValue that is used as lookup index?

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Thu, 18 Aug 2011 10:15:22 +0800

Hi,Jamal
    The contents I listed is for Weiming to modify the text conveniently.

======= 2011-08-17 17:07:26 Jamal Hadi Salim, wrote: =======
>content key in the document.
ok, if we consider the "key" is just "content key", these are all index.
But, LogicalPortID is one of the components of VlanInputTable content. It is not equal to the table index.
IncomingPortID is the same as LogicalPortID.

>>  EtherClassifyStats, CE use index to query.
table index, not the content of the table. Generally, CE will get the whole table contents.
Of course, CE can get some contents of the table according the index he wanted.

>Be explicit - which is the index used to lookup?
The same as LogicalPortID in VlanInputTable.  CE also can get the whole table 
contents or using index to get some.

>MetadataValue that is used as lookup index?
No. To get a right LFB output port, we need use MetadataID and MetadataValue at the 
same time to lookup this table.   

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 18 Aug 2011 08:03:35 -0400

> IncomingPortID is the same as LogicalPortID.

Chuanhuang,  this document is meant to be semi-formal. It is not
as precise as mathematical clarity - but we need to be clear.
If someone is reading this document, they should be able to tell
_exactly_ what it is that is used as the index.
The format should be as simple as we had earlier:
IPv4PrefixTable, Key: IPv4Address.
Can you explain the above in those terms?

> Of course, CE can get some contents of the table according the index he wanted.

What is the name of this index?

> contents or using index to get some.

please be precise as i described above

> same time to lookup this table.

How is this achieved? I can not tell from reading the text for data handling
in the document. Maybe i am being a little slow.

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 22 Aug 2011 14:10:40 +0800

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. 
For example, when CE query an array component of one LFB, FE may send a query response 
message with  FULLDATA-TLV including a series of entries: index, valueof(component1), valueof(component2). 
CE also can query some entries through setting the index number in ForCES message. 
Of course, what you have said also can be regarded as an index (like "LogicalPortID" in EtherDispatchTable). It 
is one of the members of the table. That's why I said these two kinds of "index" are not equal.  
(Exactly, i still think the latter is a "key", not index. Or you can think it is a "key index".)

Maybe i haven't understood these concepts clearly! I don't know whether any other people also have these comprehension.

>Can you explain the above in those terms?
IPv4Address is the member of  IPv4PrefixTable structure. we need use this key to Lookup the table.
The difference between LogicalPortID and IPv4Address is just their data type. LogicalPortID is an 
integer.

>What is the name of this index?
table or entry index have no name, it is just an index number.

>in the document. Maybe i am being a little slow.
All defined metadata have their own datatype, and if we hope MetadataDispatchTable 
can be applicable to all metadata, we are difficult to define it. So, there is the following text 
in the darft: 
"Currently the BasicMetadataDispatch only allows an interger value for the metadata to 
be used for dispatch."

But the text said The BasicMetadataDispatch LFB is currently defined with only one metadata 
adopted for dispatch. I think this need to be modefied to:
BasicMetadataDispatch LFB can be used with more than one metadata, so long as the metadata is 
an interger.
 
We use MetadataID and MetadataValue to lookup the table simultaneously. The draft text need 
to include this point.

Yours,
Chuanhuang

---

From: Joel <[email-masked]>
Date: Mon, 22 Aug 2011 02:16:26 -0400

Chuanhuang, your description sounds accurate.  The "index" is the 
position in the array, usable with the index reference form.  It is not 
a field in the array contents.  In contrast,
array entry information which can be used for lookups is key information.

Yours,
Joel

On 8/22/2011 2:10 AM, Chuanhuang Li wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 22 Aug 2011 05:40:10 -0400

Hi Chuanhuang,

On Mon, Aug 22, 2011 at 2:10 AM, Chuanhuang Li
<[email-masked]> wrote:
> "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