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

Reply via email to