On 6/12/18 10:36, Stewart Bryant wrote: > > > On 06/12/2018 11:42, Ole Troan wrote: >> Stewart, >> >>>>> If it has to look at any it has a much more complex set of tests, or a >>>>> large vector table given the way the EH space is fragmented. >>>> Frankly doing it without a network processor seems wrong. You can't >>>> expect >>>> an ASIC or FPGA based device to handle the EH structures. >>> Something that has served the IETF well over the years is not to >>> constrain the forwarding >>> implementation, and I think we would be wise to continue in that >>> mould. Also we need >>> to remember that an NP is an application specific processor, and thus >>> has various >>> hardware assists. >>> >>> No one talks about the internals of an NP, and I am not current on >>> any vendor's design, >>> but it is reasonable to suggest that in addition to the s/w parser >>> there might >>> be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of >>> expected type, dec >>> TTL and do what the TCAM say picking this ECMP option else parse it >>> the hard way. >>> >>> Then there is something that we do not talk at all about in such >>> designs: electrical power. >>> There is no question that it takes more power to s/w parse a packet, >>> and sooner of later >>> the power burn of the Internet is going to come under scrutiny, and >>> we will be asked >>> to reduce its carbon footprint. >> So you are arguing that we need to define ULPs that are easy for >> routers to parse? > I don't see how you would conclude that from the above. What is needed > is that whatever the parser needs to parse needs to be easy and cheap to > parse. At the end of the day, it ends up being the call of the folks running the net. -- see RFC7872. "I'm gonna make it hard for your to parse the packets" "OK, good. I'll just drop them. Good luck. Bye". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
