[homenet] draft-mrw-homenet-rtg-comparison-01

[Curtis Villamizar <[e-mail]>]

Hi,

This is a review of draft-mrw-homenet-rtg-comparison-01.

Thanks for the good work.

Curtis


A note of format of this email.  I've used the OLD: and NEW: markers
rather than unified diff.  I indented the works OLD and NEW with one
space.  When quoting text, I indented the section headings two spaces
to make it clear it is quoted text.  The body of the text is indented
three spaces as done in the internet-draft txt file.

Most important is that if this were to become a WG doc and the WG has
for some reason excluded OSPF, this document should evaluate OSPF as
well as ISIS and say why OSPF was not considered.

  Abstract

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

I will comment on this document with the assumption that OSPF will be
covered in the future.  So starting with the abstract, please addd
OSPF.

  1.  Introduction

   This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel
   [RFC6126] according to several criteria related to their use in home
   networks (HOMENETs), as defined by the HOMENET WG.

Again, please add OSPF.

   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.

This document would be a useful document if it were accurate and
became a WG document.  A final section with WG recommendations could
be added (optional) if there were WG concensus.

 OLD:

   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.

 NEW:

   The HOMENET environment is different from the environment of a
   professionally administered network.  The most obvious difference
   is that the vast majority of 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.  The option to augment protocol mechaisms
   with configuration is needed in a subset of home networks, small
   home offices, or small businesses which may use the mechanisms
   designed with the HOMENET environment in mind.  At the very
   minimum, it should be possible to provide configuration to insure
   robust network security.

 DIFF:

   Not all homenets will be configuration free.  Homenet should also
   be applicable to soho and small business.  At the very least
   security configuration (keys, passwords, pass phrases) should be
   configurable.  We don't want HOMENET and security to be mutually
   exclusive.

 OLD:

   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.

 NEW:

   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 accomodate routers with limited capability as well
   as legacy routers and switches will encourage wider adoption.
   Legacy Ethernet routers which can only NAT from an assumed WAN port
   and act as an Ethernet switch on an assumed LAN side may only be
   useful as an Ethernet switch, but only if their DHCP server can
   easily be disabled.  Some legacy Wifi routers may only be useful as
   a stub WiFi AP, performing an unecessary redundant NAT.

 DIFF:

   Last sentence become a new paragraph.  The new text (or some
   concensus variation) may provide better description of the
   usefulness (or lack of) of limited functionality homenet devices
   and legacy devices.

Note on this:

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

I have no idea what is reasonable for LOPAN networks.  Has there been
much (or any) deployment of ROLL WG protocols in consumer devices?

 OLD:

   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.

 NEW:

   The target use cases for the HOMENET environment is primarily but
   not exclusively the relatively simple home network.  In its most
   simple form, there is only one router.  The emphasis on routing
   rather than bridging would make any home network with both Ethernet
   and WiFi at least a two subnet network.  Any home network may have
   separate CPE router and WiFi AP (or APs) or have local per room
   routers or deskside routers, and therefore have multiple routers.
   Small home offices and small business are also target use cases for
   the HOMENET environment, therefore the number of routers may
   further increase.  Networks with more than a few hundred routers
   are considered well beyond HOMENET scaling targets.  Subnets with
   more than a few hundred host per subnet are also beyond scaling
   targets.

 DIFF:

   Please consider this rewording.  It should be clear that multiple
   subnets and multiple routers are very much in scope.  It should
   also be clear that scaling targets for "plastic routers" have to be
   set at some reasonable size.

Regarding this:

  2.  Protocols and Extensions Included in Comparison

   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.

Please add OSPF.

  2.1.  IS-IS Protocol and Extensions

Note that like OSPF, ISIS also support router capabilities, multiple
address families, dynamic host name exchange, etc.  Some of these
would be useful in the homenet.

