< draft-decraene-lsr-isis-flooding-speed-00.txt   draft-decraene-lsr-isis-flooding-speed-01.txt >
Network Working Group B. Decraene Network Working Group B. Decraene
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track C. Bowers Intended status: Standards Track C. Bowers
Expires: December 28, 2019 Jayesh. J Expires: January 6, 2020 Jayesh. J
Juniper Networks, Inc. Juniper Networks, Inc.
T. Li T. Li
Arista Networks Arista Networks
G. Van de Velde G. Van de Velde
Nokia Nokia
June 26, 2019 July 5, 2019
IS-IS Flooding Speed advertisement IS-IS Flooding Speed advertisement
draft-decraene-lsr-isis-flooding-speed-00 draft-decraene-lsr-isis-flooding-speed-01
Abstract Abstract
This document proposes a mechanism that can be used to increase the This document proposes a mechanism that can be used to increase the
speed at which link state information is flooded across a network speed at which link state information is flooded across a network
when multiple LSPDUs need to be flooded, such as in case of a node when multiple LSPDUs need to be flooded, such as in case of a node
failure. It also reduces the likelihood of overloading the failure. It also reduces the likelihood of overloading the
downstream flooding neighbors. This document defines a new TLV to be downstream flooding neighbors. This document defines a new TLV to be
advertised in IS-IS Hello messages. This TLV carries two parameters advertised in IS-IS Hello messages. This TLV carries two parameters
indicating the performance capacity to receive LSPDUs: the minimum indicating the performance capacity to receive LSPDUs: the minimum
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Flooding Speed TLV . . . . . . . . . . . . . . . . . . . . . 4 2. Flooding Speed TLV . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Interaction with other LSPDU rate limiting mechanisms . . . . 5 4. Interaction with other LSPDU rate limiting mechanisms . . . . 6
5. Determining values to be advertised in the Flooding Speed TLV 6 5. Determining values to be advertised in the Flooding Speed TLV 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 8 Appendix A. Changes / Author Notes . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
IGP flooding is paramount for Link State IGP as routing computations IGP flooding is paramount for Link State IGP as routing computations
assume that the Link State DataBases (LSDBs) are always in sync assume that the Link State DataBases (LSDBs) are always in sync
across all nodes in the flooding domain. across all nodes in the flooding domain.
Slow flooding directly translates to delayed network reaction to Slow flooding directly translates to delayed network reaction to
skipping to change at page 3, line 10 skipping to change at page 3, line 10
micro-loops leading to packets losses, link(s) overload, and jitter micro-loops leading to packets losses, link(s) overload, and jitter
for all classes of services. Note that the link(s) affected by those for all classes of services. Note that the link(s) affected by those
forwarding issues may be any link in the network and not necessarely forwarding issues may be any link in the network and not necessarely
the links whose IGP status has changed. the links whose IGP status has changed.
IGP flooding is hard. One would want fast flooding when the network IGP flooding is hard. One would want fast flooding when the network
is stable and slow enough flooding to not overload the neighbor(s) is stable and slow enough flooding to not overload the neighbor(s)
when the network is less stable. Since flooding is performed hop by when the network is less stable. Since flooding is performed hop by
hop, not overloading the adjacent neighbors is sufficient. This hop, not overloading the adjacent neighbors is sufficient. This
document addresses these requirements by shaping LSPDUs with a document addresses these requirements by shaping LSPDUs with a
minimal delay between two consecutives LSPDUs. This flooding minimal delay between two consecutive LSPDUs. This flooding behavior
behavior is already largely implemented by most implementations and is already largely implemented by most implementations and hence
hence doesn't require changes in the basic flooding behavior. doesn't require changes in the basic flooding behavior. However
However existing implementations rely on a shaping delay configured existing implementations rely on a shaping delay configured on the
on the node sending the LSPDUs. But since the need is to not node sending the LSPDUs. But since the need is to not overload the
overload the downstream flooding node, the need is for the upstream downstream flooding node, the need is for the upstream flooding node
flooding nodee to know the receiving speed of its downstream flooding to know the receiving speed of its downstream flooding neighbors.
neighbors. Although in theory this parameter could be configured on Although in theory this parameter could be configured on each
each upstream flooding node, given the knowledge of each of its upstream flooding node, given the knowledge of each of its neighbor
neighbor in the topology and the receiving speed of those neighbors, in the topology and the receiving speed of those neighbors, in
in practice this configuration is difficult to maintain over time as practice this configuration is difficult to maintain over time as the
the network topology change. In addition, as things currently stand, network topology change. In addition, as things currently stand,
each network operator needs to evaluate the receiving capbility of each network operator needs to evaluate the receiving capacity of
each type of platform, depending on its hardware, software version each type of platform, depending on its hardware, software version
and number of IS-IS adjacencies. Such platform performance is better and number of IS-IS adjacencies. Such platform performance is better
known by its designer (the vendor) and even if validation tests are known by its designer (the vendor) and even if validation tests are
required, one single validation test by the vendor is more effective required, one single validation test by the vendor is more effective
than N validations from N network providers. Finally, the reasoning than N validations from N network providers. Finally, the reasoning
behind the original choices of default value is not clear. Default behind the original choices of default value is not clear. Default
values have largely remained unchanged over many years, despite very values have largely remained unchanged over many years, despite very
large increases in interface speeds and processing speed. This has large increases in interface speeds and processing speed. This has
resulted in default values that are likely to be very sub-optimal. resulted in default values that are likely to be very sub-optimal.
For example, typical default values are one LSPDU per 33ms or 100ms, For example, typical default values are one LSPDU per 33ms or 100ms,
resulting in a capabilty to only send 30 or 10 LSPDUs per second. resulting in the ability to only send 30 or 10 LSPDUs per second.
However, the same vendors recommend setting a BGP DDoS policer to However, the same vendors recommend setting a BGP DDoS policer to
10,000 packets per second or more on the same control plane hardware, 10,000 packets per second or more on the same control plane hardware,
indicating that the control plane is capable of processing BGP indicating that the control plane is capable of processing BGP
packets at a rate of 10,000 packets per second. packets at a rate of 10,000 packets per second.
This document proposes that the downstream flooding node advertises This document proposes that the downstream flooding node advertises
its LSPDU receiving speed for a single interface to the upstream its LSPDU receiving speed for a single interface to the upstream
flooding node in IS-IS hellos. This allows the sender to take into flooding node in IS-IS hellos. This allows the sender to take into
account the actual speed of the receiver. It also creates an account the actual speed of the receiver. It also creates an
incentive for vendors to improve this speed over time and to innovate incentive for vendors to improve this speed over time and to innovate
skipping to change at page 4, line 36 skipping to change at page 4, line 36
Type is TBD1. Type is TBD1.
Length is 4 octets. Length is 4 octets.
Value field has two two-octets fields: Value field has two two-octets fields:
o minimumInterfaceLSPTransmissionInterval: the minimum interval, in o minimumInterfaceLSPTransmissionInterval: the minimum interval, in
milliseconds, between two LSPDUs consecutively sent by the milliseconds, between two LSPDUs consecutively sent by the
upstream flooding node on a single interface; upstream flooding node on a single interface;
o maximumInterfaceLSPTransmissionBurst: the maximum number of LSPDUs o maximumInterfaceLSPTransmissionBurst: the maximum number of un-
that can be transmitted by the upstream flooding node on a single acknowledged LSPDUs that can be transmitted by the upstream
interface with a separation interval shorter than flooding node on a single interface with a separation interval
minimumInterfaceLSPTransmissionInterval (or even 'back to back'). shorter than minimumInterfaceLSPTransmissionInterval (or even
'back to back').
+-----------------------------------------------------+ +-----------------------------------------------------+
| minimumInterfaceLSPTransmissionInterval (2 octets) | | minimumInterfaceLSPTransmissionInterval (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| maximumInterfaceLSPTransmissionBurst (2 octets) | | maximumInterfaceLSPTransmissionBurst (2 octets) |
+-----------------------------------------------------+ +-----------------------------------------------------+
Figure 1: Flooding Speed TLV Figure 1: Flooding Speed TLV
3. Operation 3. Operation
By sending the Flooding Speed TLV the node advertises to its IS-IS By sending the Flooding Speed TLV the node advertises to its IS-IS
neighbhor(s) its ability to receive, from the upstream flooding neighbor(s) its ability to receive, from the upstream flooding
neighbor receiving this Flooding Speed TLV: neighbor receiving this Flooding Speed TLV:
o minimumInterfaceLSPTransmissionInterval: the minimum interval, in o minimumInterfaceLSPTransmissionInterval: the minimum interval, in
milliseconds, between two LSPDUs consecutively sent by the milliseconds, between two LSPDUs consecutively sent by the
upstream flooding node on a single interface; upstream flooding node on a single interface;
o maximumInterfaceLSPTransmissionBurst: the maximum number of LSPDUs o maximumInterfaceLSPTransmissionBurst: the maximum number of un-
that can be transmitted by the upstream flooding node on a single acknowledged LSPDUs that can be transmitted by the upstream
interface with a separation interval shorter than flooding node on a single interface with a separation interval
minimumInterfaceLSPTransmissionInterval (or even 'back to back'). shorter than minimumInterfaceLSPTransmissionInterval (or even
'back to back').
The node sending the Flooding Speed TLV is the downstream flooding The node sending the Flooding Speed TLV is the downstream flooding
neighbor. It SHOULD be prepared to sustain, for a long duration, the neighbor. It MUST be prepared to sustain, for a long duration, the
reception of one LSPDU every minimumInterfaceLSPTransmissionInterval reception of one LSPDU every minimumInterfaceLSPTransmissionInterval
milliseconds. In addition, it SHOULD be capable of receiving milliseconds. In addition, it MUST be capable of receiving
maximumInterfaceLSPTransmissionBurst LSPDUs with a shorter separation maximumInterfaceLSPTransmissionBurst un-acknowledged LSPDUs with a
interval, provided than no more than 1000/ shorter separation interval, provided than no more than 1000/
minimumInterfaceLSPTransmissionInterval LSPDUs are transmitted in any minimumInterfaceLSPTransmissionInterval un-acknowledged LSPDUs are
one second period. transmitted in any one second period.
Note that if the above two "MUST" cannot be fulfilled because of
transient conditions, this cause no severe harm to the operation of
IS-IS as this condition 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 LSPDUs.
Note that, as per [ISO10589], the downstream flooding node
dynamically acknowledges the received LSPDUs by sending CSNP or PSNP
. By acknowledging the LSPDUs before the
maximumInterfaceLSPTransmissionBurst is exhausted, the downstream
flooding neighbor can achieve dynamic flow control and increase the
flooding speed with its upstream flooding node without risking to
overload any IS-IS router. If the
maximumInterfaceLSPTransmissionBurst is large enough, on a point to
point interface the downstream flooding node can acknowledge a set of
multiple LSPDUs up to the maximum size of a PSNP (up to 90 LPDUs)
which allows dynamic flow control without even increasing the number
of PSNPs.
The node receiving the Flooding Speed TLV is the upstream flooding The node receiving the Flooding Speed TLV is the upstream flooding
neighbor. The upstream flooding neighbor MUST NOT transmit LSPDUs at neighbor. The upstream flooding neighbor MUST NOT transmit LSPDUs at
a sustained rate greater than one LSPDU every a sustained rate greater than one LSPDU every
minimumInterfaceLSPTransmissionInterval milliseconds. The upstream minimumInterfaceLSPTransmissionInterval milliseconds. The upstream
flooding neighbor MAY transmit maximumInterfaceLSPTransmissionBurst flooding neighbor MAY transmit maximumInterfaceLSPTransmissionBurst
LSPDUs with a shorter separation interval, provided than no more than un-acknowledged LSPDUs with a shorter separation interval, provided
1000/minimumInterfaceLSPTransmissionInterval LSPDUs are transmitted than no more than 1000/minimumInterfaceLSPTransmissionInterval LSPDUs
in any one second period. are transmitted in any one second period.
4. Interaction with other LSPDU rate limiting mechanisms 4. Interaction with other LSPDU rate limiting mechanisms
[ISO10589] describes a mechanism that limits the rate at which LSPDUs [ISO10589] describes a mechanism that limits the rate at which LSPDUs
from the same source system are sent out all interfaces. (See the from the same source system are sent out all interfaces. (See the
description of the parameter minimumLSPTransmissionInterval in description of the parameter minimumLSPTransmissionInterval in
sections 7.3.21 and 7.3.15.5 of [ISO10589] .) In practice, however, sections 7.3.21 and 7.3.15.5 of [ISO10589] .) In practice, however,
router vendors have implemented mechanisms that limit the rate of router vendors have implemented mechanisms that limit the rate of
LSPDUs sent on a given interface. This is often configurable on a LSPDUs sent on a given interface. This is often configurable on a
per-interface basis using 'lsp-interval' or 'lsp-pacing-interval' CLI per-interface basis using 'lsp-interval' or 'lsp-pacing-interval' CLI
skipping to change at page 6, line 10 skipping to change at page 6, line 32
interface, by using parameters advertised by the downstream flooding interface, by using parameters advertised by the downstream flooding
neighbor. When the mechanism described in the current document is neighbor. When the mechanism described in the current document is
used, the mechanism described in section 7.3.15.5 of [ISO10589] is used, the mechanism described in section 7.3.15.5 of [ISO10589] is
not used. not used.
5. Determining values to be advertised in the Flooding Speed TLV 5. Determining values to be advertised in the Flooding Speed TLV
The values that a downstream flooding neighbor advertises in the The values that a downstream flooding neighbor advertises in the
Flooding Speed TLV should not change often. For example, in order to Flooding Speed TLV should not change often. For example, in order to
compute the values in the Flooding Speed TLV, a reasonable choice compute the values in the Flooding Speed TLV, a reasonable choice
might be for a node to use a formula based on an offline tests of the might be for a node to use a formula based on an off line tests of
overall LSPDU processing speed for a particular set of hardware and the overall LSPDU processing speed for a particular set of hardware
the number of interfaces configured for IS-IS. With such a formula, and the number of interfaces configured for IS-IS. With such a
the values advertised in the Flooding Speed TLV would only change formula, the values advertised in the Flooding Speed TLV would only
when additional IS-IS interfaces are configured. On the other hand, change when additional IS-IS interfaces are configured. On the other
it would be undesirable to use a formula that depends, for example, hand, it would be undesirable to use a formula that depends, for
on an active measurement of the CPU load to modify the values example, on an active measurement of the CPU load to modify the
advertised in the Flooding Speed TLV. This could introduce feedback values advertised in the Flooding Speed TLV. This could introduce
into the IGP flooding process that could produce unexpected behavior. feedback into the IGP flooding process that could produce unexpected
Since correct IGP flooding is so fundamental to network operation, we behavior. Since correct IGP flooding is so fundamental to network
do not want to introduce new dynamic behavior to it. By requiring operation, we do not want to introduce new dynamic behavior to it.
that the values advertised in the Flooding Speed TLV not change very By requiring that the values advertised in the Flooding Speed TLV not
often, we expect to produce overall flooding behavior similar to what change very often, we expect to produce overall flooding behavior
might be acheived by manually configuring per-interface LSPDU rate similar to what might be achieved by manually configuring per-
limiting on all interfaces in the network. interface LSPDU rate limiting on all interfaces in the network.
6. IANA Considerations 6. IANA Considerations
IANA is requested to allocate one TLV from the IS-IS TLV codepoint IANA is requested to allocate one TLV from the IS-IS TLV codepoint
registry. registry.
Type Description IIH LSP SNP Purge Type Description IIH LSP SNP Purge
---- --------------------------- --- --- --- --- ---- --------------------------- --- --- --- ---
TBD Flooding Speed TLV y n n n TBD Flooding Speed TLV y n n n
skipping to change at page 6, line 52 skipping to change at page 7, line 31
altered. altered.
As with others TLV advertisements, the use of a cryptographic As with others TLV advertisements, the use of a cryptographic
authentication as defined in [RFC5304] or [RFC5310] allows the authentication as defined in [RFC5304] or [RFC5310] allows the
authentication of the peer and the integrity of the message. As this authentication of the peer and the integrity of the message. As this
document defines a TLV for IS-IS Hello message (IIH), the relevant document defines a TLV for IS-IS Hello message (IIH), the relevant
cryptographic authentication is for IS-IS Hello message (IIH). cryptographic authentication is for IS-IS Hello message (IIH).
In the absence of cryptographic authentication, as IS-IS does not run In the absence of cryptographic authentication, as IS-IS does not run
over IP but directly over the link layer, it's considered difficult over IP but directly over the link layer, it's considered difficult
to inject false IIH without having acces to the link layer. to inject false IIH without having access to the link layer.
If a false IIH is sent with a Flooding Speed TLV set to low values, If a false IIH is sent with a Flooding Speed TLV set to low values,
the attacker can reduce the flooding speed between the two adjacent the attacker can reduce the flooding speed between the two adjacent
neighbors which can result in LSDB inconsistencies and transient neighbors which can result in LSDB inconsistencies and transient
forwarding loops. However, is not significantly different than forwarding loops. However, is not significantly different than
filtering or altering LSPDUs which would also be possible with access filtering or altering LSPDUs which would also be possible with access
to the link layer. In addition, if the downstream flooding neighbor to the link layer. In addition, if the downstream flooding neighbor
has multiple IGP neighbors, which is typically the case for has multiple IGP neighbors, which is typically the case for
reliability or topological reasons, it would receive LSPDUs at a reliability or topological reasons, it would receive LSPDUs at a
regular speed from its other neighbors and hence would maintain LSDB regular speed from its other neighbors and hence would maintain LSDB
skipping to change at page 7, line 25 skipping to change at page 8, line 6
If a false IIH is sent with a Flooding Speed TLV set to high values, If a false IIH is sent with a Flooding Speed TLV set to high values,
the attacker can increase the flooding speed which can either the attacker can increase the flooding speed which can either
overload a node or more likely generate loss of LSPDUs. However, is overload a node or more likely generate loss of LSPDUs. However, is
not significantly different than sending many LSPDUs which would also not significantly different than sending many LSPDUs which would also
be possible with access to the link layer, even with cryptographic be possible with access to the link layer, even with cryptographic
authentication enabled. In addition, IS-IS has procedures to detect authentication enabled. In addition, IS-IS has procedures to detect
the loss of LSPDUs and recover. the loss of LSPDUs and recover.
This TLV advertisement is not flooded across the network but only This TLV advertisement is not flooded across the network but only
sent between two adjacent IS-IS neighbhors. This would limit the sent between two adjacent IS-IS neighbors. This would limit the
consequences in case of forged messages, and also limits the consequences in case of forged messages, and also limits the
dissemination of such information. dissemination of such information.
8. Normative References 8. Normative References
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
 End of changes. 17 change blocks. 
57 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/