idnits 2.17.1 draft-ietf-babel-applicability-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2018) is 1989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-07 == Outdated reference: A later version (-02) exists of draft-jonglez-babel-rtt-extension-01 == Outdated reference: A later version (-08) exists of draft-ietf-babel-source-specific-04 -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Chroboczek 3 Internet-Draft IRIF, University of Paris-Diderot 4 Intended status: Informational November 14, 2018 5 Expires: May 18, 2019 7 Applicability of the Babel routing protocol 8 draft-ietf-babel-applicability-05 10 Abstract 12 Babel is a routing protocol based on the distance-vector algorithm 13 augmented with mechanisms for loop avoidance and starvation 14 avoidance. In this document, we argue that there exist niches where 15 Babel is useful and that are not adequately served by more mature 16 protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 18, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and background . . . . . . . . . . . . . . . . . 2 53 1.1. Technical overview of the Babel protocol . . . . . . . . 2 54 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 55 2.1. Simplicity and implementability . . . . . . . . . . . . . 3 56 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 60 3.1. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Large scale overlay networks . . . . . . . . . . . . . . 6 62 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 63 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 6.2. Informational References . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction and background 73 Babel [RFC6126bis] is a routing protocol based on the familiar 74 distance-vector algorithm (sometimes known as distributed Bellman- 75 Ford) augmented with mechanisms for loop avoidance (there is no 76 "counting to infinity") and starvation avoidance. In this document, 77 we argue that there exist niches where Babel is useful and that are 78 not adequately served by more mature protocols such as OSPF [RFC5340] 79 and IS-IS [RFC1195]. 81 1.1. Technical overview of the Babel protocol 83 At its core, Babel is a distance-vector protocol based on the 84 distributed Bellman-Ford algorithm, similar in principle to RIP 85 [RFC2453], but with two important extensions: provisions for sensing 86 of neighbour reachability, bidirectional reachability and link 87 quality, and support for multiple address families (e.g., IPv6 and 88 IPv4) in a single protocol instance. 90 Algorithms of this class are simple to understand and simple to 91 implement, but unfortunately they do not work very well -- they 92 suffer from "counting to infinity", a case of pathologically slow 93 convergence in some topologies after a link failure. Babel uses a 94 mechanism pioneered by EIGRP [DUAL] [RFC7868], known as 95 "feasibility", which avoids routing loops and therefore makes 96 counting to infinity impossible. 98 Feasibility is a conservative mechanism, one that not only avoids all 99 looping routes but also rejects some loop-free routes. Thus, it can 100 lead to a situation known as "starvation", where a router rejects all 101 routes to a given destination, even those that are loop-free. In 102 order to recover from starvation, Babel uses a mechanism pioneered by 103 DSDV [DSDV] and known as "sequenced routes". In Babel, this 104 mechanism is generalised to deal with prefixes of arbitrary length 105 and routes announced at multiple points in a single routing domain 106 (DSDV was a pure mesh protocol, and only dealt with host routes). 108 In DSDV, the sequenced routes algorithm is slow to react to a 109 starvation episode. In Babel, starvation recovery is accelerated by 110 using explicit requests (known as "seqno requests" in the protocol) 111 that signal a starvation episode and cause a new sequenced route to 112 be propagated in a timely manner. In the absence of packet loss, 113 this mechanism is provably complete and clears the starvation in time 114 proportional to the diameter of the network, at the cost of some 115 additional signalling traffic. 117 2. Properties of the Babel protocol 119 In this section, we describe the properties of the Babel protocol as 120 well as its known limitations. 122 2.1. Simplicity and implementability 124 Babel is a conceptually simple protocol. It consists of a familiar 125 algorithm (distributed Bellman-Ford) augmented with three simple and 126 well-defined mechanisms (feasibility, sequenced routes and explicit 127 requests). Given a sufficiently friendly audience, the principles 128 behind Babel can be explained in 15 minutes, and a full description 129 of the protocol can be done in 52 minutes (one microcentury). 131 An important consequence is that Babel is easy to implement. At the 132 time of writing, there exist four independent implementations, 133 including one that was reportedly written and debugged in just two 134 nights. 136 2.2. Robustness 138 The fairly strong properties of the Babel protocol (convergence, loop 139 avoidance, starvation avoidance) rely on some rather weak properties 140 of the network and the metric being used. The most significant are: 142 o causality: a control message is not received before it has been 143 sent (more precisely, the "happens-before" relation is acyclic); 145 o strict monotonicity of the metric: for any metric M and link 146 cost C, M < C + M; 148 o left-distributivity of the metric: for any metrics M and M' and 149 cost C, if M <= M', then C + M <= C + M'. 151 In particular, Babel does not assume a reliable transport, it does 152 not assume ordered delivery, it does not assume that communication is 153 transitive, and it does not require that the metric be discrete 154 (continuous metrics are possible, reflecting for example packet loss 155 rates). This is in contrast to link-state routing protocols such as 156 OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable 157 flooding algorithm and make stronger requirements on the underlying 158 network and metric. 160 These weak requirements make Babel a robust protocol: 162 o robust with respect to bugs: an implementation bug does most 163 likely not violate the properties on which Babel relies; in our 164 (extensive) experience, bugs tend to slow down convergence or 165 cause sub-optimal routing, but do not cause the network to 166 collapse; 168 o robust with respect to unusual networks: an unusual network (non- 169 transitive links, unstable metrics, etc.) does most likely not 170 violate the assumptions of the protocol; 172 o robust with respect to novel metrics: no matter how strange your 173 metric (continuous, constantly fluctuating, etc.), it does most 174 likely not violate the assumptions of the protocol. 176 These robustness properties have important consequences for the 177 applicability of the protocol: Babel works (more or less efficiently) 178 in a wide range of circumstances where traditional routing protocols 179 give up. 181 2.3. Extensibility 183 Babel's packet format has a number of features that make the protocol 184 extensible (see Appendix C of [RFC6126bis]), and a number of 185 extensions have been designed to make Babel work better in situations 186 that were not envisioned when the protocol was initially designed. 187 The ease of extensibility is not an accident, but a consequence of 188 the design of the protocol: it is reasonably easy to check whether a 189 given extension violates the assumptions on which Babel relies. 191 All of the extensions designed to date interoperate with the base 192 protocol and with each other. This, again, is a consequence of the 193 protocol design: in order to check the interoperability of two 194 implementations of Babel, it is enough to verify that the interaction 195 of the two does not violate the protocol's assumptions. 197 Notable extensions deployed to date include: 199 o source-specific routing (SADR) [BABEL-SS] allows forwarding to 200 take a packet's source address into account, thus enabling a cheap 201 form of multihoming [SS-ROUTING]; 203 o RTT-based routing [BABEL-RTT] minimises link delay, which is 204 useful in overlay network (where both hop count and packet loss 205 are poor metrics). 207 Some other extensions have been designed, but have not seen 208 deployment yet (and their usefulness is yet to be demonstrated): 210 o frequency-aware routing [BABEL-Z] aims to minimise radio 211 interference in wireless networks; 213 o ToS-aware routing [BABEL-TOS] allows routing to take a packet's 214 ToS marking into account for selected routes without incurring the 215 full cost of a multi-topology routing protocol. 217 2.4. Limitations 219 Babel has some undesirable properties that make it suboptimal or even 220 unusable in some deployments. 222 2.4.1. Periodic updates 224 The main mechanisms used by Babel to reconverge after a topology 225 change are reactive: triggered updates, triggered retractions and 226 explicit requests. However, in the presence of heavy packet loss, 227 Babel relies on periodic updates to clear pathologies. This reliance 228 on periodic updates makes Babel unsuitable in at least two kinds of 229 deployments: 231 o large, stable networks: since Babel sends periodic updates even in 232 the absence of topology changes, in well-managed, large, stable 233 networks the amount of control traffic will be reduced by using a 234 protocol that uses a reliable transport (such as OSPF, IS-IS or 235 EIGRP); 237 o low-power networks: the periodic updates use up battery power even 238 when there are no topology changes and no user traffic, which 239 makes Babel wasteful in low-power networks. 241 2.4.2. Full routing table 243 While there exist techniques that allow a Babel speaker to function 244 with a partial routing table (e.g., by learning just a default route 245 or, more generally, performing route aggregation), Babel is designed 246 around the assumption that every router has a full routing table. In 247 networks where some nodes are too constrained to hold a full routing 248 table, it might be preferable to use a protocol that was designed 249 from the outset to work with a partial routing table (such as AODVv2 250 [AODVv2], RPL [RFC6550] or LOADng [LOADng]). 252 2.4.3. Slow aggregation 254 Babel's loop-avoidance mechanism relies on making a route unreachable 255 after a retraction until all neighbours have been guaranteed to have 256 acted upon the retraction, even in the presence of packet loss. 257 Unless the optional algorithm described in Section 3.5.5 of 258 [RFC6126bis] is implemented, this entails that a node is unreachable 259 for a few minutes after the most specific route to it has been 260 retracted. This delay may make Babel slow to recover from a topology 261 change in networks that perform automatic route aggregation. 263 3. Successful deployments of Babel 265 In this section, we give a few examples of environments where Babel 266 has been successfully deployed. 268 3.1. Hybrid networks 270 Babel is able to deal with both classical, prefix-based ("Internet- 271 style") routing and flat ("mesh-style") routing over non-transitive 272 link technologies. Because of that, it has seen a number of 273 succesful deployments in medium-sized hybrid networks, networks that 274 combine a wired, aggregated backbone with meshy wireless bits at the 275 edges. No other routing protocol known to us is similarly robust and 276 efficient in this particular kind of topology. 278 Efficient operation in hybrid networks requires the implementation to 279 distinguish wired and wireless links, and to perform link quality 280 estimation on wireless links. 282 3.2. Large scale overlay networks 284 The algorithms used by Babel (loop avoidance, hysteresis, delayed 285 updates) allow it to remain stable and efficient in the presence of 286 unstable metrics, even in the presence of a feedback loop. For this 287 reason, it has been successfully deployed in large scale overlay 288 networks, built out of thousands of tunnels spanning continents, 289 where it is used with a metric computed from links' latencies. 291 This particular application depends on the extension for RTT- 292 sensitive routing [DELAY-BASED]. 294 3.3. Pure mesh networks 296 While Babel is a general-purpose routing protocol, it has been 297 repeatedly shown to be competitive with dedicated routing protocols 298 for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. Although 299 this particular niche is already served by a number of mature 300 protocols, notably OLSR-ETX and OLSRv2 [RFC7181] (equipped e.g. with 301 the DAT metric [RFC7779]), Babel has seen a moderate amount of 302 successful deployment in pure mesh networks. 304 3.4. Small unmanaged networks 306 Because of its small size and simple configuration, Babel has been 307 deployed in small, unmanaged networks (e.g., home and small office 308 networks), where it serves as a more efficient replacement for RIP 309 [RFC2453], over which it has two significant advantages: the ability 310 to route multiple address families (IPv6 and IPv4) in a single 311 protocol instance, and good support for using wireless links for 312 transit. 314 4. IANA Considerations 316 This document requires no IANA actions. [RFC Editor: please remove 317 this section before publication.] 319 5. Security Considerations 321 As is the case in all distance-vector routing protocols, a Babel 322 speaker receives reachability information from its neighbours, which 323 by default is trusted. A number of attacks are possible if this 324 information is not suitably protected, either by a lower-layer 325 mechanism or by an extension to the protocol itself (e.g. [RFC7298]). 327 Implementors and deployers must be aware of the insecure nature of 328 the base protocol, and must take suitable measures to ensure that the 329 protocol is deployed as securely as required by the application. 331 6. References 332 6.1. Normative References 334 [RFC6126bis] 335 Chroboczek, J. and D. Schinazi, "The Babel Routing 336 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-07, 337 November 2018. 339 6.2. Informational References 341 [AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 342 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 343 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 344 progress), May 2016. 346 [BABEL-RTT] 347 Jonglez, B. and J. Chroboczek, "Delay-based Metric 348 Extension for the Babel Routing Protocol", draft-jonglez- 349 babel-rtt-extension-01 (work in progress), May 2015. 351 [BABEL-SS] 352 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 353 Babel", draft-ietf-babel-source-specific-04 (work in 354 progress), October 2018. 356 [BABEL-TOS] 357 Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in 358 Babel", draft-chouasne-babel-tos-specific-00 (work in 359 progress), July 2017. 361 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 362 Protocol", draft-chroboczek-babel-diversity-routing-01 363 (work in progress), February 2016. 365 [BRIDGING-LAYERS] 366 Murray, D., Dixon, M., and T. Koziniec, "An Experimental 367 Comparison of Routing Protocols in Multi Hop Ad Hoc 368 Networks", Proc. ATNAC 2010, 2010. 370 [DELAY-BASED] 371 Jonglez, B. and J. Chroboczek, "A delay-based routing 372 metric", March 2014, . 374 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 375 Sequenced Distance-Vector Routing (DSDV) for Mobile 376 Computers", ACM SIGCOMM'94 Conference on Communications 377 Architectures, Protocols and Applications 234-244, 1994. 379 [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing 380 Computations", IEEE/ACM Transactions on Networking 1:1, 381 February 1993. 383 [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, 384 Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. 385 Dean, "The Lightweight On-demand Ad hoc Distance-vector 386 Routing Protocol - Next Generation (LOADng)", draft- 387 clausen-lln-loadng-15 (work in progress), January 2017. 389 [REAL-WORLD] 390 Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world 391 performance of current proactive multi-hop mesh 392 protocols", Asia-Pacific Conference on Communication 2009, 393 2009. 395 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 396 dual environments", RFC 1195, December 1990. 398 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 399 1998. 401 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 402 for IPv6", RFC 5340, July 2008. 404 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 405 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 406 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 407 Low-Power and Lossy Networks", RFC 6550, March 2012. 409 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 410 "The Optimized Link State Routing Protocol Version 2", 411 RFC 7181, April 2014. 413 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 414 (HMAC) Cryptographic Authentication", RFC 7298, 415 DOI 10.17487/RFC7298, July 2014, 416 . 418 [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric 419 Based on Packet Sequence Numbers for Optimized Link State 420 Routing Version 2 (OLSRv2)", RFC 7779, 421 DOI 10.17487/RFC7779, April 2016. 423 [RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and 424 R. White, "Cisco's Enhanced Interior Gateway Routing 425 Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 426 2016. 428 [SS-ROUTING] 429 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 430 August 2014, . 432 In Proc. IFIP Networking 2015. 434 Author's Address 436 Juliusz Chroboczek 437 IRIF, University of Paris-Diderot 438 Case 7014 439 75205 Paris Cedex 13 440 France 442 Email: jch@irif.fr