I've also listed performance optimizations for OSPF that are backward
compatible (yielding the prior performance levels).  ISIS has a lot of
these as well, since there is tons of experience in very demanding
environments using ISIS or OSPF.

  2.3.  OSPF Protocol and Extensions

   In addition to the base OSPFv3 Protocol specification (RFC 5340),
   this comparison considers the following OSPF extensions:

   o  OSPF Refresh and Flooding Reduction in Stable Topologies [RFC 4136],

   o  Authentication/Confidentiality for OSPFv3 [RFC 4552],

   o  OSPF Database Exchange Summary List Optimization [RFC 5243],

   o  The OSPF Opaque LSA Option [RFC 5250],

   o  OSPF Link-Local Signaling [RFC 5613],

   o  Dynamic Hostname Exchange Mechanism for OSPF [RFC 5642],

   o  Support of Address Families in OSPFv3 [RFC 5838],

   o  OSPF Stub Router Advertisement [RFC 6987],

   o  Supporting Authentication Trailer for OSPFv3 [RFC 7166],

   o  OSPFv3 Auto-Configuration [draft-ietf-ospf-ospfv3-autoconfig],

   o  OSPFv3 LSA Extendibility [draft-ietf-ospf-ospfv3-lsa-extend-06],

   o  Extensions to OSPF for Advertising Optional Router Capabilities
      [draft-ietf-ospf-rfc4970bis-00] (for now RFC 4970),

   o  OSPFv3 over IPv4 for IPv6 Transition
      [draft-ietf-ospf-transition-to-ospfv3-00],

   RFC 4136 and RFC 5243 are optional performance optimizations.  RFC
   5613 supports link local signaling that does not need to be flooded
   beyond the link scope.  The OSPF Standardization Report [RFC 2329]
   reflects the widespread deployment of OSPF by 1998 as well as
   having met the IETF very high bar of Full Standard.

Note on this section:

  3.  Routing Algorithms

Besides repeating the refrain about add OSPF...

Further down I'm going to suggest adding a section on mixed
environments and why they might be an option for homenet.

  3.1.  Link State Algorithm

   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.

   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.

 OLD:

   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.

 NEW:

   The link state information is known as the Link State Database
   (LSDB).  Except for information with link local scope, the LSDB is
   identical on all routers within the same OSPF area.  The flooding
   algorithm and LSDB provides an efficient means to distribute other
   information related to routing or topology.  Care must be taken in
   defining extensions not to make inappropriate use of this
   capability.

 DIFF:

   LSDB should be mentioned.  The prior text makes it appear that an
   application can easily add information to an LS protocol and break
   it.  Both ISIS and OSPF are very robust.

Next subsection looks good.

  3.2.  Loop-Avoiding Distance-Vector Algorithm (Babel)

Not so much here:

  3.3.  Algorithm Comparison

   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.

   Link state algorithms scales to very large, very dense networks.

The above is oversimplified but I suppose correct enough.

Perhaps add:

   Scaling is not expected to be a problem for the DV and LS
   protocols considered here.

 OLD:

   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.

 NEW:

   IS-IS distributes link and prefix information for each node in a
   single Link State Protocol Data Unit (LSPDU) which is distributed
   as one or more LSPDU fragments.  In large topologies or where a
   subset of information changes frequently use of multiple fragments
   is beneficial.  Where no change to an LSPDU fragment is made, only
   the LSPDU fragment checksum has to be checked.

   OSPF distributes link and prefix information in router and network
   Link State Advertisements (LSAs) as well as Opaque LSA used by OSPF
   extensions.  

Next section:

  4.  Convergence Times

 OLD:

  4.1.  IS-IS

   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.

   We easily should expect sub-second convergence for any change in
   reachability (addition or subtraction) in any conceivable homenet
   deployment.

 NEW:

  4.1  IS-IS and OSPF

   Given fast flooding of any change in the network, IS-IS and OSPF
   have 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.

   With much smaller topologies and no geographic delays limiting
   flooding time we easily should expect well below 100 ms convergence
   in any conceivable homenet deployment.

Regarding this:

  4.2.  Babel

   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.

Almost instantaneously?  Oh come on.  See below.

  4.3.  Discussion

   All three 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 can be dwarfed by the
   amount of time needed to detect a link failure, if poorly
   configured.

   The hold times in IS-IS and OSPF are 30s by default.  Where these
   hold times are used for detection they are turned down to 3
   seconds, though even this is considered slow.  In service provider
   deployments Bidirectional Forwarding Detection (BFD) [RFC 5880] is
   commonly used for fault detection in the rare case where layer-2
   information is unavailable in a service provider link.

   BFD packets can in principle be sent in as little as microsecond
   intervals.  BFD is capable of detection in a few milliseconds on
   some hardware but at the cost of a high rate of BFD packets.
   BFD supports negotiation of timers among neighbors.  A router with
   a slower CPU can therefore force a slower timer to avoid overload.

   If BFD is used on wireless networks, timers must be reduced
   substantially.  This can be automatic and an AP can renegotiate
   timers at any time in response to an increase in the number of
   stations or in response to congestion.

   Babel fault detection occurs in 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.)

Most service providers use some form of FRR, either RFC 4090 MPLS FRR
(most robust), or IP FRR, or LDP FRR.  With this they get <50 ms
protection (including detection time which is typically on the order
of 10 ms) followed by < 200ms IGP convergence yielding and possibly a
few second RSVP-TE convergence.  After protection kicks in and during
the convergence time packets continue to flow.  Convergence is then an
optimization.  Both RSVP-TE and LDP are loop free.

