[ovs-dev] [PATCH v2 3/3] datapath: add layer 3 flow/port support

[Jesse Gross]

On Fri, Apr 25, 2014 at 4:56 AM,  <thomas.morin at orange.com> wrote:
> Hi Jesse,
>
> (inlined below)
>
> Jesse Gross :
>>>>>>>>>>>
>>>>>>>>>>> In general, I think it would be a good idea for the flow key to
>>>>>>>>>>> have
>>>>>>>>>>> a
>>>>>>>>>>> field
>>>>>>>>>>> specifying the layer 3 protocol, when an ethernet header is not
>>>>>>>>>>> present.
>>>>>>>>>>
>>>>>>>>>> That makes sense to me.
>>>>>>>>>
>>>>>>>>> You mean that we keep eth.type as the L3 protocol field, or define a
>>>>>>>>> new
>>>>>>>>> one, separate from the eth union?
>>>>>>>> I think it's fine to keep using eth.type as the protocol field. I
>>>>>>>> think we can probably some holes to move the is_layer3 flag into the
>>>>>>>> non-tunnel portion of the flow though.
>>>>>>>
>>>>>>> Should we revisit this discussion?
>>>>>> I was just referring to the Netlink encoding here. Can we populate the
>>>>>> flow key in the kernel when we translate the flow?
>>>>>
>>>>> Not sure I understand the question.
>>>>>
>>>>> Going through the code, I see that omitting OVS_KEY_ATTR_ETHERTYPE
>>>>> currently
>>>>> means an 802.2 packet, if the mask is set to 0xffff.  Are you suggesting
>>>>> to
>>>>> omit OVS_KEY_ATTR_ETHERTYPE for layer 3 packets both in the flow key and
>>>>> the
>>>>> mask?
>>>> All I was trying to say is that is that the Netlink and struct
>>>> sw_flow_key representations don't necessarily have to be exactly the
>>>> same as long as we can translate back and forth. I'm not sure that the
>>>> previous discussion applies - this is more about Netlink and that
>>>> seemed to apply to struct sw_flow_key.
>>>
>>> Ok, understand now.  But validation would become even more complicated if we
>>> didn't send the OVS_KEY_ATTR_ETHERTYPE over Netlink for layer 3 packets.
>> I think we would basically have to scan for L3 attributes and use that
>> to fill in the EtherType, right? Is there anything else?
>>
>> It would be nice to fully break the link to Ethernet and it seems like
>> a half measure if we keep EtherType in. There have been various
>> requests for non-Ethernet protocols in the past so it seems like it
>> could get messy if we assume some elements of Ethernet.
>
> Assuming that the target is to carry any non-Ethernet payloads in the
> future, it seems like it is important to have a way of tracking what is
> the type of the payload.
> A natural way to do this is to rely on the ethertype value. Note that
> the use of an ethertype value is not, at least not anymore, an element
> of Ethernet; it is used by many protocols such as GRE. So keeping track
> of the ethertype of the payload looks to me as a very good idea.  In the
> general case, this is something needed (even though in the particular
> case of IP, you can find what the ethertype would be based on the (IP)
> payload header).
>
> To break the link with ethernet, which I agree is a good thing, this
> value could be carried in a field other than dl_type.
>
> A practical example is the transport of MPLS over GRE. The vport-gre
> code would extract the ethertype from the GRE header, and the MPLS
> payload will then be processed further. If we did not preserve the
> knowledge of the fact that the payload is MPLS, it becomes impossible to
> parse the payload properly.
>
> Another example is for any non-Ethernet payload received of GRE that you
> need to forward on an Ethernet port, to push a valid Ethernet header,
> you need to have preserved the knowledge of the ethertype.

I think I hopefully have mostly answered this in the previous message
that I just sent. I agree that you need to have a way to determine the
type of a packet but I believe that this already exists. For example,
in the case of an MPLS over GRE packet being received, the first TLV
in the netlink serialization would be MPLS, followed by an Ethernet
TLV. As a result, you are already getting typed data even without the
presence of an EtherType.