RE: [Ospf-wireless-design] OSPF Flooding and Higher Mobility

"Spagnolo, Phillip A" <phillip.a.spagnolo@boeing.com> Fri, 04 November 2005 22:06 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 1EY9hg-0005r6-83; Fri, 04 Nov 2005 17:06:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY9he-0005qf-JT for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 17:06:30 -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 RAA16924 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 17:06:06 -0500 (EST)
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY9wg-0004D2-8s for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 17:22:05 -0500
Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA13134; Fri, 4 Nov 2005 16:06:11 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jA4M6BH03046; Fri, 4 Nov 2005 14:06:11 -0800 (PST)
Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 14:05:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
Date: Fri, 04 Nov 2005 14:05:39 -0800
Message-ID: <08590A72DC26A54B85632FF97C2C22DA0D506D@XCH-NW-5V2.nw.nos.boeing.com>
Thread-Topic: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
Thread-Index: AcXhg2aK5PgelJBaTQykAkhcVWYsJAABsVEA
From: "Spagnolo, Phillip A" <phillip.a.spagnolo@boeing.com>
To: Acee Lindem <acee@cisco.com>, ospf-wireless-design@ietf.org
X-OriginalArrivalTime: 04 Nov 2005 22:05:39.0805 (UTC) FILETIME=[E45ED0D0:01C5E18B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: quoted-printable
Cc:
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,

Thanks for presenting these results.  Your data and method will allow
for some healthy discussion and comparison.

See some initial comments and questions below.

> -----Original Message-----
> From: Acee Lindem [mailto:acee@cisco.com] 
> Sent: Friday, November 04, 2005 12:53 PM
> To: ospf-wireless-design@ietf.org
> Subject: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
> 
> 
> Based on the INRIA reports and attendant E-mail threads, we 
> (Cisco) have
> recently gone down the path of doing some simulations with 
> higher mobility.
> The attached spread sheets show the results for 16 m/sec velocity and
> varying radio range. The pause time is still 40 seconds. We 
> found the results
> to be more drastic with a smaller pause time but had some 
> problems getting
> a complete set of runs.
> 
> MPRs have the following improvements over the base provided 
> with GTNetS:
> 
>      - Smart Peering is fixed to avoid instability by running a second
>        SPF to determine if a potential peer is available via a real
>        adjacency or unsynchronized adjacency. The adjacency 
> is only suppressed
>        in the case of connectivity to the SPT via real 
> adjacencies. This
>        is discussed in the Boeing report but wasn't implemented.

Are you allowing any adjacent path or are you limiting the adjacent path
to a certain length?

> 
> Also, we have enabled promiscuous LSA caching enabled with the LSA
> cache timeout extended to 100 seconds. We are attempting to get some
> runs with this disabled as well some with a shorter pause time.

LSA caching is not exclusive to MPRs.  In order to get a fair
comparison, it should be run independently.  The strategy will work in
either method.  Can you provide results excluding the LSA caching or
using with both methods?

> 
> For MDRs we used the standard bi-connected topology.
> 
> We will provide the diffs for the code changes supporting 
> smart peering.

Can you provide the scripts you used to generate these results?  I would
like to validate your MDR results before working with MPRs.  My first
check did not match exactly, but I don't trust it because I don't know
the parameters you used.

> 
> We have also been investigating using the MDR strategy of 
> reducing adjacencies
> by taking advantage of the flooding topology. However, doing 
> this effectively
> is more complex than it first seemed.

Can you explain this comment more clearly?

Lastly, I looked at the 50 node data for MPRs and MDRs.  Why do the MPRs
have so many LSA that are out of sync between the databases?  I was
wondering if LSA caching was covering something up here?

Thanks,
Phil


> 
> Stan Ratliff, a Cisco Software Engineer, will be presenting 
> these results.
> 
> Thanks and Sorry for the Short Notice,
> Acee
> 
> 

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