Subject: Re: [OSPF] ospf-lite welcomes comments

From: [email-masked]
Date: Thu, 27 Sep 2007 06:07:28 EDT

I observe (see email excerpt below) that OSPF-lite, though EU-funded  
research project, is rather not welcome. Hence it may be better to clarify  in the 
first place what is a valuable research objective for OSPF  improvements.
 
So let me ask you for your opinion wrt the following research ideas (maybe  
that they are already state of the art and I just don't know):
 
1) Optimizing the way how to determine the best next hop by some (root)  node 
with x adjacent links in a network with n nodes.
Assumed current practise: The current=root node computes the Dijkstra  
shortest path tree. Then, n-1 times, starting from any network node  x, it navigates 
towards the tree root.
 
Envisioned optimized alternative: The current=root node computes the  
Dijkstra shortest path tree. Then,  1 times, starting  from each root adjacent link, 
it navigates (recursively) towards the  leaves of the tree.
 
2) Respective impact to determine all equal-cost adjacent links.
 
3) Why just equal-cost multipath? Determine methods for safe (=loop-free)  
forwarding even if the costs are not equal.
 
Your opinion is appreciated.
 
Heiner

In einer eMail vom 18.09.2007 22:44:47 Westeuropäische Normalzeit schreibt  
[email-masked]:

Related  to this is the fact that nobody has *any* operational  
motivation to  deploy it, given that it appears to be nothing but a  
slightly  dumbed-down version of OSPF.  The first rule of displacing  
an  established product in the market is that you have to supplant it   
with something that is (or is perceived to be) a lot *better* in one   
way or another.  It either needs some killer functionality that   
people need, or it has to somehow be a lot cheaper.  This spec   
doesn't seem to achieve either one.

If you're serious about  displacing OSPF as we know it, come up with a  
spec that fixes the  *real* problems with OSPF (areas and DRs do not   
qualify.)

Like I've said, there's plenty of stuff about OSPF that I  think is  
stupid and counterproductive.  But the reality of the  situation is  
that OSPF is here, it's known, and it's *done.*   Without *really*  
compelling improvements in functionality, there's  simply no reason to  
go forward with  this.

--Dave

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

---

From: Acee Lindem <[email-masked]>
Date: Thu, 27 Sep 2007 10:56:46 -0400

Hi Heiner,

On Sep 27, 2007, at 6:07 AM, [email-masked] wrote:

> I observe (see email excerpt below) that OSPF-lite, though EU- 
> funded research project, is rather not welcome. Hence it may be  
> better to clarify in the first place what is a valuable research  
> objective for OSPF improvements.
>
> So let me ask you for your opinion wrt the following research ideas  
> (maybe that they are already state of the art and I just don't know):
>
> 1) Optimizing the way how to determine the best next hop by some  
> (root) node with x adjacent links in a network with n nodes.
> Assumed current practise: The current=root node computes the  
> Dijkstra shortest path tree. Then, n-1 times, starting from any  
> network node x, it navigates towards the tree root.
>
> Envisioned optimized alternative: The current=root node computes  
> the Dijkstra shortest path tree. Then,  1 times, starting from each  
> root adjacent link, it navigates (recursively) towards the leaves  
> of the tree.

The results of this may be interesting to the OSPF WG in general but  
note that this has been done before and that it can be done without  
changes to the base specification. In fact, this is stated in RFC  
2328 - section 16.1.

        The specification does not require that the above two stage
         method be used to calculate the shortest path tree.   
However, if
         another algorithm is used, an identical tree must be produced.
         For this reason, it is important to note that links between
         transit vertices must be bidirectional in order to be included
         in the above tree.  It should also be mentioned that more
         efficient algorithms exist for calculating the tree; for
         example, the incremental SPF algorithm described in [Ref1].

> 2) Respective impact to determine all equal-cost adjacent links.

I don't believe this is a very interesting research problem.

>
> 3) Why just equal-cost multipath? Determine methods for safe (=loop- 
> free) forwarding even if the costs are not equal.

Are you familiar with the work being done in the rtgwg? For example:

    draft-ietf-rtgwg-ipfrr-spec-base-09.txt

Of course, this doesn't delve in the forwarding plane issues with  
using the unequal-cost multi-path routes there has been work done  
here for load-based equal cost multipath.

http://www3.tools.ietf.org/html/draft-ietf-ospf-omp-00

If you're looking for suggestions on how to spend you research  
dollars, you could evaluate the 3 experimental drafts for OSPF MANET  
flooding and adjacency reduction.

Thanks,
Acee

> In einer eMail vom 18.09.2007 22:44:47 Westeuropäische Normalzeit  
> schreibt [email-masked]: