Subject: [OSPF] ospf-lite welcomes comments

From: "Thomas, Matthew R" <[email-masked]>
Date: Thu, 13 Sep 2007 22:43:24 +0100

Hi,

http://www.ietf.org/internet-drafts/draft-thomas-hunter-reed-ospf-lite-00.txt <http://www.ietf.org/internet-drafts/draft-thomas-hunter-reed-ospf-lite-00.txt>  
has recently been posted. 

Please do feel free to comment,

Many Thanks,

Matthew R Thomas
[email-masked]

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

---

From: Dave Katz <[email-masked]>
Date: Thu, 13 Sep 2007 16:38:05 -0700

OK, I'll bite.

I simply don't see the purpose of doing this.  Anybody building a new  
implementation is going to have to do the full protocol until such  
time as this scheme achieves wide deployment, which is never going to  
happen.  Therefore, there is not going to be any reduction in  
implementation complexity in the forseeable future.

As far as runtime efficiencies go (CPU/network), they're going to be  
in the noise.  As you point out, CPUs and network media have gotten  
orders of magnitude faster in 20 years, and OSPF simply doesn't tax  
networks in any meaningful way, and the changes offered here will not  
change that load in any meaningful way (actually it will *increase*  
both CPU and network load by getting rid of DRs.)

Basically, the only argument in favor of this scheme would be a  
modest reduction in implementation complexity, but in reality you  
will greatly *increase* implementation complexity because there is no  
feasible way (IMHO) to ever implement *just* this scheme.  Now we  
have to implement two slightly different schemes.  This is not progress.

I would not have an objection, at least in principle, to some new  
protocol that would eliminate some of the more baroque design choices  
in OSPF (those who know me have heard me rant for two decades on how  
stupid some of it is), but only if there is a *meaningful*  
improvement in functionality.  Otherwise it seems like a waste of time.

--Dave

On Sep 13, 2007, at 2:43 PM, Thomas, Matthew R wrote:

> Hi,
>
> http://www.ietf.org/internet-drafts/draft-thomas-hunter-reed-ospf- 
> lite-00.txt <http://www.ietf.org/internet-drafts/draft-thomas- 
> hunter-reed-ospf-lite-00.txt>

---

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

Well in fact the DR LSA's only reduce complexity if you have a large number 
of routers on the ethernet. If you have under 5 then the traffic actually 
decreases.

Now the DR LSA as you know is flooded through the whole area, so the DR 
saves locally, but then floods everrywhere, thus increasing the load. With 
todays VLANS, 5 routers per Lan is very reasonable. The traffic load from 
OSPF is absolutely negligable. On a 100 MB Ethernet it can be as low as 
0.008 % even with 1000 routers in a single area. Simulations are not 
required as you can acually calculate the LSA sizes and loads based on the 
packet structure.

So the arguments of N^2 actually do not compute. The arguments of having to 
support two protocols are valid.

The implementation is made significantly easier. The whole design process 
can be removed. The removal of things like DR prevent costly analysis from 
design to design that usually end up with the same design..  I understand 
your comments though..

Matthew R Thomas

----- Original Message ----- 
From: "Dave Katz" <[email-masked]>
To: "Thomas, Matthew R" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 14, 2007 12:38 AM
Subject: Re: [OSPF] ospf-lite welcomes comments

> implementation is going to have to do the full protocol until such  time 
> as this scheme achieves wide deployment, which is never going to  happen. 
> Therefore, there is not going to be any reduction in  implementation 
> complexity in the forseeable future.
>
> As far as runtime efficiencies go (CPU/network), they're going to be  in 
> the noise.  As you point out, CPUs and network media have gotten  orders 
> of magnitude faster in 20 years, and OSPF simply doesn't tax  networks in 
> any meaningful way, and the changes offered here will not  change that 
> load in any meaningful way (actually it will *increase*  both CPU and 
> network load by getting rid of DRs.)
>
> Basically, the only argument in favor of this scheme would be a  modest 
> reduction in implementation complexity, but in reality you  will greatly 
> *increase* implementation complexity because there is no  feasible way 
> (IMHO) to ever implement *just* this scheme.  Now we  have to implement 
> two slightly different schemes.  This is not progress.
>
> protocol that would eliminate some of the more baroque design choices  in 
> OSPF (those who know me have heard me rant for two decades on how  stupid 
> some of it is), but only if there is a *meaningful*  improvement in 
> functionality.  Otherwise it seems like a waste of time.
>
> --Dave
>
>

---

