Re: [mpls] Concerns about ISD

[Tony Li <[e-mail]>]

Hi Haoyu,

> You said ISD is “necessary” but my opinion is quite opposite. I think it is unnecessary and even harmful. For all the use cases you mentioned, I don’t see why they can’t be realized in PSD if they ever need any data. And as Robert pointed out, not all these use cases are suitable for data plane implementations. They need to be examined one by one with detailed requirement and cost analysis.


Well, you’re welcome to your opinion.  Not everyone shares it. In fact, some of us think the exact opposite.  Putting data in PSD unnecessarily is a major performance hit.

Continually repeating yourself is not in the least bit convincing and does not move the discussion forward.


> ISD is a significant departure from the current MPLS architecture and mechanisms. It’s basically a redesign of MPLS. It encodes new headers in “MPLS labels”. It unnecessarily limits new header’s size and format in order to fit the new header under the constraints of MPLS label format. It worsens both the parsing cost and performance by multiple times. Given so many negative effects, I see no point to support ISD.


As we’ve noted repeatedly, yes, we are adding functionality to MPLS. New functionality requires change.  


> The extension to MPLS should take the least intrusive path and conform to the established methods. If there are hierarchical tunnels in the MPLS label stack, it can be partitioned to multiple stacks (i.e., a stack of stack) and each stack can have its own PSD following it immediately. Without needing to invent new label handling method, this approach can mitigate the parsing depth concern.


I know of no existing case where there is PSD in a hierarchical label stack, so what you’re proposing here does not conform to ‘established methods’ and it’s effectively recreating ISD.

Tony