Hi, I don't think we will implement this. If I understand your usecase correctly, you need to enable PTP on only one uplink per spine. Is it always the first one or are you distributing them? I would prefer to implement some option under the ptp settings on the node, to tell which uplink to use. We could even do some modulus on the node ID with the number of uplinks and decide, so you don't have to maintain the distribution?

Hi, thanks for your answer. :) Yeah your understanding is correct. We use the eos_design role to define your media fabirc with an overlay network. For the overlay we do have connections from SpineA to LeafA and LeafB and from SpineB to LeafA and LeafB. The PTP implementation includes two grand master clocks (A and B). They are separatly connected to spineA and spineB. But then the "normal" l3ls ptp implementation distributes PTP to LeafA and LeafB from SpineA and vise versa from spineB. Thats what we like to avoid. So that PTP from grandmaster A is only distributed via spineA and leafA and PTP from grandmaster B is only distributed via spineB and leafB.

So yeah an option within a list wich is corresponding to the list of the pulink_interfaces would be great oder the modulus idea of yours sound also nice :)

Best regards

Stefan

From our best practice document I understood that the time domain should be contiguous, having a link between A and B sides on the spines only for PTP. Please check with your account team to make sure the design you are building is following the best practices. Meanwhile I will update the title and text of this issue to reflect the ask of controlling which uplinks to use for PTP.

Hi Claus,

sorry for the late reply. We are planning to implement a underlay network to do the media streaming and PTP. But we are also planning to do a overlay network for managing media devices. With this combination we are having PTP between A (Red) and B (Blue) leaf and spines, because we are implementing a L3LS architecture. But I will get in contact with the account team to get in touch regarding this topic.

Best regards

Stefan

We heard from a other radio station, that they implemented a air gapped PTP design between A and B network. They have better performance regarding the switch over from grandmaster A to B and back.

I have been asked to contribute to this discussion.
Our Media-over-IP Fabric runs with the exact setup mentioned here.
The rationale for having two active ptp grandmasters running in a single Spine-Leaf Fabric is only valid when SMPTE ST2022-7 is in mind. Our critical media devices are connected to two Leafs (A and B or Amber and Blue), where we send them the same RTP content but in different multicast/UDP streams. We have discovered that by having different grandmasters active on A and B, there will be a much faster changeover between Link A and B in the event of an issue with the PTP on A. This also results in less drift away from our clock, which in turn provides a much more stable stream output.
This setup therefore provides greater resilience in an ST2022-7 setup.

This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed

Proposed Data Model:

  node_groups:
    - group: leaf1
      nodes:
        - name: leaf1a
          ptp:
            enabled: true
	    uplinks: [...] # restrict ptp config on these uplinks only

This would enable ptp only on the uplinks described in uplinks.

Hi Sugetha,

the solution you provided sounds great. Thank you for providing a solution :)

Best regards

Stefan