Thanks John, Minor follow-up marked as [RC] below.
- (discussion of number-ports description) [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. [RC] 1588-2008 wasn't very clear on the node concept. For transparentClockDefaultDS I'd propose "number of PTP ports on the Transparent Clock". That way... however you interpret the 1588-2008 Transparent Clock (node or instance), it works for you. - [JF] Addional comment: the title should not refer to 1588v2 but to 1588-2008. The version will still be 2 in 1588-rev. I agree. 1588-rev will be v2.1, which is also "v2", so use of 1588-2008 avoids confusion. Thanks again, Rodney > -----Original Message----- > From: John Fletcher [mailto:[email protected]] > Sent: Tuesday, September 19, 2017 12:16 PM > To: Rodney Cummings <[email protected]>; [email protected] > Subject: RE: WGLC for draft-ietf-tictoc-1588v2-yang > > 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. > > > > ----------------------------- > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.bbc.co.uk&d=DwIFAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r > =WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=ejTjT1jEhX- > SngMVPjCm1bVRjYLDvvLDU4kpv7c50iY&s=77y1dSLM4cG9ThdZKO8Jxd_UXzZ56up41DfuLxm > Zpcg&e= > 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
