Hi Brian, > To what extent is this behind the present argument?
If you are calling elephant and ASIC/FPGA - that was not my reasoning at all. Regardless if you are processing packets by a fixed burned ASIC or programmable NP the packet must be read into DRAM and its header stored in SRAM during processing - that is I hope pretty clear to everyone. What matters is the amount of SRAM you have at your disposal and then how far apart are elements required for processing a given feature. I am full supporter of NPs and actually just fyi in my MS thesis I designed and prototyped Altera MAX FPGA based router :). If one can afford for required line rate speed rating and total box throughput using NP based systems is much better investment. This is more for flexibility (field programmability) and software updates for bug fixes and new features then anything to do how we should or should not design the packet headers in data plane protocols. In the comment below I was not really making an observation that when you separate multiple DOHs from CRH you can not process things - you sure can as all such EHs actually carry opaque to each other elements. I was however observing the fact that functions may require parameters which are not supported by DOHs as well as observed earlier that if you are to make sure packets entering your domain or leaving "escaping" your domain contain any unexpected headers it is much easier to set such ACL onces instead of keep updating it every time new draft gets published and new type gets allocated for another SRv6+ Destination Option. Many thx, Robert On Fri, Sep 13, 2019 at 12:32 AM Brian E Carpenter < [email protected]> wrote: > Robert, > > > But what is most important that common hardware reads just entire > > header then starts processing. So it really makes much more sense to > > encode SR SIDs and related functions and their parameters in the same > > EH rather then scatter them around. > > Sorry to get all philosophical, but it seems to me that there's another > elephant in the room here (and he's been around for twenty years or so). > There seems to be an assumption that we should design on the assumption > that fast path processing is done by ASICs or FPGAs, so header formats > should be rigid enough that conditional or linked-list processing can > be largely avoided. I've been lectured on the bad design of IPv6 extension > headers in a way that only makes sense from an ASIC or FPGA viewpoint. > > But anybody who's building the fast path using a network processor doesn't > have that constraint and can use the existing extension header design > happily enough. > > To what extent is this behind the present argument? > > Regards > Brian Carpenter
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
