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

Aniket Desai <adesai@opnet.com> Tue, 03 October 2006 01:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYwR-0000P7-Lm; Mon, 02 Oct 2006 21:19:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYwP-0000Ot-Qj for ospf-manet@ietf.org; Mon, 02 Oct 2006 21:19:25 -0400
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYwO-0002sI-Ii for ospf-manet@ietf.org; Mon, 02 Oct 2006 21:19:25 -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 k931BAZQ019440; Mon, 2 Oct 2006 21:11:12 -0400
Message-Id: <6.2.3.4.2.20061002203752.036c7a20@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 02 Oct 2006 21:18:54 -0400
To: Russ White <riw@cisco.com>
From: Aniket Desai <adesai@opnet.com>
Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 5
In-Reply-To: <4521AFA8.3070404@cisco.com>
References: <E1GUWT8-0002On-J2@megatron.ietf.org> <6.2.3.4.2.20061002185302.036db250@mailserver.opnet.com> <4521AFA8.3070404@cisco.com>
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: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: ospf-manet@ietf.org
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 08:32 PM 10/2/2006, Russ White wrote:
>I don't. There's no such thing as "leaders" in OSPF. There is such a
>thing in Spanning Tree--perhaps you're mixing up ST and OSPF? Or you're
>confusing the SPF tree, with it's root, with the concept of adjacencies?
>DRs and BDRs are optimizations for broadcast links--OSPF would work just
>fine without them. Do you know the history of p-nodes in IS-IS?
>
>Hence, a "two hop extension" to OSPF's DR's isn't "natural" in any sense
>of the term, and it's not necessarily, the best way to extend the protocol.


Hi Russ,

By leaders, I meant DR/BDR. And of course DR/BDR are leaders for 
broadcast interfaces, as they are responsible for forwarding LSAs. My 
usage of the term may be unorthodox, but it makes sense in the 
context that we are talking about.

Also having said that OSPF-MDR is a natural extension for broadcast 
interfaces, it is perfectly legit to correlate the optimizations in 
broadcast to the optimizations in OSPF-MDR. I am also not talking 
about SPF at all. All I said was that adjacencies are pointed towards 
the leaders (i.e. one end of the adjacency must be a leader) and 
leaders form a connected backbone. SPFs or STs are completely 
irrelevant and I have no idea how they entered in the discussion.

I *also* said in my response just before the one to which you 
responded that OSPF works fine without DR and BDR, and that the 
primary reason for introducing the MDR is to adding scalability. I 
believe that an agreement on basic functionality is already in place. 
I even went ahead and tried to correlate the OR/MPR interface to a 
point to multipoint interface type. Finally, I believe that we are 
primarily debating on scalability versus robustness.

I also do not know the history of p-nodes in IS-IS. Let me honestly 
declare that I don't know anything about IS-IS and I don't know what 
a p-node is. If I am missing any relevance or a connection between 
IS-IS p-node and OSPF-MANET, I apologize. Please let me know if that 
is the case.

Finally, I do not believe that the term *natural extension* is 
orthogonal to the discussion. OSPF-MDR implements a new interface 
type without changing the interface state machine. It has a one to 
one correlation with each interface state in broadcast. It has 
similar adjacency and flooding properties as broadcast (Dr. Ogier's 
slide is very educational). I honestly do not know what more *proof* 
does one need to infer that OSPF-MDR is indeed a natural extension of 
an OSPF broadcast interface. I do agree that the usage should be 
restricted to the term *natural extension of a broadcast interface* 
and not *natural extension of OSPF*. However in my opinion, the usage 
in the terms of the former phrase is not only justified but also 
essential when talking of OSPF-MDRs.

Sincerely,

Aniket



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