Subject: Re: Some issues regarding TBRPF and OLSR

From: [email-masked]
Date: Mon, 17 Dec 2001 11:27:00 -0800

To Thomas and all,

See my comments below.

> See comments below....
> 
> On Thu, 13 Dec 2001 [email-masked] wrote:
> 
> >
> > Since Thomas is emphasizing that OLSR is more "stable" than
> > TBRPF (but avoids the issue of performance), I would like
> > to say a few things in defense of TBRPF.  By "stable" he
> > means that OLSR has not changed much recently.
> >
> > First, let's not forget that OLSR was originally a full topology
> > protocol and then changed to partial topology, between version 00
> > and version 01 (I believe).  TBRPF did the same between version 00
> > and version 01.  (This occurred more recently since TBRPF was
> > introduced to the WG about a year later than OLSR.)
> 
> Richard, this is just not true. The first version of the olsr-draft was
> not full-topology. It contained and used multipoint relays in the same way as
> the current drafts. That is to say that OLSR from the beginning has been
> using partial topology.

I checked version 00 of the OLSR draft and see that you are correct.
I was referring to Amir's comment at the August 2000 IETF meeting 
(the first one at which TBRPF was presented) that OLSR was once
full topology like TBRPF. (As I'm sure you know, it is possible to 
use MPRs to broadcast full topology information, so this made sense.)
Maybe he was referring to a version of OLSR before it became a draft. 

>
> <SNIP>
> 
> Richard, please note that I was not "criticizing" that TBRPF was evolving.
> At the IETF, I was merely stating the status for the proactive work
> over the past year. This included the fact that 4 radically different
> versions of TBRPF had emerged. Is this not correct?

Actually, since the changes from version 01 to version 02 were only
minor changes to the neighbor discovery module, there were only
two major revisions to the draft: The first major revision (00 to 01) 
introduced the partial topology mode and differential neighbor
discovery; and the second major revision (02 to 03) simplified the 
protocol by using periodic updates (in addition to differential updates), 
eliminating NEW PARENT messages, and merging the PT and FT modes.

The purpose of these revisions (which of course involved a lot of 
hard work) was to achieve the goals of the MANET working group.
We have no plans for any further major revisions, so TBRPF is now
stable.  (We plan to add multiple interfaces, but that will be 
straightforward and similar to OSPF.)  

I guess one possible reason that OLSR has not changed much is due to 
the requirement for backward compatibility (which is emphasized in 
the OLSR drafts). This naturally limits the ability to modify OLSR 
based on suggestions from the working group, and to merge OLSR with 
other protocols.  (TBRPF did not have this requirement and was 
therefore more flexible in responding to suggestions.)

I will not discuss the issue of "stability" versus performance in this
message, except to say that our main goal is to standardize a proactive 
routing protocol that performs (and scales) well in both military and 
commercial ad hoc networks.  Once a protocol is standardized, it is expected 
to be used for many years, so I think performance should be a major 
consideration.

At the meeting last Tuesday, Dave Johnson pointed out that the
situation with OLSR and TBRPF is similar to that of AODV and DSR,
so that it might make sense for both protocols to become experimental 
RFCs, and I saw several people nod in agreement.  I think this is a
good solution, since it would give people a chance to assess the 
performance and stability of OLSR and TBRPF.

Richard