< draft-ietf-babel-applicability-07.txt   draft-ietf-babel-applicability-08.txt >
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Intended status: Informational July 7, 2019 Intended status: Informational August 5, 2019
Expires: January 8, 2020 Expires: February 6, 2020
Applicability of the Babel routing protocol Applicability of the Babel routing protocol
draft-ietf-babel-applicability-07 draft-ietf-babel-applicability-08
Abstract Abstract
Babel is a routing protocol based on the distance-vector algorithm Babel is a routing protocol based on the distance-vector algorithm
augmented with mechanisms for loop avoidance and starvation augmented with mechanisms for loop avoidance and starvation
avoidance. In this document, we describe a number of niches where avoidance. This document describes a number of niches where Babel
Babel has been found to be useful and that are arguably not has been found to be useful and that are arguably not adequately
adequately served by more mature protocols. served by more mature protocols.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2020. This Internet-Draft will expire on February 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
1.1. Technical overview of the Babel protocol . . . . . . . . 2 1.1. Technical overview of the Babel protocol . . . . . . . . 2
2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3
2.1. Simplicity and implementability . . . . . . . . . . . . . 3 2.1. Simplicity and implementability . . . . . . . . . . . . . 3
2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6
3.1. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6 3.1. Heterogeneous networks . . . . . . . . . . . . . . . . . 6
3.2. Large scale overlay networks . . . . . . . . . . . . . . 7 3.2. Large scale overlay networks . . . . . . . . . . . . . . 7
3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7
3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informational References . . . . . . . . . . . . . . . . 8 7.2. Informational References . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and background
Babel [RFC6126bis] is a routing protocol based on the familiar Babel [RFC6126bis] is a routing protocol based on the familiar
distance-vector algorithm (sometimes known as distributed Bellman- distance-vector algorithm (sometimes known as distributed Bellman-
Ford) augmented with mechanisms for loop avoidance (there is no Ford) augmented with mechanisms for loop avoidance (there is no
"counting to infinity") and starvation avoidance. In this document, "counting to infinity") and starvation avoidance. This document
we describe a number of niches where Babel is useful and that are describes a number of niches where Babel is useful and that are
arguably not adequately served by more mature protocols such as OSPF arguably not adequately served by more mature protocols such as OSPF
[RFC5340] and IS-IS [RFC1195]. [RFC5340] and IS-IS [RFC1195].
1.1. Technical overview of the Babel protocol 1.1. Technical overview of the Babel protocol
At its core, Babel is a distance-vector protocol based on the At its core, Babel is a distance-vector protocol based on the
distributed Bellman-Ford algorithm, similar in principle to RIP distributed Bellman-Ford algorithm, similar in principle to RIP
[RFC2453], but with two important extensions: provisions for sensing [RFC2453], but with two important extensions: provisions for sensing
of neighbour reachability, bidirectional reachability and link of neighbour reachability, bidirectional reachability and link
quality, and support for multiple address families (e.g., IPv6 and quality, and support for multiple address families (e.g., IPv6 and
skipping to change at page 3, line 26 skipping to change at page 3, line 26
starvation episode. In Babel, starvation recovery is accelerated by starvation episode. In Babel, starvation recovery is accelerated by
using explicit requests (known as "seqno requests" in the protocol) using explicit requests (known as "seqno requests" in the protocol)
that signal a starvation episode and cause a new sequenced route to that signal a starvation episode and cause a new sequenced route to
be propagated in a timely manner. In the absence of packet loss, be propagated in a timely manner. In the absence of packet loss,
this mechanism is provably complete and clears the starvation in time this mechanism is provably complete and clears the starvation in time
proportional to the diameter of the network, at the cost of some proportional to the diameter of the network, at the cost of some
additional signalling traffic. additional signalling traffic.
2. Properties of the Babel protocol 2. Properties of the Babel protocol
In this section, we describe the properties of the Babel protocol as This section describes the properties of the Babel protocol as well
well as its known limitations. as its known limitations.
2.1. Simplicity and implementability 2.1. Simplicity and implementability
Babel is a conceptually simple protocol. It consists of a familiar Babel is a conceptually simple protocol. It consists of a familiar
algorithm (distributed Bellman-Ford) augmented with three simple and algorithm (distributed Bellman-Ford) augmented with three simple and
well-defined mechanisms (feasibility, sequenced routes and explicit well-defined mechanisms (feasibility, sequenced routes and explicit
requests). Given a sufficiently friendly audience, the principles requests). Given a sufficiently friendly audience, the principles
behind Babel can be explained in 15 minutes, and a full description behind Babel can be explained in 15 minutes, and a full description
of the protocol can be done in 52 minutes (one microcentury). of the protocol can be done in 52 minutes (one microcentury).
skipping to change at page 4, line 28 skipping to change at page 4, line 28
not assume ordered delivery, it does not assume that communication is not assume ordered delivery, it does not assume that communication is
transitive, and it does not require that the metric be discrete transitive, and it does not require that the metric be discrete
(continuous metrics are possible, reflecting for example packet loss (continuous metrics are possible, reflecting for example packet loss
rates). This is in contrast to link-state routing protocols such as rates). This is in contrast to link-state routing protocols such as
OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable
flooding algorithm and make stronger requirements on the underlying flooding algorithm and make stronger requirements on the underlying
network and metric. network and metric.
These weak requirements make Babel a robust protocol: These weak requirements make Babel a robust protocol:
o robust with respect to bugs: an implementation bug does most
likely not violate the properties on which Babel relies; in our
(extensive) experience, bugs tend to slow down convergence or
cause sub-optimal routing, but do not cause the network to
collapse;
o robust with respect to unusual networks: an unusual network (non- o robust with respect to unusual networks: an unusual network (non-
transitive links, unstable metrics, etc.) does most likely not transitive links, unstable metrics, etc.) does most likely not
violate the assumptions of the protocol; violate the assumptions of the protocol;
o robust with respect to novel metrics: no matter how strange your o robust with respect to novel metrics: no matter how strange your
metric (continuous, constantly fluctuating, etc.), it does most metric (continuous, constantly fluctuating, etc.), it does most
likely not violate the assumptions of the protocol. likely not violate the assumptions of the protocol.
In addition to the above, our implementation experience indicates
that Babel tends to be robust with respect to bugs: more often than
not, an implementation bug does not violate the properties on which
Babel relies, and therefore slows down convergence or causes sub-
optimal routing rather than causing the network to collapse.
These robustness properties have important consequences for the These robustness properties have important consequences for the
applicability of the protocol: Babel works (more or less efficiently) applicability of the protocol: Babel works (more or less efficiently)
in a wide range of circumstances where traditional routing protocols in a wide range of circumstances where traditional routing protocols
give up. give up.
2.3. Extensibility 2.3. Extensibility
Babel's packet format has a number of features that make the protocol Babel's packet format has a number of features that make the protocol
extensible (see Appendix C of [RFC6126bis]), and a number of extensible (see Appendix C of [RFC6126bis]), and a number of
extensions have been designed to make Babel work better in situations extensions have been designed to make Babel work better in situations
skipping to change at page 6, line 35 skipping to change at page 6, line 35
after a retraction until all neighbours have been guaranteed to have after a retraction until all neighbours have been guaranteed to have
acted upon the retraction, even in the presence of packet loss. acted upon the retraction, even in the presence of packet loss.
Unless the optional algorithm described in Section 3.5.5 of Unless the optional algorithm described in Section 3.5.5 of
[RFC6126bis] is implemented, this entails that a node is unreachable [RFC6126bis] is implemented, this entails that a node is unreachable
for a few minutes after the most specific route to it has been for a few minutes after the most specific route to it has been
retracted. This delay may make Babel slow to recover from a topology retracted. This delay may make Babel slow to recover from a topology
change in networks that perform automatic route aggregation. change in networks that perform automatic route aggregation.
3. Successful deployments of Babel 3. Successful deployments of Babel
In this section, we give a few examples of environments where Babel This section gives a few examples of environments where Babel has
has been successfully deployed. been successfully deployed.
3.1. Hybrid networks 3.1. Heterogeneous networks
Babel is able to deal with both classical, prefix-based ("Internet- Babel is able to deal with both classical, prefix-based ("Internet-
style") routing and flat ("mesh-style") routing over non-transitive style") routing and flat ("mesh-style") routing over non-transitive
link technologies. Because of that, it has seen a number of link technologies. Just like traditional distance-vector protocols,
successful deployments in medium-sized hybrid networks, networks that Babel is able to carry prefixes of arbitrary length, to supress
redundant announcements by applying the split-horizon optimisation
where applicable, and can be configured to filter out redundant
announcements (manual aggregation). Just like specialised mesh
protocols, Babel doesn't by default assume that links are transitive
or symmetric, can dynamically compute metrics based on an estimation
of link quality, and carries large numbers of host routes efficiently
by omitting common prefixes.
Because of these properties, Babel has seen a number of successful
deployments in medium-sized heterogeneous networks, networks that
combine a wired, aggregated backbone with meshy wireless bits at the combine a wired, aggregated backbone with meshy wireless bits at the
edges. No other routing protocol known to us is similarly robust and edges. No other routing protocol known to us is similarly robust and
efficient in this particular kind of topology. efficient in this particular kind of topology.
Efficient operation in hybrid networks requires the implementation to Efficient operation in heterogeneous networks requires the
distinguish wired and wireless links, and to perform link quality implementation to distinguish between wired and wireless links, and
estimation on wireless links. to perform link quality estimation on wireless links.
3.2. Large scale overlay networks 3.2. Large scale overlay networks
The algorithms used by Babel (loop avoidance, hysteresis, delayed The algorithms used by Babel (loop avoidance, hysteresis, delayed
updates) allow it to remain stable and efficient in the presence of updates) allow it to remain stable and efficient in the presence of
unstable metrics, even in the presence of a feedback loop. For this unstable metrics, even in the presence of a feedback loop. For this
reason, it has been successfully deployed in large scale overlay reason, it has been successfully deployed in large scale overlay
networks, built out of thousands of tunnels spanning continents, networks, built out of thousands of tunnels spanning continents,
where it is used with a metric computed from links' latencies. where it is used with a metric computed from links' latencies.
skipping to change at page 8, line 9 skipping to change at page 8, line 20
In most deployments, the Babel protocol is run over a network that is In most deployments, the Babel protocol is run over a network that is
secured either at the physical layer (e.g., physically protecting secured either at the physical layer (e.g., physically protecting
Ethernet sockets) or at the link layer (using a protocol such as WiFi Ethernet sockets) or at the link layer (using a protocol such as WiFi
Protected Access (WPA2)). If Babel is being run over an unprotected Protected Access (WPA2)). If Babel is being run over an unprotected
network, then the routing traffic needs to be protected using a network, then the routing traffic needs to be protected using a
sufficiently strong cryptographic mechanism. sufficiently strong cryptographic mechanism.
At the time of writing, two such mechanisms have been defined. At the time of writing, two such mechanisms have been defined.
Babel-HMAC [HMAC] is a simple and easy to implement mechanism that Babel-HMAC [HMAC] is a simple and easy to implement mechanism that
only guarantees authenticity and integrity of the routing traffic, only guarantees authenticity, integrity and replay protection of the
and only supports symmetric keying with a small number of keys routing traffic, and only supports symmetric keying with a small
(typically just one or two), but is invulnerable to replay even in number of keys (typically just one or two). Babel-DTLS [DTLS] is a
the absence of persistent state. Babel-DTLS [DTLS] is a more complex more complex mechanism, that requires some minor changes to be made
mechanism, that requires some minor changes to be made to a typical to a typical Babel implementation and depends on a DTLS stack being
Babel implementation and depends on a DTLS stack being available, but available, but inherits all of the features of DTLS, notably
inherits all of the features of DTLS, notably confidentiality and the confidentiality, optional replay protection, and the ability to use
ability to use asymmetric keys. asymmetric keys.
Due to its simplicity, Babel-HMAC should be the preferred security Due to its simplicity, Babel-HMAC should be the preferred security
mechanism in most deployments, with Babel-DTLS available for networks mechanism in most deployments, with Babel-DTLS available for networks
that require its additional features. that require its additional features.
6. Acknowledgments 6. Acknowledgments
The author is indebted to Jean-Paul Smetz and Alexander Vainshtein The author is indebted to Jean-Paul Smetz and Alexander Vainshtein
for their input to this document. for their input to this document.
 End of changes. 16 change blocks. 
36 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/