Subject: [Ospf-manet] How can we get GTNet software?

From: Philippe Jacquet <[email-masked]>
Date: Mon, 03 Apr 2006 10:42:39 +0200

Sorry, I may have lost the posts which detailled the status and 
directions aboutGTNet software downloads. Can anyone update me on that 
subject?

Thanks in advance,

Best regards,
Philippe

_______________________________________________
Ospf-manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-manet

---

From: Acee Lindem <[email-masked]>
Date: Mon, 03 Apr 2006 06:28:02 -0400

> directions aboutGTNet software downloads. Can anyone update me on that 

Hi Philippe,

Here is the link:

<http://hipserver.mct.phantomworks.org/ietf/ospf/>

Thanks,
Acee

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 3 Apr 2006 06:49:27 -0700

Philippe, if you are interested, we can work with you to incorporate a
model of your draft in the quagga code.

Tom 

> -----Original Message-----
> From: Philippe Jacquet [mailto:[email-masked]] 
> Sent: Monday, April 03, 2006 1:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ospf-manet] How can we get GTNet software?
>

---

From: Philippe Jacquet <[email-masked]>
Date: Wed, 05 Apr 2006 22:57:22 +0200

Thanks, Acee, thanks Tom,

Sorry for the delay. I just have realized why these emails got lost, I 
have a zealous anti-spammer that systematically dropped the emails.

Yes it would be great to synchronize our efforts on GTNet. Let's see how 
to proceed.

Best regards,
Philippe

Acee Lindem wrote:

>> directions aboutGTNet software downloads. Can anyone update me on 
>> that subject?
>
>
> Hi Philippe,
>
> Here is the link:
>

---

From: Richard Ogier <[email-masked]>
Date: Tue, 11 Apr 2006 10:38:12 -0700

> Yes it would be great to synchronize our efforts on GTNet. Let's see 
> how to proceed.
>
> Best regards,
> Philippe 

I am glad that INRIA is finally joining the simulation evaluation
effort.  I am not opposed to using MPRs (in addition to a CDS),
but we need to evaluate them to see how they perform.

At the IETF meeting, Bill Fenner encouraged us to work together, so
I guess there was a perception at the meeting that we have not been
working together.  I think we have been working together, since both
Cisco and I have been working with Boeing to compare the two proposals
that have been around for the last year.

INRIA submitted their proposal only just before the last meeting, about
a year after the other two proposals, and it is still not completely
defined.  I am not sure why INRIA waited so long, but it is difficult
to evaluate their proposal when it is the only one that has not yet
been implemented in GTNetS (or even completely described).
If INRIA had submitted their (fully defined) proposal a year ago, then
we might have been able to fully evaluate it by now.

But if the consensus is that we should evaluate INRIA's proposal
(despite its late entry) then we should go ahead and do that, and also
evaluate methods that use a combination of MPRs and a CDS (MDRs),
before we make any decisions.  In this way, we should be able to
work together to decide on the best solution.

Richard

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 21 Apr 2006 17:15:06 +0200

Dear Richard,

I am glad that you consider our contribution as an interesting item. We 
have produced this draft after the design team called for short 
contributions on the subject. We apologize that we publish the draft a 
little late, but we wanted to have something clean and we thank you 
again for having immediately pointed last minute mistakes in the text. 
However most of the items that are describing in our draft were already 
intensively discussed on the mailing list for a long time, and of them 
were already simulated. In particular:

1. Robustness of MPR flooding
2. Topology reduction and synchronization of advertized links.

I recognize that the concept of MDR has interesting feature in providing 
a reduced synchronizing backbone, but one must investigate the effect of 
advertizing non synchronized links in the core OSPF. Maybe we could give 
less synchronization priority degree to other synchronized links. Maybe 
some interesting combinations are possible.

My first rule of the thumb evaluation let me think that advertizing full 
LSA's everytime there is a change may lead to a tremendous overhead, 
comparable to the of cost of synchronizing all links. Or we should 
accept that wireless OSPF would work on slow moving or quasi static 
wireless networks, and not on all kinds of MANETs.

I am looking forward the simulation results.

Best regards,
Philippe

Richard Ogier wrote:

>> Sorry for the delay. I just have realized why these emails got lost, 
>> I have a zealous anti-spammer that systematically dropped the emails.
>>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 21 Apr 2006 15:40:23 -0700

> Sent: Friday, April 21, 2006 8:15 AM
> To: Richard Ogier
> Cc: [email-masked]
> Subject: Re: [Ospf-manet] How can we get GTNet software?
> 
> 

This comment causes me to ask (perhaps more broadly of the OSPF MANET
list than just of Philippe) how one should evaluate the effect of
advertising these non-adjacent neighbors?  I have heard several people
declare general discomfort with this strategy without being able to
precisely describe why there is a problem.

Of course, in an unconstrained situation, we can form adjacencies with
everyone and advertise full topology and run sub-second Hellos, but this
is OSPF MANET and we have to trade off some of these items to achieve
better scalability.  

I think that two separate issues are being conflated in this discussion.
Adjacencies are used to preserve database synchronization in an OSPF
network.  Type 1 links are advertised in LSAs to provide a graph upon
which to build paths.  I fail to see why it should be the case that all
advertised links should be adjacent links.  If anything, it should be
the link or neighbor quality that governs whether the link is included
in the data plane, not whether it exists in the OSPF control plan.  What
is the problem here?  

