[ovs-dev] NTP support with OpenSwitch

Fri Jan 29 06:13:40 UTC 2016

To add to my previous note - the proposed reference type can be considered a "group" reference. The constraint being that the group cardinality (number of elemets referenced) should be > 0. If cardinality becomes zero, the entry is garbage-collected.

> -----Original Message-----
> From: Ansari, Shad
> Sent: Thursday, January 28, 2016 10:06 PM
> To: dev at openvswitch.org
> Cc: 'Ben Pfaff'; Srivatsan, Srinivasan
> Subject: RE: [ovs-dev] NTP support with OpenSwitch
> 
> 
> An example I can think of is a multicast forwarding table with index columns:
> - mcast address
> - UUID list of outgoing interfaces (which are some sort of weak-refs to Interface
> table entries)
> 
> It may be desirable to have a mcast table entry garbage collected when when all
> its participating interfaces are deleted.
> Maybe new category of weak refs can be employed - one that garbage collects
> an entry when it's self-to-many relationship is reduced to self-to-zero.
> 
> 
> > -----Original Message-----
> > From: Ben Pfaff [mailto:blp at ovn.org]
> > Sent: Wednesday, January 20, 2016 1:46 PM
> > To: Srivatsan, Srinivasan
> > Cc: dev at openvswitch.org; discuss at openvswitch.org; Ansari, Shad
> > Subject: Re: [ovs-dev] NTP support with OpenSwitch
> >
> > The schema constraints that OVS supports certainly aren't perfect.
> > There are plenty of situations where one can come up with better kinds
> > of constraints.  Maybe you have come up with one.  If you're going to
> > propose adding a new kind of constraint, then I think it would be
> > worthwhile to think through whether it will be useful in many
> > situations.  For example, do you have use cases beyond NTP?  If it's a
> > useful general-purpose construct, then I'm more in favor of adding it.
> >
> > On Wed, Jan 13, 2016 at 02:38:38AM +0000, Srivatsan, Srinivasan wrote:
> > > +Adding Michael
> > >
> > > Regards
> > > Srinivasan
> > >
> > >
> > >
> > >
> > > On 1/12/16, 4:16 PM, "dev on behalf of Srivatsan, Srinivasan" <dev-
> > bounces at openvswitch.org on behalf of srinivasan.srivatsan at hpe.com>
> wrote:
> > >
> > > >Hi,
> > > >
> > > >I am Srinivasan and am trying to add Network Time Protocol support for
> > OpenSwitch. Openswitch uses OVSDB as the central db for
> status/configuration
> > and inter module communication. From the NTP point of view, we are trying
> to
> > define how can modulate NTP to accommodate into the ovsdb schema design.
> > > >
> > > >About NTP client:
> > > >NTP servers local/remote synchronize time information to the connected
> > NTP clients. NTP clients are require to configure servers based on their liking.
> > What the NTP client configuration should allow is configuring of different NTP
> > servers within different VRFs. So following configurations are correct in terms
> of
> > NTP client configuration "ntp server 1.1.1.1 use_vrf vrf1" and "ntp server
> 1.1.1.1
> > use_vrf vrf2".
> > > >
> > > >Schema Design:
> > > >Now to define a schema, we have a top level System table which refers to
> > NTP table. NTP table can have multiple rows of server
> > configuration/associations. Each association should be able to support VRF
> > configuration per server configuration. Lets say we have the following
> columns
> > in the NTP table:
> > > >- "ip_address" for referring to the server ip address and
> > > >- "vrf" to refer to the vrf associated with this server.
> > > >
> > > >If we have weak references from NTP -> VRF then we should be able to use
> > NTP:"ip_address" and NTP:”vrf" as the index for the NTP table. Overall it looks
> > like this:
> > > >
> > > >    +---------+
> > > >    | SYSTEM  |
> > > >    +---------+
> > > >    |         |
> > > >+---v-+    +--v--+
> > > >| NTP +----> VRF |
> > > >|     +---->     |
> > > >+-----+    +——---+
> > > >
> > > >- Multiple NTP rows can refer to the same VRF reference.
> > > >- Multiple NTP rows can have same NTP:"ip_address" but should have a
> > different VRF:"reference"
> > > >
> > > >Pros of doing this schema:
> > > >- Simpler model of mapping NTP -> VRF instead of using VRF -> NTP since
> we
> > should not have the notion of time split per VRF.
> > > >- Rest can be nicely integrated into system/ntp/vrf or system/ntp/*
> > > >- vtysh cli/show/config implementation is easier to get all the information
> > about NTP at one go.
> > > >
> > > >Issue:
> > > >Step1: If we have 2 VRFs : "vrf1" and "vrf2", and if it maps to different rows
> in
> > the NTP table with same NTP:"ip_address".
> > > >Step2: So the NTP table has two rows: 1st row with NTP:"ip_address" as
> > 1.1.1.1 and NTP:"vrf" as uuid_of("vrf1") and 2nd row with NTP:"ip_address" as
> > 1.1.1.1 and NTP:"vrf" as uuid_of("vrf2").
> > > >Step3: Now lets say user deletes "vrf1" from the VRF table, which would
> > trigger NTP:"vrf" for the 1st row to point to []. This command executes
> > successfully and it removes the VRF reference and it invalidates entry within
> the
> > NTP table.
> > > >Step4: Now the user chooses to delete "vrf2" from the VRF table, which
> > would trigger a similar update to earlier but it would fail because you cannot
> > have two entries with the same index ie NTP:"ip_address" and NTP:"vrf"
> > combination.
> > > >
> > > >Unless the information within NTP table is cleared by a garbage collection
> > program, it would not be possible for Step4 to be executed successfully.
> > > >
> > > >From what Michael points out, Today OVSDB schema has two modes of
> > references
> > > >1)      “Strong” – target row can’t be removed as long as it has strong
> > references leading to it.
> > > >2)      “Weak” – target row can be deleted and the referencing cell will by
> > NULLed.
> > > >We use “weak” references, where one of the inter-referenced tables has to
> > be updated very frequently.
> > > >The downside is that rows that get their cells NULLed are generally invalid
> > rows and have to be garbage collected by somebody.
> > > >Additionally NULLed cells might cause index constraints violations, in which
> > case, the target row would again not be deleted.
> > > >
> > > >Ideal Solution:
> > > >What we would require in such a situation to support NTP is to have a
> "weak-
> > gc" that would allow the target row to be deleted instead of setting the
> > reference to NULL.
> > > >
> > > >I would like to hear your thoughts on whether you've encountered features
> > where we would want to support something similar to this. Do we know of any
> > work-in-progress patches which we can use to do this ? Or is there a feature
> > which has handled this differently.
> > > >
> > > >Thanks
> > > >Srinivasan
> > > >_______________________________________________
> > > >dev mailing list
> > > >dev at openvswitch.org
> > > >http://openvswitch.org/mailman/listinfo/dev
> > > _______________________________________________
> > > dev mailing list
> > > dev at openvswitch.org
> > > http://openvswitch.org/mailman/listinfo/dev