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

Richard Ogier <rich.ogier@earthlink.net> Wed, 26 October 2005 18:51 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqN5-000621-C1; Wed, 26 Oct 2005 14:51:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqN3-00061m-3Y for ospf-wireless-design@megatron.ietf.org; Wed, 26 Oct 2005 14:51:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13980 for <ospf-wireless-design@ietf.org>; Wed, 26 Oct 2005 14:51:18 -0400 (EDT)
Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqaE-0005NP-EL for ospf-wireless-design@ietf.org; Wed, 26 Oct 2005 15:05:12 -0400
Received: from dialup-4.243.128.236.dial1.sanfrancisco1.level3.net ([4.243.128.236] helo=earthlink.net) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EUqMt-00047n-00; Wed, 26 Oct 2005 14:51:24 -0400
Message-ID: <435FD024.9050208@earthlink.net>
Date: Wed, 26 Oct 2005 11:51:16 -0700
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: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
Subject: Re: [Ospf-wireless-design] any consensus?
References: <77F357662F8BFA4CA7074B0410171B6DC9E4C6@XCH-NW-5V1.nw.nos.boeing.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: 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

>> I think there is a
>> fine trade off that remains to be evaluated between taking a 
>> CDS or MPR as backbone to compute the reduction in topology 
>> advertizement.
>
>
>Again, this should be easily testable, and I don't think we yet have
>data on this.  Our intuition, which needs to be tested, is that because
>the MPR and selector relationship is not bidirectional, the set of
>adjacencies formed by all MPRs and all selectors will be many more than
>what the MDR approach yields, and there doesn't appear to be an
>intuitive way to systematically prune further adjacencies from the
>MPR/selector adjacency set.
>

I think that the main thing that should be tested (and I already
suggested this in my message dated 8/28/2005) is whether it is better to
use the existing MDR selection algorithm for selecting the CDS backbone,
or to select the CDS backbone based on MPRs (using the self-pruning
strategy in INRIA's report RR-5609).  This can be tested by modifying the
OSPF-MDR draft/code so that the self-pruning MPR method is used to select
MDRs. Backup MDRs can be obtained similarly by first selecting Backup MPRs
and applying self-pruning to these.  The algorithm for selecting MPRs and
Backup MPRs should be based on (MDR_Level, RtrPri, RID) as in the MDR
draft, for stability.  I.e., the MPR selection algorithm should not
be based on the number of 2-hop neighbors covered, since this would
result in poor stability.  This will also result in a larger number
of MPRs than before.

Adjacencies can be established between each (Backup) MDR
and each neighboring (Backup) MDR, and between each MDR Other
and its parents (selected as in the MDR draft). (This is allowed
by Section 5.5 of the OSPF-MDR draft.)  All other aspects of
OSPF-MDR can remain the same.  Instead of the min-cost LSAs, it would
be possible to originate LSAs based on MPRs, i.e., each router includes
all of its MPR selectors in its LSA.  The GTNetS code can be modified
to test this variation of OSPF-MDR (using MPRs).

If it is too much work to implement Backup MPRs for the purpose of
selecting Backup MDRs, then we can compare the two approaches using
only MDRs (and no Backup MDRs) which gives a 1-connected adjacency
graph.

On the other hand, since no detailed method has yet been
proposed for extending OSPF in this way, one could argue that it
is too late to consider new designs such as this.

Another possibility for consensus is to agree to use the OSPF-MDR draft
as a starting point and agree to test alternative methods for selecting
the MDRs, including methods based on MPRs.  (Also, to test alternative
methods for selecting neighbors to include in LSAs, including methods
based on MPRs.)

Richard


>
>




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