Internet-Draft IS-IS Packet Timestamping July 2026
Przygienda, et al. Expires 2 January 2027 [Page]
Workgroup:
Network Working Group
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Przygienda
HPE Juniper Networking
C. Barth
HPE Juniper Networking
T. Li
HPE Juniper Networking
J. Halpern
HPE Juniper Networking

IS-IS Packet Timestamping

Abstract

Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. Timestamping can be also used to detect replay attack which are not addressed in IS-IS currently.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 2 January 2027.

▲

Table of Contents

1. Introduction

Many applications in today’s networks rely on safe, reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks and advanced telemetry solutions. If such information is delayed during flooding it can be difficult for those applications to adequately fulfill their intended purpose. This document describes extensions to ISIS allowing it to carry the origination time on each packet. The origination time can be used to aid troubleshooting of large domains and/or by the applications themselves to improve their behavior. Further, the addition of timestamps into IS-IS packets allows to address replay attacks. Thus, IIHs can carry optional timestamps and LSPs will additionally contain in the timestamp the original lifetime used when originating the fragment in question.

As an example, in the case of Traffic Engineered Networks synchronization of the Traffic Engineering Database (TED) enables the compute nodes to adapt to changes in the network state and/or react to network events in a timely manner. If link state information is delayed during the flooding process this can result in an unsynchronized TED and easily lead to service degradation due to substandard re-optimization of network load. More specifically, in RSVP-TE networks, a TE path computed using a specific snapshot of the TED may be rejected during signaling by a transit node because of bandwidth unavailability on a specific link (link bandwidth information in the snapshot of TED used during computation may not be “current”). When the ingress is subsequently notified of this “error” via RSVP signaling, the link in question is avoided in the subsequent path computation and an alternate path is sought. An implementation may use a configurable “hold time” to determine how long this link needs to be avoided. The awareness of the distribution delay statistics can be used by implementations to dynamically adapt an appropriate “hold time” for a given TE link (instead of using a blanket topology-wide configuration). Therefore, the origination time proposed in this document is meant to be used by a compute node(s) or by an operator of Traffic Engineered Network to measure any delays incurred in TED synchronization. The awareness of delays in the distribution of information can be incorporated further into algorithms and network tooling to improve the responsiveness and quality of decisions taken.

As a second application, attackers attempting to replay previously recorded authenticated exchanges between nodes will be deflected by the timestamping mechanism refusing to accept packets failing the required sanity checks. Such a protection relies however on quite closely synchronized clocks which in itself is an chicken-and-egg problem given predominant dependency on mechanisms such as NTP [RFC5905] that rely themselves on forwarding decisions and resulting server connectivity. This document presents a framework where adjacencies can be formed using a roughly accurate time derived from neighbor's precise time before local clock is synchronized fully.

2. Terminology

The following terms are used throughout this document:

Synced Time:
A time source on a router that is derived from an external synchronization mechanism such as NTP [RFC5905], PTP [IEEEstd1588], or a local hardware clock of sufficient quality (e.g. a stratum module). A router operating with Synced Time is considered to have an trustworthy clock for the purposes of this specification.
Proxy Time:
A time approximation on a router that has no Synced Time available. Proxy Time is derived from the timestamp carried in an IIH received from an adjacent neighbor that does possess Synced Time. Proxy Time is inherently less precise than Synced Time as it accumulates the precision error of the source plus any propagation delay on the link. A router operating with Proxy Time MUST reflect this reduced precision in the Precision field of any timestamps it originates. Proxy time MUST NOT be derived from any other packet than neighbor's IIH.
Adjacency Timestamp:
A timestamp carried in the Adjacency Timestamp TLV, used in IIH, SNP, and ASH packets. A node without a usable time source MUST NOT include this TLV.
LSP Timestamp:
A timestamp carried in the LSP Timestamp TLV, used exclusively in LSP fragments. It indicates the point in time the fragment with its current sequence number was generated and optionally carries the originating lifetime. A node without a usable time source MUST NOT include an LSP Timestamp TLV.
Valid Timestamp:
A timestamp that passes the applicable acceptance rules defined in this document. Only a Valid Timestamp may be used for replay protection decisions or Proxy Time derivation.
Invalid Timestamp:
A timestamp that fails the applicable acceptance rules. A packet bearing an Invalid Timestamp is subject to the rejection or hold-down procedures specified in the relevant acceptance section.

3. Timestamp TLVs

This section defines two new, optional TLVs for carrying timestamps in ISIS packets. The two TLVs are distinguished by type code: the Adjacency Timestamp TLV is used in IIH, SNP, CSNP, and ASH packets, while the LSP Timestamp TLV is used exclusively in LSPs and carries the originating lifetime of the fragment. In case of multiple instances of a timestamp TLV in a packet are present, the first one MUST be processed, and any later ones MUST be ignored. The absence of a timestamp TLV signifies that the node does not have a usable time source or does not support timestamping at all.

A node that includes a timestamp TLV MUST ensure that the time value carried is strictly monotonically increasing across successive packets of the same type on the same adjacency (for Adjacency Timestamps) and monotonically for the same LSP fragment (for LSP Timestamps). An implementation MUST NOT send a timestamp with a value equal (and for Adjacency Timestamp also less than) to the last timestamp it sent in the same context, even if the local clock is adjusted backwards. In such cases the implementation MUST hold off sending until the clock advances until it reaches an acceptable value.

Both TLVs share a common time encoding. To save space the timestamp follows semantically the NTP seconds epoch [RFC5905] with the exception of an extra bit in the seconds field to extend the wrap around and carrying approximately 1 millisecond resolution in the fractional part of the timestamp since this is considered sufficient for link-state purposes. The specification follows further guidelines of [RFC8877] as far as possible.

3.1. Adjacency Timestamp TLV

When present in an IIH, SNP, CSNP, or ASH packet, this TLV carries the origination time of the packet. A node without a usable time source MUST NOT include this TLV.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Seconds                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |H|P|   Fraction        | Precs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
  • Type: TBD1
  • Length: 6 (fixed).
  • Seconds: 4 bytes of number of seconds since the NTP [RFC5905] epoch.
  • H(-Bit): 1 bit. Extra high order bit is used to prevent wrap-around in 2036 and pushes it out to 2242. The offset can be constructed in network order as 33rd bit of a 64 bits value and the `Seconds` field OR'ed into the lower order bits of the according value.
  • P(-Bit): 1 bit. Proxy Time indicator. When set to 0, the originator is using Synced Time (as defined in Section 2). When set to 1, the originator is using Proxy Time derived from neighbors' IIH timestamps.
  • Fraction: 10 bits representing the fractional part of the second linearly in units of 2^-10 seconds which is equivalent to approximately 1 millisecond resolution. The value MUST be less than 1024. Any value greater than 1024 MUST be treated as 1024 milliseconds. For example, a fraction value of 3 represents 3/1024 seconds ≈ 2.93 milliseconds and a value of 4 represents 4/1024 seconds ≈ 3.91 milliseconds, demonstrating sub-millisecond step granularity.
  • Precision: 4 bits indicating the maximum possible slip (either in future or past) of the time source used to generate the timestamp as 2^Precision milliseconds. The time source may be a synchronization protocol (such as NTP or PTP), a local hardware clock (such as a stratum 0 receiver), or an internal oscillator. The advertised value MUST reflect the worst-case accuracy achievable by whatever mechanism provides the time. This yields a range from 1 millisecond (value 0) to 32768 milliseconds (value 15). Values resulting in precision worse than 1024 milliseconds MUST be treated as indicating 1024 milliseconds by the receiver. For example, a precision value of 1 indicates 2^1 = 2 milliseconds maximum slip and a value of 2 indicates 2^2 = 4 milliseconds maximum slip. A node that cannot achieve a precision of 1024 milliseconds or better MUST NOT include this TLV.

3.2. LSP Timestamp TLV

When contained in a fragment this TLV indicates the point in time the fragment with the current sequence number has been generated and carries the original lifetime used. A node without a usable time source MUST NOT include this TLV.

For practical purposes, although desirable, timestamping the moment a fragment is flooded would be preferable but beside practical implementation problems this could generate on different interfaces the same fragment with different content which breaks one of the fundamental tenants of link-state protocols. However, an implementation is free to choose to use, e.g. the moment the fragment is queued for flooding first time rather than the time the version is generated.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Seconds                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |H|P|   Fraction        | Precs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Originating Lifetime      |
  +-------------------------------+
Figure 2
  • Type: TBD2
  • Length: Constant of 8 bytes.
  • Seconds, H-Bit, P-Bit, Fraction, Precision: Equivalent to the Adjacency Timestamp TLV (see Section 3.1). A node that cannot achieve a precision of 1024 milliseconds or better MUST NOT include an LSP Timestamp TLV.
  • Originating Lifetime: Indicates the value of the LSP remaining lifetime field when the LSP was originated.

4. Replay Attack Protection

The timestamp field MUST NOT be used if the packet is not authenticated by cryptographic signature or hash. Further considerations are outlined in Section 7.

Packets arriving on the wire SHOULD undergo timestamp sanity checking as soon as possible after being cryptographically authenticated.

The following intervals are used throughout this section:

|P (Proxy Allowance):
When a received timestamp has the P-Bit set (indicating Proxy Time as defined in Section 2), a constant not smaller than 1 second MUST be added to the indicated precision before computing |S or |L. This accounts for the inherent inaccuracy of a clock derived from a neighbor's timestamp rather than a direct synchronization source.
|S (Small Delta):
The interval of (indicated precision in the packet + local precision) multiplied by a small constant + |P if P-Bit is set. Used for validating IIH and SNP timestamps where tight clock accuracy is expected.
|L (Large Delta):
The interval of (indicated precision in the packet + local precision ) multiplied by a larger constant + |P if P-Bit is set. Used for LSP lifetime validation where coarser time resolution applies. For practical purposes |L is likely to span several seconds.

When timestamped, packets can be protected against replay attacks by following acceptance rules.

4.1. IIH, SNP and ASH Acceptance Rules

A node MUST track per adjacency the timestamp value last accepted from the neighbor (the "last-iih-timestamp-seen", "last-snp-timestamp-seen" and "last-ash-timestamp-seen"). All these values are reset when the adjacency transitions to Down state.

The following rules govern acceptance of IIH, SNP and ASH packets with respect to timestamping:

  1. When the adjacency transitions to Down state, last seen timestamps MUST be cleared.
  2. While the adjacency is in Down state and last-iih-timestamp-seen is not set, an IIH without the Adjacency Timestamp TLV is accepted (subject to normal IS-IS authentication). An IIH carrying an Adjacency Timestamp TLV with a timestamp deviating more than |S from the local clock (accounting for |P if the P-Bit is set) MUST be dropped. If the TLV is present and the timestamp is within |S, last-iih-timestamp-seen is set to the received timestamp value. Same rule applies for SNP and ASH packets while using the corresponding variable.
  3. Once last-*-timestamp-seen is set, the corresponding packet received without the Adjacency Timestamp TLV MUST be silently dropped.
  4. Once last-*-timestamp-seen is set, a packet carrying a timestamp less than or equal to last-*-timestamp-seen MUST be silently dropped.
  5. Once last-*-timestamp-seen is set, a packet carrying a timestamp deviating more than |S from the local clock (accounting for |P if the P-Bit is set) MUST be dropped.
  6. A packet carrying a Valid Timestamp (greater than last-*-timestamp-seen and within |S of the local clock and accounting for |P if the P-Bit is set) MUST be accepted and last-*-timestamp-seen MUST be updated to the received value.
  7. If last-iih-timestamp-seen is set and no valid packet has been accepted for the duration of the adjacency hold period, all last-*-timestamp-seen MUST be cleared. This covers the case where a neighbor issued timestamps and then rebooted without a clock, preventing a permanent lockout on that adjacency.

