Diff: rfc9681xml2.original.xml

	rfc9681xml2.original.xml	rfc9681.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="2"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="exp" docName="draft-ietf-lsr-isis-fast-flooding-11" ipr="trust200
	902">
	<front>
	<title abbrev="IS-IS Fast Flooding">IS-IS Fast Flooding</title>
	<author fullname="Bruno Decraene" initials="B." surname="Decraene
	">
	<organization>Orange</organization>
	<address>
	<email>bruno.decraene@orange.com</email>
	</address>
	</author>

	<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
	<organization>Cisco Systems</organization>

	<address>
	<postal>
	<street>821 Alder Drive</street>

	<city>Milpitas</city>

	<code>95035</code>

	<region>CA</region>

	<country>USA</country>
	</postal>

	<email>ginsberg@cisco.com</email>
	</address>
	</author>

	<author fullname="Tony Li" initials="T." surname="Li">
	<organization>Juniper Networks, Inc.</organization>
	<address>
	<phone/>
	<email>tony.li@tony.li</email>
	</address>
	</author>

	<author fullname="Guillaume Solignac" initials="G." surname="Soli
	gnac">

	<address>
	<email>gsoligna@protonmail.com</email>
	</address>
	</author>

	<author fullname="Marek Karasek" initials="M" surname="Karasek">
	<organization>Cisco Systems</organization>

	<address>
	<postal>
	<street>Pujmanove 1753/10a, Prague 4 - Nu
	sle</street>

	<city>Prague</city>

	<region/>

	<code>10 14000</code>

	<country>Czech Republic</country>
	</postal>

	<phone/>

	<facsimile/>

	<email>mkarasek@cisco.com</email>

	<uri/>
	</address>
	</author>

	<author initials="G." surname="Van de Velde" fullname="Gunter Van
	de Velde">
	<organization>Nokia</organization>
	<address>
	<postal>
	<street>Copernicuslaan 50</street>
	<city>Antwerp</city>
	<code>2018</code>
	<country>Belgium</country>
	</postal>
	<email>gunter.van_de_velde@nokia.com</email>
	</address>
	</author>

	<author fullname="Tony Przygienda" initials="T" surname="Przygien
	da">
	<organization>Juniper</organization>

	<address>
	<postal>
	<street>1137 Innovation Way</street>

	<city>Sunnyvale</city>

	<region>Ca</region>

	<code/>


	<country>USA</country>	<!DOCTYPE rfc [
	</postal>	<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>


	<phone/>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie tf-lsr-isis-fast-flooding-11" number="9681" ipr="trust200902" obsoletes="" updat es="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="2" consens us="true" symRefs="true" sortRefs="true" version="3">


	<facsimile/>	<front>
		<title abbrev="IS-IS Fast Flooding">IS-IS Fast Flooding</title>
		<seriesInfo name="RFC" value="9681"/>
		<author fullname="Bruno Decraene" initials="B." surname="Decraene">
		<organization>Orange</organization>
		<address>
		<email>bruno.decraene@orange.com</email>
		</address>
		</author>
		<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<street>821 Alder Drive</street>
		<city>Milpitas</city>
		<code>95035</code>
		<region>CA</region>
		<country>United States of America</country>
		</postal>
		<email>ginsberg@cisco.com</email>
		</address>
		</author>
		<author fullname="Tony Li" initials="T." surname="Li">
		<organization>Juniper Networks, Inc.</organization>
		<address>
		<email>tony.li@tony.li</email>
		</address>
		</author>
		<author fullname="Guillaume Solignac" initials="G." surname="Solignac">
		<address>
		<email>gsoligna@protonmail.com</email>
		</address>
		</author>
		<author fullname="Marek Karasek" initials="M" surname="Karasek">
		<organization>Cisco Systems</organization>
		<address>
		<postal>
		<street>Pujmanove 1753/10a, Prague 4 - Nusle</street>
		<city>Prague</city>
		<code>10 14000</code>
		<country>Czech Republic</country>
		</postal>
		<email>mkarasek@cisco.com</email>
		</address>
		</author>
		<author initials="G." surname="Van de Velde" fullname="Gunter Van de Velde">
		<organization>Nokia</organization>
		<address>
		<postal>
		<street>Copernicuslaan 50</street>
		<city>Antwerp</city>
		<code>2018</code>
		<country>Belgium</country>
		</postal>
		<email>gunter.van_de_velde@nokia.com</email>
		</address>
		</author>


	<email>prz@juniper.net</email>	<author fullname="Tony Przygienda" initials="T" surname="Przygienda">
		<organization>Juniper</organization>
		<address>
		<postal>
		<street>1137 Innovation Way</street>
		<city>Sunnyvale</city>
		<region>CA</region>
		<country>United States of America</country>
		</postal>
		<email>prz@juniper.net</email>
		</address>
		</author>
		<date month="October" year="2024"/>
		<area>RTG</area>
		<workgroup>lsr</workgroup>


	<uri/>	<!-- [rfced] Please insert any keywords (beyond those that appear in
	</address>	the title) for use on https://www.rfc-editor.org/search. -->
	</author>


	<date year="2024"/>	<keyword>example</keyword>
	<abstract>
	<t>
	Current Link State Protocol Data Unit (PDU)
	flooding rates are much slower than what modern
	networks can support. The use of IS-IS at larger
	scale requires faster flooding rates to achieve
	desired convergence goals. This document
	discusses the need for faster flooding, the issues
	around faster flooding, and some example
	approaches to achieve faster flooding. It also
	defines protocol extensions relevant to faster
	flooding.
	</t>
	</abstract>
	</front>
	<middle>


	<section title="Introduction">	<abstract>
	<t>Link state IGPs such as Intermediate-System-to-Interme	<t>Current Link State PDU flooding rates are much
	diate-System	slower than what modern networks can support. The use of IS-IS at
	(IS-IS) depend upon having consistent Link State Databases (LSDB) on all	larger scale requires faster flooding rates to achieve desired
		convergence goals. This document discusses the need for faster
		flooding, the issues around faster flooding, and some example approaches
		to achieve faster flooding. It also defines protocol extensions relevant
		to faster flooding.
		</t>
		</abstract>
		</front>
		<middle>
		<section numbered="true" toc="default">
		<name>Introduction</name>
		<t>Link state IGPs such as Intermediate System to Intermediate System
		(IS-IS) depend upon having consistent Link State Databases (LSDBs) on all
	Intermediate Systems (ISs) in the network in order to provide correct	Intermediate Systems (ISs) in the network in order to provide correct
	forwarding of data packets. When topology changes occur, new/updated	forwarding of data packets. When topology changes occur, new/updated
	Link State PDUs (LSPs) are propagated network-wide. The speed of	Link State PDUs (LSPs) are propagated network-wide. The speed of
	propagation is a key contributor to convergence time.</t>	propagation is a key contributor to convergence time.</t>

		<t>IS-IS base specification <xref target="ISO10589" format="default"/>
		does not use flow or congestion control but static flooding rates.
		Historically, flooding rates have been conservative -- on the order of
		tens of LSPs per second. This is the result of guidance in the base
		specification and early deployments when the CPU and interface speeds
		were much slower and the area scale was much smaller than they are
		today.</t>
		<t>As IS-IS is deployed in greater scale both in the number of nodes in
		an area and in the number of neighbors per node, the impact of the
		historic flooding rates becomes more significant. Consider the bring-up
		or failure of a node with 1000 neighbors. This will result in a minimum
		of 1000 LSP updates. At typical LSP flooding rates used 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 diameter of the
		network, achieving a consistent LSDB on all nodes in the network could
		easily take a minute or more.</t>
		<t>Therefore, increasing the LSP flooding rate becomes an essential
		element of supporting greater network scale.</t>
		<t> Improving the LSP flooding rate is complementary to protocol
		extensions that reduce LSP flooding traffic by reducing the flooding
		topology such as Mesh Groups <xref target="RFC2973" format="default"/>
		or Dynamic Flooding <xref target="I-D.ietf-lsr-dynamic-flooding"
		format="default"/>. Reduction of the flooding topology does not alter
		the number of LSPs required to be exchanged between two nodes, so
		increasing the overall flooding speed is still beneficial when such
		extensions are in use. It is also possible that the flooding topology
		can be reduced in ways that prefer the use of neighbors that support
		improved flooding performance.</t>
		<t>With the goal of supporting faster flooding, this document introduces t
		he signaling
		of additional flooding related parameters (<xref target="FloodingTLV" for
		mat="default"/>), specifies some
		performance improvements on the receiver (<xref target="Receiver" format=
		"default"/>)
		and introduces the use of flow and/or congestion control (<xref target="C
		ontrol" format="default"/>).</t>
		</section>
		<section anchor="Language" numbered="true" toc="default">
		<name>Requirements Language</name>
		<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
		</section>
		<section anchor="HISTORY" numbered="true" toc="default">
		<name>Historical Behavior</name>
		<t>The base specification for IS-IS <xref target="ISO10589"
		format="default"/> was first published in 1992 and updated in 2002. The
		update made no changes in regards to suggested timer values. Convergence
		targets at the time were on the order of seconds, and the specified timer
		values reflect that. Here are some examples:</t>


	<t>IS-IS base specification <xref target="ISO10589"/> doe	<dl spacing="normal" newline="false">
	s not use flow	<dt>minimumLSPGenerationInterval:</dt> <dd><t>This is the minimum time
	or congestion control but static flooding rates.	interval between generation of Link State PDUs. A source Intermediate
	Historically, flooding rates have been conservative - on	system shall wait at least this long before regenerating one of its
	the order of	own Link State PDUs.</t>
	10s of LSPs/second. This is the result of guidance in the base specificati	<t>The recommended value is 30 seconds.</t></dd>
	on
	and early deployments when the CPU and
	interface speeds were much slower and the area scale
	much smaller than they are today.</t>

	<t>As IS-IS is deployed in greater scale both in the numb
	er of nodes in an
	area and in the number of neighbors per node, the impact of the historic
	flooding rates becomes more significant. Consider the bringup or failure
	of a node with 1000 neighbors. This will result in a minimum of 1000 LSP
	updates. At typical LSP flooding rates used today
	(33 LSPs/second), it would take more than 30 seconds simply to send the up
	dated
	LSPs to a given neighbor. Depending on the diameter of the network,
	achieving a consistent LSDB on all nodes in the network could easily
	take a minute or more.</t>

	<t>Increasing the LSP flooding rate therefore becomes an
	essential element
	of supporting greater network scale.</t>


	<t> Improving the LSP flooding rate is complementary	<dt>minimumLSPTransmissionInterval:</dt> <dd><t>This is the amount of
	to protocol	time an Intermediate system shall wait before further propagating
	extensions that reduce LSP flooding traffic by reducing the	another Link State PDU from the same source system.</t>
	flooding topology such as Mesh Groups <xref target="RFC2973"/>	<t>The recommended value is 5 seconds.</t></dd>
	or Dynamic Flooding <xref target="I-D.ietf-lsr-dynamic-flooding"/>
	. Reduction of the
	flooding topology does not alter the number of LSPs required
	to be exchanged between two nodes, so increasing the overall
	flooding speed is still beneficial when such extensions are in
	use. It is also possible that the flooding topology can be
	reduced in ways that prefer the use of neighbors that support
	improved flooding performance.</t>


	<t>With the goal of supporting faster flooding, this document introduces the	<dt>partialSNPInterval:</dt> <dd><t>This is the amount of time between pe
	signaling	riodic action for
	of additional flooding related parameters <xref target="FloodingTLV"/>, s	transmission of Partial Sequence Number PDUs. It shall be less than
	pecifies some	minimumLSPTransmissionInterval.</t>
	performance improvements on the receiver <xref target="Receiver"/>	<t>The recommended value is 2 seconds.</t></dd>
	and introduces the use of flow and/or congestion control <xref target="Co	</dl>
	ntrol"/>.</t>


	</section>	<t>Most relevant to a discussion of the LSP flooding rate is the
		recommended interval between the transmission of two different LSPs on
		a given interface.</t>


	<section anchor="Language" title="Requirements Language">	<t>For broadcast interfaces, <xref target="ISO10589"
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	format="default"/> defined:</t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref
	target="RFC8174"/> when, and only when, they appear in all capitals,
	as shown here.</t>
	</section>


	<section anchor="HISTORY" title="Historical Behavior">	<blockquote><t>minimumBroadcastLSPTransmissionInterval - the minimum
	<t>The base specification for IS-IS <xref target="ISO10589"/>	interval between PDU arrivals which can be processed by the slowest
	was first	Intermediate System on the LAN.</t></blockquote>
	published in 1992 and updated in 2002. The update made no changes in
	regards to suggested timer values. Convergence targets at the time were
	on the order of seconds and the specified timer values reflect that.
	Here are some examples:</t>


	<t>	<t>
	<figure>	The default value was defined as 33 milliseconds.
	<artwork><![CDATA[minimumLSPGenerationInterval -	It is permitted to send multiple LSPs back to back
	This is the minimum time interval	as a burst, but this was limited to 10 LSPs in a one-second
	between generation of Link State PDUs. A source Intermediate	period.
	system shall wait at least this long before re-generating one	</t>
	of its own Link State PDUs.]]></artwork>
	</figure>
	</t>
	<t>
	The recommended value is 30 seconds.
	</t>
	<t>
	<figure>
	<artwork><![CDATA[minimumLSPTransmissionInterval
	- This is the amount of time an
	Intermediate system shall wait before further propagating
	another Link State PDU from the same source system.]]></artwork>
	</figure>
	</t>
	<t>
	The recommended value is 5 seconds.
	</t>
	<t>
	<figure>
	<artwork><![CDATA[partialSNPInterval - This is th
	e amount of time between periodic
	action for transmission of Partial Sequence Number PDUs.
	It shall be less than minimumLSPTransmissionInterval.]]></artwork>
	</figure>
	</t>
	<t>
	The recommended value is 2 seconds.
	</t>
	<t>Most relevant to a discussion of the LSP flooding rate is the
	recommended
	interval between the transmission of two different LSPs on a given
	interface.</t>


	<t>For broadcast interfaces, <xref target="ISO10589"/>	<t>
	defined:</t>	<!-- [rfced] Is the following referring to a section from [ISO10589]? If so,
		we recommend updating the text to cite the document.


	<t>	Current:
	<figure>	In fact, Section 12.1.2.4.3 states...
	<artwork><![CDATA[ minimumBroadcastLSPTransmissi
	onInterval - the minimum interval
	between PDU arrivals which can be processed by the slowest
	Intermediate System on the LAN.]]></artwork>
	</figure>
	</t>


	<t>	Perhaps:
	The default value was defined as 33 milliseconds.	In fact, Section 12.1.2.4.3 of [ISO10589] states...
	It is permitted to send multiple LSPs "back-to-back"	-->
	as a burst, but this was limited to 10 LSPs in a one second	Although this value was specific to LAN interfaces, this has
	period.	commonly been applied by implementations to all interfaces though
	</t>	that was not the original intent of the base specification. In
	<t>	fact, Section 12.1.2.4.3 states:</t>
	Although this value was specific to LAN interfaces, this has commonly
	been applied by implementations to all interfaces though that was not
	the original intent of the base specification. In fact Section
	12.1.2.4.3 states:</t>


	<t>	<blockquote><t>On point-to-point links the peak rate of arrival is
	<figure>	limited only by the speed of the data link and the other traffic flowing
	<artwork><![CDATA[ On point-to-point links the p	on that link.</t></blockquote>
	eak rate of arrival is limited only
	by the speed of the data link and the other traffic flowing on
	that link.]]></artwork>
	</figure>
	</t>


	<t>Although modern implementations have not strictly adhered to t	<t>Although modern implementations have not strictly adhered to the
	he 33	33-millisecond interval, it is commonplace for implementations to limit
	millisecond interval, it is commonplace for implementations to limit
	the flooding rate to the same order of magnitude: tens of milliseconds,	the flooding rate to the same order of magnitude: tens of milliseconds,

	and not the single digits or fractions of milliseconds that are needed	and not the single digits or fractions of milliseconds that are needed
	today.</t>	today.</t>
		<t>In the past 20 years, significant work on achieving faster
	<t>In the past 20 years, significant work on achieving faster
	convergence, more specifically sub-second convergence, has resulted in	convergence, more specifically sub-second convergence, has resulted in
	implementations modifying a number of the above timers in order to	implementations modifying a number of the above timers in order to
	support faster signaling of topology changes. For example,	support faster signaling of topology changes. For example,
	minimumLSPGenerationInterval has been modified to support millisecond	minimumLSPGenerationInterval has been modified to support millisecond
	intervals, often with a backoff algorithm applied to prevent LSP	intervals, often with a backoff algorithm applied to prevent LSP
	generation storms in the event of rapid successive oscillations.</t>	generation storms in the event of rapid successive oscillations.</t>

		<t>However, the flooding rate has not been fundamentally altered.</t>
		</section>
		<section anchor="FloodingTLV" numbered="true" toc="default">
		<name>Flooding Parameters TLV</name>
		<t>This document defines a new Type-Length-Value (TLV) tuple called the
		"Flooding Parameters TLV" that may be included in IS-IS Hellos (IIHs)
		or Partial Sequence Number PDUs (PSNPs). It allows IS-IS implementations
		to advertise flooding-related parameters and capabilities that may be
		used by the peer to support faster flooding.</t>


	<t>However, the flooding rate has not been fundamentally altered.	<dl newline="false" spacing="compact">
	</t>	<dt>Type:</dt> <dd>21</dd>
	</section>	<dt>Length:</dt> <dd>variable; the size in octets of the Value field</dd>
		<dt>Value:</dt> <dd>one or more sub-TLVs</dd>
	<section anchor="FloodingTLV" title="Flooding Parameters TLV">	</dl>
	<t>	<t>Several sub-TLVs are defined in this document. The support of any sub-T
	This document defines a new Type-Length-Value	LV is <bcp14>OPTIONAL</bcp14>.</t>
	tuple (TLV) called the "Flooding Parameters TLV"	<t> For a given IS-IS adjacency, the Flooding Parameters TLV does not
	that may be included in IS to IS Hellos (IIH) or	need to be advertised in each IIH or PSNP. An IS uses the latest
	Partial Sequence Number PDUs (PSNPs). It allows	received value for each parameter until a new value is advertised by the
	IS-IS implementations to advertise flooding-related	peer. However, as IIHs and PSNPs are not reliably exchanged and may
	parameters and capabilities which may be	never be received, parameters <bcp14>SHOULD</bcp14> be sent even if
	used by the peer to support faster flooding.	there is no change in value since the last transmission. For a
	</t>	parameter that has never been advertised, an IS uses its local default
	<t>Type: 21</t>	value. That value <bcp14>SHOULD</bcp14> be configurable on a per-node
	<t>Length: variable, the size in octets of the Value field</t>	basis and <bcp14>MAY</bcp14> be configurable on a per-interface basis.
		</t>
	<t>Value: One or more sub-TLVs</t>	<section anchor="LSPBurstSize" numbered="true" toc="default">
	<t>Several sub-TLVs are defined in this document. The support of	<name>LSP Burst Size Sub-TLV</name>
	any sub-TLV is OPTIONAL.</t>	<t>The LSP Burst Size sub-TLV advertises the maximum number of LSPs that
		the node can receive without an intervening delay between LSP transmissions.</t
		>
		<dl newline="false" spacing="compact">
		<dt>Type:</dt> <dd>1</dd>
		<dt>Length:</dt> <dd>4 octets</dd>
		<dt>Value:</dt> <dd>number of LSPs that can be received back to back</
		dd>
		</dl>
		</section>
		<section anchor="InterfaceLSPTransmissionInterval" numbered="true" toc="de
		fault">
		<name>LSP Transmission Interval Sub-TLV</name>
		<t>The LSP Transmission Interval sub-TLV advertises the minimum interval
		, in microseconds, between LSPs arrivals that can be sustained on this receiving
		interface.</t>
		<dl newline="false" spacing="compact">
		<dt>Type:</dt> <dd>2</dd>
		<dt>Length:</dt> <dd>4 octets</dd>
		<dt>Value:</dt> <dd>minimum interval, in microseconds, between two
		consecutive LSPs received after LSP Burst Size LSPs have been
		received</dd>
		</dl>
		<t>The LSP Transmission Interval is an advertisement of the receiver's s
		ustainable LSP reception rate. This rate may be safely used by a sender that doe
		s not support the flow control or congestion algorithm. It may also be used as t
		he minimal safe rate by flow control or congestion algorithms in unexpected case
		s, e.g., when the receiver is not acknowledging LSPs anymore. </t>
		</section>
		<section anchor="LPP" numbered="true" toc="default">
		<name>LSPs per PSNP Sub-TLV</name>
		<t>The LSP per PSNP (LPP) sub-TLV advertises the number of received LSPs
		that triggers the immediate sending of a PSNP to acknowledge them.</t>
		<dl newline="false" spacing="compact">
		<dt>Type:</dt> <dd>3</dd>
		<dt>Length:</dt> <dd>2 octets</dd>
		<dt>Value:</dt> <dd>number of LSPs acknowledged per PSNP</dd>
		</dl>
		<t>A node advertising this sub-TLV with a value for LPP <bcp14>MUST</bcp
		14> send a PSNP once LPP LSPs have been received and need to be acknowledged.</t
		>
		</section>
		<section anchor="Flags" numbered="true" toc="default">
		<name>Flags Sub-TLV</name>
		<t>The sub-TLV Flags advertises a set of flags.</t>
		<dl newline="false" spacing="compact">
		<dt>Type:</dt> <dd>4</dd>
		<dt>Length:</dt> <dd>Indicates the length in octets (1-8) of the Value
		field. The length <bcp14>SHOULD</bcp14> be the minimum required to send all bit
		s that are set.</dd>
		<dt>Value:</dt> <dd><t>list of flags</t>
		<artwork align="left" name="" type="" alt=""><![CDATA[
		0 1 2 3 4 5 6 7 ...
		+-+-+-+-+-+-+-+-+...
		\|O\| ...
		+-+-+-+-+-+-+-+-+...]]></artwork>
		</dd></dl>


	<t>	<t>An LSP receiver sets the O-flag (Ordered
	For a given IS-IS adjacency, the Flooding	acknowledgment) to indicate to the LSP sender that
	Parameters TLV does not need to be advertised	it will acknowledge the LSPs in the order as received. A PSNP
	in each IIH or PSNP. An IS uses the latest	acknowledging N LSPs is acknowledging the N oldest LSPs received. The
	received value for each parameter until a new	order inside the PSNP is meaningless. If the sender keeps track of the
	value is advertised by the peer. However, as	order of LSPs sent, this indication allows for fast detection of the
	IIHs and PSNPs are not reliably exchanged, and	loss of an LSP. This <bcp14>MUST NOT</bcp14> be used to alter the
	may never be received, parameters SHOULD be	retransmission timer for any LSP. This <bcp14>MAY</bcp14> be used to
	sent even if there is no change in value since	trigger a congestion signal.</t>
	the last transmission. For a parameter that	</section>
	has never been advertised, an IS uses	<section anchor="partialSNPI" numbered="true" toc="default">
	its local default value. That value SHOULD be	<name>Partial SNP Interval Sub-TLV</name>
	configurable on a per-node basis and MAY be	<!--[rfced] "Partial SNP" vs. "PNSP"
	configurable on a per-interface basis.	Regarding the Partial SNP Interval sub-TLV, we note that "PNSP" is
	</t>	used in another description in the same registry ("LSPs per PSNP").
	<section anchor="LSPBurstSize" title="LSP Burst Size sub-TLV">	Would you like to leave the name as is, or change it to use "PSNP"?
	<t>The LSP Burst Size sub-TLV advertises the maximum numb
	er of LSPs that the node can receive without an intervening delay between LSP tr
	ansmissions.</t>
	<t>Type: 1</t>
	<t>Length: 4 octets</t>
	<t>Value: number of LSPs that can be received back-to-bac
	k.</t>
	</section>
	<section anchor="InterfaceLSPTransmissionInterval" title="LSP Tra
	nsmission Interval sub-TLV">
	<t>The LSP Transmission Interval sub-TLV advertises the m
	inimum interval, in micro-seconds, between LSPs arrivals which can be sustained
	on this receiving interface.</t>
	<t>Type: 2</t>
	<t>Length: 4 octets</t>
	<t>Value: minimum interval, in micro-seconds, between two
	consecutive LSPs received after LSP Burst Size LSPs have been received</t>
	<t>The LSP Transmission Interval is an advertisement of t
	he receiver's sustainable LSP reception rate. This rate may be safely used by a
	sender which do not support the flow control or congestion algorithm. It may als
	o be used as the minimal safe rate by flow control or congestion algorithms in u
	nexpected cases, e.g., when the receiver is not acknowledging LSPs anymore. </t>


	</section>	Current: 4.5. Partial SNP Interval Sub-TLV
	<section anchor="LPP" title="LSPs Per PSNP sub-TLV">	Perhaps: 4.5. PSNP Interval Sub-TLV
	<t>The LSP per PSNP (LPP) sub-TLV advertises the number o
	f received LSPs that triggers the immediate sending of a PSNP to acknowledge the
	m.</t>
	<t>Type: 3</t>
	<t>Length: 2 octets</t>
	<t>Value: number of LSPs acknowledged per PSNP</t>
	<t>A node advertising this sub-TLV with a value for LPP M
	UST send a PSNP once LPP LSPs have been received and need to be acknowledged.</t
	>
	</section>
	<section anchor="Flags" title="Flags sub-TLV">
	<t>The sub-TLV Flags advertises a set of flags.</t>
	<t>Type: 4</t>
	<t>Length: Indicates the length in octets (1-8) of the Va
	lue field. The length SHOULD be the minimum required to send all bits that are s
	et.</t>
	<t>Value: List of flags.</t>
	<t>
	<figure>
	<artwork align="left">
	0 1 2 3 4 5 6 7 ...
	+-+-+-+-+-+-+-+-+...
	\|O\| ...
	+-+-+-+-+-+-+-+-+...</artwork>
	</figure>
	</t>
	<t>An LSP receiver sets the O-flag to indicate to the LSP
	sender that
	it will acknowledge the LSPs in the order as received. A
	PSNP acknowledging N LSPs is acknowledging the
	N oldest LSPs received. The order inside the
	PSNP is meaningless. If the sender keeps track
	of the order of LSPs sent, this indication
	allows a fast detection of the loss of an
	LSP. This MUST NOT be used to alter the
	retransmission timer for any LSP. This MAY be used to
	trigger a congestion signal.</t>
	</section>


	<section anchor="partialSNPI" title="Partial SNP Interval sub-TLV">	If the latter, we will ask IANA to update the registry
		(https://www.iana.org/assignments/isis-tlv-codepoints/
		isis-tlv-codepoints.xhtml#isis-sub-tlvs-for-flooding-parameters-tlv) accordingly
		.
		-->
	<t>The Partial SNP Interval sub-TLV advertises the amount of	<t>The Partial SNP Interval sub-TLV advertises the amount of

	time in milliseconds between periodic action for transmission of Partial	time in milliseconds between periodic action for transmission of PSNPs. T
	Sequence Number PDUs. This time will trigger the sending of a PSNP	his time will trigger the sending of a PSNP
	even if the number of unacknowledged LSPs received on a given	even if the number of unacknowledged LSPs received on a given

	interface does not exceed LPP (<xref target="LPP"/>). The time is	interface does not exceed LPP (<xref target="LPP" format="default"/>). T he time is
	measured from the reception of the first unacknowledged LSP.</t>	measured from the reception of the first unacknowledged LSP.</t>

		<dl newline="false" spacing="compact">
	<t>Type: 5</t>	<dt>Type:</dt> <dd>5</dd>
		<dt>Length:</dt> <dd>2 octets</dd>
	<t>Length: 2 octets</t>	<dt>Value:</dt> <dd>partialSNPInterval in milliseconds</dd>
		</dl>
	<t>Value: partialSNPInterval in milliseconds</t>	<t>A node advertising this sub-TLV <bcp14>SHOULD</bcp14> send a PSNP at
		least once
	<t>A node advertising this sub-TLV SHOULD send a PSNP at least once
	per Partial SNP Interval if one or more unacknowledged LSPs have been	per Partial SNP Interval if one or more unacknowledged LSPs have been
	received on a given interface.</t>	received on a given interface.</t>
	</section>	</section>

		<section anchor="RWIN" numbered="true" toc="default">
		<name>Receive Window Sub-TLV</name>
		<t>The Receive Window (RWIN) sub-TLV advertises the maximum number of un
		acknowledged LSPs that the node can receive for a given adjacency.</t>
		<dl newline="false" spacing="compact">
		<dt>Type:</dt> <dd>6</dd>
		<dt>Length:</dt> <dd>2 octets</dd>
		<dt>Value:</dt> <dd>maximum number of unacknowledged LSPs</dd>
		</dl>
		</section>
		<section anchor="TLVoperationLAN" numbered="true" toc="default">
		<name>Operation on a LAN Interface</name>
		<t>On a LAN interface, all LSPs are link-level multicasts. Each LSP sent
		will be received by all ISs on the LAN, and each IS will receive LSPs from all
		transmitters. In this section, we clarify how the flooding parameters should be
		interpreted in the context of a LAN.</t>
		<t>An LSP receiver on a LAN will communicate its desired flooding parame
		ters using a single Flooding Parameters TLV, which will be received by all LSP t
		ransmitters. The flooding parameters sent by the LSP receiver <bcp14>MUST</bcp14
		> be understood as instructions from the LSP receiver to each LSP transmitter ab
		out the desired maximum transmit characteristics of each transmitter. The receiv
		er is aware that there are multiple transmitters that can send LSPs to the recei
		ver LAN interface. The receiver might want to take that into account by advertis
		ing more conservative values, e.g., a higher LSP Transmission Interval. When the
		transmitters receive the LSP Transmission Interval value advertised by an LSP r
		eceiver, the transmitters should rate-limit LSPs according to the advertised flo
		oding parameters. They should not apply any further interpretation to the floodi
		ng parameters advertised by the receiver.</t>
		<t>A given LSP transmitter will receive multiple flooding parameter adve
		rtisements from different receivers that may include different flooding paramete
		r values. A given transmitter <bcp14>SHOULD</bcp14> use the most conservative va
		lue on a per-parameter basis. For example, if the transmitter receives multiple
		LSP Burst Size values, it should use the smallest value.</t>
		<t>The Designated Intermediate System (DIS) plays a special role in the
		operation of flooding on the LAN as it is responsible for responding to PSNPs se
		nt on the LAN circuit that are used to request LSPs that the sender of the PSNP
		does not have. If the DIS does not support faster flooding, this will impact the
		maximum flooding speed that could occur on a LAN. Use of LAN priority to prefer
		a node that supports faster flooding in the DIS election may be useful.</t>


	<section anchor="RWIN" title="Receive Window sub-TLV">	<aside><t>Note: The focus of work used to develop the example algorithms
	<t>The Receive Window (RWIN) sub-TLV advertises the maxim	discussed later in this document focused on operation over point-to-point inter
	um number of unacknowledged LSPs that the node can receive for a given adjacency	faces. A full discussion of how best to do faster flooding on a LAN interface is
	.</t>	therefore out of scope for this document.</t></aside>
	<t>Type: 6</t>	</section>
	<t>Length: 2 octets</t>	</section>
	<t>Value: maximum number of unacknowledged LSPs</t>	<section anchor="Receiver" numbered="true" toc="default">
	</section>	<name>Performance Improvement on the Receiver</name>
		<t>This section defines two behaviors that <bcp14>SHOULD</bcp14> be implem
	<section anchor="TLVoperationLAN" title="Operation on a LAN inter	ented on the receiver.</t>
	face">	<section anchor="LSPACKRate" numbered="true" toc="default">
	<t>On a LAN interface, all LSPs are link-level multicasts	<name>Rate of LSP Acknowledgments</name>
	. Each LSP sent will be received by all ISs on the LAN and each IS will receive	<t>On point-to-point networks, PSNPs provide acknowledgments for
	LSPs from all transmitters. In this section, we clarify how the flooding paramet	received LSPs. <xref target="ISO10589" format="default"/> suggests
	ers should be interpreted in the context of a LAN.</t>	using some delay when sending PSNPs. This provides some optimization
	<t>An LSP receiver on a LAN will communicate its desired	as multiple LSPs can be acknowledged by a single PSNP.</t>
	flooding parameters using a single Flooding Parameters TLV, which will be receiv	<t>Faster LSP flooding benefits from a faster feedback loop. This
	ed by all LSP transmitters. The flooding parameters sent by the LSP receiver MUS	requires a reduction in the delay in sending PSNPs.
	T be understood as instructions from the LSP receiver to each LSP transmitter ab	</t>
	out the desired maximum transmit characteristics of each transmitter. The receiv	<t>For the generation of PSNPs, the receiver <bcp14>SHOULD</bcp14> use
	er is aware that there are multiple transmitters that can send LSPs to the recei	a partialSNPInterval smaller than the one defined in <xref
	ver LAN interface. The receiver might want to take that into account by advertis	target="ISO10589" format="default"/>. The choice of this lower value
	ing more conservative values, e.g., a higher LSP Transmission Interval. When the	is a local choice. It may depend on the available processing power of
	transmitters receive the LSP Transmission Interval value advertised by an LSP r	the node, the number of adjacencies, and the requirement to
	eceiver, the transmitters should rate-limit LSPs according to the advertised flo	synchronize the LSDB more quickly. 200 ms seems to be a reasonable
	oding parameters. They should not apply any further interpretation to the floodi	value.</t>
	ng parameters advertised by the receiver.</t>	<t>In addition to the timer-based partialSNPInterval, the receiver
	<t>A given LSP transmitter will receive multiple flooding	<bcp14>SHOULD</bcp14> keep track of the number of unacknowledged LSPs
	parameter advertisements from different receivers that may include different fl	per circuit and level. When this number exceeds a preset threshold of
	ooding parameter values. A given transmitter SHOULD use the most convervative va	LSPs per PSNP (LPP), the receiver <bcp14>SHOULD</bcp14> immediately
	lue on a per-parameter basis. For example, if the transmitter receives multiple	send a PSNP without waiting for the PSNP timer to expire. In the case
	LSP Burst Size values, it should use the smallest value.</t>	of a burst of LSPs, this allows more frequent PSNPs, giving faster
	<t>The Designated Intermediate System (DIS) plays a speci	feedback to the sender. Outside of the burst case, the usual
	al role in the operation of flooding on the LAN as it is responsible for respond	time-based PSNP approach comes into effect.</t>
	ing to PSNPs sent on the LAN circuit which are used to request LSPs that the sen	<t>The smaller the LPP is, the faster the feedback to the sender and
	der of the PSNP does not have. If the DIS does not support faster flooding, this	possibly the higher the rate if the rate is limited by the end-to-end
	will impact the maximum flooding speed which could occur on a LAN. Use of LAN p	RTT (link RTT + time to acknowledge). This may result in an increase
	riority to prefer a node which supports faster flooding in the DIS election may	in the number of PSNPs sent, which may increase CPU and IO load on both
	be useful.</t>	the sender and receiver. The LPP should be less than or equal to 90
	<t>NOTE: The focus of work used to develop the example al	as this is the maximum number of LSPs that can be acknowledged in a
	gorithms discussed later in this document focused on operation over point-to-poi	PSNP at common MTU sizes; hence, waiting longer would not reduce the
	nt interfaces. A full discussion of how best to do faster flooding on a LAN inte	number of PSNPs sent but would delay the acknowledgments. LPP should
	rface is therefore out of scope for this document.</t>	not be chosen too high as the congestion control starts with a
	</section>	congestion window of LPP + 1. Based on experimental evidence, 15
		unacknowledged LSPs is a good value, assuming that the Receive Window
	</section>	is at least 30. More frequent PSNPs give the transmitter more
		feedback on receiver progress, allowing the transmitter to continue
	<section anchor="Receiver" title="Performance improvement on the receiver	transmitting while not burdening the receiver with undue overhead.
	">	</t>
		<t>By deploying both the time-based and the threshold-based PSNP approac
	<t>This section defines two behaviors that SHOULD be implemented	hes, the receiver can be adaptive to both LSP bursts and infrequent LSP updates.
	on the receiver.</t>	</t>
		<t>As PSNPs also consume link bandwidth, packet-queue space, and
	<section anchor="LSPACKRate" title="Rate of LSP Acknowledgments">
	<t>On point-to-point networks, PSNPs provide acknowledgme
	nts for
	received LSPs. <xref target="ISO10589"/>
	suggests that some delay be
	used when sending PSNPs. This provides some optimization as multiple
	LSPs can be acknowledged by a single PSNP.</t>

	<t>
	Faster LSP flooding benefits from a faster feedback
	loop. This requires a reduction in the delay in sending
	PSNPs.
	</t>

	<t>For the generation of PSNPs, the receiver SHOULD use a
	partialSNPInterval smaller than the one defined in [ISO10589]. The choice of th
	is lower value is a local choice. It may depend on the available processing powe
	r of the node, the number of adjacencies, and the requirement to synchronize the
	LSDB more quickly. 200 ms seems to be a reasonable value.</t>
	<t>
	In addition to the timer-based
	partialSNPInterval, the receiver SHOULD keep
	track of the number of unacknowledged LSPs
	per circuit and level. When this number
	exceeds a preset threshold of LSPs Per PSNP
	(LPP), the receiver SHOULD immediately send
	a PSNP without waiting for the PSNP timer to
	expire. In the case of a burst of LSPs, this
	allows for more frequent PSNPs, giving
	faster feedback to the sender. Outside of
	the burst case, the usual time-based PSNP
	approach comes into effect.</t>
	<t> The smaller the LPP, the faster the feedback to the
	sender
	and 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 in the number of PSNPs sent which may i
	ncrease CPU
	and IO load on 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 in a PSNP at common MTU sizes,
	hence waiting longer would not reduce the
	number of PSNPs sent but would delay the
	acknowledgements. LPP should not be chosen too high as
	the congestion control starts with a congestion window
	of LPP+1.
	Based on experimental
	evidence, 15 unacknowledged LSPs is a good
	value assuming that the Receive Window is
	at least 30. More
	frequent PSNPs gives the transmitter more
	feedback on receiver progress, allowing the
	transmitter to continue transmitting while
	not burdening the receiver with undue
	overhead.
	</t>
	<t>By deploying both the time-based and the threshold-bas
	ed PSNP approaches, the receiver can be adaptive to both LSP bursts and infreque
	nt LSP updates. </t>

	<t>As PSNPs also consume link bandwidth, packet-queue spa
	ce, 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.</t>	can be sent on an interface.</t>

	</section>	</section>
		<section anchor="PKTPRI" numbered="true" toc="default">
	<section anchor="PKTPRI" title="Packet Prioritization on Receive"	<name>Packet Prioritization on Receive</name>
	>	<t>There are three classes of PDUs sent by IS-IS:</t>
	<t>There are three classes of PDUs sent by IS-IS:</t>	<ul spacing="normal">
		<li>
	<t>	<t>Hellos</t>
	<list style="symbols">	</li>
	<t>Hellos</t>	<li>
		<t>LSPs</t>
	<t>LSPs</t>	</li>
		<li>
	<t>Complete Sequence Number PDUs (CSNPs)	<t>Complete Sequence Number PDUs (CSNPs) and PSNPs</t>
	and PSNPs</t>	</li>
	</list>Implementations today may prioritize the r	</ul>
	eception of Hellos	<t>Implementations today may prioritize the reception of Hellos
	over LSPs and Sequence Number PDUs (SNPs) in order to prevent a burst of LSP updates from	over LSPs and Sequence Number PDUs (SNPs) in order to prevent a burst of LSP updates from

	triggering an adjacency timeout which in turn would require additional	triggering an adjacency timeout, which in turn would require additional
	LSPs to be updated.</t>	LSPs to be updated.</t>

		<t>CSNPs and PSNPs serve to trigger or acknowledge the transmission of s
	<t>CSNPs and PSNPs serve to trigger or acknowledge the tr	pecified
	ansmission of specified
	LSPs. On a point-to-point link, PSNPs acknowledge the receipt of one	LSPs. On a point-to-point link, PSNPs acknowledge the receipt of one
	or more LSPs.	or more LSPs.

	For this reason, <xref target="ISO10589"/>	For this reason, <xref target="ISO10589" format="default"/>
	specifies a delay	specifies a delay
	(partialSNPInterval) before sending a PSNP so that the number of PSNPs	(partialSNPInterval) before sending a PSNP so that the number of PSNPs
	required to be sent is reduced. On receipt of a PSNP, the set of LSPs	required to be sent is reduced. On receipt of a PSNP, the set of LSPs
	acknowledged by that PSNP can be marked so that they do not need to be	acknowledged by that PSNP can be marked so that they do not need to be
	retransmitted.</t>	retransmitted.</t>

		<t>If a PSNP is dropped on reception, the set of LSPs advertised in
		the PSNP cannot be marked as acknowledged, and this results in
		needless retransmissions that further delay transmission of
		other LSPs that are yet to be transmitted. It may also make it more
		likely that a receiver becomes overwhelmed by LSP transmissions.</t>
		<t>Therefore, implementations <bcp14>SHOULD</bcp14> prioritize IS-IS
		PDUs on the way from the incoming interface to the IS-IS process. The
		relative priority of packets in decreasing order <bcp14>SHOULD</bcp14>
		be: Hellos, SNPs, and LSPs. Implementations <bcp14>MAY</bcp14> also
		prioritize IS-IS packets over other protocols, which are less critical
		for the router or network, less sensitive to delay, or more bursty
		(e.g., BGP).</t>
		</section>
		</section>
		<section anchor="Control" numbered="true" toc="default">
		<name>Congestion and Flow Control</name>
		<section anchor="Overview" numbered="true" toc="default">
		<name>Overview</name>
		<t>Ensuring the goodput between two entities is a Layer 4
		responsibility as per the OSI model. A typical example is the TCP
		protocol defined in <xref target="RFC9293" format="default"/> that
		provides flow control, congestion control, and reliability.
		</t>
		<t>Flow control creates a control loop between a transmitter and a recei
		ver so that the transmitter does not overwhelm the receiver. TCP provides a mean
		s for the receiver to govern the amount of data sent by the sender through the u
		se of a sliding window.</t>
		<t> Congestion control prevents the set of transmitters from overwhelmin
		g the path of the packets between two IS-IS implementations. This path typically
		includes a point-to-point link between two IS-IS neighbors, which is usually ov
		ersized compared to the capability of the IS-IS speakers, but potentially also i
		ncludes some internal elements inside each neighbor such as switching fabric, li
		ne card CPU, and forwarding plane buffers that may experience congestion. These
		resources may be shared across multiple IS-IS adjacencies for the system, and it
		is the responsibility of congestion control to ensure that these are shared rea
		sonably.</t>
		<t>Reliability provides loss detection and recovery. IS-IS already has m
		echanisms to ensure the reliable transmission of LSPs. This is not changed by th
		is document.</t>


	<t>If a PSNP is dropped on reception,	<!-- [rfced] In Section 6.1, is this sentence referring to Sections 6.2
	the set of LSPs advertised in the PSNP cannot be marked as	and 6.3? If so, may we update it as follows for precision?
	acknowledged and this results in needless retransmissions that will
	further delay transmission of other LSPs that are yet to be
	transmitted. It may also make it more likely that a receiver becomes
	overwhelmed by LSP transmissions.</t>


	<t>Therefore implementations SHOULD prioritize IS-IS PDUs	Current:
	on the way from the incoming interface to the IS-IS process. The relative prior	The following two sections provide two Flow and/or Congestion control
	ity of packets in decreasing order SHOULD be: Hellos, SNPs, LSPs. Implementation	algorithms that may be implemented by taking advantage of the
	s MAY also prioritize IS-IS packets over other protocols which are less critical	extensions defined in this document.
	for the router or network, less sensitive to delay or more bursty (e.g., BGP).<
	/t>
	</section>


	</section>	Perhaps:
		Sections 6.2 and 6.3 provide two flow and/or congestion control
		algorithms that may be implemented by taking advantage of the
		extensions defined in this document.
		-->
		<t>The following two sections provide two flow and/or congestion control
		algorithms that may be implemented by taking advantage of the extensions define
		d in this document. The signal that these IS-IS extensions (defined in Sections
		<xref target="FloodingTLV" format="counter"/> and <xref target="Receiver" forma
		t="counter"/>) provide is generic and is designed to support different sender-si
		de algorithms. A sender can unilaterally choose a different algorithm to use.</t
		>
		</section>
		<section anchor="RWIN-Algo" numbered="true" toc="default">
		<name>Congestion and Flow Control Algorithm</name>
		<section anchor="FlowControl" numbered="true" toc="default">
		<name>Flow Control</name>


	<section anchor="Control" title="Congestion and Flow Control">	<!-- [rfced] Will the meaning of "a single instance of a transmitter"
		be clear to the reader? Is it intended to contrast with "a single receiver"?


	<section anchor="Overview" title="Overview">	Original:
	<t>Ensuring the goodput between two entities is a layer-4	A flow control mechanism creates a control loop between a single
	responsibility as per the OSI model. A typical example is the TCP protocol defi	instance of a transmitter and a single receiver.
	ned in	-->
	<xref target="RFC9293"></xref> that provides flow
	control, congestion control, and reliability.
	</t>
	<t>Flow control creates a control loop between a transmit
	ter and a receiver so that the transmitter does not overwhelm the receiver. TCP
	provides a means for the receiver to govern the amount of data sent by the sende
	r through the use of a sliding window.</t>
	<t> Congestion control prevents the set of transmitters f
	rom overwhelming the path of the packets between two IS-IS implementations. This
	path typically includes a point-to-point link between two IS-IS neighbors which
	is usually over-sized compared to the capability of the IS-IS speakers, but pot
	entially some internal elements inside each neighbor such as switching fabric, l
	ine card CPU, and forwarding plane buffers that may experience congestion. These
	resources may be shared across multiple IS-IS adjacencies for the system and it
	is the responsibility of congestion control to ensure that these are shared rea
	sonably.</t>
	<t>Reliability provides loss detection and recovery. IS-I
	S already has mechanisms to ensure the reliable transmission of LSPs. This is no
	t changed by this document.</t>


	<t>The following two sections provide two Flow and/or Con	<t> A flow control mechanism creates a control loop between a single
	gestion control algorithms that may be implemented by taking advantage of the ex	instance of a transmitter and a single receiver. This section uses a
	tensions defined in this document. The signal that these IS-IS extensions define	mechanism similar to the TCP receive window to allow the receiver to
	d in <xref target="FloodingTLV"/> and <xref target="Receiver"/> provide are ge	govern the amount of data sent by the sender. This receive window
	neric and are designed to support different sender-side algorithms. A sender can	('rwin') indicates an allowed number of LSPs that the sender may
	unilaterally choose a different algorithm to use.</t>	transmit before waiting for an acknowledgment. The size of the
	</section>	receive window, in units of LSPs, is initialized with the value
		advertised by the receiver in the Receive Window sub-TLV.


	<section anchor="RWIN-Algo" title="Congestion and Flow Control al	<!-- [rfced] What does "this neighbor" refer to? The sender,
	gorithm">	the receiver, or otherwise? (There is no mention of a 'neighbor'
		in the preceding text of this paragraph.)


	<section anchor="FlowControl" title="Flow control">	Current:
	<t>	If no
	A flow control mechanism creates a control loop	value is advertised, the transmitter should initialize rwin with its
	between a single instance of a transmitter and a	locally configured value for this neighbor.
	single receiver. This section uses a mechanism	-->
	similar to the TCP receive window to allow the
	receiver to govern the amount of data sent by the	If no
	sender. This receive window ('rwin') indicates an	value is advertised, the transmitter should initialize rwin with its
	allowed number of LSPs that the sender may	locally configured value for this neighbor.
	transmit before waiting for an acknowledgment. The	</t>
	size of the receive window, in units of LSPs, is	<t>
	initialized with the value advertised by the
	receiver in the Receive Window sub-TLV. If no
	value is advertised, the transmitter should
	initialize rwin with its locally configured value for thi
	s neighbor.
	</t>
	<t>
	When the transmitter sends a set of LSPs to the	When the transmitter sends a set of LSPs to the
	receiver, it subtracts the number of LSPs sent	receiver, it subtracts the number of LSPs sent
	from rwin. If the transmitter receives a PSNP,	from rwin. If the transmitter receives a PSNP,
	then rwin is incremented for each acknowledged	then rwin is incremented for each acknowledged
	LSP. The transmitter must ensure that the value of	LSP. The transmitter must ensure that the value of
	rwin never goes negative.	rwin never goes negative.

	</t>	</t>
		<t>The RWIN value is of importance when the RTT is the limiting factor
	<t>The RWIN value is of importance when the RTT is the li	for the throughput. In this case, the optimal size is the desired LSP rate mult
	miting factor for the throughput. In this case the optimal size is the desired L	iplied by the RTT. The RTT is the addition of the link RTT plus the time taken b
	SP rate multiplied by the RTT. The RTT being the addition of the link RTT plus t	y the receiver to acknowledge the first received LSP in its PSNP.  50 or 10
	he time taken by the receiver to acknowledge the first received LSP in its PSNP.	0 may be reasonable default numbers.
	50 or 100 may be reasonable default numbers. As an example, a RWIN of 100 requi	<!--[rfced] Please clarify this sentence; specifically, is "and limits"
	res a control plane input buffer of 150 kbytes per neighbor assuming an IS-IS MT	outside of the "assuming" phrase?
	U of 1500 octets and limits the throughput to 10000 LSPs per second and per neig
	hbor for a link RTT of 10 ms. With the same RWIN, the throughput limitation is 2
	000 LSP per second when the RTT is 50ms. That's the maximum throughput assuming
	no other limitations such as CPU limitations.</t>

	<t>Equally RTT is of importance for the performance. That
	is why the
	performance improvements on the receiver specified in sec
	tion <xref target="Receiver"/> are
	important to achieve good throughput. If the receiver doe
	s not support
	those performance improvements, in the worst case (small
	RWIN and high
	RTT) the throughput will be limited by the LSP Transmissi
	on Interval
	as defined in section <xref target="InterfaceLSPTransmiss
	ionInterval"/>.</t>

	<section anchor="TLVoperationP2P" title="Operatio
	n on a point to point interface">

	<t>By sending the Receive Window sub-TLV,
	a node advertises to its neighbor its ability to receive that many un-acknowled
	ged LSPs from the neighbor. This is akin to a receive window or sliding window i
	n flow control. In some implementations, this value should reflect the IS-IS soc
	ket buffer size. Special care must be taken to leave space for CSNPs and PSNPs a
	nd IIHs if they share the same input queue. In this case, this document suggests
	advertising an LSP Receive Window corresponding to half the size of the IS-IS i
	nput queue. </t>

	<t>By advertising an LSP Transmission Int
	erval sub-TLV, a node advertises its ability to receive LSPs separated by at lea
	st the advertised value, outside of LSP bursts.</t>

	<t>By advertising an LSP Burst Size sub-T
	LV, a node advertises its ability to receive that number of LSPs back-to-back.</
	t>

	<t>The LSP transmitter MUST NOT exceed th
	ese parameters. After having sent a full burst of LSPs, it MUST send the subsequ
	ent LSPs with a minimum of LSP Transmission Interval between LSP transmissions.
	For CPU scheduling reasons, this rate MAY be averaged over a small period, e.g.,
	10-30ms.</t>

	<t>If either the LSP transmitter or recei
	ver does not adhere to these parameters, for example because of transient condit
	ions, this doesn't result in a fatal condition for IS-IS operation. In the worst
	case, an LSP is lost at the receiver and this situation is already remedied by
	mechanisms in <xref target="ISO10589"/>.
	After a few seconds, neighbors will excha
	nge PSNPs (for point-to-point interfaces) or CSNPs (for broadcast interfaces) an
	d recover from the lost LSPs. This worst case should be avoided as those additio
	nal seconds impact convergence time since the LSDB is not fully synchronized. He
	nce it is better to err on the conservative side and to under-run the receiver r
	ather than over-run it.</t>

	</section>
	<section title="Operation on a
	broadcast LAN
	interface">
	<t>Flow and congestion control on a LAN interfa
	ce is out of scope for this document.</t>
	</section>

	</section>
	<section anchor="CongestionControl" title="Congestion Control">
	<t>Whereas flow control prevents the sender from overwhelming t
	he receiver, congestion control prevents senders from overwhelming the network.
	For an IS-IS adjacency, the network between two IS-IS neighbors is relatively li
	mited in scope and includes a single link which is typically over-sized compared
	to the capability of the IS-IS speakers.
	In situations where the probability of LSP drop is low, flow co
	ntrol <xref target="FlowControl"/> is expected to give good results, without the
	need to implement congestion control. Otherwise, adding congestion control will
	help handling
	congestion of LSPs in the receiver.</t>
	<t>This section describes one sender-side congestion cont
	rol algorithm largely inspired by the TCP congestion control algorithm <xref tar
	get="RFC5681"></xref>.</t>
	<t>The proposed algorithm uses a variable congestion wind
	ow 'cwin'. It plays a role similar to the receive window described above. The ma
	in difference is that cwin is adjusted dynamically according to various events d
	escribed below.</t>

	<section anchor="CC1Core" title="Core algorithm">
	<t>In its simplest form, the congestion control a
	lgorithm looks like the following:</t>
	<figure anchor="cc1_core_algo">
	<artwork>
	+---------------+
	\| \|
	\| v
	\| +----------------------+
	\| \| Congestion avoidance \|
	\| + ---------------------+
	\| \|
	\| \| Congestion signal
	----------------+
	</artwork>
	</figure>
	<t>The algorithm starts with cwin = cwin0 = LPP +
	1. In the congestion avoidance phase, cwin increases as LSPs are acked: for eve
	ry acked LSP, cwin += 1 / cwin without exceeding RWIN. When LSPs are exchanged,
	cwin LSPs will be acknowledged in 1 RTT, meaning cwin(t) = t/RTT + cwin0. Since
	the RTT is low in many IS-IS deployments, the sending rate can reach fast rates
	in short periods of time.</t>

	<t>When updating cwin, it must not become higher
	than the number of LSPs waiting to be sent, otherwise the sending will not be pa
	ced by the receiving of acks. Said differently, tx pressure is needed to maintai
	n and increase cwin.</t>

	<t>When the congestion signal is triggered, cwin
	is set back to its initial value and the congestion avoidance phase starts again
	.</t>
	</section>
	<section anchor="CC1CongestionSignals" title="Congestion
	signals">
	<t>The congestion signal can take various forms.
	The more reactive the congestion signals, the fewer LSPs will be lost due to con
	gestion. However, overly aggressive congestion signals will cause a sender to ke
	ep a very low sending rate even without actual congestion on the path.</t>

	<t>Two practical signals are given below.</t>


	<t>Delay: When receiving acknowledgements, a send	Original:
	er estimates the acknowledgement time of the receiver. Based on this estimation,	As an example, a RWIN of 100 requires a control plane input
	it can infer that a packet was lost, and infer congestion on the path.</t>	buffer of 150 kbytes per neighbor assuming an IS-IS MTU of 1500
	<t>There can be a timer per LSP, but this can bec	octets and limits the throughput to 10000 LSPs per second and per
	ome costly for implementations. It is possible to use only a single timer t1 for	neighbor for a link RTT of 10 ms.
	all LSPs: during t1, sent LSPs are recorded in a list list_1. Once the RTT is o
	ver, list_1 is kept and another list list_2 is used to store the next LSPs. LSPs
	are removed from the lists when acked. At the end of the second t1 period, ever
	y LSP in list_1 should have been acked, so list_1 is checked to be empty. list_1
	can then be reused for the next RTT.</t>
	<t>There are multiple strategies to set the timeo
	ut value t1. It should be based on measurements of the maximum acknowledgement t
	ime (MAT) of each PSNP. The simplest one is to use three times the RTT. Alternat
	ively an exponential moving average of the MATs, like <xref target="RFC6298"/>.
	A more elaborate one is to take a running maximum of the MATs over a period of a
	few seconds. This value should include a margin of error to avoid false positiv
	es (e.g., estimated MAT measure variance) which would have a significant impact
	on performance.</t>


	<t> Loss: if the receiver has signaled the O-flag	Perhaps (adding parentheses):
	(Ordered acknowledgement) <xref target="Flags"/>, a sender MAY record its sendi	As an example, an RWIN of 100 requires a control plane
	ng order and check that acknowledgements arrive in the same order. If not, some	input buffer of 150 kbytes per neighbor (assuming an IS-IS MTU of
	LSPs are missing and this MAY be used to trigger a congestion signal.</t>	1500 octets) and limits the throughput to 10000 LSPs per second and
		per neighbor for a link RTT of 10 ms.
		-->
		As an example, an RWIN of 100 requires a control plane input buffer of 150 kbyte
		s per neighbor assuming an 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 R
		WIN, the throughput limitation is 2000 LSPs per second when the RTT is 50 ms. Th
		at's the maximum throughput assuming no other limitations such as CPU limitation
		s.</t>
		<t>Equally, RTT is of importance for the performance. That is why the
		performance improvements on the receiver specified in <xref
		target="Receiver" format="default"/> are important to achieve good
		throughput. If the receiver does not support those performance
		improvements, in the worst case (small RWIN and high RTT) the
		throughput will be limited by the LSP Transmission Interval as
		defined in <xref target="InterfaceLSPTransmissionInterval"
		format="default"/>.</t>
		<section anchor="TLVoperationP2P" numbered="true" toc="default">
		<name>Operation on a Point-to-Point Interface</name>
		<t>By sending the Receive Window sub-TLV, a node advertises to its n
		eighbor its ability to receive that many unacknowledged LSPs from the neighbor.
		This is akin to a receive window or sliding window in flow control. In some impl
		ementations, this value should reflect the IS-IS socket buffer size. Special car
		e must be taken to leave space for CSNPs, PSNPs, and IIHs if they share the same
		input queue. In this case, this document suggests advertising an LSP Receive Wi
		ndow corresponding to half the size of the IS-IS input queue. </t>
		<t>By advertising an LSP Transmission Interval sub-TLV, a node adver
		tises its ability to receive LSPs separated by at least the advertised value, ou
		tside of LSP bursts.</t>
		<t>By advertising an LSP Burst Size sub-TLV, a node advertises its a
		bility to receive that number of LSPs back to back.</t>
		<t>The LSP transmitter <bcp14>MUST NOT</bcp14> exceed these paramete
		rs. After having sent a full burst of LSPs, it <bcp14>MUST</bcp14> send the subs
		equent LSPs with a minimum of LSP Transmission Interval between LSP transmission
		s. For CPU scheduling reasons, this rate <bcp14>MAY</bcp14> be averaged over a s
		mall period, e.g., 10-30 ms.</t>
		<t>If either the LSP transmitter or receiver does not adhere to thes
		e parameters, for example, because of transient conditions, this doesn't result
		in a fatal condition for IS-IS operation. In the worst case, an LSP is lost at t
		he receiver, and this situation is already remedied by mechanisms in <xref targe
		t="ISO10589" format="default"/>.
		After a few seconds, neighbors will excha
		nge PSNPs (for point-to-point interfaces) or CSNPs (for broadcast interfaces) an
		d recover from the lost LSPs. This worst case should be avoided as those additio
		nal seconds impact convergence time since the LSDB is not fully synchronized. He
		nce, it is better to err on the conservative side and to under-run the receiver
		rather than over-run it.</t>
		</section>
		<section numbered="true" toc="default">
		<name>Operation on a Broadcast LAN Interface</name>
		<t>Flow and congestion control on a LAN interface is out of scope fo
		r this document.</t>
		</section>
		</section>
		<section anchor="CongestionControl" numbered="true" toc="default">
		<name>Congestion Control</name>
		<t>Whereas flow control prevents the sender from overwhelming the
		receiver, congestion control prevents senders from overwhelming the
		network. For an IS-IS adjacency, the network between two IS-IS
		neighbors is relatively limited in scope and includes a single link
		that is typically oversized compared to the capability of the IS-IS
		speakers. In situations where the probability of LSP drop is low,
		flow control (<xref target="FlowControl" format="default"/>) is
		expected to give good results, without the need to implement
		congestion control. Otherwise, adding congestion control will help
		handling congestion of LSPs in the receiver.</t>
		<t>This section describes one sender-side congestion control algorithm
		largely inspired by the TCP congestion control algorithm <xref target="RFC5681"
		format="default"/>.</t>
		<t>The proposed algorithm uses a variable congestion window 'cwin'. It
		plays a role similar to the receive window described above. The main difference
		is that cwin is adjusted dynamically according to various events described belo
		w.</t>
		<section anchor="CC1Core" numbered="true" toc="default">
		<name>Core Algorithm</name>
		<t>In its simplest form, the congestion control algorithm looks like
		the following:</t>
		<figure anchor="cc1_core_algo">
		<artwork name="" type="" align="left" alt=""><![CDATA[
		+---------------+
		\| \|
		\| v
		\| +----------------------+
		\| \| Congestion avoidance \|
		\| + ---------------------+
		\| \|
		\| \| Congestion signal
		----------------+]]></artwork>
		</figure>


	</section>	<t>The algorithm starts with cwin = cwin0 = LPP + 1. In the congesti
		on avoidance phase, cwin increases as LSPs are acked: for every acked LSP, cwin
		+= 1 / cwin without exceeding RWIN. When LSPs are exchanged, cwin LSPs will be a
		cknowledged in 1 RTT, meaning cwin(t) = t/RTT + cwin0. Since the RTT is low in m
		any IS-IS deployments, the sending rate can reach fast rates in short periods of
		time.</t>
		<t>When updating cwin, it must not become higher than the number of
		LSPs waiting to be sent, otherwise the sending will not be paced by the receivin
		g of acks. Said differently, transmission pressure is needed to maintain and inc
		rease cwin.</t>
		<t>When the congestion signal is triggered, cwin is set back to its
		initial value, and the congestion avoidance phase starts again.</t>
		</section>
		<section anchor="CC1CongestionSignals" numbered="true" toc="default">
		<name>Congestion Signals</name>
		<t>The congestion signal can take various forms. The more reactive t
		he congestion signals, the fewer LSPs will be lost due to congestion. However, o
		verly aggressive congestion signals will cause a sender to keep a very low sendi
		ng rate even without actual congestion on the path.</t>
		<t>Two practical signals are given below.</t>
		<ol spacing="normal" type="1">
		<li><t>Delay: When receiving acknowledgments, a sender
		estimates the acknowledgment time of the receiver. Based on
		this estimation, it can infer that a packet was lost and
		that congestion is on the path.</t>
		<t>There can be a timer per LSP, but this can become costly for
		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. 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 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 can then be reused for the next RTT.</t>


	<section anchor="CC1Refinement" title="Refinement">	<!-- [rfced] Please clarify how the sentence starting with "Alternatively"
	<t>With the algorithm presented above, if congest	fits with the rest of the paragraph. Would the following update retain
	ion is detected, cwin goes back to its initial value, and does not use the infor	the intended meaning?
	mation gathered in previous congestion avoidance phases.</t>


	<t>It is possible to use a fast recovery phase on	Original:
	ce congestion is detected, to avoid going through this linear rate of growth fro	There are multiple strategies to set the timeout value t1. It should
	m scratch. When congestion is detected, a fast recovery threshold frthresh is se	be based on measurements of the maximum acknowledgement time (MAT) of
	t to frthresh = cwin / 2. In this fast recovery phase, for every acked LSP, cwin	each PSNP. The simplest one is to use three times the RTT.
	+= 1. Once cwin reaches frthresh, the algorithm goes back to the congestion avo	Alternatively an exponential moving average of the MATs, like
	idance phase.</t>	[RFC6298].


	<figure anchor="cc1_algo_refinement_1">	Perhaps:
	<artwork>	There are multiple strategies to set the timeout value t1. It should
	+---------------+	be based on measurements of the maximum acknowledgment time (MAT) of
	\| \|	each PSNP. Using three times the RTT is the simplest strategy;
	\| v	alternatively, an exponential moving average of the MATs, as described
	\| +----------------------+	in [RFC6298], can be used.
	\| \| Congestion avoidance \|	-->
	\| + ---------------------+
	\| \|
	\| \| Congestion signal
	\| \|
	\| +----------------------+
	\| \| Fast recovery \|
	\| +----------------------+
	\| \|
	\| \| frthresh reached
	----------------+
	</artwork>
	</figure>


	</section>	<t>There are multiple strategies to set the timeout value t1. It
		should be based on measurements of the maximum acknowledgment
		time (MAT) of each PSNP. The simplest one is to use three times
		the RTT. Alternatively an exponential moving average of the
		MATs, like <xref target="RFC6298" format="default"/>. A more
		elaborate one is to take a running maximum of the MATs over a
		period of a few seconds. This value should include a margin of
		error to avoid false positives (e.g., estimated MAT measure
		variance), which would have a significant impact on
		performance.</t></li>
		<li><t>Loss: if the receiver has signaled the O-flag (see <xref ta
		rget="Flags" format="default"/>), a
		sender <bcp14>MAY</bcp14> record its sending order and check
		that acknowledgments arrive in the same order. If not, some
		LSPs are missing, and this <bcp14>MAY</bcp14> be used to trigger
		a congestion signal.</t></li>
		</ol>
		</section>
		<section anchor="CC1Refinement" numbered="true" toc="default">
		<name>Refinement</name>
		<t>With the algorithm presented above, if congestion is detected, cw
		in goes back to its initial value and does not use the information gathered in p
		revious congestion avoidance phases.</t>
		<t>It is possible to use a fast recovery phase once congestion is de
		tected and to avoid going through this linear rate of growth from scratch. When
		congestion is detected, a fast recovery threshold frthresh is set to frthresh =
		cwin / 2. In this fast recovery phase, for every acked LSP, cwin += 1. Once cwin
		reaches frthresh, the algorithm goes back to the congestion avoidance phase.</t
		>
		<figure anchor="cc1_algo_refinement_1">
		<artwork name="" type="" align="left" alt=""><![CDATA[
		+---------------+
		\| \|
		\| v
		\| +----------------------+
		\| \| Congestion avoidance \|
		\| + ---------------------+
		\| \|
		\| \| Congestion signal
		\| \|
		\| +----------------------+
		\| \| Fast recovery \|
		\| +----------------------+
		\| \|
		\| \| frthresh reached
		----------------+]]></artwork>
		</figure>
		</section>
		<section anchor="cc_remarks" numbered="true" toc="default">
		<name>Remarks</name>
		<t> This algorithm's performance is dependent on the LPP
		value. Indeed, the smaller the LPP is, the more information is
		available for the congestion control algorithm to perform
		well. However, it also increases the resources spent on sending
		PSNPs, so a trade-off must be made. This document recommends
		using an LPP of 15 or less. If a Receive Window is advertised, LPP
		<bcp14>SHOULD</bcp14> be lower, and the best performance is
		achieved when LPP is an integer fraction of the Receive Window.
		</t>
		<t>Note that this congestion control algorithm benefits from the
		extensions proposed in this document. The advertisement of a
		receive window from the receiver (<xref target="FlowControl"
		format="default"/>) avoids the use of an arbitrary maximum value
		by the sender. The faster acknowledgment of LSPs (<xref
		target="LSPACKRate" format="default"/>) allows for a faster
		control loop and hence a faster increase of the congestion
		window in the absence of congestion.
		</t>
		</section>
		</section>
		<section anchor="Pacing" numbered="true" toc="default">
		<name>Pacing</name>
		<t>As discussed in <xref target="RFC9002" sectionFormat="comma"
		section="7.7" format="default"/>, a sender <bcp14>SHOULD</bcp14>
		pace sending of all in-flight LSPs based on input from the
		congestion controller.</t>
		<t>Sending multiple packets without any delay between them creates a p
		acket burst that might cause short-term congestion and losses. Senders <bcp14>MU
		ST</bcp14> either use pacing or limit such bursts. Senders <bcp14>SHOULD</bcp14>
		limit bursts to LSP Burst Size.</t>
		<t>Senders can implement pacing as they choose. A perfectly paced send
		er spreads packets evenly over time. For a window-based congestion controller, s
		uch as the one in this section, that rate can be computed by averaging the conge
		stion window over the RTT. Expressed as an inter-packet interval in units of tim
		e:</t><t indent="3">interval = (SRTT / cwin) / N</t>
		<t>SRTT is the Smoothed Round-Trip Time <xref target="RFC6298" format=
		"default"/>.</t>
		<t>Using a value for N that is small, but at least 1 (for example, 1.2
		5), ensures that variations in RTT do not result in underutilization of the cong
		estion window.</t>
		<t>Practical considerations, such as scheduling delays and computation
		al efficiency, can cause a sender to deviate from this rate over time periods th
		at are much shorter than an RTT.</t>
		<t>One possible implementation strategy for pacing uses a leaky bucket
		algorithm, where the capacity of the "bucket" is limited to the maximum burst s
		ize, and the rate that the "bucket" fills is determined by the above function.</
		t>
		</section>
		<section anchor="sec_determining_values" numbered="true" toc="default">
		<name>Determining Values to be Advertised in the Flooding Parameters T
		LV</name>
		<t>The values that a receiver advertises do not need to be perfect. If
		the values are too low, then the transmitter will not use the full bandwidth or
		available CPU resources. If the values are too high, then the receiver may drop
		some LSPs during the first RTT, and this loss will reduce the usable receive wi
		ndow, and the protocol mechanisms will allow the adjacency to recover. Flooding
		slower than both nodes can support will hurt performance as will consistently ov
		erloading the receiver.</t>
		<section anchor="sec_determining_values_static" numbered="true" toc="d
		efault">
		<name>Static Values</name>
		<t>The values advertised need not be dynamic, as feedback is
		provided by the acknowledgment of LSPs in SNP
		messages. Acknowledgments provide a feedback loop on how fast the
		LSPs are processed by the receiver. They also signal that the LSPs
		can be removed from the receive window, explicitly signaling to the
		sender that more LSPs may be sent. By advertising relatively
		static parameters, we expect to produce overall flooding behavior
		similar to what might be achieved by manually configuring
		per-interface LSP rate-limiting on all interfaces in the
		network. The advertised values could be based, for example, on
		offline tests of the overall LSP-processing speed for a particular
		set of hardware and the number of interfaces configured for
		IS-IS. With such a formula, the values advertised in the Flooding
		Parameters TLV would only change when additional IS-IS interfaces
		are configured.</t>
		<t>Static values are dependent on the CPU generation, class of
		router, and network scaling, typically the number of adjacent
		neighbors. Examples at the time of publication are provided
		below.


	<section anchor="cc_remarks" title="Remarks">	The LSP Burst Size could be in the range 5 to 20. From a router
	<t>	perspective, this value typically depends on the queue(s) size(s)
	This algorithm's performance is dependent	on the I/O path from the packet forwarding engine to the control
	on the LPP value. Indeed, the smaller LPP	plane, which is very platform-dependent. It also depends upon how
	is, the more information is available for	many IS-IS neighbors share this I/O path, as typically all
	the congestion control algorithm to	neighbors will send the same LSPs at the same time. It may also
	perform well. However, it also increases	depend on other incoming control plane traffic that is sharing that
	the resources spent on sending PSNPs, so a	I/O
	trade-off must be made. This document	path, how bursty they are, and how many incoming IS-IS packets are
	recommends to use an LPP of 15 or less. If	prioritized over other incoming control plane traffic. As
	a Receive Window is advertised, LPP	indicated in <xref target="HISTORY" format="default"/>, the
	SHOULD be lower and the best performance	historical behavior from <xref target="ISO10589"
	is achieved when LPP is an integer	format="default"/> allows a value of 10; hence, 10 seems
	fraction of the Receive Window.	conservative. From a network operation perspective, it would be
	</t>	beneficial for the burst size to be equal to or higher than the
		number of LSPs that may be originated by a single failure. For a
		node failure, this is equal to the number of IS-IS neighbors of
		the failed node.


	<t>Note that this congestion control algorithm be	The LSP Transmission Interval could be in the range
	nefits from the extensions proposed in this document. The advertisement of a rec	of 1 ms to 33 ms. As indicated in <xref target="HISTORY"
	eive window from the receiver (<xref target="FlowControl"/>) avoids the use of a	format="default"/>, the historical behavior from <xref
	n arbitrary maximum value by the sender. The faster acknowledgment of LSPs (<xre	target="ISO10589" format="default"/> is 33 ms; hence, 33 ms is
	f target="LSPACKRate"/>) allows for a faster control loop and hence a faster inc	conservative. The LSP Transmission Interval is an advertisement of
	rease of the congestion window in the absence of congestion.	the receiver's sustainable LSP reception rate taking into account
	</t>	all aspects and particularly the control plane CPU and the I/O
	</section>	bandwidth. It's expected to improve (hence, decrease) as hardware
	</section>	and software naturally improve over time. It should be chosen
		conservatively, as this rate may be used by the sender in all
		conditions -- including the worst conditions. It's also not a
		bottleneck as the flow control algorithm may use a higher rate in
		good conditions, particularly when the receiver acknowledges
		quickly, and the receive window is large enough compared to the
		RTT.


	<section anchor="Pacing" title="Pacing">	LPP could be in the range of 5 to 90 with a proposed 15. A
	<t>As discussed in <xref target="RFC9002" sectionFormat="	smaller value provides faster feedback at the cost of the small
	comma" section="7.7" /> a sender SHOULD pace sending of all in-flight LSPs based	overhead of more PSNP messages.
	on input from the congestion controller.</t>
	<t>Sending multiple packets without any delay between the
	m creates a packet burst that might cause short-term congestion and losses. Send
	ers MUST either use pacing or limit such bursts. Senders SHOULD limit bursts to
	LSP Burst Size.</t>
	<t>Senders can implement pacing as they choose. A perfect
	ly paced sender spreads packets evenly over time. For a window-based congestion
	controller, such as the one in this section, that rate can be computed by averag
	ing the congestion window over the RTT. Expressed as an inter-packet interval in
	units of time:</t>
	<t>interval = (SRTT / cwin) / N</t>
	<t>SRTT is the smoothed round-tri
	p time [RFC6298]</t>
	<t>Using a value for N that is sm
	all, but at least 1 (for example, 1.25) ensures that variations in RTT do not re
	sult in underutilization of the congestion window.</t>
	<t>Practical considerations, such as scheduling delays an
	d computational efficiency, can cause a sender to deviate from this rate over ti
	me periods that are much shorter than an RTT.</t>
	<t>One possible implementation strategy for pacing uses a
	leaky bucket algorithm, where the capacity of the "bucket" is limited to the ma
	ximum burst size and the rate that the "bucket" fills is determined by the above
	function.</t>
	</section>


	<section anchor="sec_determining_values" title="Determining value	PartialSNPInterval could be in
	s to be advertised in the Flooding Parameters TLV">	the range 50 to 500 ms with a proposed value of 200 ms. One may
	<t>The values that a receiver advertises do not need to b	distinguish the value used locally from the value signaled to the
	e perfect. If the values are too low then the transmitter will not use the full	sender. The value used locally benefits from being small but is
	bandwidth or available CPU resources. If the values are too high then the receiv	not expected to be the main parameter to improve performance. It
	er may drop some LSPs during the first RTT and this loss will reduce the usable	depends on how fast the IS-IS flooding process may be scheduled by
	receive window and the protocol mechanisms will allow the adjacency to recover.	the CPU. Even when the receiver CPU is busy, it's safe because it wi
	Flooding slower than both nodes can support will hurt performance, as will consi	ll
	stently overloading the receiver.</t>	naturally delay its acknowledgments, which provides a negative
		feedback loop. The value advertised to the sender should be
		conservative (high enough) as this value could be used by the
		sender to send some LSPs rather than keep waiting for
		acknowledgments.


	<section anchor="sec_determining_values_static" title="St	Receive Window could be in the range of 30 to 200 with a
	atic values">	proposed value of 60. In general, the larger the better the performa
	<t>The values advertised need not be dynamic as feedback	nce on
	is provided by the acknowledgment of LSPs in SNP messages. Acknowledgments provi	links with high RTT. The higher that number and the higher the
	de a feedback loop on how fast the LSPs are processed by the receiver. They also	number of IS-IS neighbors, the higher the use of control plane
	signal that the LSPs can be removed from receive window, explicitly signaling t	memory, so it's mostly dependent on the amount of memory, which may
	o the sender that more LSPs may be sent. By advertising relatively static parame	be dedicated to IS-IS flooding and the number of IS-IS
	ters, we expect to produce overall flooding behavior similar to what might be ac	neighbors. From a memory usage perspective (a priori), one could
	hieved by manually configuring per-interface LSP rate-limiting on all interfaces	use the same value as the TCP receive window, but the value
	in the network. The advertised values could be based, for example, on offline t	advertised should not be higher than the buffer of the "socket"
	ests of the overall LSP-processing speed for a particular set of hardware and th	used.</t>
	e number of interfaces configured for IS-IS. With such a formula, the values adv	</section>
	ertised in the Flooding Parameters TLV would only change when additional IS-IS i	<section anchor="sec_determining_values_dynamic" numbered="true" toc="
	nterfaces are configured.</t>	default">
		<name>Dynamic Values</name>
		<t>To reflect the relative change of load on the receiver, the
		values 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 higher. For example, if LSPs are
		regularly dropped, 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 used (by IS-IS), then the values may be too
		low.</t>
		<!--[rfced] Should 'absolute value' be plural here?


	<t>Static values are dependent on the CPU generation, cla	Original:
	ss of router and network scaling, typically the number of adjacent neighbors.	The values may also be absolute value reflecting relevant average
	Examples at the time of publication are provided below. L	hardware resources that are monitored, typically the amount of buffer
	SP Burst Size could be in the range 5 to 20. From a router perspective, this val	space used by incoming LSPs.
	ue
	typically depends on the queue(s) size(s) on the I/O path
	from the packet forwarding engine to the control plane which is very platform d
	ependent.
	It also depends upon how many IS-IS neighbors share this
	I/O path as typically all neighbors will send the same LSPs at the same time.
	It may also depend on other incoming control plane traffi
	c sharing that I/O path, how bursty they are, and how many incoming IS-IS packet
	s
	are prioritized over other incoming control plane traffic
	. As indicated in <xref target="HISTORY"/>, the historical behavior from <xref
	target="ISO10589"/> allows a value
	of 10 hence 10 seems conservative. From a network operati
	on perspective, it would be beneficial for the burst size to be equal to or high
	er than the
	number of LSPs which may be originated by a single failur
	e. For a node failure, this is equal to the number of IS-IS neighbors of the fai
	led node.
	LSP Transmission Interval could be in the range of 1 ms t
	o 33 ms. As indicated in <xref target="HISTORY"/>, the historical behavior from
	<xref target="ISO10589"/> is 33ms hence
	is conservative. The LSP Transmission Interval is an adve
	rtisement of the receiver's sustainable LSP reception rate taking into account a
	ll aspects
	and in particular the control plane CPU and the I/O bandw
	idth. It's expected to improve (hence decrease) as hardware and software natural
	ly improve
	over time. It should be chosen conservatively as this rat
	e may be used by the sender in all conditions including the worst conditions.
	It's also not a bottleneck as the flow control algorithm
	may use a higher rate in good conditions, in particular when the receiver acknow
	ledges quickly
	and the receive window is large enough compared to the RT
	T.
	LPP could be in the range of 5 to 90 with a proposed 15.
	A smaller value provides faster feedback at the cost of the small overhead of mo
	re PSNP messages.
	PartialSNPInterval could be in the range 50ms to 500ms wi
	th a proposed 200ms.
	One may distinguish the value used locally from the value
	signaled to the sender. The value used locally benefits from being small but is
	not expected
	to be the main parameter to improve performance. It depen
	ds on how fast the IS-IS flooding process may be scheduled by the CPU. It's safe
	as, even when the
	receiver CPU is busy, it will naturally delay its acknowl
	edgments which provides a negative feedback loop. The value advertised to the se
	nder should be
	conservative (high enough) as this value could be used by
	the sender to send some LSPs rather than keep waiting for acknowledgments. Rece
	ive Window in the range
	of 30 to 200 with a proposed 60. In general, the larger t
	he better the performance on links with high RTT. The higher the number and the
	higher the
	number of IS-IS neighbors, the higher the use of control
	plane memory so it's mostly dependent on the amount of memory which may be dedic
	ated to IS-IS flooding
	and the number of IS-IS neighbors. From a memory usage pe
	rspective, a priori, one could use the same value as the TCP receive window, but
	the value
	advertised should not be higher than the buffer of the "s
	ocket" used.</t>
	</section>


	<section anchor="sec_determining_values_dynamic" title="D	Perhaps:
	ynamic values">	The values may also be absolute values that reflect the relevant average
	<t>The values may be updated dynamically, to reflect the	hardware resources that are monitored, e.g., the amount of buffer
	relative change of load on the receiver, by improving the values when the receiv	space used by incoming LSPs.
	er load is getting lower and degrading the values when the receiver load is gett
	ing higher. For example, if LSPs are regularly dropped, or if the queue regularl
	y comes close to being filled, then the values may be too high. On the other han
	d, if the queue is barely used (by IS-IS), then the values may be too low.</t>
	<t>The values may also be absolute value reflecting relev
	ant average hardware resources that are monitored, typically the amount of buffe
	r space used by incoming LSPs. In this case, care must be taken when choosing th
	e parameters influencing the values in order to avoid undesirable or unstable fe
	edback loops. It would be undesirable to use a formula that depends, for example
	, on an active measurement of the instantaneous CPU load to modify the values ad
	vertised in the Flooding Parameters TLV. This could introduce feedback into the
	IGP flooding process that could produce unexpected behavior.</t>
	</section>
	</section>


	<section anchor="OPS_Considerations" title="Operation considerati	Or:
	ons">	The values may be specified as absolute values that reflect
	<t>As discussed in <xref target="TLVoperationLAN"/>, the	the relevant average hardware resources, e.g., the amount of buffer
	solution is more effective on point-to-point adjacencies. Hence a broadcast int	space used by incoming LSPs.
	erface (e.g., Ethernet) only shared by two IS-IS neighbors should be configured	-->
	as point-to-point in order to have more effective flooding.</t>	<t>The values may also be absolute value reflecting relevant
	</section>	average hardware resources that are monitored, typically the
	</section>	amount of buffer space used by incoming LSPs. In this case, care
	<section anchor="TxSide" title="Transmitter Based Congestion Control Appr	must be taken when choosing the parameters influencing the values
	oach">	in order to avoid undesirable or unstable feedback loops. For
	<t>This section describes an approach to congestion control alg	example, it would be undesirable to use a formula that depends on
	orithm based on	an active measurement of the instantaneous CPU load to modify the
	performance measured by the transmitter without dependance on	values advertised in the Flooding Parameters TLV. This could
		introduce feedback into the IGP flooding process that could
		produce unexpected behavior.</t>
		</section>
		</section>
		<section anchor="OPS_Considerations" numbered="true" toc="default">
		<name>Operation Considerations</name>
		<t>As discussed in <xref target="TLVoperationLAN"
		format="default"/>, the solution is more effective on point-to-point
		adjacencies. Hence, a broadcast interface (e.g., Ethernet) only
		shared by two IS-IS neighbors should be configured as point-to-point
		in order to have more effective flooding.</t>
		</section>
		</section>
		<section anchor="TxSide" numbered="true" toc="default">
		<name>Transmitter-Based Congestion Control Approach</name>
		<t>This section describes an approach to the congestion control algorith
		m based on
		performance measured by the transmitter without dependence on
	signaling from the receiver.</t>	signaling from the receiver.</t>

		<section anchor="Router-arch" numbered="true" toc="default">
	<section anchor="Router-arch" title="Router Architecture Discussion">	<name>Router Architecture Discussion</name>
	<t>(The following description is an abstraction - implementation	<t>Note that the following description is an abstraction;
	details vary.)</t>	implementation details vary.</t>

	<t>Existing router architectures may utilize multiple input queues.	<t>Existing router architectures may utilize multiple input queues.
	On a given line card, IS-IS PDUs from multiple interfaces may be	On 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	placed in a rate-limited input queue. This queue may be dedicated to
	IS-IS PDUs or may be shared with other routing related packets.</t>	IS-IS PDUs or may be shared with other routing related packets.</t>

		<t>The input queue may then pass IS-IS PDUs to a "punt queue," which
	<t>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	is 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	punt queue typically also has controls on its size and the rate at
	which packets will be punted.</t>	which packets will be punted.</t>


	<t>An input queue in the control plane may then be used to assemble	<t>An input queue in the control plane may then be used to assemble

	PDUs from multiple linecards, separate the IS-IS PDUs from other	PDUs from multiple line cards, separate the IS-IS PDUs from other
	types of packets, and place the IS-IS PDUs on an input queue	types of packets, and place the IS-IS PDUs in an input queue
	dedicated to the IS-IS protocol.</t>	dedicated to the IS-IS protocol.</t>


	<t>The IS-IS input queue then separates the IS-IS PDUs and directs	<t>The IS-IS input queue then separates the IS-IS PDUs and directs
	them to an instance-specific processing queue. The instance-specific	them to an instance-specific processing queue. The instance-specific

	processing queue may then further separate the IS-IS PDUs	processing queue may then further separate the IS-IS PDUs by type
	by type (IIHs, SNPs, and LSPs) so that separate processing threads	(IIHs, SNPs, and LSPs) so that separate processing threads with
	with varying priorities may be employed to process the incoming	varying priorities may be employed to process the incoming PDUs.</t>
	PDUs.</t>

	<t>In such an architecture, it may be difficult for IS-IS in the	<t>In such an architecture, it may be difficult for IS-IS in the

	control plane to determine what value should be advertised as a	control plane to determine what value should be advertised as a
	receive window.</t>	receive window.</t>

	<t>The following section describes an approach to congestion control	<t>The following section describes an approach to congestion control

	based on performance measured by the transmitter without dependance	based on performance measured by the transmitter without dependence
	on signaling from the receiver.</t>	on signaling from the receiver.</t>
	</section>	</section>

		<section anchor="Ex2-tx" numbered="true" toc="default">
	<section anchor="Ex2-tx" title="Guidelines for transmitter side congesti	<name>Guidelines for Transmitter-Side Congestion Controls</name>
	on controls">	<t>The approach described in this section does not depend upon
	<t>The approach described in this section does	direct signaling from the receiver. Instead, it adapts the
	not depend upon direct signaling from the receiver. Instead it	transmission rate based on measurement of the actual rate of
	adapts the transmission rate based on measurement of the actual	acknowledgments received.</t>
	rate of acknowledgments received.</t>	<t>Flow control is not used by this approach. When congestion
		control is necessary, it can be implemented based on knowledge of
	<t>Flow control is not used by this approach. When congestion control	the current flooding rate and the current acknowledgment rate. The
	is necessary, it can be implemented	algorithm used is a local matter. There is no requirement to
	based on knowledge of the current flooding	standardize it, but there are a number of aspects that serve as
	rate and the current acknowledgement rate. The algorithm used is a	guidelines that can be described. Algorithms based on this approach
	local matter. There is no requirement to standardize it but	should follow the recommendations described below. </t>
	there are a number of aspects which serve as guidelines
	which can be described. Algorithms based on this approach should
	follow the recommendations described below. </t>

	<t>A maximum LSP transmission rate (LSPTxMax) should be	<t>A maximum LSP transmission rate (LSPTxMax) should be
	configurable. This represents the fastest LSP transmission rate	configurable. This represents the fastest LSP transmission rate

	which will be attempted. This value should be applicable to all	that will be attempted. This value should be applicable to all
	interfaces and should be consistent network wide.</t>	interfaces and should be consistent network wide.</t>


	<t>When the current rate of LSP transmission (LSPTxRate) exceeds the	<t>When the current rate of LSP transmission (LSPTxRate) exceeds the
	capabilities of the receiver, the congestion control algorithm needs t o	capabilities of the receiver, the congestion control algorithm needs t o
	quickly and aggressively reduce the LSPTxRate. Slower	quickly and aggressively reduce the LSPTxRate. Slower
	responsiveness is likely to result in a larger number of	responsiveness is likely to result in a larger number of

	retransmissions which can introduce much longer delays in	retransmissions, which can introduce much longer delays in
	convergence.</t>	convergence.</t>

		<t>Dynamic increase of the rate of LSP transmission (LSPTxRate),
	<t>Dynamic increase of the rate of LSP transmission (LSPTxRate)	i.e., making the rate faster, should be done less aggressively and on
	(i.e., faster) should be done less aggressively and only be	ly be
	done when the neighbor has demonstrated its ability to sustain the	done when the neighbor has demonstrated its ability to sustain the
	current LSPTxRate.</t>	current LSPTxRate.</t>

		<t>The congestion control algorithm should not assume that the receive
	<t>The congestion control algorithm should not assume the receive
	performance of a neighbor is static, i.e., it should handle	performance of a neighbor is static, i.e., it should handle

	transient conditions which result in a slower or faster receive rate	transient conditions that result in a slower or faster receive rate
	on the part of a neighbor.</t>	on the part of a neighbor.</t>

		<t>The congestion control algorithm should consider the expected
	<t>The congestion control algorithm should consider the expected delay	delay time in receiving an acknowledgment. Therefore, it
	time in receiving an acknowledgment. It therefore incorporates the	incorporates the neighbor partialSNPInterval (<xref
	neighbor partialSNPInterval (<xref target="partialSNPI"/>) to help	target="partialSNPI" format="default"/>) to help determine whether
	determine whether acknowlegments are keeping pace with the rate of	acknowledgments are keeping pace with the rate of LSPs
	LSPs transmitted. In the absence of an advertisement of	transmitted. In the absence of an advertisement of
	partialSNPInterval, a locally configured value can be used.</t>	partialSNPInterval, a locally configured value can be used.</t>

	</section>	</section>
	</section>	</section>
	</section>	</section>

		<section anchor="IANA_Consideration" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<section anchor="IANA_Consideration1" numbered="true" toc="default">
		<name>Flooding Parameters TLV</name>
		<t>IANA has made the following allocation in the "IS-IS Top-Level TLV Co
		depoints" registry.</t>


	<section anchor="IANA_Consideration" title="IANA Considerations">	<table align="center">
	<section anchor="IANA_Consideration1" title="Flooding Parameters TLV">	<name></name>
		<thead>
		<tr>
		<th>Value</th>
		<th>Name</th>
		<th>IIH</th>
		<th>LSP</th>
		<th>SNP</th>
		<th>Purge</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">21</td>
		<td>Flooding Parameters TLV</td>
		<td>y</td>
		<td>n</td>
		<td>y</td>
		<td>n</td>
		</tr>
		</tbody>
		</table>


	<t>IANA has made the following temporary allocation from the IS-IS TLV co	</section>
	depoint registry. This document requests the allocation be made permanent.</t>	<section anchor="IANA_Consideration2" numbered="true" toc="default">
	<figure anchor="IANA_Registration" title=''>	<name>Registry: IS-IS Sub-TLV for Flooding Parameters TLV</name>
	<preamble></preamble>	<t>IANA has created the following sub-TLV registry in the "IS-IS TLV Cod
	<artwork align="center">	epoints" registry group.</t>
	Type Description IIH LSP SNP Purge	<dl newline="false" spacing="compact">
	---- --------------------------- --- --- --- ---	<dt>Name:</dt> <dd>IS-IS Sub-TLVs for Flooding Parameters TLV</dd>
	21 Flooding Parameters TLV y n y n	<dt>Registration Procedure(s):</dt> <dd>Expert Review (as defined in <
	</artwork>	xref target="RFC8126"/>)</dd>
	</figure>	<dt>Description:</dt> <dd>This registry defines sub-TLVs for the Flood
		ing Parameters TLV (21).</dd>
		<dt>Reference:</dt> <dd>RFC 9681</dd>
		</dl>
		<table anchor="Registry_Flooding" align="center">
		<name>Initial Sub-TLV Allocations for Flooding Parameters TLV</name>
		<thead>
		<tr>
		<th>Type</th>
		<th>Description</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="center">0</td>
		<td>Reserved</td>
		</tr>
		<tr>
		<td align="center">1</td>
		<td>LSP Burst Size</td>
		</tr>
		<tr>
		<td align="center">2</td>
		<td>LSP Transmission Interval</td>
		</tr>
		<tr>
		<td align="center">3</td>
		<td>LSPs per PSNP</td>
		</tr>
		<tr>
		<td align="center">4</td>
		<td>Flags</td>
		</tr>
		<tr>
		<td align="center">5</td>
		<td>Partial SNP Interval</td>
		</tr>
		<tr>
		<td align="center">6</td>
		<td>Receive Window</td>
		</tr>
		<tr>
		<td align="center">7-255</td>
		<td>Unassigned</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="IANA_Consideration3" numbered="true" toc="default">
		<name>Registry: IS-IS Bit Values for Flooding Parameters Flags Sub-TLV</
		name>
		<t>IANA has created a new registry, in the "IS-IS TLV Codepoints" regist
		ry group, for assigning Flag bits advertised in the Flags sub-TLV.</t>
		<dl newline="false" spacing="compact">
		<dt>Name:</dt> <dd>IS-IS Bit Values for Flooding Parameters Flags Sub-
		TLV</dd>
		<dt>Registration Procedure:</dt> <dd>Expert Review</dd>
		<dt>Description:</dt> <dd><t>This registry defines bit values for the
		Flags sub-TLV (4) advertised in the Flooding Parameters TLV (21).</t></dd>
		<dt>Note:</dt><dd><t>In order to minimize encoding space, a new alloca
		tion should pick the smallest available value.</t></dd>
		<dt>Reference:</dt> <dd>RFC 9681</dd>
		</dl>
		<table anchor="Registry_Flags" align="center">
		<name>Initial Bit Allocations for Flags Sub-TLV</name>
		<thead>
		<tr>
		<th>Bit #</th>
		<th>Description</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>Ordered acknowledgment (O-flag)</td>
		</tr>
		<tr>
		<td>1-63</td>
		<td>Unassigned</td>
		</tr>
		</tbody>
		</table>
		</section>
		</section>
		<section anchor="Security" toc="default" numbered="true">
		<name>Security Considerations</name>
		<t>Security concerns for IS-IS are addressed in <xref target="ISO10589"
		format="default"/>, <xref target="RFC5304" format="default"/>, and
		<xref target="RFC5310" format="default"/>. These documents describe
		mechanisms that provide for the authentication and integrity of IS-IS
		PDUs, including SNPs and IIHs. These authentication mechanisms are not
		altered by this document.</t>
		<t>With the cryptographic mechanisms described in <xref
		target="RFC5304" format="default"/> and <xref target="RFC5310"
		format="default"/>, an attacker wanting to advertise an incorrect
		Flooding Parameters TLV would have to first defeat these mechanisms.</t>
		<t>In the absence of cryptographic authentication, as IS-IS does not run
		over IP but directly over the link layer, it's considered difficult to
		inject a false SNP or IIH without having access to the link layer.</t>
		<t>If a false SNP or IIH is sent with a Flooding Parameters TLV set to
		conservative values, the attacker can reduce the flooding speed between
		the two adjacent neighbors, which can result in LSDB inconsistencies and
		transient forwarding loops. However, it is not significantly different
		than filtering or altering LSPs, which would also be possible with access
		to the link layer. In addition, if the downstream flooding neighbor has
		multiple IGP neighbors (which is typically the case for reliability or
		topological reasons), it would receive LSPs at a regular speed from its
		other neighbors and hence would maintain LSDB consistency.</t>
		<t>If a false SNP or IIH is sent with a Flooding Parameters TLV set to
		aggressive values, the attacker can increase the flooding speed, which
		can either overload a node or more likely cause loss of
		LSPs. However, it is not significantly different than sending many LSPs,
		which would also be possible with access to the link layer, even with
		cryptographic authentication enabled. In addition, IS-IS has procedures
		to detect the loss of LSPs and recover.</t>
		<t>This TLV advertisement is not flooded across the network but only
		sent between adjacent IS-IS neighbors. This would limit the consequences
		in case of forged messages and also limit the dissemination of such
		information.</t>
		</section>


	</section>	</middle>
		<back>
		<displayreference target="I-D.ietf-lsr-dynamic-flooding" to="DYNAMIC-FLOODIN
		G"/>
		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		304.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		310.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		298.xml"/>


	<section anchor="IANA_Consideration2" title="Registry: IS-IS Sub-TLV for	<reference anchor="ISO10589" target="https://www.iso.org/standard/30932.
	Flooding Parameters TLV">	html">
	<t>This document creates the following sub-TLV Registry under the "IS-IS	<front>
	TLV Codepoints" grouping:</t>	<title>Information technology - Telecommunications and information e
	<t>Name: IS-IS Sub-TLVs for Flooding Parameters TLV.</t>	xchange between systems - Intermediate system to Intermediate system intra-domai
	<t>Registration Procedure(s): Expert Review</t>	n routeing information exchange protocol for use in conjunction with the protoco
	<t>Expert(s): TBD</t>	l for providing the connectionless-mode network service (ISO 8473)</title>
	<t>Description: This registry defines sub-TLVs for the Flooding Parameter	<author>
	s TLV(21).</t>	<organization abbrev="ISO/IEC">International Organization for Stan
	<t>Reference: This document.</t>	dardization/International Electrotechnical Commission</organization>
	<texttable anchor="Registry_Flooding" title="Initial Sub-TLV allocations	</author>
	for Flooding Parameters TLV">	<date month="Nov" year="2002"/>
	<ttcol align='center'>Type</ttcol>	</front>
	<ttcol align='left'>Description</ttcol>	<seriesInfo name="ISO/IEC" value="10589:2002"/>
	<c>0</c>	<refcontent>Second Edition</refcontent>
	<c>Reserved</c>	</reference>
	<c>1</c>
	<c>LSP Burst Size</c>
	<c>2</c>
	<c>LSP Transmission Interval</c>
	<c>3</c>
	<c>LSPs Per PSNP</c>
	<c>4</c>
	<c>Flags</c>
	<c>5</c>
	<c>Partial SNP Interval</c>
	<c>6</c>
	<c>Receive Window</c>
	<c>7-255</c>
	<c>Unassigned</c>
	</texttable>
	</section>


	<section anchor="IANA_Consideration3" title="Registry: IS-IS Bit Values f	</references>
	or Flooding Parameters Flags Sub-TLV">	<references>
	<t>This document requests IANA to create a new registry, under the "IS-IS	<name>Informative References</name>
	TLV Codepoints" grouping, for assigning Flag bits advertised in the Flags sub- T
	LV.</t>


	<t>Name: IS-IS Bit Values for Flooding Parameters Flags Sub-TLV.</t>	<!-- [I-D.ietf-lsr-dynamic-flooding] IESG state: RFC Ed Queue as of 05/14/24 -->
		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ls
		r-dynamic-flooding.xml"/>


	<t>Registration Procedure: Expert Review</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		293.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		002.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		973.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		681.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		126.xml"/>
		</references>
		</references>


	<t>Expert Review Expert(s): TBD</t>	<section anchor="Acknowledgments" numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>The authors would like to thank <contact fullname="Henk Smit"/>,
		<contact fullname="Sarah Chen"/>, <contact fullname="Xuesong Geng"/>,
		<contact fullname="Pierre Francois"/>, <contact fullname="Hannes
		Gredler"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Mirja
		Kuehlewind"/>, <contact fullname="Zaheduzzaman Sarker"/>, and <contact
		fullname="John Scudder"/> for their reviews, comments, and
		suggestions.</t>
		<t>The authors would like to thank <contact fullname="David Jacquet"/>,
		<contact fullname="Sarah Chen"/>, and <contact fullname="Qiangzhou
		Gao"/> for the tests performed on commercial implementations and for
		their identification of some limiting factors.</t>
		</section>


	<t>Description: This registry defines bit values for the Flags sub-TLV(	<section anchor="Contributors" numbered="false" toc="default">
	4) advertised in the Flooding Parameters TLV(21).</t>	<name>Contributors</name>
	<t>Note: In order to minimize encoding space, a new allocation should p	<t>The following people gave substantial contributions to the content of t
	ick the smallest available value.</t>	his document and should be considered as coauthors:</t>


	<t>Reference: This document.</t>	<contact fullname="Jayesh J">
		<organization>Ciena</organization>
		<address>
		<email>jayesh.ietf@gmail.com</email>
		</address>
		</contact>


	<texttable anchor="Registry_Flags" title="Initial bit allocations for Fla	<contact fullname="Chris Bowers">
	gs Sub-TLV">	<organization>Juniper Networks</organization>
	<ttcol align='center'>Bit #</ttcol>	<address>
	<ttcol align='left'>Description</ttcol>	<email>cbowers@juniper.net</email>
	<c>0</c>	</address>
	<c>Ordered acknowledgement (O-flag)</c>	</contact>
	<c>1-63</c>
	<c>Unassigned</c>	<contact fullname="Peter Psenak">
	</texttable>	<organization>Cisco Systems</organization>
		<address>
		<email>ppsenak@cisco.com</email>
		</address>
		</contact>

	</section>	</section>

	</section>


	<section anchor="Security" title="Security Considerations" toc="default">	<!-- [rfced] Terminology


	<t>	A) RWIN vs. rwin
	Security concerns for IS-IS are addressed in <xref target="ISO10589"/>	Please review; both forms appear in Sections 6.2.1 and 6.2.2.1.
	,	If these refer to the same concept, should these be made consistent?
	<xref target="RFC5304"/>	(Perhaps all caps "RWIN" is meant to refer to the value held in the Receive
	, and <xref target="RFC5310"/>	Window sub-TLV, whereas "rwin" is for the receive window size itself?)
	. These documents
	describe mechanisms that provide for the authentication and integrity of IS-
	IS
	PDUs, including SNPs and IIHs. These authentication mechanisms are not
	altered by this document.</t>
	<t>
	With the cryptographic mechanisms described in <xref target="RFC5304"/>
	and <xref target="RFC5310"/>
	, an attacker wanting to advertise an incorrect
	Flooding Parameters TLV would have to first defeat these mechanisms.
	</t>
	<t>In the absence of cryptographic authentication, as IS-IS does not run over IP
	but directly over the link layer, it's considered difficult to inject false SNP
	/IIH without having access to the link layer.</t>
	<t>If a false SNP/IIH is sent with a Flooding Parameters TLV set to conservative
	values, the attacker can reduce the flooding speed between the two adjacent nei
	ghbors which can result in LSDB inconsistencies and transient forwarding loops.
	However, it is not significantly different than filtering or altering LSPs which
	would also be possible with access to the link layer. In addition, if the downs
	tream flooding neighbor has multiple IGP neighbors, which is typically the case
	for reliability or topological reasons, it would receive LSPs at a regular speed
	from its other neighbors and hence would maintain LSDB consistency.</t>
	<t>If a false SNP/IIH is sent with a Flooding Parameters TLV set to aggressive v
	alues, the attacker can increase the flooding speed which can either overload a
	node or more likely generate loss of LSPs. However, it is not significantly diff
	erent than sending many LSPs which would also be possible with access to the lin
	k layer, even with cryptographic authentication enabled. In addition, IS-IS has
	procedures to detect the loss of LSPs and recover.</t>
	<t>This TLV advertisement is not flooded across the network but only sent betwee
	n adjacent IS-IS neighbors. This would limit the consequences in case of forged
	messages, and also limits the dissemination of such information.</t>
	</section>


	<section anchor="Contributors" title="Contributors">	B) acknowledgement vs. acknowledgment
	<t>The following people gave a substantial contribution to the content of this d	FYI, usage was mixed; we have updated to the latter form (no 'e').
	ocument and should be considered as coauthors:<list style="symbols">	We note that form was used slightly more in this document, and
	<t>Jayesh J, Ciena, jayesh.ietf@gmail.com</t>	it is used more commonly in the normative references of this document.
	<t>Chris Bowers, Juniper Networks, cbowers@juniper.net</t>	We will ask IANA to update to "Ordered acknowledgment (O-flag)"
	<t>Peter Psenak, Cisco Systems, ppsenak@cisco.com</t>	in the registry on https://www.iana.org/assignments/isis-tlv-codepoints.
	</list></t>
	</section>


	<section anchor="Acknowledgments" title="Acknowledgments">	C) Per vs. per
	<t>The authors would like to thank Henk Smit, Sarah Chen, Xuesong Geng, Pierre F	We suggest lowercase 'per' be used consistently in "LSP per PSNP"
	rancois, Hannes Gredler, Acee Lindem, Mirja Kuhlewind, Zaheduzzaman Sarker and J	(singular) and "LSPs per PSNP" (plural), even though the acronym "LPP" is
	ohn Scudder for their reviews, comments and suggestions.</t>	used. FYI, we have updated the document in that manner. If you agree, we
	<t>The authors would like to thank David Jacquet, Sarah Chen, and Qiangzhou Gao	will ask IANA to update the capitalization in the registry
	for the tests performed on commercial implementations and their identification o	(https://www.iana.org/assignments/isis-tlv-codepoints) accordingly.
	f some limiting factors.</t>
	</section>	Current:
	</middle>	LSP per PSNP (LPP) sub-TLV
	<back>	LSPs per PSNP (LPP)
	<references title="Normative References">	-->
	<?rfc include="reference.RFC.2119"?>
	<?rfc include="reference.RFC.8174"?>	<!-- [rfced] FYI, we updated the following abbreviations to expand upon
	<?rfc include="reference.RFC.5304"?>	first occurrence and to use them as abbreviations for the remainder of
	<?rfc include="reference.RFC.5310"?>	the document.
	<?rfc include="reference.RFC.6298"?>
	<reference anchor="ISO10589">	LSDB - Link State Databases
	<front>	CSNPs - Complete Sequence Number PDUs
	<title>Intermediate system to Intermediate system intra-domain routeing i	SNPs - Sequence Number PDUs
	nformation exchange protocol for use in conjunction with the protocol for provid	PSNPs - Partial Sequence Number PDUs
	ing the connectionless-mode Network Service (ISO 8473)</title>	(There is a separate question re: Partial SNP Interval sub-TLV.)
	<author>	-->
	<organization abbrev="ISO">International Organization for Standar
	dization</organization>	<!-- [rfced] FYI, the final paragraph of Section 4.7 has been put in an
	</author>	<aside> element. Please review.
	<date month="Nov" year="2002"/>	Also, please let us know whether any of the other notes in this
	</front>	document should be in the <aside> element. It is defined as "a container
	<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>	for content that is semantically less important or tangential to the
	</reference>	content that surrounds it"
	</references>	(https://authors.ietf.org/rfcxml-vocabulary#aside).
	<references title="Informative References">
	<?rfc include="reference.I-D.ietf-lsr-dynamic-flooding"?>	Current:
	<?rfc include="reference.RFC.9293"?>	\| Note: The focus of work used to develop the example algorithms
	<?rfc include="reference.RFC.9002"?>	\| discussed later in this document focused on operation over
	<?rfc include="reference.RFC.2973"?>	\| point-to-point interfaces. A full discussion of how best to do
	<?rfc include="reference.RFC.5681"?>	\| faster flooding on a LAN interface is therefore out of scope
	</references>	\| for this document.
	<section anchor="authors-notes" title="Changes / Author Notes">	-->
	<t>[RFC Editor: Please remove this section before publication]</t>
	<t>IND 00: Initial version.</t>	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	<t>WG 00: No change.</t>	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	<t>WG 01: IANA allocated code point.</t>	and let us know if any changes are needed. Updates of this nature typically
	<t>WG 02: No change.</t>	result in more precise language, which is helpful for readers.
	<t>WG 03: <list style="symbols">
	<t>Pacing section added (taken from RFC 9002).</t>	Note that our script did not flag any words in particular, but this should
	<t>Some text borrowed from RFC 9002 (QUIC Loss Detection and Congestion C	still be reviewed as a best practice.
	ontrol).</t>	-->
	<t>Considerations on the special role of the DIS.</t>
	<t>Editorial changes.</t>	<!-- [rfced] For Tony Przygienda, would you like to include the ZIP code
	</list></t>	in your postal address (seemingly 94089), or is it intentional to not
	<t>WG 04: Update IANA section as per IANA editor comments (2023-03-23).</t>	include it?
	<t>WG 06: AD review.</t>
	</section>	Current:
	</back>	Tony Przygienda
		Juniper
		1137 Innovation Way
		Sunnyvale, CA
		United States of America
		Email: prz@juniper.net
		-->
		</back>
	</rfc>	</rfc>

End of changes. 95 change blocks.
	1171 lines changed or deleted	1282 lines changed or added
This html diff was produced by rfcdiff 1.48.