From: Dave Katz <[email-masked]>
Date: Fri, 14 Sep 2007 12:01:34 -0700

On Sep 13, 2007, at 4:45 PM, Matthew Thomas wrote:

> Well in fact the DR LSA's only reduce complexity if you have a  
> large number of routers on the ethernet. If you have under 5 then  
> the traffic actually decreases.
>
> Now the DR LSA as you know is flooded through the whole area, so  
> the DR saves locally, but then floods everrywhere, thus increasing  
> the load. With todays VLANS, 5 routers per Lan is very reasonable.  
> The traffic load from OSPF is absolutely negligable. On a 100 MB  
> Ethernet it can be as low as 0.008 % even with 1000 routers in a  
> single area. Simulations are not required as you can acually  
> calculate the LSA sizes and loads based on the packet structure.
>
> So the arguments of N^2 actually do not compute. The arguments of  
> having to support two protocols are valid.
>
> The implementation is made significantly easier. The whole design  
> process can be removed. The removal of things like DR prevent  
> costly analysis from design to design that usually end up with the  
> same design..  I understand your comments though..

> 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

All of this is theoretically true, but I really don't understand what  
the point is.  It creates a tremendous amount of work for nonexistent  
gains.  What is the *real* motivation for this proposal?  I just  
don't get it.  It appears to be entirely an academic exercise, and I  
don't have time for those.

Given that the only tangible benefit is a minor reduction in  
implementation complexity, it's only a net gain for some implementor  
that is building a product that will operate *only* in a domain in  
which *only* this version of OSPF is being deployed.  If such a  
market exists, they should form their own forum and go off into their  
corner and have fun with it (and then go out of business because they  
can't interoperate with the vast deployed base.)

Further, the stuff you're removing is a tiny fraction of the  
complexity of a full implementation;  even if such a market existed  
where a vendor could implement only this, the savings are utterly  
marginal.

 From the operator standpoint, there's almost no gain.  If we're  
looking for "simple and stupid" in configuration, it would be trivial  
to do simplification as a CLI hack:  "protocol ospf-enterprise/ 
interface foo/end".  The config system sets up the area for you.   
Yes, the LSA database would be a little simpler, but with mature  
implementations that have worked for a decade or more I'd suspect  
that most operators don't spend a lot of time dissecting the LSA  
database, and there's almost 20 years experience in doing so.

As for bringing up EIGRP, well, I had the honor of rewriting the  
implementation without the benefit of being able to change the broken  
design.  You don't want to get me started there.  Let's just say that  
I wouldn't cozy up to those letters.  ;-)

As an ironic aside, the place where OSPF failed to scale in practice  
were the crazy full-mesh L2 networks that were so popular in the late  
90s;  hundreds of neighbors creating O(N^3) information on a link  
failure, or O(N^4) information on a node failure (each packet is O(N)  
in size.)  We got really good at scaling fixes as a result.

If I were to take on an incompatible change in this protocol, I'd  
start with mechanisms that would allow fail-safe pruning of the  
flooding tree, and add flap-free soft refresh of the LSA database.   
But that's just me.

--Dave

---

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

Hi Dave,
 
Most vendors have had trouble stabilising their code. I was implementing the odd proteon, 6611's and Wellfleet /Bay /Nortel back in 1996 and it was odd. Some companies today exist soley to help vendors achieve stabilty. In terms of Open Source some implementations some have taken 15 years and are still finalising for full commercial use. I would say IMHO that after almost 20 years of this approach, perhaps an adjustment needs to be made?
 
The protocol is complex and could be much simpler. I advocate a simplification of this protocol. I believe it is time that we perhaps tested what has really been happening. This will pay off in the long run. Ospf-lite is not a forklift upgrade. Multiple instances could run quite happily. In the case of customers connecting to MPLS networks there are multiple instances of OSPF running anyway. Any of these could be ospf-lite. I do agree with your view of EIGRP. However there was wisdom in the area  outlook on the protocol.
 
A link State protocol should be much simpler to implement. Routing a few hundred thousand routes should not be such an onerous task. Our scalability comes from very old impressions. Are areas ( not including Internet route isolation) really required? Yet they are almost globally employed.
 
I do appreciate your view though,
 
Matthew R Thomas

________________________________

From: Dave Katz [mailto:[email-masked]]
Sent: Fri 14/09/2007 20:01
To: Matthew Thomas
Cc: Thomas, Matthew R; [email-masked]
Subject: Re: [OSPF] ospf-lite welcomes comments

--Dave

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 14 Sep 2007 21:04:38 +0100

Dave,
 
In terms of shelling a CLI hack, the most major change to the protocol is a unified network type, which of course is QUITE unshellable.. :o)  (section 2)
 
