Re: [mpls] Concerns about ISD

[Tianran Zhou <[e-mail]>]

Hi Tony,

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.

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.

For the other issues, you still cannot address my concerns, although you disagree.

Best,
Tianran


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


Hi Tianran,

The readable label stack depth has long been a concern. Nothing about MNA is specific to any given piece of hardware.

ZTR> I did not see an RFC specifies the number of readable label stack (e.g. 4? 6?). Hardware varies and can keep evolving. The protocol should work on one direction, so that the hardware can keep optimizing on that direction. I did not ignore the requirement for on-path action.


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.


To me, the entropy label is 20 random bits that one system adds at the start of the LSP. While it occupies a label field in an LSE, it is in no way a label. Specifically, it is not an index that a system uses for a lookup in its LFIB.  In other words, it’s opaque data, use solely for systems that need to load balance. ISD is certainly more opaque data. The functionality is, of course, different.  Using MNA is, of course, optional.

ZTR> Entropy label could be opaque data. Because, we do not actually parse the label field. However, ISD is not. It’s certainly not “more opaque data”, devices need to parse and process the label field.  And I think you mixed the requirement for on-path action and ISD.
The on-path action is required, and of course optional, people can choose whether to add or not. However, ISD is one implementation, all we discussed are whether we need such a special implementation, while there is PSD.


I’m sorry, I’m not following your point here.



Welcome to the IETF. We do real engineering. It’s not always elegant. :)

ZTR> That sounds like any code could be IETF standard. I see the real engineering is the parser cache keeps growing. I see the real engineering is consistent/standard MPLS label operation is hardened in AISC for better performance.


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.



Devices that cannot upgrade their code will not be able to support any form of MNA. Is this somehow worth debating?

ZTR> My point is about backward compatibility. PSD gets better backward compatibility than ISD.


I strongly disagree.  Putting everything in PSD makes it impossible for devices with limited readable label stack depth to participate effectively.


Looping or recycling through a forwarding engine can cause a major performance hit (50% or more). Folks would like to avoid that.

With SR, you can have much deeper stack depths. That can cause a big difference in access times.

I don’t follow the rest of your argument. You seem to be implying that other vendors should simply give up. Somehow, I think that unlikely. :)

I expect that devices that can support MNA will try to support MNA. It is to our collective advantage (there goes my altruistic streak again) to get MNA deployed and to help network operators get as much value from MNA as possible. Asking an operator to discard even a tiny portion of their hardware is unlikely to result in any kind of progress, only hindering MNA.

ZTR> So you agree ISD is designed for some legacy hardware. I argue that ISD will introduce more code and complexity, while PSD can do on-path action. And it will not reward people to implement PSD, hence hinder the on-path action. I argue that ISD will introduce backward compatibility issue, while PSD can support the incremental deployment. Hence PSD is helpful for operators to deploy on-path action in their network for new features. Vendors can do private ISD implementations for some legacy devices. However, I do not think the community should waste energy on ISD standardization.


I disagree and I think it’s time that we just agree to disagree.

Tony