idnits 2.17.00 (12 Aug 2021) /tmp/idnits20810/draft-hsmit-lsr-isis-flooding-over-tcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2018) is 1310 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7938 (ref. '2') Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Link-State Routing H. Smit, Ed. 3 Internet-Draft 4 Intended status: Standards Track G. Van de Velde 5 Expires: April 15, 2019 Nokia 6 October 12, 2018 8 IS-IS Flooding over TCP 9 draft-hsmit-lsr-isis-flooding-over-tcp-00 11 Abstract 13 This document proposes a solution to use TCP for IS-IS flooding. The 14 proposed solution is a relative simple extension to implement. IS-IS 15 flooding over TCP brings BGP's property of scalable transport via TCP 16 to Link-State protocols. 18 This proposal defines a new TLV in point-to-point IIHs to signal the 19 intent of a router to do flooding over TCP, and it defines a small 20 header to encapsulate IS-IS PDUs in the TCP byte-stream. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [1]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 15, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. General scaling factors of IS-IS . . . . . . . . . . . . . . 3 64 2.1. Current scaling limitations of IS-IS flooding . . . . . . 4 65 2.1.1. Packet pacing and throughput . . . . . . . . . . . . 4 66 2.1.2. Reliable flooding on point-to-point interfaces . . . 4 67 2.1.3. Unreliability of CSNPs . . . . . . . . . . . . . . . 5 68 3. Improvements for IS-IS flooding . . . . . . . . . . . . . . . 6 69 3.1. Using TCP to do IS-IS flooding . . . . . . . . . . . . . 6 70 4. Negotiating Flooding over TCP . . . . . . . . . . . . . . . . 7 71 4.1. The new TLV to indicate that a router wants to flood over 72 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Format of messages over TCP . . . . . . . . . . . . . . . . . 8 74 6. New behaviour of IS-IS flooding . . . . . . . . . . . . . . . 9 75 6.1. Establishing a new IS-IS adjacency . . . . . . . . . . . 9 76 6.2. Behaviour during the existence of an IS-IS adjacency . . 10 77 7. Considerations regarding IS-IS flooding over TCP . . . . . . 11 78 7.1. Flooding over TCP is only done on point-to-point 79 interfaces . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.2. Unnumbered interfaces and reachability of the interface 81 ip-address . . . . . . . . . . . . . . . . . . . . . . . 11 82 7.3. Multiple levels of hierarchy on one interface . . . . . . 12 83 7.4. Downsides of using TCP for IS-IS flooding . . . . . . . . 12 84 7.5. What to do if the TCP connection breaks . . . . . . . . . 12 85 7.6. What to do if the TCP connection can not be set up . . . 13 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 13 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 12.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 IP Fabric Networks in data-centers are growing larger and larger. 99 The number of routers in such fabrics are pushing the boundaries of 100 routing protocols. Therefor new ideas are explored, and existing 101 protocols are being enhanced (RFC 7938 [2], RIFT [5] and LSVR [4]). 103 This document improves an existing protocol, IS-IS. One of the 104 scaling limitations of IS-IS is its flooding algorithm. BGP is known 105 to be a routing protocol of high scale. A key property and important 106 benefit of BGP is the fact that BGP uses TCP as transport mechanism. 107 Introducing TCP to IS- IS flooding would bring a major positive 108 scaling property from BGP to IS-IS. 110 2. General scaling factors of IS-IS 112 IS-IS is a highly scalable Interior Gateway Protocol (IGP). IS-IS is 113 defined in ISO-10589 [3]. Networks with thousands of routers have 114 been deployed. When bigger networks are build, certain parts of the 115 algorithm become a limitation to the scalability of IS-IS. 117 Several sub-components of the IS-IS protocol have an impact on its 118 scalability. 120 o The number of adjacenies. For each adjacency periodic IIHs have 121 to be exchanged. Each adjacency has to be included in the 122 router's Link-State PDU (LSP). When building a dynamic routing 123 protocol, this work has to be done in some form or another. Not 124 much can be done to improve the scalability of this effort. 126 o Flooding has a large impact on scalability of IS-IS. Obviously 127 the number of LSPs in an area has an impact on the operation of 128 IS-IS. Also the number of interfaces over which a router must 129 flood has an impact on the operation of IS-IS. But the flooding 130 algorithm itself has elements that limit scalability. Improving 131 these sub-algorithms will have a positive impact on scalability. 133 o Dijkstra's Shortest-Path First algorithm. This algorithm is at 134 the heart of Link-State protocols. This algorithm is 135 computationally reasonably efficient. One could build better 136 implementations, that do partial route-computation and do 137 incremental SPF. Or that check the bi-directionality of each link 138 in advance of running the SPF. One could run the regular SPF and 139 the computations for LFA and rLFA in parallel. But the SPF 140 algorithm itself can not be improved upon easily. 142 2.1. Current scaling limitations of IS-IS flooding 144 With current implementations of the IS-IS protocol, the flooding 145 algorithms have the largest impact on protocol scalability. Three 146 issues are particularly of concern. 148 2.1.1. Packet pacing and throughput 150 The first issue is packet pacing of LSPs. If routers would send 151 large bursts of routing protocol packets to other routers, there is a 152 risk that the receiving router might drop those packets. This risks 153 increases when a router has multiple neighbors that might all be 154 sending large amount of routing-protocol packets at the same time. 155 Dropped packets cause re-transmissions, delays in convergence, or 156 even worse things. The solution is packet pacing. 158 ISO-10589 suggests a router should wait 30 milliseconds between 159 sending of two consecutive LSPs. This will give the receiving router 160 time to process pending incoming packets, before input-queues get 161 overwhelmed. This means that two routers can exchange at most 33 162 LSPs per second. If a router boots, and has an empty LSDB, in a 163 network with 10000 routers (and thus at least 10000 LSPs), it will 164 take up to 300 seconds before the new router has acquired the full 165 LSDB. 167 Decreasing the inter-packet gap will speed this up, but it might have 168 a negative impact on overall network stability. More dynamic or 169 adaptive packet-pacing algorithms could be envisioned, but those are 170 not public nor standardized. If such algorithms would be developed, 171 they would probably end up including many aspects of the existing TCP 172 protocol. 174 2.1.2. Reliable flooding on point-to-point interfaces 176 The second issue is implementing reliable flooding over point-to- 177 point interfaces. The following algorithm is used when a LSP needs 178 to be flooded: 180 o When a new LSP is received, the router sets the SRM-bits for this 181 LSP for all interfaces (except the interface on which the new LSP 182 was received). 184 o For each interface a pacing-timer is started (if not running yet). 186 o When that pacing-timer expires, the router will find an LSP with 187 its SRM-bit set for that interface. It will transmit the LSP out 188 over the interface. 190 o The router will then clear the SRM-bit for that LSP. It will set 191 a bit indicating that this LSP has not been acknowledged yet. And 192 it will start a retransmit-timer for that LSP/interface 193 combination. 195 o When a PSNP is received for this LSP on this interface, the router 196 will clear the bit that indicates that no acknowledgement was 197 received yet. 199 o When the retransmit-timer fires, the router will check whether the 200 retransmit-it has been cleared yet. If so, the router stops the 201 retransmit-timer and is done. If the retransmit-bit has not been 202 cleared, then the router sets the SRM-bit for this interface/LSP 203 combination again, and start the pacing-timer for the interface 204 (if not still running). 206 Note that when flooding LSPs, the router needs to keep a retransmit- 207 timer per LSP/interface combination. These timers run typically for 208 5 seconds, or until an acknowledgement (PSNP) is received. In a 209 network with only a few hunderd LSPs, then 5 seconds * 33 LSPs/second 210 results in only 165 LSPs being flooded. If the router has 100 211 interfaces, this can cause the router to have 16500 simultanously 212 running timers. If a router falls behind processing PSNPs, or when 213 PSNPs are being dropped, this number could increase to even larger 214 numbers. The conclusion is that reliability of flooding LSPs over 215 point-to-point interfaces does not come free. And in networks under 216 stress, the cost can become even higher. 218 2.1.3. Unreliability of CSNPs 220 The third issue of concern is the unreliability of CNSPs. CSNPs are 221 used when flooding over multi-point interfaces. But CSNPs are also 222 used to synchronize LSDBs over adjacencies on point-to-point 223 interfaces. This happens right after a new adjacency over a point- 224 to-point interface is established. The algorithm used after a new 225 adjacency comes up is: 227 o The router sets the SRM-bit for this interface on all LSPs in its 228 LSDB. 230 o The router creates CSNPs describing all LSPs in its LSDB. It 231 sends these CSNPs to the new neighbor. 233 o The router waits a limited amount of time, hoping to receive all 234 the CSNPs from its new neighbors. 236 o For every LSP in every CSNP received from its new neighbor, the 237 router checks to compare its version of the LSP with its neighbors 238 version of the LSP. If the versions are the same, the router 239 clears the SRM-bit for that LSP/interface. Versions are compared 240 using the LSP sequence-number (and checksum, TTL, etc). 242 o The router starts the packet-pacing timer, and starts sending to 243 the new neighbor, LSPs that still have the SRM-bit set for that 244 interface. 246 When the number of LSPs in the LSDB grows to large numbers, the 247 number of CSNPs needed increases to large numbers as well. There can 248 be only descriptions of 91 LSPs in a typical CSNP. If a network has 249 10000 routers, and thus 10000+ LSPs, it takes 110 CNSPs to describe 250 the whole LSDB. If any of the CSNPs that get exchanged during 251 adjacency synchronization gets dropped, the sending router will 252 transmit 91 LSPs per dropped CNSPs, regardless whether that was 253 necessary or not. 255 3. Improvements for IS-IS flooding 257 BGP is considered to be a highly scaleable routing protocol. It is 258 used to carry all routes in the Global Internet. It is used to carry 259 large numbers of customer routes in Provider networks that supply 260 VPN-services. But BGP has downsides too. BGP typically requires 261 extra configuration, and in dense topologies routing-churn can be 262 experienced, because BGP does so-called path-hunting. 264 The main property of BGP that contributes to good scaling is the fact 265 that BGP uses TCP for its transport. Using TCP has certain benefits 266 for a routing protocol. TCP supplies reliability through 267 retransmissions and acknowledgements. TCP supplies high throughput 268 through its windowing mechanism and by potentially packing small 269 chunks of user-data into larger TCP segments. TCP supplies a crude 270 form of multi-threading by separating transmission and retransmission 271 of data from the user process, and letting other tasks or the kernel 272 take care of that. When a routing protocol uses TCP, it does not 273 need to burden itself anymore with tasks like retransmission, 274 acknowledgements, flow-control, or seeking high bandwidth and 275 throughput. It also doesn't need to do extras to use multi-threading 276 for reliable transmission. 278 3.1. Using TCP to do IS-IS flooding 280 This document proposes a relatively simple way to do IS-IS flooding 281 over TCP. 283 Routers remain to establish new adjacencies using IIHs via the 284 classic IS-IS mechanism. When using IS-IS TCP extensions Routers 285 remain sending periodic IIHs via the classic mechanism to maintain 286 adjacencies. However, after establishing a new adjacency and 287 successfully establish a corresponding TCP-connection, LSPs and SNPs 288 are sent only over the TCP-connection. 290 4. Negotiating Flooding over TCP 292 Before two routers can start flooding over TCP, they need to agree on 293 this new way of transport. Negotiating is done via a new TLV in the 294 IS-to-IS Hello PDUs (IIH). When a router intends to do flooding over 295 TCP, it includes this new TLV in its p2p IIHs. The existence of the 296 TLV in the IIHs is an indication to the other router that it wants to 297 use TCP for flooding. 299 The size of the TLV is variable. The value field contains the IP 300 address and TCP port-number on which the router is accepting a new 301 TCP connection for flooding. The router with the lowest System-ID 302 initiates the TCP connection to the other router. The router with 303 the highest System-ID never tries to set up a new connection. It 304 just listens on its advertised TCP port-number and accepts the TCP 305 connection from the router with the lower System-ID. 307 If only one, or neither of both routers include the new TLV in their 308 IIHs, then flooding will not be done over TCP. Instead the classic 309 IS-IS flooding algorithm is used, as described in ISO-10589. 311 Flooding over TCP is only supported on point-2-point interfaces. 313 4.1. The new TLV to indicate that a router wants to flood over TCP 315 This document proposes a new TLV for IIH messages. The existence of 316 this TLV in an IIH signals the receiving router that the sending 317 router is willing to do flooding over TCP. 319 The content of the TLV are 2 or more sub-TLVs. These sub-TLVs 320 indicate the TCP port-number on which the advertising router is 321 listening to accept new TCP-connections, and 1 or more sub-TLVs that 322 indicate the IPv4- or IPv6-address on which the router is listening 323 to accept new TCP-connections. 325 The new TLV consists of: 327 o 1 octet of TLV-Type, 329 o 1 octet of TLV-Length, 331 o 10 to 255 octets of TLV-Value, containing sub-TLVs. 333 The defined sub-TLVs are: 335 o TLV type 1, Length 2 octets. TCP port number. 337 o TLV type 2, Length 4 octets. IPv4 address. The sending router is 338 listening on this IPv4-address to open a TCP-connection for IS-IS 339 flooding. 341 o TLV type 3, Length 16 octets. IPv6 address. The sending router 342 is listening on this IPv6-address to open a TCP-connection for IS- 343 IS flooding. 345 Example of the layout of the new Flooding-over-TCP TLV. This example 346 advertises an IPv4-address to connect to. 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type | Length | Sub-TLV 1 | Sub-TLV-Len 2 | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | TCP port-number | Sub-TLV 2 | Sub-TLV-Len 4 | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | 4 Octets of IPv4-address | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 1 359 The new TLV is to be included only once in each IIH. A router MUST 360 NOT include more than one TCP port number sub-TLV. A router MAY 361 include multiple IPv4- or IPv6-address sub-TLVs. The destination IP- 362 address(es) SHOULD be addresses that are also included in the IP- 363 Interface-Addresses TLVs (TLV 132 for IPv4 or TLV 233 for IPv6). 365 5. Format of messages over TCP 367 The content of the messages that are transmitted over the TCP 368 connection are traditional IS-IS PDUs. IIHs, SNPs and LSPs can all 369 be transmitted over the TCP connection. No TLV-format or other 370 extensible format is needed, because new information is to be 371 included inside IIHs, SNPs or LSPs themselves. Therefor the format 372 of messages over TCP itself does not need to be changed, and does not 373 need to be extensible. 375 Each IS-IS PDU that is sent over TCP is to be preceeded by a header, 376 functionaing as a marker. This header consists of: 378 o Four octets of marker. The content of this marker is always 0x69 379 0x73 0x69 0x73. This marker has the same function as the marker 380 in a BGP-header. It enables the receiver to check whether 381 messages inside the TCP-bytestream have gone out of sync. 383 o Two octets of message-length. The IS-IS PDU itself also has a 384 length-field, inside the message-specific header. The length- 385 field here can be used to verify no octets are missing and that 386 there are no extra trailing octets. 388 The type of IS-IS PDU can be derived from the PDU itself, by looking 389 at the "PDU Type" field in the common IS-IS PDU header. 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Marker: 0x69 | 0x73 | 0x69 | 0x73 | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Length field | IS-IS PDU | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | IS-IS PDU | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | ....... 401 Figure 2 403 6. New behaviour of IS-IS flooding 405 When IS-IS does its flooding over TCP, the algorithms to transmit and 406 receive LSPs change slightly. The biggest difference with the 407 standard algorithms from ISO-10589 are the facts that the sending 408 router does not need to do retransmission and that the receiving 409 router does not need to send PSNPs to acknowledge receipt of LSPs. 411 6.1. Establishing a new IS-IS adjacency 413 Initially the Router looks for the new TLV in the IIH. If the other 414 router included this TLV in its IIH, flooding over TCP is initiated. 415 The router with the lowest System-ID initiates a TCP-connection to 416 the other router. The TCP port-number and destination IP-address is 417 learned from the new TLV in the IIH. 419 After the TCP session is established, a router will: 421 o Send a regular IIH over the TCP connection. The IIH is the same 422 as when it would have been encapsulated straight into a layer-2 423 header. This IIH allows the other router to verify the identity 424 and authentication of the remote router. 426 o Wait for receipt of an IIH from the remote router. This IIH is 427 used to verify the identity and authentication of the remote 428 router. 430 o Set the SRM-bit for this interface on all the LSPs in the LSDB. 432 o Send a number of CSNPs over the TCP connection. These CNSPs MUST 433 describe the whole LSDB of the sending router. The last CSNP 434 should desribe the last lexographical LSP in the LSDB. The end-id 435 in the CSNP would be FFFF.FFFF.FFFF.FF-FF. 437 o Process all incoming CSNPs from the remote router. When a CSNP is 438 received, check your own LSDB, and clear the SRM-bits on LSPs that 439 both routers have in common. If the remote router has a version 440 of the LSP that is newer, do not set the SSN-bit. It is not 441 necessary to explicitely request for the newer LSP. The remote 442 router will send it anyway. 444 o When the last CSNP has been received, walk the LSDB and send any 445 LSPs that still have the SRM-bit set for this interface. 447 o No retransmission needs to be one by either router. TCP will take 448 care of retransmission. 450 6.2. Behaviour during the existence of an IS-IS adjacency 452 The actions that a router has to take when receiving a new LSP are 453 simplified compared to classic flooding. 455 o When a router receives an LSP, it checks if it has that LSP 456 already in its LSDB. And it checks whether the version of the 457 received LSP is newer or not. 459 o If the version is the same, the router does nothing. 461 o If the version of the received LSP is older than the LSP in the 462 LSDB, the router sets the SRM-bit for the LSP. At some point in 463 time, the router will then send its own LSP back to the other 464 router. 466 o If the version of the recieved LSP is newer than the LSP in the 467 LSDB, the router sets the SRM-bits for this LSP for all 468 interfaces, except the interface it received the newer version of 469 the LSP from. 471 o The receiving router does not set the SSN-bit and does not send an 472 acknowledgement (PSNP). 474 o Periodically, or event driven, the router will check its LSDB for 475 LSPs with the SRM-bit set. When it finds such LSPs, it will send 476 as many of those LSPs to neighbors, via TCP. There is no packet- 477 pacing. All flow-control is handled by TCP. After sending one or 478 more LSPs, the router does not set any state to indicate that the 479 LSP needs retransmission. The router does not expect an 480 acknowledgement (PSNP). No retransmission-timer needs to be 481 started. Just sending the LSPs is enough. 483 7. Considerations regarding IS-IS flooding over TCP 485 7.1. Flooding over TCP is only done on point-to-point interfaces 487 Flooding over TCP is not supported for multi-point interfaces. The 488 nature of classic flooding between multiple routers on a LAN is too 489 complex to simply replace by TCP connections. Therefor the new 490 flooding-over-TCP TLV should only be included in point-to-point IIH. 492 Care must be taken that when a large network consists mostly of 493 point-to-point interfaces, there are no multi-point between routers 494 left in the network. Doing classic flooding over those multi-point 495 interfaces might require substantial more resources than flooding on 496 routers with only point-to-point interfaces. 498 7.2. Unnumbered interfaces and reachability of the interface ip-address 500 When a router tries to open a TCP connection to another router, it 501 uses the TCP port-number and an IP-address is has learned from the 502 new flooding-over-TCP TLV. This destination address can be any 503 advertised IP-address that is from a prefix shared between the two 504 routers. 506 However, it is possible that both routers use "ip unnumbered" on the 507 point-to-point interface. In that case, the remote destination ip- 508 address might not appear in the sender's routing table. Typically 509 routes are installed in the routing table only after doing an SPF 510 computation and learning how to reach all IP-prefixes that are 511 included in LSPs. Typically routers do not install routes in the 512 routing table for IP-addresses learned from the IP-Interface- 513 Addresses TLV in IIHs. When a router is planning to do flooding over 514 TCP, and does not have opened a TCP connection yet, it will not have 515 all the LSPs in its LSDB necessary to learn how to reach the IP- 516 address from the new Flooding-over-TCP TLV, or from the IP-Interface- 517 Addresses TVL. 519 Therefor it is recommended that when a router does flooding over TCP, 520 and one of its interfaces is configured as "unnumbered", that router 521 SHOULD install host-routes (/32s or /128s) in its routing table, so 522 that TCP will be able to open a connection to the router on the other 523 end of an adjacency. These host-routes can be interface-routes for 524 the IP-address(es) learned from the new Flooding-over-TCP TLV in the 525 p2p IIHs. 527 7.3. Multiple levels of hierarchy on one interface 529 IS-IS flooding over TCP is only defined for point-to-point 530 interfaces. Over point-to-point interfaces, only one type of IIH PDU 531 is sent, even when the interface is used by both level-1 and level-2 532 routing. This means that IS-IS flooding over TCP is negotiated in 533 only one location (inside the p2p IIH). Two routers use a single 534 TCP-connection, even when doing both level-1 and level-2 routing over 535 that interface. 537 The packet-types of LSPs and SNPs identify whether the packet is 538 level-1 or level-2. Therefor no confusion can occur when receiving 539 both level-1 and level-2 PDUs over the same TCP connection. 541 7.4. Downsides of using TCP for IS-IS flooding 543 When TCP-segments are dropped, TCP will retransmit those segments a 544 little while later. In the mean time, new versions might arrive of 545 the LSPs that are in the TCP buffers. Therefor TCP might retransmit 546 stale LSPs. Which it would not have done if flooding was done via 547 the standard way. This causes only a slight inefficient use of 548 resources. Ultimately the current versions of those LSPs will be 549 transmitted. To protect against this, it is recommended to not make 550 the TCP window-size larger than the default. 552 7.5. What to do if the TCP connection breaks 554 If a TCP connection gets closed or reset, the router with the lowest 555 System-ID MUST periodically try to re-open the TCP connection. Both 556 routers MUST NOT declare the adjacency down. An existing adjacency 557 must stay established as long as IIHs are exchanged and the holding- 558 time timer doesn't expire. 560 The benefit of this behaviour is that it allows IS-IS implementations 561 a certain flexibility. E.g. when an IS-IS process on a router is 562 restarted, and the TCP connection is re-established, this will not 563 bring down the adjacency. Or a router can switch over to the Hot 564 Standby Control Plane, or do In-Service Software-Upgrades (ISSU) 565 without causing adjacencies to go down. 567 7.6. What to do if the TCP connection can not be set up 569 It could happen that two routers can exchange IS-IS PDUs fine, but 570 they can not set up a TCP connection. What needs to be done in this 571 case is open for discussion. 573 8. Security Considerations 575 IS-IS as defined in ISO-10589 encapsulates IS-IS PDUs straight into a 576 layer-2 header. One of the benefits of this is that remote attackers 577 can not send IS-IS messages to a targeted router that is several ip- 578 hops away. Using TCP for IS-IS flooding would potentially open up 579 IS-IS routers to these forms of attacks. 581 The common way for a protocol to protect itself against these remote 582 attack is using the TTL-field in the IP-header of TCP-segments. 584 When a router send a TCP-segment with IS-IS flooding data, it MUST 585 set the TTL of the IP-header to 255. When a router receives a TCP- 586 segment with IS-IS flooding data, it MUST check to see if the TTL is 587 still 255. If a router receives a TCP-segment with IS-IS flooding 588 data, and the TTL is less than 255, the router MUST ignore and drop 589 the TCP-segment. 591 Identification and Authentication. When a new TCP-session is 592 established to flood over, each router MUST first send a regular IIH 593 over the TCP-session. This allows each router to verify that the 594 other side of the TCP-connection is who they expect it to be. The 595 IIH has the System-ID and the Interface-ID of the sending router. 596 Regular authentication methods will place an authentication-TLV 597 inside the IIH. Regardless of the fact whether routers flood over 598 layer-2 or flood over TCP, these authentication mechanisms can be 599 used to verify the other side of the TCP-connection. Sending a 600 regular IIH for verification and authentication, instead of having 601 our own new method, guaranteees that Flooding-over-TCP will use new 602 authentication mechanisms when those get developed in the future. 604 9. Acknowledgements 606 The authors would like to express thanks to Filip Martin, Dirk 607 Goethals and Koen Leclerq for their suggestions and comments. 609 10. Contributor Addresses 611 Below is a list of other contributing authors in alphabetical order: 613 Figure 3 615 11. IANA Considerations 617 This document requests one new TLV code-point, to be used in IIHs 619 12. References 621 12.1. Normative References 623 [1] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997, 625 . 627 [2] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 628 BGP for Routing in Large-Scale Data Centers", RFC 7938, 629 DOI 10.17487/RFC7938, August 2016, 630 . 632 12.2. Informative References 634 [3] International Standard 10589, "Intermediate System to 635 Intermediate System intra- domain routeing information 636 exchange protocol for use in conjunction with the protocol 637 for providing the connectionless-mode network service (ISO 638 8473), Second Edition.", 2002. 640 [4] Patel, K., Lindem, A., and W. Henderickx, "Link State 641 Vector Routing (LSVR)", August 2018. 643 [5] Przygienda, T., Sharma, A., Thubert, P., Atlas, A., and J. 644 Drake, "Routing in Fat Trees (RIFT)", June 2018. 646 Authors' Addresses 648 Henk Smit (editor) 650 Email: hhw.smit@xs4all.nl 652 Gunter Van de Velde 653 Nokia 654 Copernicuslaan 50 655 2018 Antwerp 656 Belgium 658 Email: gunter.van_de_velde@nokia.com