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

Tony,

Please see inline [Bruno]



Orange Restricted
From: mpls <[email protected]> On Behalf Of Tony Li



Wim,



Now also we mix 2 discussions points in my view. One is backward compatibility and 2nd is leveraging current HW to support the extensions.
For me the 2nd is also very important as this is actually an important characteristic for the speed at which we can adopt solutions. If we can get extensions with the current HW this is a big pro of the proposals out there. This is why I am advocating to adopt Bruno's draft as it allows to leverage the existing HW assets as is. Of course we need to do a SW upgrade, but this is still faster than swapping HW is most cases.


Implicit in this is the assumption that a hardware upgrade is required. That is not at all clear. In fact, that runs counter to my understanding of what's in the field: almost everything out there has some level of microcode capability.

[Bruno] It's pretty clear that you have a better knowledge of hardware capability than I have. Partly because vendors do their best not to disclose (if not hide) their limitations.
However, my understanding is that all hardware have limitations and even by design as they are tradeoff involves. (again, you know better).
Yet from my perspective and from information I have:
- it seems clear that many if not all hardware have limitations with regards to the size of the stack they can impose and read. So pushing more bytes in the header is not for free. (e.g, pushing 20/32 bits for entropy and 20/32 bits for slice id is indeed more scalable but also more costly than pushing 20/32 bits for both slice ID and entropy.)
- somehow, I'm getting occasional feedbacks from vendors that my currently deployed platforms (including some still been sold so still up to date), can't be software upgraded to support the new dataplane feature (not qos related). (even though the same vendor is claiming that ias silicon is flexible, programmable, can adapt to new features, is futureproof, much better than the competition...). So probably, there are limitations or at least trade-offs. (and I don't think that I'm contradicting you as you said "some level of")

--Bruno

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.

In short, Bruno's draft offers us limitations that we want to avoid, and advantages that seem dubious.

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

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals