Responses inline below prefixed [JF] ________________________________________ From: Rodney Cummings [[email protected]] Sent: 18 September 2017 20:08 To: John Fletcher; [email protected] Subject: RE: WGLC for draft-ietf-tictoc-1588v2-yang
Great comments John... thanks. I'll offer some opinion below. As an introduction of sorts, although this YANG is limited to the published IEEE Std 1588-2008, some of the concepts from the ongoing 1588 revision are having a subtle effect. The reason is simple: When a YANG module is created for the 1588 revision (likely 1588-2018), ideally it can be done as a revision of this 1588-2008 YANG module, such that the YANG revision complies fully with RFC 7950 section 11. There's no guarantee that this will be possible, but so far it seems feasible by keeping the fundamental hierarchy consistent with 1588-rev, while continuing to limit its nodes to 1588-2008. > There are configurable attributes beyond those listed. For example: > attributes for the optional features of 1588-2008 clauses 16 and 17; the > sample period for variance estimation (clause 7.6.3.2) etc. These should > be included. 1588-2008 didn't have a clear definition of "configurable by management" beyond the 1588-based messages of 1588-2008 clause 15. There are plans to clarify that topic in 1588-rev by recommending that the 1588 data sets serve as an information model for management. That already has precedent for 1588-2008 (e.g. RFC8173 and this YANG I-D), so it seems like a safe recommendation as we move forward. That being said, you're correct that 1588-2008 specifies data sets for the optional features in clause 16 and 17. Nevertheless, in 1588-2008 those data sets are somewhat "disconnected" relative to the other data sets (i.e. overall management hierarchy). We're clarifying that topic in 1588-rev, so my slight preference would be to defer management of these features to the creation of a 1588-rev YANG revision. Nevertheless, one of the goals of this 1588-2008 YANG is to serve shorter-term needs, so if you have a specific optional feature that you need to manage in current 1588-2008 products, maybe we should add that to this I-D. [JF] Examples would be: Unicast negotiation enable, Unicast master table, Acceptable master table. As for the period for variance estimation in 7.6.3.2, that has no data set member in 1588-2008. I seem to recall discussion in the 1588 working group of making that period manageable (i.e. a data set member), but that was rejected, and thus far the draft of 7.6.3.2 hasn't changed from 1588-2008. If you feel strongly that this period should be manageable, I'd recommend that you submit a comment for the 1588 revision. If you are an IEEE-SA member, you can do that during sponsor ballot (probably 1Q2018). If not, feel free to write something up and I'd be happy to submit it for you. [JF] 1588-2008 says the sample period shall be the value defined in the applicable PTP profile, which implies that if you want to configure a device according to a profile, you need to manage that value. I'm not aware of any profiles that define a different value from the default profile, though, so not a big deal. > I find it confusing that the hierarchy shown in section 2 has every node > as "rw" even though many are not configurable. Later, in section 2.2, > there is some explanation of this but I think a further note is needed > before the hierarchy diagram. Sounds good. > Section 2.1 says that "1588-2008 transparent clocks are domain > independent" but I don't think that is correct; transparent clocks have a > "primary syntonization domain". Correct. For the next draft, we can remove the "domain independent" language. That came from the NOTE in 1588-2008 subclause 8.3.1, and the concept isn't needed in this context. > instance-number description makes it sound like there is one PTP dataset > for each domain but I think the intention is one set of PTP datasets, the > set comprising default-ds, current-ds, parent-ds etc. However, I don't > see any reason to tie instances to domains. Instances seem to be > equivalent to clocks (one clock per instance). A device can contain > mulitple clocks and there is no requirement that all clocks in a device > are in different domains. Correct. 1588-2008 implied this "instance" concept, and 1588-rev makes it explicit. The intention is exactly as you describe. It is simply an instance of the PTP standard's specifications. Two instances might use different domainNumber, or the same domainNumber (e.g. two disjoint physical networks). I'll work with my co-authors to clarify this in the text. > I think it would help to have a definition of PTP Instance. A draft of > 1588-rev said: "A PTP Instance is one of the following: an Ordinary Clock, > a Boundary Clock, or a Transparent Clock". The yang model here seems to > be assuming that a Transparent Clock is not an instance. It would be > confusing to use a different definition of Instance than the one in 1588- > rev. An alternative would be to stick with the terminology of 1588-2008. Correct. I'll work with my co-authors to clarify this in the text. You found the issue that makes this tricky... transparent clock. As the 1588 group worked through the 1588 revision, the group decided to clarify that each "PTP Instance" (i.e. the explicit instance concept) operates on one-and-only-one domain. That's fine for ordinary clock and boundary clock, but it was controversial for transparent clock due to the preceding "domain independent" concept. Some transparent clock implementations operate on all domains, in that the timestamp in the message is changed regardless of what the domainNumber field contains. Some other transparent clock implementations operate like a "PTP Instance", in that they only change the message when the domainNumber field matches the domainNumber in the transparent clock's data sets. The intent of 1588-2008 was the "instance" way, but it wasn't clear, and now there are products in the field today that implement it both ways. If you take a look at the latest 1588-rev draft, you'll see the current consensus, which is to a) keep the original transparent clock data sets outside of the instance, to allow for domain-independent, but recommend against that implementation in the future, b) add more explicit specs for a transparent clock to be implemented using the instance data sets. I agree that the current hierarchy can be confusing (i.e. transparent clock outside of instance). Nevertheless, it seems to me that 1588-2008 itself is the source of that confusion, in that its transparent clock specs have been interpreted in contradictory ways. Since this YANG is for 1588-2008 only, I'd prefer to leave it somewhat open to interpretation according to 1588-2008 text, rather than bring up the changes coming in 1588-rev. I'd appreciate your thoughts on it. [JF] After some reading of 1588-2008 and 1588-rev, I agree the current structure is the best choice. In 1588-2008, it's clear that Transparent Clocks can (should) operate in multiple domains and that a Transparent Clock operating in multiple domains is regarded as a single Transparent Clock with single data sets. In 1588-rev, this is allowed but deprecated and the preference is "The PTP Node can provide one or more Transparent Clocks (each with an entry in instanceList), and each Transparent Clock supports a single PTP Instance and domain". In this case, the Transparent Clock uses the same data sets as an Ordinary Clock or Boundary Clock. > number-ports description says "number of PTP ports on the device". We > probably need a definition of "device" here. You might think that because > default-ds is part of an instance, the members refer to the instance (e.g. > as clock-identity does). However, in the case of number-ports, it refers > to the device, where a device is the root scope for this model and can > contain more than one instance. Perhaps a root level node for nunber- > ports with default-ds/number-ports being a link to that would help. The 1588-rev draft currently specifies numberPorts as: "The attribute, numberPorts, shall indicate the number of PTP Ports on the PTP Instance." and PTP Port is currently defined as: "A logical access point of a PTP Instance for PTP Communications to the communications network." In other words, 1588's port is a logical entity that serves as the reference point for the 1588 instance. The 1588 standard tries to keep abstracted from "physical" ports (interfaces) as much as possible. In the YANG context, 1588 assumes that ietf-interface provides the list of physical ports (interfaces) in the product. The "underlying-interface" reference is intended to mean "Here's a reference to the physical interface used by this logical PTP port." I'd recommend that we change the number-ports description to "number of PTP ports on the instance". [JF] Yes, for defaultDS that seems the best route for compatibility with 1588-rev but for transparentClockDefaultDS it needs to be "number of PTP ports on the device" or maybe "number of PTP ports on the PTP Node". [JF] I think we need to define what the top level of the hierarchy corresponds to. I think it would be a "PTP Node" in 1588-rev terminology. In 1588-2008, a "PTP Node" seems to be a single Clock but 1588-2008 doesn't really allow for multiple "instances" in the same device. > Should there be a separate list of port-ds for each instance (as shown) or > should there be one list for the device? Given that port-identity > includes clock-identity, it would seem the intention is one list per > device. See above. The device's list is ietf-interfaces. [JF] Addional comment: the title should not refer to 1588v2 but to 1588-2008. The version will still be 2 in 1588-rev. > Regards, > John Fletcher Thanks again John. [JF} Thanks for good discussion. ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
