"Yang, Yi" <yi.y.y...@intel.com> writes: > I'm not sure what new action you expect to bring here, I think group > action is just for this, as you said it isn't only bound to NSH, you can > start a new thread to discuss this. I don't think it is in scope of NSH.
It is in scope of this discussion as you will provide a user space API that makes the NSH context fields accessible from user space in a certain way. If you commit to this, there is no way going back. I haven't yet grasped the idea on how those fields will be used in OVS besides load balancing. Even for load balancing the tunnel itself (vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough entropy to do per-flow load balancing. What else is needed? Why a context header for that? You just need multiple action chains and pick one randomly. The only protocol that I can compare that to is geneve with TLVs, but the TLVs are global and uniquie and a property of the networking forwarding backplane and not a property of the path inside a tenant. So I expect this actually to be the first case where I think that matters. Why are context labels that special that they are not part of tun_ops? Thanks, Hannes
