[ovs-dev] [PATCH 0/7] Enable NSH based Service Function Chaining support in OVS

Liu, Mengke mengke.liu at intel.com
Mon Oct 26 03:22:23 UTC 2015

> > The “push_nsh” action is to add the NSH header and “output:2” is to
> > add the tunnel header via the VxLAN-GPE port.
> >
> > One question we want to discuss here is about how to implement the
> > VxLAN-GPE port, we have two proposals:
> >
> > 1)      Add a new configuration option for current VxLAN vport type:
> > “options:enable_GPE=true”, then the virtual port created with this
> > option enabled will be VxLAN-GPE but not VxLAN, corresponding actions
> > will be VxLAN-GPE specific.
> >
> > 2)      Add a new vport type “VxLAN-GPE” parallel to “VxLAN”.
> >
> > Which proposal do you prefer to take?
> I think it seems like option #1 is probably the simplest and most consistent.
> Another small note, I think I would just call the option "gpe" rather than
> "enable_GPE".

Yes, We will call it the option "gpe" rather than "enable_GPE"

> > As discussed above, the NSH layer will be an independent protocol
> > layer but not part of VxLAN tunnel. Then for the lightweight tunneling
> > support in kernel, changes we need to make are to add supports for
> VxLAN-GPE tunneling.
> > Options here are to add a new vport type for VxLAN GPE or extend
> > current VxLAN port to support VxLAN GPE.
> Here I would definitely extend the current VXLAN code. It will result in much
> less duplication and the Linux implementation of VXLAN already has a
> mechanism to support extensions.

OK. We will extend the current VXLAN port to support VxLAN GPE.

> > Except for the VxLAN GPE support in lightweight tunneling, we’ll also
> > add the NSH protocol support in the kernel space datapath code for
> > Linux upstream.
> >
> > BTW, can you give us some guidance regarding the model to upstream
> > lightweight tunneling to kernel.
> Here is some information that was sent out when the current process was
> adopted:
> http://openvswitch.org/pipermail/dev/2014-December/049513.html
> > For supporting TLV, VxLAN GPE doesn’t have option TLVs in current
> > definition. So for VxLAN GPE, we don’t need to implement the TLV
> > option fields as Geneve.
> [...]
> > But for NSH header, if the meta-type (MD-type) is 2 as below, we need
> > the option TLV support:
> [...]
> Yes, I was just referring to the TLVs in NSH.
> > So for NSH header, we need to add the TLV support. For the fixed
> > fields of NSH header like NSI, NSP, we’d like to add specific
> > meta-flow fields for them, for example:
> >
> > MFF_NSP            Type: NXM_NX_NSP (105),         Length:4 bytes
> >
> > MFF_NSI             Type: NXM_NX_NSI (106),          Length:1 bytes
> >
> > But for the variable length context headers of NSH, we’d like to use
> > fields like “tun_metadata” (tnl->metadata) to support it. We also have two
> options:
> >
> > 1)      Reuse the “tun_metadata” for NSH variable context header, it’s
> > similar to current Geneve TLV support. But it’s a little wield because
> > the NSH header is already an independent protocol layer but not belong
> > to the tunnel layer.
> >
> > 2)      Define a new “nsh_metadata” fields for NSH variable context header.
> >
> > Which one do you prefer? Please tell us for you inputs on our
> > modification plan.
> I would definitely like to reuse the same set of fields as were used for
> Geneve since there are a large number of them and have a second set
> seems wasteful. I don't think there is anything that inherently ties them to
> tunneling, so if you have a different name that is more generic we can still
> change them as long as it is before OVS 2.5 is released.
> By the way, there are several OpenFlow commands that were added support
> mapping TLVs to fields. These are currently specific to Geneve because they
> validate some protocol specific aspects. NSH actually uses the same TLV
> format as Geneve, so in theory they could be shared (and it would be nice to
> avoid duplicating these). The main thing that concerns me about this is the
> possibility that the protocols will diverge in the future or some other protocol
> that does not have the same format will want to use the same thing. In any
> case, it would be nice to think about how this could be made useable by
> everybody before OVS 2.5.

We will support NSH MD type2 with a variable-length TLV format for metadata. And 
NSH MD type2 should share TLV with Geneve.  We will send out an initial plan for 
MD type2  several days later.


More information about the dev mailing list