Hi Jesse, (below)
2014-05-09, Jesse Gross: > On Fri, Apr 25, 2014 at 4:56 AM, <thomas.mo...@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. Let me reformulate to see if I understand correctly. In the netlink protocol, you are suggesting that the type of the content of the OVS_PACKET_ATTR_PACKET attribute should be inferred based on the presence and order of OVS_KEY_ATTR_* TLVs; for instance, if OVS_KEY_ATTR_IPV4 is present and coming first, the frame in OVS_PACKET_ATTR_PACKET would be inferred to be IPv4. And in your example of an Eth-over-MPLS-over-GRE packet, we would infer that the packet is actually MPLS based on the presence of OVS_KEY_ATTR_MPLS before OVS_KEY_ATTR_ETHERNET. Assuming my understanding is correct, I wonder about the following: - in the case of MPLS, how are you going to distinguish between the case where the MPLS/GRE packet was of ethertype 0x8847 or 0x8848 ? (AFAICT this information will not be present in the key, although we may need it for proper interpretation of the label) - how are we going to identify the type of payloads that are unknown to OVS and leave no trace in the key ? (As an illustration: what if you want to setup an ISIS adjacency with a router over a GRE tunnel: OVS won't parse anything beyond the GRE header, and thus nothing is the key will provide information to identify that the payload type is LLC.) Given the above (again, assuming I understood your proposal correctly...), I really wonder if it is the right choice to not carry the type of the payload explicitly over netlink. -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
