Applicability of the Babel routing protocol
draft-ietf-babel-applicability-01

Abstract

This document describes some application areas where the Babel routing protocol (RFC 6126) has been found to be useful.

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 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 July 9, 2017.

Copyright Notice

Copyright (c) 2017 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.

Table of Contents

• 1. Introduction
• 2. Existing successful deployments of Babel
• 2.1. Hybrid networks
• 2.2. Large scale overlay networks
• 2.3. Pure mesh networks
• 2.4. Small unmanaged networks
• 3. Application Areas where Babel is not recommended
• 3.1. Large, stable networks
• 3.2. Low-power and constrained networks
• 4. IANA Considerations
• 5. Security Considerations
• 6. Informational References
• Author's Address

1. Introduction

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, and in Section 3, we describe application areas where deployment of Babel is not encouraged because better alternatives are available.

2. Existing successful deployments of Babel

2.1. Hybrid networks

Babel is able to deal with both classical, prefix-based ("Internet-style") routing and flat ("mesh-style") routing 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.

2.2. Large scale overlay networks

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

2.3. Pure mesh networks

Babel has been repeatedly shown to be competitive with dedicated routing protocols for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. While this particular niche is already served by a number of mature protocols, notably OLSR-ETX and OLSRv2 [RFC7181] equipped with the DAT metric [RFC7779], Babel has seen a moderate amount of successful deployment in pure mesh networks.

2.4. Small unmanaged networks

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], with the significant advantage of having good support for wireless links.

3. Application Areas where Babel is not recommended

There exist application areas where Babel is a poor fit.

3.1. Large, stable networks

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 [RFC7868] or IS-IS [RFC1195].

3.2. Low-power and constrained networks

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

4. IANA Considerations

This document requires no IANA actions. [RFC Editor: please remove this section before publication.]

5. Security Considerations

As in all distance-vector routing protocols, a Babel speaker receives reachability information from its neighbours, which by default is trusted. A number of attacks are possible if this information is not suitably protected, either by a lower-layer mechanism or by an extension to the protocol itself (e.g. [RFC7298]).

Implementors and deployers must be aware of the insecure nature of the base protocol, and must take suitable measures to ensure that the protocol is deployed as securely as required by the application.

6. Informational References

Author's Address