Pascal, Comments in line.
On Thu, Nov 11, 2021 at 10:58 AM Pascal Thubert (pthubert) <[email protected]> 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, [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
