Slashdot Mirror
IETF Debates On: MPLS Is Bad
A reader writes "MPLS, or Multi-protocol Label Switching, seems to be a popular choice for router vendors nowadays until two AT&T researchers argue it differently. They "say MPLS create serious network management challenges for Internet backbone providers." "Even more dire are their warnings about potential security and privacy problems for companies that deploy MPLS-based VPNs." This issue will be discussed on an IETF meeting held this week in London. More details here ." Related to the IETF [?] , this submission came in: The Internet Engineering Task Force (IETF)
is now meeting in London for
IETF-51.
You can watch
multicast sessions. "
Maybe I haven't gotten over the 8 hour jet-lag yet like I thought I had...
s/pronounced/proclaimed/g
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
Agreed
QoS allows time critcal application traffic to get priority over non-priority traffic.
QoS really only kicks in when the network traffic exceeds the bandwith allocated, so if the traffic is perfectly matched to the bandwidth QoS really dosen't play a role. If your traffic suddenly out grows, or bursts above the allocated bandwidth QoS becomes a factor and critcal traffic will be get a preferance over non-critical traffic.
The best example of this type of priority traffic (other than the previous exapmles) is SNA over IP
Technology is only a vehicle. People are the ones that drive it.
QOS is not only about "Resource Optimization" but also about "Traffic Parameters". MPLS does explicit routing: CR-LDP and TE-RSVP- both have supporters and otherwise- by deployinge either of them it performs well on both accounts. I think that from TE point of view more than a technological advantage it offers an excellent business case.. think in terms of Fixed and Operational costs. :)
Anyways prioritization is the name of the game. Also known as might is right. From the Jungle to the OS the rule is valid so whats wrong with MPLS screwing this or that: should my video streams (Hidden Dragon Crouching Tiger) compete with your icons?
You will agree that MPLS performs "atleast" what other relevant technologies have achieved in past: IBM'S Aris, or Toshiba's Packet Switching etc. It does appear to be a the logical next step in the evolution of packet forwarding. It is a standard independant of manufacturers. Even it is biased, you cant argue with the sense of buyers. Market forces ultimately decide the technology S-Curve.
It has problems Scalability , Security, etc but alteast the things are moving in the right direction.
For purely administrative reasons it falls short of offering an end-to-end QOS . So the relevance of argument, by some, that it maynot become the "internet" technology is perhaps valid.
Voltaire: God is dead.
God: Voltaire is dead!
As a user of a 300+ site MPLS VPN ompressions are generally very good. Apart from a few bugs where MPLS tags are ocasionally lost.
The alternative of a 300 site IPSEC Tunnel VPN with full mesh connectivity would be a lot harder to manage.
slashnik
Main Entry: pronounce
...
Pronunciation: pr&-'naun(t)s
Function: verb
Inflected Form(s): pronounced; pronouncing
transitive senses
1 : to declare officially or ceremoniously <the minister pronounced them husband and wife>
2 : to declare authoritatively or as an opinion <doctors pronounced him fit to resume duties>
If MPLS is that bad, I guess I'm happy to be in Duluth!
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
My point was that MPLS VPNs *re-use* existing routing protocols such as BGP, OSPF and RIP, rather than re-inventing the wheel. MPLS doesn't do encryption so it doesn't need encryption keys. The customer site on a VPN doesn't need to know it's in a VPN, and needs no special configuration - it just peers with the provider edge router, as with any other router.
There are some people who have done dynamic protocols for VPN node discovery for both IPSec and MPLS VPNs, but the problem is somewhat simpler in the MPLS case.
Please read a bit about MPLS VPNs, then this will become much clearer - a good site to start at is www.mplsrc.com.
I'm from minneapolis, and it's not a bad town at all. If you think it's bad, you've probably never even been... oh forget it.
MPLS was great before we had ASIC's that were doing full next hop lookups at OC-48 and OC-192 speeds... Now with routers actually forwarding at those line rates, the need for MPLS has dwindled... But... I believe that the ability to provide the amount of traffic engineering and VPN's afforded with MPLS is a viable solution that is here to stay for a good while. Back when I was working on a 38 POP network with multiple private peering points MPLS was going to provide a lot of the benefits of ATM on our POS network with out the fscking cell tax... These days things are a little different in the office, but I still am waiting for a good excuse to fire the MPLS up on the damn M-40's and have a good time...
No, I said that MPLS takes care of packet classification automatically, and that is the hardest part of QoS.
The hardest parts of QoS are "backpressure" and "headblocking" - surprise, surprise there is no solution yet.
The rest is limited to DiffServ functionality which does not need any MPLS.
If there is vulnerability, you can be sure the haxor kids will take advantage of it. My starting page (http://www.thehitlers.cjb.net) for example seemed to be down yesterday.
Well the good part of all these news is that they at least KNOW there is a problems and are trying to solve them.
The World's Best Music!
2.5 > 2 - True
2.5 >= 3 - False
Hmm... so... whaddaya think?
BTW, yes, I am nitpicking here, but this was too funny not to respond to. :)
Ross Callon (then DEC) is (I am happy to see) still activly working on the concepts we built into CATNIP (IPv7 draft).
really amazing...
If you want the very early history, see RFC1475 (TP/IX) and 1476 (RAP, a RIP upgrade for sending labels back upstream).
The thing I really find fascinating is large scale debates on issues identified then: yes, IMHO you want to distribute labels with multiple methods (RAP-etc being only one), yes, you use them to identify flows and tunnels.
My disappointment is that I tried very hard to get FCID/tag/label switching built into the IPng, and my proposal wasn't selected.
Oh well. It is really amazing to watch. (Did I say that already? ;-)
Robert Ullmann
Sure MPLS can do lots of nice things, but at what cost? Complexity adds a new layer that is partly overlapping with normal IP layer functionalities, eating resources and causing extra management work. The much advertised QoS (apart from straight forward load-balancing) requires rules in LSRs that can differentiate between all the various quality levels of flows. IP headers already have 8 bit TOS/TC fields to carry QoS preference info, and src/dst addresses identify individual flows uniquely enough. IPv6 address aggregation (sometimes also CIDR) allows you to identiufy traffic from/to entire providers or corporate entities with one entry.
As the experts in the nwfusion article (http://www.nwfusion.com/news/2001/0806mpls.html) state, MPLS based VPNs are not inherently secure because there's no encryption. But if our random provider or end user organization is not afraid of these minor issues (complexity, poor scalability, management difficulties and costs, ability to do the same with just IP, lack of security, need to have MPLS widely implemented, dependence on fewer vendors) then I guess they can go for it.
MPLS is NOT just a circuit switching technology - unless you are doing MPLS traffic engineering, the normal IP routing updates from your IGP drive the propagation of labels via LDP (Label Distribution Protocol). If you follow the labels, they are more like a tree than a circuit in many topologies. If you use TE, you can lay down 'circuits' but these are optional - you don't have to do TE on every part of your network, and mostly this is only done in core networks.
People are using MPLS for VPNs and other applications, not just traffic engineering. It's also a great way of turning ATM switches into IP routers, which is something that the IP people should be enjoying (ATM was going to kill IP, now IP is taking over ATM)...
As for the hardware issue - this is irrelevant, MPLS is not being used to speed up obsolete hardware, it's being used on some of the fastest routers around (Juniper M160 and Cisco 12416), for its usefulness, not just for its speed.
This is a "Good Thing" for several reasons. For one thing, it's quicker, as IP addresses are variable length, whereas MPLS labels are fixed. It also allows a lot more granular traffic control and shaping. Also, you can encapsulate just about anything inside MPLS, not just IP. And you can do QoS, CoS, VPN and lots of other stuff.
This is a VERY simplified version of what MPLS is and does. For more information try the following:
I operate my own backbone and I have never heard about this MPLS.
The goal should be whatever lets providers deliver services that customers will pay for, IMO. In any case, MPLS does fit into the 'dumb core' model quite well, just like DiffServ - core MPLS routers don't have a lot of state, and just swap labels most of the time. This is a lot closer to the 'dumb network' architecture than the traditional PSTN approach where every switch has a great deal of complexity.
rather the problem is the one of network management. When networks only had one or two connections out of the AS and less then ten data streams management from CLI was possible. As the networks grow management is becoming increasingly complex. In essence the problem is developing tools that can easily perform traffic management and provide a good measure of automation in it. From what I have seen MPLS is a good technology it just needs more robust management tools built around it. Even a protocol such as OSPF can become a bear to manage in a large network with frequent changes. Part of the security problems pointed out are that in order to ease the workload on both the network engineer and the router things become more generic, which produces security holes. Basically it all boils down to having a good management system, doing it from a CLI, which we are forced to do now, sucks big donkey balls.
I may be a pool man, but I am f@#*&ng Jon Bon Jovi's pool man!!!
I can't bring myself to watch it, it sucks so much. Major League Soccer was a sports league destined to fail in the U.S.
What exactly does this shit do?
Geekizoid: The Small Shiny Things Network ©
Gobble a dick!
Yes some people say it is not "bad" it just needs a bit of work because it is hard to use, hard to implement correctly (with out help or a lot of experience), and generally misunderstood. That's a complex way of saying "bad" in my mind. It doesn't, however, mean that it can't be touched up to make it "good". Specifically, removing some of the unused options is generally believed to be one solution that will help make it more easily implemented and used (a view I generally agree with).
How many times did you read the RFCs before understanding them. And if you re-read them again, I bet you'd learn something new (again).
/Wes -- I was there too
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
/magnus - was there.
You make a lot of inflammatory remarks. (You must work for a company that doesn't have an MPLS product and is getting clobbered. ;-))
Try and get your facts straight. For one thing, QoS is all about determining "who gets screwed the least and who gets screwed the most". Unless you have some network media that can magically create bandwidth it is all about sharing what is available and prioritizing traffic. Any QoS mechanism works that way. The only way to prevent(?) it is to use some form of Admission Control, but then doesn't the user that tries to get some bandwidth and can't get any get really "screwed"?
What are you talking about vendors' implementations don't work??? Our company uses MPLS and we love it. As for the rest of your drivel, about MPLS being the X.25 of the 90's hey maybe if you weren't such an "Anonymous Coward" we could discuss it.
See topic.
old enough to set the table, old enough to pass the meat
but my site's routers or switches or something were down for like two days and I couldn't get my e-mail or anything. It really sucked.
You know, when you troll like that you're supposed to sign the posts... something like "CmdrTaco", "Hemos", or perhaps "Anne Tomlinson".
Tarsnap: Online backups for the truly paranoid
MPLS is not for everyone, and is mainly for private IP networks at present - however, it is very useful in specific applications:
:) ).
1. To provide VPNs (with the same security as the vast number of Frame Relay and ATM networks out there) - the key difference from IPSec is that (a) they run over an IP network owned by a single provider and (b) constrained routing updates are used to limit the visibility of a VPN site. You can't even DoS an MPLS VPN site unless you are in the VPN, whereas IPSec's IKE has some well-known issues with IKE being DoSable. Anyone who is spending large amounts of money on a VPN between sites is best advised to run it on a private network - MPLS VPNs (RFC 2547) are much more scalable than FR/ATM, and the Layer 2 MPLS VPNs have their own limitations (although they are easier to set up for the enterprise). IPSec is much less scalable than the non-encryption VPNs, since gateways have limits on number of IPSec tunnels and on throughput. Whether you use IPSec, FR, ATM or MPLS L3 or L2 VPNs, there is a *lot* of configuration to be done - that's why any large provider is using a provisioning tool such as Orchestream (www.orchestream.com, my employer - yes, I am probably biased
2. Traffic engineering - this means balancing traffic across the various paths in your network - e.g. if you have a northern US and southern US path, and the latter is longer, IP routing will always go via the north, even if the southern US path is underloaded. MPLS TE allows providers to balance some of the traffic onto the southern path, providing better performance and delaying network upgrades. TE can also be used to lay down bandwidth-reserved pipes. However, it's important to note that TE is only one application of MPLS, and other applications do NOT require these 'pipes' (LSPs, label switched paths) - e.g. MPLS VPNs work quite happily without LSPs.
3. Easy upgrade to IPv6 - just migrate your core routers' control software (routing protocols etc) to IPv6, and make them act as MPLS label switches. Only edge switches need IPv6 hardware. However, within a few years most routers will have good IPv6 hardware (Cisco will do hardware acceleration for IPv6 by end of next year).
4. Provisioning of optical light paths - there is a lot of work on GMPLS (Generic MPLS), which will allow SONET cross-connect switches and optical-layer switches to be provisioned with a light path in the same way as MPLS Traffic Engineering.
There is a faction within the IETF that is against anything that adds easier centralised provisioning to IP networks - this is understandable, but IP network providers want to deliver higher-value services today, such as VPNs, and to get more utilisation out of their networks using MPLS Traffic Engineering. There are a lot of these providers at the IETF, but many others are busy running their networks.
IPSec and MPLS both have their place, and can be combined (IPSec over MPLS end to end, or just for the last mile connection).
Finally, for the 'this will destroy the Internet' crowd - having well-managed IP networks using MPLS only serves to make the providers more profitable. Many MPLS networks carry both Internet and private IP traffic, meaning that the everyday traffic can be subsidised by business traffic, just like the way the airlines use business class and flexible ticket pricing to subsidise non-business travellers.
I cant locate the actual finding/argument by the AT&T researchers but i think the issue would be that once the labels are in the LSP the upper layers have no way of provisioning security(sniffing, redirection issues).In this regard (CR)LDP perhaps provides better security than (TE)RSVP. By controlling the data at entry and exit, security is improved but still it is not ideal.
Voltaire: God is dead.
God: Voltaire is dead!
Load balancing: Regular IP networks do Equal Cost MultiPath (ECMP). The only time MPLS helps in load balancing is you can "fake out" the underlying topology into thinking it's ECMP. Usually, you're primary motivation for doing this is because you want to get good "resource utilization" from all your links. This is a horrible, horrible idea. Granted, it looks great on paper and in your mind, but fails in the real world. Why? These types of paths usually have really different path characteristics. Also, queueing theory tells you it's almost always better to have "one big pipe vs. many smaller pipes equalling the big pipe".
o VPN: This is BY FAR the dumbest use of MPLS there is. Why? Because it forces all routers along the path to participate in a LSP for the VPN. Why is that a bad idea? Because it's more state the backbone needs to manage. More data strucures to go wrong. More bugs to work out. How useful is it if the thing crashes once a week? And you've totally lost sight of the goal: to provide a secure, private network between two disconnected places. Just how does a packet passing methodology some how improve that? Why not a little box that spits out IPsec packets into the public internet and the other side decrypts them? That's all that matters. Not that "my packets followed a certain path with these parameters".
Prioritization: Nope. You've TOTALLY missed network engineering. If you're prioritizing traffic, you've already screwed the pooch. Why? Because Offered Load exceeds Available Capacity. You're just picking and choosing who's getting screwed. When you make sure that Available Capacity exceeds Offered Load amazing things happen. The whole need for prioritizing and QoS VANISHES. And raw bits are getting cheaper by the day, so there's no excuse.
As for someones comment that MPLS is not Circuit Switching, you've got it totally wrong. It's 100% circuit switch. My god, you push packets into a LSP and they pop out at the end. Sound anything like what a point to point circuit does? Or a PVC? And you're right, it's not used to speed up packets per second anymore. But that was the entire genesis of the protocols: Fixed size LSP lookups are far easier to do that Longest Prefix Match (LPM) for IP's. But it's not anymore, which obviates the whole "speed" issue.
Many people would do good to read a few Markov Chain books, Queueing theory, Graph Theory, and Network Flow books. There's real science behind this, and MPLS does nothing to address any of these points. It's another protocol on top of everything else that needs to be managed and debugged.
You optimize a network for four primary metrics: Latency, Jitter, Packet Loss, and Bandwidth. The first three have minimum bounds: speed of light determines the lower bound for latency, when jitter reaches the microsecond range, who cares, and it's hard to beat 0% packet loss. And bandwidth has a bound to: if it's enough bandwidth for your application, and you can use it all the time, it's harder to get more than that. So, it's possible to have "perfect bandwidth", and MPLS does very little to address any of these. A pure IP network can nail all of these parameters and do it much, MUCH more simply. And as we all know, the simpler, the less things to break. It's just that easy.
Point 2: No one liked ATM for IP because it was just dumb, and a hassel. And let's not forget the cell tax. MPLS is just ATM with variable sized frames. Sure, there's some differences, but fundamentally that's what it is.
Point 3: Really? I don't seem to think so. (take this as a hint. Did you use the internet today? You ran across my networks. Use slashdot? Again. You've run across my networks. All of these things you claim are so great? Not in my networks. I've got a long list as to why.)
Point 4: Great handwave on the issue.
Fast network restoration? Oh my. Tell you what, when you build a network that can burst sink 2 gigs from a single customer in a 4 hour period, I'll come back and chat with you. Otherwise, you can have your academic opinion on the matter and I'll simply say that there is a strong, STRONG, reason why most networks never deployed MPLS and those that did have regretted it.
I can't remember the main URL, but since my FOLK project uses it, I've a link from the FOLK pages.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Like several people have already pointed out, you have pretty much missed the point of MPLS. Its pretty easy to throw a MPLS shim header in front of an IP packet, and it makes the job of packet classification a hell of a lot easier (for a taste of what packet classification is like w/o MPLS, or just for some good reading, check out http://citeseer.nj.nec.com/feldmann00tradeoffs.htm l). What you choose to do with that classification really doesnt matter.
I think you discount the QoS benefits too quickly- IMO it wont be long before backbone providers will be charging differently based on different QoS levels ("for $xxx, we can guarantee that 90% of your packets will make it through our network..."). QoS is one of the hottest topics right now, and MPLS takes care of the hardest part automatically.
"The defense of freedom requires the advance of freedom" - George W Bush
MPLS is not ISO layer >= 3 but it is a "layer 2.5" technology.
Dude, " >= 3" is the same as " > 2"; and "2.5 > 2" also. You are nitpicking here.
QoS: For when you don't want to kill MP3s, but still want people to be able to read their e-mail. Great for college campuses. After all, media sharing is like a gas - it fills to expand whatever bandwidth you give it.
SIG: HUP
Just because they all love St. Paul doesn't mean they can bash MPLS that much! Oh, wait. They don't mean Minneapolis, do they. Nevermind.
That green slime had it coming.
MPLS totally sucks. It's the X.25 of the new millenia, just as ATM was the X.25 of the 90's. Why? It's a CIRCUIT SWITCH methodology on top of a PACKET SWITCHING network. Dumb! It's another thing to manage and break from a network engineering point of view. That, and most vendors implementations don't work worth a damn today. There's a few reason it came to be: The IP CIDR lookup problem used to be hard. It's not any more. You can buy off the shelf silicon that does 100M+ lookups with a 256K entrys per chip. This is multi-gigabit packets per second. Music and NetLogic make these chips. And there's proprietery algorithums that do similar speeds. Compare this to when the idea first came out: Doing variable length lookups effeciently were impossible and non-deterministic. Replace that with a fixed size label, and lookup and forwarding speeds went through the roof. This was designed when CPU's were the primary switchers. This is like using a Doom graphics engine compared to a modern OpenGL GeForce3 hardware accelerated engine. Good idea at the time, but the problem that limited you before just don't exist anymore! Oh, and it was largely a Cisco push to kill IPsilion, which had a similar circuit switching methodology. Cisco came out with Tag Switching, and pushed that through which has largely become the MPLS "standards". And don't let ANYONE tell you it's for traffic engineering. What a crock of crap. Yea, you can get a bit of finer control, but you have no idea what price you pay untill your knee deep in it. There's a heck of a lot of power in a IGP/BGP simplistic backbone, it just takes proper network engineering. And QoS... Same deal- load of crap. Here's what QoS really means: Your network is overloaded, and you get to choose who you screw the least, and who gets screwed the most. Fact: No customer pays to be screwed! Everyone wants good network service! So build your network appropriatly, and leave all this crap out of the network. The easiest thing to debug is the fluff you leave out. Little bit of math, little bit of reason, this will get you much farther than MPLS ever will.
OK, we're not perfect. But Minneapolis isn't THAT bad.
-Styopa
MPLS doesn't have much to do with packet classification for QoS - you can easily encode the result of a classification decision today in IPv4, by marking the 3 bit IP Precedence (or the 6 bit DiffServ codepoint) in the TOS byte. So an edge router looks at (say) source and dest IP address, and source and dest ports, and marks this as a single byte, so that other routers can avoid unnecessary processing and memory references.
In IPv6 you can encode the result of classifications on a per-flow basis (e.g. a VoIP call, rather than a class which is for all VoIP traffic) - this is what the Flow Label (16 bits) does, though it's unclear how much this will be used since it's dependent on per-flow RSVP being deployed.
MPLS does support using 3 bits (the EXPerimental bits) in the label to mark class of service values, just like IP Precedence - most MPLS edge routers automatically copy the IP Precedence into these bits. It can also let you reserve bandwidth etc for MPLS Traffic Engineered paths through the network, which can be a good way of guaranteeing QoS through the MPLS network. However, this has little to do with classification, which normally happens in the pure IP domain, closer to the edge of the network.
Actually, I was trying to troll my troll, but I guess he's not around to post his usual Olsen Twins reply [to anything I say]. Slashdot doesn't have any of my old comments online any more with his comments attached. Hey buddy, you awake?
My Webcomic: Asylum on 5th Street
The concept behind QoS is that some data streams depend not only on getting data, but getting it in a timely manner (voice, video, real-time nuclear control protocols). Other data streams don't care about how long it takes to deliver, just so the data comes through (ftp, mail, news).
In a general store-and-forward system (like every router & switch I've ever seen), every packet is treated equally. Meaning that the ftp/mail/news packet can get through and make my voice/video packet "late" and therefore unusable.
Quality of Service is all about asking the network if it can provide a certain bandwidth with a certain latency. (QoS as releated to connection contracts is a different matter, which is better termed Traffic Policing.) The network decides if it can provide this to me, and sets up routing tables to handle the connection. The routers now see my new voice/video packet coming in and let it jump the queue ahead of the ftp/web/news packet, because it now understands that the voice/video is worthless unless it gets there on time.
QoS, the FedEx of the Internet.
U.S. Postal Serivce, the standard "who cares when it gets there" delivery method.
That's an odd pronunciation...
--
"Karma can only be portioned out by the cosmos." - Homer Simpson [1F10]
Now, let's say that VPN configuration was as complex as Internet routing. Why develop MPLS when all you you want is a dynamic update of VPN configuration information? Why do all the routers in between the VPN endpoints need to do something different? And, as I indicated, you still have the (dynamic) key distribution problem, unless you send plaintext data outside your network (shudder).
Does anyone else think the folks foaming at the mouth about keeping the core of the network dumb are ultimately a bit silly? Next they'll be saying we should lobotomize our network and system administrators because the end-users will know enough to keep everything running.
The goal should be a cooperative, smart core, smart edge network.
It must be 3:45 over there! Go to sleep, man!
A little haiku:
Minneapolis,
A city nearby St. Paul,
Sucks in the winter.
IKE, for instance (the key exchange mechanism used by the IPsec security protocol) has also been pronounced "bad" and is going to be replaced or modified.
I gaurantee when you get 2300 people (the current conference attendance) together, they'll disagree on many a topic. The good news is that the (frequenly lively) debates are certainly fun to participate in, hence the reason I came.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
For end-to-end Quality of Traffic, MPLS struggles against the administrative barriers: nailing SLAs among approx 70,000 ISPS. Also the cost would be prohibitive!
Voltaire: God is dead.
God: Voltaire is dead!
I'll just address the VPN issue, there are plenty of others I could comment on...
All VPN packets are labelled twice - once to get them from site to site, and once to get them from PE router to PE router. Only the second (outermost) label is visible to core (P) label switch routers. Hence there is absolutely no LSP state in the core relating to VPNs. Similarly, the core LSRs don't have any per-VPN routing state, since this is kept only in the PE routers.
By all means, criticise MPLS, but please get your facts right.
See RFC 2917 for an "informational" RFC that seems (to me, at least) to be a superior technology. I'll quote the abstract inline:
The carrier operates the physical equipment that implements the virtual routers. The customers retain control of the virtual router as long as they keep paying their bills. VPN routes don't waft into the core like they do in RFC 2547, and the virtual routers are perfectly free to encrypt traffic over the LSP if the customer is willing to pay for it being done that way.
Can someone please explain why this 'request for comments' has attracted so little interest?
jhw
Routing protocols such as RIP and OSPF are used by enterprises over VPNs so that each router or IPSec gateway has routes to all other routers/gateways. In IPSec VPNs, you may have to configure this manually - some people use GRE tunnels instead of IPSec SAs purely so they can run a routing protocol to avoid this. Installing all of this from a central file is just returning to the days before dynamic routing protocols (i.e. pre-ARPANET).
MPLS VPNs are based on running the enterprise's routing protocol throughout the VPN, so there is no need to manually configure static routes everywhere (which is what your posting describes). Actually MPLS VPNs encapsulate the routing updates across the core, so that core routers never see the full VPN routing tables, but the effect is the same.
Well, it's a little late to be announcing the IETF meeting if anyone is actually interested (although I doubt the percentage of Slashdot readership that is actually interested (versus the percentage that thinks they might be) is too terribly high...), but fortunately the good multicast event hasn't been missed.
If you're at all interested in the goings-on of the IETF and would like to get a feel for the overall issues considered "important", watch the Plenary session tonight (I think it's at 1830 UTC). It is generally interesting, and guaranteed to have at least a little bit of bickering. ;-)
all your routing problems are belong to us BSD or not BSD, that's the REAL question
".Sig Stealer" was here