Hi Siwar and Alex,
We had discussed this issue in the old version 05, which said “Under certain
circumstances, the classification of an IEEE 1588 data set member can change.
For example, each port's port-state leaf is normally Dynamic, in that the IEEE
1588 protocol determines its value, and it is read-only from management..
Nevertheless, some IEEE 1588-2008 products support a proprietary boolean (e.g.
leaf in a product-specific YANG augment) that allows port-state to be
configured externally. When the proprietary boolean is false, port-state is
Dynamic, representing YANG state data. When the proprietary boolean is true,
port-state is Configurable, representing YANG configuration data.
Future revisions of the IEEE 1588 standard are considering formal
standardization of this sort of proprietary feature, to be reflected in future
revisions of this YANG module.
Due to the fact that the classification of 1588 members can change, this model
does not specify fixed YANG hierarchies of configuration and state. For
information on the classification of each data set member, refer to the IEEE
Std 1588 specifications for that member.”
The above texts were finally removed for simplification during the Last Call
resolution of this draft. Nevertheless, there may be cases of dynamic data
(e.g., protocol engine current state or clockClass) allowed to be configured at
a forced / manual way for future 1588 profiles. Thus, we modeled dynamic
members as read-write in this draft.
We also went through all members classified as static in clause 8 of IEEE
1588-2008.
defaultDS.twoStepFlag is static in IEEE 1588-2008, but in reality many vendors
have equipments on which twoStepFlag can be configured, recent internetworking
testing of PTP sync in the industry even relied on this feature.
defaultDS.numberPorts, transparentClockDefaultDS.numberPorts are also static in
IEEE 1588-2008, but they can also be dynamically changed depending on sync
interfaces found on the equipment.
Thus, it seems only the following data set member classified as static in
1588-2008 could be safely marked as ‘config false’:
1. defaultDS.clockIdentity
2. portDS.portIdentity
3. transparentClockDefaultDS.clockIdentity
4. transparentClockPortDS.portIdentity
Therefore, we can update the draft to mark them as as ‘config false’, i.e.,
‘clock-identity’ in default-ds and transparent-clock-default-ds; ‘port-number’
in port-ds-list and transparent-clock-port-ds-list.
BTW, ‘clock-identity’ in transparent-clock-port-ds-list can be removed as it is
the same as the leaf node ‘clock-identity’ in transparent-clock-default-ds.
Furthermore, we have two approaches to change a configurable member to
read-only in an implementation:
1. If a node is read-write in YANG, and if an implementation wants it
read-only in reality, the implementation can return an error/warning upon write.
2. YANG ‘deviation’ can be used to change a node statement [RFC 7950],
e.g., the following are some sample codes in YANG to turn two-step-flag into
read-only:
module ptp-deviations {
namespace "urn:example:ptp-deviations";
prefix ptpd;
import ietf-ptp {
prefix ptp;
}
deviation /ptp:ptp/ptp:instance-list/ptp:default-ds/ptp:two-step-flag {
deviate replace {
config false;
}
}
}
I hope this consideration is practical and future-proofing, but please share
your opinions on this topic.
Thanks,
Yuanlong
From: TICTOC [mailto:[email protected]] On Behalf Of BEN HADJ SAID Siwar
Sent: Wednesday, April 04, 2018 5:57 PM
To: Alex Campbell; [email protected]
Subject: Re: [TICTOC] Questions (and one comment) on ietf-ptp
Hi,
I agree with Alex.
In the ietf-ptp tree diagram all data nodes are marked “rw”.
However, according to my understanding of the standard IEEE 1588v2, several
data node are not supposed to be configured by the network management system.
In IEEE 1588v2 clause clause 8.1.2, the parameters are classified into static,
dynamic and configurable parameters.
Only configurable parameters can be modified by network management systems.
For instance, all members of the current-ds data set are dynamic (IEEE
1588-2008 clause 8.2.2) ==> IMHO, all data nodes shall be “ro” (for that, a
statement “config false” is required to be present in the current-ds container).
I drafted lately the IEEE 802.1AS YANG model in
(https://www.ietf.org/id/draft-benhadjsaid-detnet-gptp-yang-00.txt) where I
precise for each non-configurable (static and dynamic) data node “the config
false” statement.. Otherwise, the data node will be considered configurable by
default.
Siwar
De : TICTOC <[email protected]<mailto:[email protected]>> De la
part de Alex Campbell
Envoyé : mercredi 4 avril 2018 01:29
À : [email protected]<mailto:[email protected]>
Objet : Re: [TICTOC] Questions (and one comment) on ietf-ptp
Also:
It looks like several data nodes intended to contain operational data are
missing a "config false;" statement to mark them as such.
This should include anything labeled as "dynamic" in IEEE 1588-2008..
For instance (but not limited to) time-properties-ds; port-state;
log-min-delay-req-interval, and peer-mean-path-delay.
By default, all data is configuration data, which is to be written by the
network management system and not usually by the network device.
________________________________
From: TICTOC <[email protected]<mailto:[email protected]>> on
behalf of Alex Campbell
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, 4 April 2018 11:12 a.m.
To: [email protected]<mailto:[email protected]>
Subject: [TICTOC] Questions (and one comment) on ietf-ptp
Hi,
Regarding the YANG model defined in draft-ietf-tictoc-1588v2-yang-07:
When an arbitrary identifier is needed for a list key, most YANG models tend to
use strings (e.g. ietf-hardware, ietf-interfaces, tend to use strings rather
than numbers.
I suggest changing instance-number to a string instance-name.
Is there a way for the management system to determine the relationship between
port numbers and interface names, when using transparent clock mode?
port-ds-list has underlying-interface, which seems to solve exactly this
problem. But there's no such leaf for transparent-clock-port-ds-list.
Finally, what should happen if a port is configured as a member of more than
one instance (or one instance and transparent clock)?
Thanks,
Alex
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc