IS-IS Flooding Parameters advertisement
draft-decraene-lsr-isis-flooding-speed-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Bruno Decraene , Chris Bowers , Jayesh , Tony Li , Gunter Van de Velde | ||
| Last updated | 2021-06-16 | ||
| Replaced by | draft-decraeneginsberg-lsr-isis-fast-flooding | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-decraene-lsr-isis-flooding-speed-06
Network Working Group B. Decraene
Internet-Draft Orange
Intended status: Standards Track C. Bowers
Expires: December 18, 2021 Jayesh. J
Juniper Networks, Inc.
T. Li
Arista Networks
G. Van de Velde
Nokia
June 16, 2021
IS-IS Flooding Parameters advertisement
draft-decraene-lsr-isis-flooding-speed-06
Abstract
This document proposes a mechanism to adjust IS-IS flooding speed
between two adjacent routers by adjusting the sender flooding speed
to the capability of the receiver. This helps improving the flooding
throughput, reducing LSPs losses and retransmissions due to receiver
overload, and avoiding manual tuning of flooding parameters by the
network operator. This document defines a new TLV for SNP and/or
Hello messages. This TLV may carry a set of parameters indicating
the performance capacity to receive LSPs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Decraene, et al. Expires December 18, 2021 [Page 1]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flooding Parameters TLV . . . . . . . . . . . . . . . . . . . 4
3.1. InterfaceLSPReceiveWindow sub-TLV . . . . . . . . . . . . 5
3.2. minimumInterfaceLSPTransmissionInterval sub-TLV . . . . . 5
3.3. minimumLSPTransmissionInterval sub-TLV . . . . . . . . . 5
4. Flow control . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Operation on a point to point interface . . . . . . . . . 6
4.2. Faster acknowledgments of LSPs . . . . . . . . . . . . . 6
4.3. Operation on a LAN interface . . . . . . . . . . . . . . 7
5. Congestion control . . . . . . . . . . . . . . . . . . . . . 8
6. Faster loss detection and recovery . . . . . . . . . . . . . 9
7. Interaction with other LSP rate limiting mechanisms . . . . . 10
8. Determining values to be advertised in the Flooding
Parameters TLV . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
IGP flooding is paramount for Link State IGP as routing computations
assume that the Link State DataBases (LSDBs) are always in sync
across all nodes in the flooding domain.
Slow flooding directly translates to delayed network reaction to
failure and LSDB inconsistencies across nodes. The former increases
packet loss. The latter translates to routing inconsistencies and
possibly micro-loops leading to packet loss, link overload, and
jitter for all classes of service. Note that across the network,
Decraene, et al. Expires December 18, 2021 [Page 2]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
multiple links may be affected by these forwarding issues, even in
the case of a single link failure.
In addition, one single event in the network can require the flooding
of multiple LSPs. The typical case is a node failure which requires
the flooding of at least one LSP per neighbor of the failed node.
Hence, if a node has N IGP neighbors, the failure of this node
requires the advertisement and flooding of at least N LSPs. The
network won't be able to converge to the new topology until all N
LSPs are received by all nodes. Hence there is a need to be able to
quickly exchange N LSPs. This document addresses this requirement by
allowing the fast flooding of a number of consecutive LSPs.
IGP flooding is hard. One would want fast flooding when the network
is stable and slow enough flooding to not overload the neighbor(s)
when the network is less stable. Since flooding is performed hop by
hop, not overloading the adjacent receiver is sufficient.
Improving the communication speed and efficiency between IS-IS
neighbors improves IS-IS scaling. These extensions do not compete
with proposed extensions to reduce LSP flooding traffic by reducing
the flooding topology such as [I-D.ietf-lsr-dynamic-flooding]. On
the contrary, this extension complements those proposals. Indeed
reducing the flooding topology does not reduce the size of the LSDB
or the total number of LSPs to exchange between two nodes. So
increasing the overall flooding speed can be beneficial for nodes
implementing dynamic flooding. The reverse is also true: as dynamic
flooding reduces the number of neighbors with flooding enabled, this
allows nodes implementing the flooding parameter extensions to focus
their flooding resources on those neighbors by sending better
parameters to the selected flooding nodes and worse parameters to
non-selected flooding nodes.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
2. Overview
Ensuring the goodput between two entities is a layer 4 responsibility
as per the OSI model and a typical example is the TCP protocol
defined in RFC 793 [RFC0793]. It typically relies on the following
sub-functions: flow control, congestion control and reliability.
Decraene, et al. Expires December 18, 2021 [Page 3]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
Flow control is about creating a control loop between a single
transmitter and single receiver. TCP provides a mean for the
receiver to govern the amount of data sent by the sender. This is
achieved by advertising a "receive window", in units of octets, with
every ACK. This document proposes to use the same mechanism by
advertising a receive window, in units of LSP packets, in either IS-
IS xSNP (ack) or IS-IS Hello. The window indicates an allowed number
of LSPs that the sender may transmit before receiving acknowledgment
of those LSPs. There is an assumption that this is related to the
currently available data buffer space available for this adjacency.
Indicating a large window encourages transmissions.
Congestion control is about creating multiple interacting control
loops between multiple transmitters and multiple receivers. 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 consist in a link which is typically
over-sized compared to the capability of the IS-IS speakers, but also
includes components inside both routers such as a fabric switch, line
card CPU and forwarding plane buffers which may experience
congestion. For congestion avoidance in steady state TCP uses the
AIMD (Additive Increase Multiplicative Decrease) algorithm to react
to packet loss. This document proposes to use the same principle.
Reliability relies on loss detection and recovery. IS-IS already has
mechanisms to ensure the reliable transmission of LSPs. However the
reaction time is hard coded in the specification and may be too long
in some situation. This document proposes that the delay before
assuming a lost packet be advertised by the receiver. This permits a
faster receiver to allow for a faster loss detection on the sender
side.
3. Flooding Parameters TLV
This document defines a new TLV called "Flooding Parameters TLV" that
may be included in SNP and/or IIH PDUs. It allows the LSP receiver
to advertise receiver related parameters and capabilities which
allows the LSP sender to better adapt to the receiver.
Type: TBD1.
Length: variable, the size in octet of the Value field.
Value: a list of sub-TLVs.
Three sub-TLVs are defined in this document.
Decraene, et al. Expires December 18, 2021 [Page 4]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
3.1. InterfaceLSPReceiveWindow sub-TLV
The sub-TLV InterfaceLSPReceiveWindow advertises the maximum number
of un-acknowledged LSPs that the node can receive/process with no
separation interval between LSPs.
Type: 1.
Length: 4 octets.
Value: number of un-acknowledged LSPs which can be sent back to back.
3.2. minimumInterfaceLSPTransmissionInterval sub-TLV
The sub-TLV minimumInterfaceLSPTransmissionInterval advertises the
minimum interval, in micro-seconds, between LSPs arrivals which can
be processed/received on this interface, after the maximum number of
un-acknowledged LSPs has been sent.
Type: 2.
Length: 4 octets.
Value: minimum interval, in micro-seconds, between two consecutive
LSPs sent after the receive window has been used.
3.3. minimumLSPTransmissionInterval sub-TLV
The sub-TLV minimumLSPTransmissionInterval advertises the ISO
minimumLSPTransmissionInterval, in micro-seconds, that the LSP
transmitter may use.
Type: 3.
Length: 4 octets.
Value: minimum interval, in micro-seconds, before further propagating
another Link State PDU from the same source system.
4. Flow control
Flow control is about creating a control loop between a single
transmitter and single receiver. This document proposes to use a
mechanism similar to the TCP receive window to allow the receiver to
govern the amount of data sent by the sender. This receive window
indicates an allowed number of LSPs that the sender may transmit
before receiving acknowledgment of those LSPs. This receive window,
Decraene, et al. Expires December 18, 2021 [Page 5]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
in units of LSPs, is advertised in the sub-TLV
InterfaceLSPReceiveWindow in either IS-IS SNP (ack) or IS-IS Hello.
4.1. Operation on a point to point interface
By sending the InterfaceLSPReceiveWindow sub-TLV with a value N1, the
node advertises to its IS-IS neighbor, its ability to receive, over
that interface, a maximum of N1 un-acknowledged LSPs with no
separation interval. This is akin to a reception window or sliding
window in flow control.
By sending the minimumInterfaceLSPTransmissionInterval sub-TLV with a
value N2, the node advertises to its IS-IS neighbor, its ability to
receive, over that interface, after the receive window is full, LSPs
separated by at least N2 micro-seconds.
The IS transmitter MUST NOT exceed these parameters. After having
send N1 un-acknowledged LSPs, it MUST send the following LSPs with an
interval of at least N2 micro-seconds between each LSP.
Note however that if either the LSP transmitter or receiver does not
adhere to these parameters, for example because of transient
conditions, this causes no fatal condition to the operation of IS-IS.
The worst case, the loss of LSP on the IS receiver, is already
accounted for in [ISO10589]. As per [ISO10589], after a few seconds,
respectively 2 and 10 by default in [ISO10589], neighbors will
exchange PSNP (for point to point interface) or CSNP (for broadcast
interface) and recover from the lost LSPs. This worst case,
overrunning the receiver, should however be avoided as those
additional seconds are impacting the network and the traffic as the
LSDB in not fully synchronized. Hence it is better to err on the
conservative side and to underun the receiver rather then overrun it.
For a given IS-IS adjacency, the Flooding Parameters TLV does not
need to be advertised in each SNP and IIS. The IS transmitter uses
the latest value received of each parameter (sub-TLV) until a new
value is advertised by the IS receiver. Note however that CSNP and
IIH are not reliability exchanged, hence some PDU may never be
received. For a parameter which has never been advertised, the IS
transmitter use its local default value. That value SHOULD be
configurable on a per node basis and MAY be configurable on a per
interface basis.
4.2. Faster acknowledgments of LSPs
As per [ISO10589], on point to point interfaces, the LSP receiver
dynamically acknowledges the received LSPs by sending PSNP messages.
Decraene, et al. Expires December 18, 2021 [Page 6]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
By acknowledging the LSPs before the InterfaceLSPReceiveWindow is
exhausted, the receiver can achieve dynamic flow control and increase
the flooding throughput without risking to overload any IS-IS router.
If the InterfaceLSPReceiveWindow is large enough, the downstream
flooding node can acknowledge a set of multiple LSPs up to the
maximum size of a PSNP (90 LSPs) which allows dynamic flow control
with limited or even no increase in the number of sent PSNPs.
In order to avoid reducing the throughput, the receiver should avoid
letting the receive window exhaust. Therefore, the receiver SHOULD
acknowledge the LSP more quickly than the default specified in
[ISO10589]. This is beneficial both to the LSP sender which receives
faster feedback and to the LSP receiver which have more time to
acknowledge many LSPs before the sender times out and resend the LSP.
The way LSPs are acknowledged faster is a local decision on the
receiving IS.
Receiver MAY reduce partialSNPInterval. Possibly reduce it even
further when the IS-IS adjacency initially transitions to the UP
state, or when a large number of LSPs need to be received quickly, or
until the LSDB has been synchronized. The choice of this lower value
is a local choice. It may depends on the (available) processing
power of the node, the number of adjacencies been brought up at the
same time, the requirement to synchronize the LSDB more quickly.
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, the receiver
SHOULD immediately send a PSNP without waiting for the PSNP timer to
expire. In case of a burst of LSPs, this allows for more frequent
PSNPs, hence a faster feedback loop to the sender. While in the
absence of a burst of LSP, the usual time-based PSNP approach comes
into effect. By deploying both the time-based and the threshold-
based PSNP approaches, the receiver can be adaptive to both LSP
bursts and infrequent LSP updates. This number SHOULD be lower or
equal to 90 as this is the maximum number of LSPs that can be
acknowledged in a PSNP, hence waiting longer would not reduce the
number of PSNPs sent but would delay the acknoledgements. This
number SHOULD also be lower or equal to the advertised receive window
InterfaceLSPReceiveWindow, e.g., InterfaceLSPReceiveWindow/2. Based
on experimental evidence, 15 unacknowledged LSPs is a right value.
4.3. Operation on a LAN interface
On a LAN interface an IS receiver will generally receive LSPs from
many IS transmitters. And the LSPs sent by a given IS transmitter
will be received by all of the IS receivers on that LAN. In this
Decraene, et al. Expires December 18, 2021 [Page 7]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
section, we clarify how the flooding parameters should be interpreted
in the context of a LAN.
An IS receiver on a LAN will communicate its desired flooding
parameters using a single Flooding Parameters TLV, copies of which
will be received by all N transmitters. The flooding parameters sent
by the IS receiver MUST be understood as instructions from the
receiver to each transmitter about the desired maximum transmit
characteristics of each transmitter. The receiver is aware that
there are N transmitters that can send LSPs to the receiver LAN
interface. The receiver might want to take that into account by
advertising a higher value of InterfaceLSPTransmissionInterval on
this LAN interface than what it would advertise on a point to point
interface. When the transmitters receive the
InterfaceLSPTransmissionInterval value advertised by the DIS
receiver, the transmitters should rate limit LSPs according to the
advertised flooding parameters. They should not apply any further
interpretation to the flooding parameters advertised by the receiver.
A given IS transmitter will receive flooding parameter advertisements
from N different Flooding Parameters TLVs, which may carry different
flooding parameter values. A given transmitter SHOULD adjust the
flooding behavior on this LAN interface such that none of the
receivers receives more un-acknowledged LSPs or LSPs at a higher rate
than indicated by their individual flooding parameter advertisements.
In order for the InterfaceLSPReceiveWindow to be a useful parameter,
an IS transmitter needs to be able to keep track of the number of un-
acknowledged LSPs it has sent to a given IS receiver. On a LAN there
is no explicit acknowledgment of the receipt of LSPs between a given
IS transmitter and a given IS receiver. However, an IS transmitter
on a LAN can infer whether or not any IS receivers on the LAN have
requested retransmission of LSPs from the DIS by monitoring PSNPs
generated on the LAN. If no PSNPs have been generated on the LAN for
a suitable period of time, then an IS transmitter can safely set the
number of un-acknowledged LSPs to zero.
5. Congestion control
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 include in a single link
which is typically over-sized compared to the capability of the IS-IS
speakers. But also includes components inside both routers such as a
fabric switch, line card CPU and forwarding plane buffers which may
experience congestion. For congestion avoidance in steady state, TCP
uses the AIMD (Additive Increase Multiplicative Decrease) algorithm
Decraene, et al. Expires December 18, 2021 [Page 8]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
to react to packet loss. This document proposes to use the same
principle. This document proposes one congestion control algorithm
but implementations may choose a different one.
The congestion control algorithm uses
o a moderate starting rate based on the receive window advertised by
the receiver;
o an Additive Increase proportional to the number of LSPs correctly
received (acknowledged);
o an exponential reduction in case of LSP loss.
When a new set of LSPs need to be sent, the sender start with a
congestion window set to half of the receive window.
When the reception of N LSPs is acknowledged, the congestion window
is increased by N, without exceeding the received windows.
When the loss of LSP is detected, the congestion window is divided by
two.
Note that this congestion control algorithm benefits from the
extensions proposed in this document, namely the advertisement of a
receive window from the receiver (Section 4) which avoid the use of
an arbitrary value by the sender, the faster acknowledgment of LSP
(Section 4.2) which allows for a faster control loop and hence a
faster increase of the congestion window in the absence of
congestion, and the faster detection of lost LSP (Section 6) which
allows for a faster control loop and hence a decrease of the
congestion window in case of congestion.
6. Faster loss detection and recovery
As per [ISO10589], an LSP transmitter resends a un-acknowledged LSP
no sooner than minimumLSPTransmissionInterval, which is 5 seconds by
default. As the goal is to increase the speed of reliable
transmission of LSP, the transmitter should be able to retransmit
faster in case of LSP loss. The delay need to be compatible (higher)
than the partialSNPInterval or the delay needed by the IS receiver to
acknowledge the received LSPs. This document allows the receiver to
advertise to the sender a more realistic value for
minimumLSPTransmissionInterval, with a goal to advertise a smaller
value than the ISO default value and hence allow for a faster
recovery of lost LSPs.
Decraene, et al. Expires December 18, 2021 [Page 9]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
The reception of the parameter minimumLSPTransmissionInterval means
that the IS transmitter MAY set its minimumLSPTransmissionInterval to
this value or higher.
The interval advertised in minimumLSPTransmissionInterval MUST be
higher than the effective partialSNPInterval of the receiver plus the
Round Trip Time (RTT) of the interface. The effective
partialSNPInterval of the receiver is the maximum amount of time that
the receiver is expected to take to acknowledge the LSP. This would
be the partialSNPInterval on a receiver following only [ISO10589], or
an effective value if the receiver has implemented a faster method to
acknowledge LSPs, as discussed in Section 4.2. The receiver should
not be telling the transmitter to resend un-acknowledged LSPs before
the receiver had time to acknowledge LSPs it has actually received.
An LSP receiver MAY update this value depending on certain
conditions. For example, it can advertise a higher
minimumLSPTransmissionInterval value when a large number of LSPs are
been received and hence it is experiencing high load. Or it can
advertise a lower value when an LSP storm has passed, especially if
there is reason to believe that some LSPs may have been lost.
7. Interaction with other LSP rate limiting mechanisms
[ISO10589] describes a mechanism that limits the rate at which LSPs
from the same source system are sent out on interfaces. (See the
description of the parameter
minimumBroadcastLSPTranLSPTransmissionInterval in section 7.3.15.6 of
[ISO10589] .) In practice, however, router vendors have implemented
mechanisms that limit the rate of LSPs sent on a given interface.
This is often configurable on a per-interface basis using 'lsp-
interval' or 'lsp-pacing-interval' CLI configuration.) The mechanism
described in the current document extends the practice of limiting
the rate of LSPs sent on a given interface, by using parameters
advertised by the LSP receiver. When the mechanism described in the
current document is used, the mechanism described in section 7.3.15.6
of [ISO10589] is not used.
8. Determining values to be advertised in the Flooding Parameters TLV
The values that a receiving IS advertises do not need to be close to
perfection. It is OK to be too low and hence not to use the full
bandwidth or CPU resources. It is OK to be too high during some
situation and hence have the receiver drop some LSPs as the IS-IS
protocol has mechanisms to recover. What is not OK is to flood
multiple order of magnitudes slower than both nodes can achieve, or
to consistently overload the receiver.
Decraene, et al. Expires December 18, 2021 [Page 10]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
The values may not need to be dynamic as a form of dynamic is
provided by the dynamic acknowledgment of LSPs in SNP messages.
Acknowledgments provides a feedback loop on how fast/slower the LSPs
are processed by the receiver. They also signal that the LSPs have
been processed by the receiver hence removed from 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 may be based, for
example, on an off line 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.
The values MAY be updated dynamically, to reflect the relative change
of load of the receiver, by improving the values when the receiver
load is getting lower and degrading the values when the receiver load
is getting higher. For example, if LSPs are regularly dropped, or
the queue regularly comes close to being filled, then values may be
too high. On the other hand, if the queue is barely used (by IS-IS),
then values may be too low.
The values MAY may also be absolute value reflecting relevant
(averaged) hardware resources that are been monitored, typically the
amount of buffer space used by incoming LSPs. In this case, care
must be taken when choosing the parameters influencing the values, in
order to avoid undesirable or instable feedback 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
advertised in the Flooding Parameters TLV. This could introduce
feedback into the IGP flooding process that could produce unexpected
behavior.
9. IANA Considerations
IANA is requested to allocate one TLV from the IS-IS TLV codepoint
registry.
Type Description IIH LSP SNP Purge
---- --------------------------- --- --- --- ---
TBD1 Flooding Parameters TLV y n y n
Figure 1
This document creates the following sub-TLV Registry:
Decraene, et al. Expires December 18, 2021 [Page 11]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
Name: Sub-TLVs for TLV TBD1 (Flooding Parameters TLV).
Registration Procedure: Expert Review [RFC8126].
+-------+-----------------------------------------+
| Type | Description |
+-------+-----------------------------------------+
| 0 | Reserved |
| 1 | InterfaceLSPReceiveWindow |
| 2 | minimumInterfaceLSPTransmissionInterval |
| 3 | minimumLSPTransmissionInterval |
| 4-255 | Unassigned |
+-------+-----------------------------------------+
Table 1: Initial allocations
10. Security Considerations
Any new security issues raised by the procedures in this document
depend upon the ability of an attacker to inject a false but
apparently valid SNP or IIH, the ease/difficulty of which has not
been altered.
As with others TLV advertisements, the use of a cryptographic
authentication as defined in [RFC5304] or [RFC5310] allows the
authentication of the peer and the integrity of the message. As this
document defines a TLV for SNP or IIH message, the relevant
cryptographic authentication is for SNP and IIH message.
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/IHH without having access to the link layer.
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 neighbors which can result in LSDB
inconsistencies and transient forwarding loops. However, it is not
significantly different than filtering or altering LSPDUs 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.
If a false SNP/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 generate loss of LSPs.
However, it is not significantly different than sending many LSPs
Decraene, et al. Expires December 18, 2021 [Page 12]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
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.
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 limits the
dissemination of such information.
11. Acknowledgments
The authors would like to thank Henk Smit, Sarah Chen, and Xuesong
Geng for their reviews, comments and suggestions.
The authors would like to thank David Jacquet, Sarah Chen, and
Qiangzhou Gao for the tests performed on commercial implementations
and their identification of some limiting factors.
12. References
12.1. Normative References
[ISO10589]
International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Decraene, et al. Expires December 18, 2021 [Page 13]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.ietf-lsr-dynamic-flooding]
Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda,
T., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra,
"Dynamic Flooding on Dense Graphs", draft-ietf-lsr-
dynamic-flooding-08 (work in progress), December 2020.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
Appendix A. Changes / Author Notes
[RFC Editor: Please remove this section before publication]
00: Initial version.
01: Two notes added in section 3 "Operation".
02: Refresh, no technical change.
03:
o Flooding Parameters TLV: name changed, advertised in both Hello
and SNP rather than just Hello, contains sub-TLVs, parameters
encoded in 4 octets.
o Terminology: upstream/downstream terms removed, in favor of terms
from ISO specification (transmitter, receiver); burst-size rename
to receive-window.
o Significant editorials changes.
o New section on the faster acknowledgment of LSPs.
o New section on the faster retransmission of lost LSPs.
04:
o Adding general introduction on flow control, congestion control,
loss detection and recovery.
Decraene, et al. Expires December 18, 2021 [Page 14]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
o Reorganizing sections as per the high level functions: flow
control, congestion control, loss detection and recovery.
o Adding a section on congestion control.
05:
o Some editorials changes.
o Updating section "Faster acknowledgements of LSPs" following the
IS-IS flooding performance tests presented during IETF 108.
o Updated IANA section (new registry).
Authors' Addresses
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Chris Bowers
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: cbowers@juniper.net
Jayesh J
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: jayeshj@juniper.net
Tony Li
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
USA
Email: tony.li@tony.li
Decraene, et al. Expires December 18, 2021 [Page 15]
Internet-Draft IS-IS Flooding Parameters advertisement June 2021
Gunter Van de Velde
Nokia
Copernicuslaan 50
Antwerp 2018
Belgium
Email: gunter.van_de_velde@nokia.com
Decraene, et al. Expires December 18, 2021 [Page 16]