Hi, Christopher Morrow wrote: > My feeling is this: > hop-by-hop processing will happen in slow-path (if you permit it to > happen at all), you can't build a router today with an asic that'll > know how to handle options which are created in the future :(
while the latter is surely true, I don't think that this argument precludes to implement fast path processing of at least _some_ HbH options. I think that the current implemented strategy to simply pass all HbH options to the slow path CPU is broken. I'm not sure whether it is feasible, but couldn't the Fast Path (ASIC) at least check for: - known options to be processed in the fast path, e.g., some CONEX info field - known options to be processed in the control plane, i.e., punt packet to control path (slow path CPU), e.g., some to intercept packets with a specific router alert option - bypassing unknown options (depending on the specified actions) in the fast-path So some (not all) _basic_ header extension processing code should be down in the fast path (like forwarding of non-supported or "non-interesting" hop-by-hop options) while more complex processing can surely stay up in the slow path. I have the impression that we will sacrifice the possibility of future useful IPv6 extensions due to some existing implementation limitations. Regards, Roland -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
