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]> Fri, 1 Apr 2022 10:12:27 -0700
Newsgroups gmane.ietf.pwe3,gmane.ietf.mpls
Message-ID <[email protected]>
Hi Bruno,

> 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.)


This is certainly true. However, this is wholly irrelevant to the selection of SPL to be used to indicate our sub-stack.


> - 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”)


I cannot speak to whatever feedback that you’re getting. There are always trade-offs. As we introduce new functionality, processing it typically requires more code space, more data space, and more cycles. Again, this is true across all proposals. And as such, without further hard data, it’s very hard to see how this impacts our choice of SPL.

Tony

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