openconfig
Publish PTP Yang model
Change Scope
- Support PTP (Precision Time Protocol) in OpenConfig. PTP model implementation is based on IEEE1588
- This change is backwards compatible
Model
module: openconfig-ptp
+--rw ptp
+--rw instances
| +--rw instance* [id]
| +--rw id -> ../config/id
| +--rw config
| | +--rw id? uint32
| +--ro state
| | +--ro id? uint32
| | +--ro current-dataset-state
| | | +--ro steps-removed? uint16
| | | +--ro offset-from-master? oc-ptp-types:time-interval-type
| | | +--ro mean-path-delay? oc-ptp-types:time-interval-type
| | +--ro time-properties-dataset
| | +--ro current-utc-offset-valid? boolean
| | +--ro current-utc-offset? int16
| | +--ro leap59? boolean
| | +--ro leap61? boolean
| | +--ro time-traceable? boolean
| | +--ro frequency-traceable? boolean
| | +--ro ptp-timescale? boolean
| | +--ro time-source? uint8
| +--rw default-dataset
| | +--rw config
| | | +--rw priority1? uint8
| | | +--rw priority2? uint8
| | | +--rw domain-number? uint8
| | | +--rw slave-only? boolean
| | | +--rw clock-type? oc-ptp-types:clock-type-enumeration
| | | +--rw sdoid? uint16
| | | +--rw network-transport? oc-ptp-types:network-transport-enumeration
| | | +--rw unicast-multicast? oc-ptp-types:unicast-multicast-enumeration
| | | +--rw domain-profile? oc-ptp-types:domain-profile-enumeration
| | | +--rw udp6-scope? uint8
| | | +--rw master-ip* inet:ip-address
| | +--ro state
| | +--ro priority1? uint8
| | +--ro priority2? uint8
| | +--ro domain-number? uint8
| | +--ro slave-only? boolean
| | +--ro clock-type? oc-ptp-types:clock-type-enumeration
| | +--ro sdoid? uint16
| | +--ro network-transport? oc-ptp-types:network-transport-enumeration
| | +--ro unicast-multicast? oc-ptp-types:unicast-multicast-enumeration
| | +--ro domain-profile? oc-ptp-types:domain-profile-enumeration
| | +--ro udp6-scope? uint8
| | +--ro master-ip* inet:ip-address
| | +--ro two-step-flag? boolean
| | +--ro clock-identity? oc-ptp-types:clock-identity-type
| | +--ro number-ports? uint16
| | +--ro clock-quality
| | +--ro clock-class? uint8
| | +--ro clock-accuracy? uint8
| | +--ro offset-scaled-log-variance? uint16
| +--rw port-datasets
| | +--rw port-dataset* [port-number]
| | +--rw port-number -> ../config/port-number
| | +--rw config
| | | +--rw port-number? uint16
| | | +--rw underlying-interface? if:interface-ref
| | | +--rw log-announce-interval? int8
| | | +--rw announce-receipt-timeout? uint8
| | | +--rw log-sync-interval? int8
| | | +--rw delay-mechanism? oc-ptp-types:delay-mechanism-enumeration
| | | +--rw log-min-pdelay-req-interval? int8
| | | +--rw version-number? uint8
| | | +--rw unicast-multicast? oc-ptp-types:unicast-multicast-enumeration
| | +--ro state
| | +--ro port-number? uint16
| | +--ro underlying-interface? if:interface-ref
| | +--ro log-announce-interval? int8
| | +--ro announce-receipt-timeout? uint8
| | +--ro log-sync-interval? int8
| | +--ro delay-mechanism? oc-ptp-types:delay-mechanism-enumeration
| | +--ro log-min-pdelay-req-interval? int8
| | +--ro version-number? uint8
| | +--ro unicast-multicast? oc-ptp-types:unicast-multicast-enumeration
| | +--ro port-state? oc-ptp-types:port-state-enumeration
| | +--ro log-min-delay-req-interval? int8
| | +--ro peer-mean-path-delay? oc-ptp-types:time-interval-type
| +--rw parent-datasets
| +--rw parent-dataset* [parent-id]
| +--rw parent-id -> ../config/parent-id
| +--rw config
| | +--rw parent-id? uint16
| +--ro state
| +--ro parent-id? uint16
| +--ro parent-port-identity
| | +--ro clock-identity? oc-ptp-types:clock-identity-type
| | +--ro port-number? uint16
| +--ro parent-stats? boolean
| +--ro observed-parent-offset-scaled-log-variance? uint16
| +--ro observed-parent-clock-phase-change-rate? int32
| +--ro grandmaster-identity? oc-ptp-types:clock-identity-type
| +--ro grandmaster-clock-quality
| | +--ro clock-class? uint8
| | +--ro clock-accuracy? uint8
| | +--ro offset-scaled-log-variance? uint16
| +--ro grandmaster-priority1? uint8
| +--ro grandmaster-priority2? uint8
+--rw transparent-clock
+--rw default-dataset
| +--rw config
| | +--rw delay-mechanism? oc-ptp-types:delay-mechanism-enumeration
| | +--rw primary-domain? uint8
| | +--rw two-step-flag? boolean
| +--ro state
| +--ro clock-identity? oc-ptp-types:clock-identity-type
| +--ro number-ports? uint16
| +--ro delay-mechanism? oc-ptp-types:delay-mechanism-enumeration
| +--ro primary-domain? uint8
| +--ro two-step-flag? boolean
+--rw port-datasets
+--rw port-dataset* [port-number]
+--rw port-number -> ../config/port-number
+--rw config
| +--rw port-number? uint16
| +--rw underlying-interface? if:interface-ref
| +--rw network-transport? oc-ptp-types:network-transport-enumeration
+--ro state
+--ro port-number? uint16
+--ro underlying-interface? if:interface-ref
+--ro network-transport? oc-ptp-types:network-transport-enumeration
+--ro log-min-pdelay-req-interval? int8
+--ro faulty-flag? boolean
+--ro peer-mean-path-delay? oc-ptp-types:time-interval-type
No major YANG version changes in commit 0bcb8a2bb1b60959996a9f001a875bc72a378092
Yang model is not inline with IEEE1588 yang model. pls refer P1588e: https://github.com/YangModels/yang/blob/main/standard/ieee/draft/1588/ieee1588-ptp-ms.yang this is already approved and should be publish in few months.
I agree with @SulabhMohanSharma. This module is somewhat-aligned with the IEEE 1588 data sets, but not completely. In other standardization organizations, that sort of difference has proven to be quite painful for implementers. It is much safer to stick to the standard.
At a minimum, I think this PR should list the reasons for diverging from the IEEE 1588 standard.
Some possible reasons:
-
P1588e does not use sensitive terminology: There is a module to solve that: https://github.com/YangModels/yang/blob/main/standard/ieee/draft/1588/ieee1588-ptp-tt.yang
-
OpenConfig needs to add its own nodes: This can be done by importing the P1588e module and augmenting its tree. ITU-T and IEEE 802.1 are doing this.
-
P1588e has too many nodes: All nodes are formally optional, so OpenConfig can specify a smaller subset as required in order for servers to provide a more compact model.
-
OpenConfig cannot wait: IEEE Std P1588e is past the balloting stage, with formal IEEE approval (i.e., RevCom) scheduled for Jan 29, so it is moving from "draft" to "published" very soon.
Let's not reinvent one more YANG data model for PTP. Let's use the IEEE1588e standardized data model here in openconfig.
I had a number of comments as well. I noted them in Issue #1039 Can we discuss these as well.
@sallylsy are you available to discuss some of these comments?
I submitted a new PR based on our discussion. Please find the new model in https://github.com/openconfig/public/pull/1103
@proberts2022 @kam-gopalakrishnan please provide any comments so we can move this forward.
Its unclear where we should be adding comments. Issue https://github.com/openconfig/public/issues/1039 , Pull request https://github.com/openconfig/public/pull/1036 or Pull Request https://github.com/openconfig/public/pull/1103
I added the following to 1103: 1 Configuration of unicast versus multicast? default-dataset:config:unicast-multicast port-dataset:config:unicast-multicast
If the network transport protocol and the unicast/multicast qualifier are to be applied at the default-ds level, why is the unicast-multicast leaf necessary within the portDS?
- master-ip list? default-dataset:config:master-ip [list] "A list of IP addresses." Can you please provide a more detailed description of the use of this list. It is not clear to me what this list is defining. Is this a list of IP used by PTP clocks external to this clock and if so how is this list to be used? Is this the acceptable master table but using IP addresses? Is it addresses to which this clock should send Signaling messages with Unicast Negotiation TLVs?