rfc9681v3.txt   rfc9681.txt 
skipping to change at line 16 skipping to change at line 16
T. Li T. Li
Juniper Networks, Inc. Juniper Networks, Inc.
G. Solignac G. Solignac
M. Karasek M. Karasek
Cisco Systems Cisco Systems
G. Van de Velde G. Van de Velde
Nokia Nokia
T. Przygienda T. Przygienda
Juniper Juniper
October 2024 November 2024
IS-IS Fast Flooding IS-IS Fast Flooding
Abstract Abstract
Current Link State PDU flooding rates are much slower than what Current Link State PDU flooding rates are much slower than what
modern networks can support. The use of IS-IS at larger scale modern networks can support. The use of IS-IS at larger scale
requires faster flooding rates to achieve desired convergence goals. requires faster flooding rates to achieve desired convergence goals.
This document discusses the need for faster flooding, the issues This document discusses the need for faster flooding, the issues
around faster flooding, and some example approaches to achieve faster around faster flooding, and some example approaches to achieve faster
skipping to change at line 399 skipping to change at line 399
available processing power of the node, the number of adjacencies, available processing power of the node, the number of adjacencies,
and the requirement to synchronize the LSDB more quickly. 200 ms and the requirement to synchronize the LSDB more quickly. 200 ms
seems to be a reasonable value. seems to be a reasonable value.
In addition to the timer-based partialSNPInterval, the receiver In addition to the timer-based partialSNPInterval, the receiver
SHOULD keep track of the number of unacknowledged LSPs per circuit SHOULD keep track of the number of unacknowledged LSPs per circuit
and level. When this number exceeds a preset threshold of LSPs per and level. When this number exceeds a preset threshold of LSPs per
PSNP (LPP), the receiver SHOULD immediately send a PSNP without PSNP (LPP), the receiver SHOULD immediately send a PSNP without
waiting for the PSNP timer to expire. In the case of a burst of waiting for the PSNP timer to expire. In the case of a burst of
LSPs, this allows more frequent PSNPs, giving faster feedback to the LSPs, this allows more frequent PSNPs, giving faster feedback to the
sender. Outside of the burst case, the usual time-based PSNP sender. Outside of the burst case, the usual timer-based PSNP
approach comes into effect. approach comes into effect.
The smaller the LPP is, the faster the feedback to the sender and The smaller the LPP is, the faster the feedback to the sender and
possibly the higher the rate if the rate is limited by the end-to-end possibly the higher the rate if the rate is limited by the end-to-end
RTT (link RTT + time to acknowledge). This may result in an increase RTT (link RTT + time to acknowledge). This may result in an increase
in the number of PSNPs sent, which may increase CPU and IO load on in the number of PSNPs sent, which may increase CPU and IO load on
both the sender and receiver. The LPP should be less than or equal both the sender and receiver. The LPP should be less than or equal
to 90 as this is the maximum number of LSPs that can be acknowledged to 90 as this is the maximum number of LSPs that can be acknowledged
in a PSNP at common MTU sizes; hence, waiting longer would not reduce in a PSNP at common MTU sizes; hence, waiting longer would not reduce
the number of PSNPs sent but would delay the acknowledgments. LPP the number of PSNPs sent but would delay the acknowledgments. LPP
should not be chosen too high as the congestion control starts with a should not be chosen too high as the congestion control starts with a
congestion window of LPP + 1. Based on experimental evidence, 15 congestion window of LPP + 1. Based on experimental evidence, 15
unacknowledged LSPs is a good value, assuming that the Receive Window unacknowledged LSPs is a good value, assuming that the Receive Window
is at least 30. More frequent PSNPs give the transmitter more is at least 30. More frequent PSNPs give the transmitter more
feedback on receiver progress, allowing the transmitter to continue feedback on receiver progress, allowing the transmitter to continue
transmitting while not burdening the receiver with undue overhead. transmitting while not burdening the receiver with undue overhead.
By deploying both the time-based and the threshold-based PSNP By deploying both the timer-based and the threshold-based PSNP
approaches, the receiver can be adaptive to both LSP bursts and approaches, the receiver can be adaptive to both LSP bursts and
infrequent LSP updates. infrequent LSP updates.
As PSNPs also consume link bandwidth, packet-queue space, and As PSNPs also consume link bandwidth, packet-queue space, and
protocol-processing time on receipt, the increased sending of PSNPs protocol-processing time on receipt, the increased sending of PSNPs
should be taken into account when considering the rate at which LSPs should be taken into account when considering the rate at which LSPs
can be sent on an interface. can be sent on an interface.
5.2. Packet Prioritization on Receive 5.2. Packet Prioritization on Receive
There are three classes of PDUs sent by IS-IS: There are three classes of PDUs sent by IS-IS:
* Hellos * Hellos
* LSPs * LSPs
* Complete Sequence Number PDUs (CSNPs) and PSNPs * SNPs (Complete Sequence Number PDUs (CSNPs) and PSNPs)
Implementations today may prioritize the reception of Hellos over Implementations today may prioritize the reception of Hellos over
LSPs and Sequence Number PDUs (SNPs) in order to prevent a burst of LSPs and Sequence Number PDUs (SNPs) in order to prevent a burst of
LSP updates from triggering an adjacency timeout, which in turn would LSP updates from triggering an adjacency timeout, which in turn would
require additional LSPs to be updated. require additional LSPs to be updated.
CSNPs and PSNPs serve to trigger or acknowledge the transmission of CSNPs and PSNPs serve to trigger or acknowledge the transmission of
specified LSPs. On a point-to-point link, PSNPs acknowledge the specified LSPs. On a point-to-point link, PSNPs acknowledge the
receipt of one or more LSPs. For this reason, [ISO10589] specifies a receipt of one or more LSPs. For this reason, [ISO10589] specifies a
delay (partialSNPInterval) before sending a PSNP so that the number delay (partialSNPInterval) before sending a PSNP so that the number
skipping to change at line 511 skipping to change at line 511
A flow control mechanism creates a control loop between a single A flow control mechanism creates a control loop between a single
transmitter and a single receiver. This section uses a mechanism transmitter and a single receiver. This section uses a mechanism
similar to the TCP receive window to allow the receiver to govern the similar to the TCP receive window to allow the receiver to govern the
amount of data sent by the sender. This receive window (RWIN) amount of data sent by the sender. This receive window (RWIN)
indicates an allowed number of LSPs that the sender may transmit indicates an allowed number of LSPs that the sender may transmit
before waiting for an acknowledgment. The size of the receive before waiting for an acknowledgment. The size of the receive
window, in units of LSPs, is initialized with the value advertised by window, in units of LSPs, is initialized with the value advertised by
the receiver in the Receive Window sub-TLV. If no value is the receiver in the Receive Window sub-TLV. If no value is
advertised, the transmitter should initialize RWIN with its locally advertised, the transmitter should initialize RWIN with its locally
configured value for the associated neighbor. configured value for this receiver.
When the transmitter sends a set of LSPs to the receiver, it When the transmitter sends a set of LSPs to the receiver, it
subtracts the number of LSPs sent from RWIN. If the transmitter subtracts the number of LSPs sent from RWIN. If the transmitter
receives a PSNP, then RWIN is incremented for each acknowledged LSP. receives a PSNP, then RWIN is incremented for each acknowledged LSP.
The transmitter must ensure that the value of RWIN never goes The transmitter must ensure that the value of RWIN never goes
negative. negative.
The RWIN value is of importance when the RTT is the limiting factor The RWIN value is of importance when the RTT is the limiting factor
for the throughput. In this case, the optimal size is the desired for the throughput. In this case, the optimal size is the desired
LSP rate multiplied by the RTT. The RTT is the addition of the link LSP rate multiplied by the RTT. The RTT is the addition of the link
RTT plus the time taken by the receiver to acknowledge the first RTT plus the time taken by the receiver to acknowledge the first
received LSP in its PSNP. The values 50 or 100 may be reasonable received LSP in its PSNP. The values 50 or 100 may be reasonable
default numbers for RTT. As an example, an RWIN of 100 requires a default numbers for RWIN. As an example, an RWIN of 100 requires a
control plane input buffer of 150 kbytes per neighbor (assuming an control plane input buffer of 150 kbytes per neighbor (assuming an
IS-IS MTU of 1500 octets) and limits the throughput to 10000 LSPs per IS-IS MTU of 1500 octets) and limits the throughput to 10000 LSPs per
second and per neighbor for a link RTT of 10 ms. With the same RWIN, second and per neighbor for a link RTT of 10 ms. With the same RWIN,
the throughput limitation is 2000 LSPs per second when the RTT is 50 the throughput limitation is 2000 LSPs per second when the RTT is 50
ms. That's the maximum throughput assuming no other limitations such ms. That's the maximum throughput assuming no other limitations such
as CPU limitations. as CPU limitations.
Equally, RTT is of importance for the performance. That is why the Equally, RTT is of importance for the performance. That is why the
performance improvements on the receiver specified in Section 5 are performance improvements on the receiver specified in Section 5 are
important to achieve good throughput. If the receiver does not important to achieve good throughput. If the receiver does not
skipping to change at line 879 skipping to change at line 879
6.3.1. Router Architecture Discussion 6.3.1. Router Architecture Discussion
Note that the following description is an abstraction; implementation Note that the following description is an abstraction; implementation
details vary. details vary.
Existing router architectures may utilize multiple input queues. On Existing router architectures may utilize multiple input queues. On
a given line card, IS-IS PDUs from multiple interfaces may be placed a given line card, IS-IS PDUs from multiple interfaces may be placed
in a rate-limited input queue. This queue may be dedicated to IS-IS in a rate-limited input queue. This queue may be dedicated to IS-IS
PDUs or may be shared with other routing related packets. PDUs or may be shared with other routing related packets.
The input queue may then pass IS-IS PDUs to a "punt queue," which is The input queue may then pass IS-IS PDUs to a "punt queue", which is
used to pass PDUs from the data plane to the control plane. The punt used to pass PDUs from the data plane to the control plane. The punt
queue typically also has controls on its size and the rate at which queue typically also has controls on its size and the rate at which
packets will be punted. packets will be punted.
An input queue in the control plane may then be used to assemble PDUs An input queue in the control plane may then be used to assemble PDUs
from multiple line cards, separate the IS-IS PDUs from other types of from multiple line cards, separate the IS-IS PDUs from other types of
packets, and place the IS-IS PDUs in an input queue dedicated to the packets, and place the IS-IS PDUs in an input queue dedicated to the
IS-IS protocol. IS-IS protocol.
The IS-IS input queue then separates the IS-IS PDUs and directs them The IS-IS input queue then separates the IS-IS PDUs and directs them
 End of changes. 7 change blocks. 
7 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48.