idnits 2.17.00 (12 Aug 2021) /tmp/idnits21449/draft-mrw-homenet-rtg-comparison-01.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 (February 15, 2015) is 2651 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-chroboczek-babel-extension-mechanism has been published as RFC 7557 == 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 1142 (Obsoleted by RFC 7142) -- 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 (~~), 6 warnings (==), 4 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: August 19, 2015 Deutsche Telekom 6 J. Chroboczek 7 University of Paris-Diderot (Paris 7) 8 February 15, 2015 10 HOMENET IS-IS and Babel Comparison 11 draft-mrw-homenet-rtg-comparison-01.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 August 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocols and Extensions Included in Comparison . . . . . . . 4 58 2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 5 59 2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 5 60 3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 5 62 3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) . . . . . 6 63 3.3. Algorithm Comparison . . . . . . . . . . . . . . . . . . 6 64 4. Convergence Times . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Support for Source-Specific Routing . . . . . . . . . . . . . 8 73 6.1. Source-Specific Routing in IS-IS . . . . . . . . . . . . 8 74 6.2. Source-Specific Routing in Babel . . . . . . . . . . . . 8 75 6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Support for Link Metrics . . . . . . . . . . . . . . . . . . 8 77 7.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 9 78 7.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 9 79 8. Support for Attached Stub Networks . . . . . . . . . . . . . 9 80 8.1. IS-IS Support for Stub Networks . . . . . . . . . . . . . 9 81 8.2. Babel Support for Stub Networks . . . . . . . . . . . . . 10 82 9. Security Features . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Security Features in IS-IS . . . . . . . . . . . . . . . 10 84 9.2. Security Features in Babel . . . . . . . . . . . . . . . 10 85 10. Support for Multicast . . . . . . . . . . . . . . . . . . . . 10 86 10.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 10 87 10.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 10 88 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 89 12. Code and State Size . . . . . . . . . . . . . . . . . . . . . 11 90 12.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 11 91 12.2. Babel Code and State Size . . . . . . . . . . . . . . . 12 92 12.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 12 93 13. Performance on IEEE 802.11 Wireless Networks . . . . . . . . 13 94 13.1. IS-IS Performance on 802.11 . . . . . . . . . . . . . . 13 95 13.2. Babel Performance on 802.11 . . . . . . . . . . . . . . 13 96 14. Standardization Status . . . . . . . . . . . . . . . . . . . 13 97 14.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 13 98 14.2. Babel Standardization Status . . . . . . . . . . . . . . 13 99 15. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 14 100 15.1. Critical Success Factors . . . . . . . . . . . . . . . . 14 101 15.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 14 102 15.1.2. Babel Success Factos . . . . . . . . . . . . . . . . 15 103 15.2. Willing Implementors . . . . . . . . . . . . . . . . . . 15 104 15.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 15 105 15.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16 106 15.3. Willing Customers . . . . . . . . . . . . . . . . . . . 16 107 15.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 16 108 15.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16 109 15.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 16 110 15.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 16 111 15.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16 112 15.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 16 113 15.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17 114 15.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 17 115 15.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 17 116 15.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17 117 15.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 17 118 15.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 17 119 15.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17 120 15.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 18 121 15.8. Success Predictable . . . . . . . . . . . . . . . . . . 18 122 15.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 18 123 15.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 18 124 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 125 17. Informative References . . . . . . . . . . . . . . . . . . . 18 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 128 1. Introduction 130 This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel 131 [RFC6126] according to several criteria related to their use in home 132 networks (HOMENETs), as defined by the HOMENET WG. 134 Please note that this document does not represent the consenus of any 135 group, not even the authors. It is an organized collection of facts 136 and well-informed opinions provided by experts on Babel and IS-IS 137 that may be useful to the HOMENET WG in choosing a routing protocol. 139 The HOMENET environment is different from the environment of a 140 professionally administered network. The most obvious difference is 141 that a HOMENET is not administered: any protocols used must be robust 142 and fully self-configuring, and any tuning knobs that they provide 143 will be unused in the vast majority of deployments. 145 Another difference is that HOMENETs are usually built out of a 146 specific class of cheap device, the "Plastic Home Router". A Plastic 147 Home Router's firmware is installed at the factory, and is most 148 likely never updated. Additionally, experience shows that home 149 routers are often used way beyond their warranty period, and even 150 after their manufacturer leaves the router business. This, again, 151 argues in favour of simple, robust protocols that are easy to 152 implement and can be expected to keep functioning without software 153 updates. 155 HOMENETs are built and grow organically, and often end up consisting 156 of multiple link technologies with widely different performance 157 characteristics (twisted-pair Ethernet, IEEE 802.11 and its multiple 158 variants, Powerline Ethernet, etc.). It is desirable for a HOMENET 159 routing protocol to be able to dynamically optimise paths according 160 to the link characteristics. 162 Contrary to popular perception, the Plastic Home Router is usually 163 equipped with a reasonably fast CPU and reasonable amounts of flash 164 and RAM; at the time of writing, a (non-superscalar) 700MHz MIPS CPU 165 with 16MB of flash and 64MB of RAM is typical. However, we expect 166 smaller devices to participate in the HOMENET protocols, at least as 167 stub routers. The ability to scale down the HOMENET protocols is 168 therefore likely to encourage their wider adoption. 170 [Isn't it also the case that the HOMENET routing protocol will be 171 implemented on lower-end embedded devices, such as nodes in a low- 172 power wireless network? What is considered to be a reasonable low- 173 end system requirement for a HOMENET router? -- mrw] 175 Experts appear to disagree on the expected size of a HOMENET; we have 176 heard estimates ranging from just one router up to 250 routers. In 177 any case, while scaling beyond a few thousand nodes is not likely to 178 be relevant to HOMENET in the foreseeable future, the HOMENET 179 protocols, if successful, will be repurposed to larger networks, 180 whether we like it or not, and using a protocol that scales well from 181 the outset may be desirable. 183 2. Protocols and Extensions Included in Comparison 185 Both IS-IS and Babel are living protocols that are updated and 186 extended over time. This section lists the extensions that were 187 considered in this comparison. Additional protocol extensions could 188 affect some of the information included in this document. 190 2.1. IS-IS Protocol and Extensions 192 In addition to the base IS-IS protocol specification (ISO/IEC 193 10589:2002), this comparison considers the following IS-IS 194 extensions: 196 o ISIS Auto-Configuration [ISIS-AUTOCONF]; 198 o Source-Specific routing in IS-IS [ISIS-SS]. 200 2.2. Babel Protocol and Extensions 202 In addition to the base Babel Protocol specification (RFC 6126), this 203 comparison considers the following Babel extensions: 205 o Extension Mechanism for the Babel Routing Protocol [BABEL-EXT]; 207 o Source-Specific Routing [BABEL-SS], described in more detail in 208 [SS-ROUTING]. 210 3. Routing Algorithms 212 IS-IS is a Link State routing protocol, and Babel is a Loop-Avoiding 213 Distance Vector routing protocol. There are some differences between 214 these algorithms, particularly in terms of scalability, how much 215 information is exchanged when the routing topology changes, and how 216 far topology changes are propagated. 218 3.1. Link State Algorithm 220 Link state algorithms distribute information for each node to all 221 other nodes in the network using a flooding algorithm. This database 222 of information is then used by each node to compute the best path to 223 the other nodes in the network. 225 One benefit of this algorithm is that each node contains the full 226 knowledge of the topology of the network. This information can be 227 used by other applications outside the routing protocol itself. 229 Additionally the flooding algorithm has been found as an efficient 230 method for other applications to distribute node-specific application 231 data, although some care must be taken with this use so as not to 232 disrupt the fundamental routing function. 234 3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) 236 Distance-vector algorithms distribute information about the path 237 length to reach each destination through a given neighbor. Packets 238 are forwarded to the neighbor who is advertising the best path 239 towards the destination. 241 Babel, like EIGRP, DSDV, and to a certain extent BGP, uses a loop- 242 avoiding distance-vector algorithm: it avoids creating a loop even 243 during reconvergence (there is no "counting to infinity", and even 244 short-lived "microloops" are avoided in most cases). 246 3.3. Algorithm Comparison 248 Loop-Avoiding Distance Vector scales to very large networks -- the 249 amount of state is linear in the number of nodes, and, due to the 250 absence of pathologies during reconvergence, does not need to be 251 propagated in a timely manner. It scales badly in extremely dense 252 deployments, where a single node has thousands of direct neighbours; 253 such deployments are unlikely, and clearly outside the scope of 254 HOMENET. 256 Link state algorithms scales to very large, very dense networks. 258 IS-IS distributes link and prefix information for each node in a 259 single Logical LSP (possibly fragmented). It uses these LSPs to 260 compute a tree representing the entire network. There is no 261 duplication of state based on the number of adjacencies or unique 262 paths to a given prefix. 264 4. Convergence Times 266 Convergence time is defined as the amount of time after a link 267 failure is detected during which the network is not fully 268 operational. It does not include the time necessary to detect a link 269 failure. 271 4.1. IS-IS 273 Given fast flooding of any change in the network, IS-IS has been 274 shown to acheive sub 200ms end-to-end convergence even in very large 275 provider networks (single area 900+ nodes). Basically the time for 276 convergence is the time to propagate a new LSP from one end of the 277 network to the other plus the SPF (tree computation interval) and FIB 278 loading time. The flooding is done without delay and prior to 279 running the SPF (tree-calculation) algorithm. Thus is roughly 280 proportional to propagation delay across the diameter of the network. 281 The tree calculation is sub 20ms on modern CPUs. FIB load time 282 depends on the FIB hardware and design and not the routing protocol 283 choice. 285 We easily should expect sub-second convergence for any change in 286 reachability (addition or subtraction) in any conceivable homenet 287 deployment. 289 4.2. Babel 291 Since Babel maintains a redundant routing table, it is most often 292 able to reconverge almost instantaneously after a link failure (this 293 is similar to e.g. EIGRP). In the case where no feasible routes are 294 available, Babel reconverges in 20ms per hop to the source. 296 4.3. Discussion 298 Both protocols enjoy fast convergence. However, unless there is a 299 high level of integration between the routing protocol and the link 300 layer, the time needed to reconverge is dwarfed by the amount of time 301 needed to detect a link failure, which is the hold time in IS-IS (30s 302 by default), and two hello intervals on Babel wired links (8s by 303 default). (Babel performs link quality estimation on wireless links, 304 so the delay is somewhat more difficult to quantify there.) 306 5. Autoconfiguration 308 Home networks are not administered, so a routing protocol needs to be 309 entirely self-configuring in order to be suitable for HOMENETs. 311 5.1. IS-IS 313 The only required configuration for IS-IS is a unique area/system 314 identifier. The HOMENET implementation of IS-IS uses an 315 autoconfiguration extension defined in an Internet Draft 316 [ISIS-AUTOCONF], to set this value. 318 5.2. Babel 320 Babel is a fully self-configuring protocol -- the standard 321 implementation of Babel only requires a list of interfaces in order 322 to start routing. 324 5.3. Discussion 325 6. Support for Source-Specific Routing 327 Source-Specific Routing is a hard requirement for HOMENETs, as it 328 will allow traffic to be routed to the correct outbound network based 329 on host source address selection. Routing packets to the wrong 330 outbound network could result in packets being dropped due to ISP 331 ingress filtering rules. 333 Both Babel and IS-IS have extensions for source-specific routing. 335 6.1. Source-Specific Routing in IS-IS 337 IS-IS support for source specific routing is implemented with the 338 addition of a sub-TLV to a reachability (prefix) TLV. The 339 implementation assumes that all IS-IS routers have support for the 340 sub-TLV. This assumption is safe to make due to the requirement that 341 all homenet IS-IS routers also use a homenet specific area ID and 342 cleartext password. Mixing in IS-IS routers without support for 343 source specific routing is not supported as it may cause routing 344 loops. 346 6.2. Source-Specific Routing in Babel 348 The Source-specific extension to the Babel routing protocol 349 [BABEL-SS] has been implemented for over a year, has been made widely 350 available and has seen a fair amount deployment as part of OpenWRT 351 and CeroWRT. The source-specific code is currently in the process of 352 being merged into the standard Babel implementation, and is scheduled 353 to be included in version 1.6 (planned for March 2015). 355 Babel's source-specific extensions were carefully designed so that 356 source-specific and ordinary (non-specific) routers can coexist in a 357 single routing domain, without causing routing loops. However, 358 unless there is a connected backbone of source-specific routers, any 359 non-specific routers present in the HOMENET may experience 360 blackholes. Interoperability between plain Babel and Source-Specific 361 Babel is described in detail in Section VI.A of [SS-ROUTING]. 363 6.3. Discussion 365 7. Support for Link Metrics 367 Typical HOMENETs are built out of multiple link technologies with 368 very different performance characteristics -- Gigabit Ethernet can 369 easily have three orders of magnitude higher throughput than a 370 marginal wireless link. Both IS-IS and Babel quantify the 371 desirability of a link by assigning a metric to it. 373 7.1. Link Metrics in IS-IS 375 The HOMENET implementation of IS-IS uses the wide-metric (24-bit) 376 link metric. Additionally IS-IS includes multi-topology support 377 allowing for a variable number of metrics per link, as well as per- 378 link and per-prefix tags allowing for coloring of links and 379 reachability, and finally per-link and per-prefix sub-tlv's allowing 380 for any future additional extensions. 382 7.2. Link Metrics in Babel 384 Since Babel was originally designed for heterogeneous networks, it is 385 able to dynamically assign metrics to links depending on their lower- 386 layer characteristics. In practice, Babel assigns lower (better) 387 metrics to wired links than to wireless ones, dynamically measures 388 loss rates in order to favour lossless wireless links, favours routes 389 with non-interfering radio frequencies, and avoids high-latency 390 tunnels. 392 Obviously, such a wealth of information can lead to contradictory 393 data in edge cases; however, Babel's loop-avoidance mechanisms ensure 394 that the network remains in a consistent state in all cases, and a 395 hysteresis mechanism ensures that, should a feedback loop occur, the 396 frequency of oscillations remains bounded [DELAY-BASED]. 398 8. Support for Attached Stub Networks 400 A stub network is one that is attached to a HOMENET, possibly through 401 multiple HOMENET routers, but must not be used for transit. For 402 example, a stub network could be a sensor network which would 403 collapse under the HOMENET traffic should it ever be used for 404 transit. 406 In the following example, if the dotted link between C and D is a 407 stub network, then it must not be used for transit even if the link 408 between A and B fails: 410 ---- A ----- B ----- 411 | | 412 | | 413 C ..... D 415 8.1. IS-IS Support for Stub Networks 417 In IS-IS reachability (prefixes) and topology (links/adjacencies) are 418 separate things. IS-IS supports stub-networks as defined above 419 simply by advertising the prefix associated with a link, but not the 420 link itself. This is sometimes referred to as a "passive link". 422 8.2. Babel Support for Stub Networks 424 Babel supports flexible filtering of routes, and a stub network can 425 be designated by simply setting up the necessary filtering rules. 426 For resource-limited deployments, a minimalistic, stub-only 427 implementation of Babel is available. 429 9. Security Features 431 [I think this section is badly written. We should just state whether 432 each protocol supports auth or encryption, and whether it supports 433 symmetric or something more exciting. -- jch] 435 9.1. Security Features in IS-IS 437 IS-IS offers multiple levels of security from none, to simple clear- 438 text (password) authentication, to fully generic cryptographic 439 authentication using any number of hashing algorithms (e.g., HMAC- 440 MD5, HMAC-SHA1, ... HMAC-SHA512). Currently, the HOMENET 441 implementation of IS-IS uses the cleartext password set to a 442 predefined value for auto-configuration purposes. 444 9.2. Security Features in Babel 446 Babel supports symmetric key authentication using an extensible HMAC- 447 based cryptographic authentication mechanism [RFC7298]. 449 10. Support for Multicast 451 Although the HOMENET WG has not yet determined whether to support 452 multicast in HOMENET Networks, it might be desirable to pick a 453 routing protocol that supports multicast, so that it will be easier 454 to add multicast support in the future. 456 10.1. Multicast Routing in IS-IS 458 The IS-IS protocol supports multicast routing. However, none of the 459 available implementations include support for multicast. 461 10.2. Multicast Routing in Babel 463 There is no support for multicast routing in Babel. 465 11. Implementation Status 467 There are HOMENET implementations of both IS-IS and Babel. 469 The HOMENET implementation of IS-IS is the only IS-IS implementation 470 that supports source-specific routing, which is a hard requirement 471 for HOMENET. If source-specific routing is not required, there are 472 several independent, interoperable proprietary implementations of IS- 473 IS (all major router vendors implement IS-IS). We are not aware of 474 any production-quality open-source implementation of IS-IS other than 475 the HOMENET one. 477 There are multiple open source implementations of Babel, two of which 478 support source-specific routing. All implementations (except the 479 stub-only version) were originally derived from the same codebase. 481 12. Code and State Size 483 12.1. IS-IS Code and State Size 485 The HOMENET implementation of IS-IS consists of 7000 lines of Erlang 486 code and has an installed size of over 11MB. Its initial memory 487 usage (as reported by the operating system) is 22MB, and its working 488 set increases by XXX bytes for each new edge in the network graph. 489 To put these numbers into perspective, in a network with XXX nodes 490 each of which has XXX neighbours, the HOMENET implementation of IS-IS 491 requires XXX bytes for its data structures. 493 The code size of IS-IS depends greatly on what aspects of the 494 protocol have been implemented. IS-IS supports multiple address 495 families as well as completely different protocol stacks (OSI and 496 IP), multiple area hierachical operation with automatic virtual link 497 support for repairing area partitions, and multiple link types. 498 Additionally many other protocol features have been added over time 499 to augment the protocol or replace previous behavior. The protocol 500 lends itself well to not only extension, but pairing down of 501 features. 503 For HOMENET we need a level-1 only implementation supporting a common 504 topology for IPv4 and IPv6 over broadcast (i.e., ethernet) link 505 types. Additionally, we only require support of the latest extended 506 metric TLVs (i.e., not implement legacy metric support). 508 The operational state required by IS-IS is proportional to the number 509 of routers, links, and prefixes in the network. Each router in the 510 network generates and advertises a Link State Protocol Data Unit 511 (LSP) that describes it's attached links and prefixes. A copy of 512 each of these LSPs is stored by each router in the network. IS-IS 513 uses these LSPs to construct a shortest-path-first (SPF) tree with 514 attached prefix information from which routes to the prefixes are 515 created. 517 Concrete numbers lacking. 519 12.2. Babel Code and State Size 521 The source-specific implementation of Babel, which implements many 522 non-HOMENET extensions to the protocol, consists of roughly 10000 523 lines of C and has an installed size of less than 130kB on AMD-64. 524 Its initial memory usage (as reported by the operating system) is 525 300kB. 527 The amount of state stored by a Babel router is at worst one routing 528 table entry for each destination through each neighbour. In the 529 source-specific implementation, one routing entry occupies roughly 530 100 bytes of memory. To put these figures into perspective, in a 531 network with 1000 nodes, a Babel router with 10 neighbours needs 532 roughly a megabyte of memory to store its routing table (not counting 533 malloc overhead). 535 The stub-only implementation of Babel consists of 900 lines of C and 536 compiles to 12kB (dynamically linked). Its memory usage (as reported 537 by the operating system) is 200kB, and remains constant (it doesn't 538 perform any dynamic memory allocation). 540 12.3. Comparison 542 Table 1 summarises the sizes of the available HOMENET routing 543 protocol implementations. (Data courtesy of Steven Barth and Markus 544 Stenberg.) 546 +----------------+--------------------+----------------+------------+ 547 | | babeld (source- | sbabeld (stub- | AutoISIS | 548 | | specific) | only) | | 549 +----------------+--------------------+----------------+------------+ 550 | Version | 2598774 | cc7d681 | 0.8.0 | 551 | Date | 2014-09-08 | 2014-11-21 | 2014-08-26 | 552 | License | MIT | MIT | Apache 2.0 | 553 | Lines of Code | 10.000 (C) | 1.000 (C) | 7.000 | 554 | | | | (Erlang) | 555 | Installed size | 129kB | 13kB | 11,385kB | 556 | (AMD64) | | | | 557 | Total | 129kB | 13kB | 14,155kB | 558 | installed size | | | | 559 | Baseline RSS | ~300kB | ~200kB | ~22,000kB | 560 +----------------+--------------------+----------------+------------+ 562 Table 1: Comparison of HOMENET implementation size 564 In this table, "Installed size" is the size reported by the package 565 manager for the routing daemon's package(s) (including the 1.6MB of 566 the "Beam" Erlang VM in the case of IS-IS), while "Total installed 567 size" is the sum of the size of the deamon's packages and all its 568 dependencies, excluding the C library. 570 13. Performance on IEEE 802.11 Wireless Networks 572 13.1. IS-IS Performance on 802.11 574 IS-IS is in active use in in the Internet in large non-hierachical 575 (i.e., level-2 or single area level-1) deployments with hundreds of 576 nodes. The protocol has proven to be very scalable. 578 [Do we have any information about the performance of IS-IS on 802.11 579 networks, in particular? -- mrw] 581 13.2. Babel Performance on 802.11 583 Babel has been carefully optimised for 802.11 networks. In 584 particular, it performs link quality estimations of wireless links in 585 a manner that works well with the 802.11 MAC. In addition, Babel has 586 provisions for estimating radio interference [BABEL-Z], which is 587 essential for providing decent throughput on multi-hop radio routes. 589 Babel was designed to work well on pure mesh networks (networks where 590 a packet might exit through the same interface as the one it came 591 from), but this is probably out of scope for HOMENET. 593 14. Standardization Status 595 14.1. IS-IS Standardization 597 IS-IS is an ISO Standard documented in ISO/IEC 10589:2002. There is 598 an active IETF IS-IS Working Group (ISIS) that maintains and extends 599 the IS-IS protocol, and the IS-IS protocol has been extended in 600 several ISIS Working Group documents. 602 The autoconfiguration and source-specific extensions to IS-IS, which 603 are both hard requirements for HOMENET, are documented in (non-WG) 604 Internet Drafts [ISIS-AUTOCONF] [ISIS-SS]. 606 14.2. Babel Standardization Status 608 Babel is documented in an Experimental RFC (RFC 6126) published in 609 2011, and it has been updated in several individual-submission RFCs 610 and Internet Drafts. An Internet Draft establishing an IANA registry 611 of Babel extensions has been submitted for publication as an RFC 612 [BABEL-EXT]. 614 The use of Babel in a Standards Track HOMENET RFC would require a 615 "downref" to non-Standards Track documents. It would also be 616 necessary to finish publishing the extensions that are needed for the 617 HOMENET use case as RFCs. 619 15. Evaluation of RFC 5218 Criteria 621 15.1. Critical Success Factors 623 Does the protocol exhibit one or more of the critical initial success 624 factors as defined in RFC 5218? 626 15.1.1. IS-IS Success Factors 628 IS-IS exhibits the following critical initial success factors: 630 Positive Net Value: 632 Hardware cost: None. 634 Operational interface: Existing and extensive. 636 Retraining: None. 638 Business dependencies: None. 640 Incremental Deployment: Yes. 642 Open Code Availability: Yes. One implementation of the HOMENET 643 extensions, multiple proprietary implementations of the base 644 protocol. 646 Freedom from Usage Restrictions: Yes. 648 Open Specification Availability: Yes. 650 Open Maintenance Processes: Yes. 652 Good Technical Design: Proven with extensive deployment and 653 experience with the base protocol, little deployment of the 654 HOMENET extensions. 656 Extensible: Yes. 658 No Hard Scalability bound: Yes. 660 Threats Sufficiently Mitigated: Yes. 662 15.1.2. Babel Success Factos 664 Babel exhibits the following critical initial success factors: 666 Positive Net Value: 668 Hardware cost: None. 670 Operational interface: tcpdump and wireshark support, dedicated 671 monitoring software. 673 Retraining: None. 675 Business dependencies: None. 677 Incremental Deployment: Yes. 679 Open Code Availability: Yes. Multiple implementations derived 680 from a common source. 682 Freedom from Usage Restrictions: Yes. 684 Open Specification Availability: Yes. 686 Open Maintenance Processes: IANA registry in the process of being 687 created. 689 Good Technical Design: Yes. 691 Extensible: Yes. 693 No Hard Scalability bound: Yes. 695 Threats Sufficiently Mitigated: probably. 697 15.2. Willing Implementors 699 Are there implementers who are ready to implement the technology in 700 ways that are likely to be deployed? 702 15.2.1. IS-IS 704 There is only one implementation of autoconfiguration and source- 705 specific routing for IS-IS. There are some other open source 706 implementations of the base protocol, but they are incomplete (as of 707 February 2015). 709 As all major routing vendors have (proprietary) IS-IS 710 implementations, the barrier for implmeneting IS-IS for HOMENET use 711 is probably manageable, assuming that the willingness to implement 712 modifications needed for HOMENET use is present. 714 15.2.2. Babel 716 The Babel implementation is open source software (MIT licensed), and 717 the codebase has proven of sufficiently high quality to be easily 718 extended by people who were not in direct contact with the author 719 [RFC7298]. 721 15.3. Willing Customers 723 Are there customers (especially high-profile customers) who are ready 724 to deploy the technology? 726 15.3.1. IS-IS 728 Yes. IS-IS is already widely deployed in operational networks. 730 15.3.2. Babel 732 Source-Specific Babel is currently deployed as part of the OpenWRT 733 and CeroWRT operating systems. Additionally, the current version is 734 used as a testbed for the HOMENET configuration protocol. 736 15.4. Potential Niches 738 Are there potential niches where the technology is compelling? 740 15.4.1. IS-IS 742 15.4.2. Babel 744 Babel is a simple and flexible routing protocol. Like most distance- 745 vector protocols, it requires little to no configuration in most 746 topologies, and has proved popular in scenarios where competent 747 network administration was not available. In addition, it has been 748 shown to be particularly useful in scenarios where non-standard 749 dynamically computed metrics are beneficial, notably wireless mesh 750 networks and overlay networks. 752 15.5. Complexity Removal 754 If so, can complexity be removed to reduce cost? 756 15.5.1. IS-IS 758 As mentioned previously IS-IS can be significantly and easily pared 759 down to fit the more limited scope of homenet use. However, no such 760 pared down implementation exists, and the subset of the protocol that 761 needs to be implemented has never been formally defined. 763 15.5.2. Babel 765 Babel is a fairly simple protocol -- RFC 6126 is just 40 pages long 766 (not counting informative appendices), and it has been successfully 767 explained to fourth year university students in less than two hours. 769 The stub-only implementation of Babel consists of 900 lines of C 770 code, and has deliberately been kept as simple as possible. We 771 expect a competent engineer to get up to speed with it within hours. 773 15.6. Killer App 775 Is there a potential killer app? Or can the technology work 776 underneath existing unmodified applications? 778 15.6.1. IS-IS 780 As IS-IS already qualifies as successful (bordering on wildly) a 781 killer app is not particularly relevant. 783 15.6.2. Babel 785 Since Babel requires virtually no configuration, it is particularly 786 suitable to scenarios where a dedicated network administrator is not 787 available. Additionally, its support for dynamically computed non- 788 standard metrics makes it particularly appealing in highly 789 heterogeneous networks, (networks built on multiple link-layer 790 technologies with widely varying performance characteristics). 792 15.7. Extensible 794 Is the protocol sufficiently extensible to allow potential 795 deficiencies to be addressed in the future? 797 15.7.1. IS-IS 799 IS-IS has been shown to be incredibly extensible, originally designed 800 for a completely different protocol stack (OSI) it was easily adapted 801 for IP use, then to multiple address families (IPv4, IPv6) and multi- 802 topology. Indeed one of the major drivers of IS-IS's success is its 803 extensibility and adaptability. 805 15.7.2. Babel 807 The extension mechanisms built into the Babel protocol [BABEL-EXT] 808 have been shown to be a solid basis on which many backwards- 809 compatible extensions have been built, including one that 810 fundamentally changes the structure of announcements [BABEL-SS] and 811 one that needs a non-trivial extension to the space of metrics 812 [BABEL-Z]. 814 15.8. Success Predictable 816 If it is not known whether the protocol will be successful, should 817 the market decide first? Or should the IETF work on multiple 818 alternatives and let the market decide among them? Are there factors 819 listed in this document that may predict which is more likely to 820 succeed? 822 15.8.1. IS-IS 824 For IS-IS the market has already decided that the protocol is 825 successful in a fairly wide variety of deployments. [We're speaking 826 of source-specific, autoconfiguring IS-IS here? And are we speaking 827 of small, unadministered networks? -- jch] 829 15.8.2. Babel 831 Source-specific Babel is probably the only source-specific routing 832 protocol that has seen deployment and is being used in production. 834 Plain Babel has seen a modest amount of deployment, most notably for 835 routing over wireless mesh networks and large-scale overlay networks. 836 However, it remains a young protocol, certainly much younger than IS- 837 IS. 839 16. Acknowledgments 841 The authors are grateful for the input of Steven Barth, Denis 842 Ovsienko and Mark Townsley. 844 17. Informative References 846 [BABEL-EXT] 847 Chroboczek, J., "Extension Mechanism for the Babel Routing 848 Protocol", Internet Draft draft-chroboczek-babel- 849 extension-mechanism-03, June 2013. 851 [BABEL-SS] 852 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 853 Babel", Internet Draft draft-boutier-babel-source- 854 specific-00, November 2014. 856 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 857 Protocol", Internet Draft draft-chroboczek-babel- 858 diversity-routing-00, July 2014. 860 [DELAY-BASED] 861 Jonglez, B. and M. Boutier, "A delay-based routing 862 metric", March 2014, . 864 [ISIS-AUTOCONF] 865 Liu, B., "ISIS Auto-Configuration", Internet Draft draft- 866 liu-isis-auto-conf-03, October 2014. 868 [ISIS-SS] Baker, F. and D. Lamparter, "IPv6 Source/Destination 869 Routing using IS-IS", Internet Draft draft-baker-ipv6- 870 isis-dst-src-routing-02, October 2014. 872 [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 873 1142, February 1990. 875 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 876 April 2011. 878 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 879 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 881 [SS-ROUTING] 882 Boutier, M. and J. Chroboczek, "Source-sensitive routing", 883 December 2014, . 885 Authors' Addresses 887 Margaret Wasserman 888 Painless Security 889 356 Abbott Street 890 North Andover, MA 01845 891 USA 893 Phone: +1 781 405-7464 894 Email: mrw@painless-security.com 895 URI: http://www.painless-security.com 896 Christian E. Hopps 897 Deutsche Telekom 899 Email: chopps@chopps.org 901 Juliusz Chroboczek 902 University of Paris-Diderot (Paris 7) 904 Email: jch@pps.univ-paris-diderot.fr