Let's see - DNS lets you type in slashdot.org and get an IPv4 or IPv6 address. Anycast lets you type in a long hexadecimal IPv6 address in your browser bar. Why do you think Anycast could ever replace DNS? It may well be used in some niches, e.g. to talk to a server farm, but it's not going to be relevant and will never replace DNS.
Anycast isn't even supported by many IPv6 implementations, since it's hard to actually implement it. DNS is *more* important in IPv6 than IPv4, because the addresses are more of a pain to type. DNS is not going to go away...
IPv6 doesn't have 'Class A' blocks - everyone can get a large amount of address space with IPv6, not just the mega corporations. The main drivers for IPv6 are going to be:
- 3G mobile phones - IPv6 is mandated by UMTS R5, the 3G technology for GSM network operators
- Asian markets - Asia was late to the party in IP, and only got a tiny amount of IPv4 address space. This is why NTT is already running a commercial IPv6 service in the US and Japan.
I use TWiki a lot as well - it doesn't address the same problem space as XML, and in fact doesn't really have semantic markup, but it is very useful as a way of collaborating by creating web pages. The idea is that anyone with a web browser can edit any web page. There are some people working on transforming Wiki pages into documents, using TWiki, but that's not really its focus.
I agree about the quality of the writing - he should get someone who can write to edit his page before it goes live... (e.g. 'lead' for 'led' on the first page).
They should probably cut the basic price to $30 per so, including a maximum transfer amount per month, and then bill per megabyte above that - the idea being that low users can still afford the service, opening up the market. Also, having a low introductory price would mean a lot more people would try the service. Higher-volume users could have plans with much higher transfer volumes, and at the top end unlimited volumes.
Part of the problem with Metricom was not having enough subscriber volume - consumers find that $80 per month is too high, and businesses need much better national coverage. At least by cutting the prices a bit and making them volume based, there's a chance the new owners can make a profit. I'm sure Aerie has its own debts, so it's unlikely they can afford to set very low prices if they want to grow the business - new network build-outs will need to be financed by the promise of future revenues.
Ultimately, wireless operators of all kinds need to make money - although Metricom's MCDN technology is very cool, it's also quite expensive to build out since it needs a very dense deployment of poletop transmitters, so it's crucial to find a business model that will let Aerie make enough money to grow the business.
Yes, GSM is really dying - that's why it has 560 million subscribers worldwide (about 70% of the digital cellphone market)... For lots more stats, see http://www.gsmworld.com/membership/mem_stats.html - strangely enough, the US != The World, and GSM is so useful as a global standard that it is gaining market share in the US, including conversions from TDMA (D-AMPS) operators such as Cingular.
Most GSM operators are upgrading to GPRS, which provides a fairly good always-on IP network service - you just dump packets into the GPRS network whenever you want (just like cable/ADSL, but slower). The 3G standard that will be implemented by many GSM operators is called UMTS and uses Wideband CDMA (W-CDMA) as the radio interface - this is based on CDMA technology but is not upward compatible with the Qualcomm-backed version of CDMA that's used in the US, Japan, Korea and a few other places.
Japan is migrating to W-CDMA, and AT&T Wireless and some other US operators are deploying UMTS, so you'll be able to buy phones that roam across the US, Europe and Asia (including Japan), when 3G eventually arrives. The CDMA camp's strongest suit is that their CDMA2000 3G standard doesn't require new spectrum (or at least the 1X variants don't), which avoids the horribly expensive UMTS 3G licenses that European operators are suffering from.
Europe is basically 100% GSM, and GSM is predominant in Asia, but CDMA is used in both Korea and Japan, and probably some other Asian countries. Japan's other networks are PDC and PHS, no GSM there at all right now.
The key issue that needs highlighting is the *number of high severity bugs* - as long as this is going down, as it is, Mozilla is clearly converging on a releasable product. Personally, I'm quite happy with Mozilla's quality already - the few bugs that I've found myself have typically already been reported and on the way to being fixed, and in 0.9.3 it's now quite stable and almost as fast as IE5.
802.11a does have one low-power mode that might compete with Bluetooth, but most people are expecting it to be 'Wireless Fast Ethernet' (actually just 30 Mbps real throughput, even though 54 Mbps theoretical), with a range not that much lower than 802.11b.
The article is about a year out of date... 802.11b has basically won over HomeRF, and is likely to dent Bluetooth's popularity a lot. Personally, I think they both have their place, but Bluetooth will have to address its interference with 802.11b if it is not to be banned from the Wi-Fi workplace and avoided in Wi-Fi homes.
See http://www.radio.gov.uk/publication/press/2000/20o ct00.htm for the spectrum (10 GHz) used by NTL - this rules out 802.11b, which works at 2.4 GHz only.
They are using some variant of 'fixed wireless', also known as wireless local loop (WLL) - this is intended only to serve fixed sites, as the name implies, and uses a variety of spectrum from 2 GHz up to 30+ GHz - these technologies go by various names including MMDS and LMDS.
The good news is that this is licensed spectrum, so performance is determined by the network operator, not by the number of people near you with wireless LANs, and coverage is generally much better (802.11b would be quite an expensive way to try to cover a whole city).
Fixed wireless access (FWA) is already being deployed by various operators in the US (Sprint, Worldcom) and UK (Tele2, around Reading). It has a chequered history with various bankruptcies (Teligent in the US, Ionica in the UK), but if the costs come down and standards are agreed, it could be a useful competitor to Cable and xDSL, particularly for areas they don't address (e.g. industrial/business areas, and rural areas).
For more information, see http://www.watmag.com/technologies/Broadband/ovum/ broadband_ovum.html
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.
Unfortunately true - ideally you could just block the customers with infected IIS servers, but that might require router access control lists with a large set of IP addresses. It all depends on how many customers are infected, vs. how many run web servers (intentionally). Altogether, it might be best to mail all customers to notify them of port 80 blocking, and invite them to email you for unblocking if they need it unblocked - this will protect future customers who are clueless enough to have IIS running without realising (typically small businesses with Windows NT/2000 server).
You could use MPLS labels in theory to identify flows, but in practice nobody is going to use it that way - you would have a huge overhead to set up per-flow LSPs through your core network. You would also run out of label space at core routers, and the core route state maintenance overhead would be huge. At most, people will create additional LSPs to handle additional QoS requirements (e.g. create a 2nd LSP and you can handle an extra 8 CoS levels).
If you need per-flow QoS, use RSVP or one of the lighter-weight reservation protocols, as a way of admitting flows into a fixed size pipe across your core network. That pipe can be an MPLS traffic engineered LSP, which can be set up with a certain bandwidth guaranteed through the core (very like an ATM PVC). If you use IPv6 for marking flow labels, you can make the per-flow marking decision right at the first hop router, then use this flow label at all RSVP-enabled routers up to the edge MPLS LSR, which just maps the flow into the appropriate LSP.
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.
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.
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.
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.
I'm talking about the need to configure each IPSec gateway with appropriate keys, crypto maps, tunnel interfaces, tunnel IP addresses, etc - not a big deal for a few boxes but much more of an issue when you have 200 sites and each site requires a tunnel to 199 other sites.
This is enough of an issue for large networks that hardware sales are swung by the IPSec provisioning/policy software, and larger providers are looking for solutions that scale to tens of thousands of sites.
MPLS VPNs also typically require provisioning software, but by contrast most of the work is done on provider-edge routers, and can even be done by hand. MPLS VPNs don't require any tunnels at all - you just connect a new site into the VPN, and BGP automagically distributes the IP-to-label bindings around the network, keeping each VPN's address space separate. The per-packet overhead is only 4 bytes, which is significant when you want to roll out enterprise-wide VoIP over the VPN.
If you are running IPSec without encryption over the Internet, your VPN security is quite non-existent, and much lower than an MPLS VPN, so I'd be surprised if many people do this.
MPLS VPNs are just as secure (or not) as Frame Relay, which is used by most enterprise private networks (the provider runs the Frame Relay part).
You can easily run IPSec tunnels over MPLS if this concerns you, but it's a lot harder to run a huge IPSec VPN than an MPLS VPN. Both of them have their role, and will increasingly be used together - MPLS VPNs for scalability and other MPLS benefits, IPSec for end to end encryption.
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.
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.
Slashdot Mirror
Let's see - DNS lets you type in slashdot.org and get an IPv4 or IPv6 address. Anycast lets you type in a long hexadecimal IPv6 address in your browser bar. Why do you think Anycast could ever replace DNS? It may well be used in some niches, e.g. to talk to a server farm, but it's not going to be relevant and will never replace DNS.
Anycast isn't even supported by many IPv6 implementations, since it's hard to actually implement it. DNS is *more* important in IPv6 than IPv4, because the addresses are more of a pain to type. DNS is not going to go away...
IPv6 doesn't have 'Class A' blocks - everyone can get a large amount of address space with IPv6, not just the mega corporations. The main drivers for IPv6 are going to be:
- 3G mobile phones - IPv6 is mandated by UMTS R5, the 3G technology for GSM network operators
- Asian markets - Asia was late to the party in IP, and only got a tiny amount of IPv4 address space. This is why NTT is already running a commercial IPv6 service in the US and Japan.
I use TWiki a lot as well - it doesn't address the same problem space as XML, and in fact doesn't really have semantic markup, but it is very useful as a way of collaborating by creating web pages. The idea is that anyone with a web browser can edit any web page. There are some people working on transforming Wiki pages into documents, using TWiki, but that's not really its focus.
I agree about the quality of the writing - he should get someone who can write to edit his page before it goes live... (e.g. 'lead' for 'led' on the first page).
Read the story! New York is listed as one of the states where Aerie want to buy the infrastructure.
They should probably cut the basic price to $30 per so, including a maximum transfer amount per month, and then bill per megabyte above that - the idea being that low users can still afford the service, opening up the market. Also, having a low introductory price would mean a lot more people would try the service. Higher-volume users could have plans with much higher transfer volumes, and at the top end unlimited volumes.
Part of the problem with Metricom was not having enough subscriber volume - consumers find that $80 per month is too high, and businesses need much better national coverage. At least by cutting the prices a bit and making them volume based, there's a chance the new owners can make a profit. I'm sure Aerie has its own debts, so it's unlikely they can afford to set very low prices if they want to grow the business - new network build-outs will need to be financed by the promise of future revenues.
Ultimately, wireless operators of all kinds need to make money - although Metricom's MCDN technology is very cool, it's also quite expensive to build out since it needs a very dense deployment of poletop transmitters, so it's crucial to find a business model that will let Aerie make enough money to grow the business.
Yes, GSM is really dying - that's why it has 560 million subscribers worldwide (about 70% of the digital cellphone market)... For lots more stats, see http://www.gsmworld.com/membership/mem_stats.html - strangely enough, the US != The World, and GSM is so useful as a global standard that it is gaining market share in the US, including conversions from TDMA (D-AMPS) operators such as Cingular.
Most GSM operators are upgrading to GPRS, which provides a fairly good always-on IP network service - you just dump packets into the GPRS network whenever you want (just like cable/ADSL, but slower). The 3G standard that will be implemented by many GSM operators is called UMTS and uses Wideband CDMA (W-CDMA) as the radio interface - this is based on CDMA technology but is not upward compatible with the Qualcomm-backed version of CDMA that's used in the US, Japan, Korea and a few other places.
Japan is migrating to W-CDMA, and AT&T Wireless and some other US operators are deploying UMTS, so you'll be able to buy phones that roam across the US, Europe and Asia (including Japan), when 3G eventually arrives. The CDMA camp's strongest suit is that their CDMA2000 3G standard doesn't require new spectrum (or at least the 1X variants don't), which avoids the horribly expensive UMTS 3G licenses that European operators are suffering from.
Europe is basically 100% GSM, and GSM is predominant in Asia, but CDMA is used in both Korea and Japan, and probably some other Asian countries. Japan's other networks are PDC and PHS, no GSM there at all right now.
The key issue that needs highlighting is the *number of high severity bugs* - as long as this is going down, as it is, Mozilla is clearly converging on a releasable product. Personally, I'm quite happy with Mozilla's quality already - the few bugs that I've found myself have typically already been reported and on the way to being fixed, and in 0.9.3 it's now quite stable and almost as fast as IE5.
802.11a does have one low-power mode that might compete with Bluetooth, but most people are expecting it to be 'Wireless Fast Ethernet' (actually just 30 Mbps real throughput, even though 54 Mbps theoretical), with a range not that much lower than 802.11b.
The article is about a year out of date... 802.11b has basically won over HomeRF, and is likely to dent Bluetooth's popularity a lot. Personally, I think they both have their place, but Bluetooth will have to address its interference with 802.11b if it is not to be banned from the Wi-Fi workplace and avoided in Wi-Fi homes.
See http://www.radio.gov.uk/publication/press/2000/20o ct00.htm for the spectrum (10 GHz) used by NTL - this rules out 802.11b, which works at 2.4 GHz only.
/ broadband_ovum.html
They are using some variant of 'fixed wireless', also known as wireless local loop (WLL) - this is intended only to serve fixed sites, as the name implies, and uses a variety of spectrum from 2 GHz up to 30+ GHz - these technologies go by various names including MMDS and LMDS.
The good news is that this is licensed spectrum, so performance is determined by the network operator, not by the number of people near you with wireless LANs, and coverage is generally much better (802.11b would be quite an expensive way to try to cover a whole city).
Fixed wireless access (FWA) is already being deployed by various operators in the US (Sprint, Worldcom) and UK (Tele2, around Reading). It has a chequered history with various bankruptcies (Teligent in the US, Ionica in the UK), but if the costs come down and standards are agreed, it could be a useful competitor to Cable and xDSL, particularly for areas they don't address (e.g. industrial/business areas, and rural areas).
For more information, see http://www.watmag.com/technologies/Broadband/ovum
Absolutely - in fact, why not always show the year, it's only 4 digits. Has this been submitted as a bug yet?
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.
Unfortunately true - ideally you could just block the customers with infected IIS servers, but that might require router access control lists with a large set of IP addresses. It all depends on how many customers are infected, vs. how many run web servers (intentionally). Altogether, it might be best to mail all customers to notify them of port 80 blocking, and invite them to email you for unblocking if they need it unblocked - this will protect future customers who are clueless enough to have IIS running without realising (typically small businesses with Windows NT/2000 server).
You could use MPLS labels in theory to identify flows, but in practice nobody is going to use it that way - you would have a huge overhead to set up per-flow LSPs through your core network. You would also run out of label space at core routers, and the core route state maintenance overhead would be huge. At most, people will create additional LSPs to handle additional QoS requirements (e.g. create a 2nd LSP and you can handle an extra 8 CoS levels).
If you need per-flow QoS, use RSVP or one of the lighter-weight reservation protocols, as a way of admitting flows into a fixed size pipe across your core network. That pipe can be an MPLS traffic engineered LSP, which can be set up with a certain bandwidth guaranteed through the core (very like an ATM PVC). If you use IPv6 for marking flow labels, you can make the per-flow marking decision right at the first hop router, then use this flow label at all RSVP-enabled routers up to the edge MPLS LSR, which just maps the flow into the appropriate LSP.
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.
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.
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.
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.
I'm talking about the need to configure each IPSec gateway with appropriate keys, crypto maps, tunnel interfaces, tunnel IP addresses, etc - not a big deal for a few boxes but much more of an issue when you have 200 sites and each site requires a tunnel to 199 other sites.
This is enough of an issue for large networks that hardware sales are swung by the IPSec provisioning/policy software, and larger providers are looking for solutions that scale to tens of thousands of sites.
MPLS VPNs also typically require provisioning software, but by contrast most of the work is done on provider-edge routers, and can even be done by hand. MPLS VPNs don't require any tunnels at all - you just connect a new site into the VPN, and BGP automagically distributes the IP-to-label bindings around the network, keeping each VPN's address space separate. The per-packet overhead is only 4 bytes, which is significant when you want to roll out enterprise-wide VoIP over the VPN.
If you are running IPSec without encryption over the Internet, your VPN security is quite non-existent, and much lower than an MPLS VPN, so I'd be surprised if many people do this.
MPLS VPNs are just as secure (or not) as Frame Relay, which is used by most enterprise private networks (the provider runs the Frame Relay part).
You can easily run IPSec tunnels over MPLS if this concerns you, but it's a lot harder to run a huge IPSec VPN than an MPLS VPN. Both of them have their role, and will increasingly be used together - MPLS VPNs for scalability and other MPLS benefits, IPSec for end to end encryption.
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.
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.