[mpls] Re: [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim

[Tianran Zhou <[e-mail]>]

I am confused. If we have a good hardware, why not to use a united and flexible PSD solution?
ISD+PSD looks like bizarre.

Tianran




________________________________

Sent from WeLink
发件人： Tony Li<[e-mail]<mailto:[e-mail]>>
收件人： Haoyu Song<[e-mail]<mailto:[e-mail]>>
抄送： Alexander Vainshtein<Alexander.Vainshtein=[e-mail]<mailto:Alexander.Vainshtein=[e-mail]>>;mpls<[e-mail]<mailto:[e-mail]>>
主题： [mpls] Re: [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim
时间： 2025-02-21 01:11:44


Hi Haoyu,

You are most welcome to your own definition of ‘good’ hardware.

History has shown that the cost of microcoded hardware is far less than an order of magnitude, and that the architectural flexibility far exceeds any performance issue.

T


On Feb 20, 2025, at 2:14 PM, Haoyu Song - haoyu.song at futurewei.com <[e-mail]> wrote:

Hi Tony,

The ASIC-based hardware is not “bad” hardware. It can offer an order of magnitude higher throughput than the NPU-based hardware at the cost of less flexibility. That’s why it’s gaining traction in the past few years. It’s all about the tradeoff and depends on the network requirements.

Best regards,
Haoyu

From: Tony Li <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Thursday, February 20, 2025 2:04 PM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Alexander Vainshtein <Alexander.Vainshtein=[e-mail]<mailto:Alexander.Vainshtein=[e-mail]>>; mpls <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] [EXTERNAL] Re: Fwd: Fwd: Re: Discussion points for upcoming MPLS WG interim

Hi Haoyu,


As you said, the microcode-based hardware has its limitation. Even if it supports the MNA function, it may not support the required forwarding performance.


That’s true, it may or may not.  Every box has some limitations.  An MNA action that requires you to compute Ackerman’s function of the input packet might take a really long time and you might not get wire rate performance as a result.

Supporting arbitrarily complex functionality in the data plane is always going to come at some cost.



There’s a reason why IP options and extension headers are often ignored, dropped, or punted to the slow path.


That reason is that no one cared.  Microcode requires careful development and investment. If no one cares to make that investment, it doesn’t happen.  That does not imply that it can’t happen, just that the market hasn’t provided a demand that motivates the supply.

Example: I once worked on a system that did not initially support IP fragmentation in microcode.  Almost no one cared. Then came along a media with a different default MTU (FDDI), and fragmentation became an important topic. A customer came along with a Really Big Check. We ended up adding microcode support for fragmentation.



Also, I see more and more service routers start to use ASIC as the forwarding chip for higher throughput performance. In this case a hardware re-spin may be needed to support MNA.


We have been building ASIC based forwarding since the mid 1990’s.  I have personal history with the Cisco GSR, Juniper M40, Procket 8812, and an Ericsson platform.  All of them were microcoded and Turing equivalent, generally employing a number of ALU’s on die.  None of them would have required an ASIC spin to support MNA.

The whole point here is clear: good hardware is very flexible. If there is a bug in ISD or PSD, then it is a microcode change, not a spin.

Yes, if you have bad hardware, you would need to spin.  The IETF does not make standards based on supporting the worst possible hardware.

Tony