| Internet-Draft | Babel Protocol Applicability | February 2016 |
| Chroboczek | Expires 1 September 2016 | [Page] |
This document describes some application areas where the Babel routing protocol [RFC6126] has been found to be useful.¶
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 http://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 1 September 2016.¶
Copyright (c) 2016 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 (http://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.¶
Babel [RFC6126] is a loop-avoiding distance-vector routing protocol that aims to be robust in a variety of environments.¶
This document describes a few areas where Babel has been found to be useful. It is structured as follows. In Section 2, we describe application areas where Babel has been successfully deployed. In Section 3, we describe application areas where Babel works well, but has not been widely deployed yet. In Section 4, we describe application areas where deployment of Babel is not encouraged because better alternatives are available.¶
Babel is able to deal with both classical, prefix-based ("Internet-style") routing and flat ("mesh-style") over non-transitive link technologies. Because of that, it has seen a number of succesful deployments in medium-sized hybrid networks, networks that combine a wired, aggregated backbone with meshy wireless bits at the edges. No other routing protocol known to us is similarly robust and efficient in this particular type of network.¶
The algorithms used by Babel (loop avoidance, hysteresis, delayed updates) allow it to remain stable and efficient in the presence of unstable metrics, even in the presence of a feedback loop. For this reason, it has been successfully deployed in large scale overlay networks, built out of thousands of tunnels spanning continents, where it is used with a metric computed from links' latencies [DELAY-BASED].¶
Because of its small size and simple configuration, Babel has been deployed in small, unmanaged networks (three to five routers), where it serves as a more efficient replacement for RIP [RFC2453], albeit with good support for wireless links.¶
There are application areas for which Babel is a good fit, but where it has not seen major deployments yet.¶
Babel has been repeatedly shown to be competitive with dedicated routing protocols for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. However, this particular niche is already served by a number of mature protocols, notably OLSR-ETX as well as OLSRv2 [RFC7181] equipped with the DAT metric [DAT], so Babel has not seen major deployments in pure meshes yet.¶
There are a number of application areas where Babel is a poor fit.¶
Babel relies on periodic updates, and even in a stable network, it generates a constant amount of background traffic. In large, stable, well-administered networks, it is preferable to use protocols layered above a reliable transport mechanism, such as OSPF [RFC5340], EIGRP [EIGRP] or IS-IS [RFC1195].¶
Babel relies on periodic updates and maintains within each node an amount of state that is proportional to the number of reachable destinations. In networks containing resource-constrained or exteremely low-power nodes, it may be preferable to use a protocol that limits the amount of state maintained and propagated; we have heard of AODVv2 [AODVv2], RPL [RFC6550] and LOADng [LOADng].¶