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

[Acee Lindem <acee at cisco.com>]

Hi Tom,

See answers inline.

Henderson, Thomas R wrote:

>  
>
> > -----Original Message-----
> > From: Acee Lindem [mailto:acee at cisco.com] 
> > Sent: Friday, November 04, 2005 2:40 PM
> > To: Henderson, Thomas R
> > Cc: ospf-wireless-design at 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 at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design