On Tue, Nov 8, 2011 at 8:27 PM, Jesse Gross <je...@nicira.com> wrote: > On Tue, Nov 8, 2011 at 8:20 PM, Ben Pfaff <b...@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 <b...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
