Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Hi Greg,

I agree that hardware does advance faster than we can standardize protocols, but there is still a distinction between good design and bad design. While tomorrow's hardware advance may make bad design 10x better than today's good design, it's quite possible that it can also make good design 20x better. Thorough evaluation and then sticking to good design are mandatory to our engineers.

Regards,
Haoyu
From: mpls <[e-mail]> On Behalf Of Greg Mirsky
Sent: Monday, April 11, 2022 7:47 PM
To: Tianran Zhou <zhoutianran=[e-mail]>
Cc: [e-mail]
Subject: Re: [mpls] Concerns about ISD

Tianran, Tony, and Jie,
thank you for a lively and helpful discussion. I believe it is good to lay our assumptions on the table, check what is real and what is not so much.
To me, both ISD and PSD are essential elements of MNA. I expect that there will be lots of considerations, discussions and arguments around where a particular MNA will have its associated data - ISD or PSD. And, as the case with ELI/EL, there will come necessary extensions to routing protocols and corresponding YANG data models. In my view, the new MPLS data plane must be accompanied with extensions in the control and management plane.
To summarize my position, it seems that constrains of available today HW must be considered but should not prevent us from defining a more powerful, flexible new MPLS architecture. As our common experience has demonstrated again and again - HW advances faster than we can standardize protocols. I view architectural optional capabilities as an opportunity to realize a new functionality, for example on-path telemetry like IOAM, but only when when that does not affect the main goal of the network - efficiently forward data flows. that seems as an obvious, and I believe that the MNA framework and requirements documents express it clearly. We only need to follow them.

Regards,
Greg

On Mon, Apr 11, 2022 at 7:08 PM Tianran Zhou <zhoutianran=[e-mail]<mailto:[e-mail]>> wrote:
Hi Tony,

Please see in line.

Best,
Tianran

From: Tony Li [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tony Li
Sent: Monday, April 11, 2022 11:35 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Concerns about ISD


Hi Tianran,


Please see RFC 9088 and 9089.
While hardware continues to evolve, as we've discussed previously, we really want to try to maximize the value of the hardware that's already in the field. That's in  the operator's best interests and thus in ours as well.

ZTR> I quickly go over this two RFCs. I did not see any limits on the number of readable labels. On the contrast, it allows devices with different capabilities. By using the flooding and notification mechanism, the controller or so knows the capability of each device, hence easy to program the stack on the head node.


Exactly.  This exists because there is a need to understand the readable label stack depth (RLSD) and operate within it.  RLSD is important for interoperability and pushing everything to PSD would hinder interoperability. People did things this way for a reason. It makes sense for us to continue to do so.

ZTR2> PSD can work with RLSD, I cannot see how it will hinder the interoperability.
I see hard coding an ASIC as a poor choice. But I've only been saying that since 1996. :)  All of the silicon that I've had a hand in has been microcoded for exactly this reason, with very little penalty.

ZTR> I disagree. New chips are combination of AICS part and microcode part. Microcode is for changes and flexibility. But ASIC is for performance.

Ok, clearly we operate with different silicon technology.

In a related matter, it does occur to me that if you dislike ISD, you are free to take any sub-stacks that you want to inject and push them to the bottom of the label stack. This would effectively push all of your ISD just above PSD, effectively doing the same thing as doing everything in PSD.  Of course, this would minimize your interoperability.  Other devices would be able to use MNA through your device, but you would not be able to send MNA through them. If this is what you want, we won't stop you.

ZTR2> Of course I would not put ISD just above PSD. As PSD can provide all the functionalities, I do not see the reason why we need ISD anymore. Entropy label is a simple one, community chose to implement the in stack operation <optionally> as in RFC 6790. For ISD, I would not expect it to split the community effort. You can implement any fascinating ISD design privately, we won't stop you. But I do not think we need any IETF standard on ISD.

Regards,
Tony


_______________________________________________
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%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C63859641e33c401a5ec408da1c2ed8e9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637853284800900578%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M3PJMkwtXo1TArtRKtewxvwMGuEK%2F2IkvdkAA4AUzKE%3D&reserved=0>