[ovs-dev] NSH Option 2 implementation

[Li, Johnson]

> 
> + [ovs-dev]
> 
> Further comments below.
> 
> BR, Jan
> 
> > -----Original Message-----
> > From: Li, Johnson [mailto:johnson.li at 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