Internet Engineering Task Force (IETF)                        T. Li, Ed.
Internet-Draft
Request for Comments: 9667                              Juniper Networks
Intended status:
Category: Experimental                                    P. Psenak, Ed.
Expires: 7 October 2024
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                                 H. Chen
                                                               Futurewei
                                                                L. Jalil
                                                                 Verizon
                                                              S. Dontula
                                                                     ATT
                                                            5 April
                                                                    AT&T
                                                            October 2024

                    Dynamic Flooding on Dense Graphs
                   draft-ietf-lsr-dynamic-flooding-18

Abstract

   Routing with link state link-state protocols in dense network topologies can
   result in sub-optimal suboptimal convergence times due to the overhead associated
   with flooding.  This can be addressed by decreasing the flooding
   topology so that it is less dense.

   This document discusses the problem in some depth and an
   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
   and OSPFv3 are described in this document.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF
   community.  It has received public review and has been approved for
   publication by the Internet Engineering Steering Group (IESG).  Not
   all documents valid approved by the IESG are candidates for a maximum any level of six months
   Internet Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 7 October 2024.
   https://www.rfc-editor.org/info/rfc9667.

Copyright Notice

   Copyright (c) 2024 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)
   (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 Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Solution Requirements . . . . . . . . . . . . . . . . . . . .   5
   4.  Dynamic Flooding  . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Leader election . . . . . . . . . . . . . . . . . . . . .   8 Election
     4.3.  Computing the Flooding Topology . . . . . . . . . . . . .   9
     4.4.  Topologies on Complete Bipartite Graphs . . . . . . . . .  10
       4.4.1.  A Minimal Flooding Topology . . . . . . . . . . . . .  10
       4.4.2.  Xia Topologies  . . . . . . . . . . . . . . . . . . .  10
       4.4.3.  Optimization  . . . . . . . . . . . . . . . . . . . .  11
     4.5.  Encoding the Flooding Topology  . . . . . . . . . . . . .  11
     4.6.  Advertising the Local Edges Enabled for Flooding  . . . .  12
   5.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  IS-IS TLVs  . . . . . . . . . . . . . . . . . . . . . . .  13
       5.1.1.  IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . .  13
       5.1.2.  IS-IS Dynamic Flooding Sub-TLV  . . . . . . . . . . .  14
       5.1.3.  IS-IS Area Node IDs TLV . . . . . . . . . . . . . . .  15
       5.1.4.  IS-IS Flooding Path TLV . . . . . . . . . . . . . . .  16
       5.1.5.  IS-IS Flooding Request TLV  . . . . . . . . . . . . .  17
       5.1.6.  IS-IS LEEF Advertisement  . . . . . . . . . . . . . .  18
     5.2.  OSPF LSAs and TLVs  . . . . . . . . . . . . . . . . . . .  18
       5.2.1.  OSPF Area Leader Sub-TLV  . . . . . . . . . . . . . .  19
       5.2.2.  OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . .  20
       5.2.3.  OSPFv2 Dynamic Flooding Opaque LSA  . . . . . . . . .  20
       5.2.4.  OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . .  22
       5.2.5.  OSPF Area Router ID TLVs  . . . . . . . . . . . . . .  22
         5.2.5.1.  OSPFv2 Area Router ID TLV . . . . . . . . . . . .  23
         5.2.5.2.  OSPFv3 Area Router ID TLV . . . . . . . . . . . .  24
       5.2.6.  OSPF Flooding Path TLV  . . . . . . . . . . . . . . .  26
       5.2.7.  OSPF Flooding Request Bit . . . . . . . . . . . . . .  27
       5.2.8.  OSPF LEEF Advertisement . . . . . . . . . . . . . . .  28
   6.  Behavioral Specification  . . . . . . . . . . . . . . . . . .  29
     6.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  29
     6.2.  Flooding Topology . . . . . . . . . . . . . . . . . . . .  29
     6.3.  Leader Election . . . . . . . . . . . . . . . . . . . . .  30
     6.4.  Area Leader Responsibilities  . . . . . . . . . . . . . .  30
     6.5.  Distributed Flooding Topology Calculation . . . . . . . .  30
     6.6.  Use of LANs in the Flooding Topology  . . . . . . . . . .  31
       6.6.1.  Use of LANs in Centralized mode . . . . . . . . . . .  31 Mode
       6.6.2.  Use of LANs in Distributed Mode . . . . . . . . . . .  31
         6.6.2.1.  Partial flooding Flooding on a LAN in IS-IS  . . . . . . .  31
         6.6.2.2.  Partial Flooding on a LAN in OSPF . . . . . . . .  32
     6.7.  Flooding Behavior . . . . . . . . . . . . . . . . . . . .  33
     6.8.  Treatment of Topology Events  . . . . . . . . . . . . . .  33
       6.8.1.  Temporary Addition of Links to the Flooding Topology  . . . . . . . . . . . . . . . . . . . . . .  34
       6.8.2.  Local Link Addition . . . . . . . . . . . . . . . . .  34
       6.8.3.  Node Addition . . . . . . . . . . . . . . . . . . . .  35
       6.8.4.  Failures of Links Not on the Flooding Topology  . . .  35
       6.8.5.  Failures of Links On the Flooding Topology  . . . . .  36
       6.8.6.  Node Deletion . . . . . . . . . . . . . . . . . . . .  36
       6.8.7.  Local Link Addition to the Flooding Topology  . . . .  36
       6.8.8.  Local Link Deletion from the Flooding Topology  . . .  37
       6.8.9.  Treatment of Disconnected Adjacent Nodes  . . . . . .  37
       6.8.10. Failure of the Area Leader  . . . . . . . . . . . . .  37
       6.8.11. Recovery from Multiple Failures . . . . . . . . . . .  38
       6.8.12. Rate-Limiting Temporary Flooding  . . . . . . . . . .  38
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  39
     7.1.  IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . .  39
     7.2.  OSPF  . . . . . . . . . . . . . . . . . . . . . . . . . .  40
       7.2.1.  OSPF Dynamic Flooding LSA TLVs Registry . . . . . . .  42
       7.2.2.  OSPF Link Attributes Sub-TLV Bit Values Registry  . .  42
     7.3.  IGP . . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  44
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  44
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  44
     10.1.
     9.1.  Normative References . . . . . . . . . . . . . . . . . .  44
     10.2.
     9.2.  Informative References . . . . . . . . . . . . . . . . .  46
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47

1.  Introduction

   In recent years, there has been increased focus on how to address the
   dynamic routing of networks that have a bipartite (a.k.a., (also known as
   spine-leaf or leaf-spine), Clos [Clos], or Fat Tree Fat-tree [Leiserson]
   topology.  Conventional Interior Gateway Protocols (IGPs, (IGPs; i.e., IS-IS
   [ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform, underperform,
   redundantly flooding information throughout the dense topology,
   leading topology.  This
   leads to overloaded control plane inputs and thereby creating create
   operational issues.  For practical considerations, network architects
   have resorted to applying unconventional techniques to address the
   problem, e.g., applying BGP in the data center [RFC7938].  However  However,
   some network architects feel that using an Exterior Gateway Protocol
   (EGP) as an IGP is sub-
   optimal, if suboptimal, perhaps only due to because of the
   configuration overhead.

   The primary issue that is demonstrated when conventional IGPs are
   applied is the poor reaction of the network to topology changes.
   Normal link state link-state routing protocols rely on a flooding algorithm for
   state distribution within an area.  In a dense topology, this
   flooding algorithm is highly redundant, resulting redundant and results in unnecessary
   overhead.  Each node in the topology receives each link state update
   multiple times.  Ultimately, all of the redundant copies will be
   discarded, but only after they have reached the control plane and
   have been processed.  This creates issues because significant link state
   database Link
   State Database (LSDB) updates can become queued behind many redundant
   copies of another update.  This delays convergence as the link state database LSDB does
   not stabilize promptly.

   In a real-world implementation, the packet queues leading to the
   control-plane
   control plane are necessarily of finite size, so if the flooding rate
   exceeds the update processing rate for long enough, then the control
   plane will be obligated to drop incoming updates.  If these lost
   updates are of significance, this will further delay the
   stabilization of the link state database LSDB and the convergence of the network.

   This is not a new problem.  Historically, when routing protocols have
   been deployed in networks where the underlying topology is a complete
   graph, there have been similar issues.  This was more common when the
   underlying link-layer fabric presented the network layer with a full
   mesh of virtual connections.  This was addressed by reducing the
   flooding topology through IS-IS Mesh Groups [RFC2973], but this
   approach requires careful configuration of the flooding topology.

   Thus, the root problem is not limited to massively scalable data
   centers.  It exists with any dense topology at scale.

   Link state

   Link-state routing protocols were conceived when links were very
   expensive and topologies were sparse.  The fact that those same
   designs are sub-optimal suboptimal in a dense topology should not come as a huge
   surprise.  Technology has progressed to the point where links are
   cheap and common.  This represents a complete reversal in the
   economic fundamentals of network engineering.  The original designs
   are to be commended for continuing to provide correct operation to
   this point, point and optimizations for operation in today's environment are
   to be expected.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   These words may also appear in this document in lower case as plain
   English words, absent words without their normative meanings.

2.  Problem Statement

   In a dense topology, the flooding algorithm that is the heart of
   conventional link state link-state routing protocols causes a great deal of
   redundant messaging.  This is exacerbated by scale.  While the
   protocol can survive this combination, the redundant messaging is
   unnecessary overhead and delays convergence.  Thus, the problem is
   how to provide routing in dense, scalable topologies with rapid
   convergence.

3.  Solution Requirements

   A solution to this problem must then meet the following requirements:

   Requirement 1:  Provide a dynamic routing solution.  Reachability
                   must be restored after any topology change.

   Requirement 2:  Provide a significant improvement in convergence.

   Requirement 3:  The solution should address a variety of dense
                   topologies.  Just addressing a complete bipartite
                   topology such as K5,8 is insufficient.  [Bondy] insufficient (see [Bondy]).
                   Multi-stage Clos topologies must also be addressed,
                   as well as topologies that are slight variants.
                   Addressing complete graphs is a good demonstration of
                   generality.

   Requirement 4:  There must be no single point of failure.  The loss
                   of any link or node should not unduly hinder
                   convergence.

   Requirement 5:  The workload for flooding should be evenly
                   distributed.  A hot spot, where one node has an
                   extreme workload, would be a performance limitation
                   and a vulnerability for resiliency.

   Requirement 6:  Dense topologies are subgraphs of much larger
                   topologies.  Operational efficiency requires that the
                   dense subgraph not operate in a radically different
                   manner than the remainder of the topology.  While
                   some operational differences are permissible, they
                   should be minimized.  Any change to any node outside
                   of the dense subgraph is not acceptable.  These
                   situations occur when massively scaled data centers
                   are part of an overall larger wide-area network.
                   Having a second protocol operating just on this
                   subgraph would add much more complexity at the edge
                   of the subgraph where the two protocols would have to
                   inter-operate.
                   interoperate.

4.  Dynamic Flooding

   The combination of a dense topology and flooding on the physical
   topology is sub-optimal suboptimal for network scaling.  However, if the flooding
   topology is decoupled from the physical topology and restricted to a
   greatly reduced portion of that topology, the result can be efficient
   flooding and all of the resilience of existing protocols.  A node that
   supports flooding on the decoupled flooding topology is said to
   support dynamic flooding.

   With dynamic flooding, the flooding topology is computed within an
   IGP area with the dense topology either centrally on an elected node,
   termed the Area Leader, or in a distributed manner on all nodes that
   are supporting Dynamic Flooding. dynamic flooding.  If the flooding topology is
   computed centrally, it is encoded into and distributed as part of the
   normal link state database. LSDB.  This is the centralized mode of operation.  If the
   flooding topology is computed in a distributed fashion, this is the
   distributed mode of operation.  Nodes within such an IGP area would
   only flood on the flooding topology.  On links outside of the
   flooding topology, normal database synchronization
   mechanisms (i.e., mechanisms, i.e.,
   OSPF database exchange, exchange and IS-IS Complete Sequence Number Protocol Data Units (CSNPs)) PDUs
   (CSNPs), would apply, but flooding may not.  Details are  The detailed behavior of
   the nodes participating in IGP is described in Section 6.  New link link-
   state information that arrives from outside of the flooding topology
   suggests that the sender has no flooding topology information or that
   it is operating on old information about the flooding topology.  In
   these cases, the new link state link-state information should be flooded on the
   flooding topology as well.

   The flooding topology covers the full set of nodes within the area,
   but excludes some of the links that standard flooding would employ.

   Since the flooding topology is computed before topology changes, the
   effort required to compute it does not factor into the convergence
   time and can be done when the topology is stable.  The  In the case of
   centralized mode, the speed of the computation and its distribution, in the case of centralized mode, distribution
   is not a significant issue.

   Graph theory defines the 'degree' "degree" of a node to be the number of edges
   that are attached to the node.  To keep the flooding workload
   scalable and distributed, there should be no nodes in the flooding
   topology that have a much higher degree than other nodes.

   If a node does not have any flooding topology information when it
   receives new link state link-state information, it should flood according to
   standard flooding rules.  This situation will occur when the dense
   topology is first established but is unlikely to recur.

   Link state

   Link-state protocols are intentionally designed to be asynchronous, asynchronous
   with nodes acting independently.  During the flooding process,
   different nodes will have different information, resulting in
   transient conditions that can temporarily produce suboptimal
   forwarding.  These periods of transient conditions are known as
   'transients.'
   "transients."

   When centralized mode is used and if, during a transient, if there are multiple flooding
   topologies being advertised, advertised during a transient, then nodes should
   flood link state link-state updates on all of the flooding topologies.  Each
   node should locally evaluate the election of the Area Leader for the
   IGP area and first flood on its flooding topology.  The rationale
   behind this is straightforward: if there is a transient and there has
   been a recent change in Area Leader, then propagating topology
   information promptly along the most likely flooding topology should
   be the priority.

   During transients, loops may form in the flooding topology.  This is
   not problematic, as the standard flooding rules would cause duplicate
   updates to be ignored.  Similarly, during transients, the flooding
   topology may become disconnected.  Section 6.8.11 discusses how such
   conditions are handled.

4.1.  Applicability

   In a complete graph, this approach is appealing because it
   drastically decreases the flooding topology without the manual
   configuration of mesh groups.  By controlling the diameter of the
   flooding topology, as well as the maximum node degree in the flooding
   topology, convergence time goals can be met, and the stability of the
   control plane can be assured.

   Similarly, in a massively scaled data center, where center (where there are many
   opportunities for redundant flooding, flooding), this mechanism ensures guarantees that
   flooding is redundant, with each leaf and spine well connected, while
   ensuring that no update takes too many hops and that no node shares
   an undue portion of the flooding effort.

   In a network where only a portion of the nodes support Dynamic
   Flooding, dynamic
   flooding, the remaining nodes will continue to perform standard
   flooding.  This is not an issue for correctness, as no node can
   become isolated.

   Flooding that is initiated by nodes that support Dynamic Flooding dynamic flooding
   will remain within the flooding topology until it reaches a legacy
   node, where standard flooding is resumed.  Standard flooding will be
   bounded by nodes supporting Dynamic Flooding, dynamic flooding, which can help limit
   the propagation of unnecessary flooding.  Whether or not the network
   can remain stable in this condition is very dependent on the number
   and location of the nodes that support Dynamic Flooding. dynamic flooding.

   During incremental deployment of dynamic flooding, an area will
   consist of one or more sets of connected nodes that support dynamic
   flooding and one or more sets of connected nodes that do not, i.e.,
   nodes that support standard flooding.  The flooding topology is the
   union of these sets of nodes.  Each set of nodes that does not
   support dynamic flooding needs to be part of the flooding topology
   and such a set of nodes may provide connectivity between two or more
   sets of nodes that support dynamic flooding.

4.2.  Leader election Election

   A single node within the dense topology is elected as an Area Leader.

   A generalization of the mechanisms used in existing Designated Router
   (OSPF) or Designated Intermediate-System (IS-IS) elections is used
   for leader election.  The elected node is known as the Area Leader.

   In the case of centralized mode, the Area Leader is responsible for
   computing and distributing the flooding topology.  When a new Area
   Leader is elected and has distributed new flooding topology
   information, then any prior Area Leaders should withdraw any of their
   flooding topology information from their link state database LSDB entries.

   In the case of distributed mode, the distributed algorithm advertised
   by the Area Leader MUST be used by all nodes that participate in
   Dynamic Flooding.
   dynamic flooding.

   Not every node needs to be a candidate to be the Area Leader within
   an area, as a single candidate is sufficient for correct operation.
   For
   However, for redundancy, however, it is strongly RECOMMENDED that there be
   multiple candidates.

4.3.  Computing the Flooding Topology

   There is a great deal of flexibility in how the flooding topology may
   be computed.  For resilience, it needs to at least contain a cycle of
   all nodes in the dense subgraph.  However, additional links could be
   added to decrease the convergence time.  The trade-off between the
   density of the flooding topology and the convergence time is a matter
   for further study.  The exact algorithm for computing the flooding
   topology in the case of the centralized computation need not be
   standardized, as it is not an interoperability issue.  Only the
   encoding of the resultant topology needs to be documented.  In the
   case of distributed mode, all nodes in the IGP area need to use the
   same algorithm to compute the flooding topology.  It is possible to
   use private algorithms to compute flooding topology, so long as all
   nodes in the IGP area use the same algorithm.

   While the flooding topology should be a covering cycle, it need not
   be a Hamiltonian cycle where each node appears only once.  In fact,
   in many relevant topologies, this will not be possible, e.g., K5,8. possible (e.g., K5,8).
   This is fortunate, as computing a Hamiltonian cycle is known to be
   NP-complete.

   A simple algorithm to compute the topology for a complete bipartite
   graph is to simply select unvisited nodes on each side of the graph
   until both sides are completely visited.  If the numbers of nodes on
   each side of the graph are unequal, then revisiting nodes on the less
   populated side of the graph will be inevitable.  This algorithm can
   run in O(N) time, so it is quite efficient.

   While a simple cycle is adequate for correctness and resiliency, it
   may not be optimal for convergence.  At scale, a cycle may have a
   diameter that is half the number of nodes in the graph.  This could
   cause an undue delay in link state link-state update propagation.  Therefore  Therefore, it
   may be useful to have a bound on the diameter of the flooding
   topology.  Introducing more links into the flooding topology would
   reduce the diameter but at the trade-off of possibly adding redundant
   messaging.  The optimal trade-off between convergence time and graph
   diameter is for further study.

   Similarly, if additional redundancy is added to the flooding
   topology, specific nodes in that topology may end up with a very high
   degree.  This could result in overloading the control plane of those
   nodes, resulting in poor convergence.  Thus, it may be preferable to
   have an upper bound on the degree of nodes in the flooding topology.
   Again, the optimal trade-off between graph diameter, node degree,
   convergence time, and topology computation time is for further study.

   If the leader chooses to include a multi-access broadcast LAN segment
   as part of the flooding topology, all of the adjacencies in that LAN
   segment should be included as well.  Once updates are flooded on the
   LAN, they will be received by every attached node.

4.4.  Topologies on Complete Bipartite Graphs

   Complete bipartite graph topologies have become popular for data
   center applications and are commonly called leaf-spine or spine-leaf
   topologies.  This section discusses some flooding topologies that are
   of particular interest in these networks.

4.4.1.  A Minimal Flooding Topology

   A Minimal Flooding Topology minimal flooding topology on a complete bipartite graph is one in
   which the topology is connected and each node has at least degree
   two.  This is of interest because it guarantees that the flooding
   topology has no single point of failure.

   In practice, this implies that every leaf node in the flooding
   topology will have a degree of two.  As there are usually more leaves
   than spines, the degree of the spines will be higher, but the load on
   the individual spines can be evenly distributed.

   This type of flooding topology is also of interest because it scales
   well.  As the number of leaves increases, it is possible to construct
   flooding topologies that perform well.  Specifically, for N spines
   and M leaves, if M >= N(N/2-1), then there is a flooding topology
   that has a diameter of four. 4.

4.4.2.  Xia Topologies

   A Xia Topology topology on a complete bipartite graph is one in which all
   spine nodes are bi-connected biconnected through leaves with degree two, but the
   remaining leaves all have degree one and are evenly distributed
   across the spines.

   Constructively, one can create a Xia topology by iterating through
   the spines.  Each spine can be connected to the next spine by
   selecting any unused leaf.  Since leaves are connected to all spines,
   all leaves will have a connection to both the first and second spine
   and one can therefore choose any leaf without loss of generality.
   Continuing this iteration across all of the spines, selecting a new
   leaf at each iteration, iteration will result in a path that connects all
   spines.  Adding one more leaf between the last and first spine will
   produce a cycle of N spines and N leaves.

   At this point, M-N leaves remain unconnected.  These can be
   distributed evenly across the remaining spines, spines and connected by a
   single link.

   Xia topologies represent a compromise that trades off increased risk
   and decreased performance for lower flooding amplification.  Xia
   topologies will have a larger diameter.  For M spines, the diameter
   will be M + 2.

   In a Xia topology, some leaves are singly connected.  This represents
   a risk in that in some failures, convergence may be delayed. delayed in some failures.  However,
   there may be some alternate behaviors that can be employed to
   mitigate these risks.  If a leaf node sees that its single link on
   the flooding topology has failed, it can compensate by performing a
   database synchronization check with a different spine.  Similarly, if
   a leaf determines that its connected spine on the flooding topology
   has failed, it can compensate by performing a database
   synchronization check with a different spine.  In both of these
   cases, the synchronization check is intended to ameliorate any delays
   in link state link-state propagation due to the fragmentation of the flooding
   topology.

   The benefit of this topology is that flooding load is easily
   understood.  Each node in the spine cycle will never receive an
   update more than twice.  For M leaves and N spines, a spine never
   transmits more than (M/N +1) updates.

4.4.3.  Optimization

   If two nodes are adjacent in the flooding topology and there is a set
   of parallel links between them, then any given update MUST be flooded
   over only one of those links.  The selection of the specific link is
   implementation-specific.

4.5.  Encoding the Flooding Topology

   There are a variety of ways that the flooding topology could be
   encoded efficiently.  If the topology was only a cycle, a simple list
   of the nodes in the topology would suffice.  However, this is
   insufficiently flexible flexible, as it would require a slightly different
   encoding scheme as soon as a single additional link is added.
   Instead, this document chooses to encode the flooding topology as a
   set of intersecting paths, where each path is a set of connected
   links.

   Advertisement of the flooding topology includes support for multi-
   access broadcast LANs.  When a LAN is included in the flooding
   topology, all edges between the LAN and nodes connected to the LAN
   are assumed to be part of the flooding topology.  To reduce the size
   of the flooding topology advertisement, explicit advertisement of
   these edges is optional.  Note that this may result in the
   possibility of "hidden nodes" or "stealth nodes" nodes", which are part of
   the flooding topology but are not explicitly mentioned in the
   flooding topology advertisements.  These hidden nodes can be found by
   examination of the Link State database LSDB where connectivity between a LAN and nodes
   connected to the LAN is fully specified.

   Note that while all nodes MUST be part of the advertised flooding
   topology, not all multi-access LANs need to be included.  Only those
   LANs which that are part of the flooding topology need to be included in
   the advertised flooding topology.

   Other encodings are certainly possible.  This document has attempted
   to make a useful trade-off between simplicity, generality, and space.

4.6.  Advertising the Local Edges Enabled for Flooding

   Correct operation of the flooding topology requires that all nodes
   which
   that participate in the flooding topology choose local links for
   flooding which that are part of the calculated flooding topology.  Failure
   to do so could result in an unexpected partition of the flooding
   topology and/or sub-optimal suboptimal flooding reduction.  As an aid to
   diagnosing problems when dynamic flooding is in use, this document
   defines a means of advertising what local edges are enabled the Local Edges Enabled for
   flooding Flooding
   (LEEF).  The protocol-specific encodings are defined in Sections
   5.1.6 and 5.2.8.

   The following guidelines apply:

   *  Advertisement of LEEFs LEEF is optional.

   *  As the flooding topology is defined in terms of edges (i.e., pairs
      of nodes) and not in terms of links, in cases where parallel
      adjacencies to the same neighbor exist, the advertisement SHOULD
      indicate that all such links have been enabled. enabled in cases where
      parallel adjacencies to the same neighbor exist.

   *  LEEF advertisements MUST NOT include edges enabled for temporary
      flooding (Section 6.7).

   *  LEEF advertisements MUST NOT be used either when calculating a
      flooding topology or when determining what links to add
      temporarily to the flooding topology when the flooding topology is
      temporarily partitioned.

5.  Protocol Elements

5.1.  IS-IS TLVs

   The following TLVs/sub-TLVs are added to IS-IS:

   1.  A sub-TLV that an IS may include in its Link State Protocol Data
       Unit PDU (LSP) to
       indicate its preference for becoming the Area Leader.

   2.  A sub-TLV that an IS may include in its LSP to indicate that it
       supports Dynamic Flooding dynamic flooding and the algorithms that it supports for
       distributed mode, if any.

   3.  A TLV to advertise the list of system IDs that compose the
       flooding topology for the area.  A system ID is an identifier for
       a node.

   4.  A TLV to advertise a path that is part of the flooding topology.

   5.  A TLV that requests flooding from the adjacent node.

5.1.1.  IS-IS Area Leader Sub-TLV

   The IS-IS Area Leader Sub-TLV allows a system to:

   1.  Indicate its eligibility and priority for becoming the Area
       Leader.

   2.  Indicate whether centralized or distributed mode is to be used to
       compute the flooding topology in the area.

   3.  Indicate the algorithm identifier for the algorithm that is used
       to compute the flooding topology in distributed mode.

   Intermediate Systems (nodes) that are not advertising this Sub-TLV sub-TLV
   are not eligible to become the Area Leader.

   The Area Leader is the node with the numerically highest Area Leader
   priority in the area.  In the event of ties, the node with the
   numerically highest system ID is the Area Leader.  Due to transients
   during database flooding, different nodes may not agree on the Area
   Leader.  This is not problematic, as subsequent flooding will cause
   the entire area to converge.

   The IS-IS Area Leader Sub-TLV is advertised as a Sub-TLV sub-TLV of the IS-IS
   Router Capability TLV-242 that is defined in TLV (242) [RFC7981] and has the following format:

    0                   1                   2                   3
    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    |   Priority    |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: IS-IS Area Leader Sub-TLV

   Type: TBD1  27

   Length:  2 octets

   Priority:  0-255, unsigned integer.  Determination of the priority is
      outside of the scope of this document.

   Algorithm: a  A numeric identifier in the range 0-255 that identifies
      the algorithm used to calculate the flooding topology.  The
      following values are defined:

      -

      0:  Centralized computation by the Area Leader.

      -

      1-127:  Standardized distributed algorithms.

      -

      128-254:  Private distributed algorithms.  Individual values are
         to be assigned according to the "Private Use" policy defined in
         Section 4.1 of [RFC8126] (see Section 7.3).

      -

      255:  Reserved

5.1.2.  IS-IS Dynamic Flooding Sub-TLV

   The IS-IS Dynamic Flooding Sub-TLV allows a system to:

   1.  Indicate that it supports Dynamic Flooding. dynamic flooding.  This is indicated by
       the advertisement of this Sub-TLV. sub-TLV.

   2.  Indicate the set of algorithms that it supports.

   In incremental deployments, understanding which nodes support Dynamic
   Flooding dynamic
   flooding can be used to optimize the flooding topology.  In
   distributed mode, knowing the capabilities of the nodes can allow the
   Area Leader to select the optimal algorithm.

   The IS-IS Dynamic Flooding Sub-TLV is advertised as a Sub-TLV sub-TLV of the
   IS-IS Router Capability TLV (242) [RFC7981] and has the following
   format:

    0                   1                   2                   3
    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    | Algorithm...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: IS-IS Dynamic Flooding Sub-TLV

   Type: TBD7  28

   Length: 1-255;  1-255 octets; number of Algorithms

   Algorithm: numeric  Numeric identifiers in the range 0-255 that identify the
      algorithm used to calculate the flooding topology, topology as described in
      Section 5.1.1.

5.1.3.  IS-IS Area Node IDs TLV

   The IS-IS Area Node IDs TLV is only used in centralized mode.

   The IS-IS Area Node IDs TLV is used by the Area Leader to enumerate
   the
   Node node IDs (System ID + pseudo-node pseudonode ID) that it has used in
   computing the area flooding topology.  Conceptually, the Area Leader
   creates a list of node IDs for all nodes in the area (including pseudo-nodes
   pseudonodes for all LANs in the topology), assigning topology) and assigns an index to
   each node, starting with index 0.  Indices are implicitly assigned
   sequentially, with the index of the first node being the Starting
   Index and each subsequent node's index is the previous node's index +
   1.

   Because the space in a single TLV is limited, more than one TLV may
   be required to encode all of the node IDs in the area.  This TLV may
   be present in multiple LSPs.

   The format of the IS-IS Area Node IDs TLV is: has the following format:

    0                   1                   2                   3
    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    | Starting Index                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L| Reserved    | Node IDs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Node IDs continued ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: IS-IS Area Node IDs TLV

   Type: TBD2  17

   Length:  3 + ((System ID Length + 1) * (number of node IDs)) in
      octets

   Starting index: Index:  The index of the first node ID that appears in this
      TLV.

   L (Last):  This bit is set if the index of the last node ID that
      appears in this TLV is equal to the last index in the full list of
      node IDs for the area.

   Node IDs:  A concatenated list of node IDs for the area area.

   If there are multiple IS-IS Area Node IDs TLVs with the L-bit L bit set are
   advertised by the same node, the TLV which that specifies the smaller
   maximum index is used and the other TLV(s) TLVs with L-bit the L bit set are
   ignored.  TLVs which that specify node IDs with indices greater than that
   specified by the TLV with the L-bit L bit set are also ignored.

5.1.4.  IS-IS Flooding Path TLV

   The IS-IS Flooding Path TLV is only used in centralized mode.

   The IS-IS Flooding Path TLV is used to denote a path in the flooding
   topology.  The goal is an efficient encoding of the links of the
   topology.  A single link is a simple case of a path that only covers
   two nodes.  A connected path may be described as a sequence of
   indices:
   indices (I1, I2, I3, ...), denoting a link from the system with index
   1 to the system with index 2, a link from the system with index 2 to
   the system with index 3, and so on.

   If a path exceeds the size that can be stored in a single TLV, then
   the path may be distributed across multiple TLVs by the replication
   of a single system index.

   Complex topologies that are not a single path can be described using
   multiple TLVs.

   The IS-IS Flooding Path TLV contains a list of system indices
   relative to the systems advertised through the IS-IS Area Node IDs
   TLV.  At least 2 indices must be included in the TLV.  Due to the
   length restriction of TLVs, this TLV can contain at most 126 system indices. indices
   at most.

   The IS-IS Flooding Path TLV has the following format:

    0                   1                   2                   3
    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    | Starting Index                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Index 2                       | Additional indices ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: IS-IS Flooding Path TLV

   Type: TBD3  18

   Length:  2 * (number of indices in the path) in octets

   Starting index: Index:  The index of the first system in the path.

   Index 2:  The index of the next system in the path.

   Additional indices (optional):  A sequence of additional indices to
      systems along the path.

5.1.5.  IS-IS Flooding Request TLV

   The IS-IS Flooding Request TLV allows a system to request an adjacent
   node to enable flooding towards it on a specific link in the case
   where the connection to the adjacent node is not part of the existing
   flooding topology.

   A node that supports Dynamic Flooding dynamic flooding MAY include the IS-IS Flooding
   Request TLV in its Intermediate System to Intermediate System IS-IS Hello (IIH) Protocol Data Units (PDUs).

   The IS-IS Flooding Request TLV has the following format:

    0                   1                   2                   3
    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    |   Levels      |    Scope      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5: IS-IS Flooding Request TLV

   Type: TBD9  19

   Length:  1 + number of advertised Flooding Scopes flooding scopes in octets

   Levels: the level(s)  The levels for which flooding is requested.  Levels are
      encoded as the circuit type as specified in IS-IS [ISO10589]

   Scope (8 bits):  Flooding Scope scope for which the flooding is requested
      as defined in the LSP Flooding Scope Identifier Registry as
      created by [RFC7356].  Inclusion of flooding scopes is optional
      and is only necessary if [RFC7356] is supported.  Multiple
      flooding scopes MAY be included.  Values are restricted to the
      range 0..127.

   Circuit Flooding Scope flooding scope MUST NOT be sent in the Flooding Request TLV
   and MUST be ignored if received.

   When the TLV is received in a level-specific LAN-Hello PDU (L1-LAN-
   IIH or L2-LAN-IIH), only levels that match the PDU type are valid.
   Levels that do not match the PDU type MUST be ignored on receipt.

   When the TLV is received in a Point-to-Point Hello (P2P-IIH), only
   levels that are supported by the established adjacency are valid.
   Levels that are not supported by the adjacency MUST be ignored on
   receipt.

   If flooding was disabled on the received link due to Dynamic
   Flooding, dynamic
   flooding, then flooding MUST be temporarily enabled over the link for
   the specified Circuit Type(s) Types and Flooding Scope(s) flooding scopes received in the in
   the IS-IS Flooding Request TLV.  Flooding MUST be enabled until the
   Circuit Type or Flooding Scope is no longer advertised in the IS-IS
   Flooding Request TLV or the TLV no longer appears in IIH PDUs
   received on the link.

   When flooding is temporarily enabled on the link for any Circuit Type
   or Flooding Scope due to receiving the IS-IS Flooding Request TLV,
   the receiver MUST perform standard database synchronization for the
   corresponding Circuit Type(s) Types and Flooding Scope(s) flooding scopes on the link.  In the
   case of IS-IS, this results in setting the Send Routeing Message
   (SRM) flag for all related LSPs on the link and sending CSNPs.

   So long as the IS-IS Flooding Request TLV is being received, flooding
   MUST NOT be disabled for any of the Circuit Types or Flooding Scopes flooding scopes
   present in the IS-IS Flooding Request TLV, even if the connection
   between the neighbors is removed from the flooding topology.
   Flooding for such Circuit Types or Flooding Scopes flooding scopes MUST continue on
   the link and be considered temporarily enabled.

5.1.6.  IS-IS LEEF Advertisement

   In support of advertising which edges are currently enabled in the
   flooding topology, an implementation MAY indicate that a link is part
   of the flooding topology by advertising a bit-value bit value in the Link
   Attributes sub-TLV defined by [RFC5029].

   The following bit-value is defined by this document:

   Local Edge Enabled for Flooding (LEEF) - suggested value 4 (to be
   assigned by IANA) (LEEF):  0x4

5.2.  OSPF LSAs and TLVs

   This section defines new LSAs Link State Advertisements (LSAs) and TLVs
   for both OSPFv2 and OSPFv3.

   The following LSAs and TLVs/sub-TLVs are added to OSPFv2/OSPFv3:

   1.  A TLV that is used to advertise the preference for becoming the
       Area Leader.

   2.  A TLV that is used to indicate the support for Dynamic Flooding dynamic flooding
       and the algorithms that the advertising node supports for
       distributed mode, if any.

   3.  An OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding
       topology for centralized mode.

   4.  A TLV to advertise the list of Router IDs that comprise the
       flooding topology for the area.

   5.  A TLV to advertise a path that is part of the flooding topology.

   6.  A bit in the LLS Link-Local Singaling (LLS) Type 1 Extended Options
       and Flags that requests flooding from the adjacent node.

5.2.1.  OSPF Area Leader Sub-TLV

   The usage of the OSPF Area Leader Sub-TLV is identical to that of the
   IS-IS and
   is Area Leader Sub-TLV described in Section 5.1.1.

   The OSPF Area Leader Sub-TLV is used by both OSPFv2 and OSPFv3.

   The OSPF Area Leader Sub-TLV is advertised as a top-level TLV of the
   RI
   Router Information (RI) LSA that is defined in [RFC7770] and has the
   following format:

    0                   1                   2                   3
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Priority   |   Algorithm   |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: OSPF Area Leader Sub-TLV

   Type: TBD4  17

   Length:  4 octets

   Priority:  0-255, unsigned integer

   Algorithm:  As defined in Section 5.1.1.

5.2.2.  OSPF Dynamic Flooding Sub-TLV

   The usage of the OSPF Dynamic Flooding Sub-TLV is identical to that
   of the IS-IS
   and is Dynamic Flooding Sub-TLV described in Section 5.1.2.

   The OSPF Dynamic Flooding Sub-TLV is used by both OSPFv2 and OSPFv3.

   The OSPF Dynamic Flooding Sub-TLV is advertised as a top-level TLV of
   the RI LSA that is defined in [RFC7770] and has the following format:

    0                   1                   2                   3
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Algorithm ... |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: OSPF Dynamic Flooding Sub-TLV

   Type: TBD8  18

   Length:  Number of Algorithms in octets

   Algorithm:  As defined in Section 5.1.1.

5.2.3.  OSPFv2 Dynamic Flooding Opaque LSA

   The OSPFv2 Dynamic Flooding Opaque LSA is only used in centralized
   mode.

   The OSPFv2 Dynamic Flooding Opaque LSA is used to advertise
   additional data related to dynamic flooding in OSPFv2.  OSPFv2 Opaque
   LSAs are described in [RFC5250].

   Multiple OSPFv2 Dynamic Flooding Opaque LSAs can be advertised by an
   OSPFv2 router.  The flooding scope of the OSPFv2 Dynamic Flooding
   Opaque LSA is area-local.

   The format of the OSPFv2 Dynamic Flooding Opaque LSA is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |   LS Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TBD5       10      |                 Opaque ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

                Figure 1: 8: OSPFv2 Dynamic Flooding Opaque LSA

   The opaque type used by OSPFv2 Dynamic Flooding Opaque LSA is TBD. 10.
   The opaque type is used to differentiate the various types of OSPFv2
   Opaque LSAs as described in section Section 3 of [RFC5250].  The LS Type is
   10.  The LSA Length field [RFC2328] represents the total length (in
   octets) of the Opaque LSA including the LSA header and all TLVs
   (including padding).

   The Opaque ID field is an arbitrary value used to maintain multiple
   Dynamic Flooding Opaque LSAs.  For OSPFv2 Dynamic Flooding Opaque
   LSAs, the Opaque ID has no semantic significance other than to
   differentiate Dynamic Flooding Opaque LSAs originated from the same
   OSPFv2 router.

   The format of the TLVs within the body of the OSPFv2 Dynamic Flooding
   Opaque LSA is the same as the format used by the Traffic Engineering
   Extensions to OSPF [RFC3630].

   The Length field defines the length of the value portion in octets
   (thus a TLV with no value portion would have a length of 0). 0 octets).
   The TLV is padded to a 4-octet alignment; padding is not included in
   the length field (so a 3-octet value would have a length of 3, 3 octets,
   but the total size of the TLV would be 8 octets).  Nested TLVs are
   also 32-bit aligned.  For example, a 1-octet value would have the
   length field set to 1, and 3 octets of padding would be added to the
   end of the value portion of the TLV.  The padding is composed of
   zeros.

5.2.4.  OSPFv3 Dynamic Flooding LSA

   The OSPFv3 Dynamic Flooding Opaque LSA is only used in centralized
   mode.

   The OSPFv3 Dynamic Flooding LSA is used to advertise additional data
   related to dynamic flooding in OSPFv3.

   The OSPFv3 Dynamic Flooding LSA has a function code of TBD. 16.  The
   flooding scope of the OSPFv3 Dynamic Flooding LSA is area-local.  The
   U bit will be set indicating that the OSPFv3 Dynamic Flooding LSA
   should be flooded even if it is not understood.  The Link State ID
   (LSID) value for this LSA is the Instance ID.  OSPFv3 routers MAY
   advertise multiple OSPFv3 Dynamic Flooding Opaque LSAs in each area.

   The format of the OSPFv3 Dynamic Flooding LSA is as follows:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |1|0|1|          TBD6           16            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Link State ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

                   Figure 2: 9: OSPFv3 Dynamic Flooding LSA

5.2.5.  OSPF Area Router ID TLVs

   In OSPF, TLVs are defined to advertise indices associated with nodes
   and Broadcast/NBMA Broadcast / Non-Broadcast Multi-Access (NBMA) networks.  Due to
   identifier differences between OSPFv2 and OSPFv3, two different TLVs
   are defined as described in the following sub-sections.

   The OSPF Area Router ID TLVs are used by the Area Leader to enumerate
   the Router IDs that it has used in computing the flooding topology.
   This includes the identifiers associated with Broadcast/NBMA networks
   as defined for Network LSAs.  Conceptually, the Area Leader creates a
   list of Router IDs for all routers in the area, assigning area and assigns an index
   to each router, starting with index 0.  Indices are implicitly
   assigned sequentially, with the index of the first node being the
   Starting Index and each subsequent node's index is the previous
   node's index + 1.

5.2.5.1.  OSPFv2 Area Router ID TLV

   This TLV is a top-level TLV of the OSPFv2 Dynamic Flooding Opaque
   LSA.

   Because the space in a single OSPFv2 opaque LSA is limited, more than
   one LSA may be required to encode all of the Router IDs in the area.
   This TLV MAY be advertised in multiple OSPFv2 Dynamic Flooding Opaque
   LSAs so that all Router IDs can be advertised.

   The format of the OSPFv2 Area Router IDs TLV is: has the following format:

    0                   1                   2                   3
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Starting Index             |L| Flags       |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-        OSPFv2 Router ID TLV Entry                           -+
   |                           ...                                 |

                   Figure 3: 10: OSPFv2 Area Router IDs TLV

      TLV

   Type:  1

      TLV

   Length:  4 + sum of the lengths of all TLV entries in octets

   Starting index: Index:  The index of the first Router/Designated Router ID
      that appears in this TLV.

   L (Last):  This bit is set if the index of the last Router/
      Designated Router/Designated
      Router ID that appears in this TLV is equal to the last index in
      the full list of Router IDs for the area.

   OSPFv2 Router ID TLV Entries:  A concatenated list of Router ID TLV
      Entries for the area.

   If there are multiple OSPFv2 Area Router ID TLVs with the L-bit L bit set are
   advertised by the same router, the TLV which that specifies the smaller
   maximum index is used and the other TLV(s) TLVs with L-bit L bit set are ignored.
   TLVs which that specify Router IDs with indices greater than that specified
   by the TLV with the L-bit L bit set are also ignored.

   Each entry in the OSPFv2 Area Router IDs TLV represents either a node
   or a Broadcast/NBMA network identifier.  An entry has the following
   format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ID Type    |  Number of IDs                |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-    Originating Router ID/DR Address                         -+
   |                     ...                                       |

                   Figure 4: 11: OSPFv2 Router IDs TLV Entry

   ID Type:  1 octet.  The following values are defined:

      -  1 -

      1:  Router

      -  2 -

      2:  Designated Router

   Number of IDs:  2 octets

   Reserved:  1 octet, octet.  MUST be transmitted as 0 and MUST be ignored on
      receipt
      receipt.

   Originating Router ID/DR Address:(4 Address:  (4 * Number of IDs) octets as
      indicated by the ID Type Type.

5.2.5.2.  OSPFv3 Area Router ID TLV

   This TLV is a top-level TLV of the OSPFv3 Dynamic Flooding LSA.

   Because the space in a single OSPFv3 Dynamic Flooding LSA is limited,
   more than one LSA may be required to encode all of the Router IDs in
   the area.  This TLV MAY be advertised in multiple OSPFv3 Dynamic
   Flooding Opaque LSAs so that all Router IDs can be advertised.

   The format of the OSPFv3 Area Router IDs TLV is: has the following format:

    0                   1                   2                   3
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Starting Index             |L| Flags       |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-        OSPFv3 Router ID TLV Entry                           -+
   |                           ...                                 |

                   Figure 5: 12: OSPFv3 Area Router IDs TLV

      TLV

   Type:  1

      TLV

   Length:  4 + sum of the lengths of all TLV entries in octets

   Starting index: Index:  The index of the first Router/Designated Router ID
      that appears in this TLV.

   L (Last):  This bit is set if the index of the last Router/
      Designated Router/Designated
      Router ID that appears in this TLV is equal to the last index in
      the full list of Router IDs for the area.

   OSPFv3 Router ID TLV Entries:  A concatenated list of Router ID TLV
      Entries for the area.

   If there are multiple OSPFv3 Area Router ID TLVs with the L-bit L bit set are
   advertised by the same router, router the TLV which that specifies the smaller
   maximum index is used and the other TLV(s) TLVs with L-bit L bit set are ignored.
   TLVs which that specify Router IDs with indices greater than that specified
   by the TLV with the L-bit L bit set are also ignored.

   Each entry in the OSPFv3 Area Router IDs TLV represents either a
   router or a Broadcast/NBMA network identifier.  An entry has the
   following format:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ID Type    |  Number of IDs                |  Reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-    Originating ID Entry                                     -+
   |                    ...                                        |

                   Figure 6: 13: OSPFv3 Router ID TLV Entry

   ID Type - Type:  1 octet.  The following values are defined:

      -  1 -

      1:  Router

      -  2 -

      2:  Designated Router

   Number of IDs - IDs:  2 octets

      Reserved -

   Reserved:  1 octet, octet.  MUST be transmitted as 0 and MUST be ignored on receipt
      receipt.

   The Originating ID Entry takes one of the following forms, depending
   on the ID Type.

   For a Router:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Originating Router ID                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of the Originating ID Entry is (4 * Number of IDs) octets.

   For a Designated Router:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Originating Router ID                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Interface ID                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of the Originating ID Entry is (8 * Number of IDs) octets octets.

5.2.6.  OSPF Flooding Path TLV

   The OSPF Flooding Path TLV is a top-level TLV of the OSPFv2 Dynamic
   Flooding Opaque LSAs and OSPFv3 Dynamic Flooding LSA.

   The usage of the OSPF Flooding Path TLV is identical to that of the
   IS-IS and is Flooding Path TLV described in Section 5.1.4.

   The OSPF Flooding Path TLV contains a list of Router ID indices
   relative to the Router IDs advertised through the OSPF Area Router
   IDs TLV.  At least 2 indices must be included in the TLV.

   Multiple OSPF Flooding Path TLVs can be advertised in a single OSPFv2
   Dynamic Flooding Opaque LSA or OSPFv3 Dynamic Flooding LSA.  OSPF
   Flooding Path TLVs can also be advertised in multiple OSPFv2 Dynamic
   Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSA, LSAs if they all can
   not
   cannot fit in a single LSA.

   The OSPF Flooding Path TLV has the following format:

    0                   1                   2                   3
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Starting Index             |       Index 2                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                        Additional Indices                   -+
   |                           ...                                 |

                     Figure 7: 14: OSPF Flooding Path TLV

      TLV

   Type:  2

      TLV

   Length:  2 * (number of indices in the path) in octets

   Starting index: Index:  The index of the first Router ID in the path.

   Index 2:  The index of the next Router ID in the path.

   Additional indices (optional):  A sequence of additional indices to
      Router IDs along the path.

5.2.7.  OSPF Flooding Request Bit

   A single new option bit, the Flooding Request (FR) bit, is defined in
   the LLS Type 1 Extended Options and Flags field [RFC5613].  The FR
   bit allows a router to request an adjacent node to enable flooding
   towards it on a specific link in the case where the connection to the
   adjacent node is not part of the current flooding topology.

   A node that supports Dynamic Flooding dynamic flooding MAY include the FR bit in its
   OSPF LLS Extended Options and Flags TLV.

   If the FR bit is signaled for a link on which flooding was disabled
   due to Dynamic Flooding, dynamic flooding, then flooding MUST be temporarily enabled
   over the link.  Flooding MUST be enabled until the FR bit is no
   longer advertised in the OSPF LLS Extended Options and Flags TLV or
   the OSPF LLS Extended Options and Flags TLV no longer appear appears in the
   OSPF Hellos.

   When flooding is temporarily enabled on the link for any area due to
   receiving the FR bit in the OSPF LLS Extended Options and Flags TLV,
   the receiver MUST perform standard database synchronization for the
   area corresponding to the link.  If the adjacency is already in the
   FULL state, the mechanism specified in [RFC4811] MUST be used for
   database resynchronization.

   So long as the FR bit is being received in the OSPF LLS Extended
   Options and Flags TLV for a link, flooding MUST NOT be disabled on
   the link link, even if the connection between the neighbors is removed
   from the flooding topology.  Flooding MUST continue on the link and
   be considered as temporarily enabled.

5.2.8.  OSPF LEEF Advertisement

   In support of advertising the specific edges that are currently
   enabled in the flooding topology, an implementation MAY indicate that
   a link is part of the flooding topology.  The OSPF Link Attributes
   Bits TLV is defined to support this advertisement.

    0                   1                   2                   3
    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Link Attribute Bits                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-            Additional Link Attribute Bits                   -+
   |                           ...                                 |

                  Figure 8: 15: OSPF Link Attributes Bits TLV

   Type: TBD and specific to OSPFv2 and OSPFv3  21 (for OSPFv2) or 10 (for OSPFv3)

   Length:  Size of the Link Attribute Bits in octets.  It MUST be a
      multiple of 4 octets.

   The following bits are defined:

   Bit #0: -  Local Edge Enabled for Flooding (LEEF)

   OSPF Link-attribute Bits TLV appears as:

   1.  A sub-TLV of the OSPFv2 Extended Link TLV [RFC7684] [RFC7684].

   2.  A sub-TLV of the OSPFv3 Router-Link TLV [RFC8362] [RFC8362].

6.  Behavioral Specification

   This section specifies the detailed behavior of the nodes
   participating in the IGP.

6.1.  Terminology

   Some terminology to be used in the following sections:

   Reachable:  A node is considered reachable if it is part of the
      connected network graph.  Note that this is independent of any
      constraints that may be considered when performing IGP shortest-path shortest-
      path tree
      calculation (e.g., calculation, e.g., link metrics, overload bit state, etc.).
      etc.  The two-way connectivity check MUST be performed before
      including an edge in the connected network graph.

   Connected:  A node is connected to the flooding topology, topology if it has at
      least one local link, which is part of the flooding topology.

   Disconnected:  A node is disconnected from the flooding topology when
      it is not connected to the flooding topology.

   Current flooding topology - topology:  The latest version of the flooding
      topology that has been received (in the case of centralized mode)
      or calculated locally (in the case of distributed mode).

6.2.  Flooding Topology

   The flooding topology MUST include all reachable nodes in the area.

   If a node's reachability changes, the flooding topology MUST be
   recalculated.  In centralized mode, the Area Leader MUST advertise a
   new flooding topology.

   If a node becomes disconnected from the current flooding topology but
   is still reachable, then a new flooding topology MUST be calculated.
   In centralized mode, the Area Leader MUST advertise the new flooding
   topology.

   The flooding topology SHOULD be bi-connected biconnected to provide network
   resiliency, but this does incur some amount of redundant flooding.
   Xia topologies (Section 4.4.2) are an example of an explicit decision
   to sacrifice resiliency to avoid redundancy.

6.3.  Leader Election

   Any capable node MAY advertise its eligibility to become the Area
   Leader.

   Nodes that are not reachable are not eligible to become the Area
   Leader.  Nodes that do not advertise their eligibility to become the
   Area Leader are not eligible.  Amongst the eligible nodes, the node
   with the numerically highest priority is the Area Leader.  If
   multiple nodes all have the highest priority, then the node with the
   numerically highest system identifier in (in the case of IS-IS, IS-IS) or
   Router-ID in
   Router ID (in the case of OSPFv2 and OSPFv3 OSPFv3) is the Area Leader.

6.4.  Area Leader Responsibilities

   If the Area Leader operates in centralized mode, it MUST advertise
   algorithm 0 in its Area Leader Sub-TLV.  For Dynamic Flooding dynamic flooding to be
   enabled, it also MUST compute and advertise a flooding topology for
   the area.  The Area Leader may update the flooding topology at any
   time, however,
   time.  However, it should not destabilize the network with undue or
   overly frequent topology changes.  If the Area Leader operates in
   centralized mode and needs to advertise a new flooding topology, it
   floods the new flooding topology on both the new and old flooding
   topologies.

   If the Area Leader operates in distributed mode, it MUST advertise a
   non-zero
   nonzero algorithm in its Area Leader Sub-TLV.

   When the Area Leader advertises algorithm 0 in its Area Leader Sub-
   TLV and does not advertise a flooding topology, Dynamic Flooding dynamic flooding is
   disabled for the area.  Note this applies whether the Area Leader
   intends to operate in centralized mode or distributed mode.

   Note that once Dynamic Flooding dynamic flooding is enabled, disabling it risks
   destabilizing the network due to the issues discussed in Section 1.

6.5.  Distributed Flooding Topology Calculation

   If the Area Leader advertises a non-zero nonzero algorithm in its Area Leader
   Sub-TLV, all nodes in the area that support Dynamic Flooding dynamic flooding and
   support the algorithm advertised by the Area Leader MUST compute the
   flooding topology based on the Area Leader's advertised algorithm.

   Nodes that do not support the advertised algorithm MUST continue to
   use standard IS-IS/OSPF flooding mechanisms.  Nodes that do not
   support the flooding algorithm advertised by the Area Leader MUST be
   considered as Dynamic Flooding dynamic flooding incapable nodes by the Area Leader.

   If the value of the algorithm advertised by the Area Leader is from
   the range 128-254 (private distributed algorithms), it is the
   responsibility of the network operator to guarantee that all nodes in
   the area agree on the dynamic flooding algorithm corresponding to the
   advertised value.

6.6.  Use of LANs in the Flooding Topology

   The use of LANs in the flooding topology differs depending on whether
   the area is operating in centralized mode or distributed mode.

6.6.1.  Use of LANs in Centralized mode Mode

   As specified in Section 4.5, when a LAN is advertised as part of the
   flooding topology, all nodes connected to the LAN are assumed to be
   using the LAN as part of the flooding topology.  This assumption is
   made to reduce the size of the Flooding Topology flooding topology advertisement.

6.6.2.  Use of LANs in Distributed Mode

   In distributed mode, the flooding topology is NOT advertised,
   therefore advertised; thus,
   the space consumed to advertise it is not a concern.  It  Therefore, it
   is
   therefore possible to assign only a subset of the nodes connected to the LAN
   to use the LAN as part of the flooding topology.  Doing so may
   further optimize flooding by reducing the amount of redundant
   flooding on a LAN.  However, support of flooding by a subset of the
   nodes connected to a LAN requires some modest, modest but backward-
   compatible, backward-compatible
   changes in the way flooding is performed on a LAN.

6.6.2.1.  Partial flooding Flooding on a LAN in IS-IS

   The Designated Intermediate System (DIS) for a LAN MUST use the
   standard flooding behavior.

   Non-DIS nodes whose connection to the LAN is included in the flooding
   topology MUST use the standard flooding behavior.

   Non-DIS nodes whose connection to the LAN is NOT included in the
   flooding topology behave as follows:

   *  Received CSNPs from the DIS are ignored.

   *  Partial Sequence Number Protocol Data Units PDUs (PSNPs) are NOT originated on the
      LAN.

   *  An LSP that is received on the LAN that and is newer than the
      corresponding LSP present in the LSPDB Link State PDU Database (LSPDB)
      is retained and flooded on all local circuits which that are part of the
      flooding topology (i.e., do not discard newer LSPs simply because
      they were received on a LAN
      which that the receiving node is not using
      for flooding).

   *  An LSP received on the LAN which that is older or the same as the
      corresponding LSP in the LSPDB is silently discarded.

   *  LSPs received on links other than the LAN are NOT flooded on the
      LAN.

   NOTE: If any node connected to the LAN requests the enablement of
   temporary flooding, all nodes MUST revert to the standard flooding
   behavior on the LAN.

6.6.2.2.  Partial Flooding on a LAN in OSPF

   The Designated Router (DR) and Backup Designated Router (BDR) for
   LANs MUST use the standard flooding behavior.

   Non-DR/BDR nodes with a connection to a LAN that is included in the
   flooding topology use the standard flooding behavior on that LAN.

   Non-DR/BDR nodes with a connection to a LAN that is NOT included in
   the flooding topology behave as follows:

   *  LSAs received on the LAN are acknowledged to the DR/BDR.

   *  LSAs received on interfaces other than the LAN are NOT flooded on
      the LAN.

   NOTE: If any node connected to the LAN requests the enablement of
   temporary flooding, all nodes revert to the standard flooding
   behavior.

   NOTE: The sending of LSA Acks Acknowledgements by nodes NOT using the LAN
   as part of the flooding topology eliminates the need for changes on
   the part of the DR/BDR, which might include nodes that do not support
   the dynamic flooding algorithm.

6.7.  Flooding Behavior

   Nodes that support Dynamic Flooding dynamic flooding MUST use the flooding topology
   for flooding when possible, possible and MUST NOT revert to standard flooding
   when a valid flooding topology is available.

   In some cases, a node that supports Dynamic Flooding dynamic flooding may need to add
   a
   local link(s) links to the flooding topology temporarily, even though the
   link(s) is
   links are not part of the calculated flooding topology.  This is
   termed "temporary flooding" and is discussed in Section 6.8.1.

   In distributed mode, the flooding topology is calculated locally.  In
   centralized mode, the flooding topology is advertised in the area
   link state database.
   LSDB.  Received link state link-state updates, whether received on a link that
   is in the flooding topology or on a link that is not in the flooding
   topology, MUST be flooded on all links that are in the flooding topology,
   topology except for the link on which the update was received.

   In centralized mode, new information in the form of new paths or new
   node ID assignments can be received at any time.  This may replace
   some or all of the existing information about the flooding topology.
   There may be transient conditions where the information that a node
   has is inconsistent or incomplete.  If a node detects that its
   current information is inconsistent, then the node may wait for an
   implementation-specific amount of time, expecting more information to
   arrive that will provide a consistent, complete view of the flooding
   topology.

   In both centralized and distributed mode, if a node determines that
   some of its adjacencies are to be added to the flooding topology, it
   should add those and begin flooding on those adjacencies immediately.
   If a node determines that adjacencies are to be removed from the
   flooding topology, then it should wait for an implementation-specific
   amount of time before acting on that information.  This serves to
   ensure that new information is flooded promptly and completely,
   allowing all nodes to receive updates in a timely fashion.

6.8.  Treatment of Topology Events

   This section explicitly considers a variety of different topological
   events in the network and how Dynamic Flooding dynamic flooding should address them.

6.8.1.  Temporary Addition of Links to the Flooding Topology

   In some cases, a node that supports Dynamic Flooding may need to add
   a local link(s) to the flooding topology temporarily, even though the
   link(s) is not part of the calculated flooding topology.  This is
   referred to as "temporary flooding" on the link.

   When temporary flooding is enabled on the link, the flooding needs to
   be enabled in both directions on the link. directions.  To achieve that, the following steps
   MUST be performed:

   *  The Link State Database LSDB needs to be re-synchronised resynchronised on the link.  This is done
      using the standard protocol mechanisms.  In the case of IS-IS,
      this results in setting the SRM bit for all LSPs on the circuit
      and sending a complete set of CSNPs on the link.  In OSPF, the
      mechanism specified in [RFC4811] is used.

   *  Flooding is enabled locally on the link.

   *  Flooding is requested from the neighbor using the mechanism
      specified in section Section Sections 5.1.5 or Section 5.2.7.

   The request for temporary flooding MUST be withdrawn on the link when
   all of the following conditions are met:

   *  The node itself is connected to the current flooding topology.

   *  The adjacent node is connected to the current flooding topology.

   Any change in the flooding topology MUST result in an evaluation of
   the above conditions for any link on which temporary flooding was
   enabled.

   Temporary flooding is stopped on the link when both adjacent nodes
   stop requesting temporary flooding on the link.

6.8.2.  Local Link Addition

   If a local link is added to the topology, the protocol will form a
   normal adjacency on the link and update the appropriate link state
   advertisements LSAs for the
   nodes on either end of the link.  These link state updates will be
   flooded on the flooding topology.

   In centralized mode, the Area Leader, upon receiving these updates, Leader may choose to retain the
   existing flooding topology or may choose to modify the flooding topology. topology upon
   receiving these updates.  If the Area Leader decides to change the
   flooding topology, it will update the flooding topology in the
   link state database LSDB
   and flood it using the new flooding topology.

   In distributed mode, any change in the topology, including the link
   addition, MUST trigger the flooding topology recalculation.  This is
   done to ensure that all nodes converge to the same flooding topology,
   regardless of the time of the calculation.

   Temporary flooding MUST be enabled on the newly added local link, link as
   long as at least one of the following conditions are met:

   *  The node on which the local link was added is not connected to the
      current flooding topology.

   *  The new adjacent node is not connected to the current flooding
      topology.

   Note that in this case there is no need to perform a database
   synchronization as part of the enablement of the temporary flooding, flooding
   because it was part of the adjacency bring-up itself.

   If multiple local links are added to the topology before the flooding
   topology is updated, temporary flooding MUST be enabled on a subset
   of these links per the conditions discussed in Section 6.8.12.

6.8.3.  Node Addition

   If a node is added to the topology, then at least one link is also
   added to the topology.  Section 6.8.2 applies.

   A node that has a large number of neighbors is at risk of introducing
   a local flooding storm if all neighbors are brought up at once and
   temporary flooding is enabled on all links simultaneously.  The most
   robust way to address this is to limit the rate of initial adjacency
   formation following bootup.  This reduces unnecessary redundant
   flooding as part of initial database synchronization and minimizes
   the need for temporary flooding flooding, as it allows time for the new node
   to be added to the flooding topology after only a small number of
   adjacencies have been formed.

   In the event a node elects to bring up a large number of adjacencies
   simultaneously, a significant amount of redundant flooding may be
   introduced as multiple neighbors of the new node enable temporary
   flooding to the new node node, which initially is not part of the flooding
   topology.

6.8.4.  Failures of Links Not on the Flooding Topology

   If a link that is not part of the flooding topology fails, then the
   adjacent nodes will update their link state advertisements LSAs and flood them on the flooding
   topology.

   In centralized mode, the Area Leader, upon receiving these updates, Leader may choose to retain the
   existing flooding topology or may choose to modify the flooding topology. topology upon
   receiving these updates.  If it elects to change the flooding
   topology, it will update the flooding topology in the link state
   database LSDB and flood
   it using the new flooding topology.

   In distributed mode, any change in the topology, including the
   failure of the link that is not part of the flooding topology topology, MUST
   trigger the flooding topology recalculation.  This is done to ensure
   that all nodes converge to the same flooding topology, regardless of
   the time of the calculation.

6.8.5.  Failures of Links On the Flooding Topology

   If there is a failure on the flooding topology, the adjacent nodes
   will update their link state advertisements LSAs and flood them.  If the original flooding
   topology is bi-connected, biconnected, the flooding topology should still be
   connected despite a single failure.

   If the failed local link represented the only connection to the
   flooding topology on the node where the link failed, the node MUST
   enable temporary flooding on a subset of its local links.  This
   allows the node to send its updated link state advertisement(s) LSAs and
   also, keep receiving link state receive link-state
   updates from other nodes in the network before the new flooding
   topology is calculated and distributed (in the case of centralized
   mode).

   In centralized mode, the Area Leader will notice the change in the
   flooding topology, recompute the flooding topology, and flood it
   using the new flooding topology.

   In distributed mode, all nodes supporting dynamic flooding will
   notice the change in the topology and recompute the new flooding
   topology.

6.8.6.  Node Deletion

   If a node is deleted from the topology, then at least one link is
   also removed from the topology.  Section 6.8.4 and Section 6.8.5
   apply.

6.8.7.  Local Link Addition to the Flooding Topology

   If the flooding topology changes and a local link that was not part
   of the flooding topology is now part of the flooding topology, then
   the node MUST:

      Re-synchronize

   *  Resynchronize the Link State Database LSDB over the link.  This is done using the
      standard protocol mechanisms.  In the case of IS-
      IS, IS-IS, this requires
      sending a complete set of CSNPs.  In OSPF, the mechanism specified
      in [RFC4811] is used.

   *  Make the link part of the flooding topology and start flooding on
      it.

6.8.8.  Local Link Deletion from the Flooding Topology

   If the flooding topology changes and a local link that was part of
   the flooding topology is no longer part of the flooding topology,
   then the node MUST remove the link from the flooding topology.

   The node MUST keep flooding on such link for a limited amount of time
   to allow other nodes to migrate to the new flooding topology.

   If the removed local link represented the only connection to the
   flooding topology on the node, the node MUST enable temporary
   flooding on a subset of its local links.  This allows the node to
   send its updated link state advertisement(s) LSAs and also keep receiving
   link state receive link-state updates from other nodes
   in the network before the new flooding topology is calculated and
   distributed (in the case of centralized mode).

6.8.9.  Treatment of Disconnected Adjacent Nodes

   Every time there is a change in the flooding topology, a node MUST
   check if any adjacent nodes are disconnected from the current
   flooding topology.  Temporary flooding MUST be enabled towards a
   subset of the disconnected nodes per the discussion in Section Sections 6.8.12 and Section 6.7.

6.8.10.  Failure of the Area Leader

   The failure of the Area Leader can be detected by observing that it
   is no longer reachable.  In this case, the Area Leader election
   process is repeated and a new Area Leader is elected.

   To minimize disruption to Dynamic Flooding dynamic flooding if the Area Leader becomes
   unreachable, the node that has the second-highest priority for
   becoming Area Leader (including the system identifier/Router-ID tie-
   breaker identifier / Router ID
   tiebreaker if necessary) SHOULD advertise the same algorithm in its
   Area Leader Sub-TLV as the Area Leader and (in centralized mode)
   SHOULD advertise a flooding topology.  This SHOULD be done even when
   the Area Leader is reachable.

   In centralized mode, the new Area Leader will compute a new flooding
   topology and flood it using the new flooding topology.  To minimize
   disruption, the new flooding topology SHOULD have as much in common
   as possible with the old flooding topology.  This will minimize the
   risk of over-flooding. excess flooding with the new flooding topology.

   In the distributed mode, the new flooding topology will be calculated
   on all nodes that support the algorithm that is advertised by the new
   Area Leader.  Nodes that do not support the algorithm advertised by
   the new Area Leader will no longer participate in Dynamic Flooding dynamic flooding
   and will revert to standard flooding.

6.8.11.  Recovery from Multiple Failures

   In the event of multiple failures on the flooding topology, it may
   become partitioned.  The nodes that remain active on the edges of the
   flooding topology partitions will recognize this and will try to
   repair the flooding topology locally by enabling temporary flooding
   towards the nodes that they consider disconnected from the flooding
   topology until a new flooding topology becomes connected again.

   Nodes, where local failure was detected, update their link state
   advertisements LSAs and flood
   them on the remainder of the flooding topology.

   In centralized mode, the Area Leader will notice the change in the
   flooding topology, recompute the flooding topology, and flood it
   using the new flooding topology.

   In distributed mode, all nodes that actively participate in Dynamic
   Flooding dynamic
   flooding will compute the new flooding topology.

   Note that this is very different from the area partition because
   there is still a connected network graph between the nodes in the
   area.  The area may remain connected and forwarding may still be
   functioning correctly.

6.8.12.  Rate-Limiting Temporary Flooding

   As discussed in the previous sections, some events require the
   introduction of temporary flooding on edges that are not part of the
   current flooding topology.  This can occur regardless of whether the
   area is operating in centralized mode or distributed mode.

   Nodes that decide to enable temporary flooding also have to decide
   whether to do so on a subset of the edges that are currently not part
   of the flooding topology or on all the edges that are currently not
   part of the flooding topology.  Doing the former risks a longer
   convergence time as it may miss vital edges and not fully repair the
   flooding topology.  Doing the latter risks introducing a flooding
   storm that destabilizes the network.

   It is recommended that a node rate limit the number of edges on which
   it chooses to enable temporary flooding.  Initial values for the
   number of edges on which to enable temporary flooding and the rate at
   which additional edges may subsequently be enabled is left as an
   implementation decision.

7.  IANA Considerations

7.1.  IS-IS

   This document requests the

   The following code points from have been assigned in the "IS-IS Sub-
   TLVs Sub-TLVs
   for IS-IS Router CAPABILITY TLV" registry (IS-IS TLV 242).

      Type: TBD1

      Description:

       +======+========================+==========================+
       | Type | Description            | Reference                |
       +======+========================+==========================+
       | 27   | IS-IS Area Leader Sub-TLV

      Reference: This document      | RFC 9667 (Section 5.1.1)

      Type: TBD7

      Description: |
       +------+------------------------+--------------------------+
       | 28   | IS-IS Dynamic Flooding Sub-TLV

      Reference: This document | RFC 9667 (Section 5.1.2)

   This document requests that |
       +------+------------------------+--------------------------+

                                 Table 1

   IANA allocate and assign has assigned code points from the "IS-IS Top-Level TLV
   Codepoints" registry.  One registry, one for each of the following TLVs:

      Type: TBD2

      Description:

       +======+========================+==========================+
       | Type | Description            | Reference                |
       +======+========================+==========================+
       | 17   | IS-IS Area System Node IDs TLV

      Reference: This document    | RFC 9667 (Section 5.1.3)

      Type: TBD3

      Description: |
       +------+------------------------+--------------------------+
       | 18   | IS-IS Flooding Path TLV

      Reference: This document    | RFC 9667 (Section 5.1.4)

      Type: TBD9

      Description: |
       +------+------------------------+--------------------------+
       | 19   | IS-IS Flooding Request TLV
      Reference: This document | RFC 9667 (Section 5.1.5)

   This document requests that |
       +------+------------------------+--------------------------+

                                 Table 2

   IANA extend has extended the "IS-IS Neighbor Link-
   Attribute Link-Attribute Bit Values"
   registry to contain a an "L2BM" column that indicates if a bit may
   appear in an L2 Bundle Member Attributes TLV.  All existing rows should have
   the value "N" for "L2BM".  The following explanatory note should be has been
   added to the registry:

   |  The "L2BM" column indicates applicability to the L2 Bundle Member
   |  Attributes TLV.  The options for the "L2BM" column are:
   |
   |  Y - This bit MAY appear in the L2 Bundle Member Attributes TLV.
   |
   |  N - This bit MUST NOT appear in the L2 Bundle Member Attributes
   |  TLV.

   This document requests that

   IANA allocate has allocated a new bit-value from the "IS-IS Neighbor Link-Attribute Link-
   Attribute Bit Values" registry.

      Value:

   +=======+======+========================================+===========+
   | Value | L2BM | Name                                   | Reference |
   +=======+======+========================================+===========+
   | 0x4 (suggested, to be assigned by IANA)

      L2BM:   | N

      Name:    | Local Edge Enabled                     | RFC 9667  |
   |       |      | for Flooding (LEEF)

      Reference: This document                    |           |
   +-------+------+----------------------------------------+-----------+

                                  Table 3

7.2.  OSPF

   This document requests the

   The following code points from have been assigned in the "OSPF Router
   Information (RI) TLVs" registry:

      Type: TBD4

      Description:

       +=======+=======================+==========================+
       | Value | TLV Name              | Reference                |
       +=======+=======================+==========================+
       | 17    | OSPF Area Leader Sub-TLV

      Reference: This document      | RFC 9667 (Section 5.2.1)

      Type: TBD8

      Description: |
       +-------+-----------------------+--------------------------+
       | 18    | OSPF Dynamic Flooding Sub-TLV

      Reference: This document | RFC 9667 (Section 5.2.2)

   This document requests the |
       +-------+-----------------------+--------------------------+

                                 Table 4

   The following code point from points have been assigned in the "Opaque
   Link-State Link-
   State Advertisements (LSA) Option Types" registry:

      Type: TBD5
      Description:

     +=======+====================================+=================+
     | Value | Opaque Type                        | Reference       |
     +=======+====================================+=================+
     | 10    | OSPFv2 Dynamic Flooding Opaque LSA

      Reference: This document | RFC 9667        |
     |       |                                    | (Section 5.2.3)

   This document requests the |
     +-------+------------------------------------+-----------------+

                                 Table 5

   The following code point from has been assigned in the "OSPFv3 LSA
   Function Codes" registry:

      Type: TBD6

      Description:

    +=======+=============================+==========================+
    | Value | LSA Function Code Name      | Reference                |
    +=======+=============================+==========================+
    | 16    | OSPFv3 Dynamic Flooding LSA

      Reference: This document | RFC 9667 (Section 5.2.4)

   This document requests |
    +-------+-----------------------------+--------------------------+

                                 Table 6

   IANA has assigned a new bit in the "LLS Type 1 Extended Options and
   Flags" registry:

    +==============+======================+==========================+
    | Bit Position: TBD10

      Description: Position | Description          | Reference                |
    +==============+======================+==========================+
    | 0x00000020   | Flooding Request bit

      Reference: This document | RFC 9667 (Section 5.2.7)

   This document requests the |
    +--------------+----------------------+--------------------------+

                                 Table 7

   The following code point from has been assigned in the "OSPFv2 Extended
   Link TLV Sub-TLVs" registry:

      Type: TBD11

      Description:

     +======+========================+===========+===================+
     | Type | Description            | Reference | L2 Bundle Member  |
     |      |                        |           | Attributes (L2BM) |
     +======+========================+===========+===================+
     | 21   | OSPFv2 Link Attributes | RFC 9667  | Y                 |
     |      | Bits Sub-TLV

      Reference: This document           | (Section  |                   |
     |      |                        | 5.2.8)

      L2 Bundle Member Attributes (L2BM): Y

   This document requests the    |                   |
     +------+------------------------+-----------+-------------------+

                                  Table 8

   The following code point from has been assigned in the "OSPFv3 Extended
   LSA Sub-TLVs" registry:

      Type: TBD12

      Description:

     +======+========================+===========+===================+
     | Type | Description            | Reference | L2 Bundle Member  |
     |      |                        |           | Attributes (L2BM) |
     +======+========================+===========+===================+
     | 10   | OSPFv3 Link Attributes | RFC 9667  | Y                 |
     |      | Bits Sub-TLV

      Reference: This document           | (Section  |                   |
     |      |                        | 5.2.8)

      L2 Bundle Member Attributes (L2BM): Y    |                   |
     +------+------------------------+-----------+-------------------+

                                  Table 9

7.2.1.  OSPF Dynamic Flooding LSA TLVs Registry

   This specification also requests a

   A new registry - has been created: "OSPF Dynamic Flooding LSA TLVs".
   New values can be allocated via IETF Review or IESG Approval.

   The "OSPF Dynamic Flooding LSA TLVs" registry will define defines top-level TLVs
   for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic
   Flooding LSAs.  It should be has been added to the "Open Shortest Path First
   (OSPF) Parameters" registries registry group.

   The following initial values are have been allocated:

      Type:

        +======+======================+==========================+
        | Type | Description          | Reference                |
        +======+======================+==========================+
        | 0

      Description:    | Reserved

      Reference: This document

      Type:             | RFC 9667                 |
        +------+----------------------+--------------------------+
        | 1

      Description:    | OSPF Area Router IDs TLV

      Reference: This document | RFC 9667 (Section 5.2.5)

      Type: |
        +------+----------------------+--------------------------+
        | 2

      Description:    | OSPF Flooding Path TLV

      Reference: This document   | RFC 9667 (Section 5.2.6) |
        +------+----------------------+--------------------------+

                                 Table 10

   Types in the range 32768-33023 are Reserved for experimental use; Experimental Use;
   these will not be registered with IANA, IANA and MUST NOT be mentioned by
   RFCs.

   Types in the range 33024-65535 are Reserved.  They are not to be
   assigned at this time.  Before any assignments can be made in the
   33024-65535 range, there MUST be an IETF specification that specifies
   IANA Considerations that cover the range being assigned.

7.2.2.  OSPF Link Attributes Sub-TLV Bit Values Registry

   This specification also requests a

   A new registry - has been created: "OSPF Link Attributes Sub-TLV Bit
   Values".  New values can be allocated via IETF Review or IESG
   Approval.

   The "OSPF Link Attributes Sub-TLV Bit Values" registry defines Link
   Attribute bit-values for the OSPFv2 Link Attributes Sub-TLV and
   OSPFv3 Link Attributes Sub-TLV.  It should be has been added to the "Open
   Shortest Path First (OSPF) Parameters" registries registry group.  This registry should contain
   contains a column "L2BM" that indicates if a bit may appear in an L2
   Bundle Member Attributes (L2BM) sub-TLV. Sub-TLV.  The following explanatory
   note should be has been added to the registry:

   |  The "L2BM" column indicates applicability to the L2 Bundle Member
   |  Attributes sub-TLV.  The options for the "L2BM" column are:
   |
   |  Y - This bit MAY appear in the L2 Bundle Member Attributes sub-
   |  TLV.
   |
   |  N - This bit MUST NOT appear in the L2 Bundle Member Attributes
   |  sub-TLV.

   The following initial value is allocated:

     +========+=====================+===========+===================+
     | Bit Number:    | Description         | Reference | L2 Bundle Member  |
     | Number |                     |           | Attributes (L2BM) |
     +========+=====================+===========+===================+
     | 0

      Description:      | Local Edge Enabled  | RFC 9667  | N                 |
     |        | for Flooding(LEEF)

      Reference: This document Flooding (LEEF) | (Section  |                   |
     |        |                     | 5.2.8)

      L2 Bundle Member Attributes (L2BM): N    |                   |
     +--------+---------------------+-----------+-------------------+

                                 Table 11

7.3.  IGP

   IANA is requested to set up has created a registry called "IGP Algorithm Type For Computing
   Flooding Topology" under in the existing "Interior Gateway Protocol (IGP)
   Parameters" IANA registry. registry group.

   The registration policy for this registry is Expert Review.

   Values in this registry come from the range 0-255.

   The initial values in the IGP "IGP Algorithm Type For Computing Flooding
   Topology
   Topology" registry are:

      0: are as follows:

      +=========+==================================================+
      | Value   | Description                                      |
      +=========+==================================================+
      | 0       | Reserved for centralized mode.

      1-127: mode                    |
      +---------+--------------------------------------------------+
      | 1-127   | Unassigned.  Individual values are to be         |
      |         | assigned according to the "Expert Review" policy |
      |         | defined in [RFC8126].  The designated experts    |
      |         | should require a clear, public specification of  |
      |         | the algorithm and comply with [RFC7370].

      128-254:         |
      +---------+--------------------------------------------------+
      | 128-254 | Reserved for private use.

      255: Reserved. Private Use                         |
      +---------+--------------------------------------------------+
      | 255     | Reserved                                         |
      +---------+--------------------------------------------------+

                                 Table 12

8.  Security Considerations

   This document introduces no new security issues.  Security of routing
   within a domain is already addressed as part of the routing protocols
   themselves.  This document proposes no changes to those security
   architectures.

   An attacker could become the Area Leader and introduce a flawed
   flooding algorithm into the network thus compromising the operation
   of the protocol.  Authentication methods as described in [RFC5304]
   and [RFC5310] for IS-IS, [RFC2328] and [RFC7474] for OSPFv2 OSPFv2, and
   [RFC5340] and [RFC4552] for OSPFv3 SHOULD be used to prevent such
   attacks.

9.  Acknowledgements

   The authors would like to thank Sarah Chen, Tony Przygienda, Dave
   Cooper, Gyan Mishra, and Les Ginsberg for their contribution to this
   work.  The authors would also like to thank Arista Networks for
   supporting the development of this technology.

   The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam
   Sweeney, Acee Lindem, and Olufemi Komolafe for their helpful
   comments.

   The authors would like to thank Tom Edsall for initially introducing
   them to the problem.

   Advertising Local Edges Enabled for Flooding (LEEF) is based on an
   idea proposed by Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng
   Liu, Yanhe Fan, and Lei Liu.  We wish to thank them for their
   contribution.

10.  References

10.1.

9.1.  Normative References

   [ISO10589] ISO, "Intermediate "Information technology — Telecommunications and
              information exchange between systems — Intermediate System
              to Intermediate System Intra-
              Domain Routing Exchange Protocol intra-domain routeing information
              exchange protocol for use in Conjunction conjunction with the Protocol protocol
              for Providing providing the Connectionless-mode
              Network Service connectionless-mode network service (ISO
              8473)", Second Edition, ISO/IEC 10589:2002, October
              2002. November 2002,
              <https://www.iso.org/standard/30932.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
              <https://www.rfc-editor.org/info/rfc4552>.

   [RFC5029]  Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link
              Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029,
              September 2007, <https://www.rfc-editor.org/info/rfc5029>.

   [RFC5250]  Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
              July 2008, <https://www.rfc-editor.org/info/rfc5250>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <https://www.rfc-editor.org/info/rfc5304>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310, February
              2009, <https://www.rfc-editor.org/info/rfc5310>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.

   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
              Yeung, "OSPF Link-Local Signaling", RFC 5613,
              DOI 10.17487/RFC5613, August 2009,
              <https://www.rfc-editor.org/info/rfc5613>.

   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
              Scope Link State PDUs (LSPs)", RFC 7356,
              DOI 10.17487/RFC7356, September 2014,
              <https://www.rfc-editor.org/info/rfc7356>.

   [RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
              "Security Extension for OSPFv2 When Using Manual Key
              Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
              <https://www.rfc-editor.org/info/rfc7474>.

   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <https://www.rfc-editor.org/info/rfc7684>.

   [RFC7770]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
              S. Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
              February 2016, <https://www.rfc-editor.org/info/rfc7770>.

   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,
              <https://www.rfc-editor.org/info/rfc7981>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
              F. Baker, "OSPFv3 Link State Advertisement (LSA)
              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
              2018, <https://www.rfc-editor.org/info/rfc8362>.

10.2.

9.2.  Informative References

   [Bondy]    Bondy, J. A. and U. S. R. Murty, "Graph Theory With
              Applications", Elsevier Science Publishing Co., Inc.,
              ISBN 0-444-19451-7, 1976,
              <https://www.zib.de/groetschel/teaching/WS1314/
              BondyMurtyGTWA.pdf>.  ISBN 0-444-19451-7

   [Clos]     Clos, C., "A Study study of Non-Blocking Switching Networks", non-blocking switching networks",
              The Bell System Technical Journal Vol. 32(2), Journal, Volume 32, Issue 2, pp.
              406-424, DOI 10.1002/j.1538-7305.1953.tb01433.x, March
              1953,
              <http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
              <https://doi.org/10.1002/j.1538-7305.1953.tb01433.x>.

   [Leiserson]
              Leiserson, C. E., "Fat-Trees: "Fat-trees: Universal Networks networks for
              Hardware-Efficient Supercomputing",
              hardware-efficient supercomputing", IEEE Transactions on
              Computers 34(10):892-901, 1985.
              Computers, Volume C-34, Issue 10, pp. 892-901,
              DOI 10.1109/TC.1985.6312192, October 1985,
              <https://doi.org/10.1109/TC.1985.6312192>.

   [RFC2973]  Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",
              RFC 2973, DOI 10.17487/RFC2973, October 2000,
              <https://www.rfc-editor.org/info/rfc2973>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC4811]  Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link
              State Database (LSDB) Resynchronization", RFC 4811,
              DOI 10.17487/RFC4811, March 2007,
              <https://www.rfc-editor.org/info/rfc4811>.

   [RFC7370]  Ginsberg, L., "Updates to the IS-IS TLV Codepoints
              Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
              <https://www.rfc-editor.org/info/rfc7370>.

   [RFC7938]  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>.

Acknowledgements

   The authors would like to thank Sarah Chen, Tony Przygienda, Dave
   Cooper, Gyan Mishra, and Les Ginsberg for their contributions to this
   work.  The authors would also like to thank Arista Networks for
   supporting the development of this technology.

   The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam
   Sweeney, Acee Lindem, and Olufemi Komolafe for their helpful
   comments.

   The authors would like to thank Tom Edsall for initially introducing
   them to the problem.

   Advertising Local Edges Enabled for Flooding (LEEF) is based on an
   idea proposed by Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng
   Liu, Yanhe Fan, and Lei Liu.  The authors wish to thank them for
   their contributions.

Authors' Addresses

   Tony Li (editor)
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, California 94089
   United States of America
   Email: tony.li@tony.li

   Peter Psenak (editor)
   Cisco Systems, Inc.
   Eurovea Centre, Central 3
   Pribinova Street 10
   81109 Bratislava
   Slovakia
   Email: ppsenak@cisco.com

   Huaimo Chen
   Futurewei
   Boston, MA, Massachusetts
   United States of America
   Email: hchen.ietf@gmail.com

   Luay Jalil
   Verizon
   Richardson, Texas 75081
   United States of America
   Email: luay.jalil@verizon.com

   Srinath Dontula
   ATT
   AT&T
   200 S Laurel Ave
   Middletown, New Jersey 07748
   United States of America
   Email: sd947e@att.com