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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev