Re: [Ospf-manet] MPR-OSPF GTNetS simulations report

Richard Ogier <rich.ogier@earthlink.net> Thu, 18 January 2007 22:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7g1f-0005VT-1C; Thu, 18 Jan 2007 17:46:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7g1e-0005VO-30 for ospf-manet@ietf.org; Thu, 18 Jan 2007 17:46:30 -0500
Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7g1c-0007FC-Pv for ospf-manet@ietf.org; Thu, 18 Jan 2007 17:46:30 -0500
Received: from dialup-4.245.102.78.dial1.sanjose1.level3.net ([4.245.102.78]) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H7g1Z-0004ZV-00; Thu, 18 Jan 2007 17:46:26 -0500
Message-ID: <45AFF8C2.3040705@earthlink.net>
Date: Thu, 18 Jan 2007 14:46:26 -0800
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report
References: <45A43BD4.5090609@inria.fr> <45A6C59D.1070105@earthlink.net> <45A7A448.4030707@inria.fr>
In-Reply-To: <45A7A448.4030707@inria.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: ospf-manet@ietf.org
X-BeenThere: ospf-manet@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions of OSPFv3 extensions supporting MANET <ospf-manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf-manet>
List-Post: <mailto:ospf-manet@ietf.org>
List-Help: <mailto:ospf-manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=subscribe>
Errors-To: ospf-manet-bounces@ietf.org

> Emmanuel Baccelli wrote:
> Hi Richard,
>
> We are happy to see that you join the consensus to push the 3 current 
> proposals to experimental status. That way the community will gather 
> experience by mixing the various mechanisms for flooding reduction, 
> topology reduction and adjacency reduction.
>
> We agree that multicast decreases the impact of adjacency reduction. 
> It is one of the factors that enables MPR-OSPF to perform that well 
> while keeping strict OSPF adjacency mechanisms.
>
> Regards,
> Emmanuel 


Emmanuel,

(I have been away from my email for the last week.)
It's amazing how you twist my words to conclude that I have joined
"consensus" to push the 3 current proposals to experimental status.
This twisting of words is one reason why I do NOT want to engage
in arguments with INRIA for the next year or so.  Another reason
is that you are trying to avoid a fair comparison, which is why I
had to work hard to write code for your MPR-based adjacency
reduction.

My points were that your main contributions - MPR-based LSA reduction
and multicast retransmitted LSAs - do not by themselves constitute an
OSPF extension, but are techniques that can be applied to either ORs
or MDRs (and it is not yet clear that either provides any significant 
advantage for MDR).  Also, your MPR-based adjacency reduction is
simply not scalable, as was clearly shown in my simulations.
I am currently running simulations for 80 and 100 nodes to
add to my previous simulation results.

Some may say that INRIA's solution is "good enough" to become
an experimental WG draft, but I disagree with that because
it does not scale to dense 100-node networks, as do
the other solutions, and INRIA has not shown that it scales
to such networks.  If you can show that it scales as well
(or almost as well) as the other two solutions, then I
would agree that it can be advanced to experimental.
But I don't think this is possible without major changes.

And this leads to the problem that Joe Macker warned about
at the last meeting, i.e., we want to avoid major changes
to the drafts once they become experimental WG drafts.
Otherwise, we may never converge.  Since your solution is
not currently as scalable as the other solutions, maybe
you are planning to later to modify it later to make it
more scalable, e.g., by using the database signature
exchange mechanism.  As Joe Macker advised, we want to
avoid making such major changes later.  Therefore,
any major changes should be made BEFORE your draft is
advanced to experimental, and simulations should
be run to compare the finalized version to the other
proposals.  (On the other hand, using the database
signature method might have the disadvantage of being
too much of a change from legacy OSPFv3, but that is
a different issue.)

In summary, once you have finalized your draft (so that
no major changes will be necessary), then let's compare
it to the other two solutions.  If it is almost as
scalable as MDR, then I would have no objection to
your draft becoming an experimental WG draft.

Richard


>
>
> _______________________________________________
> Ospf-manet mailing list
> Ospf-manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf-manet
>


_______________________________________________
Ospf-manet mailing list
Ospf-manet@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-manet