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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Markus Stenberg writes:
 
> On 2.3.2015, at 5.12, Curtis Villamizar <[e-mail]> wrote:
> > 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.
>  
> I thought the WG more or less arbitrarily chose to make this beauty
> contest just limited to 2 protocols based on some live meeting
> comments or something. So this might be too little, too late, perhaps.

Whatever the basis was for dropping OSPF should be documented
somewhere.  ISIS and OSPF are very similar.  LSPDUs vs LSA.  It
affects how much stuff you have to flood when a change occurs, but the
differences are minor.  The real difference is OSPF runs over IP and
ISIS runs over CLNP which means bringing in new Ethertype and protocol
family.

> > 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.
>  
> draft-baker-ipv6-ospf-dst-src-routing-03 (expired) exists too. And
> conceptually it is exactly same as IS-IS draft with also draft-baker-
> prefix.

I'm sure Fred would resubmit if there was interest.

> > OSPFv3 also support IPv4 and IPv6 multicast.
>  
> Any (open-source) implementations?

Not open source.  Cisco and Juniper and other commercial yes.  Its
probably in DCL or IPI code base or on their roadmap (commercial
source code).

> > Maybe it would be better to run a multicast routing protocol than
> > ISIS, OSPF, or Babel extensions.
>  
> Yes, something like PIM (or a bunch of proxies, ha ha).

OK maybe the topology is simple enough and there are few enough
multicast groups to just carry all multicast <S,G> in the unicast
routing protocol.  I'll concede that.

> >  11.  Implementation Status
> > 
> >   There are HOMENET implementations of both IS-IS and Babel.
> > 
> > How do you define a HOMENET implementation?
>  
> Filling the criteria above I guess. 

If you mean above this section in the document, then OSPF fills the
criteria.

> > 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.
>  
> Notably, I am not aware of a single OSPF (open-source) implementation
> with zeroconf and source-specific routing.

Zeroconf would be easy to do.  Source specific would not be quite so
easy.

> > I'm not sure if there are any open source ospf-zero-conf
> > implementations.  Anyone know?
>  
> I used to maintain one originally made by Benjamin Patterson (fork of
> BIRD). However, I am still not aware of an implementation with the
> source-specific routing support which is the more painful part
> (especially as it essentially requires OSPF3.1, due to changing all
> LSAs, see draft-ietf-ospf-ospfv3-lsa-extend draft).
>  
> At a guess it would be weeks-months of happy hacking for someone. 

I'm not convinced it would take that long.

> > 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.
>  
> A very academic point of view but I can respect that, you are not the
> only one with it here.
>  
> > 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/ 
>  
> Certainly. Please point me to src-specific zeroconf open-source
> implementation of IS-IS or OSPF that is written in C.

What I'm saying is that a poor implementation of a protocol is not
indicitive of what the protocol is capable of.

> > 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.
>  
> Most of real Quagga footprint is non-routing-protocol code. For Bird
> it is not quite that bad, but still.
>  
> If we are trying to defuse the pointless things from the document,
> line count is also completely BS measure, I can produce OSPF
> implementation in 1 line of C by taking in Bird, little preprocessing,
> and 1 sed command.

I agree.  Line count and image footprint are a poor basis for choice.
In a 200 node topology there isn't a whole lot of state either.

> Only thing that really matters (from my point of view) is whether it
> fits in compiled form in small enough RAM/flash, and does not kill the
> low-end CPU.

The amount of flash and RAM will increase so we don't want to use
arguments about hackers not being able to fit into some of the old
designs supported by openwrt.  The vast majority of consumers will see
this in new product, not flashed into old stuff they have.  Hackers
may have to toss something for their 2MB/8MB flash/RAM thingie.

> > 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.
>  
> Me too (CLNP should die), but I am not sure we have that option unless
> someone coughs up implementation that is actually usable for this
> case. Saying that the (partially expired) draft set can be used to
> produce a homenet conforming implementation is one thing, but having
> them already (IS-IS / Babel) is quite different.

That would be a good reason to go with OSPF if we would like to be
able to gather topology information.

> Cheers,
>  
> -Markus

Cheers,

Curtis