Subject: [manet] IETF 71 Preliminary Agenda

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 3 Mar 2008 13:08:21 +0530

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
[email-masked]
https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 3 Mar 2008 09:07:26 -0000

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: [email-masked] [mailto:[email-masked]] 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. 

Please let us know if you there are other items that you'd like
discussed.

Thanks.
Ian Chakeres

********************************************************************
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.
********************************************************************

---

From: "Yasunori Owada" <[email-masked]>
Date: Mon, 3 Mar 2008 22:28:49 +0900

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 <[email-masked]>
TEL: +81-25-262-7429

---

From: "Hokelek, Ibrahim" <[email-masked]>
Date: Mon, 3 Mar 2008 12:46:33 -0500

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]>
TEL: +81-25-262-7429

---

From: mase <[email-masked]>
Date: Tue, 04 Mar 2008 07:00:40 +0900

>at odds with the rest of the literature.

Some follow-up explanations and results on our presentation on loop 
detection at the last IETF were recently submitted in MANET mailing 
list. We welcome detail technical discussions.

Kenichi

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 5 Mar 2008 10:53:43 +0530

I will continue to update the agenda as we approach the meeting next Monday.

http://www.ietf.org/proceedings/08mar/agenda/manet.txt

If you are a presenter please send me your materials as soon as
possible. I will make the presentations available before the meeting
Monday.

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=71

Thank you,
Ian Chakeres

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 6 Mar 2008 15:27:33 -0500

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.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hokelek, Ibrahim
> Sent: Monday, March 03, 2008 12:47 PM
> To: [email-masked]
> Cc: Dearlove, Christopher (UK); [email-masked]

---

From: "Hokelek, Ibrahim" <[email-masked]>
Date: Fri, 7 Mar 2008 11:07:37 -0500

Joe -

We presented this draft first time at the 69th IETF meeting in the rtg
ipfrr wg. There was good discussion on this topic by the participants.
We left it there with more discussion to be conducted on the mailing
list. At that time, we did not have a working implementation of our
proposal. Since then, we have an implementation of our proposal that
works with Cisco routers (running OSPF) and we plan to also implement
our proposal in open-source xorp routers. We also have results on
coverage of LFAPs when node/link failures occur based on our proposal &
BRITE generated topologies. Our initial results have demonstrated that
small neighborhood size is sufficient for the complete coverage & are
promising. We plan to present these results in the Routing Area Open
Meeting in the coming IETF mtg.

Our proposal considers scenarios of multiple failures occuring
simultaneously which are more likely in a manet setting rather than a
commercial deployment. Hence, the rtg wg chair suggested that we also
contact the manet wg to see if there is any interest in adopting this
proposal within their charter. Our proposal can be implemented either
within the router by modifying the router implementation or as an
adjunct to the router as an agent & there are pro's & con's of either
approach. Hence, we wanted to explore whether we should consider this as
a potential extension to OLSRv2 that is being worked in the MANET WG. We
could present the pro's & con's next week if the group is interested.

Regards,
Ibrahim.

-----Original Message-----
From: Joe Macker [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 3:28 PM
To: Hokelek, Ibrahim; [email-masked]
Cc: 'Dearlove, Christopher (UK)'
Subject: RE: [manet] IETF 71 Preliminary Agenda

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.

> Of Hokelek, Ibrahim
> 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 

> 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
> 

> >  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
> >  Registered Office: Warwick House, PO Box 87,  Farnborough Aerospace

> > Centre, Farnborough, Hants, GU14 6YU, UK  Registered in England & 
> > Wales No: 1996687
> >
> >  This mail has originated outside your organization,  either from an

> > external partner or the Global Internet.
> >  Note: Several items (marked TBD) are not confirmed, and they may 
> > not  make it onto the final agenda given our two hour timeslot.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 7 Mar 2008 08:12:00 -0800

When do you want to talk about SEAL? Right after SMF maybe?
Draft is here:

  http://www.ietf.org/internet-drafts/draft-templin-seal-03.txt

Fred
[email-masked] 

>From: Ian Chakeres [mailto:[email-masked]] 
>Sent: Sunday, March 02, 2008 11:38 PM
>To: manet

---

From: "Joe Macker" <[email-masked]>
Date: Fri, 7 Mar 2008 16:00:51 -0500

I was going to mention SEAL as one of the likely follow-on efforts in my SMF slides.

-Joe

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Friday, March 07, 2008 11:12 AM
> To: Ian Chakeres; manet