> > + [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. > Yes, to output to VxLAN-GPE port, we could just use "output:1" as shown in The example flow, while adding some additional flow actions are required to Output to normal L2 port. We could explicitly add flow action "push_eth" or We could use implicit "push_eth" dataplane action to add an Ethernet header To the packet before outputting to the normal L2 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. Yes, that works 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. Thanks to point it out, I will try to add pre-requisite. > > 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. > Ok, I will try to change the name for NSH Metadata. > > > > 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
