Re: [mpls] Concerns about ISD

[Tony Li <[e-mail]>]

Hi Tianran,


> However, what I see the ISD is a specific optimization for specific hardware.
> I do not think we should standardize such a solution.


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


> 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. 


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. 


> 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.


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


> 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.


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


> 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.


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.

Regards,
Tony