Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

reserve a seat
back to overview

Zero Bandwidth Traffic Engineering

Oliver Steudler from Juniper sent me a link to an interesting Juniper blog post describing zero-bandwidth traffic engineering.

Read the blog post first and then come back for some opinionated rambling ;)

Is the problem real? Yes. Make-before-break inevitably results in temporary double bandwidth booking. While RSVP-TE solves double-counting on shared legs of the path, it cannot do the same when the old and the new paths diverge.

Is this a problem worth solving? It depends on the percentage of the network bandwidth reserved for traffic engineering tunnels. You don’t have the problem if you use MPLS-TE solely for fast reroute, or if you don’t use most of the reservable bandwidth.

Will this work without a controller? No. Someone has to keep track of how much bandwidth is actually reserved, and in this case the information resides only within the controller. If you allow the MPLS routers to establish additional (non-PCE-controlled) tunnels, you’ll get a nice mess.

Isn’t this functionally equivalent to TE for Segment Routing (aka SPRING)? Yes. In both cases the network devices don’t track bandwidth reservations and thus cannot make reliable autonomous decisions.

So why exactly do we need two equivalent solutions? Most routers deployed today don’t support SPRING, and some may not support (at least some variants of) segment routing without a hardware upgrade. Zero-bandwidth trick works with every router running PCE client.

3 comments:

  1. I don't get it, in the original post the "resulting green path" is as incompatible as the sought after "best one". Well, may be the diagram and the text are wrong, and not all links are 10G (but for the .107 - .103). Also, I don't see why is not .102-.106-.107-.103 a better orange path.
    BTW, this is all graph theory and litle networking :)

    ReplyDelete
    Replies
    1. Yes, the diagram in the original post is suboptimal. You could route the orange path across the other link.

      Delete
    2. My take is that the markings on the links (eg: 50 - 50 on .102 -> .106) are metrics, so the high-priority orange is only ever going to be setup along .102, .105, .107, .103

      Also - LSPs are uni-directional, so the resulting Green Path (3rd diagram) is actually correct - it will only count BW in one direction.

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar