One document matched: draft-mrw-homenet-rtg-comparison-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc6126 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6126.xml'>
<!ENTITY rfc7298 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7298.xml'>
<!ENTITY rfc1142 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1142.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-mrw-homenet-rtg-comparison-01.txt">
<front>
<title>HOMENET IS-IS and Babel Comparison</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405-7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author initials="C." surname="Hopps" fullname="Christian E. Hopps">
<organization>Deutsche Telekom</organization>
<address>
<email>chopps@chopps.org</email>
</address>
</author>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek">
<organization>University of Paris-Diderot (Paris 7)</organization>
<address>
<email>jch@pps.univ-paris-diderot.fr</email>
</address>
</author>
<date month="February" year="2015"/>
<area>Internet</area>
<workgroup>Homenet Working Group</workgroup>
<abstract>
<t>
This document is intended to provide information to members of
the IETF Home Networks Working Group (HOMENET WG), so that we
can make an informed decision regarding which routing protocol
to use in home networks. The routing protocols compared
in this document are: The Babel Routing Protocol (Babel) and
The Intermediate System to Intermediate System Intra-Domain
Routing Protocol (IS-IS).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document compares IS-IS (ISO/IEC 10589:2002) <xref
target="RFC1142"/> and Babel <xref target="RFC6126"/> according to
several criteria related to their use in home networks (HOMENETs),
as defined by the HOMENET WG.
</t>
<t>
Please note that this document does not represent the consenus
of any group, not even the authors. It is an organized
collection of facts and well-informed opinions provided by
experts on Babel and IS-IS that may be useful to the
HOMENET WG in choosing a routing protocol.
</t>
<t>
The HOMENET environment is different from the environment of
a professionally administered network. The most obvious
difference is that a HOMENET is not administered: any protocols
used must be robust and fully self-configuring, and any tuning
knobs that they provide will be unused in the vast majority of
deployments.
</t>
<t>
Another difference is that HOMENETs are usually built out of
a specific class of cheap device, the "Plastic Home Router".
A Plastic Home Router's firmware is installed at the factory, and
is most likely never updated. Additionally, experience shows that
home routers are often used way beyond their warranty period, and
even after their manufacturer leaves the router business. This,
again, argues in favour of simple, robust protocols that are easy
to implement and can be expected to keep functioning without
software updates.
</t>
<t>
HOMENETs are built and grow organically, and often end up
consisting of multiple link technologies with widely different
performance characteristics (twisted-pair Ethernet, IEEE 802.11
and its multiple variants, Powerline Ethernet, etc.). It is
desirable for a HOMENET routing protocol to be able to dynamically
optimise paths according to the link characteristics.
</t>
<t>
Contrary to popular perception, the Plastic Home Router is usually
equipped with a reasonably fast CPU and reasonable amounts of
flash and RAM; at the time of writing, a (non-superscalar) 700MHz
MIPS CPU with 16MB of flash and 64MB of RAM is typical. However,
we expect smaller devices to participate in the HOMENET protocols,
at least as stub routers. The ability to scale down the HOMENET
protocols is therefore likely to encourage their wider adoption.
</t>
<t>
[Isn't it also the case that the HOMENET routing protocol will
be implemented on lower-end embedded devices, such as nodes in
a low-power wireless network? What is considered to be a
reasonable low-end system requirement for a HOMENET router?
-- mrw]
</t>
<t>
Experts appear to disagree on the expected size of a HOMENET; we
have heard estimates ranging from just one router up to 250
routers. In any case, while scaling beyond a few thousand nodes
is not likely to be relevant to HOMENET in the foreseeable future,
the HOMENET protocols, if successful, will be repurposed to larger
networks, whether we like it or not, and using a protocol that
scales well from the outset may be desirable.
</t>
</section>
<section title="Protocols and Extensions Included in Comparison">
<t>
Both IS-IS and Babel are living protocols that are updated and
extended over time. This section lists the extensions that
were considered in this comparison. Additional protocol
extensions could affect some of the information included in this
document.
</t>
<section title="IS-IS Protocol and Extensions">
<t>
In addition to the base IS-IS protocol specification
(ISO/IEC 10589:2002), this comparison considers the
following IS-IS extensions:
</t>
<t><list style="symbols">
<t>
ISIS Auto-Configuration <xref target="ISIS-AUTOCONF"/>;
</t>
<t>
Source-Specific routing in IS-IS <xref target="ISIS-SS"/>.
</t>
</list></t>
</section>
<section title="Babel Protocol and Extensions">
<t>
In addition to the base Babel Protocol specification (RFC
6126), this comparison considers the following Babel
extensions:
</t>
<t><list style="symbols">
<t>
Extension Mechanism for the Babel Routing Protocol
<xref target="BABEL-EXT"/>;
</t>
<t>
Source-Specific Routing <xref target="BABEL-SS"/>, described in
more detail in <xref target="SS-ROUTING"/>.
</t>
</list></t>
</section>
</section>
<section title="Routing Algorithms">
<t>
IS-IS is a Link State routing protocol, and Babel is
a Loop-Avoiding Distance Vector routing protocol. There are some
differences between these algorithms, particularly in terms of
scalability, how much information is exchanged when the routing
topology changes, and how far topology changes are propagated.
</t>
<section title="Link State Algorithm">
<t>
Link state algorithms distribute information for each node to all
other nodes in the network using a flooding algorithm. This database
of information is then used by each node to compute the best path to
the other nodes in the network.
</t>
<t>
One benefit of this algorithm is that each node contains the
full knowledge of the topology of the network. This
information can be used by other applications outside the
routing protocol itself.
</t>
<t>
Additionally the flooding algorithm has been found as an
efficient method for other applications to distribute
node-specific application data, although some care must be
taken with this use so as not to disrupt the fundamental
routing function.
</t>
</section>
<section title="Loop-Avoiding Distance-Vector Algorithm (Babel)">
<t>
Distance-vector algorithms distribute information about the
path length to reach each destination through a given
neighbor. Packets are forwarded to the neighbor who is
advertising the best path towards the destination.
</t>
<t>
Babel, like EIGRP, DSDV, and to a certain extent BGP, uses
a loop-avoiding distance-vector algorithm: it avoids creating
a loop even during reconvergence (there is no "counting to
infinity", and even short-lived "microloops" are avoided in most
cases).
</t>
</section>
<section title="Algorithm Comparison">
<t>
Loop-Avoiding Distance Vector scales to very large
networks -- the amount of state is linear in the number of
nodes, and, due to the absence of pathologies during
reconvergence, does not need to be propagated in a timely
manner. It scales badly in extremely dense deployments, where
a single node has thousands of direct neighbours; such
deployments are unlikely, and clearly outside the scope of
HOMENET.
</t>
<t>
Link state algorithms scales to very large, very dense
networks.
</t>
<t>
IS-IS distributes link and prefix information for
each node in a single Logical LSP (possibly fragmented). It
uses these LSPs to compute a tree representing the entire
network. There is no duplication of state based on the
number of adjacencies or unique paths to a given prefix.
</t>
</section>
</section>
<section title="Convergence Times">
<t>
Convergence time is defined as the amount of time after a link
failure is detected during which the network is not fully
operational. It does not include the time necessary to detect
a link failure.
</t>
<section title="IS-IS">
<t>
Given fast flooding of any change in the network, IS-IS has
been shown to acheive sub 200ms end-to-end convergence even
in very large provider networks (single area 900+
nodes). Basically the time for convergence is the time to
propagate a new LSP from one end of the network to the other
plus the SPF (tree computation interval) and FIB loading
time. The flooding is done without delay and prior to
running the SPF (tree-calculation) algorithm. Thus is
roughly proportional to propagation delay across the
diameter of the network. The tree calculation is sub 20ms on
modern CPUs. FIB load time depends on the FIB hardware and
design and not the routing protocol choice.
</t>
<t>
We easily should expect sub-second convergence for any change
in reachability (addition or subtraction) in any conceivable
homenet deployment.
</t>
</section>
<section title="Babel">
<t>
Since Babel maintains a redundant routing table, it is most
often able to reconverge almost instantaneously after a link
failure (this is similar to e.g. EIGRP). In the case where
no feasible routes are available, Babel reconverges in 20ms
per hop to the source.
</t>
</section>
<section title="Discussion">
<t>
Both protocols enjoy fast convergence. However, unless there is
a high level of integration between the routing protocol and the
link layer, the time needed to reconverge is dwarfed by the
amount of time needed to detect a link failure, which is the
hold time in IS-IS (30s by default), and two hello intervals on
Babel wired links (8s by default). (Babel performs link quality
estimation on wireless links, so the delay is somewhat more
difficult to quantify there.)
</t>
</section>
</section>
<section title="Autoconfiguration">
<t>
Home networks are not administered, so a routing protocol
needs to be entirely self-configuring in order to be suitable
for HOMENETs.
</t>
<section title="IS-IS">
<t>
The only required configuration for IS-IS is a unique
area/system identifier. The HOMENET implementation of IS-IS
uses an autoconfiguration extension defined in an Internet
Draft <xref target="ISIS-AUTOCONF"/>, to set this value.
</t>
</section>
<section title="Babel">
<t>
Babel is a fully self-configuring protocol -- the standard
implementation of Babel only requires a list of interfaces
in order to start routing.
</t>
</section>
<section title="Discussion">
</section>
</section>
<section title="Support for Source-Specific Routing">
<t>
Source-Specific Routing is a hard requirement for HOMENETs, as
it will allow traffic to be routed to the correct outbound
network based on host source address selection. Routing
packets to the wrong outbound network could result in packets
being dropped due to ISP ingress filtering rules.
</t>
<t>
Both Babel and IS-IS have extensions for source-specific routing.
</t>
<section title="Source-Specific Routing in IS-IS">
<t>
IS-IS support for source specific routing is implemented
with the addition of a sub-TLV to a reachability (prefix)
TLV. The implementation assumes that all IS-IS routers have
support for the sub-TLV. This assumption is safe to make due
to the requirement that all homenet IS-IS routers also use a
homenet specific area ID and cleartext password. Mixing in
IS-IS routers without support for source specific routing is
not supported as it may cause routing loops.
</t>
</section>
<section title="Source-Specific Routing in Babel">
<t>
The Source-specific extension to the Babel routing protocol
<xref target="BABEL-SS"/> has been implemented for over a
year, has been made widely available and has seen a fair
amount deployment as part of OpenWRT and CeroWRT. The
source-specific code is currently in the process of being
merged into the standard Babel implementation, and is
scheduled to be included in version 1.6 (planned for March
2015).
</t>
<t>
Babel's source-specific extensions were carefully designed
so that source-specific and ordinary (non-specific) routers
can coexist in a single routing domain, without causing
routing loops. However, unless there is a connected
backbone of source-specific routers, any non-specific
routers present in the HOMENET may experience blackholes.
Interoperability between plain Babel and Source-Specific
Babel is described in detail in Section VI.A of <xref
target="SS-ROUTING"/>.
</t>
</section>
<section title="Discussion">
</section>
</section>
<section title="Support for Link Metrics">
<t>
Typical HOMENETs are built out of multiple link technologies
with very different performance characteristics -- Gigabit
Ethernet can easily have three orders of magnitude higher
throughput than a marginal wireless link. Both IS-IS and
Babel quantify the desirability of a link by assigning a
metric to it.
</t>
<section title="Link Metrics in IS-IS">
<t>
The HOMENET implementation of IS-IS uses the wide-metric
(24-bit) link metric. Additionally IS-IS includes
multi-topology support allowing for a variable number of
metrics per link, as well as per-link and per-prefix tags
allowing for coloring of links and reachability, and finally
per-link and per-prefix sub-tlv's allowing for any future
additional extensions.
</t>
</section>
<section title="Link Metrics in Babel">
<t>
Since Babel was originally designed for heterogeneous
networks, it is able to dynamically assign metrics to links
depending on their lower-layer characteristics. In
practice, Babel assigns lower (better) metrics to wired
links than to wireless ones, dynamically measures loss rates
in order to favour lossless wireless links, favours routes
with non-interfering radio frequencies, and avoids
high-latency tunnels.
</t>
<t>
Obviously, such a wealth of information can lead to
contradictory data in edge cases; however, Babel's
loop-avoidance mechanisms ensure that the network remains in
a consistent state in all cases, and a hysteresis mechanism
ensures that, should a feedback loop occur, the frequency of
oscillations remains bounded <xref target="DELAY-BASED"/>.
</t>
</section>
</section>
<section title="Support for Attached Stub Networks">
<t>
A stub network is one that is attached to a HOMENET, possibly
through multiple HOMENET routers, but must not be used for
transit. For example, a stub network could be a sensor
network which would collapse under the HOMENET traffic should
it ever be used for transit.
</t>
<t>
In the following example, if the dotted link between C and D is
a stub network, then it must not be used for transit even if the
link between A and B fails:
</t>
<figure><artwork><![CDATA[
---- A ----- B -----
| |
| |
C ..... D
]]></artwork></figure>
<section title="IS-IS Support for Stub Networks">
<t>
In IS-IS reachability (prefixes) and topology
(links/adjacencies) are separate things. IS-IS supports
stub-networks as defined above simply by advertising the
prefix associated with a link, but not the link itself. This
is sometimes referred to as a "passive link".
</t>
</section>
<section title="Babel Support for Stub Networks">
<t>
Babel supports flexible filtering of routes, and a stub
network can be designated by simply setting up the necessary
filtering rules. For resource-limited deployments, a
minimalistic, stub-only implementation of Babel is
available.
</t>
</section>
</section>
<section title="Security Features">
<t>
[I think this section is badly written. We should just state
whether each protocol supports auth or encryption, and whether it
supports symmetric or something more exciting. -- jch]
</t>
<section title="Security Features in IS-IS">
<t>
IS-IS offers multiple levels of security from none, to
simple clear-text (password) authentication, to fully
generic cryptographic authentication using any number of
hashing algorithms (e.g., HMAC-MD5, HMAC-SHA1,
... HMAC-SHA512). Currently, the HOMENET implementation of
IS-IS uses the cleartext password set to a predefined value
for auto-configuration purposes.
</t>
</section>
<section title="Security Features in Babel">
<t>
Babel supports symmetric key authentication using an
extensible HMAC-based cryptographic authentication mechanism
<xref target="RFC7298"/>.
</t>
</section>
</section>
<section title="Support for Multicast">
<t>
Although the HOMENET WG has not yet determined whether to
support multicast in HOMENET Networks, it might be desirable
to pick a routing protocol that supports multicast, so that it
will be easier to add multicast support in the future.
</t>
<section title="Multicast Routing in IS-IS">
<t>
The IS-IS protocol supports multicast routing. However, none of
the available implementations include support for multicast.
</t>
</section>
<section title="Multicast Routing in Babel">
<t>
There is no support for multicast routing in Babel.
</t>
</section>
</section>
<section title="Implementation Status">
<t>
There are HOMENET implementations of both IS-IS and Babel.
</t>
<t>
The HOMENET implementation of IS-IS is the only IS-IS
implementation that supports source-specific routing, which is
a hard requirement for HOMENET. If source-specific routing is
not required, there are several independent, interoperable
proprietary implementations of IS-IS (all major router vendors
implement IS-IS). We are not aware of any production-quality
open-source implementation of IS-IS other than the HOMENET
one.
</t>
<t>
There are multiple open source implementations of Babel, two
of which support source-specific routing. All implementations
(except the stub-only version) were originally derived from
the same codebase.
</t>
</section>
<section title="Code and State Size">
<section title="IS-IS Code and State Size">
<t>
The HOMENET implementation of IS-IS consists of 7000 lines
of Erlang code and has an installed size of over 11MB. Its
initial memory usage (as reported by the operating system)
is 22MB, and its working set increases by XXX bytes for each
new edge in the network graph. To put these numbers into
perspective, in a network with XXX nodes each of which has
XXX neighbours, the HOMENET implementation of IS-IS requires
XXX bytes for its data structures.
</t>
<t>
The code size of IS-IS depends greatly on what aspects of
the protocol have been implemented. IS-IS supports multiple
address families as well as completely different protocol
stacks (OSI and IP), multiple area hierachical operation
with automatic virtual link support for repairing area
partitions, and multiple link types. Additionally many other
protocol features have been added over time to augment the
protocol or replace previous behavior. The protocol lends
itself well to not only extension, but pairing down of
features.
</t>
<t>
For HOMENET we need a level-1 only implementation supporting
a common topology for IPv4 and IPv6 over broadcast (i.e.,
ethernet) link types. Additionally, we only require support
of the latest extended metric TLVs (i.e., not implement
legacy metric support).
</t>
<t>
The operational state required by IS-IS is proportional to
the number of routers, links, and prefixes in the network.
Each router in the network generates and advertises a Link
State Protocol Data Unit (LSP) that describes it's attached
links and prefixes. A copy of each of these LSPs is stored
by each router in the network. IS-IS uses these LSPs to
construct a shortest-path-first (SPF) tree with attached
prefix information from which routes to the prefixes are
created.
</t>
<t>
Concrete numbers lacking.
</t>
</section>
<section title="Babel Code and State Size">
<t>
The source-specific implementation of Babel, which
implements many non-HOMENET extensions to the protocol,
consists of roughly 10000 lines of C and has an installed
size of less than 130kB on AMD-64. Its initial memory usage
(as reported by the operating system) is 300kB.
</t>
<t>
The amount of state stored by a Babel router is at worst one
routing table entry for each destination through each
neighbour. In the source-specific implementation, one
routing entry occupies roughly 100 bytes of memory. To put
these figures into perspective, in a network with 1000
nodes, a Babel router with 10 neighbours needs roughly a
megabyte of memory to store its routing table (not counting
malloc overhead).
</t>
<t>
The stub-only implementation of Babel consists of 900 lines
of C and compiles to 12kB (dynamically linked). Its memory
usage (as reported by the operating system) is 200kB, and
remains constant (it doesn't perform any dynamic memory
allocation).
</t>
</section>
<section title="Comparison">
<t>
<xref target="size-comparison"/> summarises the sizes of the
available HOMENET routing protocol implementations. (Data
courtesy of Steven Barth and Markus Stenberg.)
</t>
<texttable title="Comparison of HOMENET implementation size" anchor="size-comparison">
<ttcol align="center"/>
<ttcol align="center">babeld (source-specific)</ttcol>
<ttcol align="center">sbabeld (stub-only)</ttcol>
<ttcol align="center">AutoISIS</ttcol>
<c>Version</c>
<c>2598774</c>
<c>cc7d681</c>
<c>0.8.0</c>
<c>Date</c>
<c>2014-09-08</c>
<c>2014-11-21</c>
<c>2014-08-26</c>
<c>License</c>
<c>MIT</c>
<c>MIT</c>
<c>Apache 2.0</c>
<c>Lines of Code</c>
<c>10.000 (C)</c>
<c>1.000 (C)</c>
<c>7.000 (Erlang)</c>
<c>Installed size (AMD64)</c>
<c>129kB</c>
<c>13kB</c>
<c>11,385kB</c>
<c>Total installed size</c>
<c>129kB</c>
<c>13kB</c>
<c>14,155kB</c>
<c>Baseline RSS</c>
<c>~300kB</c>
<c>~200kB</c>
<c>~22,000kB</c>
</texttable>
<t>
In this table, "Installed size" is the size reported by the
package manager for the routing daemon's package(s) (including
the 1.6MB of the "Beam" Erlang VM in the case of IS-IS), while
"Total installed size" is the sum of the size of the deamon's
packages and all its dependencies, excluding the C library.
</t>
</section>
</section>
<section title="Performance on IEEE 802.11 Wireless Networks">
<section title="IS-IS Performance on 802.11">
<t>
IS-IS is in active use in in the Internet in large
non-hierachical (i.e., level-2 or single area level-1)
deployments with hundreds of nodes. The protocol has proven
to be very scalable.
</t>
<t>
[Do we have any information about the performance of IS-IS
on 802.11 networks, in particular? -- mrw]
</t>
</section>
<section title="Babel Performance on 802.11">
<t>
Babel has been carefully optimised for 802.11 networks. In
particular, it performs link quality estimations of wireless
links in a manner that works well with the 802.11 MAC. In
addition, Babel has provisions for estimating radio
interference <xref target="BABEL-Z"/>, which is essential
for providing decent throughput on multi-hop radio routes.
</t>
<t>
Babel was designed to work well on pure mesh networks
(networks where a packet might exit through the same
interface as the one it came from), but this is probably out
of scope for HOMENET.
</t>
</section>
</section>
<section title="Standardization Status">
<section title="IS-IS Standardization">
<t>
IS-IS is an ISO Standard documented in ISO/IEC 10589:2002.
There is an active IETF IS-IS Working Group (ISIS) that
maintains and extends the IS-IS protocol, and the IS-IS
protocol has been extended in several ISIS Working Group
documents.
</t>
<t>
The autoconfiguration and source-specific extensions to
IS-IS, which are both hard requirements for HOMENET, are
documented in (non-WG) Internet Drafts <xref
target="ISIS-AUTOCONF"/> <xref target="ISIS-SS"/>.
</t>
</section>
<section title="Babel Standardization Status">
<t>
Babel is documented in an Experimental RFC (RFC 6126)
published in 2011, and it has been updated in several
individual-submission RFCs and Internet Drafts. An Internet
Draft establishing an IANA registry of Babel extensions has
been submitted for publication as an RFC <xref
target="BABEL-EXT"/>.
</t>
<t>
The use of Babel in a Standards Track HOMENET RFC would require
a "downref" to non-Standards Track documents. It would also be
necessary to finish publishing the extensions that are needed
for the HOMENET use case as RFCs.
</t>
</section>
</section>
<section title="Evaluation of RFC 5218 Criteria">
<section title="Critical Success Factors">
<t>
Does the protocol exhibit one or more of the critical initial
success factors as defined in RFC 5218?
</t>
<section title="IS-IS Success Factors">
<t>
IS-IS exhibits the following critical initial success factors:
<list>
<t>Positive Net Value:
<list>
<t> Hardware cost: None. </t>
<t> Operational interface: Existing and extensive. </t>
<t> Retraining: None. </t>
<t> Business dependencies: None. </t>
</list>
</t>
<t>Incremental Deployment: Yes.</t>
<t>Open Code Availability: Yes. One implementation of the
HOMENET extensions, multiple proprietary implementations of
the base protocol.</t>
<t>Freedom from Usage Restrictions: Yes.</t>
<t>Open Specification Availability: Yes.</t>
<t>Open Maintenance Processes: Yes.</t>
<t>Good Technical Design: Proven with extensive deployment
and experience with the base protocol, little deployment of
the HOMENET extensions.</t>
<t>Extensible: Yes.</t>
<t>No Hard Scalability bound: Yes.</t>
<t>Threats Sufficiently Mitigated: Yes.</t>
</list>
</t>
</section>
<section title="Babel Success Factos">
<t>
Babel exhibits the following critical initial success factors:
<list>
<t>Positive Net Value:
<list>
<t> Hardware cost: None. </t>
<t> Operational interface: tcpdump and wireshark support,
dedicated monitoring software. </t>
<t> Retraining: None. </t>
<t> Business dependencies: None. </t>
</list>
</t>
<t>Incremental Deployment: Yes.</t>
<t>Open Code Availability: Yes. Multiple implementations
derived from a common source.</t>
<t>Freedom from Usage Restrictions: Yes.</t>
<t>Open Specification Availability: Yes.</t>
<t>Open Maintenance Processes: IANA registry in the process
of being created.</t>
<t>Good Technical Design: Yes.</t>
<t>Extensible: Yes.</t>
<t>No Hard Scalability bound: Yes.</t>
<t>Threats Sufficiently Mitigated: probably.</t>
</list>
</t>
</section>
</section>
<section title="Willing Implementors">
<t>
Are there implementers who are ready to implement the technology
in ways that are likely to be deployed?
</t>
<section title="IS-IS">
<t>
There is only one implementation of autoconfiguration and
source-specific routing for IS-IS. There are some other open
source implementations of the base protocol, but they are
incomplete (as of February 2015).
</t>
<t>
As all major routing vendors have (proprietary) IS-IS
implementations, the barrier for implmeneting IS-IS for
HOMENET use is probably manageable, assuming that the
willingness to implement modifications needed for HOMENET
use is present.
</t>
</section>
<section title="Babel">
<t>
The Babel implementation is open source software (MIT
licensed), and the codebase has proven of sufficiently high
quality to be easily extended by people who were not in direct
contact with the author <xref target="RFC7298"/>.
</t>
</section>
</section>
<section title="Willing Customers">
<t>
Are there customers (especially high-profile customers) who are
ready to deploy the technology?
</t>
<section title="IS-IS">
<t>
Yes. IS-IS is already widely deployed in operational networks.
</t>
</section>
<section title="Babel">
<t>
Source-Specific Babel is currently deployed as part of the
OpenWRT and CeroWRT operating systems. Additionally, the
current version is used as a testbed for the HOMENET
configuration protocol.
</t>
</section>
</section>
<section title="Potential Niches">
<t>
Are there potential niches where the technology is compelling?
</t>
<section title="IS-IS">
</section>
<section title="Babel">
<t>
Babel is a simple and flexible routing protocol. Like
most distance-vector protocols, it requires little to no
configuration in most topologies, and has proved popular
in scenarios where competent network administration was
not available. In addition, it has been shown to be
particularly useful in scenarios where non-standard
dynamically computed metrics are beneficial, notably
wireless mesh networks and overlay networks.
</t>
</section>
</section>
<section title="Complexity Removal">
<t>
If so, can complexity be removed to reduce cost?
</t>
<section title="IS-IS">
<t>
As mentioned previously IS-IS can be significantly and easily
pared down to fit the more limited scope of homenet use.
However, no such pared down implementation exists, and the
subset of the protocol that needs to be implemented has never
been formally defined.
</t>
</section>
<section title="Babel">
<t>
Babel is a fairly simple protocol -- RFC 6126 is just 40
pages long (not counting informative appendices), and it
has been successfully explained to fourth year university
students in less than two hours.
</t>
<t>
The stub-only implementation of Babel consists of 900
lines of C code, and has deliberately been kept as simple
as possible. We expect a competent engineer to get up to
speed with it within hours.</t>
</section>
</section>
<section title="Killer App">
<t>
Is there a potential killer app? Or can the technology work
underneath existing unmodified applications?
</t>
<section title="IS-IS">
<t>
As IS-IS already qualifies as successful (bordering on
wildly) a killer app is not particularly relevant.
</t>
</section>
<section title="Babel">
<t>
Since Babel requires virtually no configuration, it is
particularly suitable to scenarios where a dedicated
network administrator is not available. Additionally, its
support for dynamically computed non-standard metrics
makes it particularly appealing in highly heterogeneous
networks, (networks built on multiple link-layer
technologies with widely varying performance
characteristics).
</t>
</section>
</section>
<section title="Extensible">
<t>
Is the protocol sufficiently extensible to allow potential
deficiencies to be addressed in the future?
</t>
<section title="IS-IS">
<t>
IS-IS has been shown to be incredibly extensible,
originally designed for a completely different protocol
stack (OSI) it was easily adapted for IP use, then to
multiple address families (IPv4, IPv6) and
multi-topology. Indeed one of the major drivers of IS-IS's
success is its extensibility and adaptability.
</t>
</section>
<section title="Babel">
<t>
The extension mechanisms built into the Babel protocol
<xref target="BABEL-EXT"/> have been shown to be a solid
basis on which many backwards-compatible extensions have
been built, including one that fundamentally changes the
structure of announcements <xref target="BABEL-SS"/> and
one that needs a non-trivial extension to the space of
metrics <xref target="BABEL-Z"/>.
</t>
</section>
</section>
<section title="Success Predictable">
<t>
If it is not known whether the protocol will be successful,
should the market decide first? Or should the IETF work on
multiple alternatives and let the market decide among them?
Are there factors listed in this document that may predict
which is more likely to succeed?
</t>
<section title="IS-IS">
<t>
For IS-IS the market has already decided that the protocol
is successful in a fairly wide variety of
deployments. [We're speaking of source-specific,
autoconfiguring IS-IS here? And are we speaking of small,
unadministered networks? -- jch]
</t>
</section>
<section title="Babel">
<t>
Source-specific Babel is probably the only source-specific
routing protocol that has seen deployment and is being
used in production.
</t>
<t>
Plain Babel has seen a modest amount of deployment, most
notably for routing over wireless mesh networks and
large-scale overlay networks. However, it remains a young
protocol, certainly much younger than IS-IS.
</t>
</section>
</section>
</section>
<section title="Acknowledgments">
<t>
The authors are grateful for the input of Steven Barth, Denis
Ovsienko and Mark Townsley.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&rfc6126;
&rfc7298;
<reference anchor="BABEL-SS"><front>
<title>Source-Specific Routing in Babel</title>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier"/>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date year="2014" month="November"/>
</front>
<seriesInfo name="Internet Draft" value="draft-boutier-babel-source-specific-00"/>
</reference>
<reference anchor="SS-ROUTING" target="http://arxiv.org/abs/1403.0445">
<front>
<title>Source-sensitive routing</title>
<author initials="M." surname="Boutier" fullname="Matthieu Boutier"/>
<author initials="J." surname="Chroboczek" fullname="Juliusz Chroboczek"/>
<date year="2014" month="December"/>
</front>
</reference>
<reference anchor="BABEL-EXT"><front>
<title>Extension Mechanism for the Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date month="June" year="2013"/>
</front>
<seriesInfo name="Internet Draft" value="draft-chroboczek-babel-extension-mechanism-03"/>
</reference>
<reference anchor="BABEL-Z"><front>
<title abbrev="Babel Diversity Routing">Diversity Routing for the Babel
Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
<date year="2014" month="July"/>
</front>
<seriesInfo name="Internet Draft" value="draft-chroboczek-babel-diversity-routing-00"/>
</reference>
&rfc1142;
<reference anchor="DELAY-BASED" target="http://arxiv.org/abs/1403.3488">
<front>
<title>A delay-based routing metric</title>
<author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/>
<author fullname="Matthieu Boutier" initials="M." surname="Boutier"/>
<date year="2014" month="March"/>
</front>
</reference>
<reference anchor="ISIS-AUTOCONF"><front>
<title>ISIS Auto-Configuration</title>
<author fullname="B. Liu" initials="B." surname="Liu"/>
<date year="2014" month="October"/>
</front>
<seriesInfo name="Internet Draft" value="draft-liu-isis-auto-conf-03"/>
</reference>
<reference anchor="ISIS-SS"><front>
<title>IPv6 Source/Destination Routing using IS-IS</title>
<author fullname="F. J. Baker" initials="F. J." surname="Baker"/>
<author fullname="D. Lamparter" initials="D." surname="Lamparter"/>
<date year="2014" month="October"/>
</front>
<seriesInfo name="Internet Draft" value="draft-baker-ipv6-isis-dst-src-routing-02"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:38:00 |