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 arbitrary depth? Because why would the buck stop at the UDP header when transport has moved one layer up?
What is the status of the flow label in practice? As I said earlier in
the thread, I know the five tuple is trusted for ECMP, but I hear very
little discussion of the flow label being a trusted source of entropy to
feed the ECMP selector.
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…
That seems a fundamentally bad idea. Why would you go out of your way to
make something difficult when you never know what path future protocol
development will take you?
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”.
I think I have been describing the Internet architecture as it exists
today regardless of the what the RFCs say.
- Stewart
Cheers,
Ole
