On Tue, 7 Aug 2001, Robert Raszuk wrote:
Vijay,
Ok so you say that increasing the number of features in any implementation can cause critical bugs - hey I agree 100%.
But what is the solution - do the freez in code and do not implement any new features and enhancements ? All vendors (at least those significant :) get a lot of new feature requests some of them touching much much deeper then the mpls-vpn implementation into the elements of bgp, ospf, isis etc .... Should all vendors just say - forget it we are not doing it as it can introduce bugs ???
If not why you are particluary so flaming mpls-vpns and not other features requested which when done wrong can cause hell lot of more issues into the networks ?
R.
If we agree that the "value proposition" in the Power Point slides leverages the installed infrastructure of a given ISP, then it becomes necessary to make sure that all the features in a given image work well enough to support ALL the services that the ISP offers, be they BGP MPLS VPN, L2 MPLS VPN, standard IP routing, IP QoS routing/queuing, what have you. I think the point is that people might want to tread lightly when rolling out a completely new service that may get you into a trade-off situation where you decide whether you run the image (or HW since so much is done in HW now) that supports service A and D or the one that supports service B and C. Hard to pretend to either gun-shy IT managers or telco overlords that those kind of networks are going to have the reliability that people are used to with telephone networks any time soon. The more knobs that are turned; the more that can break. If you get to the point of keeping a "special router" in a/every POP to terminate VPN customers vs. all others, you've blown the "value proposition", big time. It's not a no-brainer no matter what people may be whispering in our ears. Tony
Vijay Gill wrote:
--On Tuesday, August 07, 2001 08:29 -0700 Robert Raszuk <raszuk@cisco.com> wrote:
Vijay,
I am not defending IOS bugs or any particular implementation - I am defending the architecture.
R.
Robert,
the point here being that software is a complex beast that is fairly hard to get right and often has very subtle failure modes. The interactions between various small bugs in subsystems often result in catastrophic failures when they interact as a part of a much larger whole. The architecture is fine, and in fact like all Powered By PowerPoint (tm) architectures, looks good in labs and papers, runs extremely well on slide projectors and will probably run fine in the real world for a while too.
However, there are real life operations folks who have to run these things on large networks with lots of interactions among various components that are hard to duplicate in a lab setting (else we'd have bug free code on FCS).
There was no singling out of IOS or any other implementation, I was just pointing out two fairly recent failure modes in code paths that has been exercised for years and deal with a "well known" RIB and adjacency maintenance issues. It is entirely possible that there are no bugs in current implementations; I just won't bet my day job on that possibility.
Besides for those individuals who have problems with maintaining a sinlge RIB with IGP routes I would higly advise a caution in deploying an mpls-vpn service or even touching the routers :).
That was uncalled for. We do have problems maintaining a single RIB with IGP routes sometimes, mostly they are due to buggy implementations.
/vijay