Re: [Ospf-wireless-design] Re: consensus

Richard Ogier <rich.ogier@earthlink.net> Fri, 04 November 2005 21:29 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY97g-0007XJ-Gs; Fri, 04 Nov 2005 16:29:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY97f-0007XE-3W for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 16:29:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14918 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 16:28:53 -0500 (EST)
Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY9Mg-0003C8-E8 for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 16:44:51 -0500
Received: from dialup-4.246.33.169.dial1.sanjose1.level3.net ([4.246.33.169] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EY97Y-0006VE-00; Fri, 04 Nov 2005 16:29:12 -0500
Message-ID: <436BD2A8.5040805@earthlink.net>
Date: Fri, 04 Nov 2005 13:29:12 -0800
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
To: Acee Lindem <acee@cisco.com>
Subject: Re: [Ospf-wireless-design] Re: consensus
References: <436B37D9.3070709@inria.fr> <436BA9DC.6020902@earthlink.net> <436BBB9D.9010108@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: 7bit
Cc: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, ospf-wireless-design@ietf.org
X-BeenThere: ospf-wireless-design@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OSPF Wireless Design Team <ospf-wireless-design.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/ospf-wireless-design>
List-Post: <mailto:ospf-wireless-design@lists.ietf.org>
List-Help: <mailto:ospf-wireless-design-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=subscribe>
Sender: ospf-wireless-design-bounces@lists.ietf.org
Errors-To: ospf-wireless-design-bounces@lists.ietf.org

Acee Lindem wrote:

> Richard Ogier wrote:
>
>> Emmanuel,
>>
>> You seem to be missing some points in the recent discussion.
>> Phil pointed out one of these in his email today.
>> Another one you seem to be missing is that adjacencies
>> based on MPRs (the way you select them) do not work, since they
>> do not guarantee the graph of adjacencies is connected.
>>
> Hi Richard,
> I don't understand why it wouldn't if an adjacency is formed (or 
> retained)
> if either neighbor selects the other as a relay? Of course, to do this 
> effectively
> the MPR selection algorithm should consider whether or not there is an
> exant adjacency and give those relay candidate preference.
>
> Thanks,
> Acee

Acee,

I gave a few examples in an email I posted a few days ago, showing why
the resulting adjacency graph is not guaranteed to be connected, even if
an adjacency is formed when either neighbor selects the other as an MPR.
I don't have access to my old emails now, but the simplest example
is a fully connected network, which has no MPRs.

In any case, we seem to be in agreement that using MPRs to select
adjacent neighbors results in more adjacencies than using MDRs.
Even more significant, using MPRs results in a MUCH greater RATE
of new adjacencies than OSPF-MDR (according to my simulations).

Emmanuel wrote:

> On the other hand using MPR/MPRselector adjacencies does yield more 
> adjacencies,
> but no route stretching whatsoever. So here (in the topology reduction 
> design) there is a
> trade-off that was not yet fully discussed in my opinion. 


As Phil pointed out, there is no such trade-off, since MDRs can be used
with min-cost LSAs (or even with LSAs based on MPRs) without any
route stretch.

As I mentioned, I still think it is worth evaluating the selection of
the CDS/MDRs based on pruning MPRs, and this can easily be implemented
by modifying the GTNetS code for OSPF-MDR.  It is also worth evaluating
the use of LSAs based on MPRs (the LSA would contain MPR selectors as
in OLSR).   Therefore, based on the recent discussions (from which
we can exclude MPR-based adjacencies), it appears to me that the consensus
is headed toward using a CDS, which may or may not be based on MPRs.
Since we already have a CDS solution that performs very well (OSPF-MDR),
I hope we can agree to use OSPF-MDR as a starting point, and to evaluate
modifications of it that use MPRs to select the MDRs and/or to generate
LSAs.


 > Of course, to do this effectively
 > the MPR selection algorithm should consider whether or not there is an
 > exant adjacency and give those relay candidate preference.

Giving existing adjacencies higher preference when selecting
MPRs does not help to ensure the adjacency graph is connected.
Using my modified MPR selection algorithm, which ensures the adjacency
graph is connected, you would have to give MPRs preference *independently*
of the MPR selector, so that all nodes agree on the priority of
a given node.  I tried doing this in simulations (so that a node
has higher priority if *any* neighbor selected it as an MPR),
but it did not help performance.  This is probably because, with the
modified MPR selection algorithm, more than half of the nodes are
selected as MPR by some neighbor.

Richard


>
>



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