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

Tony, inline

From: Tony Li <[email protected]> on behalf of Tony Li <[email protected]>
Date: Thursday, 31 March 2022 at 20:34
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email protected]>
Cc: Greg Mirsky <[email protected]>, detnet WG <[email protected]>, mpls <[email protected]>, [email protected] <[email protected]>
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

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.

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

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.

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

Regards,
Tony

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