Optional IS-IS Fragment Timestamping and Database FingerprintHPE Juniper Networkingantoni.przygienda@hpe.comHPE Juniper Networkingcolby.barth@hpe.comNetDEFrenato@netdef.org
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.
Additionally, a mechanism is proposed by which the consistency of databases on all routers in
the network can be easily verified and a rough metric of diffusion behavior derived.
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 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 fragment.
The origination time can be used to aid troubleshooting of large domains and/or by the applications themselves
to improve their behavior.
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.
In a similar vein it is important in large networks when they are in a stable state to measure
whether all databases have synchronized properly and derive the delays involved in the propagation
of information across the network. This document proposes an extension to the yang schema that allows
easy access to such information.
This section defines a new, optional TLV that can be present in any fragment. In case of multiple
instances of the TLV in a fragment only the first occurrence MUST be used. The semantics of the TLV is the point in time the
fragment with the current sequence number has been generated. Its absence signifies that such
information is not available due to host of possible issues, one of them lack of clock
with synchronization precise enough.
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.
To save space the timestamp is following semantically NTP seconds epoch with the exception of
an extra bit in the seconds field to extend the wrap around and
carrying only 2^-8 of a second as maximum resolution of the timestamp since this is considered
sufficient for link-state purposes. The specification follows further guidelines of
as far as possible.
Type: TBD1
Length: ...
Seconds: 4 bytes of number of seconds since the NTP 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 `HB` shifted to left without overflow by 32 bits and the `Seconds` field OR'ed into the according value.
Fraction: 8-bits of fraction of the second in units of 2^-8 which is equivalent
to 1/256 of a second or roughly 4 msecs resolution.
Precision: 7 bits indicating the maximum possible slip (either in future or past)
of the clock used to generate the
timestamp (depending on the synchronization
protocol) as 2^Precision where at minimum of the range signifies 2 msec or better precision
and the maximum of the range amounts to 256 msec precision or less. A node that cannot achieve
this minimum precision required SHOULD NOT advertise the fragment timestamp.
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 , Precision Time Protocol (PTP) IEEE Std. 1588
or 802.1AS 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.
To allow for quick validation of database synchronization across all nodes a node can implement
yang extensions providing the checksum of all fragments per level. The extension includes the
time difference from the last fingerprint change which facilitates measurement of flooding behavior
across the network.
Aged out LSPs are excluded from the fingerprint calculation.
Reference checksum algorithm for a fragment is given in . The overall fingerprint
is the XOR of all fragment checksums.
This document uses the graphical representation of data models per .The following shows the tree diagram of the module:The following is the YANG module:
WG List:
Author: Tony Przygienda
Author: Colby Barth
Author: Renato Westphal
";
description
"The YANG module augments the base IS-IS YANG data model with
operational state related to IS-IS fragment timestamping and
LSDB fingerprinting.
Copyright (c) 2025 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-01-14 {
description
"Initial Version";
reference
"RFC XXXX: Optional IS-IS Fragment Timestamping";
}
/* LSDB fingerprint */
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/isis:isis/isis:database/"
+ "isis:levels" {
when "derived-from-or-self(../../../rt:type, 'isis:isis')" {
description
"This augment ISIS routing protocol when used";
}
container fingerprint {
description
"Information about the LSDB fingerprint for this level.";
leaf value {
type uint64;
description
"A 64-bit fingerprint derived from the set of LSPs at this
level.
The fingerprint is computed by XOR-combining a per-LSP
component value for each LSP whose remaining lifetime is
non-zero. The per-LSP component value is derived from the
LSP identifier, the LSP checksum, and the LSP length, as
specified in Appendix A of RFC XXXX.
The fingerprint is intended for detecting potential LSDB
synchronization differences. Different values indicate
different LSDB contents; identical values do not guarantee
equivalence due to possible collisions.";
}
leaf last-update {
type uint32;
units "seconds";
description
"Time elapsed since the fingerprint for this level's LSDB
was last updated.";
}
}
}
/* 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.";
}
}
}
]]>IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control SystemsIEEEIEEE Standard for Local and Metropolitan Area Networks - Timing
and Synchronization for Time-Sensitive Applications in Bridged Local
Area NetworksIEEE
pub(crate) fn lsdb_fingerprint_component(&self) -> u64 {
let mut result: u64 = 0;
let system_id: &[u8] = self.lsp_id.system_id.as_ref();
for i in system_id.iter().chain(&[self.lsp_id.pseudonode]) {
result <<= 8;
result ^= *i as u64;
}
// fragment checksum
result ^= (self.cksum as u64) << 48;
// This is equal to the PDU length advertised by the fragment
result ^= (self.raw.len() as u64) << 32;
result
}
]]>