+Adding Michael
Regards
Srinivasan
On 1/12/16, 4:16 PM, "dev on behalf of Srivatsan, Srinivasan"
<dev-boun...@openvswitch.org on behalf of srinivasan.srivat...@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@openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