Obviously homenet neither needs this fast protection or could afford
the protocol machinery in the "plastic router".

There was just recently a brief discussion of a LQM like capability
for wireless.  This could be used by anything, Babel, ISIS, or OSPF.
For Ethernet, BFD seems the best bet if we need under 3 second fault
detection.  Otherwise set the hello timer to 1 sec and get 3 sec fault
detection.  In both ISIS and OSPF, the timer can be negociated so a
slow CPU can increase it.  I think in both cases it can't be changed
once it has been negociated.

 OLD:

  5.  Autoconfiguration

   Home networks are not administered, so a routing protocol needs to be
   entirely self-configuring in order to be suitable for HOMENETs.

 NEW:

  5.  Autoconfiguration

   Most home networks are not administered, so a routing protocol
   needs to be entirely self-configuring in order to be suitable for
   HOMENETs.

 DIFF:

   Add "Most".

 OLD:

  5.1.  IS-IS

   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
   [ISIS-AUTOCONF], to set this value.

 NEW:

  5.1.  IS-IS

   The only required configuration for IS-IS and OSPF is a unique
   area/system identifier.  An implementation of ISIS may use the
   autoconfiguration extension defined in [ISIS-AUTOCONF], to set this
   value.  An OSPF implementation may use the autoconfiguration
   extension defined in [draft-ietf-ospf-ospfv3-autoconfig].

Note that the ISIS extension is an individual submission while the
OSPF extension is in the RFC editor's queue.

Next subsection seems file:

  5.2.  Babel

   Babel is a fully self-configuring protocol -- the standard
   implementation of Babel only requires a list of interfaces in order
   to start routing.

Add new subsection:

 OLD:

  5.3.  Discussion

 NEW:

  5.3.  Mixed deployment

   It is common in service providers to mix ISIS and OSPF.  This is
   easily done be importing the routers from one routing protocol
   instance into the other as external routes.  It is more difficult
   to make the combined topology appear to either protocol to be a
   single area as this requires translation of LSDB information.
   EIGRP routes have also been carried as external routes.

   Using the technique of importing the routers from another routing
   protocol, either ISIS or OSPF could carry Babel routes and export
   reachability to ISIS or OSPF routes into Babel.  In OSPF and ISIS
   internal routes (intra-area or inter-area in OSPF or same level in
   ISIS) are preferred over external routes.  This would work well if
   ISIS or OSPF were used over Ethernet and Babel used over wireless.

  5.4.  Discussion

Next section:

  6.  Support for Source-Specific Routing

 OLD:

   Both Babel and IS-IS have extensions for source-specific routing.

 NEW:

   Both Babel and IS-IS have extensions for source-specific routing.
   Adding such an extension to OSPF would be easy.  Both ISIS and OSPF
   also have multitopology (MT) support which could also be used to
   support source-specific routing.

Note: MT might be a better solution.  One TLV maps the source prefix
to a topology identifier (an integer).  This also maps well into the
Linux and BSD implementations of multiple routing tables with an index
for each routing table, and the default being zero.  Perhaps another
thing for the WG to discuss.

Given the above I won't touch this section for now:

  6.1.  Source-Specific Routing in IS-IS

   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.

This is fine:

  6.2.  Source-Specific Routing in Babel

   The Source-specific extension to the Babel routing protocol
   [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).

   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 [SS-ROUTING].

  6.3.  Discussion

Nothing here except include OSPF:

  7.  Support for Link Metrics

   [...]

  7.1.  Link Metrics in IS-IS

   [...]

  7.2.  Link Metrics in Babel

   [...]

  8.  Support for Attached Stub Networks

   [...]

Some changes here:

  8.1.  IS-IS and OSPF Support for Stub Networks

   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 a
   peer adjacency.

   In addition, OSPF supports the stub routers.  The equivalent in
   ISIS can be achieved by setting very high metrics on the links to
   the stub router so that it is not used for transit.

Nothing here:

  8.2.  Babel Support for Stub Networks

   [...]

Regarding this:

  9.  Security Features

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

I agree it needs work.  Later.

Therefore skip to:

  10.  Support for Multicast

   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.

  10.1.  Multicast Routing in IS-IS

   The IS-IS protocol supports multicast routing.  However, none of the
   available implementations include support for multicast.

OSPFv3 also support IPv4 and IPv6 multicast.

  10.2.  Multicast Routing in Babel

   There is no support for multicast routing in Babel.

Maybe it would be better to run a multicast routing protocol than
ISIS, OSPF, or Babel extensions.

  11.  Implementation Status

   There are HOMENET implementations of both IS-IS and Babel.