Matthew R Thomas

From: Thomas, Matthew R
Sent: Fri 14/09/2007 20:49
To: Dave Katz
Cc: [email-masked]
Subject: RE: [OSPF] ospf-lite welcomes comments

Hi Dave,

 

Matthew R Thomas

--Dave

---

From: Dave Katz <[email-masked]>
Date: Tue, 18 Sep 2007 13:31:32 -0700

I guess my point is that getting rid of areas and DRs does not  
significantly simplify the implementation, and such implementation  
will continue to be hard.  Furthermore, a *good* implementation of  
even a simpler protocol is quite hard.  For example, the OSPF spec  
considers "flood the LSA" to be an atomic operation;  the expectation  
is that you'll queue up a copy of it on every interface and on the  
retransmission lists of every neighbor.  This is one of the reasons  
that accidentally dumping full routing into OSPF causes such  
heartburn in many implementations;  a massive origination of LSAs  
multiplied by large numbers of neighbors causes a tremendous state  
explosion.  Fixing this is not easy and requires intuitive knowledge  
of the protocol.

The fact that most people can't manage to do good implementations of  
OSPF means that they should go out of business.  There's a reason  
that there are only two dominant implementations.  Frankly, I like  
the fact that it's not trivial, but then I'm a capitalist and a  
stockholder.  A slightly easier version of the protocol is not going  
to change this significantly.

Aside from all this, I see two fundamental issues in doing anything  
like this.  First is the implementation issue;  having a "simpler"  
OSPF accomplishes nothing unless the old OSPF can be made to  
disappear (so that you don't have to implement it.)  Otherwise you  
have only succeeded in making every implementor's life even more  
difficult, and I guarantee that nobody will want anything to do with  
it.  Even if it were the best thing since sliced bread, you then have  
to figure out how to transition a network to it.

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

On Sep 14, 2007, at 12:49 PM, Thomas, Matthew R wrote:

> Hi Dave,
>
> Most vendors have had trouble stabilising their code. I was  
> implementing the odd proteon, 6611's and Wellfleet /Bay /Nortel  
> back in 1996 and it was odd. Some companies today exist soley to  
> help vendors achieve stabilty. In terms of Open Source some  
> implementations some have taken 15 years and are still finalising  
> for full commercial use. I would say IMHO that after almost 20  
> years of this approach, perhaps an adjustment needs to be made?
>
> The protocol is complex and could be much simpler. I advocate a  
> simplification of this protocol. I believe it is time that we  
> perhaps tested what has really been happening. This will pay off in  
> the long run. Ospf-lite is not a forklift upgrade. Multiple  
> instances could run quite happily. In the case of customers  
> connecting to MPLS networks there are multiple instances of OSPF  
> running anyway. Any of these could be ospf-lite. I do agree with  
> your view of EIGRP. However there was wisdom in the area  outlook  
> on the protocol.
>
> A link State protocol should be much simpler to implement. Routing  
> a few hundred thousand routes should not be such an onerous task.  
> Our scalability comes from very old impressions. Are areas ( not  
> including Internet route isolation) really required? Yet they are  
> almost globally employed.
>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Tue, 18 Sep 2007 23:18:16 +0100

I do see your arguments Dave,
 
However, there are State diagrams included which detail exactly how the flooding mechanism works.
 
The implementation is extraodinarily simple. NextHop which exists to provise working ready to go protocol stacks list some of the most major maufacturers as clients. OSPF is clearly not an easy protocol to implement.
 
The removal of DR's removes ALL the Network LSA's. The removal of areas and replacement with an AS structure removes the LSA 3's. The idea of Area summary is easier to put into practise as redistributed routes. There is more control and simpler to implement. Most network implementations require an LSA 3 for each area network, summaries are often ineffective in terms of route count and LSA count without manual manipulation. 
 
Few routers have no Ethernet, and so with respect to the DR, in many networks this is an instant 50% reduction on all connections, p2p included, as the netowrk LSA's are not there to flood. I would say that is a real simplification. Although pruning trees is more interesting to work on sure and more challenging, would it produce such an easy hit. If you have removed it, then there is no need to save on it. Not that I am against pruning trees.
 
However, the main point is; ospf-lite is not trying to save data from the wire. ospf-lite is about simplifying the protocol. The main argument against it is that it will load the network, which often is mostly the opposite. It just sends what it needs to get on with the job. Its deadly effective and does nothing else. This makes it inherently scalable.
 
Thanks for the comments,
 
Matthew R Thomas

From: Dave Katz [mailto:[email-masked]]
Sent: Tue 18/09/2007 21:31
To: Thomas, Matthew R
Cc: [email-masked]
Subject: Re: [OSPF] ospf-lite welcomes comments

--Dave

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 19 Sep 2007 09:52:32 +0200

Matthew,

 > The implementation is extraodinarily simple.
    I think you are missing the basic Dave's point here - for which 
reason vendor with existing OSPF code might want to implement your new 
protocol, however simple it is; and for which reason customer with 
existing network might want to migrate his IGP to your protocol going 
thru HUGE pain of network redesign, however simple is configuration 
afterwards?
    Until you come up with answer on this question (business question, 
if you like) any engineering discussion won't make sense.

    There exists only one flavor of OSPF - the one which can 
interoperate with  rfc2328. Make no mistake - what you are trying to do 
is to design a new IGP. It happen - for good or for worse - to resemble 
OSPF more than BGP or RIP but that's about it.
    I agree with you that OSPF carries burden of historic treats which 
better be avoided in design of a new protocol and current IGPs are far 
from being perfect. But the reality is - world doesn't need new IGP at 
this moment.
    You will be better off if you try to create COMPLETELY new IGP which 
RADICALLY solves problems of current standardized IGPs. That may have at 
least remote chance to be used in the future.

    Thanks,

Anton

---

From: "Matthew Thomas" <[email-masked]>
Date: Wed, 19 Sep 2007 10:02:51 +0100

Thanks for your comments Anton,

This is a powerful extra tool in an implementors box. It is complimentary to 
the current heavy version. There is zero network implementation redesign. 
OSPF V2 has tight restrictions and ospf-lite has practically no 
restrictions. Standard run in parallel, cut over etc procedures. For the 
network implementor; (Even with existing stub area design), simply change 
each area to ospf-lite, redist all routes other than external type 5's 
(fully supported) which are your internet routes. (lite version of stub 
area). It is very straightforward. Later simplify out most of your areas and 
remove them. You could then re-assign some design staff. Its not for here to 
go into, so appologies to the board, but the savings are staggering.

I appreciate your comments,

Matthew R Thomas

----- Original Message ----- 
From: "Anton Smirnov" <[email-masked]>
To: "Thomas, Matthew R" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 19, 2007 8:52 AM
Subject: Re: [OSPF] ospf-lite welcomes comments

>    I think you are missing the basic Dave's point here - for which reason 
> vendor with existing OSPF code might want to implement your new protocol, 
> however simple it is; and for which reason customer with existing network 
> might want to migrate his IGP to your protocol going thru HUGE pain of 
> network redesign, however simple is configuration afterwards?
>    Until you come up with answer on this question (business question, if 
> you like) any engineering discussion won't make sense.
>
>    There exists only one flavor of OSPF - the one which can interoperate 
> with  rfc2328. Make no mistake - what you are trying to do is to design a 
> new IGP. It happen - for good or for worse - to resemble OSPF more than 
> BGP or RIP but that's about it.
>>  The implementation is extraodinarily simple. NextHop which exists to 
>> provise working ready to go protocol stacks list some of the most major 
>> maufacturers as clients. OSPF is clearly not an easy protocol to 
>> implement.
>>  The removal of DR's removes ALL the Network LSA's. The removal of areas 
>> and replacement with an AS structure removes the LSA 3's. The idea of 
>> Area summary is easier to put into practise as redistributed routes. 
>> There is more control and simpler to implement. Most network 
>> implementations require an LSA 3 for each area network, summaries are 
>> often ineffective in terms of route count and LSA count without manual 
>> manipulation. Few routers have no Ethernet, and so with respect to the 
>> DR, in many networks this is an instant 50% reduction on all connections, 
>> p2p included, as the netowrk LSA's are not there to flood. I would say 
>> that is a real simplification. Although pruning trees is more interesting 
>> to work on sure and more challenging, would it produce such an easy hit. 
>> If you have removed it, then there is no need to save on it. Not that I 
>> am against pruning trees.
>>  However, the main point is; ospf-lite is not trying to save data from 
>> the wire. ospf-lite is about simplifying the protocol. The main argument 
>> against it is that it will load the network, which often is mostly the 
>> opposite. It just sends what it needs to get on with the job. Its deadly 
>> effective and does nothing else. This makes it inherently scalable.
>>  Thanks for the comments,
>>  Matthew R Thomas
>>
>> significantly simplify the implementation, and such implementation will 
>> continue to be hard.  Furthermore, a *good* implementation of even a 
>> simpler protocol is quite hard.  For example, the OSPF spec considers 
>> "flood the LSA" to be an atomic operation;  the expectation is that 
>> you'll queue up a copy of it on every interface and on the retransmission 
>> lists of every neighbor.  This is one of the reasons that accidentally 
>> dumping full routing into OSPF causes such heartburn in many 
>> implementations;  a massive origination of LSAs multiplied by large 
>> numbers of neighbors causes a tremendous state explosion.  Fixing this is 
>> not easy and requires intuitive knowledge of the protocol.
>>
>> The fact that most people can't manage to do good implementations of OSPF 
>> means that they should go out of business.  There's a reason that there 
>> are only two dominant implementations.  Frankly, I like the fact that 
>> it's not trivial, but then I'm a capitalist and a stockholder.  A 
>> slightly easier version of the protocol is not going to change this 
>> significantly.
>>
>> Aside from all this, I see two fundamental issues in doing anything like 
>> this.  First is the implementation issue;  having a "simpler" OSPF 
>> accomplishes nothing unless the old OSPF can be made to disappear (so 
>> that you don't have to implement it.)  Otherwise you have only succeeded 
>> in making every implementor's life even more difficult, and I guarantee 
>> that nobody will want anything to do with it.  Even if it were the best 
>> thing since sliced bread, you then have to figure out how to transition a 
>> network to it.
>>
>> 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.
>>
>> 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
>>
>>
>>
>>> Most vendors have had trouble stabilising their code. I was implementing 
>>> the odd proteon, 6611's and Wellfleet /Bay /Nortel back in 1996 and it 
>>> was odd. Some companies today exist soley to help vendors achieve 
>>> stabilty. In terms of Open Source some implementations some have taken 
>>> 15 years and are still finalising for full commercial use. I would say 
>>> IMHO that after almost 20 years of this approach, perhaps an adjustment 
>>> needs to be made?
>>>
>>> simplification of this protocol. I believe it is time that we perhaps 
>>> tested what has really been happening. This will pay off in the long 
>>> run. Ospf-lite is not a forklift upgrade. Multiple instances could run 
>>> quite happily. In the case of customers connecting to MPLS networks 
>>> there are multiple instances of OSPF running anyway. Any of these could 
>>> be ospf-lite. I do agree with your view of EIGRP. However there was 
>>> wisdom in the area  outlook on the protocol.
>>>
>>> A link State protocol should be much simpler to implement. Routing a few 
>>> hundred thousand routes should not be such an onerous task. Our 
>>> scalability comes from very old impressions. Are areas ( not including 
>>> Internet route isolation) really required? Yet they are almost globally 
>>> employed.
>>>

---

From: Dave Katz <[email-masked]>
Date: Wed, 19 Sep 2007 13:16:01 -0700

On Sep 19, 2007, at 2:02 AM, Matthew Thomas wrote:

>
> This is a powerful extra tool in an implementors box.

Protocol implementor, or network implementor?

 From the network implementor (operations) side, there is essentially  
nothing to gain in using this spec.

 From the protocol implementor side, it's just one more thing to code  
at significant additional cost, for no gain at all (since the other  
version is not going away.)

Why is this a "powerful extra tool?"  Powerful in what way, and to whom?

> Its not for here to go into, so appologies to the board, but the  
> savings are staggering.

Savings in what?  And "staggering?"  This is just a bit too much.

Taking a peek at our source, we've got something in the tens of  
thousands of lines of code in our OSPF implementation.  DR election  
is about 1% of that, as is area handling.  Generation and processing  
of the to-be-discarded LSA types is in the noise.

Let me be brutally frank here.  I happen to know what is required to  
implement a complete, robust, scalable implementation of OSPF, having  
done so.  The *vast* majority of the code has nothing at all to do  
with the optimizations proposed, and as such, from an implementation  
standpoint, the proposal is not significantly easier to implement if  
you plan on building one that is commercially viable.

What you're proposing has absolutely no hope of moving forward.  It  
would create needless work for implementors, provide no gain for  
operators, and is incompatible with the vast deployed base.

I'm assuming that this is part of your doctoral thesis, for which I  
wish you the best.  However, you need to understand that in the real  
world this spec is fundamentally impractical, because the benefits  
are minimal and the costs are huge.  If the industry is to consider a  
new IGP (which for all practical purposes this is), it would need to  
be fundamentally better than what we have now, in one or more  
dimensions (functionality, scalability, cost of deployment, etc.)

Like I've said, as an implementor I have derided some of the more  
baroque aspects of OSPF since it was first proposed.  I also  
appreciate the idea that something can be made easier to implement.   
However, implementation cost (within reason) is *not* a significant  
factor in the market success of a protocol.  The money paid to me to  
build this has been dwarfed by many orders of magnitude by the money  
earned by its existence.  And the money earned by existence has been  
dwarfed by the money spent deploying it.

I would suggest that we drop this matter in the context of the IETF,  
as I seriously doubt that there is any significant interest in going  
forward with it.

--Dave

---

From: "Matthew Thomas" <[email-masked]>
Date: Wed, 19 Sep 2007 23:22:54 +0100

OK,

I am talking network implementor. The cost of the design phase for an OSPF 
rollout are quite staggering. In the late 90's I know of one client that 
spent in the order of 100's of millions of dollars for a few thousand low 
end (2600's as it happens) routers. The industry bill for the complexity of 
supporting this protocol IS staggering.

The costs to the end customer (network implementor) of such a heavy protocol 
is very high. there are design teams, and consultants all managing a 
protocol that you describe as baroque. Vendors should be able to offer a 
choice to their customers. ospf-lite needs to be looked at, and put into 
context. IGP's need to be greatly simplified in order to scale. The problem 
here is not network traffic as we have seen (we ARE in the noise), it is 
trying to support an overly complex protocol. 20 years is long enough for a 
strip and rebuild.

A vendor will probably implement this first, to provide choice to the 
market. In the end the market will decide. Lets focus instead if you are 
interested on the technical details. Trying to look into the future about 
other peoples perceptions doesnt get us very far, and is ineffective. I have 
worked with ospf since 1995, and only been in Academia since 2006 so this is 
nothing to do with my PhD thesis but thanks for asking anyway.

Matthew R Thomas

----- Original Message ----- 
From: "Dave Katz" <[email-masked]>
To: "Matthew Thomas" <[email-masked]>
Cc: "Anton Smirnov" <[email-masked]>; "Thomas, Matthew R" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, September 19, 2007 9:16 PM
Subject: Re: [OSPF] ospf-lite welcomes comments

> From the protocol implementor side, it's just one more thing to code  at 
> significant additional cost, for no gain at all (since the other  version 
> is not going away.)
>
>> Its not for here to go into, so appologies to the board, but the  savings 
>> are staggering.
>
> Taking a peek at our source, we've got something in the tens of  thousands 
> of lines of code in our OSPF implementation.  DR election  is about 1% of 
> that, as is area handling.  Generation and processing  of the 
> to-be-discarded LSA types is in the noise.
>
> done so.  The *vast* majority of the code has nothing at all to do  with 
> the optimizations proposed, and as such, from an implementation 
> standpoint, the proposal is not significantly easier to implement if  you 
> plan on building one that is commercially viable.
>
> What you're proposing has absolutely no hope of moving forward.  It  would 
> create needless work for implementors, provide no gain for  operators, and 
> is incompatible with the vast deployed base.
>
> I'm assuming that this is part of your doctoral thesis, for which I  wish 
> you the best.  However, you need to understand that in the real  world 
> this spec is fundamentally impractical, because the benefits  are minimal 
> and the costs are huge.  If the industry is to consider a  new IGP (which 
> for all practical purposes this is), it would need to  be fundamentally 
> better than what we have now, in one or more  dimensions (functionality, 
> scalability, cost of deployment, etc.)
>
> Like I've said, as an implementor I have derided some of the more  baroque 
> aspects of OSPF since it was first proposed.  I also  appreciate the idea 
> that something can be made easier to implement.   However, implementation 
> cost (within reason) is *not* a significant  factor in the market success 
> of a protocol.  The money paid to me to  build this has been dwarfed by 
> many orders of magnitude by the money  earned by its existence.  And the 
> money earned by existence has been  dwarfed by the money spent deploying 
> it.
>
> I would suggest that we drop this matter in the context of the IETF,  as I 
> seriously doubt that there is any significant interest in going  forward 
> with it.
>
> --Dave
>
>
>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Thu, 20 Sep 2007 00:33:22 +0100

Dave,

Just for reference; there is in fact significant interest from both reasonably sized Telco operators, and Router Vendors. The draft is long and takes a little time to absorb.
 
Matthew R Thomas

From: Matthew Thomas [mailto:[email-masked]]
Sent: Wed 19/09/2007 23:22
To: Dave Katz
Cc: Anton Smirnov; Thomas, Matthew R; [email-masked]
Subject: Re: [OSPF] ospf-lite welcomes comments

OK,

Matthew R Thomas

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Sep 2007 20:36:24 -0400

In message <000701c7fb0b$a0516790$fb271752@DGYSNN2J>
> trying to support an overly complex protocol. 20 years is long enough for a 

If you are talking about the cost charged for OSPF, that's an issue
with a particular router vendor that charges for software and charges
excessively for LS IGPs, BGP, and anything an ISP might need.  That's
also no where near 100s of millions of dollars.

Having had a hand in the OSPF rollout at the NSFNET backbone (and a
major hand in the BGP4 rollout) in the mid-90s I can say from first
hand experiend that the engineering cost are quite minimal.  We had
about 1,000 routers including CPE, under 200 not including CPE.

Many of the smarter providers, going back to early 90s, machine
generate router configurations so the field tech with a new edge
router (or any other) just installs a minimal config and downloads the
machine generated config that was prepared when the service order went
through the system.  Config flexibility rather than simplicity is
greatly appreciated by the programmer (often perl hacks in the early
days) that generates the configs (that was me for the NSFNET core -
the configs for regional routers and CPE were quite simple).

> nothing to do with my PhD thesis but thanks for asking anyway.

Except that people like Dave have been talking to engineering people
at IP providers for over a decade and have quite a bit of clue about
something like this.

IMHO - This is a waste of time.  The WG should not pursue it.

Curtis

---

From: "Matthew Thomas" <[email-masked]>
Date: Thu, 20 Sep 2007 01:43:22 +0100

I worked on a project that charged 250+ million dollars for 2000 routers, 
albeit with some PC installs and leased lines etc. I do not want to rise to 
this. I have spoken in depth with over 2000 (its hard to keep count) ospf 
network  implementation engineers over 10 years  but my experience is 
irrelevant. It isnt as good as yours, but it is firm. An engineers 
experience is not neccessarily of relevance to a solution. Lets stick to 
technical or take this direct.

Thanks for your comments,

Matthew R Thomas

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Sep 2007 22:34:47 -0400

Hi Matthew,
I've been involved with OSPF for some time myself and I don't see a  
requirement for this light weight version. If a Telco operator wants  
to limit themselves to a single area and only P2P/P2MP links then  
they'd certainly be able to do so with most implementations (at least  
the last 2 that I've worked on). Furthermore, I can't see any serious  
router vendor wanting to support another variant of OSPF - especially  
one that is close to being a proper subset but deviates in subtle  
ways. I can't see this simplifying anybody's OSPF code base.

Thanks,
Acee
P.S. I wish I'd have been around to design that OSPF network and  
configure those 2000 OSPF routers - I'd have done it for a paltry $25  
million. That would leave plenty to spare to buy/physically install  
the routers and the rest of the equipment :^)

On Sep 19, 2007, at 8:43 PM, Matthew Thomas wrote:

> I worked on a project that charged 250+ million dollars for 2000  
> routers, albeit with some PC installs and leased lines etc. I do  
> not want to rise to this. I have spoken in depth with over 2000  
> (its hard to keep count) ospf network  implementation engineers  
> over 10 years  but my experience is irrelevant. It isnt as good as  
> yours, but it is firm. An engineers experience is not neccessarily  
> of relevance to a solution. Lets stick to technical or take this  
> direct.
>
> ----- Original Message ----- From: "Curtis Villamizar"  
> <[email-masked]>

---

From: "Matthew Thomas" <[email-masked]>
Date: Thu, 20 Sep 2007 08:51:33 +0100

Sure Acee, it was in 1996. I sugested something lke that but it wasnt going 
to happen :o)

Matthew

----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: "Matthew Thomas" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 20, 2007 3:34 AM
Subject: Re: [OSPF] ospf-lite welcomes comments

> requirement for this light weight version. If a Telco operator wants  to 
> limit themselves to a single area and only P2P/P2MP links then  they'd 
> certainly be able to do so with most implementations (at least  the last 2 
> that I've worked on). Furthermore, I can't see any serious  router vendor 
> wanting to support another variant of OSPF - especially  one that is close 
> to being a proper subset but deviates in subtle  ways. I can't see this 
> simplifying anybody's OSPF code base.
>
> Thanks,
> Acee
> million. That would leave plenty to spare to buy/physically install  the 
> routers and the rest of the equipment :^)
>
>> routers, albeit with some PC installs and leased lines etc. I do  not 
>> want to rise to this. I have spoken in depth with over 2000  (its hard to 
>> keep count) ospf network  implementation engineers  over 10 years  but my 
>> experience is irrelevant. It isnt as good as  yours, but it is firm. An 
>> engineers experience is not neccessarily  of relevance to a solution. 
>> Lets stick to technical or take this  direct.
>>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Thu, 20 Sep 2007 09:18:06 +0100

Acee,
 
What is interesting is your response to the price. It was the smae as mine. High  prices are not as uncommon within the Enterprise market. How many routers does a national high street bank have, or a national store, or Gas station etc etc. In my experience in many cases the numbers of these networks dwarf the ISP's. Large clouds. 1000 routers will NOT give you a national (high street) bank that is for sure.
 
The cost of rolling these networks really is enourmous, and they yield a huge percentage of the vendors income. Of course these networks are not represented here on the Forum so often.
 
For a vendor to be able to offer a simplified version (even though a teclco network implementor) would be a powerful business winner. So the vendor would win for sure. Have you read the document.
 
Matthew R Thomas

From: Matthew Thomas [mailto:[email-masked]]
Sent: Thu 20/09/2007 08:51
To: Acee Lindem
Cc: [email-masked]
Subject: Re: [OSPF] ospf-lite welcomes comments

Matthew

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Thu, 20 Sep 2007 12:41:04 +0100

I am closing (if that is possible :o) this particular thread. We are in discussions with router vendors and end clients and this thread has lost its technical clarity and sight.
 
Thank you for your opinions Dave, Curtis et all.  See you in Vancouver of course.

Matthew R Thomas

From: Thomas, Matthew R [mailto:[email-masked]]
Sent: Thu 20/09/2007 09:18
To: [email-masked]
Subject: FW: [OSPF] ospf-lite welcomes comments

Acee,

Matthew R Thomas

Matthew

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Sep 2007 23:43:47 -0400

In message <002d01c7fb5b$109340b0$fb271752@DGYSNN2J>
> Sure Acee, it was in 1996. I sugested something lke that but it wasnt going 

The total backbone NSFNET funding was $15M/year.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Sep 2007 00:04:23 -0400

In message <[email-masked]>
"Thomas, Matthew R" writes:
>  
> Dave,
>  
> Just for reference; there is in fact significant interest from both
> reasonably sized Telco operators, and Router Vendors. The draft is
> long and takes a little time to absorb.
>  
> Matthew R Thomas

Let them speak for themselves.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Sep 2007 00:35:09 -0400

In message <[email-masked]>
"Thomas, Matthew R" writes:
>  
> Acee,
>  
> What is interesting is your response to the price. It was the smae as
> mine. High prices are not as uncommon within the Enterprise
> market. How many routers does a national high street bank have, or a
> national store, or Gas station etc etc. In my experience in many cases
> the numbers of these networks dwarf the ISP's. Large clouds. 1000
> routers will NOT give you a national (high street) bank that is for
> sure.
>  
> The cost of rolling these networks really is enourmous, and they yield
> a huge percentage of the vendors income. Of course these networks are
> not represented here on the Forum so often.
>  
> For a vendor to be able to offer a simplified version (even though a
> teclco network implementor) would be a powerful business winner. So
> the vendor would win for sure. Have you read the document.
>  
> Matthew R Thomas

ISPs dont' count the CPE router, evn if it is managed by the provider.
The normal demarc is the circuit to the customer so the aggregation
(or access, or whatever, terminology varies among providers) router is
the closest to the edge to be counted.

In 1996, when ANS was reporting about 200 routers they were not
counting routers beyond the core and regional.  For example, they has
deployed over 1 million modems for the AOL service, in banks of 500 to
5,000 depending on the size of the metro, each with at least two pizza
box routers (for redundancy).

Most ISPs seem to have on the order of 1,000 routers in the IGP.  The
CPE is mostly single homed and therefore is generally handled with a
static route (or routes in rare cases) and a default route on the CPE.
They are each just a VLAN number on an one interface of a aggregation
(access) router or in older metros, maybe a VC on ATM or FR or a T1
channel on a SONET link.

Ask an MSO or DSL provider how many subscribers they have some time.
If they are willing to say, the number for most is way into the
millions.  That is most like counting enterprise routers, couning
every little box that you could buy at the office supply place or
could find next to the TVs and clothes washers in the big box store.

This is so off topic it is ridiculous.  Appologies for my
participation in this thread.

Curtis

    The amount of clue in the network is growing linearly at best.
    The network is growing exponentially.
    Therefore the clue density is shrinking exponentially.
	      -- source - who knows? - Randy Bush maybe - early 1990s