Subject: [OSPF] ospf-lite welcomes comments

From: "Matthew Thomas" <[email-masked]>
Date: Fri, 14 Sep 2007 01:14:23 +0100

I would also like to point out the following: In OSPF V2 it seems that the graph algorithm was designed, and then all the vertices required are sent out on the wire. This includes some odd special cases such as the point-to-point lines with their extra stubs. I would say that perhaps this is the source of a lot of the frustration with this very effective protocol?

I am assuming judgement call was made, and a reasonable one, that it would be simpler to have all the ingredients of the final calculation actually on the wire. Ospf-lite only sends what you need to get your graph built. Vertices are created as needed. This is a fundamental difference in the shape of the protocol. As scaling goes further with projects such as hlphotnets the scalability of the protocol becomes as you say both less and more important. A realisation that we are in 'the noise' should surely allow the redesign without the argments of loading CPU etc. Loading / CPU is referred to in the document to nulify its relevance to change rather than a direct improvement. Implmentation simplification and operation over different media is the main desgn requirement for the protocol.

In a sense this protocol is ideal for the enterprise market. An open source link State 'EIGRP' if you will? I would greatly welcome further coments.

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Sep 2007 11:28:24 -0400

Hello Matthew,

On Sep 13, 2007, at 8:14 PM, Matthew Thomas wrote:

> I would also like to point out the following: In OSPF V2 it seems  
> that the graph algorithm was designed, and then all the vertices  
> required are sent out on the wire. This includes some odd special  
> cases such as the point-to-point lines with their extra stubs. I  
> would say that perhaps this is the source of a lot of the  
> frustration with this very effective protocol?
>
> I am assuming judgement call was made, and a reasonable one, that  
> it would be simpler to have all the ingredients of the final  
> calculation actually on the wire. Ospf-lite only sends what you  
> need to get your graph built. Vertices are created as needed. This  
> is a fundamental difference in the shape of the protocol. As  
> scaling goes further with projects such as hlphotnets the  
> scalability of the protocol becomes as you say both less and more  
> important. A realisation that we are in 'the noise' should surely  
> allow the redesign without the argments of loading CPU etc.  
> Loading / CPU is referred to in the document to nulify its  
> relevance to change rather than a direct improvement. Implmentation  
> simplification and operation over different media is the main desgn  
> requirement for the protocol.

So I guess this would be the "less filling" argument :^). In all  
seriousness, I don't think there is a strong requirement for a  
simpler version of OSPF. Also, IMHO, if we were going go through the  
pain of developing a new version of OSPF, we'd change a lot more than  
simply subseting the old version.

Thanks,
Acee

>
> In a sense this protocol is ideal for the enterprise market. An  
> open source link State 'EIGRP' if you will? I would greatly welcome  
> further coments.
>
> Matthew R Thomas
> [email-masked]
>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 14 Sep 2007 20:55:30 +0100

________________________________

From: Thomas, Matthew R
Sent: Fri 14/09/2007 20:33
To: Acee Lindem
Cc: 
Subject: RE: [OSPF] ospf-lite welcomes comments

Hi Acee,
 
I must disagree with your view of the 'less filling' argument. As the primary link State protocol OSPF could be better. Although updated, there had not been a re-evaluation of the design decisons made in almost 20 years. The protocol has become heavier and heavier as additions have been made. The cost of implementation is quite extreme. If you analyse the protocol carefully you will see that it is a complete rewrite, and more than a subsetting.
 
Reusing what has been implemented, in a similar way to Fast and Giga Ethernet knocking out more comlex new protocols is sensible.  It all comes down perhaps with 'what to keep and what to throw'. 20 years seems long enough to wait for a strip out and rebuild. The wheel does work well after all. 
 
Areas block mobile applications and complexities reduce the ability of lighter mobile implementations. 
 
I hope that people get a chance to look at some of the details,
 
Matthew R Thomas

________________________________

From: Acee Lindem [mailto:[email-masked]]
Sent: Fri 14/09/2007 16:28
To: Matthew Thomas
Cc: [email-masked]
Subject: Re: [OSPF] ospf-lite welcomes comments

Hello Matthew,  

	 

So I guess this would be the "less filling" argument :^). In all seriousness, I don't think there is a strong requirement for a simpler version of OSPF. Also, IMHO, if we were going go through the pain of developing a new version of OSPF, we'd change a lot more than simply subseting the old version. 

Thanks,
Acee

	 
	Matthew R Thomas
	[email-masked]