Hi Tom, Yes, to all.
My sentence was the conscious part of my +1 above in support of your work. The values, whatever they are, must be adapted to dev cycles (over multiple years) and could be defined with a roadmap to increase over time. Regards, Pascal > Le 11 nov. 2021 à 20:19, Tom Herbert <t...@herbertland.com> a écrit : > > Pascal, > > Comments in line. > >> On Thu, Nov 11, 2021 at 10:58 AM Pascal Thubert (pthubert) >> <pthub...@cisco.com> wrote: >> >> +1 . >> >> To Ole that without a good use case in a limited domain it’s hard to expect >> implementation. >> > Unfortunately, TLVs weren't interesting enough when the protocol was > defined so now we have a lot of deployed hardware that couldn't > support them even if they wanted. There are two things that give me > hope for the future in that regard: 1) The emergence of programmable > hardware datapaths may eventually limit the need for hardware swap out > everytime someone wants to support a new protocol 2) TCP has always > has TLVs as a core part of the protocol, as hardware implementation > move up the stack they are going to need to deal with TLVs (like it > someone wanted to build a high performance NVMe/TCP stack in > hardware). > >> To the point that the HbH must remain simple to operate and very short, same >> spirit as already demonstrated with SRH. >> >> We’re in a weird situation with arbitrary limits in vendor silicon because >> the IETF failed to give clear directions on EH sizes. >> >> It would be neat to provide a roadmap of how long the minimum EH size to >> parse should be so the IETF can design things that can be later implemented >> by the vendors. > > That is precisely the intent of > https://tools.ietf.org/id/draft-herbert-6man-eh-limits-00.txt :-) > > Tom > >> >> Regards, >> >> Pascal >> >> Le 11 nov. 2021 à 18:34, otr...@employees.org a écrit : >> >> Tom, >> >> [...] >> >> I think you're dancing around the core problem. Hardware >> >> implementations didn't support Hop-by-Hop options because they contain >> >> TLVs which are considered to be hard to process in a high performance >> >> datapath hardware pipeline. RFC2460 did mandate that all intermediate >> >> nodes need to process the HBH options which left hardware vendors with >> >> three choices: 1) process them in a software slow path and adhere to >> >> RFC2460 2) ignore them altogether and violate RFC2460 3) drop the >> >> packet which technically adheres to RFC2460, but obviously kills any >> >> utility of feature. RFC8200 relaxed the requirement for all nodes to >> >> process HBH options and acknowledged that this is reality. From an >> >> application perspective, if the TLVs can't be processed in a "fast >> >> path" it is best to ignore the options. >> >> >> I mostly agree with your reasoning. >> To add some more nuance. The only TLV that existed was Router Altert for >> MLD, and that was a signal to send the packet to the control plane. >> I think the reason HBH isn't implemented in hardware is because there aren't >> any options in existence. Until quite recently. >> And those mainly apply in a limited domain. >> >> If a transit network supported some specific forwarding behavour triggered >> by the HBH option, it would be highly unlikely that it would allow arbitrary >> end-users to use that function. >> >> To conclude. HBH hasn't been implemented in hardware because there hasn't >> been a use case. >> >> Cheers, >> Ole >> >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
