Recent posts in the same categories

7 comments:

  1. stretch 09 July 2010 19:58
    I would mention a couple reasons why MPLS is used (e.g. so that P routers need not carry a global table, traffic engineering, etc.).
  2. Muhammad Zeeshan Sanaullah 09 July 2010 22:42
    A key difference between IP Forwarding and MPLS is the considerations that determine how a packet is assigned to an FEC. In MPLS, FECs can be many things like (same IP Prefix, IBGP next-hop etc) and also that FEC of a packet is determined only at the ingress of the MPLS network ... obviously explaining this would take a third of an MPLS book ;)
  3. Petr Lapukhov 10 July 2010 20:59
    In two words, I would say IP is "connectionless" while MPLS is "connection-oriented" :)
  4. Ivan Pepelnjak 10 July 2010 21:15
    No, "connection-oriented" has a completely different meaning. I'll get to that in one of the "summer campfire" blog posts.
  5. Petr Lapukhov 10 July 2010 22:06
    Fine, but I still stand for "connection-oriented" :) Maybe you think of some different meaning, but for me connection-oriented means the fact that MPLS creates LSPs and *maintains* their state across the network core. It's not "truly" connection-oriented in the sense that X.25 or ATM were, but in many senses very close, especially if you think of RSVP-TE.

    In my opinion, the "connection-oriented" nature is what makes the IP+MPLS hybrid so effective: connectionless service is encapsulated in loosely connetion-oriented transport.
  6. Pavel Smirnov 12 July 2010 11:27
    Here some of advantages
    1 ) mpls gives you more control on how traffic goes through the core: constraint lsp, bandwidth reservation etc
    2) LSP applied to whole core network and ip routing make decisions on each box. So you need only to control how traffic get into lsp on ingress router.
    3) lsp fast re-routeing switch traffic in case of failure in milliseconds, comes near to sdh.

    drawbacks
    1) lack of ipv6 support in control protocols RSVP-TE, LDP
  7. Kevin Wenzel 13 July 2010 15:35
    >lsp fast re-routeing switch traffic in case of failure in milliseconds, comes near to sdh.

    In theory, yes - in practice this turns out to be difficult for the 10-15 L3VPN providers we deal with. Two quick points about the idea - first, FRR being F depends on failure *detection* being quick for the milliseconds part to become true (there are a lot of poll-based rather than interrupt-based interfaces still out there, for example), and second, avoiding fate-sharing between primary and backup LSPs (which makes FRR useless) seems to be pretty difficult in large-scale production networks.
Add comment
Home
Sidebar