Experts call MPLS bad for 'Net http://www.nwfusion.com/news/2001/0806mpls.html Intersting read. This should start a nice long thread :-) -Hank
On Tue, 7 Aug 2001, Hank Nussbacher wrote:
Experts call MPLS bad for 'Net
I think its pretty well known that multiple routing tables, ala 2547-bis, is not scalable. Apparently the author was fed the story and doesn't have a clear understanding of the protocols of MPLS. To say MPLS is bad and write a story about 2547-bis is a bit short sited. No mention of martini or any other vendors besides the two exemplifies this even more. andy
I agree that the article sorts of wanders a bit, but seems to try and focus on the RFC2547 style of L3VPNs. While it seems clear that the author does not have a firm grasp of the topic at hand, do you honestly look for that in mass media? (I refer you to most publications your typical "upper management" reads, if so). The remarks about RFC2547 is certainly salient. Most people are trying to figure out how to deal with BGP routing - why multiply and obfuscate the problem unnecessarily? Often I find myself in a position where I fight to avoid implementing every trade-rag product/technology du-jour on our network that well-meaning executives read about. Particularly ones that seem to be unmanageable (don't go into debugging) for even your smarter-than-average operator. MPLS is falling into the same traps that ATM did. Remember those heated discussions of how IP was going to be made obsolete because everyone was going to be running ATM to everywhere? As I remember, MPLS was originally done as a performance enhancement - controlling MPLS wound up with the side-effect of being able to manage bandwidth. The telephone execs that control large portions of the Internet seem hell-bent on re-implementing what they know and are familiar with (circuit switching). Ultimately it fails, because it is a flawed model for data communications. We did not, however, throw out ATM altogether because the Internet did not become a cross-stitch of ATM SVCs - we do, however, use it where applicable. The article fails miserably in that it appears to condemn MPLS along with the L3VPN model proposed under RFC2547 (and its successor). I believe that RFC2547 and its ilk will ultimately collapse under it's own lumbering weight - however I do remain a fan of MPLS when used appropriately. In the meantime it remains an irksome fact of life that I have to continue to "explain" to people that L3VPNs (a la 2547) are a bad idea to people that don't understand packet switching. Too bad, I would've liked to have used this article as part of that ammunition. To date, my best ammunition has been vendor's "seminars" on how to implement L3VPNs -- when they spend four hours giving "a brief overview" of it, even the most clueless have to have concerns about the operational aspects. - Tom On Tue, 7 Aug 2001, Andy Walden wrote:
On Tue, 7 Aug 2001, Hank Nussbacher wrote:
Experts call MPLS bad for 'Net
I think its pretty well known that multiple routing tables, ala 2547-bis, is not scalable. Apparently the author was fed the story and doesn't have a clear understanding of the protocols of MPLS. To say MPLS is bad and write a story about 2547-bis is a bit short sited. No mention of martini or any other vendors besides the two exemplifies this even more.
andy
-- -- Thomas P. Brisco tbrisco@globix.net Senior Network Architect 212-625-7073 Globix Corp. Q: A priest, a rabbi, and RFC2547bis are on an airplane. During the flight, the plane encounters a storm and crashes. How many people die? A: Only two. Everybody knows that RFC2547bis will never fly.
On Tue, Aug 07, 2001 at 05:11:41AM -0500, Andy Walden wrote:
I think its pretty well known that multiple routing tables, ala 2547-bis, is not scalable.
[..] I think it's pretty well known that the point you mention is FUD. Besides, it's not really intended to be 'multiple tables' with multiple instances of routing processes.. it's an indexed table run by the same routing process. Take a look at the mpls@uu.net archives for a rather exhaustive and exhausting discussion of this very subject, or provide facts as to what specifically doesn't scale. -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only.""
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
I think it's pretty well known that the point you mention is FUD. Besides, it's not really intended to be 'multiple tables' with multiple instances of routing processes.. it's an indexed table run by the same routing process.
Logic says that not seeing the routes at all, a la layer-2 tunnels, is going to scale *better* then having your routers deal with them at all. Less routes/resources=greater scalability. andy
On Tue, Aug 07, 2001 at 09:03:53AM -0500, Andy Walden wrote:
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
I think it's pretty well known that the point you mention is FUD. Besides, it's not really intended to be 'multiple tables' with multiple instances of routing processes.. it's an indexed table run by the same routing process.
Logic says that not seeing the routes at all, a la layer-2 tunnels, is going to scale *better* then having your routers deal with them at all.
I really wanted to reply... "Logic says you need to check the facts before posting such nonsense." .. but that would be a flame. Let's try this instead: In an RFC2547(bis) MPLS-VPN, the edge doesn't neccessarily need to see all the routes at all. All the PE does need to know is enough for the two CE's to communicate with each other. This can be a static route, this can be a summary route. So, if you get another, say 3000 routes for 1000 customers, this is really going to be that much of a scaling problem? In fact, if your customers build BGP sessions etc between their CE's, the routes carried by the PE's are very skinny. So, you're going to try to tell us next that n^2 tunnels scale better and are less of an operational nightmare at scale than the connectivity provided inside of an MPLS-VPN? Have you ever actually used the code yourself? -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
I really wanted to reply... "Logic says you need to check the facts before posting such nonsense." .. but that would be a flame. Let's try this instead:
So good of you to show restraint. Your awfully assuming that no one else has as much MPLS knowledge and experience as you. Try to maintain the conversation without "asserting yourself" at the beginning of each response.
In an RFC2547(bis) MPLS-VPN, the edge doesn't neccessarily need to see all the routes at all. All the PE does need to know is enough for the two CE's to communicate with each other. This can be a static route, this can be a summary route. So, if you get another, say 3000 routes for 1000 customers, this is really going to be that much of a scaling problem? In fact, if your customers build BGP sessions etc between their CE's, the routes carried by the PE's are very skinny.
"Doesn't neccessarily"..."if"... Scaling is looking ahead and considering how it could grow. Your going to have to do *something* on each PE, I think signalling a tunnel and being done with it is better.
So, you're going to try to tell us next that n^2 tunnels scale better and are less of an operational nightmare at scale than the connectivity provided inside of an MPLS-VPN?
I think so. I'm sure either will work in its element. Obviously you don't agree, we can leave it at that.
Have you ever actually used the code yourself?
"the code"? Assuming you mean have I setup L3 VPNs, yes, but you can refer to my first comment. andy
On Tue, Aug 07, 2001 at 10:18:30AM -0500, Andy Walden wrote:
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
I really wanted to reply... "Logic says you need to check the facts before posting such nonsense." .. but that would be a flame. Let's try this instead:
So good of you to show restraint. Your awfully assuming that no one else has as much MPLS knowledge and experience as you. Try to maintain the conversation without "asserting yourself" at the beginning of each response.
There is such a thing as sarcasm. Geez. ;)
Scaling is looking ahead and considering how it could grow. Your going to have to do *something* on each PE, I think signalling a tunnel and being done with it is better.
If all you're building is a small amount of point to point VPNs, sure.. At a large number of VPNs and complex VPN topologies (better than p2p), I think there are some very distinct advantages.
So, you're going to try to tell us next that n^2 tunnels scale better and are less of an operational nightmare at scale than the connectivity provided inside of an MPLS-VPN?
I think so. I'm sure either will work in its element. Obviously you don't agree, we can leave it at that.
I think the point I'm trying to make is this. People keep saying that RFC2547(bis) implementations won't scale, when the funny part is that they really don't become terribly useful unless used at scale. Many of the advantages aren't realized at small scale. And, I'd rather have a thousand prefixes than a thousand tunnels across my network. But, that's also with the premise that I'm working on building a very large, complex customer topology VPN infrastructure from the outset. But, the point you're hitting on is absolutely appropriate. MPLS-VPNs aren't a solution for everything, and neither are tunnels. It very much depends on your customer's needs, on your topology etc. Global bashing of either is inappropriate. And at very large SP scale, I think the overhead and inflexibility of tunnels isn't acceptable. If that's all I want, I might just as well buy tons of FR/ATM. Tunnels will always happen. It's something any customer can do on their own. In my opinion, if what they're looking for is a large scale managed VPN, the options of topology & traffic management in MPLS-VPNs outweigh those of tunnels.
Have you ever actually used the code yourself?
"the code"? Assuming you mean have I setup L3 VPNs, yes, but you can refer to my first comment.
Please don't be ridiculous. The point was that it is incomprehensible to me how some of the statements are made about MPLS-VPNs if you've actually touched the stuff and worked with it. All too many people comment on this stuff with mere book knowledge. That was the point, and no more. Cheers, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
But, the point you're hitting on is absolutely appropriate. MPLS-VPNs aren't a solution for everything, and neither are tunnels. It very much depends on your customer's needs, on your topology etc. Global bashing of either is inappropriate.
I think what we can take away from this at this point is its still too early out of the gate to completely write one or the other off. And if history is any teacher, there will be installed bases of each and a few standing L3 vs L2 VPN papers that get referenced when someone asks which is better. Much like OSPF-ISIS exists these days. andy
Take a look at the mpls@uu.net archives for a rather exhaustive and exhausting discussion of this very subject, or provide facts as to what specifically doesn't scale.
to paraphrase vijay, if dealing with one rib is a major discussion in the operator and ietf communities, how many thousands of them do you think a prudent operator wants to deal with in 2547? did you notice all those extra *e routers with 2547? do you wonder why router vendors push 2547? randy
On Tue, Aug 07, 2001 at 03:14:02PM +0100, Randy Bush wrote:
Take a look at the mpls@uu.net archives for a rather exhaustive and exhausting discussion of this very subject, or provide facts as to what specifically doesn't scale.
to paraphrase vijay, if dealing with one rib is a major discussion in the operator and ietf communities, how many thousands of them do you think a prudent operator wants to deal with in 2547?
I think you're blowing this completely out of proportion like it has happened on mpls@uu.net before. A PE carries only the routes needed at a specific PE depending on the VPNs present at a specific PE. The routes aren't kept in a seperate rib, what happens is that a meta rib is created which indexes all rib entries based on their origin. Sounds a lot more complicated but it is in essence something like this: 128.10.0.1.0 129.10.0.1.0 129.10.0.2.0 130.10.0.1.0 130.10.0.2.0 130.10.0.3.0 They're called VPNv4 routes, consisting of IPv4 routes and the index (with 128, 129, 130 being the index.. ). It's still just one rib. Provided all those RD's are present at the same PE. So, how many thousands of suitable MPLS VPN customers do you have for this to amount to much? Again, there has been an exhaustive discussion of this on mpls@uu.net many moons ago, and for you specifically to rehash this issue in another forum again is rather curious to me. You couldn't win the argument in IETF MPLS, and now it's being dragged to NANOG?
did you notice all those extra *e routers with 2547? do you wonder why router vendors push 2547?
If the shoe fits, why not? MPLS VPNs solve a very specific set of problems. If you don't like because it doesn't fit your operational model, don't use it. But this sort of generic bashing and FUD leads nowhere. -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, Aug 07, 2001 at 03:34:05PM +0100, Randy Bush wrote:
A PE carries only the routes needed at a specific PE depending on the VPNs present at a specific PE.
and five years out, what percentage of my O(10-^6) vpn customers will have a branch in each of (chicago|nyc|sf|.*)?
Randy, and how should I know? ;-).. I'm a) lacking a functional crystal ball (a magic 8 ball is my only ball shaped engineering tool) and b) they'll presumably be still your customers and not mine! ;-) Seriously, what point are you trying to make? There are several ways to interpret the statement. Thanks, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
The point is very simple - virtual circuit routing does not scale. That was beaten to death in ATM vs IP discussions years ago. Do we need to repeat that again? http://www.kotovnik.com/~avg/pluris/ip_vs_atm/ --vadim On Tue, 7 Aug 2001, Christian Kuhtz wrote:
On Tue, Aug 07, 2001 at 03:34:05PM +0100, Randy Bush wrote:
A PE carries only the routes needed at a specific PE depending on the VPNs present at a specific PE.
and five years out, what percentage of my O(10-^6) vpn customers will have a branch in each of (chicago|nyc|sf|.*)?
Randy,
and how should I know? ;-).. I'm a) lacking a functional crystal ball (a magic 8 ball is my only ball shaped engineering tool) and b) they'll presumably be still your customers and not mine! ;-)
Seriously, what point are you trying to make? There are several ways to interpret the statement.
Thanks, Chris
-- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, Aug 07, 2001 at 06:25:50PM -0700, Vadim Antonov wrote:
The point is very simple - virtual circuit routing does not scale. That was beaten to death in ATM vs IP discussions years ago.
What does this have to do with VC routing?! And tunnels are probably closer to VC routing than 2547(bis) style VPNs. What is your point? -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, Aug 07, 2001 at 11:29:02PM -0400, Christian Kuhtz wrote:
On Tue, Aug 07, 2001 at 06:25:50PM -0700, Vadim Antonov wrote:
The point is very simple - virtual circuit routing does not scale. That was beaten to death in ATM vs IP discussions years ago.
What does this have to do with VC routing?! And tunnels are probably closer to VC routing than 2547(bis) style VPNs. What is your point?
Or, to put it differently.. there are a handful of fundamental assertions of your paper that I very much disagree with and consider flawed. The discussion of resource reservation is one of them. The sheer blanket statement mentality of your doc is inappropriate, IMHO, and doesn't do the problem space justice. -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
Or, to put it differently.. there are a handful of fundamental assertions of your paper that I very much disagree with and consider flawed. The discussion of resource reservation is one of them. The sheer blanket statement mentality of your doc is inappropriate, IMHO, and doesn't do the problem space justice.
I'm known for making strong statements, you are right. However, so far I've heard no convincing argument against these positions; and I tried to solicit opinions by offering the opinions in question for the public review. Frankly, i was disappointed by the "let's wait and see which one works" attitude. As Randy was kind to point out, that attitude already gave us a slew of DOA networking technologies, to the tune of billions wasted. I would really like to enjoy a reasoned discussion, resulting not in relativistic opinions, but in real understanding of consequences of different design decisions. And, yes, I'm a strong adherent of K.I.S.S. principle, particularly where poorly understood and tightly coupled systems are involved. (As for the question "why didn't you go to IETF to express your opinion there" - my current line of work does not touch on IETF activities; and, besides, in my opinion, IETF ceased any useful design activity years ago, and became a forum for spreading marketectures). --vadim
Anything which routes on both source and destination addresses is a form of circuit switching in disguise. At least from the point of view of routing information needed. Thus MPLS is no different from ATM in regard to computational complexity of algorithms involved. (Note that there's such thing as statically-configured PVCs, of MPLS used for manually-configured TE; those mereley augment physical network topology, from the point of view of dynamic routing level). Tunnels do _not_ inject any routing information into backbone. As long as they aren't created and destroyed "on demand" (with corresponding updates to network's routing info) they're safe. --vadim On Tue, 7 Aug 2001, Christian Kuhtz wrote:
On Tue, Aug 07, 2001 at 06:25:50PM -0700, Vadim Antonov wrote:
The point is very simple - virtual circuit routing does not scale. That was beaten to death in ATM vs IP discussions years ago.
What does this have to do with VC routing?! And tunnels are probably closer to VC routing than 2547(bis) style VPNs. What is your point?
-- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
Randy, 5 years from now you will see routers from multiple vedors allowing you to store & process orders of mangnitute of more routes. As a matter of fact if you have so much routes - you as an opertator should only be happy - as it means you are selling your new service and erning more money. 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 :). R.
Randy Bush wrote:
A PE carries only the routes needed at a specific PE depending on the VPNs present at a specific PE.
and five years out, what percentage of my O(10-^6) vpn customers will have a branch in each of (chicago|nyc|sf|.*)?
randy
--On Tuesday, August 07, 2001 08:11 -0700 Robert Raszuk <raszuk@cisco.com> wrote:
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 :).
It isn't quite the individuals who are having problems maintaining a single RIB with IGP routes, it looks like the software is having trouble keeping its sanity. Seeing that it took ~ 12 months to track down some iBGP withdrawl bugs and a single fence post error in an AS path sanity check took down a significant portion of the internet, I suggest perhaps one must first put ones own house in order before going out and throwing stones at others. thanks /vijay
Vijay, I am not defending IOS bugs or any particular implementation - I am defending the architecture. R.
Vijay Gill wrote:
--On Tuesday, August 07, 2001 08:11 -0700 Robert Raszuk <raszuk@cisco.com> wrote:
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 :).
It isn't quite the individuals who are having problems maintaining a single RIB with IGP routes, it looks like the software is having trouble keeping its sanity. Seeing that it took ~ 12 months to track down some iBGP withdrawl bugs and a single fence post error in an AS path sanity check took down a significant portion of the internet, I suggest perhaps one must first put ones own house in order before going out and throwing stones at others.
thanks
/vijay
--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
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.
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
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
On Tue, Aug 07, 2001 at 11:49:38AM -0400, Vijay Gill wrote: [..]
That was uncalled for. We do have problems maintaining a single RIB with IGP routes sometimes, mostly they are due to buggy implementations.
Vijay, your notion of complexity is well taken in the context of operational reality. The question is a matter of trade off in my opinion. Sure, every once in a while my phone doesn't give me a dial tone or just fastbusies.. Does that mean I will start praying to my favorite deity/deities for good weather and no wind so that I can start using smoke signals again? Any new technology has glitches, which are typically resolved over time. That's an operational reality, too. That's why there are precautions in place to prevent meltdowns, which start with testing and safety break-aways of your network to prevent meltdowns.. it's either time to come up with them or not participate in the risk. That's a choice you make, but not a thumbs up or thumbs down on the value or effectiveness of a given technology or architecture. They certainly influence each other to a degree, but they're not the only thing that matters. Risk is manageable. Cheers, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
--On Tuesday, August 07, 2001 12:03 -0400 Christian Kuhtz <ck@arch.bellsouth.net> wrote:
Any new technology has glitches, which are typically resolved over time. That's an operational reality, too. That's why there are precautions in place to prevent meltdowns, which start with testing and safety break-aways of your network to prevent meltdowns.. it's either time to come up with them or not participate in the risk. That's a choice you make, but not a thumbs up or thumbs down on the value or effectiveness of a given technology or architecture. They certainly influence each
This is a pretty good summing up but I have always fallen on the conservative side of the the continuing operational cost/benefit tradeoff. Some folks will feel that this approach to mpls vpn yields an acceptable number, some will not. I strongly encourage the competition to deploy this (tm MO). Maybe it'll be all good, and I'll be eating crow, won't be for the first time. /vijay
On Tue, 7 Aug 2001, Robert Raszuk wrote:
5 years from now you will see routers from multiple vedors allowing you to store & process orders of mangnitute of more routes. As a matter of fact if you have so much routes - you as an opertator should only be happy - as it means you are selling your new service and erning more money.
Funny how nothing changes as years pass... For some obscure reason, these promised "routers able to store & process orders of magnitude of more routes" always seem to be available a year or so _after_ they could save the day. I think the _best_ way for an operator to earn money is called "customer retention". No implementation costs, little operational costs; a cash cow. In my opinion, the best way to keep customers is not to offer new features on a flaky network, but to have network to be truly dependable. It's customer churn (and "make buck quickly" mentality) which kills ISPs. --vadim
On Tue, Aug 07, 2001 at 06:35:12PM -0700, Vadim Antonov wrote: [..]
I think the _best_ way for an operator to earn money is called "customer retention". No implementation costs, little operational costs; a cash cow. In my opinion, the best way to keep customers is not to offer new features on a flaky network, but to have network to be truly dependable. [..]
Ideally, customers will never ask for anything new, nobody will ever invent a better mousetrap, nobody will ever come up with a more efficient way of doing something. I think that's called paradise. This isn't about chasing a reality that doesn't exist. It's about managing the risk of evolving an infrastructure. And it is possible to evolve the network while maintaining stability. Quite frankly, I don't see what this has to do with 2547(bis) architectural viability anymore. -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
On Tue, 7 Aug 2001, Christian Kuhtz wrote:
You couldn't win the argument in IETF MPLS, and now it's being dragged to NANOG?
(....)
I really wanted to reply... "Logic says you need to check the facts before posting such nonsense." .. but that would be a flame.
Life would be much better if grocery stores didn't exist. Men could obtain the power, gratification and recognition they need thru killing something, rathing than sending email. -- Ken Woods kwoods@kens.com "smile, you know it was funny"
Christian,
MPLS VPNs solve a very specific set of problems. If you don't like because it doesn't fit your operational model, don't use it. But this sort of generic bashing and FUD leads nowhere.
That would be a rational position, but it can't be accepted by the folks who have a fairly irrational attitude about the subject. These folks are of firm opinion that they know how things should be done, and moreover, their way of doing things is the one, and *only* one way of doing this. In the absence of any rational arguments (like the case we have at hand), the only thing these folks could use to justify their dogmas is generic bashing and FUD. Yakov.
On Tue, Aug 07, 2001 at 05:33:39PM +0100, Randy Bush wrote:
That would be a rational position, but it can't be accepted by the folks who have a fairly irrational attitude about the subject.
love those ad hominem arguments by the desperate in the defense of clearly non-scalable technology. will ad homina be part of 2547bis?
Nice shot, Randy! ;) If it is so clear, how about engaging in a discussion and providing a rationale and reply to those who say it ain't so? If you can provide solid arguments disproving the arguments of those who think it is scalable, I think it would be very easily put to rest. 2547bis may not be a fit for your vision/problem. However, that's entirely seperate argument from whether or not it is scalable. Cheers, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only."
If it is so clear, how about engaging in a discussion and providing a rationale and reply to those who say it ain't so? If you can provide solid arguments disproving the arguments of those who think it is scalable, I think it would be very easily put to rest.
are you running it on the same routers as your main backbone? is it simpler or (someday please, oh godded) less code? tell your bean counters how scalable it is. and don't give me the bumph about provisioning costs. any transit and/or vpn vendor that is not completely auto-configured knows the deepest, darkest, most horrid, and expensive truth about non- scalability. randy
Randy rants:
If it is so clear, how about engaging in a discussion and providing a rationale and reply to those who say it ain't so? If you can provide solid arguments disproving the arguments of those who think it is scalable, I think it would be very easily put to rest.
are you running it on the same routers as your main backbone? is it simpler or (someday please, oh godded) less code? tell your bean counters how scalable it is.
and don't give me the bumph about provisioning costs. any transit and/or vpn vendor that is not completely auto-configured knows the deepest, darkest, most horrid, and expensive truth about non- scalability.
Ch vs R: 2:0 Randy, still no arguments, -- Arnold
are you running it on the same routers as your main backbone? is it simpler or (someday please, oh godded) less code? tell your bean counters how scalable it is.
and don't give me the bumph about provisioning costs. any transit and/or vpn vendor that is not completely auto-configured knows the deepest, darkest, most horrid, and expensive truth about non- scalability.
Ch vs R: 2:0
Randy, still no arguments,
the depth of your argument is impressive
Is someone running this? pls resond privately, -- name: Arnold Nipper org: nIPper consulting mail: arnold@nipper.de phone: +49 172 2650958, fax: +49 1212 512 364 310
Yakov, that was not nice. If you look at the "opposition" side you'll see quite a lot of people who had to run real backbones; and who have a feeling of impact featurism has on reliability of code. For what it worth, nothing makes you appreciate simplicity and quality as getting dragged out of bed in the middle of the night to fix backbone falling down in flames because of yet anothing interesting glitch caused by the flaky but feature-rich software. My position was always consistent - if you can do something (like VPN) at the edge boxes w/o inroducing complexity into core transport, this is the way to do that. "Intelligent networks" is a _bad_ idea. Also note that in the backbone world, no operator is protected from other's stupid decisions. That's why promoting good practices is a necessity, not just a religious argument. Otherwise wily Randy would heartily advise everyone else to switch to X.25 running on top of ATM :) --vadim On Tue, 7 Aug 2001, Yakov Rekhter wrote:
Christian,
MPLS VPNs solve a very specific set of problems. If you don't like because it doesn't fit your operational model, don't use it. But this sort of generic bashing and FUD leads nowhere.
That would be a rational position, but it can't be accepted by the folks who have a fairly irrational attitude about the subject. These folks are of firm opinion that they know how things should be done, and moreover, their way of doing things is the one, and *only* one way of doing this.
In the absence of any rational arguments (like the case we have at hand), the only thing these folks could use to justify their dogmas is generic bashing and FUD.
Yakov.
If you look at the "opposition" side you'll see quite a lot of people who had to run real backbones; and who have a feeling of impact featurism has on reliability of code. For what it worth, nothing makes you appreciate simplicity and quality as getting dragged out of bed in the middle of the night to fix backbone falling down in flames because of yet anothing interesting glitch caused by the flaky but feature-rich software.
It is all right. Eventually they will get a correlation between their errors and missed earnings. Alex
On Tue, Aug 07, 2001 at 07:00:38PM -0700, Vadim Antonov wrote:
My position was always consistent - if you can do something (like VPN) at the edge boxes w/o inroducing complexity into core transport, this is the way to do that. "Intelligent networks" is a _bad_ idea.
Not entirely.. Keeping the features and misc. cruft on the edges of the network is a good thing. However, as the edge becomes more intelligent, the core has to adapt to service it. This often cannot be done without adding intelligence into the core. This does not mean that the core should be a participant of the newest and greatest feature but should know about the established features in order to optomize overall function. (eg, multicast.. the core knows about it, but makes no decisions other than routing and replicating packets... It does what it is told. All the rest is handled at the edge and at the RP.)
Also note that in the backbone world, no operator is protected from other's stupid decisions. That's why promoting good practices is a necessity, not just a religious argument. Otherwise wily Randy would heartily advise everyone else to switch to X.25 running on top of ATM :)
--vadim
These good practices, of course, have to start at the vendors. This is an area that has been lacking in recent years. (silly defaults, code that gets pushed into production before its ready because of marketing schedules, etc.) -Wayne
On Tue, 7 Aug 2001, Wayne E. Bouchard wrote:
However, as the edge becomes more intelligent, the core has to adapt to service it. This often cannot be done without adding intelligence into the core. This does not mean that the core should be a participant of the newest and greatest feature but should know about the established features in order to optomize overall function. (eg, multicast.. the core knows about it, but makes no decisions other than routing and replicating packets... It does what it is told. All the rest is handled at the edge and at the RP.)
Funny that you choose multicast as an example. I always thought that it is a very rotten idea, and a security nightmare, too. Distributed transparent caching does not require injection of any routing information from customers into the core routing, and is a lot more efficient than multicasting (i.e. you can always think of multicasting as a caching with cache retention time set to nearly zero).
These good practices, of course, have to start at the vendors. This is an area that has been lacking in recent years. (silly defaults, code that gets pushed into production before its ready because of marketing schedules, etc.)
Recent years? :) ROFL :) --vadim
Vadim,
Yakov, that was not nice.
If you look at the "opposition" side you'll see quite a lot of people who had to run real backbones; and who have a feeling of impact featurism has on reliability of code. For what it worth, nothing makes you appreciate simplicity and quality as getting dragged out of bed in the middle of the night to fix backbone falling down in flames because of yet anothing interesting glitch caused by the flaky but feature-rich software.
My position was always consistent - if you can do something (like VPN) at the edge boxes w/o inroducing complexity into core transport, this is the way to do that.
Then to be consistent with your own position, you certainly should agree that 2547 is "the way to do" VPNs, as with 2547 all the VPN-related information is confined to the PEs (where "PE" stands for provider *edge*), and none of the P (core) routers maintain any VPN-related information. Yakov.
On Wed, 8 Aug 2001, Yakov Rekhter wrote:
Then to be consistent with your own position, you certainly should agree that 2547 is "the way to do" VPNs, as with 2547 all the VPN-related information is confined to the PEs (where "PE" stands for provider *edge*), and none of the P (core) routers maintain any VPN-related information.
Ghm. Unless you do not count MPLS labels as routing information, that's it. "All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists." [sic] I particularly liked discussion of using border routers for inter-AS VPN routing. These are precisely the ones which are usually in deep poo-poo in case of any routing instability. "PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router. (Certain procedures for setting up label switched paths in the backbone may not require the presence of the /32 address prefixes.)" I hope i understood that right. Inserting _any_ additional stuff into backbone IGP is pretty much close to suicide. The first rapidly flapping circuit or box will get your backbone crash and burn. How many PE routers are attached to a typical backbone? What is the probability of one of them going banana (or getting a loose cluster LAN connection, or a flap attack from _within_ customer VPN, saturating its processor to the point that it loses backbone IGP timeouts? I.e. all it takes to kill the backbone is one smartass with gated on his workstation - insides of VPNs are not known for stringent filtering of routing information). A good rule for a backbone operator is to have _only_ core routers (not customer access concentrator boxes) to participate in IGP, injecting one prefix each, to hang iBGP mesh off. (As a side note - does anyone do flap damping in IGPs?) That was the reason why i asked Paul and Tony to make a knob to allow preservation of next-hop addresses in border BGP routers in the first place (yep, and to hang off all those tiny AS-es off 1239 :) Handwaving, Yakov. Saying that 2547's VPN routing information is confined to PEs is a case of selective vision. _Interior_ VPN information is hidden, yes, but exterior of VPNs is quite visible. And in the words "this enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router" are hidden all those teeny weeny label information exchanges, which have to happen every time IGP hiccups. Compare that with tunnelled or NAT-based VPNs which do not force backbone boxes to do anything but native IPv4 routing; and, yes, allows them to aggregation, too. And it does not require cross-provider exchange of /32s or any new bugs in BGP engines. What i see is an attempt to drag in new features to solve a problem which was adequately solved years ago in ways which do not contribute to core network instability. 2547 is a neat idea, but falls short of criteria of being safe and absolutely necessary to deliver VPN service. Sometimes older ways are simply better. --vadim
Vadim, While trying to parse your mail I am really not sure what are you trying to smash here. Is it 2547 or is it MPLS LDP based LSPs ? Please notice that while they may be seen as coupled today that is not the necessity. Could you clarify ? Also I find it interesting that for some providers those "teeny weeny label information exchanges" in the core make it much more stable and solid as full mesh of ipv4 ibgp there becomes no longer a requiremnt. R. PS. Yes mutlicast RPF breaks when you disable full ipv4 ibgp but you can add a subset of this full table via Multicast BGP and still save on router's RIB/FIB sizes significantly.
Vadim Antonov wrote:
On Wed, 8 Aug 2001, Yakov Rekhter wrote:
Then to be consistent with your own position, you certainly should agree that 2547 is "the way to do" VPNs, as with 2547 all the VPN-related information is confined to the PEs (where "PE" stands for provider *edge*), and none of the P (core) routers maintain any VPN-related information.
Ghm. Unless you do not count MPLS labels as routing information, that's it.
"All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists." [sic]
I particularly liked discussion of using border routers for inter-AS VPN routing. These are precisely the ones which are usually in deep poo-poo in case of any routing instability.
"PE routers (and ASBRs which redistribute VPN-IPv4 addresses) need to insert /32 address prefixes for themselves into the IGP routing tables of the backbone. This enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router. (Certain procedures for setting up label switched paths in the backbone may not require the presence of the /32 address prefixes.)"
I hope i understood that right. Inserting _any_ additional stuff into backbone IGP is pretty much close to suicide. The first rapidly flapping circuit or box will get your backbone crash and burn. How many PE routers are attached to a typical backbone? What is the probability of one of them going banana (or getting a loose cluster LAN connection, or a flap attack from _within_ customer VPN, saturating its processor to the point that it loses backbone IGP timeouts? I.e. all it takes to kill the backbone is one smartass with gated on his workstation - insides of VPNs are not known for stringent filtering of routing information).
A good rule for a backbone operator is to have _only_ core routers (not customer access concentrator boxes) to participate in IGP, injecting one prefix each, to hang iBGP mesh off. (As a side note - does anyone do flap damping in IGPs?) That was the reason why i asked Paul and Tony to make a knob to allow preservation of next-hop addresses in border BGP routers in the first place (yep, and to hang off all those tiny AS-es off 1239 :)
Handwaving, Yakov. Saying that 2547's VPN routing information is confined to PEs is a case of selective vision. _Interior_ VPN information is hidden, yes, but exterior of VPNs is quite visible. And in the words "this enables MPLS, at each node in the backbone network, to assign a label corresponding to the route to each PE router" are hidden all those teeny weeny label information exchanges, which have to happen every time IGP hiccups.
Compare that with tunnelled or NAT-based VPNs which do not force backbone boxes to do anything but native IPv4 routing; and, yes, allows them to aggregation, too. And it does not require cross-provider exchange of /32s or any new bugs in BGP engines.
What i see is an attempt to drag in new features to solve a problem which was adequately solved years ago in ways which do not contribute to core network instability. 2547 is a neat idea, but falls short of criteria of being safe and absolutely necessary to deliver VPN service. Sometimes older ways are simply better.
--vadim
On Tue, 7 Aug 2001, Andy Walden wrote:
Experts call MPLS bad for 'Net
I think its pretty well known that multiple routing tables, ala 2547-bis, is not scalable. Apparently the author was fed the story and doesn't have
Why not? Each MPLS VPN will likely not add very many routes. Having just setup a few MPLS VPNs, I think the only hard parts were finding clear docs/examples on Cisco's web site and working around IOS bugs encountered while turning up some of the VPN circuits. We're using BGP to distribute static and connected routes between our PE's and the CE's all have static routes, mostly just defaults. Once you've done one, it's really not any harder than turning up a regular IP customer. It's certainly easier than dealing with the traditional VPN support in some CPE hardware. I don't buy the security concern that we'll misconfigure VPNs and leak routes and traffic from one to another. I do think MPLS VPNs will give customers a false sense of security though. As others have mentioned, it's not really virtual, and it's not private. Their packets still ride our network without encryption. It's segregated by our routers, but not private. Unfortunately, a few network providers started the ball rolling by offering this type of service, and now some customers expect it, even if their original provider went out of business. So we've been rushed into figuring out and deploying it. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Randy and Vijay are completely correct - 2547 is nothing but bad news. The comments about MPLS VPN security seem a little out of place - they could easily apply to Frame relay, for that matter. And nothing is stopping folks from encrypting anything they want. The story is quite good, though - the vendors are pushing 2547, some in the service provider community are listening, and they will end up regreting it. L2 MPLS VPNs, like CCC and Martini will one day provide a very nice alternative to Frame and ATM, but there is neither a market for, nor a scalable, safe way to deliver 2547. - Dan
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Hank Nussbacher Sent: Tuesday, August 07, 2001 1:37 AM To: nanog@merit.edu Subject: MPLS VPNs or not?
Experts call MPLS bad for 'Net
http://www.nwfusion.com/news/2001/0806mpls.html
Intersting read. This should start a nice long thread :-)
-Hank
On Tue, Aug 07, 2001 at 08:33:52AM -0400, Daniel Golding wrote:
Randy and Vijay are completely correct - 2547 is nothing but bad news.
Right.
The comments about MPLS VPN security seem a little out of place - they could easily apply to Frame relay, for that matter. And nothing is stopping folks from encrypting anything they want. The story is quite good, though - the vendors are pushing 2547, some in the service provider community are listening, and they will end up regreting it.
Why?
L2 MPLS VPNs, like CCC and Martini will one day provide a very nice alternative to Frame and ATM, but there is neither a market for, nor a scalable, safe way to deliver 2547.
Really. Based on what sort of market research and backup material? -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only.""
participants (16)
-
alex＠yuriev.com -
Andy Walden -
Christian Kuhtz -
Daniel Golding -
Hank Nussbacher -
jlewis＠lewis.org -
Ken Woods -
Nipper, Arnold -
Randy Bush -
Robert Raszuk -
Thomas P. Brisco -
Tony Tauber -
Vadim Antonov -
Vijay Gill -
Wayne E. Bouchard -
Yakov Rekhter