1. Proposed title of this feature request
PTP Leap Seconds maintenance in connected and disconnected environment

2. What is the nature and description of the request?
Every 6 months the leapseconds file is expiring. See bugs reported in https://issues.redhat.com//browse/OCPBUGS-25939  and https://issues.redhat.com/browse/OCPBUGS-15584

3. Why does the customer need this? (List the business requirements here)

The expiration of the leap second file is fatal for the maintenance of the T-GM synchronization service in production deployments. Basically the synchronization T-GM service stops working as can be showed below:

oc logs -f linuxptp-daemon-wt4qf -c linuxptp-daemon-container | grep ts2phc
gnss[1704209762]:[ts2phc.0.config] ens7f0 gnss_status 3 offset 5 s2
GM[1704209762]:[ts2phc.0.config] ens7f0 T-GM-STATUS s0
ts2phc[1802.831]: [ts2phc.0.config] nmea delay: -38461555556 ns
ts2phc[1802.831]: [ts2phc.0.config] nmea: unable to find utc time in leap second table
ts2phc[1802.831]: [ts2phc.0.config] ens7f0 extts index 0 at 1704209800.225449761 corr 0 src 1704209802.687047061 diff -1774550239

4. Approach is at the high level to 1) detect leap events, 2) update offset with UTC, and 3) announce the UTC in advance)

Detect Leap Events

• Using information captured from the GNSS receiver (e.g., using ubxtool for u-blox GNSS receiver present in Intel Timing Synchronization cards). The PTP operator can consume leap second event by polling the GNSS receiver with the following command:

# ubxtool  -t -p NAV-TIMELS -P 29.20
UBX-NAV-TIMELS:
  iTOW 144529000 version 0 reserved2 0 0 0 srcOfCurrLs 2
  currLs 18 srcOfLsChange 2 lsChange 0 timeToLsEvent -66672511
  dateOfLsGpsWn 2185 dateOfLsGpsDn 7 reserved2 0 0 0
  valid x3

• Consume the information above from GNSS receiver and implement logic in the PTP operator to understand whether a leap second event will really add a leap second or not. Note that a leap second event will ALWAYS happen every 6 months. 

Update offset with UTC

• Option a) Instead of generating a leap file work at kernel layer/ts2phc and set the UTC offset (PHC clock is in TAI format). This does not require to restart ts2phc as the offset is set directly in the kernel. Set the UTC offset directly in kernel. Requires that 1) PTP operator logic has to trigger that change in the setting of the UTC offset in the kernel and 2) changes at kernel/ts2phc layer.

• Option b) Set the new UTC offset via leapfile. It will imply a change of the leap second file:
  • Expiration date of the new file needs to get updated
    • New hash value computed according to FIPS 180-1 
  • Regenerate the leapsecond based on the previous information gathered from ubxtoo and current leap second file (for option a) see an initial prototype here: https://github.com/jnunyez/leap-utils/blob/main/leap_generator.py )
  • This would require to restart the ts2phc process (to be checked) every 6 months (almanac update from ubxtool info) so availability of the service will decrease. 

Announce the potential new UTC offset in advance

For both option a) and option b) the leap second event must be announced 12hrs before the actual leap second occurs to be compliant with T-GM behavior. This implies that getting it when it happens is not sufficient. Getting when it happens can be obtained from ubxtool command.