On 8/7/2001 at 15:50:00 -0400, Fletcher E Kittredge said:
1980 X.25
Still in use worldwide, 21 years later.
1984 OSI
Usable parts adapted for IP use.
1991 ATM
Running DSL circuits everywhere (though not for much longer, at this rate.) Not to mention voice and video, and even some IP backbones.
2000 MPLS
Yep. You missed Frame Relay, PPP, SONET, a bunch of other protocols, and making any sort of point... unless you're trying to say some protocols do better than others, which is a given. -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet
Stepping back one notch from this discussion, there's a basic architectural point here. As Milo Medin is fond of saying, "with enough thrust anything will fly" and sometimes they get enough thrust to semi-permanently embed themselves into the networking infrastructure. ATM is a case in point. By about 1993, it was clearly losing steam, but so much money had been put into it, that it was already part of the infrastructure, and once in, it wasn't leaving soon. (Side note, the marginal cost of using an inferior technology that is already installed is often lower than the cost of installing the better technology). MPLS has a genealogy that leaves it suspect (it descends from a vendor response to IP switching -- and IP switching turned out to be a fad) but a lot of careful work has gone into trying to make MPLS a sturdy technology. The issue is, has that work succeeded? I'm actually not in a good place to say. I know some of the things people say about MPLS are clearly silly (the notion MPLS is faster to switch than IP reflects a poor knowledge of router innards, or a poor router design). Other statements have some credibility -- carriers have long wanted to do overlay networks to better track resources (witness how UUNET ran their backbone a few years ago) and MPLS apparently can help. Craig
Unnamed Administration Sources Report that Criag Partidge said...
{snip}
MPLS has a genealogy that leaves it suspect (it descends from a vendor response to IP switching -- and IP switching turned out to be a fad) but a lot of careful work has gone into trying to make MPLS a sturdy technology. The issue is, has that work succeeded?
I'm actually not in a good place to say. I know some of the things people say about MPLS are clearly silly (the notion MPLS is faster to switch than IP reflects a poor knowledge of router innards, or a poor router design). Other statements have some credibility -- carriers have long wanted to do overlay networks to better track resources (witness how UUNET ran their backbone a few years ago) and MPLS apparently can help.
The scary thing is that the "speed" of MPLS-based networks is taken as gospel by an alarming number of engineers, mainly those who have come out of the large telco's (i.e. ILECs), and are still kind of mad that ATM didn't work out. These folks are more or less alarmed by IP, and desperately seek a more deterministic, switch-based model of data transmission for the Internet as a whole. The fact that there is no practical, real-world difference in forwarding speed between straight IP, and IP over MPLS is generally explained away by these guys in a fairly elaborate handwaving exercise. At least one major hardware vendor is not helping this, with some of their engineers convincing major customers that conventional IP routing is bad, and that anything MPLS is good. While I agree that MPLS has it's uses - i.e. TE as an exception handling mechanism for outages, and L2VPN technology as a FR/ATM replacement, some folks need to approach the technology with additional caution, and not blindly embrace it as a panacea. As the internet engineering community evolves, learning from things like ATM, becomes quite important. - Daniel Golding
Daniel,
The scary thing is that the "speed" of MPLS-based networks is taken as gospel by an alarming number of engineers, mainly those who have come out of the large telco's (i.e. ILECs), and are still kind of mad that ATM didn't work out. These folks are more or less alarmed by IP, and desperately seek a more deterministic, switch-based model of data transmission for the Internet as a whole. The fact that there is no practical, real-world difference in forwarding speed between straight IP, and IP over MPLS is generally explained away by these guys in a fairly elaborate handwaving exercise. At least one major hardware vendor is not helping this, with some of their engineers convincing major customers that conventional IP routing is bad, and that anything MPLS is good. While I agree that MPLS has it's uses - i.e. TE as an exception handling mechanism for outages, and L2VPN technology as a FR/ATM replacement, some folks need to approach the technology with additional caution, and not blindly embrace it as a panacea. As the internet engineering community evolves, learning from things like ATM, becomes quite important.
Too true! Whats scary is that product "managers" believe the hype, and you get into discussions about how MPLS can enable "application based QoS" because some sales "engineer" [WTF is that anyway?] at a vendor conference has waffled on about it and how well it works. What isn't provided at these conferences are the realities in deploying it, or any real life examples of an application, and also finding some dumg idiot thats willing to pay for it when he can buy something else [ATM/FR/SDH/PDH] at fraction of the price isn't clear either. Oh and that the router supports these features in: 3.fixed3bugs.added14others.4.hohoyoureatotalnutterifyourunthiscode.1 and that the management system will be able to manage these features in q4 of 2010 which , "but no we won't commit to that" and isn't our CLI wonderful. Some of the VPN/VRF functionality clearly isn't deployable in a scalable manner [atleast my definition of scalable], I think one of the solutions to scaling is to deploy multiple sets of route-reflectors to manage routing updates for different services. One set for Internet, one for high level service, and one for low etc. That, to me, isn't the definition of scaling and the minute you get a customer who wants to cross the boundaries of this setup you are screwed. The other thing that is worrying is how many telco dinosaurs have come out of their hiding places claiming to be gurus on all things IP and MPLS because to them it looks like a telephone switch. These people will cause you to lose hair - either trying to get a word in edgewise or trying to fix the abortive "designs and solutions" that they have "engineered". Be afraid! Regards, Neil.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Actually I think I find myself agreeing with both of these viewpoints. When MPLS first launched everyone was hyping what a massive speed increase it would have through your network which has been proved to be a load of rubbish. However I do believe that it has some useful applications and deploying it as an enabler technology across your backbone may not be a bad thing - infact certain features (i.e.. fast reroute) are a good thing in certain topologies. Many of the "applications" that are being (note I say are being as they don't work well enough yet!) developed i.e. L2 and L3 VPNs may well be, in the future, very handy and very sought after services to sell to your clients but currently there are just too many flaws to really consider (in my opinion - and from experience) deploying them in anger. In the future I have no doubt that routers and vendor code sets will be able to cope with the strains and stresses these "features" place on them but at the moment the abilities to deploy, provision and support these applications are just not viable on a large ISP/carrier backbone. This is backed up by my inherent dislike of offline provisioning/management tools which many vendors are recommending for L3 VPN provisioning on a large scale. The other debate you often find yourself in is the "do we use LDP/TDP to dynamically distribute labels and create LSPs or do we statically (RSVP) define LSPs"? Both have their advantages and it depends on your network, traffic topologies and congestion levels but if your network is in good shape then my personal opinion is that I'd plump for LDP anytime as I'm not a fan of the Telco/ATM theories of creating a large PtP mesh network. Anyways - just my 2 cents. James - -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Neil J. McRae Sent: 08 August 2001 08:31 To: Daniel Golding Cc: Craig Partridge; davei@biohazard.demon.digex.net; nanog@merit.edu Subject: Re: MPLS VPNs or not? Daniel,
The scary thing is that the "speed" of MPLS-based networks is taken as gospel by an alarming number of engineers, mainly those who have come out of the large telco's (i.e. ILECs), and are still kind of mad that ATM didn't work out. These folks are more or less alarmed by IP, and desperately seek a more deterministic, switch-based model of data transmission for the Internet as a whole. The fact that there is no practical, real-world difference in forwarding speed between straight IP, and IP over MPLS is generally explained away by these guys in a fairly elaborate handwaving exercise. At least one major hardware vendor is not helping this, with some of their engineers convincing major customers that conventional IP routing is bad, and that anything MPLS is good. While I agree that MPLS has it's uses - i.e. TE as an exception handling mechanism for outages, and L2VPN technology as a FR/ATM replacement, some folks need to approach the technology with additional caution, and not blindly embrace it as a panacea. As the internet engineering community evolves, learning from things like ATM, becomes quite important.
Too true! Whats scary is that product "managers" believe the hype, and you get into discussions about how MPLS can enable "application based QoS" because some sales "engineer" [WTF is that anyway?] at a vendor conference has waffled on about it and how well it works. What isn't provided at these conferences are the realities in deploying it, or any real life examples of an application, and also finding some dumg idiot thats willing to pay for it when he can buy something else [ATM/FR/SDH/PDH] at fraction of the price isn't clear either. Oh and that the router supports these features in: 3.fixed3bugs.added14others.4.hohoyoureatotalnutterifyourunthiscode.1 and that the management system will be able to manage these features in q4 of 2010 which , "but no we won't commit to that" and isn't our CLI wonderful. Some of the VPN/VRF functionality clearly isn't deployable in a scalable manner [atleast my definition of scalable], I think one of the solutions to scaling is to deploy multiple sets of route-reflectors to manage routing updates for different services. One set for Internet, one for high level service, and one for low etc. That, to me, isn't the definition of scaling and the minute you get a customer who wants to cross the boundaries of this setup you are screwed. The other thing that is worrying is how many telco dinosaurs have come out of their hiding places claiming to be gurus on all things IP and MPLS because to them it looks like a telephone switch. These people will cause you to lose hair - either trying to get a word in edgewise or trying to fix the abortive "designs and solutions" that they have "engineered". Be afraid! Regards, Neil. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBO3EzqTyrtEQtecfwEQJKxgCgwTi5I59IBNGkrO9JYpUBhgcDc6MAoPnv 8uvAwe9Ug43ExKb12sVSA0eq =/GEb -----END PGP SIGNATURE-----
Craig Partridge wrote:
the notion MPLS is faster to switch than IP reflects a poor knowledge of router innards, or a poor router design.
Or just outdated information. It wasn't too long ago that IP best- match lookup hardware couldn't do line-rate at the high speeds needed in the cores of large networks. At that time, ATM was able to do line- rate forwarding at those speeds. This is one of the reasons that ATM was adopted in those networks. One of the big reasons for ATM's speed is its use of fixed-length VPI/VCI header lookups instead of variable- length IP best-match lookups. MPLS, thanks to its use of a fixed- length label header lookup has the same advantage. Over time, however, this advantage disappeared. IP best-match lookup chips were developed that could do a proper IP lookup at full line rate for OC-48 and even OC-192. With line-rate IP lookup, it's no longer possible for something else to be faster. It is possible that the pendulum may swing back the other way in time, of coruse. It is possible that IP lookup chips that can handle the next generation of line rate may not become available in a timely manner, which would once again give the advantage to fixed-length header lookup chips. But not having a crystal ball at hand, I have no idea if this is actually going to happen or not. -- David
On Tue, 7 Aug 2001 16:18:25 -0400 Dave Israel wrote:
1991 ATM
Running DSL circuits everywhere (though not for much longer, at this rate.) Not to mention voice and video, and even some IP backbones.
I almost included DSL in my original list of failed, telco originated technologies, but the list was getting too long. Obligatory off topic digression: My current happiness is based on events of the year 1996, Common Era. In that year, we: 1) read Scott Bradner's post on NANOG in which he said that generation two of cable modems were pretty good (if Bradner says it works, it works), 2) read the DSL specs, and realized that not only did bellheads write them, but they were ATM based. Therefore, DSL would fail.
From the above, we decided our ISP should concentrate on high speed over cable modems. Turns out, knowing what you are doing technically does have advantages.... Of course, you will just have to take my word for it as you lack the prerequisites to test this postulate.
good luck, fletcher P.S. Did you know that there is an evolving generation of DSL specs... that are Ethernet based? See: http://www.ieee802.org/3/efm/index.html for details (EFM is Ethernet in the First Mile.)
participants (7)
-
Craig Partridge -
Daniel Golding -
Dave Israel -
David Charlap -
Fletcher E Kittredge -
James Cumming -
neil＠DOMINO.ORG