Re: [mpls] Concerns about ISD

[Haoyu Song <[e-mail]>]

Thanks, Tony,

If you continue to read the indicator draft, you’ll find it may be possible to reach the EHs faster.
Even we don’t use that mechanism, the parsing latency is indeed linear to the label stack depth. But if you check the cost of parsing ISD, this can still be a better choice. Moreover, the stack of stack can help to reduce the label stack depth to reach the EHs.

For the EH encoding efficiency, I appreciate your input. Currently it follows the IPv6 EH type (i.e., using NH + LENGTH to delineate every EH). There could certainly be room for improvement.

Best regards,
Haoyu


From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Friday, April 15, 2022 11:09 AM
To: Haoyu Song <[e-mail]>
Cc: John E Drake <jdrake=[e-mail]>; Tianran Zhou <zhoutianran=[e-mail]>; [e-mail]
Subject: Re: [mpls] Concerns about ISD


Hi Haoyu,


Please take a look at our EH draft if you haven’t yet. The mechanism is there and the essence is that it doesn’t tamper the MPLS label stack and label semantics. That’s why I say PSD is least intrusive.


Thank you, I was unaware of it and have now looked at it.  If I understand it correctly, the EHI is the trigger to look for extension headers, all of which are in PSD.  Again, the parsing performance is a linear read to find the bottom of stack.

While it may be minimally intrusive to the label stack semantics, that doesn’t seem like a good trade-off for the performance penalty.

On a separate point, I have deep concerns about the encoding efficiency of the extension headers.  We can talk about this if and when it becomes relevant.

Tony