[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