Re: [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
Tony Li <[email protected]>
| Newsgroups | gmane.ietf.pwe3,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
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. 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 _______________________________________________ Pals mailing list [email protected] https://www.ietf.org/mailman/listinfo/pals