Building network automation solutions

9 module online course

Start now!

7 comments:

  1. 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. 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. In two words, I would say IP is "connectionless" while MPLS is "connection-oriented" :)
  4. No, "connection-oriented" has a completely different meaning. I'll get to that in one of the "summer campfire" blog posts.
  5. 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. 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. >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
Sidebar