Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Hi John,

I’m a hardware guy and I’d like to discuss with your hardware experts on the design tradeoffs. You keep saying that you don’t believe my analysis so I really want to learn what’s wrong with it or which part you don’t agree with.
You can show them my slides to begin with. Thanks!

Best regards,
Haoyu
From: John E Drake <[e-mail]>
Sent: Wednesday, April 13, 2022 1:09 PM
To: Haoyu Song <[e-mail]>; Kireeti Kompella <[e-mail]>
Cc: [e-mail]
Subject: RE: [mpls] Concerns about ISD

Hi,

Comments inline below, indicated by [JD2}.

Yours Irrespectively,

John



Juniper Business Use Only
From: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 13, 2022 3:47 PM
To: John E Drake <[e-mail]<mailto:[e-mail]>>; Kireeti Kompella <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Concerns about ISD

[External Email. Be cautious of content]

Inline, thanks.

From: John E Drake <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 13, 2022 11:31 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>; Kireeti Kompella <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: [mpls] Concerns about ISD

Hi,

Comments inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Haoyu Song
Sent: Wednesday, April 13, 2022 12:38 PM
To: Kireeti Kompella <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD

[External Email. Be cautious of content]

Hi Kireeti,

As I said, hardware advance would benefit good design more than bad design.

[JD]  And that is for the working group to decide

[HS] Don’t you believe this claim? I don’t see why the WG can decide this. If you mean the WG should evaluate and compare different designs and decide which is better, then yes.

[JD2]  Ultimately, the WG will reach rough consensus on a design, based upon whatever criteria the individual WG members decide is important to them, in consultation with their
hardware experts.  I don’t believe that is possible to demonstrate that there is a single best design for all hardware designs/use cases

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.

[JD]  The problem is that you have presented how a single hardware design works and then asserted that all hardware designs work as you have described.  Members of the design team, myself included, don’t believe this

[HS] The parsing logic I described is general, regardless of hardware, software, or whether or not an explicit parser is implemented. It describes the common logic to understand what information is encoded. Please be specific what you don’t believe, I’ll try my best to explain further.

[JD2]  Kireeti has checked with hardware experts at both Juniper and Broadcom, and has found that those experts don’t necessarily agree with your conclusions.  As an aside, while not a hardware expert, I understand that parsing in not necessarily the most important aspect to consider

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.

[JD]  It’s not in your remit to evaluate these claims or to make a decision of which design to adopt.  What the process stipulates is that hardware designers will be asked whether a given design is easy or hard to implement but they are not required to explain their reasoning, the assumption being that they are answering in good faith

[HS] It’s not about easy or hard to implement, it’s about the tradeoff between performance, cost, flexibility, and extensibility. Unlike the control plane protocols, the design will run in high performance device data plane, so every clock tick counts. In this regard, “Easy” or “Hard” can be and should be evaluated based on a set of solid qualitative and quantitative criteria when we compare different schemes.  We should choose the best design to the best of our knowledge.

[JD2]  I don’t think this is true at all.  I don’t believe there is one best design for every piece of hardware that will implement MNA.  Rather, I think that we will reach some sort of compromise which is acceptable to a majority, as determined by the chairs.







Best regards,

Haoyu


From: Kireeti Kompella <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, April 13, 2022 2:29 AM
To: Haoyu Song <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD

Hi Haoyu,
See inline.

On Apr 12, 2022, at 17:46, Haoyu Song <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Tuesday, April 12, 2022 7:14 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fmpls__*3B!!NEt6yMaO-gk!TjXrzMCdH7mFLrbzEc4_NQ7dDL4LxwayKEfcbrhq3T7I0-I5uRVPZDO2fH0fHng*24%26data%3D05*7C01*7Chaoyu.song*40futurewei.com*7Ca882208f295949acdb9908da1d7bcc44*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637854714814416125*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3Dt6piKQSyz*2FOC5G6KaCu39MMqLdmVFvLqxfc2Zf3aTpg*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!SOyQ3gj9bkv5YOx_8jQ-_mk-MN3iD6-kGLEh0OVS196pctj8z0hwiUwoiT-kMgA%24&data=05%7C01%7Chaoyu.song%40futurewei.com%7Cda9d36909a9a4a9ec2c108da1d898371%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637854773728966684%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HQwcWaELit%2BFdy3jCFMwpnOX3tHret9Pp4WNaRlWRHE%3D&reserved=0>