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