Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

IETF Debates On: MPLS Is Bad 94

Posted by Hemos from the future-of-the-internet dept.
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. "
This discussion has been archived. No new comments can be posted.

IETF Debates On: MPLS Is Bad More

IETF Debates On: MPLS Is Bad

Comments Filter:

  • User's view (Score:3, Informative)

    by slashnik ( 181800 ) on Wednesday August 08, 2001 @02:55AM (#2113883)

    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

    • As I understand it, using MPLS to set up IP tunnels eliminates encryption. That means you just don't get the same security as with a VPN--you are missing the "P" in "VPN".

      I also don't quite understand why you say that a "300 site IPSEC Tunnel VPN" would be harder to manage. It seems that if you have a public key infrastructure (and you need that anyway), any two sites can easily and securely identify themselves to each other and set up a VPN between them if they choose; there should be no need for any central administration or management at all, at least if you have reasonably good software at the endpoints.

      • 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 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).

          That doesn't sound particularly reassuring, since it relies on physical security, integrity of your infrastructure, and trust in your provider if you outsource. For example, if anybody breaks into some machine that's part of your infrastructure, they can potentially get access to all the traffic going through that router.

          it's a lot harder to run a huge IPSec VPN than an MPLS VPN

          I still don't understand what you mean by this. What is there "to run" with a VPN? For a VPN, you need to know the gateways, subnets, and public keys of anybody you want to talk to (if you don't want encryption, you don't need the keys), and you don't have to think about transports or routing at all since that is taken care of by the existing Internet infrastructure. It seems to me that MPLS requires you to worry about additional things. So, I really don't see how MPLS makes things simpler for anybody when it comes to VPNs.

          • 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.

      • Re:User's view (Score:2, Interesting)

        by slashnik ( 181800 )

        The alternative would have been a private network over leased lines or frame relay links. We have a virtual private network in that all sites are linked together over a 3rd party core providing seperacy of data / routing protocols from other users of the 3rd party core. Where security is required we still encrypt data using IPSEC over the MPLS VPN.

        With the MPLS solution there is "single hop" connectivity between all sites at all times.

        Wouldn't there be high management overhead to reproduce with IPSEC tunnels?

        slashnik
        • Wouldn't there be high management overhead to reproduce with IPSEC tunnels?

          I don't see why. With a VPN, each participant needs to know the public keys, gateways, and subnets of all the others it wants to talk to directly. You can distribute and update that information automatically from a central, public site as a single file and have it installed on each satellite system automatically. How much easier can it get?

          MPLS somewhere requires at least the same amount of information. Now, maybe your communications provider uses their internal customer/equipment database to hide this from you, but the bookkeeping is still happening, and presumably you are paying for the convenience. Furthermore, since your provider isn't doing encryption for you with MPLS, you still have the same key distribution problem, so you end up doing the distribution yourself anyway, at least if you want any kind of security.

          So, overall, I still don't get it. In terms of total effort, MPLS seems no easier to set up and use than a VPN to me. It's shifting some of the work around, but its lack of encryption means that you end up duplicating effort anyway.

          • What sort of router would you use to create 300 IPSEC tunnels?
            • Well, for applications where the traffic isn't too high, a workstation with a software VPN solution. That clearly is not a good solution for many installations, but it is easy to set up and shows that technically, there is nothing complex about it. I don't know of any high-end hardware solutions that is designed to handle such a configuration. (I'm also not sure it's really a good way of setting up a VPN, but that's another issue.)

              Let me ask you the corresponding question. With MPLS, how do you handle encryption? Do you just not bother? Do you do it in software? Or do you use hardware? How do you distribute keys and how do you revoke them? How do you install those keys on your encryption hardware if you are using hardware?

              So, the question is: why is the industry pushing MPLS rather than offering better VPNs? Probably MPLS is really being deployed because it addresses another problem, and this is just another service that can be offered using it. No doubt, users find it convenient given that devices with equivalent/better VPN-based functionality aren't being sold (as widely?). Communications providers may like that it creates a "closer relationship" with their customer (i.e., you probably won't switch as easily). Hardware manufacturers may see an opportunity to sell a lot more boxes. I don't know exactly what the reason is, that's what I'm trying to understand (thanks--the discussion so far has helped). In any case, I'd hold on to my wallet :-)

              • The main point to remember here is that the carriers' MPLS VPN service was an alternative to having to build a private country wide 300 node network. It would be pretty expensive to do this where each site requires E1(T1) access. Even once it's built it would cost a fortune to run and manage

                When encryption is required, eg. for financial data, encryption is done in hardware (NIC -> Router) this is not my area so I don't know how keys are handled

                As to why the industry is pushing VPN's, It may be that to large service providers bandwidth is pretty cheap. MPLS VPN's provide them with a way that they can productize this bandwith while keeping logical separation between the customers networks. Customers can even use the same IP address ranges.

          • 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.
            • Yes, VPNs don't have a widely used protocol for dynamically distributing their configuration information. That's probably because people haven't traditionally used VPNs in that way and because VPN configuration is a much simpler problem than updating Internet routing information and can be addressed pretty well without a special protocol.

              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).

              • 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.

  • Well... It doesn't suck but... (Score:4, Interesting)

    by BigScoob ( 138622 ) on Wednesday August 08, 2001 @03:05AM (#2118788) Homepage
    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...

    • It's true that one of MPLS's goals was to speed up forwarding, and that this is no longer necessary with fast IP forwarding hardware. However, it had many other goals, including separation of routing and forwarding, enabling (1) traffic engineering so that you can balance traffic across your network topology, (2) VPNs with same security as FR/ATM and (3) core router upgrades to IPv6 without changing the forwarding hardware.

      As usual, the journalists are late to the controversy - this was a hot topic in 1997 when MPLS was first invented (tag switching, Cisco's proprietary version) and then again a year or two later as the MPLS working group hotted up.
  • I'm just astounded at how far this has developed. I remember describing the concept of tag or label switching in a hop-by-hop packet net (which I then called a "forward cache ID", as usual, the inventor picks a too-mundane name ;-) at the IETF in Columbus Ohio (I think, 1993? You could look it up!) in one of the IPng/IPv7 "keynote" talks: Tony Li (then of cisco, more recently Juniper) immediately complained that I was making router makers' life more complicated ...

    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

  • 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.

  • MPLS is a useful tool (Score:4, Informative)

    by Cato ( 8296 ) on Wednesday August 08, 2001 @04:40AM (#2136059)
    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.
  • There -IS- an MPLS implementation for Linux, so you can actually decide for yourself whether it's "good", "evil" or "code".

    I can't remember the main URL, but since my FOLK project uses it, I've a link from the FOLK pages [sourceforge.net].

  • Hey now! (Score:2, Funny)

    by Xaroth ( 67516 )
    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.

  • MPLS sucks (Score:3, Informative)

    by Anonymous Coward on Wednesday August 08, 2001 @03:02AM (#2148501)
    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.

    • Re:MPLS sucks (Score:2, Informative)

      by sireenmalik ( 309584 )
      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.
    • 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.
    • 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.

    • Re:MPLS sucks (Score:2, Informative)

      by cheezedawg ( 413482 )
      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 [nec.com]). 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.
      • 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.

        • Well, using the EXP bits, you can uniquely identify 8 different flows, but using an MPLS shim you can uniquely identify 2^23 flows (20 bits for the tag, and the 3 EXP bits). I really don't see that as the same thing.
          • 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.
    • 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.

    • QoS, the Future (Score:2, Informative)

      by SamBaughman ( 74713 )
      QoS is not (directly) about who gets screwed. Only paranoid bandwidth junkies who are afraid about having to pay market value for their bandwidth think about it that way.

      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.

      • 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

    • Re:MPLS sucks (Score:5, Informative)

      by Florian Otel ( 513312 ) on Wednesday August 08, 2001 @05:12AM (#2151004) Homepage
      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.
      [snip]

      This would be enough for a person with an average education in MPLS to judge how much you (don't) know about MPLS. I am doing MPLS-oriented research for the last 1.5 years so let me try clearing some of the "bad air" around the issue:

      1) MPLS is NOT circuit switching ON TOP of packet switching. If you would care to do some minimal reading before you flame a subject, you would find out that MPLS is not ISO layer >= 3 but it is a "layer 2.5" technology. In other words IP datagrams are carried on top of MPLS frames pretty much the way ATM worked.

      2) The reasons behind MPLS are too complex to describe here (for the intrested reader, take a look at RFC3031). But basically it was acknowledged that despite ATM being "evil" circuit switched technology does offer some advantages. That's why you can (_very_ roughly) characterize MPLS as an "IP friendly ATM", minus some of ATM's design shortcomings (that were present there due to the technology limitations at that time and ATM's intended use).
      But to rebute your misconception, MPLS is NOT about "routing IP datagrams fast", nor "replacing CIDR". Again, if you care to skim the mentioned RFC it is acknowledged that this _were_ some advantages few MPLS proponents claimed but this is simply not true, as you correctly state: Efficient algorithms for IP address lookup and routing are implemented in hardware by several vendors (incl. cisco, btw...) so MPLS doesn't have any edge there.

      3) About "Traffic Engineering being a load of crap" I would say that few of the top 10 largest carriers in US might disagree a bit. Get a hold of an educated MCI network operations engineering (say MCI/UUNET) and ask how much improvement (and revenue) TE gives them. And yes, the reaction is "WOW".

      And QoS... Same deal- load of crap.
      4) Well, QoS is too broad a topic to disuss in any relevance here. But in saying that you automatically excluded _all_ mechanisms for traffic differentiation in a network. Enough said.

      Also, to end this, MPLS is _not_ only about TE/QoS/IP fast switching. It is used for fast network restoration, it is extended for supporting WDM in a similar manner (see "Generalized"MPLS), etc. People w/ some network education might care to take a look here [watersprings.org] for a overall view on the MPLS-related topics.

      All in all I would dare to say that your posting is the worst kind of mis-information:It contains a grain of truth and mixes completely different and unrelated subjects as "comparisons" (OPenGL w/ CIDR)

      For the rest of the readers, the necessary grain of salt when reading the linked article: In IETF there is a lot of politics around MPLS (disguised in "technical debates") -- surprise,surprise. For example if someone cares to browse the MPLS mailing list archives Mr. Randy Bush long opposed BGP/MPLS VPNs (described initially in RFC2547.IIRC there is also draft updating it). Which happen to be a technology cisco pushes very hard and which Mr. Bush opposes violently.
      What particular agenda Mr. Bellovin has escapes me. But I assume (again, this is _speculation_) since AT&T made a _huge_ investment in ATM in the past do not see MPLS (which is simply a better competening technology) so favorably.

      All in all, remember that the most competent answer is "I don't know.It depends".


      My $0.02
      Florian-Daniel Otel
      http://www.ce.chalmers.se/staff/otel [chalmers.se]
      • 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.
        • LOL! I'm guessing you just didn't get enough sleep, but how 'bout I use your example, and you tell me if ">= 3" is really the same as "> 2", 'kay?

          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. :)

    • Re:MPLS sucks (Score:3, Informative)

      by Anonymous Coward
      You are just missing the point. It is a lot more than just switching, because, for example, MPLS packets can be distributed along different paths if available (load balancing), you can force the routing of a tag over a specific path, overriding all the routing table, and the most important, it is the easier way to implement a VPN in seconds and to keep all your backbone transparent for the user (you just can have an INTERNET vpn that has all the customers ports and the internet uplinks). Then, you can do whatever you want in your backbone without bothering about what customers will see. It is all about efficiency in network design. On the other hand, is true that Cisco's implementation still has a lot of annoying bugs but i still hope they will dissapear in time.
      • 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.
        • 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.

          Thats not what the experts said- they said that the default is to not encrypt. There is nothing to stop you from encrypting the whole packet as long as you leave the MPLS label alone.

          Sure MPLS can do lots of nice things, but at what cost?

          This new layer of complexity amounts to checking the first couple of bits of a packet to see if it has an MPLS shim or not. Thats not a whole lot of complexity or cost.

          src/dst addresses identify individual flows uniquely enough

          The source and destination addresses can identify flows most of the time, but its expensive to maintian that rule base and to identify a packet. And if you want more accuracy, you have to add more dimensions to your rule base (src port and dest port for example), and it gets even worse. The best algorithms out there do it in O(n), but the lookup of an MPLS label is done in constant time.

          • Thats not what the experts said- they said that the default is to not encrypt. There is nothing to stop you from encrypting the whole packet as long as you leave the MPLS label alone.

            Of course, but the customer either is not aware of the lack of encryption or you have to add one more layer to the processing of packets.

            This new layer of complexity amounts to checking the first couple of bits of a packet to see if it has an MPLS shim or not. Thats not a whole lot of complexity or cost.

            The mechanism in LSRs is not complex. It is the management of the various flows.

            The source and destination addresses can identify flows most of the time, but its expensive to maintian that rule base and to identify a packet. And if you want more accuracy, you have to add more dimensions to your rule base (src port and dest port for example), and it gets even worse. The best algorithms out there do it in O(n), but the lookup of an MPLS label is done in constant time.

            With IPv6, the core routers can efficiently forward packets based on e.g. /24 or /32 matches without extra lower (2.5 or 2) layer MPLS and the level of detail increases as network edge approaches. I strongly doubt if anyone would use MPLS to separate individual services, so port level accuracy is not an issue. If the VPN gateways want to use labels for identification, they can still use IPv6 flow label field (although this is unnecessary, given the intrinsic route aggregation).

  • OK, we're not perfect. But Minneapolis isn't THAT bad.
  • 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.
    • 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.

  • The IETF loves saying things are bad... (Score:4, Informative)

    by hardaker ( 32597 ) on Wednesday August 08, 2001 @02:43AM (#2150926) Homepage
    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.
    • NO NO NO. It was clarified yesterday on the IPSec session. Radia Perlman did a run-through of those things that ought to be changed, but saying that IKE is "bad" is a misinterpretation. IKE is a bit complicated and a lot of the attendees yesterday agreed on that simplifications made to IKE would be a good thing.


      /magnus - was there.

      • 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

    • Re:The IETF loves saying things are bad... (Score:4, Funny)

      by Swaffs ( 470184 ) <swaff AT fudo DOT org> on Wednesday August 08, 2001 @02:48AM (#2149347) Homepage
      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.

      That's an odd pronunciation...

  • 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!

  • See RFC 2917 [ietf.org] for an "informational" RFC that seems (to me, at least) to be a superior technology. I'll quote the abstract inline:

    This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications.

    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?

  • 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. ;-)

Slashdot Top Deals

If you think the system is working, ask someone who's waiting for a prompt.

Close