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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUX26-0006yf-DI; Mon, 02 Oct 2006 19:17:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUX24-0006ya-Sf for ospf-manet@ietf.org; Mon, 02 Oct 2006 19:17:08 -0400
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUX23-0005zN-FZ for ospf-manet@ietf.org; Mon, 02 Oct 2006 19:17:08 -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 k92N96bl007758 for <ospf-manet@ietf.org>; Mon, 2 Oct 2006 19:09:06 -0400
Message-Id: <6.2.3.4.2.20061002185302.036db250@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 02 Oct 2006 19:16:50 -0400
To: ospf-manet@ietf.org
From: Aniket Desai <adesai@opnet.com>
In-Reply-To: <E1GUWT8-0002On-J2@megatron.ietf.org>
References: <E1GUWT8-0002On-J2@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: 4adaf050708fb13be3316a9eee889caa
Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 5
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

At 06:41 PM 10/2/2006, you wrote:
>IMHO, it doesn't matter what you think is a "natural" and "unnatural"
>extension to OSPF. What should matter is the requirements, and the way
>to solve those requirements.

- Let's say OSPF-MDR is a natural way to extend OSPF's broadcast 
interface for MANET type physical medium. It should be an acceptable 
term. What requirements does this solve: scalability, scalability and 
scalability.


>I didn't ask you to stop saying "this is natural" because I have any
>thoughts on what's natural or not, but rather, because it doesn't lead
>to any useful discussion. Tossing words with emotional connotations into
>the conversation doesn't clarify it in any way, shape, or form.
>
>I could, in fact, argue that just about _any_ extension to OSPF is
>"natural," in some sense or another. It's a meaningless concept, in this
>world.

If you agree that OSPF is about maintaining a connected/biconnected 
adjacency graph that is rooted towards its leaders (DR and BDR) which 
are also the *forwarders* of data on this graph, then the CDS concept 
and the subsequent MDRs make perfect sense. That is how scalability 
should be achieved in OSPF. In this design, each node tries to form 
adjacencies that are aligned towards the leaders, and the leader 
*backbone* (i.e. CDS) will forward the LSAs originated by everyone 
everywhere. Also *very important* part is that each node determines 
its own status, which is known universally (not like MPR, where any 
given MPR has no universal context and hence I believe will fall 
seriously short of scalability). Inherent robust mechanisms can also 
elongate the lifetime of an MDR and all that an MDR-other node needs 
to do is find its best MDR and continue to remain adjacent to it as 
long as possible. This makes core adjacency graph as stable as 
possible. I find this design brilliant and in the true spirit of OSPF.

I have to say that this is very natural in the context of OSPF. I do 
agree that the word *natural* can be twisted any way when taken 
without context, but I believe when Dr. Ogier claims *natural*, he 
thinks of scalability and a broadcast interface. Perhaps it is better 
to call MDRs a natural way to extend broadcast interface of OSPF.

Sincerely,

Aniket  


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