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

After explaining the basics of BGP-LS and PCEP, and a quick deep dive into BGP-LS, Julian Lucek focused on the second topic of his excellent webinar and described the details of Path Computation Element Protocol (PCEP).

My good friend Tiziano Tofoni (the organizer of wonderful autumn seminars in Rome) sent me these questions after attending the BGP-LS and PCEP Deep Dive webinar, starting with:

Are there real use cases for BGP-LS and PCEP? Are they really useful? Personally I do not think they will ever be used by ISP in their (large) networks.

There are some ISPs that actually care about the network utilization on their expensive long-distance links.

After explaining why you’d want to use BGP-LS and PCEP in your network, Julian Lucek did a quick deep dive into the intricacies of BGP-LS, including printouts relating BGP-LS updates to IS-IS topology database.

This part of the PCEP/BGP-LS webinar is already public, to watch the rest of it fill in a short form on the webinar description page.

I was often asked about two emerging technologies that enable standard controller-based WAN traffic engineering: BGP-LS to extract the network topology and PCEP to establish end-to-end tunnels from a controller.

Unfortunately, I never found time to explore these emerging technologies and develop a webinar. However, after Julian Lucek from Juniper did such a great job on the NorthStar podcast, I asked him whether he would be willing to do a deep dive technology webinar on the two technologies and he graciously agreed to do it.

You might be familiar with the idea of using BGP as an SDN tool that pushes forwarding entries into routing and forwarding tables of individual devices, allowing you to build hop-by-hop path across the network (more details in Packet Pushers podcast with Petr Lapukhov).

Researchers from University of Louvain, ETH Zürich and Princeton figured out how to use OSPF to get the same job done and called their approach Fibbing. For more details, listen to Episode 45 of Software Gone Wild podcast with Laurent Vanbever (one of the authors), visit the project web site, or download the source code.

Content providers were using centralized traffic flow optimization together with MPLS TE for at least 15 years (some of them immediately after Cisco launched the early MPLS-TE implementation in their 12.0(5)T release), but it was always hard to push the results into the network devices.

PCEP and BGP-LS all changed that – they give you a standard mechanism to extract network topology and install end-to-end paths across the network, as Julian Lucek of Juniper Networks explained in Episode 43 of Software Gone Wild.

Ethan Banks recently wrote a nice blog post detailing the benefits and drawbacks of traditional routing protocols and comparing them with their SD-WAN counterparts.

While I agree with everything he wrote, the comparison between the two isn’t exactly fair – it’s a bit like trying to cut the cheese with a chainsaw and complaining about the resulting waste.

In the final part of our MPLS-focused discussion (now part of MPLS Essentials webinar), Seamus wanted to know how one could combine MPLS/VPN, MPLS-TE and QoS (for example, sending VoIP traffic for one customer over a different path).

Short answer: don’t even think about doing that. The added complexity is not worth whatever extra money you’ll be charging the customer (or not).

MPLS Traffic Engineer is sometimes promoted as a QoS solution (it seems bandwidth calendaring is a permanent obsession of some networking engineers, and OpenFlow is no more a solution than MPLS-TE was ;), but in reality it’s pretty hard to make the two work together seamlessly (just ask anyone who had to implement auto-bandwidth MPLS-TE in a large network).