> On Mon, Jun 20, 2016 at 9:02 PM, Li, Johnson <johnson...@intel.com> wrote: > > 2) Add framework codes (or full implementation) for MD type 2 support of > > the NSH header. According to the discussion at > > http://comments.gmane.org/gmane.network.openvswitch.devel/53788 > > I will reuse the definitions for METADATA[0...63]. Since NSH is not > > one of > > The tunneling encapsulation headers, renaming for the fields is > > required. > > This might be a huge change for the current code base: > > Please see this discussion with you coworker from 6 months ago: > http://openvswitch.org/pipermail/dev/2015-December/063306.html > > You guys already renamed the fields once. At this point, you need to live with > what is there since we're not going to break compatibility with previous > releases. > [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.
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. > > 3) Add "Ethernet + NSH" support for the OVS. Following the discussion > > at > > http://comments.gmane.org/gmane.network.openvswitch.devel/53788 > > we will introduce new match fields "encap_eth_dst/encap_eth_src" > > and > > related openflow actions"push_encap_eth/pop_encap_eth". Since we > > treat outer Ethernet header as encapsulation header, so NO VLAN > > and > > MPLS tags are supported for the outer header. That means packets > > with > > Format "Ethernet + VLAN[|MPLS] + NSH + Ethernet + IPv4[|IPv6] + > playload" > > Will be dropped by the OVS when parsing the packets. > > Examples for Ethernet NSH case: > > 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
