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. Best, -Thomas _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
