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.
Julian Lucek did a fantastic job describing how NorthStar controller uses BGP-LS and PCEP, so I asked him whether he’d be willing to do a deep dive on these two topics. He gracefully agreed, and the results are already online.
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.
One of my readers was having an LDP argument with his colleague:
Yesterday I was arguing with someone who works for a large MPLS provider about LDP label allocation. He kept saying that LDP assigns a label to each next-hop, not to each prefix. Reading your blog, I believe this is the default behavior on Juniper but on Cisco LDP assigns a unique label for each IGP (non-BGP) prefix.
He’s absolutely right; Cisco and Juniper use different rules when allocating MPLS labels.
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).
After discussing the load sharing intricacies we briefly dabbled with the concept of entropy labels.
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).
After discussing the basics of MPLS, MPLS-TE and LDP, and the relationship between FECs, LDP and BGP, Seamus and myself focused on another interesting topic: how MPLS protocol stack uses RSVP to implement traffic engineering.
One of my readers is struggling with the aftermath of marketing gimmicks:
We will be implementing a new network soon, and we're discussing P-routers versus regular routers versus switches. I'm looking for arguments to go one way or the other.
MPLS bottom-of-stack bit confused one of my readers. In particular, he had a problem with the part where the egress MPLS Label Switch Router (LSR) should go from labeled (MPLS) to unlabeled (IPv4, IPv6) packets and has to figure out what’s in the packet.