Re: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
Acee Lindem <acee@cisco.com> Mon, 07 November 2005 02:19 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 1EYwbs-0008R2-Ss; Sun, 06 Nov 2005 21:19:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYwbr-0008Or-QM for ospf-wireless-design@megatron.ietf.org; Sun, 06 Nov 2005 21:19:47 -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 VAA05600 for <ospf-wireless-design@ietf.org>; Sun, 6 Nov 2005 21:19:21 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYwrO-0003lS-1u for ospf-wireless-design@ietf.org; Sun, 06 Nov 2005 21:35:50 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2005 18:19:38 -0800
X-IronPort-AV: i="3.97,298,1125903600"; d="scan'208"; a="227726261:sNHT26323412"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jA72Ig6e010092; Sun, 6 Nov 2005 18:19:30 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 18:04:38 -0800
Received: from [10.21.90.69] ([10.21.90.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Nov 2005 18:04:37 -0800
Message-ID: <436EB634.1000200@cisco.com>
Date: Sun, 06 Nov 2005 21:04:36 -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: <77F357662F8BFA4CA7074B0410171B6DC9E60E@XCH-NW-5V1.nw.nos.boeing.com>
In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E60E@XCH-NW-5V1.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2005 02:04:37.0555 (UTC) FILETIME=[9B295830:01C5E33F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
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
Hi Tom, See answers inline. Henderson, Thomas R wrote: > > > > >>-----Original Message----- >>From: Acee Lindem [mailto:acee@cisco.com] >>Sent: Friday, November 04, 2005 2:40 PM >>To: Henderson, Thomas R >>Cc: ospf-wireless-design@ietf.org >>Subject: Re: [Ospf-wireless-design] OSPF Flooding and Higher Mobility >> >>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. >> >> >> > >Regardless of pruning, do you agree that there is a potential problem of >making a decision to suppress an adjacency but having to later >re-evaluate it (because the path via real adjacencies disappears)? > I believe we handle this case. > It >almost seems to me to require (in the extreme) a recheck of all >unsynchronized adjacent neighbors when any topology changes in the >network, or to log some side information, per suppressed adjacency, that >the suppressed adjacency is dependent on certain other full adjacencies >to stay up. > > We do not this. In the little I've thought about, it almost seems like it would pretty complex. >Further, if you are not doing pruning, I'd be curious to understand >whether simulations suggest that there is overhead growth over time as >adjacencies accumulate. But I think you are saying above that you would >like to do pruning but haven't figured out the details yet. > > Right - we don't do pruning and over time adjacencies could accumulate dependent on the nature of the topology changes. What is interesting about the results is the fact that the overhead comparisons are significantly different when a lower velocity/pause time scenarios are examined. This is despite that that smart peering may not be the optimal adjacency reduction mechanism. Thanks, Acee >Tom > > > _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
- [Ospf-wireless-design] OSPF Flooding and Higher M… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- RE: [Ospf-wireless-design] OSPF Flooding and High… Spagnolo, Phillip A
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- RE: [Ospf-wireless-design] OSPF Flooding and High… Alvaro Retana
- RE: [Ospf-wireless-design] OSPF Flooding and High… Henderson, Thomas R
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- RE: [Ospf-wireless-design] OSPF Flooding and High… Henderson, Thomas R
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- [Ospf-wireless-design] Smart Peering draft update Abhay Roy