draft-ietf-babel-applicability-03.txt   draft-ietf-babel-applicability-04.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 April 7, 2018 Intended status: Informational October 23, 2018
Expires: October 9, 2018 Expires: April 26, 2019
Applicability of the Babel routing protocol Applicability of the Babel routing protocol
draft-ietf-babel-applicability-03 draft-ietf-babel-applicability-04
Abstract Abstract
Where we argue that, although OSPF and IS-IS are fine protocols, Babel is a routing protocol based on the distance-vector algorithm
there exists a space where the Babel routing protocol (RFC 6126bis) augmented with mechanisms for loop avoidance and starvation
is useful. avoidance. In this document, we argue that there exist niches where
Babel is useful and that are not adequately 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 October 9, 2018. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 21 skipping to change at page 2, line 21
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. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6
3.2. Large scale overlay networks . . . . . . . . . . . . . . 6 3.2. Large scale overlay networks . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 7
6. Informational References . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informational References . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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. In this document,
we argue that there exist niches where Babel is useful and that are we argue that there exist niches where Babel is useful and that are
not adequately served by more mature protocols such as OSPF [RFC5340] not adequately served by more mature protocols such as OSPF [RFC5340]
and IS-IS [RFC1195]. 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 traditional distance-vector protocol based on At its core, Babel is a distance-vector protocol based on the
the distributed Bellman-Ford algorithm, similar in principle to RIP distributed Bellman-Ford algorithm, similar in principle to RIP
[RFC2453], but with two obvious extensions: provisions for sensing of [RFC2453], but with two important extensions: provisions for sensing
neighbour reachability, bidirectional reachability and link quality, of neighbour reachability, bidirectional reachability and link
and support for multiple address families (e.g., IPv6 and IPv4) in a quality, and support for multiple address families (e.g., IPv6 and
single protocol instance. IPv4) in a single protocol instance.
Algorithms of this class are simple to understand and simple to Algorithms of this class are simple to understand and simple to
implement, but unfortunately they do not work very well -- they implement, but unfortunately they do not work very well -- they
suffer from "counting to infinity", a case of pathologically slow suffer from "counting to infinity", a case of pathologically slow
convergence in some topologies after a link failure. Babel uses a convergence in some topologies after a link failure. Babel uses a
mechanism pioneered by EIGRP [DUAL] [RFC7868], known as mechanism pioneered by EIGRP [DUAL] [RFC7868], known as
"feasibility", which avoids routing loops and therefore makes "feasibility", which avoids routing loops and therefore makes
counting to infinity impossible. counting to infinity impossible.
Feasibility is a conservative mechanism, one that not only avoids all Feasibility is a conservative mechanism, one that not only avoids all
skipping to change at page 3, line 35 skipping to change at page 3, line 38
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).
An important consequence is that Babel is easy to implement. While An important consequence is that Babel is easy to implement. At the
Babel is a young protocol, there exist four independent time of writing, there exist four independent implementations,
implementations, including one that was reportedly written and including one that was reportedly written and debugged in just two
debugged in just two nights. nights.
2.2. Robustness 2.2. Robustness
The fairly strong properties of the Babel protocol (convergence, loop The fairly strong properties of the Babel protocol (convergence, loop
avoidance, starvation avoidance) rely on some rather weak properties avoidance, starvation avoidance) rely on some rather weak properties
of the network and the metric being used. The most significant are: of the network and the metric being used. The most significant are:
o causality: a control message is not received before it has been o causality: a control message is not received before it has been
sent (more precisely, the "happens-before" relation is acyclic); sent (more precisely, the "happens-before" relation is acyclic);
o strict monotonicity of the metric: M < C + M; o strict monotonicity of the metric: for any metric M and link cost
o left-distributivity of the metric: if M <= M', then C, < C + M;
C + M <= C + M'.
o left-distributivity of the metric: for any metrics M and M' and
cost C, if M <= M', then C + M <= C + M'.
In particular, Babel does not assume a reliable transport, it does In particular, Babel does not assume a reliable transport, it does
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 traditional link-state routing rates). This is in contrast to link-state routing protocols such as
protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which are OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable
layered over a reliable flooding algorithm and make stronger flooding algorithm and make stronger requirements on the underlying
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 o robust with respect to bugs: an implementation bug does most
probably not violate the properties on which Babel relies; in our likely not violate the properties on which Babel relies; in our
(extensive) experience, bugs tend to slow down convergence or (extensive) experience, bugs tend to slow down convergence or
cause sub-optimal routing, but do not cause the network to cause sub-optimal routing, but do not cause the network to
collapse; 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 probably 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
probably not violate the assumptions of the protocol. likely not violate the assumptions of the protocol.
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
that were not envisioned when the protocol was initially designed. that were not envisioned when the protocol was initially designed.
The ease of extensibility is not an accident, but a consequence of The ease of extensibility is not an accident, but a consequence of
the design of the protocol: it is reasonably easy to check whether a the design of the protocol: it is reasonably easy to check whether a
given extension violates the assumptions on which Babel relies. given extension violates the assumptions on which Babel relies.
Remarkably enough, all of the extensions designed to date All of the extensions designed to date interoperate with the base
interoperate with the base protocol and with each other. This, protocol and with each other. This, again, is a consequence of the
again, is a consequence of the protocol design: in order to check the protocol design: in order to check the interoperability of two
interoperability of two implementations of Babel, it is enough to implementations of Babel, it is enough to verify that the interaction
verify that the interaction of the two does not violate the of the two does not violate the protocol's assumptions.
protocol's assumptions.
Notable extensions deployed to date include: Notable extensions deployed to date include:
o source-specific routing (SADR) [BABEL-SS] allows forwarding to o source-specific routing (SADR) [BABEL-SS] allows forwarding to
take a packet's source address into account, thus enabling a cheap take a packet's source address into account, thus enabling a cheap
form of multihoming [SS-ROUTING]; form of multihoming [SS-ROUTING];
o RTT-based routing [BABEL-RTT] minimises link delay, which is o RTT-based routing [BABEL-RTT] minimises link delay, which is
useful in overlay network (where both hop count and packet loss useful in overlay network (where both hop count and packet loss
are poor metrics). are poor metrics).
skipping to change at page 5, line 44 skipping to change at page 5, line 45
The main mechanisms used by Babel to reconverge after a topology The main mechanisms used by Babel to reconverge after a topology
change are reactive: triggered updates, triggered retractions and change are reactive: triggered updates, triggered retractions and
explicit requests. However, in the presence of heavy packet loss, explicit requests. However, in the presence of heavy packet loss,
Babel relies on periodic updates to clear pathologies. This reliance Babel relies on periodic updates to clear pathologies. This reliance
on periodic updates makes Babel unsuitable in at least two kinds of on periodic updates makes Babel unsuitable in at least two kinds of
deployments: deployments:
o large, stable networks: since Babel sends periodic updates even in o large, stable networks: since Babel sends periodic updates even in
the absence of topology changes, in well-managed, large, stable the absence of topology changes, in well-managed, large, stable
networks the amount of control traffic will be reduced by using a networks the amount of control traffic will be reduced by using a
protocol that relies on a reliable transport (such as OSPF, IS-IS protocol that uses a reliable transport (such as OSPF, IS-IS or
or EIGRP); EIGRP);
o low-power networks: the periodic updates use up battery power even o low-power networks: the periodic updates use up battery power even
when there are no topology changes and no user traffic, which when there are no topology changes and no user traffic, which
makes Babel wasteful in low-power networks. makes Babel wasteful in low-power networks.
2.4.2. Full routing table 2.4.2. Full routing table
While there exist techniques that allow a Babel speaker to function While there exist techniques that allow a Babel speaker to function
with a partial routing table (e.g., by learning just a default route with a partial routing table (e.g., by learning just a default route
or, more generally, performing route aggregation), Babel is designed or, more generally, performing route aggregation), Babel is designed
skipping to change at page 7, line 47 skipping to change at page 7, line 47
As is the case in all distance-vector routing protocols, a Babel As is the case in all distance-vector routing protocols, a Babel
speaker receives reachability information from its neighbours, which speaker receives reachability information from its neighbours, which
by default is trusted. A number of attacks are possible if this by default is trusted. A number of attacks are possible if this
information is not suitably protected, either by a lower-layer information is not suitably protected, either by a lower-layer
mechanism or by an extension to the protocol itself (e.g. [RFC7298]). mechanism or by an extension to the protocol itself (e.g. [RFC7298]).
Implementors and deployers must be aware of the insecure nature of Implementors and deployers must be aware of the insecure nature of
the base protocol, and must take suitable measures to ensure that the the base protocol, and must take suitable measures to ensure that the
protocol is deployed as securely as required by the application. protocol is deployed as securely as required by the application.
6. Informational References 6. References
6.1. Normative References
[RFC6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04,
October 2017.
6.2. Informational References
[AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and [AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and
V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2
(AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in
progress), May 2016. progress), May 2016.
[BABEL-RTT] [BABEL-RTT]
Jonglez, B. and J. Chroboczek, "Delay-based Metric Jonglez, B. and J. Chroboczek, "Delay-based Metric
Extension for the Babel Routing Protocol", draft-jonglez- Extension for the Babel Routing Protocol", draft-jonglez-
babel-rtt-extension-01 (work in progress), May 2015. babel-rtt-extension-01 (work in progress), May 2015.
[BABEL-SS] [BABEL-SS]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-ietf-babel-source-specific-03 (work in Babel", draft-ietf-babel-source-specific-04 (work in
progress), August 2018. progress), October 2018.
[BABEL-TOS] [BABEL-TOS]
Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in
Babel", draft-chouasne-babel-tos-specific-00 (work in Babel", draft-chouasne-babel-tos-specific-00 (work in
progress), July 2017. progress), July 2017.
[BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing
Protocol", draft-chroboczek-babel-diversity-routing-01 Protocol", draft-chroboczek-babel-diversity-routing-01
(work in progress), February 2016. (work in progress), February 2016.
skipping to change at page 9, line 20 skipping to change at page 9, line 30
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998. 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04,
October 2017.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, March 2012. Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", "The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014. RFC 7181, April 2014.
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
 End of changes. 17 change blocks. 
44 lines changed or deleted 52 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/