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

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Sat, 05 November 2005 00:25 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 1EYBrm-0005jN-5p; Fri, 04 Nov 2005 19:25:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBrl-0005jC-3S for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 19:25:05 -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 TAA24257 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 19:24:42 -0500 (EST)
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYC6q-0007zs-Us for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 19:40:41 -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 SAA29275; Fri, 4 Nov 2005 18:24:48 -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 jA50OmH23663; Fri, 4 Nov 2005 16:24:48 -0800 (PST)
Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Nov 2005 16:24: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 16:24:38 -0800
Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E60E@XCH-NW-5V1.nw.nos.boeing.com>
Thread-Topic: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
Thread-Index: AcXhkLCfbX/fRFViSlisd+fUinWHZwADX7+Q
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: Acee Lindem <acee@cisco.com>
X-OriginalArrivalTime: 05 Nov 2005 00:24:39.0042 (UTC) FILETIME=[4EF16620:01C5E19F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: quoted-printable
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

 

> -----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)?  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.

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.

Tom

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