<?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 rfc1195 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml'>
	  <!ENTITY rfc5304 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5304.xml'>
	  <!ENTITY rfc5305 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml'>
	  <!ENTITY rfc5308 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml'>
	  <!ENTITY rfc7368 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7368.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-02.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="March" 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="ISO10589"/> 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>
	[There has been a request that this document compare OSPF as
	well as Babel and IS-IS. If the WG would find that useful, we
	would need an OSPF expert who is willing to provide text on
	OSPF similar to the information that has been provided for
	IS-IS and Babel.]
      </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 most home networks are 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. There may be exceptions to the
        "no configuration" rule in some environments.  For instance,
        Homenet products may be used in environments where network
        security is important enough to warrant the configuration of
        security information, such as keys or certificates.  However,
        even in those environments, minimal configuration should be
        necessary to deploy a Homenet network.
      </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>
        A Plastic Home Router is usually equipped with a reasonable CPU but
        fairly small amounts of flash and RAM.  At the time of writing,
        a typical example of the bottom of the range has a 200MHz MIPS
        4KEc CPU (8kB data cache), but only 4MB of flash and 8MB of RAM.
        More expensive multi-purpose products may have a 700MHz MIPS 24Kc
        with 32MB of flash and as much as 128MB of RAM.
      </t>
      <t>
        We expect smaller devices to want to participate in the Homenet
        protocols.  In particular, some vendors have expressed interest in
        producing sensor-class hardware that is able to interoperate with
        Homenet (smart thermostats, home automation hardware, etc.).  It
        is therefore desirable to be able to scale down the Homenet
        protocols down to a few tens of kB, at least in a stub role.
      </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 at gigabit
        speed, IEEE 802.11 (WiFi) 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>
        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 it is desirable to use
        a protocol that scales well.
      </t>
    </section>
    <section title="Protocols and Extensions Included in Comparison">
      <t>
	Both the IS-IS and Babel protocols 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 <xref
	  target="ISO10589"/>, this comparison considers the following IS-IS
	  extensions:
	</t>
        <t>Homenet related specifications</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>
        <t>Base protocol specifications.</t>
        <t><list style="symbols">
          <t>
            Use of OSI IS-IS for Routing in TCP/IP and Dual
            Environments <xref target="RFC1195"/>
          </t>
          <t>
            IS-IS Extensions for Traffic Engineering <xref target="RFC5305"/>
          </t>
          <t>
            Routing IPv6 with IS-IS <xref target="RFC5308"/>
          </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 through the neighbor that 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="Discussion">
        <t>
          From a purely algorithmic point of view, both kinds of
          algorithms are known to scale well beyond the needs of Homenet.
          Issues of scaling over wireless and lossy links is discussed in
          <xref target="wireless"/>.
        </t>
      </section>
    </section>
    <section title="Convergence Times" anchor="convergence-time">
      <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 new link state 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>
          [According to Gredler, "today, 1000–2000 routers in a single
          area are said to represent the upper boundary of IS-IS [...] The
          authors do not endorse these optimistic area numbers, since
          a lot is dependent on other factors than just the raw number of
          routers." (p. 84).  And I'm pretty sure he's not thinking of
          200MHz CPUs with 8kB data caches, 802.11 and powerline. -- jch]
        </t>
        <t>
          We easily should expect sub-second convergence for any change in
          reachability (addition or subtraction) in any conceivable
          Homenet deployment that does not use IEEE 802.11 for
          router-to-router links (see <xref target="wireless"/>).
        </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, 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 2.5 hello intervals on Babel wired links (2.5*4s,
          i.e. 10s by default).  (Babel performs link quality estimation
          on wireless links, so the delay is a little higher when wireless
          links are involved.)
        </t>
        <t>
          This can be mitigated somewhat by using smaller timers, at the
          cost of higher overhead, especially on wireless links, which
          tend to suffer from abominable per-frame overhead.  IS-IS
          supports hold times as small as 1s, while Babel supports hello
          intervals as low as 10ms (leading to a 25ms hold time).  (Either
          protocol could of course be combined with BFD, which supports
          arbitrarily small hold times.)
        </t>
        <t>
          It has been suggested that physical layer carrier sense could be
          used to detect broken links in a timely manner.  Unfortunately,
          this technique is not useful in Homenet, since most Plastic Home
          Routers put their Ethernet ports behind an internal switch in
          order to provide 5 or more Ethernet ports using a single NIC:
          carrier sense indicates the status of the internal link to the
          switch, not that of the user-visible Ethernet link.  Carrier
          sense has also been found to be unreliable on wireless links.
        </t>
      </section>
    </section>
    <section title="Autoconfiguration" anchor="autoconf">
      <t>
        Most 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">
        <t>
          When combined with HNCP, both protocols are able to run in an
          unadministered network (but see also <xref target="metrics"/>).
        </t>
      </section>
    </section>
    <section title="Support for Source-Specific Routing"
             anchor="source-specific">
      <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">
        <t>
          Both protocols have been extended with support for
          source-specific routing.  The IS-IS extension is not able to
          coexist with non-extended implementations, but this is probably
          not a serious problem for Homenet.
        </t>
      </section>
    </section>
    <section title="Support for Link Metrics" anchor="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 model the notion
        of greater or lesser desirability of a link by a value called
        a metric; the smaller the metric, the more desirable the link.
      </t>
      <t>
        The following example illustrates the importance of assigning
        suitable metrics to links in a home network:
      </t>
      <figure><artwork><![CDATA[
      Internet --- A --- B....C          --- is Ethernet
                    .        .           ... is WiFi
                     ........
       ]]></artwork></figure>
      <t>
        A is the CPE (edge router), and lives in a storeroom.  B is the
        home's main router, lives in the living room, and is connected to
        A over Ethernet.  C is a wireless router in the guest room, or
        perhaps in the garden shed.  All the routers are equipped with
        wireless interfaces.
      </t>
      <t>
        Suppose that the wireless link B..C is solid, but the longer A..C
        link has very high packet loss.  Murphy's law dictates that the
        link A..C will be just good enough for the routing instances on
        A and C to become neighbours.  If the routing protocol doesn't
        take link quality into account in its metric computation, even if
        it is smart enough to prefer wired links to wireless ones, it will
        prefer the lossy route A..C to the solid route A-B..C.
      </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,
          the protocol is able to automatically include a number of
          sources of information in its metric computation.  The current
          implementation is able to automatically take the following
          criteria into account:
          <list style="symbols">
            <t>whether a link is wired or wireless;</t>
            <t>packet loss;</t>
            <t>link latency <xref target="BABEL-RTT"/>;</t>
            <t>intra-route radio interference <xref target="BABEL-Z"/>.</t>
          </list>
        </t>
        <t>
          This wealth of information can produce conflicting data in edge
          cases.  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 title="Discussion">
        <t>
          Babel has reasonably good support for dynamically computed
          metrics for IEEE 802.11 links and high-latency tunnels.  The
          current implementation doesn't have explicit support for
          variable-speed Ethernet and Powerline Ethernet, both
          technologies are bundled into a single "good quality link"
          category.
        </t>
        <t>
          Current implementations of IS-IS will supply a default metric for
          links if not configured. We are unaware of any implementation that
          computes this default metric dynamically, rather it is static and
          supplied by the vendor. While
          support for dynamically computed metrics could potentially be
          added to IS-IS, this is not completely trivial to do right,
          since a naive approach would cause unacceptable churn,
          potentially leading to repeated SPF computations and transient
          microloops.  Suitable mitigation techniques could probably be
          developed, but they would likely be different from the
          mitigation techniques that work well in Babel, since the
          link-state algorithm used by IS-IS and the triggered updates
          used by Babel have fundamentally different dynamics.
        </t>
      </section>
    </section>
    <section title="Support for Stub Networks and Stub Routers" anchor="stub">
      <t>
        A stub network is one that is attached to a Homenet, possibly
        through multiple Homenet routers, but must not be used for
        transit.  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>
      <t>
        Similarly a stub router is a router which may advertise and be a
        destination for stub networks but should never be used for transit
        traffic.
      </t>
      <t>
        A number of people have expressed interest in attaching sensor
        class equipment to Homenets, such as smart thermostats and home
        automation hardware.  Presumably, the sensor-class devices will
        run over a dedicated low-power link (e.g. IEEE 802.15.4), with
        a small number of devices acting as gateways between the homenet
        and the low power network.  Ideally, the gateway nodes would not
        be dedicated devices, but merely sensor nodes that happen to have
        been equipped with an Ethernet or WiFi interface.
      </t>
      <t>
        Since low power links have orders of magnitude lower throughput
        than Homenet links, routing Homenet traffic through the low power
        link would cause it to collapse.  Designating this link as a stub
        network avoids this issue.
      </t>
      <section title="IS-IS Support for Stub Networks and Stub Routers">
        <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>
        <t>
          Further an IS-IS router has the ability to set a bit (the
          overload bit) to indicate that it should not be used for any
          transit traffic, and that it will only be considered a
          destination for the prefixes it has advertised, i.e., it is
          a stub router as defined above. As per the IS-IS standard
          <xref target="ISO10589"/> an IS-IS router marked as such is
          not expected to participate in the propagation of link state
          or the SPF computation.
        </t>
      </section>
      <section title="Babel Support for Stub Networks">
        <t>
          As all distance vector protocols, Babel supports fairly
          arbitrary route filtering.  Designating a stub network is done
          with two statements in the current implementation's filtering
          language.
        </t>
        <t>
          For resource-limited deployments, a minimalistic, stub-only
          implementation of Babel is available that consists of less than
          1000 lines of C code that compile to a dozen kilobytes of text.
          Just like the standard implementation, the stub implementation
          is mostly portable code, and should be easily ported to any
          embedded environment that supports the "sockets" API.
	</t>
      </section>
      <section title="Discussion">
        <t>
          A tiny, stub-only implementation of Babel is available.
        </t>
        <t>
          A tiny, stub-router-only implementation of IS-IS is
          available. This is the "tinyisis" referred to later in the
          document when comparing implementation sizes.
        </t>
      </section>
    </section>
    <section title="Support for non-IEEE 802.2 link layers">
      <t>
        Most link technologies employed in a Homenet use the IEEE
        802.2 frame format; this is notably the case of Ethernet, IEEE
        802.11 and common powerline technologies.  However, other
        framing formats exist, and at least PPP, PPPoE, IEEE 802.15.4,
        GRE and various VPN technologies are likely to be used in
        Homenets.
      </t>
      <section title="IS-IS">
        <t>
          IS-IS is built directly above the link layer (IS-IS control
          data is not encapsulated within IP packets), and therefore
          needs explicit support for every type of lower layer
          encapsulation.  It is not known what particular kinds of
          framing the Homenet implementation of IS-IS supports.
        </t>
      </section>
      <section title="Babel">
        <t>
          Babel is built above UDP over link-local IPv6, and is able to
          run with no modifications over any link that supports IPv6.
        </t>
      </section>
    </section>
    <section title="Security Features">
      <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 <xref target="RFC5304"/>. 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"/>.  This mechanism is not vulnerable to
          replay attacks.
	</t>
      </section>
      <section title="Discussion">
        <t>
          Both protocols support password authentication.  This
          probably provides the necessary hooks for the Homenet
          Configuration Protocol (HNCP) to implement whatever security
          policies are required by Homenet.
        </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 title="Discussion">
        <t>
          Some experts believe that it may be better to run a
          dedicated multicast routing protocol rather than extensions
          to a unicast routing protocol.
        </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>
          [Does that mean that we don't care about PPP, PPPeE, GRE
          etc?]
        </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 13kB (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>
        <t>
          The stub-only implementation of IS-IS consists of 1300 lines
          of C and compiles to 18kB (stripped and dynamically linked).
          Its base memory usage (as reported by 32-bit linux) is
          330kB.
	</t>
      </section>
      <section title="Comparison">
        <t>
          <xref target="size-comparison"/> summarises the sizes of the
          available Homenet routing protocol implementations.  (Babel 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 (SS)</ttcol>
          <ttcol align="center">sbabeld (stub)</ttcol>
          <ttcol align="center">AutoISIS (SS)</ttcol>
          <ttcol align="center">tinyisis (stub)</ttcol>

          <c>Version</c>
          <c>2598774</c>
          <c>cc7d681</c>
          <c>[update]0.8.0</c>
          <c>3ed2068</c>

          <c>Date</c>
          <c>2014-09-08</c>
          <c>2014-11-21</c>
          <c>2014-08-26</c>
          <c>2015-02-22</c>

          <c>License</c>
          <c>MIT</c>
          <c>MIT</c>
          <c>Apache 2.0</c>
          <c>Apache 2.0</c>

          <c>Lines of Code</c>
          <c>10000 (C)</c>
          <c>1000 (C)</c>
          <c>7000 (Erlang)</c>
          <c>1300 (C)</c>

          <c>Installed size (AMD64)</c>
          <c>129kB</c>
          <c>13kB</c>
          <c>732kB</c>
          <c>17kB</c>

          <c>Total installed size</c>
          <c>129kB</c>
          <c>13kB</c>
          <c>7MB</c>
          <c>17kB</c>

          <c>Baseline RSS</c>
          <c>~300kB</c>
          <c>~200kB</c>
          <c>11MB</c>
          <c>330kB</c>
        </texttable>
        <t>
          In this table, "Installed size" is the size reported by the
          package manager for the routing daemon's package(s), while
          "Total installed size" is the sum of the size of the deamon's
          packages and all its dependencies, excluding the C library.
        </t>
        <t>
          The erlang AutoISIS has not been optimized for space or
          features (i.e., it is a full IS-IS multilevel multi-address
          family implementation). One example of how this affects the
          reported numbers, is that the erlang logging package is
          taking up 4MB of ram.
        </t>
        <t>
          Additionally, as erlang is interpreted and not compiled as
          with the C implementations, there's not much use in directly
          comparing the numbers themselves.
        </t>
        <t>
          [We should add the size of the native Quagga isisd.  While this
          implementation is incomplete and doesn't support the Homenet
          extensions, it should give us an idea how much we can hope to
          scale IS-IS down.  It's roughly 20000 lines of C, not counting
          the additional 20000 for zebra. -- jch]
        </t>
      </section>
    </section>
    <section title="Ease of porting">
      <t>
        If successful, the Homenet protocols will be implemented on exotic
        devices, such as sensor-class devices, set-top boxes and mobile
        phones.  Rather than a full Unix system, such devices sometimes
        provide a more exotic environment, such as an embedded operating
        system or one designed for mobile phones.
      </t>
      <section title="IS-IS ease of porting">
        <t>
          As IS-IS runs directly over layer 2, an implementation needs to
          be able to send and receive layer 2 frames itself.  On Unix
          systems, this can be done using raw sockets or by hooking into
          the Berkeley Packet Filter.  Such interfaces might not be
          available on non-Unix systems, and even on Unix are restricted
          to priviledged processes.
        </t>
      </section>
      <section title="Babel ease of porting">
        <t>
          Babel is layered above UDP.  Except for a thin layer interfacing
          to the kernel, the reference implementation of Babel consists of
          portable code using the familiar "sockets" API (RFC 3493).
          Enabling forwarding and manipulating the kernel's routing tables
          is the only priviledged operation it performs.
        </t>
        <t>
          Babel has been successfully ported to Android.  Android does not
          currently allow unpriviledged code to manipulate the kernel's
          routing table, so Babel can only run on "rooted" phones.  Should
          a future version of Android provide the ability to manipulate
          the kernel's routing table, Babel could conceivably be packaged
          as an installable "app".
        </t>
      </section>
      <section title="Discussion">
        <t>
          IS-IS is somewhat difficult to port, due to the requirement for
          raw sockets.  Except for the requirement to install routes,
          Babel is portable code, and has been successfully ported to
          Android.
        </t>
      </section>
    </section>
    <section title="Behaviour upon resource exhaustion">
      <section title="IS-IS">
        <t>
          The IS-IS protocol has an overload indicator. When the
          protocol is unable to acquire a needed resource, it enters
          overloaded state. This state is signaled to the other
          routers and the overloaded router is considered to be
          destination only (i.e., it becomes a stub router).
        </t>
      </section>
      <section title="Babel">
        <t>
          Babel degrades gracefully.  Since Babel is a distance-vector
          protocol, a Babel implementation can simply drop excess routes
          when it runs out of memory.  As long as the default route is not
          discarded, connectivity will be degraded but not completely
          lost.
        </t>
        <t>
          The current implementation of Babel discards redundant routes
          before it starts dropping announcements, but doesn't yet
          prioritise the default route.  (This behaviour was tested when
          somebody redistributed the entire IPv6 default-free zone into
          a Babel network.  We had a lot of fun that day.)
        </t>
      </section>
    </section>
    <section title="Performance and scaling on IEEE 802.11 Wireless Networks"
             anchor="wireless">
      <t>
        We expect wireless networks, and notably IEEE 802.11 wireless
        networks, to be in wide use in Homenets, not only for client
        connections but also for router-to-router connections.  In fact,
        some of us believe that the ability to cheaply and easily extend
        wireless coverage by adding a wireless router is a "killer feature"
        of Homenet, one that is easy to explain both to one's boss and to
        end users.
      </t>
      <t>
        IEEE 802.11 has some rather unpleasant performance
        characteristics.  First, wireless links are of very variable
        quality.  Second, multicast traffic is sent at a lowest common
        denominator speed, typically 2Mbit/s, which makes multicast
        outrageously expensive (13ms for a full-size frame).  Third,
        multicast traffic is not protected by link-layer ARQ, which makes
        multicast packet drops very common, especially in the presence of
        collisions, which are particularly likely when the routing
        protocol is in the process of reconverging.
      </t>
      <t>
        This has some consequences for routing protocols:
        <list style="symbols">
          <t>
            the routing protocol must be able to deal with varying link
            qualities (see <xref target="metrics"/>);
          </t>
          <t>
            if the routing protocol uses multicast for transmitting
            control data, it must deal gracefully with packet loss
            during reconvergence;
          </t>
          <t>
            the routing protocol must avoid sending large bursts of
            multicast traffic from multiple nodes simultaneously during
            reconvergence.
          </t>
        </list>
      </t>
      <t>
        IEEE 802.11 has two main modes of operation.  In
        "infrastructure mode", a small number of "access points"
        (APs), often just one, communicate with a number of "stations"
        (STAs); communication between two stations transits through
        one or at most two APs.  In "IBSS mode" (also called "ad hoc
        mode"), communication is unrestricted, and any node can
        directly communicate with any other node in range; as there is
        no link-layer forwarding, IBSS mode does not guarantee that
        communication is transitive.  Virtually all home network
        deployments today use infrastructure mode, with the router
        acting as AP and client devices acting as stations.  We
        believe that IBSS may be out of scope for Homenet, but we
        expect that people will attempt to use the Homenet protocols
        in IBSS mode, whether we like it or not.
      </t>

      <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>
          We are not aware of any results in the open litterature about
          the behaviour of IS-IS over IEEE 802.11.  In particular, we do
          not know how IS-IS's reliable flooding mechanism behaves over
          IEEE 802.11.
        </t>
      </section>
      <section title="Babel Performance on 802.11">
	<t>
          Babel has been carefully optimised for IEEE 802.11 networks.
          While Babel transmits most control data over multicast, it
          applies large amounts of random jitter (on the order of
          seconds) to all but its most urgent control messages.
          Roughly speaking, Babel sends in a timely manner those
          control messages that are likely to repair a broken route,
          but delays sending those messages that merely announce a
          slightly better route than one that is already available.
          This mechanism has been shown to work well in dense wireless
          deployments, with recent versions of Babel being able to
          avoid link-layer meltdowns even when a whole network is
          being rebooted simultaneously.
        </t>
        <t>
          As explained in <xref target="metrics"/>, Babel performs
          link quality estimation on wireless links in a manner that
          works relatively well with the 802.11 MAC.  In addition,
          Babel has provisions for estimating radio interference <xref
          target="BABEL-Z"/>, which is necessary in order to provide
          decent throughput on multi-hop radio routes.
        </t>
        <t>
          Babel has been designed to work well in IBSS mode, where
          communication is not transitive and therefore a packet may be
          routed through the same interface it was received on.
        </t>
      </section>
      <section title="Discussion">
        <t>
          Babel has been designed with wireless networks in mind, and
          has been shown to work reasonably well even in the extremely
          hostile environment of wireless mesh networks built over
          IEEE 802.11 in IBSS ("ad hoc") mode.
        </t>
        <t>
          We are not aware of any results about the behaviour of
          IS-IS's reliable flooding sub-protocol over IEEE 802.11
          multicast.  IS-IS will not work over IEEE 802.11 IBSS mode
          without changes, since both the pseudonode optimisation and
          DIS election assume that communication is transitive.
        </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
	  <xref target="ISO10589"/> There is an active IETF IS-IS
	  Working Group (isis-wg) that maintains and extends the IS-IS
	  protocol, and the IS-IS protocol has been extended in
	  several IS-IS 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 7368 Criteria">
      <t>
        Section 3.5 of <xref target="RFC7368"/> lists a set of
        criteria that the Homenet routing protocol must satisfy.
      </t>
      <t><list style="symbols">
        <t>border discovery: out of scope, as this is done by HNCP.</t>
        <t>self configuring: both protocols are self-configuring, see
        <xref target="autoconf"/>.</t>
        <t>behaviour during reconfiguration and reconvergence:
        <list style="symbols">
          <t>both protocols are able to establish adjacencies and to route
          IPv6 before they even receive an IPv6 address due to their use
          of stable neighbour identifiers;</t>
          <t>Babel will avoid creating loops even during reconvergence, but
          might create temporary blackholes;</t>
          <t>IS-IS may create short-lived loops during reconvergence;</t>
          <t>since HNCP doesn't depend on unicast, in principle it is not
          impacted by the routing protocol's behaviour during
          reconvergence; however, on a wireless network, the interference
          caused by routing loops may delay HNCP's reconvergence.</t>
        </list> </t>
        <t>the Homenet routing protocol should be based on a previously
        deployed protocol:
        <list style="symbols">
          <t>IS-IS is more widely deployed in carrier networks,</t>
          <t>there is more experience with running Babel on Plastic
          Home Routers</t>
          <t>Only the Babel implementation of source-specific routing has
          seen any deployment.</t>
        </list></t>
        <t>support for IPv4: both protocols are intrinsically double-stack --
        a single routing instance is able to carry both IPv6 and IPv4.</t>
        <t>multiple types of physical interfaces must be accounted for:
        only Babel is able to differentiate between different link
        technologies, see <xref target="metrics"/>; nothing is known about
        IS-IS's behaviour on wireless links.</t>
        <t>minimising convergence time: both protocols converge fast, see
        <xref target="convergence-time"/>.</t>
        <t>support the generic use of multiple Internet connections: both
        protocols support source-specific routing, see
        <xref target="source-specific"/>.</t>
        <t>scalable to higher hop counts: both protocols have reasonably
        wide metrics (24 bits in IS-IS, 16 bits in Babel).</t>
        <t>support for attached LLNs and other non-transit networks: both
        protocols are able to designate a link as non-transit.  Tiny
        stub implementations of Babel and IS-IS are available.  
        See <xref target="stub"/>.</t>
        <t>support for Multicast: IS-IS is able to carry multicast routes,
        Babel is not.</t>
      </list></t>
    </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 style="symbols">
              <t>Positive Net Value:
              <list style="symbols">
                <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 Factors">
          <t>
            Babel exhibits the following critical initial success factors:
            <list style="symbols">
              <t>Positive Net Value:
              <list style="symbols">
                <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>
          <t>
            With the exception of a small number of functions used for
            interfacing with the kernel's routing tables, Babel is
            portable code, and is easily ported to any environment
            that supports the familiar "sockets" API.
          </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">
	  <t>
	    [TBD]
	  </t>
        </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 used to build a
            number of extensions, including one that significantly
            extends 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>
          <t>
            All Babel extensions that have been defined interoperate
            with the original protocol, as defined in RFC 6126, to the
            extent possible.  For example, a router that doesn't
            implement the radio interference extension will just
            ignore the frequency information attached to route
            updates, which may lead to slightly sub-optimal routing
            but will cause neither blackholes nor routing loops.  To
            the contrary, a router that doesn't support the
            source-specific extensions will silently ignore any
            source-specific update, and therefore route according to
            the non-specific subset of available routes, which might
            cause blackholes, but under no circumstances will cause
            routing loops.  Backwards compatibility provisions are
            described in Section 4 of <xref target="BABEL-EXT"/>.
          </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.
          </t>
        </section>
        <section title="Babel">
          <t>
            Plain (non-source-specific) Babel has seen a modest amount
            of deployment, most notably for routing over wireless mesh
            networks and intercontinental overlay networks.  Babel is
            included as an installable package in many Linux
            distributions, which makes it easily available to
            interested parties.
          </t>
          <t>
            Source-specific Babel is probably the only source-specific
            routing protocol that has seen any deployment.
            Source-specific Babel is available as an installable
            package for OpenWRT, and is used by default by CeroWRT.
          </t>
        </section>
      </section>
    </section>
    <section title="Acknowledgments">
      <t>
        The authors are grateful for the input of Steven Barth, Denis
        Ovsienko, Mark Townsley, and Curtis Villamizar.
      </t>
    </section>
  </middle>
  <back>
    <references title="Informative References">
      &rfc6126;

      &rfc7298;

      &rfc7368;

      <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>

      <reference anchor="BABEL-RTT"><front>
        <title>Delay-based Metric Extension for the Babel Routing Protocol</title>

        <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/>
        <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
        <date year="2014" month="July"/>
        </front>
        <seriesInfo name="Internet Draft" value="draft-jonglez-babel-rtt-extension-00"/>
      </reference>

      <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>
      <reference anchor="ISO10589">
        <front>
          <title>Intermediate system to Intermediate system intra-domain
          routeing information exchange protocol for use in conjunction with the
          protocol for providing the connectionless-mode Network Service (ISO
          8473) Second Edition</title>
          <author>
            <organization>ISO/IEC</organization>
          </author>
          <date year="2002" month="Novmeber"/>
        </front>
        <annotation>ISO 10589:2002 Second Edition</annotation>
      </reference>
      &rfc1195;
      &rfc5304;
      &rfc5305;
      &rfc5308;
    </references>
  </back>
</rfc>
