Feat(eos_designs): Only enable PTP on certain uplinks

[geckigek]

Edit by @ClausHolbechArista:

Enhancement summary

Provide a mechanism to control which uplinks are enabled for PTP. Could b either a list of uplink interfaces or maybe an algorithm like modulus on the node ID.

---

Original ask:

Enhancement summary

When defining uplink ports (uplink_switches) between spine and leafs in the Arista AVD role eos_designs, it would be desirable to assign a port profile to the ports from the ordered lists in order to specify whether PTP should be enabled or not via the port profile.

Which component of AVD is impacted

eos_designs

Use case example

The use case would be to define links where no ptp should be implemented. The reason for that is that we would like to seperate PTP in a media fabirc between A (red) and B (blue) spine and leaf architecture and would like to achieve that with loading port profiles. But we want to have a redundant connection from spine A to leaf a and b to be able to have a overlay netzwork in the media fabric.

Describe the solution you would like

The solution would look like the following:

      uplink_interfaces:
         - Ethernet55/1
         - Ethernet56/1

      uplink_switch_interfaces:
        - Ethernet3/47/1
        - Ethernet3/47/1

      uplink_switch_profiles
        - Profile_PTP-enabled
        - Profile_PTP-not-enabled

Describe alternatives you have considered

No response

Additional context

No response

Contributing Guide

• [X] I agree to follow this project's Code of Conduct

[ClausHolbechArista]

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?

[geckigek]

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

[ClausHolbechArista]

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.

[geckigek]

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

[geckigek]

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.

[SRF-hilberad]

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.

[github-actions[bot]]

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

[sugetha24]

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.