Re: [Ospf-wireless-design] OSPF Wireless Design Team Minutes

["Madhavi W. Chandra" <[e-mail]>]

Good notes.  One FYI comment inline...

On Wed, Mar 09, 2005 at 06:24:16PM -0500, Joe Macker wrote:
>  
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On 
> > Behalf Of Acee Lindem
> > Sent: Wednesday, March 09, 2005 1:49 PM
> > To: [e-mail]
> > Subject: [Ospf-wireless-design] OSPF Wireless Design Team Minutes 
> > 
> > All,
> > 
> > Yesterday morning Tom Henderson, Thomas Clausen, Joe Macker, 
> > Emmanuel Baccelli, and I got together to design team issues, 
> > progress, and actions. This E-mail includes my notes from the 
> > meeting. Please feel free to add comments and corrections.
> > 
> > One of the first things we discussed was how to handle the 
> > evolution of requirements.
> > All of us agreed that if we were going to make any progress 
> > we needed to stick to the original charter of the design. Joe 
> > reiterated that the MANET WG is actively pursing protocols 
> > optimized to MANET environments including reactive protocols. 
> > I added
> > that it would be interesting to see how either the protocols 
> > and/or concepts could be seamlessly integrated with OSPF 
> > (however, that also is not within the scope of the design team).
> > 
> > We diverged and had a brief discussion of wireless link 
> > metrics and agreed that while the handling of these could 
> > have a profound effect on the effectiveness on a wireless 
> > routing protocol but  they were also not within the scope of 
> > the design team or the OSPF WG.
> > 
> > Right now our immediate goal is to work toward a decision on 
> > the selection of a recommended flooding mechanism by the next 
> > IETF. This would include both the both the selection of who 
> > to flood to and the dissemination of 2-Hop neighbor 
> > information. We also discussed the difficulties of making a 
> > decision when design team members have ownership of the proposals.
> > 
> > Tom updated us on the progress with GTSNet and  indicated 
> > there were people in the process of coding Ogier's flooding 
> > extensions. GTSNet is the primary tool for evaluating 
> > flooding mechanisms.
> > 
> > Tom and Joe indicated one thing that was needed in the MPR 
> > (Chandra) proposal was how to reduce the number of 
> > adjacencies in very dense environments. In other words, how 
> > does one operate with a partial topology.
> > 
> > We concluded with a discussion of metrics should go into the  
> > MPR or CDS selection preference. Joe brought up some work his 
> > team had done with radio quality as a determining factor.
> Thanks Acee for the good summary.
> 
> The radio quality issue is really about an additional weighting factor not
> so much a determining factor.  Degree is still used but is not an overriding
> metric. 

Good!  We modified our overlapping relay selection algorithm a while ago
to incorporate wireless link metrics into the selection process...in 
addition to degree, overlap, and Willingness.  We didn't update our draft 
to include this since we think the selection algorithm of overlapping relays 
need not be standard, allowing flexibility.  The behavior of an active 
overlapping relay once selected is what should be standard.

> I also brought up a suggestion to look at adjancency failure/arrival models
> in evaluating approaches not just mobility.  Realistic time varying radio
> channels will be of this nature and mobility models along does not
> completely exercise 'real world" robustness and repairing efficiency
> Mobility alone within a bouncing box tends to have more persistent adjacency
> behavior as was shown in Richard's work. Having said that, I believe the
> work to date is good, but I think we need this additional consideration.

This sounds very reasonable.

Thanks,
Madhavi

> > 
> > Thanks,
> > Acee
> > 
> > 
> > _______________________________________________
> > Ospf-wireless-design mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
> > 
> 
> 
> 
> _______________________________________________
> Ospf-wireless-design mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

_______________________________________________
Ospf-wireless-design mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design