4.1.1. Recovery Considerations

Clearing last-iih-timestamp-seen on transition into Down state is not sufficient to prevent permanent lockout. Consider the following scenario: the adjacency is already in Down state, a valid timestamped IIH arrives from the neighbor (setting last-iih-timestamp-seen), and the neighbor then reboots without support of timestamping. The rebooted neighbor now sends IIHs without the Adjacency Timestamp TLV forever, which are dropped because last-iih-timestamp-seen is set. Since the adjacency is already Down, no hold timer is running to expire it and trigger a fresh Down transition that would clear the value. The adjacency is permanently stuck.

The inactivity reset rule above resolves this: if no valid timestamped packet is accepted within the hold period (regardless of adjacency state), last-*-timestamp-seen variables are cleared unconditionally. This allows the adjacency formation to proceed once the rebooted neighbor resumes sending IIHs (with or without timestamps).

When a node reboots and has lost its clock, the neighbor's last-iih-timestamp-seen still holds the value from before the reboot. The rebooted node cannot send a timestamp higher than this value because it has no time source. Two recovery paths exist:

  • The neighbor's adjacency hold timer expires (no valid IIHs accepted), the adjacency transitions to Down, last-*-timestamp-seen variables are cleared, and the 3-way handshake proceeds normally once the rebooted node acquires a clock.
  • The rebooted node derives Proxy Time from a received IIH on the same or another interface. Since time always advances, the derived Proxy Time will be higher than any previously sent timestamp. The node can then send an IIH with this Proxy Time which will be accepted by the neighbor (it is greater than last-iih-timestamp-seen), allowing the adjacency to recover without waiting for the hold timer.

4.2. LSP Acceptance Rules

The following diagrams illustrate the temporal relationships between originating timestamp, originating lifetime, LSP remaining lifetime, and the acceptance window. We use the term time-in-transit to indicate (originating lifetime - current lsp lifetime).

Normal LSP in transit:

  orig_ts                          now     orig_ts + orig_lifetime
  |                                 |                       |
  |=================================|=======================|
  |<--- elapsed since origination ->|<-- lsp_lifetime ----->|
  |                                 |                       |
  |<-------------- orig_lifetime (from Timestamp TLV) ----->|

  Invariant: orig_ts + orig_lifetime - lsp_lifetime ≈ now
  (the difference is propagation delay + processing)
Figure 3
Acceptance window for (orig_ts + lsp_lifetime):

    |L|                   now                          |L|
    <->                    |                           <->
 REJECT |<============ ACCEPT WINDOW ===============>| REJECT
        |                                            |
        | now - L                            now + L |

  - orig_ts + time-in-transit must fall within [now - |L, now + |L]
  - lsp_lifetime must be ≤ orig_lifetime
  - orig_ts + time-in-transit must be > last accepted timestamp (strictly monotonic)
Figure 4

A node MUST track per LSP fragment the timestamp value last accepted as the "last-fragment-timestamp-seen". This variable is set when a timestamped fragment is accepted and is used to enforce monotonicity across successive instances of the same fragment. If a newer, authenticated fragment (as determined by standard IS-IS fragment comparison rules) arrives without an LSP Timestamp TLV, it MUST be accepted normally and last-fragment-timestamp-seen MUST be cleared for that fragment. This covers the case of a node that was downgraded or lost its clock and is re-originating without timestamps. To prevent a chain of attacks with pre-recorded higher fragment version numbers without timestamps a node MAY decide to issue timestamped newer versions the fragment with a large increment in case of such an attack.

When timestamped, LSPs packets which are not purges and trigger any of the criteria corresponding to Figure 4 acceptance window failure

  1. LSP lifetime larger than originating lifetime
  2. (originating timestamp + time-in-transit) deviating more than |L from current local time
  3. (originating timestamp + time-in-transit) smaller than last-fragment-timestamp-seen (except purges)