How do you define a HOMENET implementation?

There are open source implementations of ISIS, OSPF, and Babel.  Some
have been linked in with the openwrt code.  openwrt != homenet; but
its nice to see open code on a plastic router.

I'm not sure if there are any open source ospf-zero-conf
implementations.  Anyone know?

   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.

   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.

I'm going to skip this since what we should be discussing is an
analysis of the amount of state needed so we don't risk making a
comparison using poorly written code.

  12.  Code and State Size

Skip to:

  12.3.  Comparison

   Table 1 summarises the sizes of the available HOMENET routing
   protocol implementations.  (Data courtesy of Steven Barth and Markus
   Stenberg.)

   +----------------+--------------------+----------------+------------+
   |                |  babeld (source-   | sbabeld (stub- |  AutoISIS  |
   |                |     specific)      |     only)      |            |
   +----------------+--------------------+----------------+------------+
   |    Version     |      2598774       |    cc7d681     |   0.8.0    |
   |      Date      |     2014-09-08     |   2014-11-21   | 2014-08-26 |
   |    License     |        MIT         |      MIT       | Apache 2.0 |
   | Lines of Code  |     10.000 (C)     |   1.000 (C)    |   7.000    |
   |                |                    |                |  (Erlang)  |
   | Installed size |       129kB        |      13kB      |  11,385kB  |
   |    (AMD64)     |                    |                |            |
   |     Total      |       129kB        |      13kB      |  14,155kB  |
   | installed size |                    |                |            |
   |  Baseline RSS  |       ~300kB       |     ~200kB     | ~22,000kB  |
   +----------------+--------------------+----------------+------------+

            Table 1: Comparison of HOMENET implementation size

This seems like a silly comparison.  C code vs Erlang.  For example,
without reading the source code, do we know which implementation makes
good use of dynamic allocation vs allocates big static arrays.  This
is meaningless.  Cisco ISIS and OSPF used to be viable in routers with
under 1MB RAM circa early 1990s with a tiny footprint.

For the purpose of sizing it might be better to consider the OSPF
implementations in C such as http://bird.network.cz/,
http://www.openbgp.org/, http://www.quagga.net/ 

Note that the quagga ISIS is experimental.  Quagga also includes
Babel.

For example.  Bird OSPFv3 is about 12K lines of C code including both .h
and .c files.  Quagga OSPFv3 is 23K lines of C code.  In comparison,
Quagga BGP is 56k lines of code.

Can't add anything to the following section at this time:

  13.  Performance on IEEE 802.11 Wireless Networks

Skip to:

  14.  Standardization Status

Add:

  14.0.  OSPF Standardization

   OSPF has been entirely under the control of IETF since its
   inception well over two decades ago.  OSPFv4 is aimed at IPV4 only
   but has acheived IETF Full Standard status indicating multiple
   implementations, multiple large scale deployment and verified
   interoperability of implentations of all features of the protocol
   specification.  OSPFv3 was initially defined for IPv6 but can carry
   IPv4 unicast and multicast and IPv6 unicast and multicast.  Using
   [draft-ietf-ospf-transition-to-ospfv3-00] IPv6 can be carried over
   parts of a network which are forward IPv4 only, making it viable to
   use OSPFv3 in a mixed network with some IPv4 only, some IPv6 only,
   and some dual stack routers and links.

   OSPF continues to be actively be extended and maintained by the
   IETF OSPF WG.

Skip to:

  15.  Evaluation of RFC 5218 Criteria

Sparse comments here:

Note that there are commercial sources of IS-IS and OSPF code that is
used in some equipment.  This includes DCL (renamed to meta-something)
and IPI (IP Infusion).  Some commercial vendors already use these.

Also note that there are more open OSPF implementations than IS-IS
implementations.  Only quagga I think.  Quality varies.

  15.4.  Potential Niches

OSPF might be best for Ethernet.  Perhaps Babel can be used for WiFi
if OSPF proves unworkable.  IS-IS requires CLNP and so it might be
better for homenet to stick with OSPF.

  15.5.  Complexity Removal

   If so, can complexity be removed to reduce cost?

OSPF offers stub routers (non-transit) but this doens't make for a low
functionality implementation, just no transit through the node.



  15.6.  Killer App

   Is there a potential killer app?  Or can the technology work
   underneath existing unmodified applications?

I think this means a compelling reason for home users to want this.

There is no need to modify applications to run a routing protocol.

  15.8.  Success Predictable

   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?

Too early to decide IMHO.

I'm in favor of multiple alternatives and let the market decide.  I'm
also in favor of using OSPF rather than ISIS due to ISIS use of CLNP.