[HN Gopher] Was MPLS Traffic Engineering Worthwhile?
___________________________________________________________________
Was MPLS Traffic Engineering Worthwhile?
Author : signa11
Score : 55 points
Date : 2023-04-03 16:32 UTC (6 hours ago)
(HTM) web link (systemsapproach.substack.com)
(TXT) w3m dump (systemsapproach.substack.com)
| zakki wrote:
| Curious, is Karpathy in MPLS the same Karpathy in current AI
| tech?
| great_wubwub wrote:
| Huh? What Karpathy are you talking about?
| kstrauser wrote:
| Sounds like it's time for my periodic re-reading of "Netheads vs
| Bellheads" (https://www.wired.com/1996/10/atm-3/).
| tushar-r wrote:
| For Cisco? Yes! :-P
|
| (Though, after 3 years of QA'ing the stuff, I gave up on MPLS and
| moved to other technologies. I was just not able to understand it
| to the deep level I wanted to.)
| great_wubwub wrote:
| I always broke MPLS-TE into two categories - traffic engineering
| for bandwidth, and fast reroute (FRR).
|
| Bandwidth engineering, like Bruce said, was religion for some
| people and anathema for others. It saved at least one company
| from bankruptcy, letting them run the network they had much
| hotter than IP would have.
|
| FRR, though, was an absolute game-changer. Local protection to
| failure and sub-50ms (often sub-10ms) protection switching in an
| IP network? Immensely valuable. Link connectivity protection was
| easy to deploy and I will argue made a massive difference in an
| Internet network's ability to provide real-time services in the
| face of failure. Node protection and bandwidth protection? Less
| so. But MPLS-TE-based FRR was the first local protection
| mechanism that didn't require you to have a specific topology and
| which could cover 100% of all connectivity failures.
|
| I'm surprised Bruce didn't call out this distinction, because
| they really are two separate things using the same underlying
| tech.
| drbruced wrote:
| Saving it for another post. It is actually just as
| controversial as there was a lot of work to improve convergence
| times in standard IP routing at the same time.
| nu11ptr wrote:
| There is no doubt FRR had value, but like all tech, there was a
| complexity that came with it, so it really only made sense for
| certain applications. Heavy voice/video networks were a no
| brainer, but other TCP-based applications that were less
| sensitive were of less value, esp. as IGP convergence improved.
| great_wubwub wrote:
| Yeah, for sure. I'm not saying FRR was always the right
| answer for all questions, but for a good decade or more it
| was a pretty solid choice, and particularly with auto-tunnel,
| it was easy to do. RSVP was far too complex a hammer for just
| FRR, and I like SR-LDP for FRR now, but from maybe 1998 (?)
| to 2015 (?) MPLS-TE FRR was the best tool we had.
| zuzatm wrote:
| There is some extremely nice 2018 research paper on new routing
| paradigms that seems to be blowing out older stuff, and that is
| only possible because MPLS exists. The NSDI paper is linked
| below.
|
| https://www.usenix.org/system/files/conference/nsdi18/nsdi18...
|
| I guess it makes sense why the article says how it is central in
| Google's / Microsoft's network architecture to achieve
| performance gains.
| nsteel wrote:
| I had always assumed MPLS (and the even more hideous, SRv6) were
| designed by software engineers. If you are designing a hardware
| network processor, traversing a variable stack of labels at line-
| rate is pretty horrible.
| bcrl wrote:
| Eh? Each hop only looked at the outermost label, keeping it,
| doing a push or a pop. The label namespace is small, which made
| it possible to use it directly as an index into a small SRAM to
| do a lookup and determine what the next hop is. That's how MPLS
| made line rate possible at a time when there wasn't enough
| space on silicon to do full IPv4 route lookups. It was very
| much a design driven by hardware requirements for how to do
| hardware line rate forwarding with limited resources.
| nsteel wrote:
| Correct, the (dumb, cheap) devices within the network have an
| easy time. The devices on the edge can have a lot of work to
| do, potentially popping multiple labels. And then there's a
| bunch of meta labels that have other meanings (I'm not
| actually sure if those are standardised or not).
| bcrl wrote:
| Edge routers already have to cope with adding and removing
| arbitrary sized headers (just look at tunneling protocols
| like IPIP, L2TP or the more modern VXLAN), so it's not like
| MPLS with multiple labels is a new requirement for the data
| path. And it's only at the originating site that you have
| to push multiple labels onto a packet -- the receiving end
| should only have to pop at most 1 label off as the
| transport network would consume the rest. I had to
| implement a software MLPS data path once upon a time maybe
| a decade ago.
|
| I've also written some Verilog code for adding and removing
| headers on packets on FPGAs. Once you have to support VLANs
| in hardware, you're already half way towards inserting an
| arbitrary number of bytes into a packet as higher data
| rates in FPGAs mean wide busses with all the corner cases
| of packets being aligned at various offsets into a 256 bit
| or 512 bit data path. Figuring out how to implement an
| ethernet CRC32 block that meets timing in a Kintex 7 was
| certainly fun!
| noselasd wrote:
| It's the oposite, trying to route or switch on variable length
| prefixes(as you would with IPv4 or V6), is pretty horrible to
| do in hardware, thanks to CAM it's atleast doeable. Route or
| switch directly on MAC addresses is ok, but creating policies
| becomes painful as there's no hierarchy.
|
| With MPLS, you get simple fixed length headers with single
| integer values is quite easy to push/pop and look up in
| hardware, and you can have software to generate the policies
| and manage hierarchies, placing the complexities and hard work
| at the MPLS edges, and having simple/dumb (aka. cheap) devices
| in the core.
| quercusa wrote:
| It's always a good time to re-read the Saltzer, Reed, and Clark
| _End-to-End Arguments in System Design_ paper. "A too-real
| example" triggers a certain degree of paranoia.
| aaronbrethorst wrote:
| Darn, I was really looking forward to a discussion of car culture
| and public transit in the Twin Cities. e.g.
| https://www.strongtowns.org/journal/tag/Minneapolis
| craigching wrote:
| I honestly thought it was going to be something cool about
| routing automobile traffic in the Twin Cities as well!
| betaby wrote:
| Yes! However LDP and and especially RSVP weren't. Thankfully with
| Segment Routing and PCE it's kind of solved problem now.
| great_wubwub wrote:
| LDP gave us BGP-free cores. Don't underestimate how much that
| changed the game in large networks. BGP converged faster and
| core routers didn't need to do anywhere near as much. SR is a
| better way to do that now and LDP/IGP sync was a huge pain, but
| IMO BGP-free cores changed the SP game as much as route
| reflectors did.
|
| LDP also enabled L2VPN and was an IGP-bound mechanism to enable
| MPLS VPN, which was always the killer app for MPLS.
|
| LDP by itself? Meh. But it opened up a whole lot of other
| possibilities.
| craigching wrote:
| What are all these acronyms? I read the first paragraph but it
| really doesn't give much context if you're an outsider.
| tushar-r wrote:
| https://www.rfc-editor.org/rfc/rfc3031#page-6
|
| or if you'd prefer wiki -
| https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching
| nu11ptr wrote:
| Here you go - it might not help much, this is a pretty
| specialized field of network engineering. If you were in a
| service provider, you were likely aware of this tech
| otherwise probably not at all.
|
| From my head:
|
| LDP = Label Distribution Protocol
|
| RSVP = ReSource Reservation Protocol
|
| PCE = Path Computation Element
|
| BGP = Border Gateway Protocol
|
| L2VPN = Layer 2 Virtual Private Network
|
| IGP = Interior Gateway Protocol
|
| MPLS = Multi Protocol Label Switching
|
| TE = Traffic Engineering
|
| FRR = Fast ReRoute
|
| SR = Segment Routing
|
| SP = Service Provider
| kazen44 wrote:
| im my opinion, segment routing is more complex then a proper
| RSVP implementation.
|
| running a PCE also adds a massive failure domain compared to
| the decentralised nature of RSVP.
|
| Does RSVP have a million bells and whistles? yes. Segment
| routing also has a billion different bells and whistles, and
| those are far less mature.
___________________________________________________________________
(page generated 2023-04-03 23:01 UTC)