> -----Original Message----- > From: Jesse Gross [mailto:je...@kernel.org] > Sent: Saturday, December 12, 2015 1:41 AM > To: Liu, Mengke <mengke....@intel.com> > Cc: dev@openvswitch.org; Pritesh Kothari (pritkoth) <pritk...@cisco.com>; > Zhou, Danny <danny.z...@intel.com>; Li, Ricky <ricky...@intel.com>; > pa...@cisco.com > Subject: Re: [ovs-dev] [PATCH 0/7] Enable NSH based Service Function > Chaining support in OVS > > On Thu, Dec 10, 2015 at 6:55 PM, Liu, Mengke <mengke....@intel.com> > wrote: > >> -----Original Message----- > >> From: jgr...@nicira.com [mailto:jgr...@nicira.com] On Behalf Of Jesse > >> Gross > >> Sent: Tuesday, December 8, 2015 12:32 AM > >> To: Liu, Mengke <mengke....@intel.com> > >> Cc: dev@openvswitch.org; Pritesh Kothari (pritkoth) > >> <pritk...@cisco.com>; Zhou, Danny <danny.z...@intel.com>; Li, Ricky > >> <ricky...@intel.com>; pa...@cisco.com > >> Subject: Re: [ovs-dev] [PATCH 0/7] Enable NSH based Service Function > >> Chaining support in OVS > >> > >> On Fri, Nov 6, 2015 at 4:23 PM, Jesse Gross <je...@nicira.com> wrote: > >> > On Tue, Nov 3, 2015 at 10:20 AM, Liu, Mengke <mengke....@intel.com> > >> wrote: > >> >>> > 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. > >> >> > >> >> For NSH TLV implementation, We agree that we should reuse the > >> >> same > >> set of fields as were used for Geneve. As NSH in MD-Type 2 use same > >> TLV format as Geneve, they can share the pool of 64 NXMs which can be > >> mapped on Geneve TLVs or NSH TLVs. It may be better to make the > >> command name more generic. For example, we can rename > >> “add-geneve-map” to “add-tlv- map”. > >> >> An example in our initial design for NSH MD-type 2 support: > >> >> ovs-ofctl add-tlv-map br0 > >> >> {class=0xffff,type=0,len=4}->tun_metadata0 > >> >> ovs-ofctl add-flow br0 in_port=LOCAL, actions=push_nsh, > >> >> set_field:221->nsp, set_field:3->nsi, set_field:2- > >> >nsh_md_type,set_field:111->tun_metadata0, 1 What do you think > about > >> this proposal for NSH TLV support? > >> > > >> > I think it's basically fine although I worry a bit that "add-tlv-map" > >> > isn't overly descriptive - it isn't obvious that it is referring to > >> > this type of metadata or there could be TLVs in other formats. > >> > >> I just wanted to point out that OVS 2.5 has branched at this point > >> and contains the current (Geneve-centric) names of these > commands/fields. > >> If you want to change them, I would still apply a patch to help with > >> forward compatibility. However, the window of time to do that is > >> rapidly closing, so speak now or forever hold your peace. > > > > We strongly agree that the command "add-geneve-map" should be > renamed to "add-tlv-map" or the other generic name for NSH TLV support > and other protocol in future. We plan to add NSH MD-Type 2 support in the > first quarter of 2016. > > > > About this patch for renaming the command name, if you are busy, we are > pleased to submit it for review. Thanks. > > Please submit a patch to do the renaming ASAP so that it can be applied to > branch-2.5.
The patch has been submitted to OVS community. The subject of email is "[PATCH] geneve-map-rename: rename geneve-map to tlv-map." _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
