[Ospf-manet] Re: Regarding OSPF MDR

Richard Ogier <rich.ogier@earthlink.net> Thu, 15 February 2007 20:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHmsw-0004Bv-2s; Thu, 15 Feb 2007 15:07:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHmsu-0004AX-1W for ospf-manet@ietf.org; Thu, 15 Feb 2007 15:07:16 -0500
Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHmss-0004bR-P0 for ospf-manet@ietf.org; Thu, 15 Feb 2007 15:07:16 -0500
Received: from dialup-4.245.99.6.dial1.sanjose1.level3.net ([4.245.99.6]) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HHmsq-0001T7-00; Thu, 15 Feb 2007 15:07:12 -0500
Message-ID: <45D4BD6A.3000009@earthlink.net>
Date: Thu, 15 Feb 2007 12:07:06 -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: Philippe Jacquet <philippe.jacquet@inria.fr>
References: <45B5D944.9010303@inria.fr> <45BD37DF.1050005@earthlink.net> <45C38419.7070208@inria.fr> <45C8C704.8020908@earthlink.net> <45CC98B1.8060907@inria.fr> <45CCD19B.9070604@earthlink.net> <45D31ECA.50007@inria.fr>
In-Reply-To: <45D31ECA.50007@inria.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: ospf-manet@ietf.org
Subject: [Ospf-manet] Re: Regarding OSPF MDR
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

Philippe,

Philippe Jacquet wrote:

> Dear Richard,
>
> In contrast to the claims of the MDR draft, the code (available on the 
> Boeing WWW-site and used for the simulations in the milcom06-paper) 
> does not provide min-hop path, regardless of backlink check, cost 
> metric and cost distortion.


It is because of the backlink check that it does not provide min-hop
paths, since the old min-cost LSA algorithm did not advertise neighbors
symmetrically. (Note that min-COST routing would require Hellos to
advertise neighbor costs, which is an option not implemented in GTNetS.)
As I pointed out, INRIA's original code for MPR-OSPF did not
even perform a backlink check (but has now been corrected).
Frankly, I think it would be better if we could omit the backlink
check, but that would not be compatible with legacy OSPF.

The cost "distortion" is simply a small penalty to favor the use
of synchronized links, and does not affect the hop length for paths
less than 10 hops.  Also, this penalty is optional.
The updated min-cost LSA problem (to be announced soon), will
advertise neighbors symmetrically and will always provide
min-cost paths.

>
> Since the LSA reduction in MDR is still not mature and certainly not 
> tested (since no code is available), it is misleading to advertise the 
> simulations with anything else but the full LSA option.


I don't agree.  For example, one can use the "minimal LSA" option with
MDR, which allows only synchronized links to be used for routing.
This does not provide min-hop or min-cost routing, but some applications
may be willing to trade off path optimality to achieve much lower overhead.
Also, I am sure you would not object if MDR uses path-MPR-based LSAs.
I plan to compare path-MPR-based LSAs to the updated min-cost LSA
algorithm, and I would be happy to use whichever method turns out to
perform better.

You are focusing on LSAs, which are decoupled from flooding and
adjacency reduction in OSPF-MDR.
You are right that my simulation results did not provide a fair
comparison of LSU overhead, but they *did* provide a fair comparison
of synchronization (DD) overhead, since the choice of LSAs have no
effect on DD overhead (assuming that each router originates an LSA).

I  plan to compare the following three protocols:

1. MPR-OSPF (with path-MPR-based LSAs)
2. OSPF-MDR with path-MPR-based LSAs
3. OSPF-MDR with the updated min-cost LSA algorithm.

Comparing 1 and 2 will allow the flooding and adjacency reduction
methods to be compared independently of the choice of LSAs.
Comparing 2 and 3 will determine which LSA algorithm performs better
with OSPF-MDR.

Also, we can try using multicast LSA retransmissions with OSPF-MDR.
For fairness, any technique that is used with one protocol and that
can be used to improve the performance of the other protocol, should
be used by both protocols.

In order for MPR-OSPF to provide min-cost paths (based on metrics),
you will have to select "path MPRs" and advertise these and link
costs in Hellos, along with MPRs.
Your Appendix C describes a Path MPR Selection Heuristic,
which is not implemented in GTNetS.  So I guess we are
both experimenting with LSA algorithms that are not yet
mature.  That is fine, since the need for LSA reduction was
not considered a goal until relatively recently.  That is why
Cisco's OR/SP drafts do not specify an algorithm for LSA
reduction.

Richard

P.S. BTW, the min-cost LSA algorithm could be called
"path-MPR-source-based LSAs".  I.e., a router selects
MPR sources (equivalent to MPR selectors) instead of MPRs.
But I think using the term MPR in both cases is inappropriate,
since path-MPRs are not used for multipoint relaying.
I prefer the more generic term "selected advertised neighbors".












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