> comparable to the of cost of synchronizing all links. 

Exactly.

> Or we should 

I don't think we have to accept that.  However, I do think that if we
declare that OSPF MANET will only work on quasi-static or sparse MANETs,
and we do not allow for strategies to intelligently prune dense
topologies when they arise, OSPF MANET will have been a wasted effort.

Tom

---

From: Richard Ogier <[email-masked]>
Date: Mon, 24 Apr 2006 12:27:07 -0700

Philippe,

Philippe Jacquet wrote:

> Dear Richard,
>
> I am glad that you consider our contribution as an interesting item. 
> We have produced this draft after the design team called for short 
> However most of the items that are describing in our draft were 
> already intensively discussed on the mailing list for a long time, and 
> of them were already simulated. In particular:
>

I was referring to a detailed specification of your solution, which
did not come until just before the last IETF meeting. (Actually, it
probably still needs some more details before it is fully specified.)
Also, your simulations used abstract, simplified models.
Both the MDR and OR solutions have been implemented in GTNetS for
about a year.  Hopefully, INRIA's solution will be implemented in
GTNetS soon.

>
>
> I recognize that the concept of MDR has interesting feature in 
> providing a reduced synchronizing backbone, but one must investigate 
> the effect of advertizing non synchronized links in the core OSPF.

There is a common misconception here, which has been discussed.
OSPF does advertise links that are not synchronized (but are indirectly
synchronized). I mentioned this in Section 2.4 of the MDR draft.
(Note that I modified the overview of OSPF-MDR in the draft
to provide more motivation.)  The network-LSA of OSPF implies there is
a direct connection between any two routers attached to the same
broadcast network, if both routers are synchronized with the DR.
This implies that any such router can use any other such routeras a next 
hop (in the SPF calculation). Of course, a network-LSA cannot
describe the general topology of a MANET, so it is necessary to
explicitly include non-adjacent neighbors in the router-LSA.
In both cases, the LSA does imply that unsynchronized links can be
used for routing (even beyond the first hop).

Of course, even in your solution the first hop of a route need not
be synchronized, which could cause a problem unless you use a
routability condition as in OSPF-MDR.

Anyway, the simulation results will show how performance is affected
when unsynchronized links are advertised.  I think the main difference
will be that the solution will not be as scalable if all MPRs are
required to be synchronized.

> Maybe we could give less synchronization priority degree to other 
> synchronized links. Maybe some interesting combinations are possible.

The GTNetS simulations already assign a slightly larger metric to
unsynchronized links.

Richard

>
>
> My first rule of the thumb evaluation let me think that advertizing 
> full LSA's everytime there is a change may lead to a tremendous 
> overhead, comparable to the of cost of synchronizing all links. Or we 
> should accept that wireless OSPF would work on slow moving or quasi 
> static wireless networks, and not on all kinds of MANETs.
>

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 28 Apr 2006 15:07:10 +0200

Dear Tom,

Maybe the discomfort comes from the fact that we tried to go too fast on 
MANET over OSPF. Since people seem already reluctant to have flooding on 
non adjacent links, we may expect even more reluctance to have data 
routed over non adjacent links. Indeed data doesn’t have sequence number 
and loops of data packets could be possible (although it is rather 
unlikely). I would say that MANET belongs more to the land of best 
effort, and OSPF belongs more to the land of exactitude, so to speak, in 
terms of routing. I am sure that MANET-OSPF can find a good compromise 
in between.

For example, I don’t think that we have to sacrifice some performance 
for exactitude (or not more than temporarily). In particular, 
synchronization overhead can be greatly reduced by using signature 
exchange between direct neighbors. If in the near future there is a 
trend towards using such an optimization, then the performance issues 
related to synchronization overhead will disappear.

Best regards,
Philippe

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 28 Apr 2006 10:44:10 -0700

Philippe, comments inline:

> Sent: Friday, April 28, 2006 6:07 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: advertising non-adjacent links (was RE: 
> [Ospf-manet] How canwe get GTNet software?)
> 
> Dear Tom,
> 
> routed over non adjacent links. 

I do not think these issues are the same.  Retransmissions are related
to preserving database synchronization and are hence related to
adjacencies.  When the topic of flooding over non-adjacent links has
arisen in the past, an implementor complained that it would be too
disruptive to their implementations to decouple retransmissions from
adjacencies.  Richard has also pointed out numerous times that OSPF
already allows data to be forwarded over non-adjacent links.

I am not disputing that there may be reluctance to forward data over non
adjacent links, only that this reluctance has never been justified
adequately in my opinion (including this message).

> Indeed data doesn't have 
> sequence number 
> For example, I don't think that we have to sacrifice some performance 

You seem to be suggesting that the reduction of synchronization overhead
by making the existing process more efficient can approach the
efficiency of just suppressing some of the adjacencies.  I think that
remains to be seen and would add that it is may be the combination of
both that would be the most efficient.  I don't know what the level of
acceptance of changes to database synchronization procedures would be,
relative to the acceptance of procedures to suppress some adjacencies  

Regards,
Tom