6 Mar 2008 21:27
Re: IETF 71 Preliminary Agenda
Joe Macker <joseph.macker <at> nrl.navy.mil>
2008-03-06 20:27:33 GMT
2008-03-06 20:27:33 GMT
Since this is proposal is fairly general has it been well vetted with the broader LSRP community? That is the real proper home for this work if accepted by the community. How has the presentation,etc gone within rtg wg or others OSPF, e.g.? As you mention, if vetted, manet may be an additional consideration. > -----Original Message----- > From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf Of Hokelek, Ibrahim > Sent: Monday, March 03, 2008 12:47 PM > To: manet <at> ietf.org > Cc: Dearlove, Christopher (UK); macker <at> itd.nrl.navy.mil > Subject: Re: [manet] IETF 71 Preliminary Agenda > > Dear manet WG members, > > There is extensive amount of work on the loop detection/avoidance for > the backbone network. Most of these works assume that link state routing > protocols (LSRPs) (e.g., OSPF and IS-IS) are in use. Micro-loops can > form in any stage of LSRPs (e.g., link metric changes) but especially if > there are link/node failures and hence the topology view of one node > might be different than others for a certain time period. During a > topology change, it might take longer for routing protocols to > convergence to their new routes and this long time may not be tolerated > by real-time applications such as voice and video. The IP Fast-reroute > (IPFRR) framework (draft-ietf-rtgwg-ipfrr-framework-08.txt) is proposed > to provide the fast convergence of the underlying routing protocols if > any topology change occurs (e.g., link/node failures). Micro-loops > become more serious issue in the IPFRR context since the routes are also > modified temporarily by the fast reroute process rather than determined > only by routing protocols. > > As we mentioned in our first e-mail, our proposed mechanism targets the > backbone networks but is very generic and applicable to any LSRP. We > would like to get the comments and feedback specifically from the manet > WG members during our presentation if provided. Once we obtain the > requirements of the manet LSRPs (e.g., OLSR and OSPF with MANET > extension), we would like to create a section in our draft to address > the applicability of our work to manet environment. > > I would like to also point out that due to mobility topology changes > occur much more frequently in manet environment than the backbone and > hence multiple simultaneous uncorrelated link failures can be observed > more likely. One important feature of our draft is to handle multiple > simultaneous uncorrelated failures. Another important point is that > LSRPs have certain timers. If these timers are set to small values the > routing convergence times can be reduced but the signaling overhead will > significantly increase. We believe that using our mechanism these timers > can be set to more stable (higher) values without increasing the routing > convergence times. > > > Regards, > Ibrahim Hokelek > > |---------------------------------| > | Ibrahim Hokelek | > | Telcordia Technologies, Inc. | > | Piscataway, NJ | > | Phone: 732-699-3905 | > | Fax: 732-336-7013 | > |---------------------------------| > > -----Original Message----- > From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf > Of Yasunori Owada > Sent: Monday, March 03, 2008 8:29 AM > To: Dearlove, Christopher (UK) > Cc: manet > Subject: Re: [manet] IETF 71 Preliminary Agenda > > I think we need to discuss this problem. > We have implemented OLSRv2 that runs as a Linux daemon and also runs on > QualNet simulator. In our simulation analysis, path looping issue seldom > appears when using abstructed PHY model, but it surely occurs when > realistic PHY parameters such as fading and bit error are given, and > mostly relatively space network topology. > I think, loop detection/avoidance are also required for the wired > network, but it is much significant issue for MANET because of its > limited wireless bandwidth and its high probability of loop formation > attributed to its frequency of topology information change and control > packet loss ratio. > I can explain how the loop is formed in OLSR and OLSRv2, that could not > be solved by additional (interval independent) HELLO message. > These loop formation is attributed to the topology information > inconsistency and asynchronous change of routing table. So that we need > to discuss these issues. > Thanks, > -- > Assistant Professor of Natural Hazard and Disaster Recovery, Niigata > University, Japan. > Yasunori Owada <owada <at> ie.niigata-u.ac.jp> > TEL: +81-25-262-7429 > > > > > 2008/3/3, Dearlove, Christopher (UK) <Chris.Dearlove <at> baesystems.com>: > > > > I don't believe this item is appropriate > > > > o Loop Detection/Avoidance Discussion - TBD > > - draft-hokelek-rlfap-01.txt > > > > First, the work (from different authors, but with that > > title) presented at the last IETF meeting failed to > > show any evidence of a problem, as was clear from its > > evidently incorrect static results, and had results which > > were entirely explicable based on the incorrect implementation > > of link quality described in that ID. The results were also > > at odds with the rest of the literature. > > > > Second, I've only just skimmed this ID, but as far as I can > > see it is not aimed at MANETs, the word "MANET" does not > > appear in it and none of the references are to MANET protocols > > (but there is at least one to backbone routing). > > > > -- > > Christopher Dearlove > > Technology Leader, Communications Group > > Networks, Security and Information Systems Department > > BAE Systems Advanced Technology Centre > > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > > Tel: +44 1245 242194 Fax: +44 1245 242124 > > > > BAE Systems (Operations) Limited > > Registered Office: Warwick House, PO Box 87, > > Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > > Registered in England & Wales No: 1996687 > > > > -----Original Message----- > > From: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On > Behalf > > Of Ian Chakeres > > Sent: 03 March 2008 07:38 > > To: manet > > Subject: [manet] IETF 71 Preliminary Agenda > > > > > > *** WARNING *** > > > > This mail has originated outside your organization, > > either from an external partner or the Global Internet. > > Keep this in mind if you answer this message. > > > > > > I have posted a preliminary agenda for IETF 71 at > > http://www.ietf.org/proceedings/08mar/agenda/manet.txt. > > > > Please let us know if you there are other items that you'd like > > discussed. > > > > Thanks. > > Ian Chakeres > > > > Note: Several items (marked TBD) are not confirmed, and they may not > > make it onto the final agenda given our two hour timeslot. > > _______________________________________________ > > manet mailing list > > manet <at> ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > > > > > _______________________________________________ > > manet mailing list > > manet <at> ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet <at> ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet <at> ietf.org > https://www.ietf.org/mailman/listinfo/manet
RSS Feed