SHOULD not be accepted.

The last condition allows specifically for sending multiple versions of a fragment with the same timestamp within a small window of time. Attempts to tighten this further would limit the maximum rates of packet issuance given the timestamp resolution and impose further very strict packet queuing limitations. An attempted replay attack within this window is detectable by arrival of excessive amount of versions of the same fragment within a small window of time and should be tracked and reported.

Purging presents a particularly difficult problem since [RFC6232] mandates the acceptable TLVs in a purge and timestamping is currently not part of those TLVs. Due to this precondition, a change in standard is needed and timestamping on purging can only be originated after upgrade of the whole domain. Additionally, purges carry a lifetime of 0 which defeats the timestamp criteria as defined above and thus need a different set of rules. Purges that trigger any of the criteria

  1. If last-fragment-timestamp-seen is set, a purge without an LSP Timestamp TLV MUST be rejected.
  2. timestamp contains originating lifetime different from 0.
  3. (originating timestamp + |L) is in the future compared to current local time
  4. originating timestamp less or equal to the timestamp seen on the last purge for this LSP
  5. originating timestamp smaller than last-fragment-timestamp-seen

SHOULD be discarded.

5. Proxy Time Derivation

A node that has not yet synchronized a precise internal clock (e.g. has not acquired NTP synchronization) SHOULD derive its Proxy Time from its adjacent neighbors' IIH timestamps using the following algorithm:

  1. Collect periodically the most recent accepted IIH timestamp from each neighbor that has P=0 (Synced Time). Timestamps with P=1 MUST be excluded from Proxy Time derivation to prevent compounding of inaccuracies through successive diffusion of proxy-derived clocks across multiple hops. The acceptance rules for IIHs when using or deriving a proxy time is relaxed to only check for authentication and monotonicity against current proxy time. The proxy time can be used to set a local clock source progressing the proxy time or otherwise must be derived often enough to not trigger sent IIH acceptance rules and resulting discard on the receivers.
  2. Compute the median of these collected timestamps. Using the median rather than the average ensures that an attacker controlling a minority of adjacencies cannot skew the derived Proxy Time. In case of even amount of samples, the value one above the index of 1/2 of the samples must be used to prevent attacks when only 2 adjacencies are established. This thwarts replay attackers controlling fewer than 50% of the eligible adjacencies.
  3. The new Proxy Time is set to: max(current Proxy Time, computed median). When updating the proxy time with new median maximum of its precision and precision of local source SHOULD be used to advertise with the proxy time. Proxy Time MUST never decrease. This monotonicity constraint prevents a skew-down attack in which an adversary replays old (but once-valid) timestamps on a newly-formed adjacency in an attempt to pull the proxy clock backwards.

The combination of median selection and monotonic advancement provides Byzantine-fault-tolerant proxy derivation: an attacker must compromise more than half the eligible adjacencies of a node to influence its Proxy Time at all, and even then cannot move it backwards.

A node operating with Proxy Time MUST set the P-Bit on all timestamps it originates (in IIHs, SNPs, ASHs and LSPs).

6. Operational and Deployment Considerations

A requirement for the correct interpretation of the additions proposed in this document is an infrastructure capable of synchronizing time across devices involved so the timestamps at the various points of interest become comparable. This could be accomplished by utilizing NTP [RFC5905], Precision Time Protocol (PTP) IEEE Std. 1588 [IEEEstd1588] or 802.1AS [IEEEstd8021AS] designed for bridged LANs. The achieved precision is carried in the timestamp of the fragment.

Though the timestamp can be very useful in deriving measurement of behavior in a deployed IS-IS network, e.g. maximum incurred flooding delays between any pair of nodes, it should not be used in any attempts to modify the behavior of protocol behavior itself such as e.g. influencing flooding rates. A single badly synchronized clock could otherwise change the behavior of parts or even the whole network in unpredictable or even detrimental way. Replay protection as defined in Section 4 is an exception.

