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