[ovs-dev] NTP support with OpenSwitch

Srivatsan, Srinivasan srinivasan.srivatsan at hpe.com
Wed Jan 13 02:38:38 UTC 2016


+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


More information about the dev mailing list