[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
- [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue… Aniket Desai