Dynamic Flooding on Dense Graphs
draft-li-dynamic-flooding-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Tony Li | ||
| Last updated | 2018-03-27 | ||
| Replaced by | draft-li-lsr-dynamic-flooding | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-dynamic-flooding-04
Internet Engineering Task Force T. Li
Internet-Draft Arista Networks
Intended status: Informational March 26, 2018
Expires: September 27, 2018
Dynamic Flooding on Dense Graphs
draft-li-dynamic-flooding-04
Abstract
Routing with link state protocols in dense network topologies can
result in sub-optimal 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 is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Li Expires September 27, 2018 [Page 1]
Internet-Draft Dynamic Flooding March 2018
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 4
4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 6
4.3. Computing the Flooding Topology . . . . . . . . . . . . . 7
4.4. Topologies on Complete Bipartite Graphs . . . . . . . . . 8
4.4.1. A Minimal Flooding Topology . . . . . . . . . . . . . 8
4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 8
4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 9
4.5. Encoding the Flooding Topology . . . . . . . . . . . . . 9
4.6. Analysis of Topology Changes . . . . . . . . . . . . . . 9
4.6.1. Link Addition . . . . . . . . . . . . . . . . . . . . 10
4.6.2. Node Addition . . . . . . . . . . . . . . . . . . . . 10
4.6.3. Link Failures Off the Flooding Topology . . . . . . . 10
4.6.4. Failure of the Area Leader . . . . . . . . . . . . . 10
4.6.5. Failures on the Flooding Topology . . . . . . . . . . 10
4.6.6. Recovery from Multiple Failures . . . . . . . . . . . 11
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11
5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Area Leader TLV . . . . . . . . . . . . . . . . . . . 12
5.1.2. Area System IDs TLV . . . . . . . . . . . . . . . . . 12
5.1.3. Flooding Path TLV . . . . . . . . . . . . . . . . . . 13
5.2. OSPFv2 LSAs . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. OSPFv3 LSAs . . . . . . . . . . . . . . . . . . . . . . . 14
6. Behavioral Specification . . . . . . . . . . . . . . . . . . 14
6.1. Leader Election . . . . . . . . . . . . . . . . . . . . . 14
6.2. Area Leader Responsibilities . . . . . . . . . . . . . . 15
6.3. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Li Expires September 27, 2018 [Page 2]
Internet-Draft Dynamic Flooding March 2018
1. Introduction
In recent years, there has been increased focused on how to address
the dynamic routing of networks that have a bipartite (a.k.a. spine-
leaf or leaf-spine), Clos [Clos], or Fat Tree [Leiserson] topology.
Conventional Interior Gateway Protocols (IGPs, i.e. IS-IS [ISO10589],
OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform, redundantly
flooding information throughout the dense topology, leading to
overloaded control plane inputs and thereby creating operational
issues. For practical considerations, network architects have
resorted to applying unconventional techniques to address the
problem, applying BGP in the data center [RFC7938], however it is
very clear that using an Exterior Gateway Protocol as an IGP is sub-
optimal, if only due to the configuration overhead.
The primary issue that is demonstrated when conventional mechanisms
are applied is the poor reaction of the network to topology changes.
Normal link state routing protocols rely on a flooding algorithm for
state distribution. In a dense topology, this flooding algorithm is
highly redundant, resulting 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 been processed. This
creates issues because significant link state database updates can
become queued behind many redundant copies of another update. This
delays convergence as the link state database does not stabilize
promptly.
In a real world implementation, the packet queues leading to the
control plane are necessarily of finite size, so if the flooding rate
exceeds the update processing rate for long enough, the control plane
will be obligated to drop incoming updates. If these lost updates
are of significance, this will further delay stabilization of the
link state database 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.
This problem is not entirely surprising. Link state routing
protocols were conceived when links were very expensive and
Li Expires September 27, 2018 [Page 3]
Internet-Draft Dynamic Flooding March 2018
topologies were sparse. The fact that those same designs are sub-
optimal in a dense topology should not come as a huge surprise. The
fundamental premise that was addressed by the original designs was an
environment of extreme cost and scarcity. 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, 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Problem Statement
In a dense topology, the flooding algorithm that is the heart of
conventional 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 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. 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 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. Changes to nodes
Li Expires September 27, 2018 [Page 4]
Internet-Draft Dynamic Flooding March 2018
outside of the dense subgraph are 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.
4. Dynamic Flooding
We have observed that the combination of the dense topology and
flooding on the physical topology in a scalable network is sub-
optimal. However, if we decouple the flooding topology from the
physical topology and only flood on a greatly reduced portion of that
topology, we can have efficient flooding and retain all of the
resilience of existing protocols.
In this idea, one node is elected to compute the flooding topology
for the dense subgraph. This flooding topology is encoded into and
distributed as part of the normal link state database. Nodes within
the dense topology would only flood on the flooding topology. On
links outside of the normal flooding topology, normal database
synchronization mechanisms (i.e., OSPF database exchange, IS-IS
CSNPs) would apply, but flooding would not. New link state
information that arrives from outside of the flooding topology
suggests that the sender has a different or no flooding topology
information and that the link state update should be flooded on the
flooding topology as well.
Since the flooding topology is computed prior to topology changes, it
does not factor into the convergence time and can be done when the
topology is stable. The speed of the computation and its
distribution is not a significant issue.
If a node has not received any flooding topology information when it
receives new link state information, it should flood according to
legacy flooding rules. This situation will occur when the dense
topology is first established, but is unlikely to recur.
If, during a transient, there are multiple flooding topologies being
advertised, then nodes should flood link state updates on all of the
flooding topologies. Each node should locally evaluate the election
of the lead node for the dense subgraph and first flood on the
topology of the lead node. The rationale behind this is
straightforward: if there is a transient and there has been a recent
change in the elected node, then propagating topology information
promptly along the most likely flooding topology should be the
priority.
Li Expires September 27, 2018 [Page 5]
Internet-Draft Dynamic Flooding March 2018
During transients, it is possible that loops will form in the
flooding topology. This is not problematic, as the legacy flooding
rules would cause duplicate updates to be ignored. Similarly, during
transients, it is possible that the forwarding topology may become
disconnected. To address this, nodes can perform a database
synchronization check anytime a link is added to or removed from the
flooding topology.
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 degree node in the flooding
topology, convergence time goals can be met and the stability of the
control plan can be assured.
Similarly, in a massively scaled data center, where there are many
opportunities for redundant flooding, this mechanism ensures that
flooding is redundant, with each leaf and spine well connected, while
ensuring that no update need make 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, the remaining nodes will continue to perform universal
flooding. This is not an issue for correctness, as no node can
become isolated. The flooding topology will effectively include
everything computed by the Area Leader plus additional flooding
triggered by the legacy nodes. Whether or not the network can remain
stable in this condition is unknown and may be very dependent on the
number and location of the nodes that support Dynamic Flooding.
4.2. Leader election
The election of the node within the dense topology that computes the
flooding topology is straightforward. A generalization of the
mechanisms used in existing Designated Router (OSPF) or Designated
Intermediate-System (IS-IS) elections suffices. The elected node is
known as the area leader. When a new node is elected and has
distributed new flooding topology information, then the old node
should withdraw its flooding topology information from the link state
database. If the old node does not return to the topology in a
timely manner, the new node may remove the old node's information
from the link state database.
Li Expires September 27, 2018 [Page 6]
Internet-Draft Dynamic Flooding March 2018
4.3. Computing the Flooding Topology
There is a great deal of flexibility in how the flooding topology is
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 need not be standardized, as it is not an interoperability
issue. Only the encoding of the result needs to be documented.
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. Consider
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 number 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 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 update propagation. 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 optimal to
have an upper bound on the degree of nodes in the flooding topology.
Again, the optimal trade-off between graph diameter, node degree, and
convergence time, and topology computation time is for further study.
If the leader chooses to include a multi-node broadcast LAN segment
as part of the flooding topology, all of the connectivity to that LAN
segment should be included as well. Once updates are flooded onto
the LAN, they will be received by every attached node.
Li Expires September 27, 2018 [Page 7]
Internet-Draft Dynamic Flooding March 2018
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. In this section, we discuss some flooding topologies
that are of particular interest in these networks.
4.4.1. A Minimal Flooding Topology
We define a Minimal Flooding Topology on a complete bipartite graph
as 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 points 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, we can 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.2. Xia Topologies
We define a Xia Topology on a complete bipartite graph as one in
which all spine nodes are bi-connected through leaves with degree
two, but the remaining leaves all have degree one and are evenly
distributed across the spines.
Constructively, we 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
we can therefore choose any leaf without loss of generality.
Continuing this iteration across all of the spines, selecting a new
leaf at each 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, connected by a single
link.
Xia topologies represent a compromise that trades off increased risk
and decreased performance for lower flooding amplification. Xia
Li Expires September 27, 2018 [Page 8]
Internet-Draft Dynamic Flooding March 2018
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.
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 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 n leaves and m spines, a spine never
transmits more than m/n updates.
4.4.3. Optimization
If two systems have multiple links between them, only one of the
links should be part of the flooding topology. Moreover, symmetric
selection of the link to use for flooding is not required.
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 as it would require a slightly different
encoding scheme as soon as a single additional link is added.
Instead, we choose to encode the flooding topology as a set of
intersecting paths, where each path is a set of connected edges.
Other encodings are certainly possible. We have attempted to make a
useful trade off between simplicity, generality, and space.
4.6. Analysis of Topology Changes
In this section, we explicitly consider a variety of different
topological failures in the network and how dynamic flooding should
address them.
Li Expires September 27, 2018 [Page 9]
Internet-Draft Dynamic Flooding March 2018
4.6.1. Link Addition
If a link is added to the topology, the protocol will form a normal
adjacency on the link and update the appropriate link state
advertisements for the routers on either end of the link. These link
state updates will be flooded on the flooding topology. The Area
Leader, upon receiving these updates, may choose to retain the
existing flooding topology or may choose to modify the flooding
topology. If it elects to change the flooding topology, it will
update the flooding topology in the link state database and flood it
using the new flooding topology.
4.6.2. Node Addition
If a node is added to the topology, then at least one link is also
added to the topology. The paragraph above applies and the Area
Leader will necessarily need to add the new node to the flooding
topology.
4.6.3. Link Failures Off the Flooding Topology
If a link that is not part of the flooding topology fails, then the
adjoining routers will update their link state advertisements and
flood them on the flooding topology. There is no need for changes to
the flooding topology.
4.6.4. Failure of the Area Leader
There are two cases of interest. If the Area Leader leaves the
topology momentarily and returns promptly, such as might happen using
Graceful Restart (i.e., [RFC5306], [RFC3623]), then recomputing the
flooding topology is not required.
If, in a reasonable amount of time, the Area Leader does not return
to the topology, then the area should elect a new Area Leader. The
new Area Leader will compute a new flooding topology and flood the
new topology using the new topology. The new Area Leader should
flush the old flooding topology from the area's link state database.
As an optimization, the new Area Leader should compute a new flooding
topology that has as much in common as possible with the old flooding
topology. This will minimize the risk of over-flooding.
4.6.5. Failures on the Flooding Topology
If there is a failure on the flooding topology, the adjoining routers
will update their link state advertisements and flood them. If the
Li Expires September 27, 2018 [Page 10]
Internet-Draft Dynamic Flooding March 2018
original flooding topology is bi-connected, the flooding topology
should still be connected despite a single failure.
The Area Leader will notice the change in the flooding topology,
recompute the flooding topology, and flood it using the new flooding
topology.
4.6.6. Recovery from Multiple Failures
In the unlikely event of multiple failures on the flooding topology,
it may become disconnected. The nodes that remain active on the
edges of the flooding topology will recognize this, update their own
link state advertisements and flood them on the remainder of the
flooding topology. At this point, nodes will be able to compute that
the flooding topology is partitioned.
Note that this is very different from partitioning the area itself.
The area may remain connected and forwarding may still be effective.
When this condition is detected, the flooding topology can no longer
be expected to deliver link state updates in a prompt manner. Nodes
should perform database synchronization on all links not on the
flooding topology. Updates received from off of the flooding
topology should be flooded on the remaining flooding topology. Any
links that provide updates or require updates that are not part of
the flooding topology should temporarily be added to the flooding
topology. This should repair the current flooding topology, albeit
in a sub-optimal manner.
The Area Leader will also detect this condition, compute a new
flooding topology, and flood it using the new flooding topology.
5. Protocol Elements
5.1. IS-IS TLVs
The following TLVs are added to IS-IS:
1. A TLV that an IS may inject into its LSP to indicate its
preference for becoming Area Leader.
2. A TLV to carry the list of system IDs that compromise the
flooding topology for the area.
3. A TLV to carry the adjacency matrix for the flooding topology for
the area.
Li Expires September 27, 2018 [Page 11]
Internet-Draft Dynamic Flooding March 2018
5.1.1. Area Leader TLV
The Area Leader TLV allows a system to indicate its eligibility and
priority for becoming Area Leader. Intermediate Systems (routers)
not advertising this TLV are not eligible to become Area Leader.
The Area Leader is the router with the numerically highest Area
Leader priority in the area. In the event of ties, the router with
the numerically highest system ID is the Area Leader. Due to
transients during database flooding, different routers may not agree
on the Area Leader.
The format of the Area Leader TLV is:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type: XXX
TLV Length: 1
Priority: 0-255, unsigned integer
5.1.2. Area System IDs TLV
The Area System IDs TLV is used by the Area Leader to enumerate the
system IDs that it has used in computing the flooding topology.
Conceptually, the Area Leader creates a list of system IDs for all
routers in the area, assigning indices to each system, starting with
index 0.
Because the space in a single TLV is small, it may require more than
one TLV to encode all of the system IDs in the area. This TLV may
recur in multiple LSP segments so that all system IDs can be
advertised.
The format of the Area System IDs TLV is:
Li Expires September 27, 2018 [Page 12]
Internet-Draft Dynamic Flooding March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | Starting Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Index |L| Reserved | System IDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System IDs continued ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type: YYY
TLV Length: 9 + (ID length * N)
Starting index: The index of the first system ID that appears in
this TLV.
Ending index: The index of the last system ID that appears in this
TLV.
L (Last): This bit is set if the ending index of this TLV is the
last index in the full list of system IDs for the area.
System IDs: A concatenated list of system IDs for the area.
5.1.3. Flooding Path TLV
The 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: (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 Flooding Path TLV contains a list of system indices relative to
the systems advertised through the Area System 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.
The Flooding Path TLV has the format:
Li Expires September 27, 2018 [Page 13]
Internet-Draft Dynamic Flooding March 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | Starting Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index 2 | Additional indices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type: ZZZ
TLV Length: 9 + Length of Matrix octet contents
Starting 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.2. OSPFv2 LSAs
To be written.
5.3. OSPFv3 LSAs
To be written.
6. Behavioral Specification
In this section, we specify the detailed behaviors of the nodes
participating in the IGP.
6.1. Leader Election
Any node that is capable MAY advertise its eligibility to become Area
Leader.
Nodes that are not reachable are not eligible as Area Leader. Nodes
that do not advertise their eligibility to become 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 is the Area Leader.
Li Expires September 27, 2018 [Page 14]
Internet-Draft Dynamic Flooding March 2018
6.2. Area Leader Responsibilities
The Area Leader MUST compute and advertise a flooding topology for
the area. The Area Leader MAY update the flooding topology at any
time, however, it should not destabilize the network with undue or
overly frequent topology changes.
The flooding topology MUST include all reachable nodes in the area.
If nodes become unreachable on the flooding topology, the area leader
MUST compute and advertise a new flooding topology.
The flooding topology MAY be bi-connected. This is strongly
RECOMMENDED but not required.
If the area link state database contains a flooding topology
generated from a node that is not reachable and the current Area
Leader has advertised a flooding topology, then the Area Leader
SHOULD purge the old flooding topology from the area link state
database.
6.3. Flooding Behavior
Nodes that support Dynamic Flooding MUST use a flooding topology if
one is present in the area link state database. Link state updates
received on one link in the flooding topology MUST be flooded to all
other links in the flooding topology where that update has not been
received. Link state updates received on a link not in the flooding
topology MUST be flooding to all links in the flooding topology where
that update has not been received.
If multiple flooding topologies are present in the area link state
database, the node SHOULD flood on the union of the topologies.
When failures occur, nodes will learn about them from link state
updates and can compare those to flooding topology. If the flooding
topology becomes disconnected, then the node should perform a
database synchronization on all links. While the flooding topology
is disconnected, if a new link state update is received on link not
in the flooding topology, then the node SHOULD temporarily consider
the link as part of the flooding topology. When a new flooding
topology is received, this MUST be discontinued.
7. IANA Considerations
This memo requests that IANA allocate and assign three code points
from the IS-IS TLV Codepoints registry. One for each of the
following TLVs:
Li Expires September 27, 2018 [Page 15]
Internet-Draft Dynamic Flooding March 2018
1. Area Leader TLV
2. Area System IDs TLV
3. Flooding Path TLV
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.
9. Acknowledgements
The author would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam
Sweeney, and Olufemi Komolafe for their helpful comments.
The author would like to thank Tom Edsall for initially introducing
him to the problem.
10. References
10.1. Normative References
[ISO10589]
International Organization for Standardization,
"Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002.
[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>.
[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>.
Li Expires September 27, 2018 [Page 16]
Internet-Draft Dynamic Flooding March 2018
10.2. Informative References
[Clos] Clos, C., "A Study of Non-Blocking Switching Networks",
The Bell System Technical Journal Vol. 32(2), DOI
10.1002/j.1538-7305.1953.tb01433.x, March 1953,
<http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[Leiserson]
Leiserson, C., "Fat-Trees: Universal Networks for
Hardware-Efficient Supercomputing", IEEE Transactions on
Computers 34(10):892-901, 1985.
[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>.
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003,
<https://www.rfc-editor.org/info/rfc3623>.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
RFC 5306, DOI 10.17487/RFC5306, October 2008,
<https://www.rfc-editor.org/info/rfc5306>.
[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>.
Author's Address
Tony Li
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
USA
Email: tony.li@tony.li
Li Expires September 27, 2018 [Page 17]