[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/