Re: [mpls] Concerns about ISD

["Dongjie (Jimmy)" <[e-mail]>]

Hi Tony and Tianran,

Please see some observations about this discussion inline with [Jie]:

From: mpls [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.

[Jie] IMO one of the difference between entropy label and ISD is whether the format of the label field, the TTL field and TC field are redefined or not. This will impact the parsing and processing implementation of network nodes. And concatenation of multiple fields in the same or different LSEs would be a very different behavior from the existing MPLS label processing.


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.

[Jie] For backward compatibility, one thing to consider is the risk of ISD being exposed at the top of label stack on the legacy nodes, which may be misunderstood as forwarding labels.


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.

[Jie] This shows that further hardware analysis is really needed. We’ve had some discussion about the hardware-friendly design principles, and the comparison between the optional encodings in terms of processing complexity and overhead.

I hope at least we can agree that MIAD or MNA requires new functionalities, then it would be helpful to understand what can and cannot be done with legacy hardware, what would be the requirements to new hardware, and hardware people’s feedback about these requirements.

Best regards,
Jie


Tony