Re: [mpls] Concerns about ISD

Hi Kireeti,

As I said, hardware advance would benefit good design more than bad design. Also, Tony insists that the design should also be applied for today’s hardware. Therefore, we do need careful evaluation before making potentially costly decisions.

I have done my homework and formed my opinion. I presented it in details publicly and welcome feedback. If I'm proven wrong, I would be willing to adjust my stance. What I cannot accept is either one claims there is secret sauce that can't be revealed or simply claim the future hardware would solve all the problems. I believe in evidence but not speculation.

Best regards,

Haoyu

From: Kireeti Kompella <kireeti.kompella@gmail.com>
Sent: Wednesday, April 13, 2022 2:29 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tony Li <tony.li@tony.li>; Dongjie (Jimmy) <jie.dong@huawei.com>; mpls@ietf.org
Subject: Re: [mpls] Concerns about ISD

Hi Haoyu,
See inline.

On Apr 12, 2022, at 17:46, Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:

Hi Tony,

As I recall, Kireeti only gave a few words claiming

“claiming” :)

Yeah, no microcode. Sorry.

it’s easily implementable, while the other vendors (HW and Cisco) confirmed my analysis with their analysis documented in PPTs (specifically, the bitmap encoded ISD increases both parser size and parsing latency).
I believe detailed analysis based on the solid assumption (e.g., parse-able header depth) is needed to understand the tradeoff. After all, for both old and new hardware, we prefer simpler design for higher performance.

There are three things to keep in mind:

1) there wasn’t a detailed (public) analysis of how to implement MPLS when it was first proposed: where to put the BoS, TC, how many bits for the label, etc., based on existing hardware. That’s not the IETF approach. While we appreciate your detailed analysis, it is just one data point.

2) Hardware adapts. Parsing a three label stack was hard once. We are setting standards, not for today, but for the next decade, if not longer. Analysis based solely on today’s hardware is the wrong approach. Analysis based on hardware 10 years from now needs a crystal ball (mine is kaput). So, we use architectural principles as best we can.

3) I’m not saying no PSD, I’m saying do both. Each has its strongpoints. You’re saying, no ISD — that’s a very narrow viewpoint. (We do both today: ELI and CW.)

At this point, I’m done with this topic. It’s an exciting subject and lots of good debate. Chairs, how do we move forward?

Kireeti

Best regards,
Haoyu

From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Tony Li
Sent: Tuesday, April 12, 2022 7:14 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] Concerns about ISD

Hi Jie,

We have had two presentations of hardware analysis.

One on 3/10/2022 and another on 1/27/2022.  What more are you expecting?

[Jie] The analysis we had on 1/27/2022 and 3/3/2022 in the DT showed the overhead and complexity of ISD, and questioned whether ISD is needed or not. The analysis slides are attached in the DT meeting notes.

We are still missing equivalent hardware analysis from the proponents of draft-kompella-mpls-mspl4fa. Without that, it is hard to tell whether the proposal is implementable with existing or new hardware, and what would be the cost.

That was the presentation on 3/10.

As I recall, the result was that it was easily implementable, but the recommendation was to replace continuation bits with length fields.

T

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls