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

Acee Lindem <acee@cisco.com> Fri, 04 November 2005 22:40 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 1EYAEF-0002i5-Cg; Fri, 04 Nov 2005 17:40:11 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYAED-0002hl-QA for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 17:40:10 -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 RAA18379 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 17:39:45 -0500 (EST)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYATH-000516-Sg for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 17:55:45 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2005 14:39:59 -0800
X-IronPort-AV: i="3.97,293,1125903600"; d="scan'208"; a="672064950:sNHT24959308"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA4MdQO9025685; Fri, 4 Nov 2005 14:39:57 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 14:39:55 -0800
Received: from [10.21.90.69] ([10.21.90.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 14:39:55 -0800
Message-ID: <436BE33A.1070906@cisco.com>
Date: Fri, 04 Nov 2005 17:39:54 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
Subject: Re: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
References: <77F357662F8BFA4CA7074B0410171B6DC9E609@XCH-NW-5V1.nw.nos.boeing.com>
In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E609@XCH-NW-5V1.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Nov 2005 22:39:55.0577 (UTC) FILETIME=[ADB4BA90:01C5E190]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
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

Henderson, Thomas R wrote:

>Acee, first, thanks for providing this information and (eventually) the
>code. 
>
>  
>
>>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.
>>
>>    
>>
>
>One potential problem that I foresee with this method is that, as
>connectivity conditions change in the network, one has to go back and
>re-evaluate whether previous decisions to suppress the formation of
>adjacencies are still valid.  Are you addressing this issue somehow, and
>if so, how?
>  
>
Actually, we are not doing any adjacency pruning. While the discussion 
has not subsided on this
issue my hope would be that any MPR based solution would use the relay 
state as a parameter for
adjacency reduction. However, heretofore this concept has not been fully 
developed.

>Tom
>
>  
>

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