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

Thanks for the thorough review Curtis.  I am working on an -02 version that we are hoping to publish tomorrow at this point.  I will incorporate your editorial suggestions, but some of your more substantive changes may have to wait until there is agreement about them on the list.  If we can agree to changes, we can add them for the -03 version.

We did not include OSPF because the WG seemed to have narrowed down the choices to Babel and IS-IS at the last meeting.  It is not clear that this document will be published as an RFC -- it is really just intended to aid the WG in making a decision.

Margaret

On Mar 1, 2015, at 10:12 PM, Curtis Villamizar <curtis@ipv6.occnc.com> wrote:

> 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.
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet