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

[[e-mail]]

Tony, all

I realize that your subsequent email was already covering my minutes ago reply. Sorry for the spam, I was replying by emails in order after a long day of work.

> Well, I would appreciate hard data.

So am I.
But clearly vendors are never disclaiming their hardware limitations. In my experience, a very limited set are disclosed privately when the hardware limitations become undefendable by the vendor, and under strict NDA.
I personally don't find credible that we would have public knowledge of such data.

This email is a public call to all vendors: if you are ready to privately fully disclose the limitation of your forwarding silicon, I'm ready to take the time for the discussions (and reading the written data). (Actually, I'm pretty sure that my employer would even pay me for that time)
Obviously, if you are also ready to share publicly, you are very welcome to do so by replying to this email.

Regards,
--Bruno



Orange Restricted
From: mpls <[e-mail]> On Behalf Of Tony Li
Sent: Thursday, March 31, 2022 10:41 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>
Cc: detnet WG <[e-mail]>; [e-mail]; mpls <[e-mail]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)


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



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.