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

Li, Johnson johnson.li at intel.com
Wed Jun 22 02:40:51 UTC 2016


> 
> On Tue, Jun 21, 2016 at 6:50 PM, Li, Johnson <johnson.li at intel.com> wrote:
> >> On Mon, Jun 20, 2016 at 9:02 PM, Li, Johnson <johnson.li at intel.com>
> wrote:
> > [JL] Yes, Mengke had renamed the command line and mapping table from
> > xx-geneve-yy To xx-tlv-yy. However, the flow fields are still named
> > TUN_xxxx and bind to geneve Tunneling ports. So there are some issues
> > here. For example, I added one VxLAN port With the following command:
> > # sudo ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 type=vxlan \
> >                          options:dst_port=4790 options:remote_ip=192.168.50.101 \
> >                          options:key=1000 options:exts=gpe Then I
> > tried to add some TLV map and then some flows:
> > #sudo ovs-ofctl add-tlv-map br-int "{class=0xffff,type=0,len=4}-
> >tun_metadata0,  \
> >             {class=0xffff,type=1,len=8}->tun_metadata1"
> > #sudo ovs-ofctl add-flow br-int "table=0, priority=260, in_port=LOCAL \
> >             actions=load:0x11223344->NXM_NX_TUN_METADATA0[], \
> >             load:0x5566778899aabbcc->NXM_NX_TUN_METADATA1[],output:1"
> >  Then I dumped the data path flow rules, it would be like:
> >     set(tunnel(tun_id=0x3e8,dst=192.168.50.101,ttl=64, \
> >     geneve({class=0xffff,type=0,len=4,0x11223344} \
> >
> > {class=0xffff,type=0x1,len=8,0x5566778899aabbcc}),flags(df|key))),2
> > Even though I set the tunneling port's type to be VxLAN, the data
> > plane flow will Be geneve, then the flows cannot be downloaded to the
> data plane.
> 
> Sure, this isn't surprising considering that Geneve is the only user of those
> fields in the current codebase. You'll need to find a way to generate the
> correct fields in this situation but that shouldn't involve any widespread
> renaming.
> 
[JL]: I will try to make smallest change to make both geneve and NSH work. 
I will rename the definition which MUST be renamed. 
> > In the development, we must unbind the fields TUN_METADATAx from
> > geneve tunneling Ports.  So rename the these fields may also be
> > required since the NSH header is not A tunneling encapsulation header.
> http://comments.gmane.org/gmane.network.openvswitch.devel/53788
> >> 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. 


More information about the dev mailing list