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

[Stewart Bryant <[e-mail]>]

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