Internet DRAFT - draft-hsmit-lsr-isis-flooding-over-tcp
draft-hsmit-lsr-isis-flooding-over-tcp
Link-State Routing H. Smit, Ed.
Internet-Draft
Intended status: Standards Track G. Van de Velde
Expires: April 15, 2019 Nokia
October 12, 2018
IS-IS Flooding over TCP
draft-hsmit-lsr-isis-flooding-over-tcp-00
Abstract
This document proposes a solution to use TCP for IS-IS flooding. The
proposed solution is a relative simple extension to implement. IS-IS
flooding over TCP brings BGP's property of scalable transport via TCP
to Link-State protocols.
This proposal defines a new TLV in point-to-point IIHs to signal the
intent of a router to do flooding over TCP, and it defines a small
header to encapsulate IS-IS PDUs in the TCP byte-stream.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
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 April 15, 2019.
Smit & Van de Velde Expires April 15, 2019 [Page 1]
Internet-Draft IS-IS Flooding over TCP October 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General scaling factors of IS-IS . . . . . . . . . . . . . . 3
2.1. Current scaling limitations of IS-IS flooding . . . . . . 4
2.1.1. Packet pacing and throughput . . . . . . . . . . . . 4
2.1.2. Reliable flooding on point-to-point interfaces . . . 4
2.1.3. Unreliability of CSNPs . . . . . . . . . . . . . . . 5
3. Improvements for IS-IS flooding . . . . . . . . . . . . . . . 6
3.1. Using TCP to do IS-IS flooding . . . . . . . . . . . . . 6
4. Negotiating Flooding over TCP . . . . . . . . . . . . . . . . 7
4.1. The new TLV to indicate that a router wants to flood over
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Format of messages over TCP . . . . . . . . . . . . . . . . . 8
6. New behaviour of IS-IS flooding . . . . . . . . . . . . . . . 9
6.1. Establishing a new IS-IS adjacency . . . . . . . . . . . 9
6.2. Behaviour during the existence of an IS-IS adjacency . . 10
7. Considerations regarding IS-IS flooding over TCP . . . . . . 11
7.1. Flooding over TCP is only done on point-to-point
interfaces . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Unnumbered interfaces and reachability of the interface
ip-address . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Multiple levels of hierarchy on one interface . . . . . . 12
7.4. Downsides of using TCP for IS-IS flooding . . . . . . . . 12
7.5. What to do if the TCP connection breaks . . . . . . . . . 12
7.6. What to do if the TCP connection can not be set up . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Smit & Van de Velde Expires April 15, 2019 [Page 2]
Internet-Draft IS-IS Flooding over TCP October 2018
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
IP Fabric Networks in data-centers are growing larger and larger.
The number of routers in such fabrics are pushing the boundaries of
routing protocols. Therefor new ideas are explored, and existing
protocols are being enhanced (RFC 7938 [2], RIFT [5] and LSVR [4]).
This document improves an existing protocol, IS-IS. One of the
scaling limitations of IS-IS is its flooding algorithm. BGP is known
to be a routing protocol of high scale. A key property and important
benefit of BGP is the fact that BGP uses TCP as transport mechanism.
Introducing TCP to IS- IS flooding would bring a major positive
scaling property from BGP to IS-IS.
2. General scaling factors of IS-IS
IS-IS is a highly scalable Interior Gateway Protocol (IGP). IS-IS is
defined in ISO-10589 [3]. Networks with thousands of routers have
been deployed. When bigger networks are build, certain parts of the
algorithm become a limitation to the scalability of IS-IS.
Several sub-components of the IS-IS protocol have an impact on its
scalability.
o The number of adjacenies. For each adjacency periodic IIHs have
to be exchanged. Each adjacency has to be included in the
router's Link-State PDU (LSP). When building a dynamic routing
protocol, this work has to be done in some form or another. Not
much can be done to improve the scalability of this effort.
o Flooding has a large impact on scalability of IS-IS. Obviously
the number of LSPs in an area has an impact on the operation of
IS-IS. Also the number of interfaces over which a router must
flood has an impact on the operation of IS-IS. But the flooding
algorithm itself has elements that limit scalability. Improving
these sub-algorithms will have a positive impact on scalability.
o Dijkstra's Shortest-Path First algorithm. This algorithm is at
the heart of Link-State protocols. This algorithm is
computationally reasonably efficient. One could build better
implementations, that do partial route-computation and do
incremental SPF. Or that check the bi-directionality of each link
in advance of running the SPF. One could run the regular SPF and
the computations for LFA and rLFA in parallel. But the SPF
algorithm itself can not be improved upon easily.
Smit & Van de Velde Expires April 15, 2019 [Page 3]
Internet-Draft IS-IS Flooding over TCP October 2018
2.1. Current scaling limitations of IS-IS flooding
With current implementations of the IS-IS protocol, the flooding
algorithms have the largest impact on protocol scalability. Three
issues are particularly of concern.
2.1.1. Packet pacing and throughput
The first issue is packet pacing of LSPs. If routers would send
large bursts of routing protocol packets to other routers, there is a
risk that the receiving router might drop those packets. This risks
increases when a router has multiple neighbors that might all be
sending large amount of routing-protocol packets at the same time.
Dropped packets cause re-transmissions, delays in convergence, or
even worse things. The solution is packet pacing.
ISO-10589 suggests a router should wait 30 milliseconds between
sending of two consecutive LSPs. This will give the receiving router
time to process pending incoming packets, before input-queues get
overwhelmed. This means that two routers can exchange at most 33
LSPs per second. If a router boots, and has an empty LSDB, in a
network with 10000 routers (and thus at least 10000 LSPs), it will
take up to 300 seconds before the new router has acquired the full
LSDB.
Decreasing the inter-packet gap will speed this up, but it might have
a negative impact on overall network stability. More dynamic or
adaptive packet-pacing algorithms could be envisioned, but those are
not public nor standardized. If such algorithms would be developed,
they would probably end up including many aspects of the existing TCP
protocol.
2.1.2. Reliable flooding on point-to-point interfaces
The second issue is implementing reliable flooding over point-to-
point interfaces. The following algorithm is used when a LSP needs
to be flooded:
o When a new LSP is received, the router sets the SRM-bits for this
LSP for all interfaces (except the interface on which the new LSP
was received).
o For each interface a pacing-timer is started (if not running yet).
o When that pacing-timer expires, the router will find an LSP with
its SRM-bit set for that interface. It will transmit the LSP out
over the interface.
Smit & Van de Velde Expires April 15, 2019 [Page 4]
Internet-Draft IS-IS Flooding over TCP October 2018
o The router will then clear the SRM-bit for that LSP. It will set
a bit indicating that this LSP has not been acknowledged yet. And
it will start a retransmit-timer for that LSP/interface
combination.
o When a PSNP is received for this LSP on this interface, the router
will clear the bit that indicates that no acknowledgement was
received yet.
o When the retransmit-timer fires, the router will check whether the
retransmit-it has been cleared yet. If so, the router stops the
retransmit-timer and is done. If the retransmit-bit has not been
cleared, then the router sets the SRM-bit for this interface/LSP
combination again, and start the pacing-timer for the interface
(if not still running).
Note that when flooding LSPs, the router needs to keep a retransmit-
timer per LSP/interface combination. These timers run typically for
5 seconds, or until an acknowledgement (PSNP) is received. In a
network with only a few hunderd LSPs, then 5 seconds * 33 LSPs/second
results in only 165 LSPs being flooded. If the router has 100
interfaces, this can cause the router to have 16500 simultanously
running timers. If a router falls behind processing PSNPs, or when
PSNPs are being dropped, this number could increase to even larger
numbers. The conclusion is that reliability of flooding LSPs over
point-to-point interfaces does not come free. And in networks under
stress, the cost can become even higher.
2.1.3. Unreliability of CSNPs
The third issue of concern is the unreliability of CNSPs. CSNPs are
used when flooding over multi-point interfaces. But CSNPs are also
used to synchronize LSDBs over adjacencies on point-to-point
interfaces. This happens right after a new adjacency over a point-
to-point interface is established. The algorithm used after a new
adjacency comes up is:
o The router sets the SRM-bit for this interface on all LSPs in its
LSDB.
o The router creates CSNPs describing all LSPs in its LSDB. It
sends these CSNPs to the new neighbor.
o The router waits a limited amount of time, hoping to receive all
the CSNPs from its new neighbors.
o For every LSP in every CSNP received from its new neighbor, the
router checks to compare its version of the LSP with its neighbors
Smit & Van de Velde Expires April 15, 2019 [Page 5]
Internet-Draft IS-IS Flooding over TCP October 2018
version of the LSP. If the versions are the same, the router
clears the SRM-bit for that LSP/interface. Versions are compared
using the LSP sequence-number (and checksum, TTL, etc).
o The router starts the packet-pacing timer, and starts sending to
the new neighbor, LSPs that still have the SRM-bit set for that
interface.
When the number of LSPs in the LSDB grows to large numbers, the
number of CSNPs needed increases to large numbers as well. There can
be only descriptions of 91 LSPs in a typical CSNP. If a network has
10000 routers, and thus 10000+ LSPs, it takes 110 CNSPs to describe
the whole LSDB. If any of the CSNPs that get exchanged during
adjacency synchronization gets dropped, the sending router will
transmit 91 LSPs per dropped CNSPs, regardless whether that was
necessary or not.
3. Improvements for IS-IS flooding
BGP is considered to be a highly scaleable routing protocol. It is
used to carry all routes in the Global Internet. It is used to carry
large numbers of customer routes in Provider networks that supply
VPN-services. But BGP has downsides too. BGP typically requires
extra configuration, and in dense topologies routing-churn can be
experienced, because BGP does so-called path-hunting.
The main property of BGP that contributes to good scaling is the fact
that BGP uses TCP for its transport. Using TCP has certain benefits
for a routing protocol. TCP supplies reliability through
retransmissions and acknowledgements. TCP supplies high throughput
through its windowing mechanism and by potentially packing small
chunks of user-data into larger TCP segments. TCP supplies a crude
form of multi-threading by separating transmission and retransmission
of data from the user process, and letting other tasks or the kernel
take care of that. When a routing protocol uses TCP, it does not
need to burden itself anymore with tasks like retransmission,
acknowledgements, flow-control, or seeking high bandwidth and
throughput. It also doesn't need to do extras to use multi-threading
for reliable transmission.
3.1. Using TCP to do IS-IS flooding
This document proposes a relatively simple way to do IS-IS flooding
over TCP.
Routers remain to establish new adjacencies using IIHs via the
classic IS-IS mechanism. When using IS-IS TCP extensions Routers
remain sending periodic IIHs via the classic mechanism to maintain
Smit & Van de Velde Expires April 15, 2019 [Page 6]
Internet-Draft IS-IS Flooding over TCP October 2018
adjacencies. However, after establishing a new adjacency and
successfully establish a corresponding TCP-connection, LSPs and SNPs
are sent only over the TCP-connection.
4. Negotiating Flooding over TCP
Before two routers can start flooding over TCP, they need to agree on
this new way of transport. Negotiating is done via a new TLV in the
IS-to-IS Hello PDUs (IIH). When a router intends to do flooding over
TCP, it includes this new TLV in its p2p IIHs. The existence of the
TLV in the IIHs is an indication to the other router that it wants to
use TCP for flooding.
The size of the TLV is variable. The value field contains the IP
address and TCP port-number on which the router is accepting a new
TCP connection for flooding. The router with the lowest System-ID
initiates the TCP connection to the other router. The router with
the highest System-ID never tries to set up a new connection. It
just listens on its advertised TCP port-number and accepts the TCP
connection from the router with the lower System-ID.
If only one, or neither of both routers include the new TLV in their
IIHs, then flooding will not be done over TCP. Instead the classic
IS-IS flooding algorithm is used, as described in ISO-10589.
Flooding over TCP is only supported on point-2-point interfaces.
4.1. The new TLV to indicate that a router wants to flood over TCP
This document proposes a new TLV for IIH messages. The existence of
this TLV in an IIH signals the receiving router that the sending
router is willing to do flooding over TCP.
The content of the TLV are 2 or more sub-TLVs. These sub-TLVs
indicate the TCP port-number on which the advertising router is
listening to accept new TCP-connections, and 1 or more sub-TLVs that
indicate the IPv4- or IPv6-address on which the router is listening
to accept new TCP-connections.
The new TLV consists of:
o 1 octet of TLV-Type,
o 1 octet of TLV-Length,
o 10 to 255 octets of TLV-Value, containing sub-TLVs.
The defined sub-TLVs are:
Smit & Van de Velde Expires April 15, 2019 [Page 7]
Internet-Draft IS-IS Flooding over TCP October 2018
o TLV type 1, Length 2 octets. TCP port number.
o TLV type 2, Length 4 octets. IPv4 address. The sending router is
listening on this IPv4-address to open a TCP-connection for IS-IS
flooding.
o TLV type 3, Length 16 octets. IPv6 address. The sending router
is listening on this IPv6-address to open a TCP-connection for IS-
IS flooding.
Example of the layout of the new Flooding-over-TCP TLV. This example
advertises an IPv4-address to connect to.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-TLV 1 | Sub-TLV-Len 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP port-number | Sub-TLV 2 | Sub-TLV-Len 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 Octets of IPv4-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The new TLV is to be included only once in each IIH. A router MUST
NOT include more than one TCP port number sub-TLV. A router MAY
include multiple IPv4- or IPv6-address sub-TLVs. The destination IP-
address(es) SHOULD be addresses that are also included in the IP-
Interface-Addresses TLVs (TLV 132 for IPv4 or TLV 233 for IPv6).
5. Format of messages over TCP
The content of the messages that are transmitted over the TCP
connection are traditional IS-IS PDUs. IIHs, SNPs and LSPs can all
be transmitted over the TCP connection. No TLV-format or other
extensible format is needed, because new information is to be
included inside IIHs, SNPs or LSPs themselves. Therefor the format
of messages over TCP itself does not need to be changed, and does not
need to be extensible.
Each IS-IS PDU that is sent over TCP is to be preceeded by a header,
functionaing as a marker. This header consists of:
o Four octets of marker. The content of this marker is always 0x69
0x73 0x69 0x73. This marker has the same function as the marker
Smit & Van de Velde Expires April 15, 2019 [Page 8]
Internet-Draft IS-IS Flooding over TCP October 2018
in a BGP-header. It enables the receiver to check whether
messages inside the TCP-bytestream have gone out of sync.
o Two octets of message-length. The IS-IS PDU itself also has a
length-field, inside the message-specific header. The length-
field here can be used to verify no octets are missing and that
there are no extra trailing octets.
The type of IS-IS PDU can be derived from the PDU itself, by looking
at the "PDU Type" field in the common IS-IS PDU header.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Marker: 0x69 | 0x73 | 0x69 | 0x73 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length field | IS-IS PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......
Figure 2
6. New behaviour of IS-IS flooding
When IS-IS does its flooding over TCP, the algorithms to transmit and
receive LSPs change slightly. The biggest difference with the
standard algorithms from ISO-10589 are the facts that the sending
router does not need to do retransmission and that the receiving
router does not need to send PSNPs to acknowledge receipt of LSPs.
6.1. Establishing a new IS-IS adjacency
Initially the Router looks for the new TLV in the IIH. If the other
router included this TLV in its IIH, flooding over TCP is initiated.
The router with the lowest System-ID initiates a TCP-connection to
the other router. The TCP port-number and destination IP-address is
learned from the new TLV in the IIH.
After the TCP session is established, a router will:
o Send a regular IIH over the TCP connection. The IIH is the same
as when it would have been encapsulated straight into a layer-2
header. This IIH allows the other router to verify the identity
and authentication of the remote router.
Smit & Van de Velde Expires April 15, 2019 [Page 9]
Internet-Draft IS-IS Flooding over TCP October 2018
o Wait for receipt of an IIH from the remote router. This IIH is
used to verify the identity and authentication of the remote
router.
o Set the SRM-bit for this interface on all the LSPs in the LSDB.
o Send a number of CSNPs over the TCP connection. These CNSPs MUST
describe the whole LSDB of the sending router. The last CSNP
should desribe the last lexographical LSP in the LSDB. The end-id
in the CSNP would be FFFF.FFFF.FFFF.FF-FF.
o Process all incoming CSNPs from the remote router. When a CSNP is
received, check your own LSDB, and clear the SRM-bits on LSPs that
both routers have in common. If the remote router has a version
of the LSP that is newer, do not set the SSN-bit. It is not
necessary to explicitely request for the newer LSP. The remote
router will send it anyway.
o When the last CSNP has been received, walk the LSDB and send any
LSPs that still have the SRM-bit set for this interface.
o No retransmission needs to be one by either router. TCP will take
care of retransmission.
6.2. Behaviour during the existence of an IS-IS adjacency
The actions that a router has to take when receiving a new LSP are
simplified compared to classic flooding.
o When a router receives an LSP, it checks if it has that LSP
already in its LSDB. And it checks whether the version of the
received LSP is newer or not.
o If the version is the same, the router does nothing.
o If the version of the received LSP is older than the LSP in the
LSDB, the router sets the SRM-bit for the LSP. At some point in
time, the router will then send its own LSP back to the other
router.
o If the version of the recieved LSP is newer than the LSP in the
LSDB, the router sets the SRM-bits for this LSP for all
interfaces, except the interface it received the newer version of
the LSP from.
o The receiving router does not set the SSN-bit and does not send an
acknowledgement (PSNP).
Smit & Van de Velde Expires April 15, 2019 [Page 10]
Internet-Draft IS-IS Flooding over TCP October 2018
o Periodically, or event driven, the router will check its LSDB for
LSPs with the SRM-bit set. When it finds such LSPs, it will send
as many of those LSPs to neighbors, via TCP. There is no packet-
pacing. All flow-control is handled by TCP. After sending one or
more LSPs, the router does not set any state to indicate that the
LSP needs retransmission. The router does not expect an
acknowledgement (PSNP). No retransmission-timer needs to be
started. Just sending the LSPs is enough.
7. Considerations regarding IS-IS flooding over TCP
7.1. Flooding over TCP is only done on point-to-point interfaces
Flooding over TCP is not supported for multi-point interfaces. The
nature of classic flooding between multiple routers on a LAN is too
complex to simply replace by TCP connections. Therefor the new
flooding-over-TCP TLV should only be included in point-to-point IIH.
Care must be taken that when a large network consists mostly of
point-to-point interfaces, there are no multi-point between routers
left in the network. Doing classic flooding over those multi-point
interfaces might require substantial more resources than flooding on
routers with only point-to-point interfaces.
7.2. Unnumbered interfaces and reachability of the interface ip-address
When a router tries to open a TCP connection to another router, it
uses the TCP port-number and an IP-address is has learned from the
new flooding-over-TCP TLV. This destination address can be any
advertised IP-address that is from a prefix shared between the two
routers.
However, it is possible that both routers use "ip unnumbered" on the
point-to-point interface. In that case, the remote destination ip-
address might not appear in the sender's routing table. Typically
routes are installed in the routing table only after doing an SPF
computation and learning how to reach all IP-prefixes that are
included in LSPs. Typically routers do not install routes in the
routing table for IP-addresses learned from the IP-Interface-
Addresses TLV in IIHs. When a router is planning to do flooding over
TCP, and does not have opened a TCP connection yet, it will not have
all the LSPs in its LSDB necessary to learn how to reach the IP-
address from the new Flooding-over-TCP TLV, or from the IP-Interface-
Addresses TVL.
Therefor it is recommended that when a router does flooding over TCP,
and one of its interfaces is configured as "unnumbered", that router
SHOULD install host-routes (/32s or /128s) in its routing table, so
Smit & Van de Velde Expires April 15, 2019 [Page 11]
Internet-Draft IS-IS Flooding over TCP October 2018
that TCP will be able to open a connection to the router on the other
end of an adjacency. These host-routes can be interface-routes for
the IP-address(es) learned from the new Flooding-over-TCP TLV in the
p2p IIHs.
7.3. Multiple levels of hierarchy on one interface
IS-IS flooding over TCP is only defined for point-to-point
interfaces. Over point-to-point interfaces, only one type of IIH PDU
is sent, even when the interface is used by both level-1 and level-2
routing. This means that IS-IS flooding over TCP is negotiated in
only one location (inside the p2p IIH). Two routers use a single
TCP-connection, even when doing both level-1 and level-2 routing over
that interface.
The packet-types of LSPs and SNPs identify whether the packet is
level-1 or level-2. Therefor no confusion can occur when receiving
both level-1 and level-2 PDUs over the same TCP connection.
7.4. Downsides of using TCP for IS-IS flooding
When TCP-segments are dropped, TCP will retransmit those segments a
little while later. In the mean time, new versions might arrive of
the LSPs that are in the TCP buffers. Therefor TCP might retransmit
stale LSPs. Which it would not have done if flooding was done via
the standard way. This causes only a slight inefficient use of
resources. Ultimately the current versions of those LSPs will be
transmitted. To protect against this, it is recommended to not make
the TCP window-size larger than the default.
7.5. What to do if the TCP connection breaks
If a TCP connection gets closed or reset, the router with the lowest
System-ID MUST periodically try to re-open the TCP connection. Both
routers MUST NOT declare the adjacency down. An existing adjacency
must stay established as long as IIHs are exchanged and the holding-
time timer doesn't expire.
The benefit of this behaviour is that it allows IS-IS implementations
a certain flexibility. E.g. when an IS-IS process on a router is
restarted, and the TCP connection is re-established, this will not
bring down the adjacency. Or a router can switch over to the Hot
Standby Control Plane, or do In-Service Software-Upgrades (ISSU)
without causing adjacencies to go down.
Smit & Van de Velde Expires April 15, 2019 [Page 12]
Internet-Draft IS-IS Flooding over TCP October 2018
7.6. What to do if the TCP connection can not be set up
It could happen that two routers can exchange IS-IS PDUs fine, but
they can not set up a TCP connection. What needs to be done in this
case is open for discussion.
8. Security Considerations
IS-IS as defined in ISO-10589 encapsulates IS-IS PDUs straight into a
layer-2 header. One of the benefits of this is that remote attackers
can not send IS-IS messages to a targeted router that is several ip-
hops away. Using TCP for IS-IS flooding would potentially open up
IS-IS routers to these forms of attacks.
The common way for a protocol to protect itself against these remote
attack is using the TTL-field in the IP-header of TCP-segments.
When a router send a TCP-segment with IS-IS flooding data, it MUST
set the TTL of the IP-header to 255. When a router receives a TCP-
segment with IS-IS flooding data, it MUST check to see if the TTL is
still 255. If a router receives a TCP-segment with IS-IS flooding
data, and the TTL is less than 255, the router MUST ignore and drop
the TCP-segment.
Identification and Authentication. When a new TCP-session is
established to flood over, each router MUST first send a regular IIH
over the TCP-session. This allows each router to verify that the
other side of the TCP-connection is who they expect it to be. The
IIH has the System-ID and the Interface-ID of the sending router.
Regular authentication methods will place an authentication-TLV
inside the IIH. Regardless of the fact whether routers flood over
layer-2 or flood over TCP, these authentication mechanisms can be
used to verify the other side of the TCP-connection. Sending a
regular IIH for verification and authentication, instead of having
our own new method, guaranteees that Flooding-over-TCP will use new
authentication mechanisms when those get developed in the future.
9. Acknowledgements
The authors would like to express thanks to Filip Martin, Dirk
Goethals and Koen Leclerq for their suggestions and comments.
10. Contributor Addresses
Below is a list of other contributing authors in alphabetical order:
Smit & Van de Velde Expires April 15, 2019 [Page 13]
Internet-Draft IS-IS Flooding over TCP October 2018
Figure 3
11. IANA Considerations
This document requests one new TLV code-point, to be used in IIHs
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>.
[2] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>.
12.2. Informative References
[3] International Standard 10589, "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), Second Edition.", 2002.
[4] Patel, K., Lindem, A., and W. Henderickx, "Link State
Vector Routing (LSVR)", August 2018.
[5] Przygienda, T., Sharma, A., Thubert, P., Atlas, A., and J.
Drake, "Routing in Fat Trees (RIFT)", June 2018.
Authors' Addresses
Henk Smit (editor)
Email: hhw.smit@xs4all.nl
Gunter Van de Velde
Nokia
Copernicuslaan 50
2018 Antwerp
Belgium
Email: gunter.van_de_velde@nokia.com
Smit & Van de Velde Expires April 15, 2019 [Page 14]
