idnits 2.17.1 draft-mrw-homenet-rtg-comparison-00.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 9, 2015) is 3363 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-chroboczek-babel-extension-mechanism-03 == 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 -- 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 (~~), 4 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: Standards Track C. Hopps 5 Expires: August 13, 2015 Deutsche Telekom 6 J. Chroboczek 7 University of Paris-Diderot (Paris 7) 8 February 9, 2015 10 HOMENET IS-IS and Babel Comparison 11 draft-mrw-homenet-rtg-comparison-00.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 13, 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 . . . . . . . 3 58 2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 3 59 2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 4 60 3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 4 62 3.2. Distance-Vector Algorithm (Babel) . . . . . . . . . . . . 4 63 3.3. Algorithm Comparison . . . . . . . . . . . . . . . . . . 4 64 4. Support for Source-Specific Routing . . . . . . . . . . . . . 5 65 4.1. Source Specific Routing in IS-IS . . . . . . . . . . . . 5 66 4.2. Source Specific Routing in Babel . . . . . . . . . . . . 5 67 4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Support for Link Metrics . . . . . . . . . . . . . . . . . . 6 69 5.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 6 70 5.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 6 71 6. Support for Attached Stub Networks . . . . . . . . . . . . . 6 72 6.1. IS-IS Support for Stub Networks . . . . . . . . . . . . . 6 73 6.2. Babel Supportt for Stub Networks . . . . . . . . . . . . 6 74 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Security Features in IS-IS . . . . . . . . . . . . . . . 6 76 7.2. Security Features in Babel . . . . . . . . . . . . . . . 7 77 8. Support for Multicast . . . . . . . . . . . . . . . . . . . . 7 78 8.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 7 79 8.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 7 80 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 81 10. Code and State Size . . . . . . . . . . . . . . . . . . . . . 7 82 10.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 7 83 10.2. Babel Code and State Size . . . . . . . . . . . . . . . 8 84 11. Scalablity on IEEE 802.11 Wireless Networks . . . . . . . . . 9 85 11.1. IS-IS Scalability on 802.11 . . . . . . . . . . . . . . 9 86 11.2. Babel Scalability on 802.11 . . . . . . . . . . . . . . 9 87 12. Standardization Status . . . . . . . . . . . . . . . . . . . 9 88 12.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 9 89 12.2. Babel Standardization Status . . . . . . . . . . . . . . 10 90 13. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 10 91 13.1. Critical Success Factors . . . . . . . . . . . . . . . . 10 92 13.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 10 93 13.1.2. Babel Success Factos . . . . . . . . . . . . . . . . 11 94 13.2. Willing Implementors . . . . . . . . . . . . . . . . . . 11 95 13.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 11 96 13.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 12 98 13.3. Willing Customers . . . . . . . . . . . . . . . . . . . 12 99 13.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 12 100 13.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 12 101 13.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 12 102 13.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 12 103 13.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 12 104 13.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 13 105 13.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 13 106 13.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 13 107 13.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 13 108 13.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 13 109 13.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 13 110 13.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 13 111 13.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 14 112 13.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 14 113 13.8. Success Predictable . . . . . . . . . . . . . . . . . . 14 114 13.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 14 115 13.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 14 116 14. Informative References . . . . . . . . . . . . . . . . . . . 14 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 119 1. Introduction 121 This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel 122 [RFC6126] across several criteria related to their use in home 123 networks, as defined by the HOMENET WG (HOMENETs). 125 Although there are substantial differences between the IS-IS and 126 Babel routing protocols, both routing protocols work well, and either 127 of them could be used in a home network. There are many 128 characteristics of these protocols that make them more or less 129 suitable for use in HOMENETs, as defined in (reference homenet 130 architecture and HNCP documents), and those characteristics are 131 explored in this document. 133 2. Protocols and Extensions Included in Comparison 135 Both IS-IS and Babel are living protocols that are updated and 136 extended over time. This section lists the extensions that were 137 considered in this comparison. Additional protocol extensions could 138 affect some of the information included in this document. 140 2.1. IS-IS Protocol and Extensions 142 In addition to the base IS-IS protocol specification (ISO/IEC 143 10589:2002), this comparison considers the following IS-IS 144 extensions: 146 2.2. Babel Protocol and Extensions 148 In addition to the base Babel Protocol specification (RFC 6126), this 149 comparison considers the following Babel extensions: 151 Source-Specific Routing [BABEL-SS], described in more detail in 152 [SS-ROUTING]. 154 Extension Mechanism for the Babel Routing Protocol[BABEL-EXT] 156 3. Routing Algorithms 158 IS-IS is a Link State routing protocol, and Babel is a Loop-avoiding 159 Distance Vector routing protocol. There are some differences between 160 these algorithms, particularly in terms of scalability, how much 161 information is exchanged when the routing topology changes, and how 162 far topology changes are propagated. [chopps: Perhaps we should see 163 if we can find an external reference for comparing DVRP to link-state 164 RPs for this section]. 166 3.1. Link State Algorithm 168 Link state algorithms distribute information for each node to compute 169 a tree representing the entire network. 171 Link state algorithms scale well in both very large and very dense 172 networks. 174 3.2. Distance-Vector Algorithm (Babel) 176 Distance-vector algorithms distribute information about the path 177 length to reach each destination through a given neighbor. Packets 178 are forwarded to the neighbor who is advertising the shortest path to 179 reach the destination. 181 3.3. Algorithm Comparison 183 Loop-avoiding Distance Vector scales beautifully to very large 184 networks -- the amount of state is linear in the number of nodes, and 185 does not need to be propagated in a timely manner. It scales badly 186 in extremely dense deployments, where a single node has thousands of 187 direct neighbours; such deployments are unlikely, and clearly outside 188 the scope of Homenet. 190 Naive link state has somewhat worse scaling properties, since it has 191 state that is proportional to the number of edges in the network 192 graph, and requires strict state synchronisation between nodes. 193 Real-world link-state protocols work around that issue by splitting 194 the network into multiple "areas", and performing distance-vector 195 routing between areas. It is unclear whether this workaround is 196 suitable for Homenet. 198 4. Support for Source-Specific Routing 200 Source-Specific Routing is a hard requirement for HOMENETs, as it 201 will allow traffic to be routed to the correct outbound network based 202 on host source address selection. Routing packets to the wrong 203 outbound network could result in packets being dropped due to ISP 204 ingress filtering rules. 206 Both Babel and IS-IS have extensions for source-specific routing. 208 4.1. Source Specific Routing in IS-IS 210 [XXX: chopps] 212 Reports indicate that IS-IS has critical issues (routing loops) in a 213 mixed environment where some routers support Source-Specific Routing, 214 and some routers do not. However, this is not likely to be a problem 215 for Homenet, as we will require Source-Specific Routing on all 216 routers. 218 4.2. Source Specific Routing in Babel 220 The Source-specific extension to the Babel routing protocol 221 [BABEL-SS] has been implemented for over a year, has been made widely 222 available and has seen a fair amount deployment as part of OpenWRT 223 and CeroWRT. The implementation is currently being merged into the 224 standard Babel implementation, and is scheduled to be included in 225 version 1.6 (planned for March 2015). 227 4.3. Discussion 229 Babel's source-specific extensions were carefully designed so that 230 source-specific and ordinary (non-specific) routers can coexist in a 231 single routing domain, without routing pathologies such as routing 232 loops. Interoperability between plain Babel and Source-Specific 233 Babel is described in detail in Section VI.A of [SS-ROUTING]. 235 Reports indicate that source-specific IS-IS has critical issues 236 (routing loops) in a mixed environment where some routers support 237 Source-Specific Routing, and some routers do not. However, this is 238 not likely to be a problem for Homenet, as we will require Source- 239 Specific Routing on all routers. 241 [How will we enforce that? -- jch] 243 5. Support for Link Metrics 245 5.1. Link Metrics in IS-IS 247 IS-IS supports 2 types of link metrics a legacy link metric (which 248 should probably not be considered for HOMENET use) and a modern 249 extended (24-bit) link metric. Additionally multi-topology support 250 allows for a variable number of metrics per link. 252 5.2. Link Metrics in Babel 254 In Babel, metrics are unsigned 16-bit integers, which means that 255 metrics are arbitrary integers between 0 and 65534 (the value 65535 256 is reserved to mean "infinity"); this has been found to be sufficient 257 even in the chaotic environment of wireless mesh networks. If 258 needed, the Babel extension mechanism can be used to extend the 259 metric space in arbitrary ways (not just integers), which has already 260 been done by the radio interference extensions to Babel [BABEL-Z]. 262 6. Support for Attached Stub Networks 264 [I don't understand why this issue is important for Homenet. -- jch] 266 6.1. IS-IS Support for Stub Networks 268 A stub network in IS-IS is supported by the advertisement of 269 reachability to a prefix by a router in its LSP. [How does this 270 prevent the network from being used for transit? -- jch] 272 6.2. Babel Supportt for Stub Networks 274 Babel supports flexible filtering of routes, and a stub network can 275 be designated by simply setting up the necessary filtering rules. 276 For resource-limited deployments, a minimalistic, stub-only 277 implementation of Babel is available. 279 7. Security Features 281 7.1. Security Features in IS-IS 283 IS-IS offers multiple levels of security from none, to simple clear- 284 text (password) authentication, to fully generic cryptographic 285 authentication using any number of hashing algorithms (e.g., HMAC- 286 MD5, HMAC-SHA1, ... HMAC-SHA512) based on security associations 287 (link, area and domain scoped). 289 [What does that mean? Just support for HMAC-based authentication, or 290 am I missing something? -- jch] 292 7.2. Security Features in Babel 294 Babel supports an extensible HMAC-based cryptographic authentication 295 mechanism [RFC7298]. 297 8. Support for Multicast 299 Although the HOMENET WG has not yet determined how/if to support 300 multicast in HOMENET Networks, it might be desirable to pick a 301 routing protocol that supports multicast, so that it will be easier 302 to add multicast support in the future. 304 8.1. Multicast Routing in IS-IS 306 The IS-IS protocol supports multicast routing. However, none of the 307 available implementations include support for multicast. [XXX: 308 chopps: what do we mean by supporting multicast routing?] 310 [Does the Homenet implementation support multicast? Does any open 311 source implementation support multicast? -- jch] 313 8.2. Multicast Routing in Babel 315 There is no support for multicast routing in Babel. 317 9. Implementation Status 319 There are Homenet implementations of both IS-IS and Babel. 321 Only the Homenet implementation of IS-IS supports source-specific 322 routing, which is a hard requirement for Homenet. If source-specific 323 routing is not required, there are several independent, interoperable 324 implementations of IS-IS (all major router vendors implement IS-IS), 325 including some open source implementations. 327 There are multiple open source implementations of Babel, two of which 328 support source-specific routing. However, they were both originally 329 derived from the same codebase. 331 10. Code and State Size 333 10.1. IS-IS Code and State Size 335 The Homenet implementation of IS-IS consists of 7000 lines of Erlang 336 code and has an installed size of over 11MB. Its initial memory 337 usage (as reported by the operating system) is 22MB, and its working 338 set increases by XXX bytes for each new edge in the network graph. 339 To put these numbers into perspective, in a network with XXX nodes 340 each of which has XXX neighbours, the Homenet implementation of IS-IS 341 requires XXX bytes for its data structures. 343 [I suggest removing the rest of this section, since it consists of 344 unsubstantiated, vague claims depending on a not-yet-implemented 345 version of a not-yet-specified subset of a large protocol. -- jch] 347 The code size of IS-IS depends greatly on what aspects of the 348 protocol have been implemented. IS-IS supports multiple address 349 families as well as completely different protocol stacks (OSI and 350 IP), multiple area hierachical operation with automatic virtual link 351 support for repairing area partitions, and multiple link types. 352 Additionally many other protocol features have been added over time 353 to augment the protocol or replace previous behavior. The protocol 354 lends itself well to not only extension, but pairing down of 355 features. 357 For HOMENET we could use a very simple level-2 only implementation 358 supporting a common topology supporting IPv4 and IPv6 over broadcast 359 (i.e., ethernet) link types. Additionally, we would need only 360 support the latest extended metric TLV (i.e., not implement legacy 361 metric support). Implemented as such the code size should be very 362 manageable. 364 The state actually required by IS-IS is not large, and primarily 365 correlates to the number of routers in the network (for LSP storage). 366 The protocol stores it's own link and adjacency data which is 367 expected to be negligible. Additionally, the protocol stores 368 received and generated LSPs, and typically an SPF tree with prefix 369 information attached. This state correlates directly to the number 370 of routers and prefixes in the network. Each router in the network 371 generates, a single LSP (possibly fragmented into segments) with 372 prefix information, a single copy of these LSPs is stored by each 373 router in the network regardless of the number of links, adjacencies 374 or the distance (or number of hops) from the storing router to the 375 advertising router. 377 10.2. Babel Code and State Size 379 The source-specific implementation of Babel, which implements many 380 non-Homenet extensions to the protocol, consists of roughly 10000 381 lines of C and has an installed size of less than 130kB on AMD-64. 382 Its initial memory usage (as reported by the operating system) is 383 300kB. 385 The amount of state stored by a Babel router is at worst one routing 386 table entry for each destination through each neighbour. In the 387 source-specific implementation, one routing entry occupies roughly 388 100 bytes of memory. To put these figures into perspective, in a 389 network with 1000 nodes, a Babel router with 10 neighbours needs 390 roughly a megabyte of memory to store its routing table (not counting 391 malloc overhead). 393 The stub-only implementation of Babel consists of 900 lines of C and 394 compiles to 12kB (dynamically linked). Its memory usage (as reported 395 by the operating system) is 200kB, and remains constant (it doesn't 396 perform any dynamic memory allocation). 398 11. Scalablity on IEEE 802.11 Wireless Networks 400 [I suggest renaming this section to "Performance on 802.11 wireless 401 networks. Are we trying to get homenets to scale to millions of 402 nodes? -- jch] 404 11.1. IS-IS Scalability on 802.11 406 IS-IS is in active use in in the Internet in large non-hierachical 407 (i.e., level-2 or single area level-1) deployments with hundreds of 408 nodes. The protocol has proven to be very scalable. 410 Do we have any information about the scaling of IS-IS on 802.11 411 networks, in particular? 413 11.2. Babel Scalability on 802.11 415 Babel was carefully optimised for 802.11 networks. In particular, it 416 has (optional) provisions for link quality estimation and (optional) 417 provisions for radio-interference sensitive routing. 419 Babel was designed to work well on pure mesh networks (networks where 420 a packet might exit through the same interface as the one it came 421 from), but this is probably out of scope for Homenet. 423 12. Standardization Status 425 12.1. IS-IS Standardization 427 IS-IS is an ISO Standard documented in ISO/IEC 10589:2002. There is 428 an active IETF IS-IS Working Group (ISIS) that maintains and extends 429 the IS-IS protocol, and the IS-IS protocol has been extended in 430 several ISIS Working Group documents. 432 The source-specific extension to IS-IS is standardized as XXX. [Will 433 it require a downref? -- jch] 435 12.2. Babel Standardization Status 437 Babel is documented in an Experimental RFC (RFC 6126) published in 438 2011, and it has been updated in several individual-submission RFCs 439 and Internet Drafts. 441 The use of Babel in a Standards Track HOMENET RFC would require a 442 "downref" to non-Standards Track documents. It would also be 443 necessary to publish the extensions that are needed for the HOMENET 444 use case as RFCs. 446 13. Evaluation of RFC 5218 Criteria 448 13.1. Critical Success Factors 450 Does the protocol exhibit one or more of the critical initial success 451 factors as defined in RFC 5218? 453 13.1.1. IS-IS Success Factors 455 IS-IS exhibits the following critical initial success factors: 457 Positive Net Value: 459 Hardware cost: None. 461 Operational interface: Existing and extensive. 463 Retraining: None. 465 Business dependencies: None. 467 Incremental Deployment: Yes. 469 Open Code Availability: Yes. Multiple implementations. 471 Freedom from Usage Restrictions: Yes. 473 Open Specification Availability: Yes. 475 Open Maintenance Processes: Yes. 477 Good Technical Design: Proven with extensive deployment and 478 experience. 480 Extensible: Yes. 482 No Hard Scalability bound: Yes. 484 Threats Sufficiently Mitigated: Yes. 486 13.1.2. Babel Success Factos 488 Babel exhibits the following critical initial success factors: 490 Positive Net Value: 492 Hardware cost: None. 494 Operational interface: ??. 496 Retraining: None. 498 Business dependencies: None. 500 Incremental Deployment: Yes. 502 Open Code Availability: Yes. One implementation. 504 Freedom from Usage Restrictions: Yes. 506 Open Specification Availability: Yes. 508 Open Maintenance Processes: No. 510 Good Technical Design: Yes, but less widely deployed/proven than 511 IS-IS. 513 Extensible: Yes. 515 No Hard Scalability bound: No. 517 Threats Sufficiently Mitigated: ??. 519 13.2. Willing Implementors 521 Are there implementers who are ready to implement the technology in 522 ways that are likely to be deployed? 524 13.2.1. IS-IS 526 There is only one implementation of source-specific routing for IS- 527 IS. [Has it ever been extended by people who are not the authors? 528 If so, who? -- jch] 530 [I suggest the rest of this section should be removed. -- jch] 531 As all major routing vendors have IS-IS implementations as well as 532 the existence of for sale and open source implementations, the 533 barrier for implmeneting IS-IS for homenet use is quite low. Given 534 this we can assume that willingness to implement modifications (if 535 any) for homenet use is present and strong. 537 13.2.2. Babel 539 The Babel implementation is open source software (MIT licensed, non- 540 copyleft), and the codebase has proven of sufficiently high quality 541 to be easily extended by people who were not in direct contact with 542 the author [RFC7298]. 544 13.3. Willing Customers 546 Are there customers (especially high-profile customers) who are ready 547 to deploy the technology? 549 13.3.1. IS-IS 551 Yes. IS-IS is already widely deployed in operational networks. 553 [I suggest more details should be given. Recall that we're speaking 554 of source-specific IS-IS here. -- jch] 556 13.3.2. Babel 558 Babel is currently deployed as part of the OpenWRT and CeroWRT 559 operating systems. Additionally, the current version is used as a 560 testbed for the Homenet configuration protocol. 562 13.4. Potential Niches 564 Are there potential niches where the technology is compelling? 566 13.4.1. IS-IS 568 13.4.2. Babel 570 Babel is a simple and flexible routing protocol. Like most distance- 571 vector protocols, it requires little to no configuration in most 572 topologies, and has proved popular in scenarios where competent 573 network administration was not available. In addition, it has been 574 shown to be particularly useful in scenarios where non-standard 575 metrics were needed, notably wireless mesh networks and overlay 576 networks. 578 13.5. Complexity Removal 580 If so, can complexity be removed to reduce cost? 582 13.5.1. IS-IS 584 As mentioned previously IS-IS can be significantly and easily paired 585 down to fit the more limited scope of homenet use. 587 [Any actual implementations the reader can examine? -- jch] 589 13.5.2. Babel 591 Babel is a fairly simple protocol -- RFC 6126 is just 40 pages long 592 (not counting informative appendices), and it has been successfully 593 explained to fourth year university students in less than two hours. 595 The stub-only implementation of Babel consists of 900 lines of C 596 code, and has deliberately been kept as simple as possible. We 597 expect a competent engineer to get up to speed with it within hours. 599 13.6. Killer App 601 Is there a potential killer app? Or can the technology work 602 underneath existing unmodified applications? 604 13.6.1. IS-IS 606 As IS-IS already qualifies as successful (bordering on wildly) a 607 killer app is not particularly relevant. 609 13.6.2. Babel 611 Since Babel requires virtually no configuration, it is particularly 612 suitable to scenarios where a dedicated network administrator is not 613 available. Additionally, its support for link quality sensing and 614 non-standard metrics makes it particularly appealing in highly 615 heterogeneous networks, (networks built on multiple link-layer 616 technologies with widely varying performance characteristics). 618 13.7. Extensible 620 Is the protocol sufficiently extensible to allow potential 621 deficiencies to be addressed in the future? 623 13.7.1. IS-IS 625 IS-IS has been shown to be incredibly extensible, originally designed 626 for a completely different protocol stack (OSI) it was easily adapted 627 for IP use, then to multiple address families (IPv4, IPv6) and multi- 628 topology. Indeed one of the major drivers of IS-IS's success is its 629 extensibility and adaptability. 631 13.7.2. Babel 633 The extension mechanisms built into the Babel protocol [BABEL-EXT] 634 have been shown to be a solid basis on which many backwards- 635 compatible extensions have been built, including one that 636 fundamentally changes the structure of announcements [BABEL-SS] and 637 one that needed a non-trivial extension to the space of metrics 638 [BABEL-Z]. 640 13.8. Success Predictable 642 If it is not known whether the protocol will be successful, should 643 the market decide first? Or should the IETF work on multiple 644 alternatives and let the market decide among them? Are there factors 645 listed in this document that may predict which is more likely to 646 succeed? 648 13.8.1. IS-IS 650 For IS-IS the market has already decided that the protocol is 651 successful in a fairly wide variety of deployments. 653 13.8.2. Babel 655 Source-specific Babel is probably the only source-specific routing 656 protocol that has seen a fair amount of deployment and is being used 657 in production. 659 Plain Babel has seen a modest amount of deployment, most notably for 660 routing over wireless mesh networks and large-scale overlay networks. 661 However, it remains a young protocol, certainly much younger than IS- 662 IS. 664 14. Informative References 666 [BABEL-EXT] 667 Chroboczek, J., "Extension Mechanism for the Babel Routing 668 Protocol", Internet Draft draft-chroboczek-babel- 669 extension-mechanism-03, June 2013. 671 [BABEL-SS] 672 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 673 Babel", Internet Draft draft-boutier-babel-source- 674 specific-00, November 2014. 676 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 677 Protocol", Internet Draft draft-chroboczek-babel- 678 diversity-routing-00, July 2014. 680 [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 681 1142, February 1990. 683 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 684 April 2011. 686 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 687 (HMAC) Cryptographic Authentication", RFC 7298, July 2014. 689 [SS-ROUTING] 690 Boutier, M. and J. Chroboczek, "Source-sensitive routing", 691 December 2014, . 693 Authors' Addresses 695 Margaret Wasserman 696 Painless Security 697 356 Abbott Street 698 North Andover, MA 01845 699 USA 701 Phone: +1 781 405-7464 702 Email: mrw@painless-security.com 703 URI: http://www.painless-security.com 705 Christian E. Hopps 706 Deutsche Telekom 708 Email: chopps@rawdofmt.org 710 Juliusz Chroboczek 711 University of Paris-Diderot (Paris 7) 713 Email: jch@pps.univ-paris-diderot.fr