> From: [email protected] > [mailto:[email protected]] On Behalf Of Ben Pfaff > Sent: Wednesday, 29 November, 2017 02:11 [...] > > Hence, it is impossible to use the ToS and TTL 'inherit' feature in > > case of MPLS tunneled traffic, because currently the values to be > > inherited are coming from the cleared (invalidated) variables of > > struct 'flow'. > > OK, I spent some time and I think I understand what going on. > > 1. Start with some IPv4 or IPv6 packet. It has a TTL and a TOS. > 2. An MPLS label gets pushed on. It has a TTL but not a TOS, since MPLS > doesn't have a TOS field. > 3. We send the MPLS packet to an L3 tunnel. It has a TTL and a TOS that > need to get initialized. > > The problem is that the inner TOS from step 1 wants to get propagated to > the TOS in step 3, but it was lost in the middle. > > Now that I understand the problem better, let me comment on the proposed > solution. > > First, it is not much fun to have to copy nw_tos into latest_nw_tos > whenever the former might change. I don't think it's actually necessary > to carefully analyze all the points when it might change. It seems like > it would be OK to just copy it whenever an MPLS label gets pushed. > > Second, this solution feels a little "magical". An approach that would > feel more "natural" and more in line with usual OVS approaches would be > to introduce a new tun_tos field, which could be copied from nw_tos or > otherwise set, and then allow tunnels to configure "tos" as "flow". > Then a controller that wants to do this kind of propagation from step 1 > to step 3 could easily do so. The same approach could work for ttl > although it is not as necessary of course. > > What do you think?
Thanks for the feedback, Ben. Miklos has left Ericsson, so let me answer. We were primarily aiming for a solution within OVS to allow TOS inheritance for MPLSoGRE tunnel ports in the same way as for plain GRE and VXLAN tunnels without additional controller impact. I agree that our proposal is a little "magical". But it certainly simplifies life for the SDN controller if TOS and TTL inheritance of a tunnel port is refined to mean inheritance from an inner IPv4 or IPv6 packet, no matter if there are additional "shim" headers in between. MPLS is only one example. NSH is another valid use case, I think. This little "magic" could be clarified in the tunnel port documentation. The more explicit method you suggest certainly makes sense and would be in line with general OVS principles. But I would like to point out two drawbacks: 1. Configuring the ttl and tos attributes of a tunnel port as "flow" would lead to conflicts in cases where PTAP tunnel ports carry both IP and non-IP packets and for IP packets ttl and tos should simply be inherited, whereas for non-IP packets they should be populated from the tun_ttl/tun_tos fields. 2. In the NSH use case the pipeline complex that pushes the NSH header (classifier) and the complex that decides to transmit the NSH packet out on a VXLAN-GPE (SFF) tunnel are conceptionally different entities and your proposal would create a new coupling between them because the classifier would have to save the nw_tos field in tun_tos, just in case the SFF complex later decides to send the packet to a VXLAN-GPE port, rather than over Ethernet to a locally connected SF VM. We would therefore prefer to pursue our implicit TOS/TTL inheritance proposal (possibly a bit streamlined according to your suggestion). Please let us know if you agree. Regards, Jan _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
