idnits 2.17.1 draft-ietf-babel-applicability-03.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 7, 2018) is 2204 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 7, 2018 5 Expires: October 9, 2018 7 Applicability of the Babel routing protocol 8 draft-ietf-babel-applicability-03 10 Abstract 12 Where we argue that, although OSPF and IS-IS are fine protocols, 13 there exists a space where the Babel routing protocol (RFC 6126bis) 14 is 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 9, 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 and background . . . . . . . . . . . . . . . . . 2 51 1.1. Technical overview of the Babel protocol . . . . . . . . 2 52 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 53 2.1. Simplicity and implementability . . . . . . . . . . . . . 3 54 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 58 3.1. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Large scale overlay networks . . . . . . . . . . . . . . 6 60 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 61 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. Informational References . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction and background 69 Babel [RFC6126bis] is a routing protocol based on the familiar 70 distance-vector algorithm (sometimes known as distributed Bellman- 71 Ford) augmented with mechanisms for loop avoidance (there is no 72 "counting to infinity") and starvation avoidance. In this document, 73 we argue that there exist niches where Babel is useful and that are 74 not adequately served by more mature protocols such as OSPF [RFC5340] 75 and IS-IS [RFC1195]. 77 1.1. Technical overview of the Babel protocol 79 At its core, Babel is a traditional distance-vector protocol based on 80 the distributed Bellman-Ford algorithm, similar in principle to RIP 81 [RFC2453], but with two obvious extensions: provisions for sensing of 82 neighbour reachability, bidirectional reachability and link quality, 83 and support for multiple address families (e.g., IPv6 and IPv4) in a 84 single protocol instance. 86 Algorithms of this class are simple to understand and simple to 87 implement, but unfortunately they do not work very well -- they 88 suffer from "counting to infinity", a case of pathologically slow 89 convergence in some topologies after a link failure. Babel uses a 90 mechanism pioneered by EIGRP [DUAL] [RFC7868], known as 91 "feasibility", which avoids routing loops and therefore makes 92 counting to infinity impossible. 94 Feasibility is a conservative mechanism, one that not only avoids all 95 looping routes but also rejects some loop-free routes. Thus, it can 96 lead to a situation known as "starvation", where a router rejects all 97 routes to a given destination, even those that are loop-free. In 98 order to recover from starvation, Babel uses a mechanism pioneered by 99 DSDV [DSDV] and known as "sequenced routes". In Babel, this 100 mechanism is generalised to deal with prefixes of arbitrary length 101 and routes announced at multiple points in a single routing domain 102 (DSDV was a pure mesh protocol, and only dealt with host routes). 104 In DSDV, the sequenced routes algorithm is slow to react to a 105 starvation episode. In Babel, starvation recovery is accelerated by 106 using explicit requests (known as "seqno requests" in the protocol) 107 that signal a starvation episode and cause a new sequenced route to 108 be propagated in a timely manner. In the absence of packet loss, 109 this mechanism is provably complete and clears the starvation in time 110 proportional to the diameter of the network, at the cost of some 111 additional signalling traffic. 113 2. Properties of the Babel protocol 115 In this section, we describe the properties of the Babel protocol as 116 well as its known limitations. 118 2.1. Simplicity and implementability 120 Babel is a conceptually simple protocol. It consists of a familiar 121 algorithm (distributed Bellman-Ford) augmented with three simple and 122 well-defined mechanisms (feasibility, sequenced routes and explicit 123 requests). Given a sufficiently friendly audience, the principles 124 behind Babel can be explained in 15 minutes, and a full description 125 of the protocol can be done in 52 minutes (one microcentury). 127 An important consequence is that Babel is easy to implement. While 128 Babel is a young protocol, there exist four independent 129 implementations, including one that was reportedly written and 130 debugged in just two nights. 132 2.2. Robustness 134 The fairly strong properties of the Babel protocol (convergence, loop 135 avoidance, starvation avoidance) rely on some rather weak properties 136 of the network and the metric being used. The most significant are: 138 o causality: a control message is not received before it has been 139 sent (more precisely, the "happens-before" relation is acyclic); 141 o strict monotonicity of the metric: M < C + M; 142 o left-distributivity of the metric: if M <= M', then 143 C + M <= C + M'. 145 In particular, Babel does not assume a reliable transport, it does 146 not assume ordered delivery, it does not assume that communication is 147 transitive, and it does not require that the metric be discrete 148 (continuous metrics are possible, reflecting for example packet loss 149 rates). This is in contrast to traditional link-state routing 150 protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which are 151 layered over a reliable flooding algorithm and make stronger 152 requirements on the underlying network and metric. 154 These weak requirements make Babel a robust protocol: 156 o robust with respect to bugs: an implementation bug does most 157 probably not violate the properties on which Babel relies; in our 158 (extensive) experience, bugs tend to slow down convergence or 159 cause sub-optimal routing, but do not cause the network to 160 collapse; 162 o robust with respect to unusual networks: an unusual network (non- 163 transitive links, unstable metrics, etc.) does most probably not 164 violate the assumptions of the protocol; 166 o robust with respect to novel metrics: no matter how strange your 167 metric (continuous, constantly fluctuating, etc.), it does most 168 probably not violate the assumptions of the protocol. 170 These robustness properties have important consequences for the 171 applicability of the protocol: Babel works (more or less efficiently) 172 in a wide range of circumstances where traditional routing protocols 173 give up. 175 2.3. Extensibility 177 Babel's packet format has a number of features that make the protocol 178 extensible (see Appendix C of [RFC6126bis]), and a number of 179 extensions have been designed to make Babel work better in situations 180 that were not envisioned when the protocol was initially designed. 181 The ease of extensibility is not an accident, but a consequence of 182 the design of the protocol: it is reasonably easy to check whether a 183 given extension violates the assumptions on which Babel relies. 185 Remarkably enough, all of the extensions designed to date 186 interoperate with the base protocol and with each other. This, 187 again, is a consequence of the protocol design: in order to check the 188 interoperability of two implementations of Babel, it is enough to 189 verify that the interaction of the two does not violate the 190 protocol's assumptions. 192 Notable extensions deployed to date include: 194 o source-specific routing (SADR) [BABEL-SS] allows forwarding to 195 take a packet's source address into account, thus enabling a cheap 196 form of multihoming [SS-ROUTING]; 198 o RTT-based routing [BABEL-RTT] minimises link delay, which is 199 useful in overlay network (where both hop count and packet loss 200 are poor metrics). 202 Some other extensions have been designed, but have not seen 203 deployment yet (and their usefulness is yet to be demonstrated): 205 o frequency-aware routing [BABEL-Z] aims to minimise radio 206 interference in wireless networks; 208 o ToS-aware routing [BABEL-TOS] allows routing to take a packet's 209 ToS marking into account for selected routes without incurring the 210 full cost of a multi-topology routing protocol. 212 2.4. Limitations 214 Babel has some undesirable properties that make it suboptimal or even 215 unusable in some deployments. 217 2.4.1. Periodic updates 219 The main mechanisms used by Babel to reconverge after a topology 220 change are reactive: triggered updates, triggered retractions and 221 explicit requests. However, in the presence of heavy packet loss, 222 Babel relies on periodic updates to clear pathologies. This reliance 223 on periodic updates makes Babel unsuitable in at least two kinds of 224 deployments: 226 o large, stable networks: since Babel sends periodic updates even in 227 the absence of topology changes, in well-managed, large, stable 228 networks the amount of control traffic will be reduced by using a 229 protocol that relies on a reliable transport (such as OSPF, IS-IS 230 or EIGRP); 232 o low-power networks: the periodic updates use up battery power even 233 when there are no topology changes and no user traffic, which 234 makes Babel wasteful in low-power networks. 236 2.4.2. Full routing table 238 While there exist techniques that allow a Babel speaker to function 239 with a partial routing table (e.g., by learning just a default route 240 or, more generally, performing route aggregation), Babel is designed 241 around the assumption that every router has a full routing table. In 242 networks where some nodes are too constrained to hold a full routing 243 table, it might be preferable to use a protocol that was designed 244 from the outset to work with a partial routing table (such as AODVv2 245 [AODVv2], RPL [RFC6550] or LOADng [LOADng]). 247 2.4.3. Slow aggregation 249 Babel's loop-avoidance mechanism relies on making a route unreachable 250 after a retraction until all neighbours have been guaranteed to have 251 acted upon the retraction, even in the presence of packet loss. 252 Unless the optional algorithm described in Section 3.5.5 of 253 [RFC6126bis] is implemented, this entails that a node is unreachable 254 for a few minutes after the most specific route to it has been 255 retracted. This delay may make Babel slow to recover from a topology 256 change in networks that perform automatic route aggregation. 258 3. Successful deployments of Babel 260 In this section, we give a few examples of environments where Babel 261 has been successfully deployed. 263 3.1. Hybrid networks 265 Babel is able to deal with both classical, prefix-based ("Internet- 266 style") routing and flat ("mesh-style") routing over non-transitive 267 link technologies. Because of that, it has seen a number of 268 succesful deployments in medium-sized hybrid networks, networks that 269 combine a wired, aggregated backbone with meshy wireless bits at the 270 edges. No other routing protocol known to us is similarly robust and 271 efficient in this particular kind of topology. 273 Efficient operation in hybrid networks requires the implementation to 274 distinguish wired and wireless links, and to perform link quality 275 estimation on wireless links. 277 3.2. Large scale overlay networks 279 The algorithms used by Babel (loop avoidance, hysteresis, delayed 280 updates) allow it to remain stable and efficient in the presence of 281 unstable metrics, even in the presence of a feedback loop. For this 282 reason, it has been successfully deployed in large scale overlay 283 networks, built out of thousands of tunnels spanning continents, 284 where it is used with a metric computed from links' latencies. 286 This particular application depends on the extension for RTT- 287 sensitive routing [DELAY-BASED]. 289 3.3. Pure mesh networks 291 While Babel is a general-purpose routing protocol, it has been 292 repeatedly shown to be competitive with dedicated routing protocols 293 for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. Although 294 this particular niche is already served by a number of mature 295 protocols, notably OLSR-ETX and OLSRv2 [RFC7181] (equipped e.g. with 296 the DAT metric [RFC7779]), Babel has seen a moderate amount of 297 successful deployment in pure mesh networks. 299 3.4. Small unmanaged networks 301 Because of its small size and simple configuration, Babel has been 302 deployed in small, unmanaged networks (e.g., home and small office 303 networks), where it serves as a more efficient replacement for RIP 304 [RFC2453], over which it has two significant advantages: the ability 305 to route multiple address families (IPv6 and IPv4) in a single 306 protocol instance, and good support for using wireless links for 307 transit. 309 4. IANA Considerations 311 This document requires no IANA actions. [RFC Editor: please remove 312 this section before publication.] 314 5. Security Considerations 316 As is the case in all distance-vector routing protocols, a Babel 317 speaker receives reachability information from its neighbours, which 318 by default is trusted. A number of attacks are possible if this 319 information is not suitably protected, either by a lower-layer 320 mechanism or by an extension to the protocol itself (e.g. [RFC7298]). 322 Implementors and deployers must be aware of the insecure nature of 323 the base protocol, and must take suitable measures to ensure that the 324 protocol is deployed as securely as required by the application. 326 6. Informational References 328 [AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 329 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 330 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 331 progress), May 2016. 333 [BABEL-RTT] 334 Jonglez, B. and J. Chroboczek, "Delay-based Metric 335 Extension for the Babel Routing Protocol", draft-jonglez- 336 babel-rtt-extension-01 (work in progress), May 2015. 338 [BABEL-SS] 339 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 340 Babel", draft-ietf-babel-source-specific-03 (work in 341 progress), August 2018. 343 [BABEL-TOS] 344 Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in 345 Babel", draft-chouasne-babel-tos-specific-00 (work in 346 progress), July 2017. 348 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 349 Protocol", draft-chroboczek-babel-diversity-routing-01 350 (work in progress), February 2016. 352 [BRIDGING-LAYERS] 353 Murray, D., Dixon, M., and T. Koziniec, "An Experimental 354 Comparison of Routing Protocols in Multi Hop Ad Hoc 355 Networks", Proc. ATNAC 2010, 2010. 357 [DELAY-BASED] 358 Jonglez, B. and J. Chroboczek, "A delay-based routing 359 metric", March 2014, . 361 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 362 Sequenced Distance-Vector Routing (DSDV) for Mobile 363 Computers", ACM SIGCOMM'94 Conference on Communications 364 Architectures, Protocols and Applications 234-244, 1994. 366 [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing 367 Computations", IEEE/ACM Transactions on Networking 1:1, 368 February 1993. 370 [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, 371 Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. 372 Dean, "The Lightweight On-demand Ad hoc Distance-vector 373 Routing Protocol - Next Generation (LOADng)", draft- 374 clausen-lln-loadng-15 (work in progress), January 2017. 376 [REAL-WORLD] 377 Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world 378 performance of current proactive multi-hop mesh 379 protocols", Asia-Pacific Conference on Communication 2009, 380 2009. 382 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 383 dual environments", RFC 1195, December 1990. 385 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 386 1998. 388 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 389 for IPv6", RFC 5340, July 2008. 391 [RFC6126bis] 392 Chroboczek, J. and D. Schinazi, "The Babel Routing 393 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, 394 October 2017. 396 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 397 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 398 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 399 Low-Power and Lossy Networks", RFC 6550, March 2012. 401 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 402 "The Optimized Link State Routing Protocol Version 2", 403 RFC 7181, April 2014. 405 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 406 (HMAC) Cryptographic Authentication", RFC 7298, 407 DOI 10.17487/RFC7298, July 2014, 408 . 410 [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric 411 Based on Packet Sequence Numbers for Optimized Link State 412 Routing Version 2 (OLSRv2)", RFC 7779, 413 DOI 10.17487/RFC7779, April 2016. 415 [RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and 416 R. White, "Cisco's Enhanced Interior Gateway Routing 417 Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 418 2016. 420 [SS-ROUTING] 421 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 422 August 2014, . 424 In Proc. IFIP Networking 2015. 426 Author's Address 428 Juliusz Chroboczek 429 IRIF, University of Paris-Diderot 430 Case 7014 431 75205 Paris Cedex 13 432 France 434 Email: jch@irif.fr