Applicability of the Babel Routing Protocol
RFC 8965

Document Type RFC - Informational (January 2021; No errata)
Author Juliusz Chroboczek 
Last updated 2021-01-11
Replaces draft-chroboczek-babel-applicability
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Donald Eastlake
Shepherd write-up Show (last changed 2018-12-25)
IESG IESG state RFC 8965 (Informational)
Action Holders
(None)
Consensus Boilerplate Yes
Telechat date
Responsible AD Martin Vigoureux
Send notices to "Donald Eastlake" <d3e3e3@gmail.com>
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions


Internet Engineering Task Force (IETF)                     J. Chroboczek
Request for Comments: 8965             IRIF, University of Paris-Diderot
Category: Informational                                     January 2021
ISSN: 2070-1721

              Applicability of the Babel Routing Protocol

Abstract

   Babel is a routing protocol based on the distance-vector algorithm
   augmented with mechanisms for loop avoidance and starvation
   avoidance.  This document describes a number of niches where Babel
   has been found to be useful and that are arguably not adequately
   served by more mature protocols.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of 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 obtained at
   https://www.rfc-editor.org/info/rfc8965.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Background
     1.1.  Technical Overview of the Babel Protocol
   2.  Properties of the Babel Protocol
     2.1.  Simplicity and Implementability
     2.2.  Robustness
     2.3.  Extensibility
     2.4.  Limitations
   3.  Successful Deployments of Babel
     3.1.  Heterogeneous Networks
     3.2.  Large-Scale Overlay Networks
     3.3.  Pure Mesh Networks
     3.4.  Small Unmanaged Networks
   4.  Security Considerations
   5.  References
     5.1.  Normative References
     5.2.  Informative References
   Acknowledgments
   Author's Address

1.  Introduction and Background

   Babel [RFC8966] is a routing protocol based on the familiar distance-
   vector algorithm (sometimes known as distributed Bellman-Ford)
   augmented with mechanisms for loop avoidance (there is no "counting
   to infinity") and starvation avoidance.  This document describes a
   number of niches where Babel is useful and that are arguably not
   adequately served by more mature protocols such as OSPF [RFC5340] and
   IS-IS [RFC1195].

1.1.  Technical Overview of the Babel Protocol

   At its core, Babel is a distance-vector protocol based on the
   distributed Bellman-Ford algorithm, similar in principle to RIP
   [RFC2453] but with two important extensions: provisions for sensing
   of neighbour reachability, bidirectional reachability, and link
   quality, and support for multiple address families (e.g., IPv6 and
   IPv4) in a single protocol instance.

   Algorithms of this class are simple to understand and simple to
   implement, but unfortunately they do not work very well -- they
   suffer from "counting to infinity", a case of pathologically slow
   convergence in some topologies after a link failure.  Babel uses a
   mechanism pioneered by the Enhanced Interior Gateway Routing Protocol
   (EIGRP) [DUAL] [RFC7868], known as "feasibility", which avoids
   routing loops and therefore makes counting to infinity impossible.

   Feasibility is a conservative mechanism, one that not only avoids all
   looping routes but also rejects some loop-free routes.  Thus, it can
   lead to a situation known as "starvation", where a router rejects all
   routes to a given destination, even those that are loop-free.  In
   order to recover from starvation, Babel uses a mechanism pioneered by
   the Destination-Sequenced Distance-Vector Routing Protocol (DSDV)
   [DSDV] and known as "sequenced routes".  In Babel, this mechanism is
   generalised to deal with prefixes of arbitrary length and routes
   announced at multiple points in a single routing domain (DSDV was a
   pure mesh protocol, and only carried host routes).

   In DSDV, the sequenced routes algorithm is slow to react to a
   starvation episode.  In Babel, starvation recovery is accelerated by
   using explicit requests (known as "seqno requests" in the protocol)
   that signal a starvation episode and cause a new sequenced route to
   be propagated in a timely manner.  In the absence of packet loss,
Show full document text