Hi Roland, The problem is not just about known options here, like I mentioned earlier. A structure where there is a list which needs to be walked serially and no fixed place for an information, it is bad for the fast path.
I have mentioned cases for how bad it can get for IPv6. One good thing IPv6 does is it defined the order of options. If we want to process connex or some particular option, we could process it. However there may need to be some assumptions like, the option is the first in the list of options or any such thing. Thanks, Vishwas On Fri, Feb 4, 2011 at 4:21 AM, Roland Bless <[email protected]> wrote: > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
