Re: [Tsv-art] ECMP [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

[Ole Troan <[e-mail]>]

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?
At arbitrary depth? Because why would the buck stop at the UDP header when transport has moved one layer up?

As opposed to the 6man argument which is that IPv6 is explicitly designed to only require routers to need to process the first 40 bytes (with the one exception hook).
And the design of EHs is specifically done to make it hard to parse for intermediate devices…

Is that really the Internet we want? Of course it will be countered with encryption, but I foresee a raft of problems if the IETF as a whole would redefine the “formal Internet architecture”.

Cheers,
Ole