[Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 3

Aniket Desai <adesai@opnet.com> Mon, 02 October 2006 19:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUT4c-0005Ef-8V; Mon, 02 Oct 2006 15:03:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUT4b-0005EW-5e for ospf-manet@ietf.org; Mon, 02 Oct 2006 15:03:29 -0400
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUT4Z-0001tw-MT for ospf-manet@ietf.org; Mon, 02 Oct 2006 15:03:29 -0400
Received: from wtn12131.opnet.com (wtn12131.opnet.com [172.16.12.131]) by enterprise58.opnet.com (8.13.6/8.12.10) with ESMTP id k92It5TS012163 for <ospf-manet@ietf.org>; Mon, 2 Oct 2006 14:55:05 -0400
Message-Id: <6.2.3.4.2.20061002144356.036572c8@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 02 Oct 2006 15:02:49 -0400
To: ospf-manet@ietf.org
From: Aniket Desai <adesai@opnet.com>
In-Reply-To: <E1GUS5K-0000dF-C6@megatron.ietf.org>
References: <E1GUS5K-0000dF-C6@megatron.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OPNET-MailScanner: Found to be clean
X-MailScanner-From: adesai@opnet.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 3
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

With regards to the whole discussion about what draft is a *natural 
extension*, I think it will help to put a little better context around it.

As far as I can see, MDRs extend the concept of a *broadcast* 
interface type - i.e. they provide both adjacency reduction and 
flooding optimization.

MPRs on the other hand can be treated as if they are extensions of 
point to multipoint interface types, with special flooding. They may 
or may not provide adjacency reduction (depending upon whether one 
chooses to form an adjacency between MPR selector and MPR or full 
topology adjacencies) but they do provide flooding optimization by 
MPR signaling.

One can definitely choose to run any OSPF interface type no matter 
what the underlying physical medium is. It is not needed to run 
broadcast interface type on ethernet networks. But the fact of the 
matter is; whether one chooses to run this interface type or not; it 
does exist as given by the RFC. I have always thought of this problem 
from the point of view of scalability, and hence I have always felt 
that MDRs were the natural way to extend OSPF.

I also have another thing to point out. MDR optimization pays off the 
most when networks are very dense (which is exactly the applicability 
statement you will find in the OLSR draft - rightfully so). If the 
network is sparse, most of the nodes will become MDR anyway and the 
ratio of adjacent neighbors to bidirectional neighbors will be close 
to 1. This is a situation that is very close to full topology 
adjacencies "despite" MDRs. However if the network is dense, MDRs by 
nature will minimize adjacencies in a way *that will NOT affect 
robustness of the network*. Why? Because the average lifetime of an 
adjacent neighbor will be much higher. The point I am making is that 
in the sparse networks, where robustness will be crucial; by nature 
number of MDRs will be higher and the distributed CDS algorithm will 
try to get all adjacencies up. It will do that because it is a 
distributed heuristic trying to find a connected/biconnected graph, 
and in process of doing so, it will end up connected a lot of 
redundant links as adjacencies.

Finally as Dr. ogier has pointed out, it is possible to dissociate 
MDR state of an interface with its corresponding adjacencies. Each 
interface can simply ask all its neighbors to become adjacent, and 
some straightforward changes in the receiver can make it possible. In 
this case, I can safely say that MDR = MPR (with respect to flooding 
and adjacencies).

I still feel that in order to test all the hypothesis such as above 
and even more; simulations are an excellent tool.

Sincerely,

Aniket


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