Category: traffic engineering
It’s amazing how creative networking engineers become once they have the basic tools to get the job done a bit quicker. Last week Pete Crocker published the largest topology I’ve seen built with netlab so far: a 13-router lab running RSVP TE to transport IP traffic between external autonomous systems1.
A while ago Russ White (answering a reader question) mentioned some areas where we might find machine learning useful in networking:
If we are talking about the overlay, or traffic engineering, or even quality of service, I think we will see a rising trend towards using machine learning in network environments to help solve those problems. I am not convinced machine learning can solve these problems, in the sense of leaving humans out of the loop, but humans could set the parameters up, let the neural network learn the flows, and then let the machine adjust things over time. I tend to think this kind of work will be pretty narrow for a long time to come.
Guess what: as fancy as it sounds, we don’t need machine learning to solve those problems.
After covering the details of PCEP protocol in the BGP-LS and PCEP Deep Dive webinar Julian Lucek focused on how a controller would use PCEP to build MPLS TE paths across a network.
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).
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.
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).