Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

[Tony Li <[e-mail]>]

Wim,

> WH> not all HW has this capability or is very constraint without another compromise. This is in my view an important consideration to select the proposal


Understood, but without clear evidence of these limitations, it’s somewhat hard to justify limiting our approach.  The commonality of the hardware in relevant locations is key.  

If we find that Brand X has hardware limitations and there are a million deployed throughout service providers everywhere, that is worth noting.

If we find that Brand Y has hardware limitations, but is only deployed in 10 home offices world wide, it is inconsequential.

As always, we have to make tradeoffs using the data that we have at hand.  


> If that’s accurate, then we are a software upgrade away, regardless of which solution we select. The true hardware limitations will arise as we define more complex actions, which require more data that is not readily accessible, either because there is too much in-stack data or access to the post-stack data that cannot be done without a performance penalty, if at all.
>  
> WH> I don’t believe this is true with what we have on the table right now and this is why restate to start with Bruno’s proposal to start and go to a more advanced solution that can be supported with new HW capabiltiies.


Well, I would appreciate hard data.  I have had a hand in MPLS since day one and have seen many hardware designs along the way. There are many hardware platforms that have limitations on label stack depth. That is definitely a concern, but that is already an issue for the entropy label today.  I’m unaware of any hardware implementation that cannot support the use of a different bSPL.  I welcome education, but without clear contradictory evidence, not just opinion or unsupported assertion, the data that I have suggests that we effectively have a small Turing-equivalent processor operating on some significant chunk of the label stack.

Tony