Subject: Re: [forces] comments #7

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

Regarding this issue, I'v changed some of the texts as below:

in Section 5.1.3.1
----from ---
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 VLAN ID then that is also carried downstream as metadata (otherwise a VLAN ID of 0 is assumed). 

--- 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 is a VLAN packet and contains a VLAN ID and a VLAN priority value, then the VLAN ID and the VLAN priority value are also carried downstream as metadata. As a result, the VLAN ID and priority metadata are defined with the availability of "conditional".
----------

in Section 5.1.4.1
--- from ---
The LFB always expects from upstream LFBs the MediaEncapInfoIndex metadata which is used as an index to lookup the Encapsulation Table. In the case an input packet contains only a VLAN priority field metadata, a default VLAN tag of 0 is assumed. 
(Chuanghuang, can you explain what is the last sentense meant?)

--- to ----
The LFB always expects from upstream LFBs the MediaEncapInfoIndex metadata which is used as an index to lookup the Encapsulation Table.   An input packet may also optionally receive a VLAN priority metadata, indicating that the packet is originally with a priority value. The priority value will be loaded back to the packet when encapsulating.  The default value for a priority metadata is 0.
----------
(Chuanghuang, can you explain what does the meaning of the defaultValue in the XML <ref dependency="optional" defaultValue="0"> VlanPriority</ref> ? I just can not understand how we can have a default value for an input metadata?)

in Section 5.1.4.1
------ no change but just ask for doube check of the correctness ---------
By default the table entry for VlanID of 0 is used as per IEEE rules. Whatever the   value of VlanID is, if the input metadata VlanPriority is non-zero, the packet will have a VLAN tag. If the VlanPriority and the VlanID are all zero, there is no VLAN tag to this packet.
-----------

thks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>

Your call - please go ahead and add clarifying text.

cheers,
jamal

On Wed, Aug 17, 2011 at 3:57 AM, Chuanhuang Li
<[email-masked]> wrote:
> About this issue, as i have commented in the previous email, i think the
> draft content is no problem. But it need specify where "VlanPriority" metadata
> is produced and consumed both in EtherClassifier and EtherEncap. It also need
> point out emphatically this metadata is "optional". When there is no VLAN tag
> in the orginal packet, EtherClassifier will not produce it, and EtherEncap will not
> expect it.
>
> Yours,
> Chuanhuang
>
> ======= 2011-08-16 22:30:48 Wang,Weiming, wrote: =======
>
>>Chuanhuang,
>>Can you make a summary on this comment so that I can incorparate the results in the text.
>>
>>thks,
>>Weiming
>>
>>----- Original Message -----
>>From: "Jamal Hadi Salim" <[email-masked]>
>>Subject: Re: comments #7
>>
>>
>>Hi Chuanhuang,
>>
>>On Sun, Aug 14, 2011 at 11:23 AM, Chuanhuang Li
>><[email-masked]> wrote:
>>
>>>>That may make sense - but sounds inconsistent.
>>>>Arent you always passing this metadata? If you want to keep that way
>>>>fine with me - i did not see it that way when i read the text.
>>>
>>> Currently, in EtherEncap, the input metadata "VlanPriority" was defined "optional".
>>> If the orginal packet hadn't Vlan tag (That is no vlan priority input), The VlanPriority
>>> defaultValue was 0.
>>> In the draft:
>>> " Optinally an input packet may be accompanied by a Vlan priority metadata. In this case,
>>> default value for the metadata is 0."
>>
>>It is up to you how you want to reach this - my take on it is:
>>functionally assuming presence of both tag and priority is easier to follow.
>>Sometimes one or both could be zero.
>>
>>cheers,
>>jamal
>
>
>

---

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

>(Chuanghuang, can you explain what is the last sentense meant?)
This sentence is added( and modified) by Jamal.
I guess he wants to say the VLAN ID is zero in that case. But the vlan ID is obtained by looking up the EncapTable.
If the priority metadata is zero, and the VLAN ID is also zero, there is no VLAN tag only in this case. 

I think we have specified this issue in the text: 
"If the Input metadata VlanPriority is non-zero, the packet will have a VLAN tag, 
whatever the value of VlanID is(zero or non-zero). If VlanPriority and the VlanID 
are all zero, there is no VLAN tag to this packet." 

We only need add some text to describe where the "VlanPriority" was produced. Accordingly, add some text to describe 
where it was consumed in EtherClassifier LFB.

>The LFB always expects from upstream LFBs the MediaEncapInfoIndex metadata which is used as an index to lookup the Encapsulation Table.   An input packet may also optionally receive a VLAN priority…
There is the specification In RFC5812:
   An input port group may "require" a given metadatum, or may treat it
   as "optional" information.  In the latter case, the LFB class
   definition MUST explicitly define what happens if any optional
   metadata is not provided.  One approach is to specify a default value
   for each optional metadatum, and assume that the default value is
   used for any metadata that is not provided with the packet.

Yours,
Chuanhuang

---

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

>   used for any metadata that is not provided with the packet.
If an input metadata is defined by the LFB as 'optional', it should not be redefined as a  'must input' anymore.  As a result, my take is, the default case will not exist, because the LFB should not in any case expect such metadata, rather, just should receive the metadata if it is there. It will have to be treated as an error that the LFB processing function MUST requrie the metadata while the input packet does not have it.

thks,
Weiming

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 19 Sep 2011 15:03:52 +0800

>If an input metadata is defined by the LFB as 'optional', it should not be redefined as a  'must input' >anymore.  As a result, my take is, the default case will not exist, because the LFB should not in any case >expect such metadata, rather, just should receive the metadata if it is there. It will have to be treated as >an error that the LFB processing function MUST requrie the metadata while the input packet does not have >it.
If the input metadata is not "optional" but "must", on the contrary, i think it shouldn't have default value.
Default value is just used to tell to the LFB that this metadta haven't been produced by the upstream LFBs. 
So LFB can do something to deal with this situation. 

Yours,
Chuanhuang

---

From: "Chuanhuang Li" <[email-masked]>
Date: Mon, 19 Sep 2011 15:25:37 +0800

>If an input metadata is defined by the LFB as 'optional', it should not be redefined as a  'must input' 
>anymore.  As a result, my take is, the default case will not exist, because the LFB should not in any case 
>expect such metadata, rather, just should receive the metadata if it is there. It will have to be treated as 
>an error that the LFB processing function MUST requrie the metadata while the input packet does not have 
>it.

Yours,
Chuanhuang