[ovs-dev] [RFC PATCH v1 3/3] OVN ACL: Allow a user to input ct.label value for an acl
blp at ovn.org
Fri Feb 8 02:51:03 UTC 2019
On Thu, Feb 07, 2019 at 09:32:33PM +0000, Ankur Sharma wrote:
> Hi Ben,
> My bad, should have explained the use case as well.
> Following is the use case I started with:
> a. By associating identifier with connection tracker we can facilitate debugging from connection tracker side.
> b. For example, if a system has multiple OVN ACLs (Hundreds or Thousands), and we see an unexpected FLOW getting established.
> We can debug it from connection tracker side to see which "Allow" ACL, let the packet passthrough.
> I will update the documentation with this use case as well.
> Please let me know your thoughts.
> -----Original Message-----
> From: Ben Pfaff <blp at ovn.org>
> Sent: Wednesday, February 6, 2019 6:11 PM
> To: Ankur Sharma <ankur.sharma at nutanix.com>
> Cc: ovs-dev at openvswitch.org
> Subject: Re: [ovs-dev] [RFC PATCH v1 3/3] OVN ACL: Allow a user to input ct.label value for an acl
> I'd like to hear some kind of overall use case here. Sure, you can use it to identify an OVN ACL, or a security group, or anything else. How does that contribute to a larger system? There should be a hint to the reader about how and why to use it.
> On Wed, Feb 06, 2019 at 10:06:46PM +0000, Ankur Sharma wrote:
> > Reason for using 128 bits:
> > a. Connection tracker has only 2 fields for metadata, ct.mark(32 bits) and ct.label(128 bits).
> > b. Purpose of this series is to ensure that we use smaller field, i.e ct.mark for flags and use the bigger field, i.e ct.label for associating metadata with the ct entry.
> > c. An example of metadata could be a value which maps ct entry to corresponding OVN ACL or Security Group or both.
> > d. Yes, I agree that 128 could more than sufficient for most of the cases, but unless we see a use case of dividing ct.label in subfields, i thought we can leverage on full 128 bits.
> > This keeps implementation simple and also keeps the interpretation of a connection tracking entry simple.
> > Please let me know, if it sounds reasonable.
> > Thanks
> > Regards,
> > Ankur
> > -----Original Message-----
> > From: Ben Pfaff <blp at ovn.org>
> > Sent: Tuesday, February 5, 2019 1:40 PM
> > To: Ankur Sharma <ankur.sharma at nutanix.com>
> > Cc: ovs-dev at openvswitch.org
> > Subject: Re: [ovs-dev] [RFC PATCH v1 3/3] OVN ACL: Allow a user to
> > input ct.label value for an acl
> > On Fri, Jan 11, 2019 at 12:16:39AM +0000, Ankur Sharma wrote:
> > > This patch allows user to associate a value with acl, which will be
> > > assigned to ct.label of the corresponding connection tracking entry.
> > >
> > > This value can be used to map a ct entry with corresponding OVN ACL
> > > or higher level constructs like security group.
> > >
> > > signed-off-by: Ankur Sharma <ankur.sharma at nutanix.com>
> > Thanks for the patch!
> > Please capitalize the "S" in "Signed-off-by".
> > This adds a column in ovn-sb.ovsschema, so it should increment the minor version (the y in x.y.z).
> > The documentation for the new column explains what it does, but it does not explain the purpose. Why would a user set this column? What are its effects?
> > The column is a string, but its value is an integer. Maybe that is because OVSDB integer columns are limited to 64 bits, but this value can be 128 bits. That is a very large space. What is the reason that so much space should be dedicated to this identifier? Even 64 bits is more identifiers than any deployment will ever use, so there must be some other reason.
> > Please do not use // comments.
> > Please document the new option in the ovn-sbctl manpage.
> > Please add a NEWS item for the new feature.
More information about the dev