Category: MPLS

MPLS Requires Custom Silicon. Really?

I heard the following pretty bold statement while listening to an episode of my favorite podcast: “Bringing MPLS into the data center is impractical because MPLS requires custom silicon.” Really? How about checking the Intel FM 6000 product brief first?

Broadcom Trident chipset supposedly also supports MPLS. I couldn’t verify that because Broadcom considers the capabilities of their hardware highly confidential (but if you know more, do write a comment). Absolutely refreshing for a chipset that you get in almost every ToR switch you buy.

read more see 10 comments

Exception Routing with BGP: SDN Done Right

One of the holy grails of data center SDN evangelists is controller-driven traffic engineering (throwing more leaf-and-spine bandwidth at the problem might be cheaper, but definitely not sexier). Obviously they don’t call it traffic engineering as they don’t want to scare their audience with MPLS TE nightmares, but the idea is the same.

Interestingly, you don’t need new technologies to get as close to that holy grail as you wish; Petr Lapukhov got there with a 20 year old technology – BGP.

read more see 26 comments

Can BGP Route Reflectors Really Generate Forwarding Loops?

TL&DR Summary: Yes (if you’re clumsy enough).

A while ago I read Impact of Graceful IGP Operations on BGP – an article that described how changes in IGP topology result in temporary (or sometimes even permanent) forwarding loops in networks using BGP route reflectors.

Is the problem real? Yes, it is. Could you generate a BGP RR topology that results in a permanent forwarding loop? Yes. It’s not that hard.

read more see 9 comments

Could you run an MPLS-TE-only MPLS/VPN network without LDP?

One of my readers sent me a surprising question: “We run only LDP in our MPLS network and need to run RSVP for TE and then phase out LDP. How could we do it?

My first reaction was “Why would you ever want to do that” and I got no reasonable answer (suggestions, anyone?) but let’s focus on “Could you do it?

TL&DR summary: You could, but that doesn’t mean you should.

read more see 8 comments

Edge Protocol Independence: Another Benefit of Edge-and-Core Layering

I asked Martin Casado to check whether I correctly described his HotSDN’12 paper in my Edge and Core OpenFlow post, and he replied with another interesting observation:

The (somewhat nuanced) issue I would raise is that [...] decoupling [also] allows evolving the edge and core separately. Today, changing the edge addressing scheme requires a wholesale upgrade to the core.

The 6PE architecture (IPv6 on the edge, MPLS in the core) is a perfect example of this concept.

read more see 3 comments

Edge and Core OpenFlow (and why MPLS is not NAT)

More than a year ago, I explained why end-to-end flow-based forwarding doesn’t scale (and Doug Gourlay did the same using way more colorful language) and what the real-life limitations are. Not surprisingly, the gurus that started the whole OpenFlow movement came to the same conclusions and presented them at the HotSDN conference in August 2012 ... but even that hasn’t stopped some people from evangelizing the second coming.

read more see 10 comments

Secondary MPLS-TE Tunnels and Fast Reroute

Ronald sent me an interesting question: What's the point of having a secondary path set up for a certain LSP, when this LSP also has fast-reroute enabled (for example, with the Junos fast-reroute command)?

The idea of having a pre-established secondary LSP backing up a traffic engineering tunnel was commonly discussed before FRR was widely adopted, but should have quietly faded away by now.

read more see 8 comments

OpenFlow and Ipsilon: Nothing New Under the Sun

I’d promised to record another MPLS-related podcast and wanted to refresh my failing memory and revisit the beginnings of Tag Switching (Cisco’s proprietary technology that was used as the basis for MPLS). Several companies were trying to solve the IP+ATM integration problem in mid-nineties, most of them using IP-based architectures (Cisco, IBM, 3Com), while Ipsilon tried its luck with a flow-based solutions.

read more see 3 comments