[ovs-dev] [RFC PATCH 07/14] Add APIs to set NSH keys for match fields

Jesse Gross jesse at kernel.org
Wed Jun 22 17:11:50 UTC 2016


On Tue, Jun 21, 2016 at 7:40 PM, Li, Johnson <johnson.li at intel.com> wrote:
>> On Tue, Jun 21, 2016 at 6:50 PM, Li, Johnson <johnson.li at intel.com> wrote:
>> >> Please make a generalized push/pop Ethernet header rather than a
>> >> specialized one for this case. There are other use cases that involve
>> >> this and they should be consistent (i.e. connecting an L3 tunnel to
>> >> an
>> >> L2 interface, MAC-in-MAC encapsulation, etc.)
>> > [JL] Since we introduced new fields encap_eth_dst/src, we know that
>> > the field differs from Origin eth_dst/src definitons. Then if we
>> > defines push_eth/pop_eth actions, but use the new field Definition
>> encap_eth_dst/src as values to be pushed/popped, that would be confusing.
>>
>> I'd like to have only one set of actions to do the same operation in different
>> circumstances (and doesn't have arbitrary restrictions).
>> There has been some work in OpenFlow as well as discussion on the OVS
>> mailing list for some of these other scenarios which might be useful as a
>> reference. Please investigate how you can have a clean solution that make
>> sense in these different cases - this one seems too NSH-specific.
> [JL]: Yes, there is another option is that  we still use the field definition eth_dst/src
> For the key fields and we introduce push_eth/pop_eth flow actions. Once we use
> Flow command push_eth, we will add one eth header at the front of packet.
> The origin Ethernet header(if exists) will be treated as payload, while pop_eth will
> Always strip the outer Ethernet header. In this implementation, the origin packet's
> Ethernet header would not be parsed, so they could be used as match fields.
> Yi Yang would have some concern for this kind of implementation since he would
> Use the inner header as part of match fields in his user cases.

Using a push/pop model seems better to me on the OpenFlow side as this
would be consistent with VLAN/MPLS tags, which can also be stacked.
Popping and then moving to a new table for an additional lookup could
be used to access the inner headers if necessary.

On the kernel side, it might be reasonable to parse multiple Ethernet
headers in one pass to avoid a round of recirculation. This is
possible since the kernel netlink interface handles nesting better and
would be consistent with how MPLS is implemented and (eventually)
VLAN. The reasonableness of that approach would depend on the extent
to which it can avoid expanding the flow key in a way that would
pessimize common use cases.



More information about the dev mailing list