idnits 2.17.1 draft-ietf-babel-applicability-02.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 (April 6, 2018) is 2211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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-03 == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-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 April 6, 2018 5 Expires: October 8, 2018 7 Applicability of the Babel routing protocol 8 draft-ietf-babel-applicability-02 10 Abstract 12 Where we argue that although OSPF and IS-IS are fine protocols, there 13 exists a space where the Babel routing protocol (RFC 6126bis) can be 14 useful. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 8, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Technical overview of the Babel protocol . . . . . . . . 2 52 1.2. Properties of the Babel protocol . . . . . . . . . . . . 3 53 1.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 54 2. Existing successful deployments of Babel . . . . . . . . . . 6 55 2.1. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6 56 2.2. Large scale overlay networks . . . . . . . . . . . . . . 6 57 2.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 6 58 2.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. Informational References . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 Babel [RFC6126bis] is a routing protocol based on the familiar 67 distance-vector algorithm (sometimes known as distributed Bellman- 68 Ford) augmented with mechanisms for loop avoidance (there is no 69 "counting to infinity") and starvation avoidance. In this document, 70 we argue that there exist niches where Babel is useful and that are 71 not adequately served by the mature, efficient and highly refined 72 protocols that are usually deployed, such as OSPF [RFC5340] and IS-IS 73 [RFC1195]. 75 1.1. Technical overview of the Babel protocol 77 At its core, Babel is a traditional distance-vector protocol based on 78 the distributed Bellman-Ford algorithm, similar in principle to RIP 79 [RFC2453], but with two obvious extensions: provisions for explicit 80 neighbour reachability, bidirectional reachability and link-quality 81 sensing, and support for multiple address families (e.g., IPv6 and 82 IPv4) in a single protocol instance. 84 Algorithms of this class are simple to understand and simple to 85 implement, but unfortunately they do not work very well -- they 86 suffer from "counting to infinity", a case of pathologically slow 87 convergence in some topologies after a link has been brought down. 88 Babel uses a mechanism pioneered by EIGRP [DUAL] [RFC7868], known as 89 "feasibility", which avoids routing loops and therefore makes 90 counting to infinity impossible. 92 Feasibility is a very conservative mechanism, one that not only 93 rejects all looping routes, but also rejects some loop-free routes; 94 it can easily lead to a situation known as starvation, where a router 95 rejects all routes to a given destination, even those that are loop- 96 free. In order to recover from starvation, Babel uses a mechanism 97 pioneered by DSDV [DSDV] and known as "sequenced routes". In Babel, 98 this mechanism is generalised to deal with prefixes of arbitrary 99 length and routes announced at multiple points in a single routing 100 domain (DSDV was a pure mesh protocol, and did not need to deal with 101 such details). 103 The sequenced routes algorithm is slow to react to a starvation 104 episode. In Babel, starvation recovery is accelerated by using 105 explicit requests (known as "seqno requests" in the protocol) to 106 signal a starvation episode and to cause a new sequenced route to be 107 propagated in the network. In the absence of packet loss, this 108 mechanism is provably complete and clears the starvation in time 109 proportional to the diameter of the network, at the cost of some 110 additional signalling traffic. 112 1.2. Properties of the Babel protocol 114 The fairly strong properties of the Babel protocol (convergence, loop 115 avoidance, starvation avoidance) rely on some rather weak properties 116 of the network and the metric being used. The most significant are: 118 o causality: a control message is not received before it has been 119 sent; 121 o strict monotonicity of the metric: M < C + M; 123 o left-distributivity of the metric: if M <= M', then 124 C + M <= C + M'. 126 In particular, Babel does not assume a reliable transport, it does 127 not require an ordered transport, it does not require transitive 128 communication, and it does not require that the metric be discrete 129 (continuous metrics are possible, reflecting for example packet loss 130 rates). This is in contrast to traditional link-state routing 131 protocols such as OSPF [RFC5340] or IS-IS [RFC1195] which are layered 132 over a reliable flooding algorithm and make some rather strong 133 requirements on the underlying network and metric. 135 1.2.1. Simplicity and implementability 137 Babel is a conceptually simple protocol. It consists of a familiar 138 algorithm (distributed Bellman-Ford) augmented with three simple and 139 well-defined mechanisms (feasibility, sequenced routes and explicit 140 requests). Given a sufficiently friendly audience, the principles 141 behind Babel can be explained in 15 minutes, and a full description 142 of the protocol can be done in 52 minutes (one microcentury). 144 An important consequence is that Babel is easy to implement. While 145 Babel is a young protocol, there already exist four independent 146 implementations, one of which was reportedly written and debugged in 147 just two nights. 149 1.2.2. Robustness 151 Babel's correctness depends on a small number of fairly weak and 152 reasonably obvious properties. This makes Babel in many ways a 153 robust protocol: 155 o robust with respect to bugs: unless you are very unlucky, an 156 implementation bug does probably not violate the properties on 157 which Babel relies; in practice, implementation bugs tend to slow 158 down convergence or cause sub-optimal routing, but do not cause 159 the protocol to collapse; 161 o robust with respect to broken networks: a fragile network (non- 162 transitive links, unstable links, etc.) does most probably not 163 violate the assumptions of the protocol; 165 o robust with respect to strange metrics: no matter how strange your 166 metric (continuous, constantly fluctuating, etc.), it does most 167 probably not violate the assumptions of the protocol. 169 These robustness properties have important consequences for the 170 applicability of the protocol: Babel works (more or less efficiently) 171 in a wide range of networks where traditional routing protocols give 172 up. 174 1.2.3. Extensibility 176 Babel's packet format has a number of features designed to make the 177 protocol extensible, and a number of extensions have been designed to 178 make Babel work in situations that were not envisioned when the 179 protocol was initially designed. This extensibility is not an 180 accident, but a consequence of the design of the protocol: it is easy 181 to check whether a given extension violates the assumptions made by 182 the protocol. 184 Remarkably enough, all of the extensions designed to date 185 interoperate with the base protocol and with each other. Again, this 186 is a consequence of the protocol design: in order to check the 187 interoperability of two implementations of Babel, it is enough to 188 verify that the interaction of the two does not violate the 189 protocol's assumptions. 191 Notable extensions deployed to date include: 193 o source-specific routing (SADR) [BABEL-SS], which allows routing to 194 take a packet's source address into account, thus enabling a cheap 195 form of multihoming; 197 o RTT-based routing [BABEL-RTT], which allows routing to minimise 198 link delay, which is useful in overlay network (where both hop 199 count and packet loss are poor metrics). 201 Some other extensions have been designed, but have not seen 202 deployment yet (and their usefulness is yet to be demonstrated): 204 o frequency-aware routing [BABEL-Z], which allows routing to 205 minimise radio interference in wireless networks; 207 o ToS-aware routing [BABEL-TOS], which allows routing to take a 208 packet's ToS marking into account for selected routes without 209 incurring the full cost of a multi-topology routing protocol. 211 1.3. Limitations 213 Babel has some undesirable properties that make it suboptimal or even 214 unusable in some deployments. 216 1.3.1. Periodic updates 218 The main mechanisms used by Babel to reconverge after a topology 219 change are reactive: triggered updates, triggered retractions and 220 explicit requests. However, in the presence of heavy packet loss, 221 Babel relies on periodic updates to clear routing pathologies. This 222 reliance on periodic updates makes Babel unsuitable in at least two 223 kinds of deployments: 225 o large, stable networks: since Babel sends periodic updates even in 226 the absence of topology changes, in well-managed large, stable 227 networks, protocols that rely on a reliable transport (such as 228 OSPF, IS-IS or EIGRP) are intrinsically more efficient; 230 o low-power networks: the periodic updates use up battery power even 231 when there are no topology changes, which makes Babel undesirable 232 in stable, low-power networks. 234 1.3.2. Full routing table 236 While there exist techniques that allow a Babel speaker to function 237 with a partial routing table (e.g., by using just a default route), 238 the basic design of the protocol is that every Babel speaker has a 239 full routing table. In networks where some nodes are too constrained 240 to hold a full routing table, protocols such as AODVv2 [AODVv2], RPL 241 [RFC6550] and LOADng [LOADng] may be preferable to Babel. 243 1.3.3. Slow aggregation 245 Babel's loop-avoidance mechanism relies on making a route unreachable 246 after a retraction until all neighbours have been guaranteed to have 247 acted upon the retraction, even in the presence of packet loss. 248 Unless the optional algorithm described in Section 3.5.5 of 249 [RFC6126bis] is implemented, this entails that a node is unreachable 250 for a few minutes after the most specific route to it has been 251 retracted. This property may make Babel undesirable in networks that 252 perform automatic aggregation. 254 2. Existing successful deployments of Babel 256 In this section, we give a few examples of environments where Babel 257 has been successfully deployed. 259 2.1. Hybrid networks 261 Babel is able to deal with both classical, prefix-based ("Internet- 262 style") routing and flat ("mesh-style") routing over non-transitive 263 link technologies. Because of that, it has seen a number of 264 succesful deployments in medium-sized hybrid networks, networks that 265 combine a wired, aggregated backbone with meshy wireless bits at the 266 edges. No other routing protocol known to us is similarly robust and 267 efficient in this particular type of network. 269 2.2. Large scale overlay networks 271 The algorithms used by Babel (loop avoidance, hysteresis, delayed 272 updates) allow it to remain stable and efficient in the presence of 273 unstable metrics, even in the presence of a feedback loop. For this 274 reason, it has been successfully deployed in large scale overlay 275 networks, built out of thousands of tunnels spanning continents, 276 where it is used with a metric computed from links' latencies 277 [DELAY-BASED]. 279 This particular application depends on the extension for RTT- 280 sensitive routing. 282 2.3. Pure mesh networks 284 While Babel is a general-purpose routing protocol, it has been 285 repeatedly shown to be competitive with dedicated routing protocols 286 for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. While 287 this particular niche is already served by a number of mature 288 protocols, notably OLSR-ETX and OLSRv2 [RFC7181] equipped with the 289 DAT metric [RFC7779], Babel has seen a moderate amount of successful 290 deployment in pure mesh networks. 292 2.4. Small unmanaged networks 294 Because of its small size and simple configuration, Babel has been 295 deployed in small, unmanaged networks (three to five routers), where 296 it serves as a more efficient replacement for RIP [RFC2453], over 297 which it has two significant advantages: the ability to route 298 multiple address families (IPv6 and IPv4) in a single protocol 299 instance, and good support for using wireless links for transit. 301 3. IANA Considerations 303 This document requires no IANA actions. [RFC Editor: please remove 304 this section before publication.] 306 4. Security Considerations 308 As in all distance-vector routing protocols, a Babel speaker receives 309 reachability information from its neighbours, which by default is 310 trusted. A number of attacks are possible if this information is not 311 suitably protected, either by a lower-layer mechanism or by an 312 extension to the protocol itself (e.g. [RFC7298]). 314 Implementors and deployers must be aware of the insecure nature of 315 the base protocol, and must take suitable measures to ensure that the 316 protocol is deployed as securely as required by the application. 318 5. Informational References 320 [AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 321 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 322 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 323 progress), May 2016. 325 [BABEL-RTT] 326 Jonglez, B. and J. Chroboczek, "Delay-based Metric 327 Extension for the Babel Routing Protocol", draft-jonglez- 328 babel-rtt-extension-01 (work in progress), May 2015. 330 [BABEL-SS] 331 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 332 Babel", draft-ietf-babel-source-specific-03 (work in 333 progress), August 2018. 335 [BABEL-TOS] 336 Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in 337 Babel", draft-chouasne-babel-tos-specific-00 (work in 338 progress), July 2017. 340 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 341 Protocol", draft-chroboczek-babel-diversity-routing-01 342 (work in progress), February 2016. 344 [BRIDGING-LAYERS] 345 Murray, D., Dixon, M., and T. Koziniec, "An Experimental 346 Comparison of Routing Protocols in Multi Hop Ad Hoc 347 Networks", Proc. ATNAC 2010, 2010. 349 [DELAY-BASED] 350 Jonglez, B. and J. Chroboczek, "A delay-based routing 351 metric", March 2014, . 353 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 354 Sequenced Distance-Vector Routing (DSDV) for Mobile 355 Computers", ACM SIGCOMM'94 Conference on Communications 356 Architectures, Protocols and Applications 234-244, 1994. 358 [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing 359 Computations", IEEE/ACM Transactions on Networking 1:1, 360 February 1993. 362 [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, 363 Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. 364 Dean, "The Lightweight On-demand Ad hoc Distance-vector 365 Routing Protocol - Next Generation (LOADng)", draft- 366 clausen-lln-loadng-15 (work in progress), January 2017. 368 [REAL-WORLD] 369 Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world 370 performance of current proactive multi-hop mesh 371 protocols", Asia-Pacific Conference on Communication 2009, 372 2009. 374 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 375 dual environments", RFC 1195, December 1990. 377 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 378 1998. 380 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 381 for IPv6", RFC 5340, July 2008. 383 [RFC6126bis] 384 Chroboczek, J. and D. Schinazi, "The Babel Routing 385 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, 386 October 2017. 388 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 389 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 390 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 391 Low-Power and Lossy Networks", RFC 6550, March 2012. 393 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 394 "The Optimized Link State Routing Protocol Version 2", 395 RFC 7181, April 2014. 397 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 398 (HMAC) Cryptographic Authentication", RFC 7298, 399 DOI 10.17487/RFC7298, July 2014, 400 . 402 [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric 403 Based on Packet Sequence Numbers for Optimized Link State 404 Routing Version 2 (OLSRv2)", RFC 7779, 405 DOI 10.17487/RFC7779, April 2016. 407 [RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and 408 R. White, "Cisco's Enhanced Interior Gateway Routing 409 Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 410 2016. 412 Author's Address 414 Juliusz Chroboczek 415 IRIF, University of Paris-Diderot 416 Case 7014 417 75205 Paris Cedex 13 418 France 420 Email: jch@irif.fr