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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