7. Security Considerations

For practical reasons, the timestamping replay protection defined in this document relies on strictly monotonically increasing timestamps rather than negotiation and repetition of nonces. It preconditions clock synchronization across nodes and hence presents an attack vector where the necessary clock mechanisms can be compromised if vulnerable. The attack windows and vectors are otherwise comparable due to the nature of IGPs which do not rely on lossless communication channels.

The replay protection mechanisms defined in this document rely on the IS-IS three-way handshake as defined in [RFC5303] to prevent an attacker from exploiting adjacency state transitions to reset timestamp tracking state. Accordingly, IS-IS three-way handshake MUST be deployed on all interfaces and cryptographic authentication MUST be enabled before timestamping is used for replay attack protection. If either precondition is not met, IIH timestamps MUST NOT be relied upon for replay protection and SHOULD be used for informational purposes only. LSP replay protection as defined in this document does not depend on the three-way handshake but MUST only be employed when cryptographic authentication of LSPs is enabled.

8. Acknowledgments

TBD

9. Yang Extensions for Fragment Timestamping

9.1. Tree for the YANG Data Model

This document uses the graphical representation of data models per [RFC8340].

The following shows the tree diagram of the module:

      module: ietf-isis-fragment-timestamping

        augment /rt:routing/rt:control-plane-protocols
                  /rt:control-plane-protocol/isis:isis
                  /isis:database/isis:levels/isis:lsp:
          +--rw fragment-origination-time?   yang:date-and-time

9.2. YANG Data Model

The following is the YANG module:

<CODE BEGINS> file "ietf-isis-fragment-timestamping@2026-06-26.yang"

module ietf-isis-fragment-timestamping {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-isis-timestamping";
  prefix isis-fragment-timestamping;

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
       Management (NMDA Version)";
  }
  import ietf-isis {
    prefix isis;
    reference
      "RFC 9130: YANG Data Model for the IS-IS Protocol";
  }

  organization
    "IETF LSR - LSR Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lsr>
     WG List:  <mailto:lsr@ietf.org>

     Author:    Renato Westphal
               <renato@netdef.org>
    ";
  description
    "The YANG module augments the base IS-IS YANG data model with
     operational state related to IS-IS fragment timestamping.

     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.";
  reference
    "RFC XXXX: Optional IS-IS Fragment Timestamping";

  revision 2026-06-26 {
    description
      "Initial Version";
    reference
      "RFC XXXX: Optional IS-IS Fragment Timestamping";
  }

  /* Fragment Timestamp TLV */

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol"
        + "/isis:isis/isis:database/isis:levels/isis:lsp" {
    when "derived-from-or-self(../../../../rt:type,"
        + "'isis:isis')" {
      description
        "This augment ISIS routing protocol when used";
    }
    description
      "This augments IS-IS protocol LSDB with Timestamp TLV.";
    leaf fragment-origination-time {
      type yang:date-and-time;
      description
        "The time at which this LSP fragment with the
         current sequence number was generated.";
    }
  }
}

<CODE ENDS>

10. Normative References

[IEEEstd1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, <https://ieeexplore.ieee.org/document/4579760/>.
[IEEEstd8021AS]
IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE Standard 802.1AS, <https://ieeexplore.ieee.org/document/5741898/>.
[RFC5303]
Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, , <https://www.rfc-editor.org/info/rfc5303>.
[RFC6232]
Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, , <https://www.rfc-editor.org/info/rfc6232>.

11. Informative References

[RFC5905]
Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, , <https://www.rfc-editor.org/info/rfc5905>.
[RFC8340]
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
[RFC8877]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Defining Packet Timestamps", RFC 8877, DOI 10.17487/RFC8877, , <https://www.rfc-editor.org/info/rfc8877>.

Authors' Addresses

Tony Przygienda
HPE Juniper Networking
Colby Barth
HPE Juniper Networking
Tony Li
HPE Juniper Networking
Joel Halpern
HPE Juniper Networking