On Wed, Oct 14, 2015 at 1:28 AM, Liu, Mengke <mengke....@intel.com> wrote: > Hi, Jesse, > > Thanks for your comments on this series. Below are our comments and our > modification plan for this patch: > > Firstly, we agree that we should operate VxLAN GPE header and NSH header at > different protocol layers, which will avoid lots of unnecessary conflations. > Then in our modified high level design, we will decouple VxLAN/VxLAN-GPE > tunneling header push/pop and NSH header push/pop. As the NSH header is > handled as an independent layer, a new push/pop action “push_nsh/pop_nsh” > will be added to support push and pop NSH header in both kernel datapath and > userspace datapath. In this way, NSH header will not be part of tunnel > header, it’s independent and the NSH header will be added/removed by NSH > specific actions, for example:
Great, that sounds good. > Ovs-ofctl add-flow br-int “in_port=1, actions=set_nsi:1, set_nsp:12345, > push_nsh, output:2” (port 2 is the VxLAN GPE port) One small note here, rather than adding explicit actions for each of these fields, you can just use the existing set_field action with the new matches you added. > 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". > 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. > 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
