+ [ovs-dev] Further comments below.
BR, Jan > -----Original Message----- > From: Li, Johnson [mailto:johnson...@intel.com] > Sent: Thursday, 11 August, 2016 03:36 > Subject: RE: NSH Option 2 implementation > > > > > Hi Danny, > > > > thanks, for your quick response. I look forward to hearing from Johnson Li. > > > > On the topic of my patches. I think Pravin and I have found a way > > forwards regarding handling of skb fields for l3 packets and I will > > work towards resubmitting the patches in the near future. > > > > On Wed, Aug 10, 2016 at 11:56:51AM +0000, Zhou, Danny wrote: > > > Hi Simon, > > > > > > Johnson Li is our guy who is working on preparing patches for MD > > > Type 2 > > support. He planned to send out NSH v3 RFC patch to OVS mailing list > > for comment but Jesse suggested waiting for your patches to be merged, > > so we decided to create a forked OVS repository at github with links > > to OVS and your patches, so people can play with. Stay tuned for that github > repository. > > > > > > In the meantime, Johnson can summary how to support MD type 2 using > > command line and Openflow and send out for discussion. > > > > Here are examples: > 1. ovs-ofctl commands: > $ovs-ofctl add-tlv-map br-int "{class=0xffff,type=0,len=4}->tun_metadata0, > {class=0xffff,type=1,len=8}->tun_metadata1" > #create two TLV maps, will be used as NSH metadata options > > $ovs-ofctl add-flow br-int "table=0, priority=260, in_port=LOCAL > actions=load:0x800001->NXM_NX_NSP[],load:0xFF->NXM_NX_NSI[], > load:2->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[], > load:0x11223344->NXM_NX_TUN_METADATA0[], > load:0x5566778899aabbcc->NXM_NX_TUN_METADATA1[],push_nsh,output:1" > # Encapsulation flow rules [Jan] Should sending a packet after push_nsh to an output port be allowed in general? For a VXLAN-GPE tunnel port this is OK, but my expectation was that one must explicitly do push_eth (followed by set_field for dl_src and dl_dst) to be able to transmit on a normal Ethernet port. Have you tried to use action syntax "set_field:0x11223344->tun_metadata0" instead of the "load:0x11223344->NXM_NX_TUN_METADATA0[]"? I think that should work as well. > $ovs-ofctl add-flow br-int "table=0, priority=260, nsh_mdtype=2, nsp=0x1, > nsi=0xFF, tun_metadata0=0x44332211, tun_metadata1=0xccbbaa9988776655 > actions=pop_nsh,output:LOCAL" > #Decapsulation flow, metadata as match field. [Jan] Matching on any nsh header fields must only be allowed if the pre-requisite eth_type=0x894f is also matched. The normal behavior of OVS is to ignore the match fields whose pre-requisite is not fulfilled. Try matching on nw_dst without specifying also ip (alias for eth_type=0x800) and see what happens. This handling must be implemented for all NSH packet header match fields. > > I still use the keywords "tun_metadata" in command line to keep backward > Compatibility with Geneve support. [Jan] To set the mapped MD2 TLVs before push_nsh, or to access them after pop_nsh, I feel the use of tun_metadata field names may be acceptable, as these are packet metadata fields nd not part of the actual packet header. For matching on NSH MD2 TLVs of a packet I would indeed prefer to introduce NSH-specific NSX field codes in OF and names in ovs-ofctl command, such as nsh_md2_tlv<X>. Internally these could still be stored in the same fields of the flow struct. > > The above flow rules will be translated into OF rules like: > push_nsh(flags=0x0,md_type=2,next_proto=3,nsp=0x800001,nsi=0xff, > {class=0xffff,type=0x0,len=4,0x11223344} > {class=0xffff,type=0x1,len=8,0x5566778899aabbcc}) > > Or > nsh(nsh_mdtype=2, nsi=0xff, > nsp=0x1,metadata({class=0xffff,type=0x0,len=4,0x44332211} > {class=0xffff,type=0x1,len=8,0xccbbaa9988776655})) These are not OpenFlow rules but OVS datapath flow cache entries. That is a significant difference. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
