rfc9681v2.txt		rfc9681.txt
	skipping to change at line 127 ¶		skipping to change at line 127 ¶
	today (33 LSPs per second), it would take more than 30 seconds simply		today (33 LSPs per second), it would take more than 30 seconds simply
	to send the updated LSPs to a given neighbor. Depending on the		to send the updated LSPs to a given neighbor. Depending on the
	diameter of the network, achieving a consistent LSDB on all nodes in		diameter of the network, achieving a consistent LSDB on all nodes in
	the network could easily take a minute or more.		the network could easily take a minute or more.
	Therefore, increasing the LSP flooding rate becomes an essential		Therefore, increasing the LSP flooding rate becomes an essential
	element of supporting greater network scale.		element of supporting greater network scale.
	Improving the LSP flooding rate is complementary to protocol		Improving the LSP flooding rate is complementary to protocol
	extensions that reduce LSP flooding traffic by reducing the flooding		extensions that reduce LSP flooding traffic by reducing the flooding
	topology such as Mesh Groups [RFC2973] or Dynamic Flooding		topology such as Mesh Groups [RFC2973] or Dynamic Flooding [RFC9667].
	[DYNAMIC-FLOODING]. Reduction of the flooding topology does not		Reduction of the flooding topology does not alter the number of LSPs
	alter the number of LSPs required to be exchanged between two nodes,		required to be exchanged between two nodes, so increasing the overall
	so increasing the overall flooding speed is still beneficial when		flooding speed is still beneficial when such extensions are in use.
	such extensions are in use. It is also possible that the flooding		It is also possible that the flooding topology can be reduced in ways
	topology can be reduced in ways that prefer the use of neighbors that		that prefer the use of neighbors that support improved flooding
	support improved flooding performance.		performance.
	With the goal of supporting faster flooding, this document introduces		With the goal of supporting faster flooding, this document introduces
	the signaling of additional flooding related parameters (Section 4),		the signaling of additional flooding related parameters (Section 4),
	specifies some performance improvements on the receiver (Section 5)		specifies some performance improvements on the receiver (Section 5)
	and introduces the use of flow and/or congestion control (Section 6).		and introduces the use of flow and/or congestion control (Section 6).
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at line 156 ¶		skipping to change at line 156 ¶
	capitals, as shown here.		capitals, as shown here.
	3. Historical Behavior		3. Historical Behavior
	The base specification for IS-IS [ISO10589] was first published in		The base specification for IS-IS [ISO10589] was first published in
	1992 and updated in 2002. The update made no changes in regards to		1992 and updated in 2002. The update made no changes in regards to
	suggested timer values. Convergence targets at the time were on the		suggested timer values. Convergence targets at the time were on the
	order of seconds, and the specified timer values reflect that. Here		order of seconds, and the specified timer values reflect that. Here
	are some examples:		are some examples:
	minimumLSPGenerationInterval - This is the minimum time interval		| minimumLSPGenerationInterval - This is the minimum time interval
	between generation of Link State PDUs. A source Intermediate		| between generation of Link State PDUs. A source Intermediate
	system shall wait at least this long before regenerating one of		| system shall wait at least this long before regenerating one of
	its own Link State PDUs.		| its own Link State PDUs. [...]
			|
	The recommended value is 30 seconds.		| A reasonable value is 30 s.
			|
	minimumLSPTransmissionInterval - This is the amount of time an		| minimumLSPTransmissionInterval - This is the amount of time an
	Intermediate system shall wait before further propagating another		| Intermediate system shall wait before further propagating
	Link State PDU from the same source system.		| another Link State PDU from the same source system. [...]
			|
	The recommended value is 5 seconds.		| A reasonable value is 5 s.
			|
	partialSNPInterval - This is the amount of time between periodic		| partialSNPInterval - This is the amount of time between periodic
	action for transmission of Partial Sequence Number PDUs. It shall		| action for transmission of Partial Sequence Number PDUs. It
	be less than minimumLSPTransmissionInterval.		| shall be less than minimumLSPTransmissionInterval. [...]
			|
	The recommended value is 2 seconds.		| A reasonable value is 2 s.
	Most relevant to a discussion of the LSP flooding rate is the		Most relevant to a discussion of the LSP flooding rate is the
	recommended interval between the transmission of two different LSPs		recommended interval between the transmission of two different LSPs
	on a given interface.		on a given interface.
	For broadcast interfaces, [ISO10589] defined:		For broadcast interfaces, [ISO10589] states:
	| minimumBroadcastLSPTransmissionInterval - the minimum interval		| minimumBroadcastLSPTransmissionInterval indicates the minimum
	| between PDU arrivals which can be processed by the slowest		| interval between PDU arrivals which can be processed by the
	| Intermediate System on the LAN.		| slowest Intermediate System on the LAN.
	The default value was defined as 33 milliseconds. It is permitted to		The default value was defined as 33 milliseconds. It is permitted to
	send multiple LSPs back to back as a burst, but this was limited to		send multiple LSPs back to back as a burst, but this was limited to
	10 LSPs in a one-second period.		10 LSPs in a one-second period.
	Although this value was specific to LAN interfaces, this has commonly		Although this value was specific to LAN interfaces, this has commonly
	been applied by implementations to all interfaces though that was not		been applied by implementations to all interfaces though that was not
	the original intent of the base specification. In fact,		the original intent of the base specification. In fact,
	Section 12.1.2.4.3 of [ISO10589] states:		Section 12.1.2.4.3 of [ISO10589] states:
	skipping to change at line 645 ¶		skipping to change at line 645 ¶
	The congestion signal can take various forms. The more reactive the		The congestion signal can take various forms. The more reactive the
	congestion signals, the fewer LSPs will be lost due to congestion.		congestion signals, the fewer LSPs will be lost due to congestion.
	However, overly aggressive congestion signals will cause a sender to		However, overly aggressive congestion signals will cause a sender to
	keep a very low sending rate even without actual congestion on the		keep a very low sending rate even without actual congestion on the
	path.		path.
	Two practical signals are given below.		Two practical signals are given below.
	1. Delay: When receiving acknowledgments, a sender estimates the		1. Delay: When receiving acknowledgments, a sender estimates the
	acknowledgment time of the receiver. Based on this estimation,		acknowledgment time of the receiver. Based on this estimation,
	it can infer that a packet was lost and that congestion is on the		it can infer that a packet was lost and that the path is
	path.		congested.
	There can be a timer per LSP, but this can become costly for		There can be a timer per LSP, but this can become costly for
	implementations. It is possible to use only a single timer t1		implementations. It is possible to use only a single timer t1
	for all LSPs: during t1, sent LSPs are recorded in a list list_1.		for all LSPs: during t1, sent LSPs are recorded in a list list_1.
	Once the RTT is over, list_1 is kept and another list, list_2, is		Once the RTT is over, list_1 is kept and another list, list_2, is
	used to store the next LSPs. LSPs are removed from the lists		used to store the next LSPs. LSPs are removed from the lists
	when acked. At the end of the second t1 period, every LSP in		when acked. At the end of the second t1 period, every LSP in
	list_1 should have been acked, so list_1 is checked to be empty.		list_1 should have been acked, so list_1 is checked to be empty.
	list_1 can then be reused for the next RTT.		list_1 can then be reused for the next RTT.
	skipping to change at line 846 ¶		skipping to change at line 846 ¶
	6.2.4.2. Dynamic Values		6.2.4.2. Dynamic Values
	To reflect the relative change of load on the receiver, the values		To reflect the relative change of load on the receiver, the values
	may be updated dynamically by improving the values when the receiver		may be updated dynamically by improving the values when the receiver
	load is getting lower and by degrading the values when the receiver		load is getting lower and by degrading the values when the receiver
	load is getting higher. For example, if LSPs are regularly dropped,		load is getting higher. For example, if LSPs are regularly dropped,
	or if the queue regularly comes close to being filled, then the		or if the queue regularly comes close to being filled, then the
	values may be too high. On the other hand, if the queue is barely		values may be too high. On the other hand, if the queue is barely
	used (by IS-IS), then the values may be too low.		used (by IS-IS), then the values may be too low.
	Alternatively, the values may be specified as absolute values that		Alternatively, the values may be computed to reflect the relevant
	reflect the relevant average hardware resources, e.g., the amount of		average hardware resources, e.g., the amount of buffer space used by
	buffer space used by incoming LSPs. In this case, care must be taken		incoming LSPs. In this case, care must be taken when choosing the
	when choosing the parameters influencing the values in order to avoid		parameters influencing the values in order to avoid undesirable or
	undesirable or unstable feedback loops. For example, it would be		unstable feedback loops. For example, it would be undesirable to use
	undesirable to use a formula that depends on an active measurement of		a formula that depends on an active measurement of the instantaneous
	the instantaneous CPU load to modify the values advertised in the		CPU load to modify the values advertised in the Flooding Parameters
	Flooding Parameters TLV. This could introduce feedback into the IGP		TLV. This could introduce feedback into the IGP flooding process
	flooding process that could produce unexpected behavior.		that could produce unexpected behavior.
	6.2.5. Operational Considerations		6.2.5. Operational Considerations
	As discussed in Section 4.7, the solution is more effective on point-		As discussed in Section 4.7, the solution is more effective on point-
	to-point adjacencies. Hence, a broadcast interface (e.g., Ethernet)		to-point adjacencies. Hence, a broadcast interface (e.g., Ethernet)
	only shared by two IS-IS neighbors should be configured as point-to-		only shared by two IS-IS neighbors should be configured as point-to-
	point in order to have more effective flooding.		point in order to have more effective flooding.
	6.3. Transmitter-Based Congestion Control Approach		6.3. Transmitter-Based Congestion Control Approach
	skipping to change at line 1099 ¶		skipping to change at line 1099 ¶
	"Computing TCP's Retransmission Timer", RFC 6298,		"Computing TCP's Retransmission Timer", RFC 6298,
	DOI 10.17487/RFC6298, June 2011,		DOI 10.17487/RFC6298, June 2011,
	<https://www.rfc-editor.org/info/rfc6298>.		<https://www.rfc-editor.org/info/rfc6298>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[DYNAMIC-FLOODING]
	Li, T., Psenak, P., Chen, H., Jalil, L., and S. Dontula,
	"Dynamic Flooding on Dense Graphs", Work in Progress,
	Internet-Draft, draft-ietf-lsr-dynamic-flooding-18, 5
	April 2024, <https://datatracker.ietf.org/doc/html/draft-
	ietf-lsr-dynamic-flooding-18>.
	[RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",		[RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",
	RFC 2973, DOI 10.17487/RFC2973, October 2000,		RFC 2973, DOI 10.17487/RFC2973, October 2000,
	<https://www.rfc-editor.org/info/rfc2973>.		<https://www.rfc-editor.org/info/rfc2973>.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,		Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
	<https://www.rfc-editor.org/info/rfc5681>.		<https://www.rfc-editor.org/info/rfc5681>.
	[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection		[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,		and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
	May 2021, <https://www.rfc-editor.org/info/rfc9002>.		May 2021, <https://www.rfc-editor.org/info/rfc9002>.
	[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",		[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
	STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,		STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
	<https://www.rfc-editor.org/info/rfc9293>.		<https://www.rfc-editor.org/info/rfc9293>.
			[RFC9667] Li, T., Ed., Psenak, P., Ed., Chen, H., Jalil, L., and S.
			Dontula, "Dynamic Flooding on Dense Graphs", RFC 9667,
			DOI 10.17487/RFC9667, October 2024,
			<https://www.rfc-editor.org/info/rfc9667>.
	Acknowledgments		Acknowledgments
	The authors would like to thank Henk Smit, Sarah Chen, Xuesong Geng,		The authors would like to thank Henk Smit, Sarah Chen, Xuesong Geng,
	Pierre Francois, Hannes Gredler, Acee Lindem, Mirja Kuehlewind,		Pierre Francois, Hannes Gredler, Acee Lindem, Mirja Kühlewind,
	Zaheduzzaman Sarker, and John Scudder for their reviews, comments,		Zaheduzzaman Sarker, and John Scudder for their reviews, comments,
	and suggestions.		and suggestions.
	The authors would like to thank David Jacquet, Sarah Chen, and		The authors would like to thank David Jacquet, Sarah Chen, and
	Qiangzhou Gao for the tests performed on commercial implementations		Qiangzhou Gao for the tests performed on commercial implementations
	and for their identification of some limiting factors.		and for their identification of some limiting factors.
	Contributors		Contributors
	The following people gave substantial contributions to the content of		The following people gave substantial contributions to the content of
End of changes. 9 change blocks.
	48 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.48.