[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.

-Mengke



More information about the dev mailing list