Subject: Re: advertising non-adjacent links (was RE: [Ospf-manet] How can we get GTNet software?)

From: Richard Ogier <[email-masked]>
Date: Tue, 02 May 2006 10:56:57 -0700

Philippe Jacquet wrote:

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

Such an optimization would involve a substantial departure from OSPF.
I thought we decided to keep the OSPF notions of adjacencies and database
exchange in order to minimize changes to OSPF.  Otherwise, we are designing
a new protocol.  Also, as Joe said at the OSPF WG meeting in Dallas,
we should not over-optimize.  I think such discussions of optimizations
should have been done about two years ago.  In fact, such discussions did
take place about two years ago, so there has been plenty of time to
design and implement an OSPF extension based on them, but I think this
was not done because the WG wanted to minimize changes to OSPF.
Anyway, in the interest of avoiding further delays, I don't think we
should be considering new approaches that will take another
year or two to fully design and implement (i.e., we should not
over-optimize).

Related to this, I proposed an optimization about two years ago in which
each MDR periodically multicasts (to all neighbors) a complete set of DD
packets, similar to the complete sequence numbers packets of IS-IS.
I think this would require less of a change to OSPF than the
signature exchange method.  However, I don't think it would reduce
overhead significantly compared to MDR-based adjacency reduction.

I think most of us agree that the MDR approach is a good way to
reduce adjacencies.  But I think some of the details of the
MDR solution can be improved and/or simplified.
(For example, use link quality to avoid repeatedly forming
an adjacency with a poor quality neighbor.)
As Acee said at the IETF meeting, we need more experience with
people looking at the solution and implementing and optimizing it.
Therefore, I encourage people to look at the MDR draft and to
suggest improvements:

http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-07.txt

Richard

> Best regards,
> Philippe

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

---

From: Richard Ogier <[email-masked]>
Date: Tue, 02 May 2006 17:21:24 -0700

> good compromise in between.

I think that MANET-OSPF has already found a good compromise in between,
by allowing non-adjacent links to be used for routing, but requiring that
the set of adjacencies form a connected (or biconnected) spanning graph.
In fact, RFC 2328 already found such a compromise, since it allows data
to be forwarded over non-adjacent links (as has been mentioned many
times).

Richard

> Henderson, Thomas R wrote:
>
>>
>>
>>  
>>
>>> -----Original Message-----
>>> From: Philippe Jacquet [mailto:[email-masked]] Sent: 
>>> Friday, April 21, 2006 8:15 AM
>>> To: Richard Ogier
>>> Cc: [email-masked]
>>> Subject: Re: [Ospf-manet] How can we get GTNet software?
>>>
>>>
>>> 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.
>>>   
>>
>>
>> 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? 
>>  
>>
>>> 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.   
>>
>>
>> Exactly.
>>
>>  
>>
>>> 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 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: "Joe Macker" <[email-masked]>
Date: Tue, 9 May 2006 11:41:17 -0400

Let me restate what I was trying to say in Dallas. When we began this DT
effort it was agreed it was a non-goal to be optimal. We knew this would
drive us into a longer term research state if we let it take hold of the
process.

Some rough goals we had:

- Improve OSPF mechanisms in MANET and wireless environments
- Minimize design changes in the overall OSPF design framework
- Engineer and test first order improvements in scaling

I think the DT has achieved most of what it set out to do and had a fairly
long engineering evaluation phase. Optimization and extensions can continue
to be discussed but I suggest we concentrate on getting the initial work
progressed.  When you look at what we had before and what we have on the
table its clearly an improvement.

-joe

>From: Richard Ogier [mailto:[email-masked]] 
>Sent: Tuesday, May 02, 2006 1:57 PM
>To: [email-masked]
>Subject: Re: advertising non-adjacent links (was RE: 
>[Ospf-manet] How can weget GTNet software?)
>
>Philippe Jacquet wrote:
>
>> Dear Tom,
>>
>> have data routed over non adjacent links. Indeed data doesn't have 
>> For example, I don't think that we have to sacrifice some 
>performance 
>I thought we decided to keep the OSPF notions of adjacencies 
>and database exchange in order to minimize changes to OSPF.  
>Otherwise, we are designing a new protocol.  Also, as Joe said 
>at the OSPF WG meeting in Dallas, we should not over-optimize. 
> I think such discussions of optimizations should have been 
>done about two years ago.  In fact, such discussions did take 
>place about two years ago, so there has been plenty of time to 
>design and implement an OSPF extension based on them, but I 
>think this was not done because the WG wanted to minimize 
>changes to OSPF.
>Anyway, in the interest of avoiding further delays, I don't 
>think we should be considering new approaches that will take 
>another year or two to fully design and implement (i.e., we 
>should not over-optimize).
>
>Related to this, I proposed an optimization about two years 
>ago in which each MDR periodically multicasts (to all 
>neighbors) a complete set of DD packets, similar to the 
>complete sequence numbers packets of IS-IS.
>signature exchange method.  However, I don't think it would 
>reduce overhead significantly compared to MDR-based adjacency 
>reduction.
>
>I think most of us agree that the MDR approach is a good way 
>to reduce adjacencies.  But I think some of the details of the 
>(For example, use link quality to avoid repeatedly forming an 
>adjacency with a poor quality neighbor.) As Acee said at the 
>IETF meeting, we need more experience with people looking at 
>the solution and implementing and optimizing it.