[Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 13
Aniket Desai <adesai@opnet.com> Wed, 20 December 2006 16:08 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3zh-0006jw-3O; Wed, 20 Dec 2006 11:08:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3zf-0006jr-Mo for ospf-manet@ietf.org; Wed, 20 Dec 2006 11:08:35 -0500
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3zc-0003DU-J6 for ospf-manet@ietf.org; Wed, 20 Dec 2006 11:08:35 -0500
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 kBKG7ZiF013621 for <ospf-manet@ietf.org>; Wed, 20 Dec 2006 11:07:35 -0500
Message-Id: <6.2.3.4.2.20061220104719.037846a8@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 20 Dec 2006 11:08:22 -0500
To: ospf-manet@ietf.org
From: Aniket Desai <adesai@opnet.com>
In-Reply-To: <E1GXT9u-00078J-RG@megatron.ietf.org>
References: <E1GXT9u-00078J-RG@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: b4a0a5f5992e2a4954405484e7717d8c
Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 13
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
Richard, Adjacency reduction is indeed an interesting approach that is present in various ways in the three solutions OR, MPR and MDR. The specificity of the MPR solution is that it brings topology reduction too, in a way compliant with the usual "route on adjacencies only". The draft and the code we released shows that the MPR solution is simple and valid. You say you still need to experiment with your code, and we all need to experiment with the code. I agree: that is why the three solutions are going to experimental status, as decided by the working group. So I don't understand where you are getting at? By the way, regarding adjacency reduction, it must be pointed out that contrary to what you claim the available code for the MPR solution is compliant with the draft, since adjacency reduction is specified as optional. Regards, Emmanuel Hi, I would like to point out the following document: Advantages of OSPF-MDR (with details) draft-ogier-ospf-mdr-position-00.txt Notice that in this document, detailed scenarios with a lot of statistics are presented. This information is very useful for implementors for multiple reasons - the obvious being code evaluation. But it is much more than that. One can understand the inherent dynamics in the system by correlating multiple statistics with each other. Because it has been done for MDRs at least once, I think Dr. Ogier is right in pointing out that more experiments should be done for other drafts. MDR draft is also being experimented more, but there is a difference with respect to other drafts. Also from a pure draft standpoint, MDR draft is much more detailed. Every sub-section in MDR draft points to RFCs 2328/2740 with detailed instructions as to which steps are being changed/replaced/modified. I did not see the same with any other drafts. Also, it was discussed that rather than adjacency reduction by itself, adjacency rate is more important. MDRs achieve both. Regarding route on adjacencies only, if the adjacency graph is too volatile (as would be the case in MPR-MPR selector pairing in highly dynamic scenarios), it may not amount to much. I think the advantage of MDR scheme is stabilizing the adjacency graph as much as possible, which increases the chance that it is at least connected even in the face of dynamicity. If the adjacency graph is connected, everyone is indirectly synchronized to everyone else and one can route over shortcuts. Of course the problem is interesting and needs to be explored more. Thanks, 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