idnits 2.17.1 draft-mrw-homenet-rtg-comparison-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3339 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 1129, but not defined == Outdated reference: A later version (-04) exists of draft-chroboczek-babel-extension-mechanism-03 == Outdated reference: A later version (-02) exists of draft-jonglez-babel-rtt-extension-00 == Outdated reference: A later version (-03) exists of draft-boutier-babel-source-specific-00 == Outdated reference: A later version (-01) exists of draft-chroboczek-babel-diversity-routing-00 == Outdated reference: A later version (-06) exists of draft-liu-isis-auto-conf-03 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-02 -- Obsolete informational reference (is this intentional?): RFC 6126 (Obsoleted by RFC 8966) -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group M. Wasserman 3 Internet-Draft Painless Security 4 Intended status: Informational C. Hopps 5 Expires: September 6, 2015 Deutsche Telekom 6 J. Chroboczek 7 University of Paris-Diderot (Paris 7) 8 March 5, 2015 10 Homenet IS-IS and Babel Comparison 11 draft-mrw-homenet-rtg-comparison-02.txt 13 Abstract 15 This document is intended to provide information to members of the 16 IETF Home Networks Working Group (Homenet WG), so that we can make an 17 informed decision regarding which routing protocol to use in home 18 networks. The routing protocols compared in this document are: The 19 Babel Routing Protocol (Babel) and The Intermediate System to 20 Intermediate System Intra-Domain Routing Protocol (IS-IS). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 6, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Protocols and Extensions Included in Comparison . . . . . . . 5 58 2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 5 59 2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 6 60 3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 6 62 3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) . . . . . 6 63 3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Convergence Times . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Support for Source-Specific Routing . . . . . . . . . . . . . 9 73 6.1. Source-Specific Routing in IS-IS . . . . . . . . . . . . 9 74 6.2. Source-Specific Routing in Babel . . . . . . . . . . . . 9 75 6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Support for Link Metrics . . . . . . . . . . . . . . . . . . 10 77 7.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 10 78 7.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 10 79 7.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. Support for Stub Networks and Stub Routers . . . . . . . . . 11 81 8.1. IS-IS Support for Stub Networks and Stub Routers . . . . 12 82 8.2. Babel Support for Stub Networks . . . . . . . . . . . . . 12 83 8.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 84 9. Support for non-IEEE 802.2 link layers . . . . . . . . . . . 13 85 9.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 9.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10. Security Features . . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. Security Features in IS-IS . . . . . . . . . . . . . . . 13 89 10.2. Security Features in Babel . . . . . . . . . . . . . . . 13 90 10.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14 91 11. Support for Multicast . . . . . . . . . . . . . . . . . . . . 14 92 11.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 14 93 11.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 14 94 11.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14 95 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 96 13. Code and State Size . . . . . . . . . . . . . . . . . . . . . 15 97 13.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 15 98 13.2. Babel Code and State Size . . . . . . . . . . . . . . . 15 99 13.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 16 100 14. Ease of porting . . . . . . . . . . . . . . . . . . . . . . . 17 101 14.1. IS-IS ease of porting . . . . . . . . . . . . . . . . . 17 102 14.2. Babel ease of porting . . . . . . . . . . . . . . . . . 17 103 14.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 18 104 15. Behaviour upon resource exhaustion . . . . . . . . . . . . . 18 105 15.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 15.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . 18 107 16. Performance and scaling on IEEE 802.11 Wireless Networks . . 18 108 16.1. IS-IS Performance on 802.11 . . . . . . . . . . . . . . 19 109 16.2. Babel Performance on 802.11 . . . . . . . . . . . . . . 19 110 16.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 20 111 17. Standardization Status . . . . . . . . . . . . . . . . . . . 20 112 17.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 20 113 17.2. Babel Standardization Status . . . . . . . . . . . . . . 20 114 18. Evaluation of RFC 7368 Criteria . . . . . . . . . . . . . . . 21 115 19. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 22 116 19.1. Critical Success Factors . . . . . . . . . . . . . . . . 22 117 19.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 22 118 19.1.2. Babel Success Factors . . . . . . . . . . . . . . . 23 119 19.2. Willing Implementors . . . . . . . . . . . . . . . . . . 24 120 19.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 24 121 19.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 24 122 19.3. Willing Customers . . . . . . . . . . . . . . . . . . . 24 123 19.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 24 124 19.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 24 125 19.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 25 126 19.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 25 127 19.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 25 128 19.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 25 129 19.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 25 130 19.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 25 131 19.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 25 132 19.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 26 133 19.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 26 134 19.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 26 135 19.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 26 136 19.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 26 137 19.8. Success Predictable . . . . . . . . . . . . . . . . . . 27 138 19.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 27 139 19.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 27 140 20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 141 21. Informative References . . . . . . . . . . . . . . . . . . . 27 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 144 1. Introduction 146 This document compares IS-IS (ISO/IEC 10589:2002) [ISO10589] and 147 Babel [RFC6126] according to several criteria related to their use in 148 home networks (Homenets), as defined by the Homenet WG. 150 [There has been a request that this document compare OSPF as well as 151 Babel and IS-IS. If the WG would find that useful, we would need an 152 OSPF expert who is willing to provide text on OSPF similar to the 153 information that has been provided for IS-IS and Babel.] 155 Please note that this document does not represent the consenus of any 156 group, not even the authors. It is an organized collection of facts 157 and well-informed opinions provided by experts on Babel and IS-IS 158 that may be useful to the Homenet WG in choosing a routing protocol. 160 The Homenet environment is different from the environment of a 161 professionally administered network. The most obvious difference is 162 that most home networks are not administered: any protocols used must 163 be robust and fully self-configuring, and any tuning knobs that they 164 provide will be unused in the vast majority of deployments. There 165 may be exceptions to the "no configuration" rule in some 166 environments. For instance, Homenet products may be used in 167 environments where network security is important enough to warrant 168 the configuration of security information, such as keys or 169 certificates. However, even in those environments, minimal 170 configuration should be necessary to deploy a Homenet network. 172 Another difference is that Homenets are usually built out of a 173 specific class of cheap device, the "Plastic Home Router". A Plastic 174 Home Router's firmware is installed at the factory, and is most 175 likely never updated. Additionally, experience shows that home 176 routers are often used way beyond their warranty period, and even 177 after their manufacturer leaves the router business. This, again, 178 argues in favour of simple, robust protocols that are easy to 179 implement and can be expected to keep functioning without software 180 updates. 182 A Plastic Home Router is usually equipped with a reasonable CPU but 183 fairly small amounts of flash and RAM. At the time of writing, a 184 typical example of the bottom of the range has a 200MHz MIPS 4KEc CPU 185 (8kB data cache), but only 4MB of flash and 8MB of RAM. More 186 expensive multi-purpose products may have a 700MHz MIPS 24Kc with 187 32MB of flash and as much as 128MB of RAM. 189 We expect smaller devices to want to participate in the Homenet 190 protocols. In particular, some vendors have expressed interest in 191 producing sensor-class hardware that is able to interoperate with 192 Homenet (smart thermostats, home automation hardware, etc.). It is 193 therefore desirable to be able to scale down the Homenet protocols 194 down to a few tens of kB, at least in a stub role. 196 Homenets are built and grow organically, and often end up consisting 197 of multiple link technologies with widely different performance 198 characteristics (twisted-pair Ethernet at gigabit speed, IEEE 802.11 199 (WiFi) and its multiple variants, Powerline Ethernet, etc.). It is 200 desirable for a Homenet routing protocol to be able to dynamically 201 optimise paths according to the link characteristics. 203 Experts appear to disagree on the expected size of a Homenet: we have 204 heard estimates ranging from just one router up to 250 routers. In 205 any case, while scaling beyond a few thousand nodes is not likely to 206 be relevant to Homenet in the foreseeable future, the Homenet 207 protocols, if successful, will be repurposed to larger networks, 208 whether we like it or not, and it is desirable to use a protocol that 209 scales well. 211 2. Protocols and Extensions Included in Comparison 213 Both the IS-IS and Babel protocols are updated and extended over 214 time. This section lists the extensions that were considered in this 215 comparison. Additional protocol extensions could affect some of the 216 information included in this document. 218 2.1. IS-IS Protocol and Extensions 220 In addition to the base IS-IS protocol specification [ISO10589], this 221 comparison considers the following IS-IS extensions: 223 Homenet related specifications 225 o ISIS Auto-Configuration [ISIS-AUTOCONF]; 227 o Source-Specific routing in IS-IS [ISIS-SS]. 229 Base protocol specifications. 231 o Use of OSI IS-IS for Routing in TCP/IP and Dual Environments 232 [RFC1195] 234 o IS-IS Extensions for Traffic Engineering [RFC5305] 236 o Routing IPv6 with IS-IS [RFC5308] 238 2.2. Babel Protocol and Extensions 240 In addition to the base Babel Protocol specification (RFC 6126), this 241 comparison considers the following Babel extensions: 243 o Extension Mechanism for the Babel Routing Protocol [BABEL-EXT]; 245 o Source-Specific Routing [BABEL-SS], described in more detail in 246 [SS-ROUTING]. 248 3. Routing Algorithms 250 IS-IS is a Link State routing protocol, and Babel is a Loop-Avoiding 251 Distance Vector routing protocol. There are some differences between 252 these algorithms, particularly in terms of scalability, how much 253 information is exchanged when the routing topology changes, and how 254 far topology changes are propagated. 256 3.1. Link State Algorithm 258 Link state algorithms distribute information for each node to all 259 other nodes in the network using a flooding algorithm. This database 260 of information is then used by each node to compute the best path to 261 the other nodes in the network. 263 One benefit of this algorithm is that each node contains the full 264 knowledge of the topology of the network. This information can be 265 used by other applications outside the routing protocol itself. 267 Additionally the flooding algorithm has been found as an efficient 268 method for other applications to distribute node-specific application 269 data, although some care must be taken with this use so as not to 270 disrupt the fundamental routing function. 272 3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) 274 Distance-vector algorithms distribute information about the path 275 length to reach each destination through a given neighbor. Packets 276 are forwarded through the neighbor that is advertising the best path 277 towards the destination. 279 Babel, like EIGRP, DSDV, and to a certain extent BGP, uses a loop- 280 avoiding distance-vector algorithm: it avoids creating a loop even 281 during reconvergence, there is no "counting to infinity", and even 282 short-lived "microloops" are avoided in most cases. 284 3.3. Discussion 286 From a purely algorithmic point of view, both kinds of algorithms are 287 known to scale well beyond the needs of Homenet. Issues of scaling 288 over wireless and lossy links is discussed in Section 16. 290 4. Convergence Times 292 Convergence time is defined as the amount of time after a link 293 failure is detected during which the network is not fully 294 operational. It does not include the time necessary to detect a link 295 failure. 297 4.1. IS-IS 299 Given fast flooding of any change in the network, IS-IS has been 300 shown to acheive sub 200ms end-to-end convergence even in very large 301 provider networks (single area 900+ nodes). Basically the time for 302 convergence is the time to propagate new link state from one end of 303 the network to the other plus the SPF (tree computation interval) and 304 FIB loading time. The flooding is done without delay and prior to 305 running the SPF (tree-calculation) algorithm. Thus is roughly 306 proportional to propagation delay across the diameter of the network. 307 The tree calculation is sub 20ms on modern CPUs. FIB load time 308 depends on the FIB hardware and design and not the routing protocol 309 choice. 311 [According to Gredler, "today, 1000-2000 routers in a single area are 312 said to represent the upper boundary of IS-IS [...] The authors do 313 not endorse these optimistic area numbers, since a lot is dependent 314 on other factors than just the raw number of routers." (p. 84). And 315 I'm pretty sure he's not thinking of 200MHz CPUs with 8kB data 316 caches, 802.11 and powerline. -- jch] 318 We easily should expect sub-second convergence for any change in 319 reachability (addition or subtraction) in any conceivable Homenet 320 deployment that does not use IEEE 802.11 for router-to-router links 321 (see Section 16). 323 4.2. Babel 325 Since Babel maintains a redundant routing table, it is most often 326 able to reconverge almost instantaneously after a link failure (this 327 is similar to e.g. EIGRP). In the case where no feasible routes are 328 available, Babel reconverges in 20ms per hop to the source. 330 4.3. Discussion 332 Both protocols enjoy fast convergence. However, the time needed to 333 reconverge is dwarfed by the amount of time needed to detect a link 334 failure, which is the hold time in IS-IS (30s by default), and 2.5 335 hello intervals on Babel wired links (2.5*4s, i.e. 10s by default). 336 (Babel performs link quality estimation on wireless links, so the 337 delay is a little higher when wireless links are involved.) 339 This can be mitigated somewhat by using smaller timers, at the cost 340 of higher overhead, especially on wireless links, which tend to 341 suffer from abominable per-frame overhead. IS-IS supports hold times 342 as small as 1s, while Babel supports hello intervals as low as 10ms 343 (leading to a 25ms hold time). (Either protocol could of course be 344 combined with BFD, which supports arbitrarily small hold times.) 346 It has been suggested that physical layer carrier sense could be used 347 to detect broken links in a timely manner. Unfortunately, this 348 technique is not useful in Homenet, since most Plastic Home Routers 349 put their Ethernet ports behind an internal switch in order to 350 provide 5 or more Ethernet ports using a single NIC: carrier sense 351 indicates the status of the internal link to the switch, not that of 352 the user-visible Ethernet link. Carrier sense has also been found to 353 be unreliable on wireless links. 355 5. Autoconfiguration 357 Most home networks are not administered, so a routing protocol needs 358 to be entirely self-configuring in order to be suitable for Homenets. 360 5.1. IS-IS 362 The only required configuration for IS-IS is a unique area/system 363 identifier. The Homenet implementation of IS-IS uses an 364 autoconfiguration extension defined in an Internet Draft 365 [ISIS-AUTOCONF], to set this value. 367 5.2. Babel 369 Babel is a fully self-configuring protocol -- the standard 370 implementation of Babel only requires a list of interfaces in order 371 to start routing. 373 5.3. Discussion 375 When combined with HNCP, both protocols are able to run in an 376 unadministered network (but see also Section 7). 378 6. Support for Source-Specific Routing 380 Source-Specific Routing is a hard requirement for Homenets, as it 381 will allow traffic to be routed to the correct outbound network based 382 on host source address selection. Routing packets to the wrong 383 outbound network could result in packets being dropped due to ISP 384 ingress filtering rules. 386 Both Babel and IS-IS have extensions for source-specific routing. 388 6.1. Source-Specific Routing in IS-IS 390 IS-IS support for source specific routing is implemented with the 391 addition of a sub-TLV to a reachability (prefix) TLV. The 392 implementation assumes that all IS-IS routers have support for the 393 sub-TLV. This assumption is safe to make due to the requirement that 394 all homenet IS-IS routers also use a homenet specific area ID and 395 cleartext password. Mixing in IS-IS routers without support for 396 source specific routing is not supported as it may cause routing 397 loops. 399 6.2. Source-Specific Routing in Babel 401 The Source-specific extension to the Babel routing protocol 402 [BABEL-SS] has been implemented for over a year, has been made widely 403 available and has seen a fair amount deployment as part of OpenWRT 404 and CeroWRT. The source-specific code is currently in the process of 405 being merged into the standard Babel implementation, and is scheduled 406 to be included in version 1.6 (planned for March 2015). 408 Babel's source-specific extensions were carefully designed so that 409 source-specific and ordinary (non-specific) routers can coexist in a 410 single routing domain, without causing routing loops. However, 411 unless there is a connected backbone of source-specific routers, any 412 non-specific routers present in the Homenet may experience 413 blackholes. Interoperability between plain Babel and Source-Specific 414 Babel is described in detail in Section VI.A of [SS-ROUTING]. 416 6.3. Discussion 418 Both protocols have been extended with support for source-specific 419 routing. The IS-IS extension is not able to coexist with non- 420 extended implementations, but this is probably not a serious problem 421 for Homenet. 423 7. Support for Link Metrics 425 Typical Homenets are built out of multiple link technologies with 426 very different performance characteristics -- Gigabit Ethernet can 427 easily have three orders of magnitude higher throughput than a 428 marginal wireless link. Both IS-IS and Babel model the notion of 429 greater or lesser desirability of a link by a value called a metric; 430 the smaller the metric, the more desirable the link. 432 The following example illustrates the importance of assigning 433 suitable metrics to links in a home network: 435 Internet --- A --- B....C --- is Ethernet 436 . . ... is WiFi 437 ........ 439 A is the CPE (edge router), and lives in a storeroom. B is the 440 home's main router, lives in the living room, and is connected to A 441 over Ethernet. C is a wireless router in the guest room, or perhaps 442 in the garden shed. All the routers are equipped with wireless 443 interfaces. 445 Suppose that the wireless link B..C is solid, but the longer A..C 446 link has very high packet loss. Murphy's law dictates that the link 447 A..C will be just good enough for the routing instances on A and C to 448 become neighbours. If the routing protocol doesn't take link quality 449 into account in its metric computation, even if it is smart enough to 450 prefer wired links to wireless ones, it will prefer the lossy route 451 A..C to the solid route A-B..C. 453 7.1. Link Metrics in IS-IS 455 The Homenet implementation of IS-IS uses the wide-metric (24-bit) 456 link metric. Additionally IS-IS includes multi-topology support 457 allowing for a variable number of metrics per link, as well as per- 458 link and per-prefix tags allowing for coloring of links and 459 reachability, and finally per-link and per-prefix sub-tlv's allowing 460 for any future additional extensions. 462 7.2. Link Metrics in Babel 464 Since Babel was originally designed for heterogeneous networks, the 465 protocol is able to automatically include a number of sources of 466 information in its metric computation. The current implementation is 467 able to automatically take the following criteria into account: 469 o whether a link is wired or wireless; 470 o packet loss; 472 o link latency [BABEL-RTT]; 474 o intra-route radio interference [BABEL-Z]. 476 This wealth of information can produce conflicting data in edge 477 cases. Babel's loop-avoidance mechanisms ensure that the network 478 remains in a consistent state in all cases, and a hysteresis 479 mechanism ensures that, should a feedback loop occur, the frequency 480 of oscillations remains bounded [DELAY-BASED]. 482 7.3. Discussion 484 Babel has reasonably good support for dynamically computed metrics 485 for IEEE 802.11 links and high-latency tunnels. The current 486 implementation doesn't have explicit support for variable-speed 487 Ethernet and Powerline Ethernet, both technologies are bundled into a 488 single "good quality link" category. 490 Current implementations of IS-IS will supply a default metric for 491 links if not configured. We are unaware of any implementation that 492 computes this default metric dynamically, rather it is static and 493 supplied by the vendor. While support for dynamically computed 494 metrics could potentially be added to IS-IS, this is not completely 495 trivial to do right, since a naive approach would cause unacceptable 496 churn, potentially leading to repeated SPF computations and transient 497 microloops. Suitable mitigation techniques could probably be 498 developed, but they would likely be different from the mitigation 499 techniques that work well in Babel, since the link-state algorithm 500 used by IS-IS and the triggered updates used by Babel have 501 fundamentally different dynamics. 503 8. Support for Stub Networks and Stub Routers 505 A stub network is one that is attached to a Homenet, possibly through 506 multiple Homenet routers, but must not be used for transit. In the 507 following example, if the dotted link between C and D is a stub 508 network, then it must not be used for transit even if the link 509 between A and B fails: 511 ---- A ----- B ----- 512 | | 513 | | 514 C ..... D 516 Similarly a stub router is a router which may advertise and be a 517 destination for stub networks but should never be used for transit 518 traffic. 520 A number of people have expressed interest in attaching sensor class 521 equipment to Homenets, such as smart thermostats and home automation 522 hardware. Presumably, the sensor-class devices will run over a 523 dedicated low-power link (e.g. IEEE 802.15.4), with a small number 524 of devices acting as gateways between the homenet and the low power 525 network. Ideally, the gateway nodes would not be dedicated devices, 526 but merely sensor nodes that happen to have been equipped with an 527 Ethernet or WiFi interface. 529 Since low power links have orders of magnitude lower throughput than 530 Homenet links, routing Homenet traffic through the low power link 531 would cause it to collapse. Designating this link as a stub network 532 avoids this issue. 534 8.1. IS-IS Support for Stub Networks and Stub Routers 536 In IS-IS reachability (prefixes) and topology (links/adjacencies) are 537 separate things. IS-IS supports stub-networks as defined above 538 simply by advertising the prefix associated with a link, but not the 539 link itself. This is sometimes referred to as a "passive link". 541 Further an IS-IS router has the ability to set a bit (the overload 542 bit) to indicate that it should not be used for any transit traffic, 543 and that it will only be considered a destination for the prefixes it 544 has advertised, i.e., it is a stub router as defined above. As per 545 the IS-IS standard [ISO10589] an IS-IS router marked as such is not 546 expected to participate in the propagation of link state or the SPF 547 computation. 549 8.2. Babel Support for Stub Networks 551 As all distance vector protocols, Babel supports fairly arbitrary 552 route filtering. Designating a stub network is done with two 553 statements in the current implementation's filtering language. 555 For resource-limited deployments, a minimalistic, stub-only 556 implementation of Babel is available that consists of less than 1000 557 lines of C code that compile to a dozen kilobytes of text. Just like 558 the standard implementation, the stub implementation is mostly 559 portable code, and should be easily ported to any embedded 560 environment that supports the "sockets" API. 562 8.3. Discussion 564 A tiny, stub-only implementation of Babel is available. 566 A tiny, stub-router-only implementation of IS-IS is available. This 567 is the "tinyisis" referred to later in the document when comparing 568 implementation sizes. 570 9. Support for non-IEEE 802.2 link layers 572 Most link technologies employed in a Homenet use the IEEE 802.2 frame 573 format; this is notably the case of Ethernet, IEEE 802.11 and common 574 powerline technologies. However, other framing formats exist, and at 575 least PPP, PPPoE, IEEE 802.15.4, GRE and various VPN technologies are 576 likely to be used in Homenets. 578 9.1. IS-IS 580 IS-IS is built directly above the link layer (IS-IS control data is 581 not encapsulated within IP packets), and therefore needs explicit 582 support for every type of lower layer encapsulation. It is not known 583 what particular kinds of framing the Homenet implementation of IS-IS 584 supports. 586 9.2. Babel 588 Babel is built above UDP over link-local IPv6, and is able to run 589 with no modifications over any link that supports IPv6. 591 10. Security Features 593 10.1. Security Features in IS-IS 595 IS-IS offers multiple levels of security from none, to simple clear- 596 text (password) authentication, to fully generic cryptographic 597 authentication using any number of hashing algorithms [RFC5304]. 598 Currently, the Homenet implementation of IS-IS uses the cleartext 599 password set to a predefined value for auto-configuration purposes. 601 10.2. Security Features in Babel 603 Babel supports symmetric key authentication using an extensible HMAC- 604 based cryptographic authentication mechanism [RFC7298]. This 605 mechanism is not vulnerable to replay attacks. 607 10.3. Discussion 609 Both protocols support password authentication. This probably 610 provides the necessary hooks for the Homenet Configuration Protocol 611 (HNCP) to implement whatever security policies are required by 612 Homenet. 614 11. Support for Multicast 616 Although the Homenet WG has not yet determined whether to support 617 multicast in Homenet Networks, it might be desirable to pick a 618 routing protocol that supports multicast, so that it will be easier 619 to add multicast support in the future. 621 11.1. Multicast Routing in IS-IS 623 The IS-IS protocol supports multicast routing. However, none of the 624 available implementations include support for multicast. 626 11.2. Multicast Routing in Babel 628 There is no support for multicast routing in Babel. 630 11.3. Discussion 632 Some experts believe that it may be better to run a dedicated 633 multicast routing protocol rather than extensions to a unicast 634 routing protocol. 636 12. Implementation Status 638 There are Homenet implementations of both IS-IS and Babel. 640 The Homenet implementation of IS-IS is the only IS-IS implementation 641 that supports source-specific routing, which is a hard requirement 642 for Homenet. If source-specific routing is not required, there are 643 several independent, interoperable proprietary implementations of IS- 644 IS (all major router vendors implement IS-IS). We are not aware of 645 any production-quality open-source implementation of IS-IS other than 646 the Homenet one. 648 There are multiple open source implementations of Babel, two of which 649 support source-specific routing. All implementations (except the 650 stub-only version) were originally derived from the same codebase. 652 13. Code and State Size 654 13.1. IS-IS Code and State Size 656 The Homenet implementation of IS-IS consists of 7000 lines of Erlang 657 code and has an installed size of over 11MB. Its initial memory 658 usage (as reported by the operating system) is 22MB, and its working 659 set increases by XXX bytes for each new edge in the network graph. 660 To put these numbers into perspective, in a network with XXX nodes 661 each of which has XXX neighbours, the Homenet implementation of IS-IS 662 requires XXX bytes for its data structures. 664 The code size of IS-IS depends greatly on what aspects of the 665 protocol have been implemented. IS-IS supports multiple address 666 families as well as completely different protocol stacks (OSI and 667 IP), multiple area hierachical operation with automatic virtual link 668 support for repairing area partitions, and multiple link types. 669 Additionally many other protocol features have been added over time 670 to augment the protocol or replace previous behavior. The protocol 671 lends itself well to not only extension, but pairing down of 672 features. 674 For Homenet we need a level-1 only implementation supporting a common 675 topology for IPv4 and IPv6 over broadcast (i.e., ethernet) link 676 types. Additionally, we only require support of the latest extended 677 metric TLVs (i.e., not implement legacy metric support). 679 [Does that mean that we don't care about PPP, PPPeE, GRE etc?] 681 The operational state required by IS-IS is proportional to the number 682 of routers, links, and prefixes in the network. Each router in the 683 network generates and advertises a Link State Protocol Data Unit 684 (LSP) that describes it's attached links and prefixes. A copy of 685 each of these LSPs is stored by each router in the network. IS-IS 686 uses these LSPs to construct a shortest-path-first (SPF) tree with 687 attached prefix information from which routes to the prefixes are 688 created. 690 Concrete numbers lacking. 692 13.2. Babel Code and State Size 694 The source-specific implementation of Babel, which implements many 695 non-Homenet extensions to the protocol, consists of roughly 10000 696 lines of C and has an installed size of less than 130kB on AMD-64. 697 Its initial memory usage (as reported by the operating system) is 698 300kB. 700 The amount of state stored by a Babel router is at worst one routing 701 table entry for each destination through each neighbour. In the 702 source-specific implementation, one routing entry occupies roughly 703 100 bytes of memory. To put these figures into perspective, in a 704 network with 1000 nodes, a Babel router with 10 neighbours needs 705 roughly a megabyte of memory to store its routing table (not counting 706 malloc overhead). 708 The stub-only implementation of Babel consists of 900 lines of C and 709 compiles to 13kB (dynamically linked). Its memory usage (as reported 710 by the operating system) is 200kB, and remains constant (it doesn't 711 perform any dynamic memory allocation). 713 The stub-only implementation of IS-IS consists of 1300 lines of C and 714 compiles to 18kB (stripped and dynamically linked). Its base memory 715 usage (as reported by 32-bit linux) is 330kB. 717 13.3. Comparison 719 Table 1 summarises the sizes of the available Homenet routing 720 protocol implementations. (Babel data courtesy of Steven Barth and 721 Markus Stenberg.) 723 +------------+------------+------------+---------------+------------+ 724 | | babeld | sbabeld | AutoISIS (SS) | tinyisis | 725 | | (SS) | (stub) | | (stub) | 726 +------------+------------+------------+---------------+------------+ 727 | Version | 2598774 | cc7d681 | [update]0.8.0 | 3ed2068 | 728 | Date | 2014-09-08 | 2014-11-21 | 2014-08-26 | 2015-02-22 | 729 | License | MIT | MIT | Apache 2.0 | Apache 2.0 | 730 | Lines of | 10000 (C) | 1000 (C) | 7000 (Erlang) | 1300 (C) | 731 | Code | | | | | 732 | Installed | 129kB | 13kB | 732kB | 17kB | 733 | size | | | | | 734 | (AMD64) | | | | | 735 | Total | 129kB | 13kB | 7MB | 17kB | 736 | installed | | | | | 737 | size | | | | | 738 | Baseline | ~300kB | ~200kB | 11MB | 330kB | 739 | RSS | | | | | 740 +------------+------------+------------+---------------+------------+ 742 Table 1: Comparison of Homenet implementation size 744 In this table, "Installed size" is the size reported by the package 745 manager for the routing daemon's package(s), while "Total installed 746 size" is the sum of the size of the deamon's packages and all its 747 dependencies, excluding the C library. 749 The erlang AutoISIS has not been optimized for space or features 750 (i.e., it is a full IS-IS multilevel multi-address family 751 implementation). One example of how this affects the reported 752 numbers, is that the erlang logging package is taking up 4MB of ram. 754 Additionally, as erlang is interpreted and not compiled as with the C 755 implementations, there's not much use in directly comparing the 756 numbers themselves. 758 [We should add the size of the native Quagga isisd. While this 759 implementation is incomplete and doesn't support the Homenet 760 extensions, it should give us an idea how much we can hope to scale 761 IS-IS down. It's roughly 20000 lines of C, not counting the 762 additional 20000 for zebra. -- jch] 764 14. Ease of porting 766 If successful, the Homenet protocols will be implemented on exotic 767 devices, such as sensor-class devices, set-top boxes and mobile 768 phones. Rather than a full Unix system, such devices sometimes 769 provide a more exotic environment, such as an embedded operating 770 system or one designed for mobile phones. 772 14.1. IS-IS ease of porting 774 As IS-IS runs directly over layer 2, an implementation needs to be 775 able to send and receive layer 2 frames itself. On Unix systems, 776 this can be done using raw sockets or by hooking into the Berkeley 777 Packet Filter. Such interfaces might not be available on non-Unix 778 systems, and even on Unix are restricted to priviledged processes. 780 14.2. Babel ease of porting 782 Babel is layered above UDP. Except for a thin layer interfacing to 783 the kernel, the reference implementation of Babel consists of 784 portable code using the familiar "sockets" API (RFC 3493). Enabling 785 forwarding and manipulating the kernel's routing tables is the only 786 priviledged operation it performs. 788 Babel has been successfully ported to Android. Android does not 789 currently allow unpriviledged code to manipulate the kernel's routing 790 table, so Babel can only run on "rooted" phones. Should a future 791 version of Android provide the ability to manipulate the kernel's 792 routing table, Babel could conceivably be packaged as an installable 793 "app". 795 14.3. Discussion 797 IS-IS is somewhat difficult to port, due to the requirement for raw 798 sockets. Except for the requirement to install routes, Babel is 799 portable code, and has been successfully ported to Android. 801 15. Behaviour upon resource exhaustion 803 15.1. IS-IS 805 The IS-IS protocol has an overload indicator. When the protocol is 806 unable to acquire a needed resource, it enters overloaded state. 807 This state is signaled to the other routers and the overloaded router 808 is considered to be destination only (i.e., it becomes a stub 809 router). 811 15.2. Babel 813 Babel degrades gracefully. Since Babel is a distance-vector 814 protocol, a Babel implementation can simply drop excess routes when 815 it runs out of memory. As long as the default route is not 816 discarded, connectivity will be degraded but not completely lost. 818 The current implementation of Babel discards redundant routes before 819 it starts dropping announcements, but doesn't yet prioritise the 820 default route. (This behaviour was tested when somebody 821 redistributed the entire IPv6 default-free zone into a Babel network. 822 We had a lot of fun that day.) 824 16. Performance and scaling on IEEE 802.11 Wireless Networks 826 We expect wireless networks, and notably IEEE 802.11 wireless 827 networks, to be in wide use in Homenets, not only for client 828 connections but also for router-to-router connections. In fact, some 829 of us believe that the ability to cheaply and easily extend wireless 830 coverage by adding a wireless router is a "killer feature" of 831 Homenet, one that is easy to explain both to one's boss and to end 832 users. 834 IEEE 802.11 has some rather unpleasant performance characteristics. 835 First, wireless links are of very variable quality. Second, 836 multicast traffic is sent at a lowest common denominator speed, 837 typically 2Mbit/s, which makes multicast outrageously expensive (13ms 838 for a full-size frame). Third, multicast traffic is not protected by 839 link-layer ARQ, which makes multicast packet drops very common, 840 especially in the presence of collisions, which are particularly 841 likely when the routing protocol is in the process of reconverging. 843 This has some consequences for routing protocols: 845 o the routing protocol must be able to deal with varying link 846 qualities (see Section 7); 848 o if the routing protocol uses multicast for transmitting control 849 data, it must deal gracefully with packet loss during 850 reconvergence; 852 o the routing protocol must avoid sending large bursts of multicast 853 traffic from multiple nodes simultaneously during reconvergence. 855 IEEE 802.11 has two main modes of operation. In "infrastructure 856 mode", a small number of "access points" (APs), often just one, 857 communicate with a number of "stations" (STAs); communication between 858 two stations transits through one or at most two APs. In "IBSS mode" 859 (also called "ad hoc mode"), communication is unrestricted, and any 860 node can directly communicate with any other node in range; as there 861 is no link-layer forwarding, IBSS mode does not guarantee that 862 communication is transitive. Virtually all home network deployments 863 today use infrastructure mode, with the router acting as AP and 864 client devices acting as stations. We believe that IBSS may be out 865 of scope for Homenet, but we expect that people will attempt to use 866 the Homenet protocols in IBSS mode, whether we like it or not. 868 16.1. IS-IS Performance on 802.11 870 IS-IS is in active use in in the Internet in large non-hierachical 871 (i.e., level-2 or single area level-1) deployments with hundreds of 872 nodes. The protocol has proven to be very scalable. 874 We are not aware of any results in the open litterature about the 875 behaviour of IS-IS over IEEE 802.11. In particular, we do not know 876 how IS-IS's reliable flooding mechanism behaves over IEEE 802.11. 878 16.2. Babel Performance on 802.11 880 Babel has been carefully optimised for IEEE 802.11 networks. While 881 Babel transmits most control data over multicast, it applies large 882 amounts of random jitter (on the order of seconds) to all but its 883 most urgent control messages. Roughly speaking, Babel sends in a 884 timely manner those control messages that are likely to repair a 885 broken route, but delays sending those messages that merely announce 886 a slightly better route than one that is already available. This 887 mechanism has been shown to work well in dense wireless deployments, 888 with recent versions of Babel being able to avoid link-layer 889 meltdowns even when a whole network is being rebooted simultaneously. 891 As explained in Section 7, Babel performs link quality estimation on 892 wireless links in a manner that works relatively well with the 802.11 893 MAC. In addition, Babel has provisions for estimating radio 894 interference [BABEL-Z], which is necessary in order to provide decent 895 throughput on multi-hop radio routes. 897 Babel has been designed to work well in IBSS mode, where 898 communication is not transitive and therefore a packet may be routed 899 through the same interface it was received on. 901 16.3. Discussion 903 Babel has been designed with wireless networks in mind, and has been 904 shown to work reasonably well even in the extremely hostile 905 environment of wireless mesh networks built over IEEE 802.11 in IBSS 906 ("ad hoc") mode. 908 We are not aware of any results about the behaviour of IS-IS's 909 reliable flooding sub-protocol over IEEE 802.11 multicast. IS-IS 910 will not work over IEEE 802.11 IBSS mode without changes, since both 911 the pseudonode optimisation and DIS election assume that 912 communication is transitive. 914 17. Standardization Status 916 17.1. IS-IS Standardization 918 IS-IS is an ISO Standard documented in ISO/IEC 10589:2002 [ISO10589] 919 There is an active IETF IS-IS Working Group (isis-wg) that maintains 920 and extends the IS-IS protocol, and the IS-IS protocol has been 921 extended in several IS-IS Working Group documents. 923 The autoconfiguration and source-specific extensions to IS-IS, which 924 are both hard requirements for Homenet, are documented in (non-WG) 925 Internet Drafts [ISIS-AUTOCONF] [ISIS-SS]. 927 17.2. Babel Standardization Status 929 Babel is documented in an Experimental RFC (RFC 6126) published in 930 2011, and it has been updated in several individual-submission RFCs 931 and Internet Drafts. An Internet Draft establishing an IANA registry 932 of Babel extensions has been submitted for publication as an RFC 933 [BABEL-EXT]. 935 The use of Babel in a Standards Track Homenet RFC would require a 936 "downref" to non-Standards Track documents. It would also be 937 necessary to finish publishing the extensions that are needed for the 938 Homenet use case as RFCs. 940 18. Evaluation of RFC 7368 Criteria 942 Section 3.5 of [RFC7368] lists a set of criteria that the Homenet 943 routing protocol must satisfy. 945 o border discovery: out of scope, as this is done by HNCP. 947 o self configuring: both protocols are self-configuring, see 948 Section 5. 950 o behaviour during reconfiguration and reconvergence: 952 * both protocols are able to establish adjacencies and to route 953 IPv6 before they even receive an IPv6 address due to their use 954 of stable neighbour identifiers; 956 * Babel will avoid creating loops even during reconvergence, but 957 might create temporary blackholes; 959 * IS-IS may create short-lived loops during reconvergence; 961 * since HNCP doesn't depend on unicast, in principle it is not 962 impacted by the routing protocol's behaviour during 963 reconvergence; however, on a wireless network, the interference 964 caused by routing loops may delay HNCP's reconvergence. 966 o the Homenet routing protocol should be based on a previously 967 deployed protocol: 969 * IS-IS is more widely deployed in carrier networks, 971 * there is more experience with running Babel on Plastic Home 972 Routers 974 * Only the Babel implementation of source-specific routing has 975 seen any deployment. 977 o support for IPv4: both protocols are intrinsically double-stack -- 978 a single routing instance is able to carry both IPv6 and IPv4. 980 o multiple types of physical interfaces must be accounted for: only 981 Babel is able to differentiate between different link 982 technologies, see Section 7; nothing is known about IS-IS's 983 behaviour on wireless links. 985 o minimising convergence time: both protocols converge fast, see 986 Section 4. 988 o support the generic use of multiple Internet connections: both 989 protocols support source-specific routing, see Section 6. 991 o scalable to higher hop counts: both protocols have reasonably wide 992 metrics (24 bits in IS-IS, 16 bits in Babel). 994 o support for attached LLNs and other non-transit networks: both 995 protocols are able to designate a link as non-transit. Tiny stub 996 implementations of Babel and IS-IS are available. See Section 8. 998 o support for Multicast: IS-IS is able to carry multicast routes, 999 Babel is not. 1001 19. Evaluation of RFC 5218 Criteria 1003 19.1. Critical Success Factors 1005 Does the protocol exhibit one or more of the critical initial success 1006 factors as defined in RFC 5218? 1008 19.1.1. IS-IS Success Factors 1010 IS-IS exhibits the following critical initial success factors: 1012 o Positive Net Value: 1014 * Hardware cost: None. 1016 * Operational interface: Existing and extensive. 1018 * Retraining: None. 1020 * Business dependencies: None. 1022 o Incremental Deployment: Yes. 1024 o Open Code Availability: Yes. One implementation of the Homenet 1025 extensions, multiple proprietary implementations of the base 1026 protocol. 1028 o Freedom from Usage Restrictions: Yes. 1030 o Open Specification Availability: Yes. 1032 o Open Maintenance Processes: Yes. 1034 o Good Technical Design: Proven with extensive deployment and 1035 experience with the base protocol, little deployment of the 1036 Homenet extensions. 1038 o Extensible: Yes. 1040 o No Hard Scalability bound: Yes. 1042 o Threats Sufficiently Mitigated: Yes. 1044 19.1.2. Babel Success Factors 1046 Babel exhibits the following critical initial success factors: 1048 o Positive Net Value: 1050 * Hardware cost: None. 1052 * Operational interface: tcpdump and wireshark support, dedicated 1053 monitoring software. 1055 * Retraining: None. 1057 * Business dependencies: None. 1059 o Incremental Deployment: Yes. 1061 o Open Code Availability: Yes. Multiple implementations derived 1062 from a common source. 1064 o Freedom from Usage Restrictions: Yes. 1066 o Open Specification Availability: Yes. 1068 o Open Maintenance Processes: IANA registry in the process of being 1069 created. 1071 o Good Technical Design: Yes. 1073 o Extensible: Yes. 1075 o No Hard Scalability bound: Yes. 1077 o Threats Sufficiently Mitigated: probably. 1079 19.2. Willing Implementors 1081 Are there implementers who are ready to implement the technology in 1082 ways that are likely to be deployed? 1084 19.2.1. IS-IS 1086 There is only one implementation of autoconfiguration and source- 1087 specific routing for IS-IS. There are some other open source 1088 implementations of the base protocol, but they are incomplete (as of 1089 February 2015). 1091 As all major routing vendors have (proprietary) IS-IS 1092 implementations, the barrier for implmeneting IS-IS for Homenet use 1093 is probably manageable, assuming that the willingness to implement 1094 modifications needed for Homenet use is present. 1096 19.2.2. Babel 1098 The Babel implementation is open source software (MIT licensed), and 1099 the codebase has proven of sufficiently high quality to be easily 1100 extended by people who were not in direct contact with the author 1101 [RFC7298]. 1103 With the exception of a small number of functions used for 1104 interfacing with the kernel's routing tables, Babel is portable code, 1105 and is easily ported to any environment that supports the familiar 1106 "sockets" API. 1108 19.3. Willing Customers 1110 Are there customers (especially high-profile customers) who are ready 1111 to deploy the technology? 1113 19.3.1. IS-IS 1115 Yes. IS-IS is already widely deployed in operational networks. 1117 19.3.2. Babel 1119 Source-Specific Babel is currently deployed as part of the OpenWRT 1120 and CeroWRT operating systems. Additionally, the current version is 1121 used as a testbed for the Homenet configuration protocol. 1123 19.4. Potential Niches 1125 Are there potential niches where the technology is compelling? 1127 19.4.1. IS-IS 1129 [TBD] 1131 19.4.2. Babel 1133 Babel is a simple and flexible routing protocol. Like most distance- 1134 vector protocols, it requires little to no configuration in most 1135 topologies, and has proved popular in scenarios where competent 1136 network administration was not available. In addition, it has been 1137 shown to be particularly useful in scenarios where non-standard 1138 dynamically computed metrics are beneficial, notably wireless mesh 1139 networks and overlay networks. 1141 19.5. Complexity Removal 1143 If so, can complexity be removed to reduce cost? 1145 19.5.1. IS-IS 1147 As mentioned previously IS-IS can be significantly and easily pared 1148 down to fit the more limited scope of homenet use. However, no such 1149 pared down implementation exists, and the subset of the protocol that 1150 needs to be implemented has never been formally defined. 1152 19.5.2. Babel 1154 Babel is a fairly simple protocol -- RFC 6126 is just 40 pages long 1155 (not counting informative appendices), and it has been successfully 1156 explained to fourth year university students in less than two hours. 1158 The stub-only implementation of Babel consists of 900 lines of C 1159 code, and has deliberately been kept as simple as possible. We 1160 expect a competent engineer to get up to speed with it within hours. 1162 19.6. Killer App 1164 Is there a potential killer app? Or can the technology work 1165 underneath existing unmodified applications? 1167 19.6.1. IS-IS 1169 As IS-IS already qualifies as successful (bordering on wildly) a 1170 killer app is not particularly relevant. 1172 19.6.2. Babel 1174 Since Babel requires virtually no configuration, it is particularly 1175 suitable to scenarios where a dedicated network administrator is not 1176 available. Additionally, its support for dynamically computed non- 1177 standard metrics makes it particularly appealing in highly 1178 heterogeneous networks, (networks built on multiple link-layer 1179 technologies with widely varying performance characteristics). 1181 19.7. Extensible 1183 Is the protocol sufficiently extensible to allow potential 1184 deficiencies to be addressed in the future? 1186 19.7.1. IS-IS 1188 IS-IS has been shown to be incredibly extensible, originally designed 1189 for a completely different protocol stack (OSI) it was easily adapted 1190 for IP use, then to multiple address families (IPv4, IPv6) and multi- 1191 topology. Indeed one of the major drivers of IS-IS's success is its 1192 extensibility and adaptability. 1194 19.7.2. Babel 1196 The extension mechanisms built into the Babel protocol [BABEL-EXT] 1197 have been used to build a number of extensions, including one that 1198 significantly extends the structure of announcements [BABEL-SS] and 1199 one that needs a non-trivial extension to the space of metrics 1200 [BABEL-Z]. 1202 All Babel extensions that have been defined interoperate with the 1203 original protocol, as defined in RFC 6126, to the extent possible. 1204 For example, a router that doesn't implement the radio interference 1205 extension will just ignore the frequency information attached to 1206 route updates, which may lead to slightly sub-optimal routing but 1207 will cause neither blackholes nor routing loops. To the contrary, a 1208 router that doesn't support the source-specific extensions will 1209 silently ignore any source-specific update, and therefore route 1210 according to the non-specific subset of available routes, which might 1211 cause blackholes, but under no circumstances will cause routing 1212 loops. Backwards compatibility provisions are described in Section 4 1213 of [BABEL-EXT]. 1215 19.8. Success Predictable 1217 If it is not known whether the protocol will be successful, should 1218 the market decide first? Or should the IETF work on multiple 1219 alternatives and let the market decide among them? Are there factors 1220 listed in this document that may predict which is more likely to 1221 succeed? 1223 19.8.1. IS-IS 1225 For IS-IS the market has already decided that the protocol is 1226 successful in a fairly wide variety of deployments. 1228 19.8.2. Babel 1230 Plain (non-source-specific) Babel has seen a modest amount of 1231 deployment, most notably for routing over wireless mesh networks and 1232 intercontinental overlay networks. Babel is included as an 1233 installable package in many Linux distributions, which makes it 1234 easily available to interested parties. 1236 Source-specific Babel is probably the only source-specific routing 1237 protocol that has seen any deployment. Source-specific Babel is 1238 available as an installable package for OpenWRT, and is used by 1239 default by CeroWRT. 1241 20. Acknowledgments 1243 The authors are grateful for the input of Steven Barth, Denis 1244 Ovsienko, Mark Townsley, and Curtis Villamizar. 1246 21. Informative References 1248 [BABEL-EXT] 1249 Chroboczek, J., "Extension Mechanism for the Babel Routing 1250 Protocol", draft-chroboczek-babel-extension-mechanism-03 1251 (work in progress), June 2013. 1253 [BABEL-RTT] 1254 Jonglez, B. and J. Chroboczek, "Delay-based Metric 1255 Extension for the Babel Routing Protocol", Internet Draft 1256 draft-jonglez-babel-rtt-extension-00, July 2014. 1258 [BABEL-SS] 1259 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 1260 Babel", draft-boutier-babel-source-specific-00 (work in 1261 progress), November 2014. 1263 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 1264 Protocol", draft-chroboczek-babel-diversity-routing-00 1265 (work in progress), July 2014. 1267 [DELAY-BASED] 1268 Jonglez, B. and M. Boutier, "A delay-based routing 1269 metric", March 2014, . 1271 [ISIS-AUTOCONF] 1272 Liu, B., "ISIS Auto-Configuration", draft-liu-isis-auto- 1273 conf-03 (work in progress), October 2014. 1275 [ISIS-SS] Baker, F. and D. Lamparter, "IPv6 Source/Destination 1276 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 1277 routing-02 (work in progress), October 2014. 1279 [ISO10589] 1280 ISO/IEC, "Intermediate system to Intermediate system 1281 intra-domain routeing information exchange protocol for 1282 use in conjunction with the protocol for providing the 1283 connectionless-mode Network Service (ISO 8473) Second 1284 Edition", Novmeber 2002. 1286 ISO 10589:2002 Second Edition 1288 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1289 dual environments", RFC 1195, December 1990. 1291 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1292 Authentication", RFC 5304, October 2008. 1294 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1295 Engineering", RFC 5305, October 2008. 1297 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1298 2008. 1300 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 1301 April 2011. 1303 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 1304 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 1306 [RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1307 "IPv6 Home Networking Architecture Principles", RFC 7368, 1308 October 2014. 1310 [SS-ROUTING] 1311 Boutier, M. and J. Chroboczek, "Source-sensitive routing", 1312 December 2014, . 1314 Authors' Addresses 1316 Margaret Wasserman 1317 Painless Security 1318 356 Abbott Street 1319 North Andover, MA 01845 1320 USA 1322 Phone: +1 781 405-7464 1323 Email: mrw@painless-security.com 1324 URI: http://www.painless-security.com 1326 Christian E. Hopps 1327 Deutsche Telekom 1329 Email: chopps@chopps.org 1331 Juliusz Chroboczek 1332 University of Paris-Diderot (Paris 7) 1334 Email: jch@pps.univ-paris-diderot.fr