Re: [mpls] Concerns about ISD

[Tianran Zhou <[e-mail]>]

Hi Tony,
Thanks for your reply and good to know you thoughts.
However, what I see the ISD is a specific optimization for specific hardware.
I do not think we should standardize such a solution.

Please see my reply in line for detail.

Best,
Tianran.

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


Hi Tianran,

Thank you for your opinion.


I followed the discussion in the mailing list for a while,  and read all the proposed solutions.
As I see some proposals mentioned about ISD, I do not think we really need it.
The only reason I see is the lower parsing depth.
However, the complexity we add to the implementation and the backward compatibility issue is a disaster.

Let's see some concerns:
1. ISD breaks the MPLS stack. It's very different from existing implementations. Different label processions are required for the whole stack.


The precedent, of course, is the Entropy label, which is effectively ISD.

ZTR> I do not think this is a good example. Firstly, entropy label is still an MPLS label, but ISD is not, with very different process. Secondly, RFC6790 indicates the in stack process of entropy label is optional. That said, this is only for specific hardware.

2. ISD has constrained space and format. For example, the s bit is reserved to not use. This will fragment the data space. Hence introduce a lot of complexities on the parsing, processing, encoding, hence damage the flexibility and extensibility.


Working around the s bit is certainly annoying and time consuming, but is not unduly complex. If your implementation is motivated to concatenate around the s bit, then two mask operations, a shift, and an or operation will give you contiguous bits.
ZTR> Of cause, anyway you can implement. But not elegant.


3. Pop the entire ISD within a lsp/sr-path is a very different procession to existing implementation.


Yes, the code will have to change. Adding functions requires new code.



4. ISD itself will increase the depth of the label stack. Several ISDs encoded in the label stack will severely impact the payload efficiency.
5.  If ISD carries any field that can change en route, it will impact the ECMP hash.


That’s implementation specific. An implementation is not required to use the entire stack in doing an ECMP hash.  You could just hash on embedded entropy labels.
ZTR> But there are different implementations to do hash. You do not know the device in the network, if they can change code or not. This will course backward compatibility issue.


6. ISD cannot replace PSD. If we can achieve with only PSD with one piece of code, I can find no reason to implement both ISD and PSD.


As you note, the advantage of ISD is that it lowers the parsing depth. Pushing everything to PSD causes a major performance hit if relevant data is past the readable label stack depth.
ZTR> As you note, anyway you can implement, even the parsing buffer is low, you can loop or cache twice for PSD. But let’s see further on the ISD use cases. For MPLS/LSP, the normal case is two or three labels. There is no big difference on in stack or post stack. For MPLS-SR, the path is programmable. And PSD could be ignored by node not support. On the other hand, if the device is resource constraint, with limited parsing buffer or so, I do not think it should even consider the ISD for programmability. Especially, ISD will introduce complexity on the constraint device.

In all, my design philosophy is simplicity. However, ISD breaks the elegant MPLS label stack.
I would strongly object to ISD.


Thank you for commenting,
Tony