Comments on proposed PTP model PR #1036
proberts2022 opened this issue · 12 comments
Re; PR #1036
I am new to this process of adding to the openconfig model but I hope review comments are welcomed. I have many years working with PTP and when I look at this model that has been defined for PTP in openconfig, I see differences here compared to the datasets of the IEEE1588 standard itself and also with the draft YANG model as defined by the IEEE1588 working group.
I think the model defined within openconfig should align with the datasets of the standard and avoid as much as possible additional attributes that may be implementation specific.
Here is a list of the items I saw that are different in this model compared to the standard:
Firstly, I am confused as to why the parent-dataset is defined as a list when an individual PTP clock instance can only have one single parent clock at any given time. Within the IEEE1588 standard there is only one instance of a parentDS. I think this level of list hierarchy should be removed.
Secondly, while the model does seem to include support for PTP over IP, it doesn’t include any support for the unicast discovery and unicast message negotiation. Is the intention that only static IP is to be supported for now?
default-dataset:config:domain-profile
- this is defining the profile in use by the clock. I agree this is necessary and the method to set this is not well defined in the standard itself.
default-dataset:config:network-transport
- This seems to be indicating that the PTP clock shall only operate with one transport protocol. This is not a restriction required by the standard itself. In theory, a clock may use PTP over UDP/IPv4 communication with some external PTP clocks while using PTP over UDP/IPv6 with other PTP clocks. The transport layer protocol should be defined for each port in the port-dataset and I believe this is via the configurable underlying-interface. I think this leaf should be removed
default-dataset:config:unicast-multicast
port-dataset:config:unicast-multicast
- I support the concept of this configurable parameter at the port level, but I don’t agree with a global setting for the entire clock. And what are the procedures when a port setting conflicts with the global clock setting. I think the default-dataset leaf should be removed.
default-dataset:config:udp6-scope
- This is not in the standard but does seem useful as is to apply to all UDP/IPv6 multicast messages generated out of this PTP clock, if that transport mode is used. Maybe this should be under the port so it the model allows for it to differ on a given IP communication path
default-dataset:config:master-ip [list]
- It is not clear to me what this list is defining. Is this a list of IP used by PTP clocks external to this clock and if so how is this list to be used? Is this the acceptable master table but using IP addresses? Is it addresses t which this clock should send Signallign messages with Unicast Negotiation TLVs?
@proberts2022 : It is good that you are trying to point out all the discrepancies here, I would ask the @sallylsy why do we even need to come up with new data/YANG model when there is already one defined in the IEEE1588e - which is probably published officially in another few months.
If there are some missing attributes or additional attributes needed apart from what has been defined in IEEE1588e YANG model, then those can be added here as needed. But I would not recommend another new model here conflicting with IEEE1588e.
Thanks for the comments. I am still working on the replay. Here is part of the it.
-
About ParentDS. I checked IEEE 1588-2008 spec. The definition is
parentDS: Attributes describing the parent (the clock to which the ordinary clock synchronizes) and the grandmaster (the clock at the root of the master−slave hierarchy).So I modeled as list, since we may explain both parent and grandmaster here. If the purpose of ParentDS is to describe the ONLY parent of a PTP clock instance, I can remove the list modeling. -
default-ds:config:domain-profile: I will I add a reference for this leaf her. Looks like we should keep this leaf.
-
default-ds:config:udp6-scope. Add some contexts. This field should refer to scop E of multicast addresses ref. The IPv6 multicast address is an identifier for a group of interfaces. As per IEEE model, each PTP port would have one underlying-interface. I think it is definitely ok to move this leaf at port level, just wonder it is still proper to do so with this background.
- The parentDS is a single container that includes some attributes that come from the grandmaster and some different attributes that come form the parent clock. There is no need for more than one instance of this container.
- In the YANG model from IEEE, there is a profile-identifier within the description-port-ds container. While this is not marked "config false" I do not believe this is intended to configure the profile per port. So to me it makes sense to have an attribute to configure the profile in use in a particular PTP instance and adding this attribute to the defaultDS makes sense to me. This is also where the ITU-T decided the configuration should exist (see ITU-T G.8275.1, G.8275.2 and G.8265.1). But perhaps @kam-gopalakrishnan or @RodneyCummings can comment.
- I do not have a response right now. I will need to research more.
My overall comment is that the OpenConfig YANG for PTP should 1) decide whether it supports 1588-2008 or 1588-2019 and state that in the module description, then 2) import the corresponding 1588 YANG (either RFC8575 or P1588e), and 3) augment to add OpenConfig-specific leaves. That would clarify many of these issues.
On the specifics:
-
Per the 1588 standards, parentDS is a single data set (i.e., YANG container) for the current parent (i.e., PTP Port in slave / timeReceiver state). This is reflected in both YANG for 1588.
-
Regarding domain-profile, this looks fine to me (i.e., OpenConfig-specific). In the 1588 WG, there was debate about if/how to provide a configurable profile in the data sets, but unfortunately we couldn't reach consensus (mainly on whether it is instance-level or port-level). In the end the only agreement was to specify a read-only profile at the port level. Personally... I think that was a mistake by the 1588 WG. Nevertheless, it means that each profile (like OpenConfig) must define its own YANG leaf to configure the profile (an oxymoron). That's what OpenConfig is doing (as does O-RAN and ITU-T G.7721.1) with domain-profile.
-
Regarding IP and UDP configuration, both of the 1588 YANG modules have an "underlying-interface" leaf that references into the ietf-interfaces stack. The intent is to place IP/UDP configuration outside the context of 1588 as much as possible.
@RodneyCummings - Can I ask for a little clarification on your point 3.
For the case of using PTP over IP multicast, it makes sense to me that the port shall point to an interfaces used at the IP routing level. And enabling that PTP port means that the clock shall transmit and receive messages on that interface that matches the PTP multicast IP address (either Annex C or D or some configured value)
But for IP unicast, in my implementation, I have a PTP port defined for the unicast communication to an external IP address within a given routing -instance. Would it be correct for the associated local PTP port's underlying-interface to be an IP loopback address interface within the routing instance?
Thanks Kam. And do you agree that this means there might be more than one local PTP port that has the same underlying-interface (the loopback address for PTP over IP communications) if there is more than one external unicast IP address being accessed within the same routing-instance.
Hi Peter.
To be honest... I'm not sure. I reviewed some of the ITU-T specs (since they are the primary use case for unicast negotiation), but I didn't find much clarity there.
My view of unicast is that we have a PTP server (master) running on one logical PTP port with an underlying-interface to one IP unicast interface (stacked on a physical interface). PTP's unicast negotiation protocol is used for clients (slaves) to dynamically come and go (grant/cancel connection to the server). There might be 10 clients one minute, and 1000 clients the next minute.
At any moment in time, is each client represented in the YANG of the server?
I kind of assumed 'No', but I acknowledge that can bring practical problems, because there is a socket (interface) for each client.
If we answer 'Yes' how is that modeled?
I tend to think that 1000 clients would not be represented as 1000 PTP ports. Maybe underlying-interface needs to be a list, so that there are 1000 IP unicast interfaces for one PTP port.
I'm hoping that maybe Kam has implemented this, and he has thoughts?
FYI: If 1588's data sets and YANG need to be enhanced for this, I can help push that through.
@sallylsy - do you need support in the model for unicast IP or will multicast IP suffice initially?
As @RodneyCummings points out, unicast IP often comes with the Unicast Negotiation and Unicast Discovery capability and you haven't included those datasets in your proposed YANG model.
@RodneyCummings I have implemented support in Nokia products for PTP over IP with unicast negotiation but the Nokia proprietary YANG model uses a different design from whats in the IEEE 1588 standard with its unicastNegotiationPortDS and unicastDiscoveryPortDS. Its probably worth a separate discussion from this PR to discuss how those DS are to be used to manage unicast sessions. I will DM you and Kam.
This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.