[ovs-dev] proposed flow key compatibility rules

[Jesse Gross]

On Tue, Nov 8, 2011 at 8:27 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Tue, Nov 8, 2011 at 8:20 PM, Ben Pfaff <blp at nicira.com> wrote:
>> On Tue, Nov 08, 2011 at 06:40:51PM -0800, Jesse Gross wrote:
>>> On Tue, Nov 8, 2011 at 5:03 PM, Ben Pfaff <blp at nicira.com> wrote:
>>> > Jesse and I spent some time pondering this face-to-face, so there's a
>>> > bunch of discussion that hasn't shown up on the mailing list.
>>> >
>>> > My understanding of what we concluded is:
>>> >
>>> > ?? ?? ?? ??- We will add a new "encap" flow key attribute that contains
>>> > ?? ?? ?? ?? ??nested attributes. ??An "encap" is used whenever layering is
>>> > ?? ?? ?? ?? ??duplicated or jumps down (e.g. when a L2, L3, or L4 header
>>> > ?? ?? ?? ?? ??is followed by an L2 header).
>>> >
>>> > ?? ?? ?? ??- The "set" action is explicitly defined to act on the
>>> > ?? ?? ?? ?? ??outermost instance of a header.
>>> >
>>> > ?? ?? ?? ??- We will abandon the pretense that "push" and "pop" can be
>>> > ?? ?? ?? ?? ??generic and introduce explicit "push_vlan" and "pop_vlan"
>>> > ?? ?? ?? ?? ??actions.
>>>
>>> I agree that this is what we concluded.  I had one additional thought
>>> though: In general, this format is now ordering independent but the
>>> encap attribute is linked to the encapsulating tag but is separate.  I
>>> think this is not actually ambiguous because there can only be one
>>> level of encapsulation at a given nesting level and it is always
>>> essentially at the end.  It's a little strange though.
>>
>> There are other alternatives that are odd in other ways.  Instead of
>> vlan(vid,pcp),encap(...), we could use vlan(vid,pcp),vlan_encap(...),
>> that is, make the encap attribute specific to what's causing the
>> encapsulation, or we could use vlan_encap(vlan(vid,pcp),...).
>
> Another thing that I thought of was:
> vlan(encap_attrs(vid,pcp),...)
> i.e. have a generic encapsulation attributes type with contents that
> depends on the outer tag.
>
> Like you said though, they're all weird in some way.

Having thought about this some more, I think the encap tag as you
wrote it is probably still the best.  I guess that it's not really
that different from a given EtherType causing us to expect a
particular L3 protocol, for example.