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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURHZ-0004Ge-3e; Mon, 02 Oct 2006 13:08:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GURHX-0004EE-DJ for ospf-manet@ietf.org; Mon, 02 Oct 2006 13:08:43 -0400
Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GURHV-0003pE-33 for ospf-manet@ietf.org; Mon, 02 Oct 2006 13:08:43 -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 k92H0Que031276 for <ospf-manet@ietf.org>; Mon, 2 Oct 2006 13:00:26 -0400
Message-Id: <6.2.3.4.2.20061002125614.036ec290@mailserver.opnet.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Mon, 02 Oct 2006 13:08:07 -0400
To: ospf-manet@ietf.org
From: Aniket Desai <adesai@opnet.com>
In-Reply-To: <E1GUPOB-0000FA-SD@megatron.ietf.org>
References: <E1GUPOB-0000FA-SD@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: 97adf591118a232206bdb5a27b217034
Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 11, Issue 2
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

As I mentioned, a single OSPF extension can be flexible enough
to work in all (or almost all) environments.  If adjacency reduction
is not appropriate for some environments, OSPF-MDR can include the
option of full topology adjacencies, as has been discussed.
This might not be the ideal solution for full topology
adjacencies, but Boeing's simulations show it is as good
as any in terms of performance, and we get the benefit of
a single flexible protocol for a wide range of environments.

- Supporting full topology adjacencies in MDRs is very easy as far as 
I can tell. Parent selection and dependent selection algorithms can 
be modified if a full topology option is specified on a router 
(modification is straightforward: If full topology option is 
specified, form adjacencies with all bidirectional neighbors 
regardless of whether they belong to parent/dependent subset). Sender 
should perhaps put a multicast address in the DR and BDR fields of 
its MDR TLV (?). The receiver will work as usual (i.e. it will honor 
an incoming adjacency only if it is from a child or a dependent 
selector); however an exception will be made for the special 
multicast DR/BDR addresses, and the incoming adjacency will be 
treated as if it came from a child and/or a dependent selector 
(doesn't matter).

I like this scheme, because each router can independently decide 
whether it wants to form full topology adjacencies or optimal 
adjacencies. Also, this does not affect flooding at all, which will 
follow the usual MDR flooding rules. That way, we can get best of 
both the worlds (robustness and efficiency).

Sincerely,

Aniket 


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