Re: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

[Rodney Cummings <[e-mail]>]

Hi John and Yuanlong,

I could be wrong, but I think there is some upcoming work in ITU-T that plans to use 1588's optional unicast negotiation feature. That being said, that feature was enhanced in 1588-rev, so ITU-T may be planning to use those enhancements (not limited to 1588-2008).

Regardless of what ITU-T is planning, for optional features that exist in 1588-2008 as a data set, it is reasonable to request those features in this YANG project.

Nevertheless, my preference is to avoid those optional features in this YANG project. As Yuanlong said:
> As we envisioned, this module should be the basic 1588 YANG model
The authors of this I-D are hoping to keep this YANG focused on the core 1588 data sets only, and avoid optional features. This presumably helps us to reach RFC sooner. A profile or product that needs the optional features can create their own YANG augment for those features.

Does this mean that we will never have 1588-wide (i.e. profile-independent) YANG for the optional features?
	No... at least not in my opinion. We are simply deferring that work.

In the IEEE 1588 working group, there is tentative consensus that as soon as 1588-rev publishes (hopefully 1Q2018), the 1588 working group will create an amendment PAR for 1588-rev YANG. That 1588-rev YANG will include all data sets, including all optional features. My tentative hope is that the 1588-rev YANG will be a revision of this 1588-2008 YANG project. That is one of the reasons I was hoping to avoid optional features in this 1588-2008 YANG, because the more this 1588-2008 YANG focuses on "basic 1588" only, the more likely we can revise it in the future to support the "optional 1588" features.

John... I'd appreciate your thoughts on this.

Rodney


> -----Original Message-----
> From: Jiangyuanlong [mailto:[e-mail]]
> Sent: Friday, September 22, 2017 8:47 PM
> To: John Fletcher ; Rodney Cummings ; [e-mail]
> Subject: RE: WGLC for draft-ietf-tictoc-1588v2-yang
> 
> Hi John and Rodney,
> 
> Regarding "optional features", I would like to chime in:
> As we envisioned, this module should be the basic 1588 YANG model, and
> transport profile, bridge profile and router profile modules can import
> this module and add their new optional features respectively.
> However, it says in A.9 of G.8275.1 (2016):" Other optional features of
> [IEEE 1588] are not used in this version of the profile. These include
> unicast message negotiation...". thus, it is clear that ITU-T PTP profile
> don't need to support these optional features.
> Therefore, we'd better exclude unnecessary optional features and make sure
> the module only include the most fundamental features.
> 
> B.R.,
> Yuanlong
> 
> -----Original Message-----
> From: TICTOC [mailto:[e-mail]] On Behalf Of John Fletcher
> Sent: Wednesday, September 20, 2017 1:16 AM
> To: Rodney Cummings; [e-mail]
> Subject: Re: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
> 
> Responses inline below prefixed [JF]
> ________________________________________
> From: Rodney Cummings [[e-mail]]
> Sent: 18 September 2017 20:08
> To: John Fletcher; [e-mail]
> 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=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r
> =WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=q08sdix-
> IT4WEtYgvpO5Vc1bUOFvO-
> iWzjpVV7ymSVM&s=n8KVe2hEurlWYuTojP8rcGy5y15wDqyrXhF24XeQGFg&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
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_tictoc&d=DwIFgQ&c=I_0YwoKy7z5LMTVdyO6YCi
> E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=q08s
> dix-IT4WEtYgvpO5Vc1bUOFvO-iWzjpVV7ymSVM&s=BbZVGr-
> smJLMoDi8n42rSt3QtircWOMV-E3lTmaXjNA&e=