Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

[[e-mail]]

Tom,

> This is not the way it works for *every* middlebox on the planet. For
> instance, in Linux we can deduce a flow hash from ports-- not just for
> TCP and UDP but for SCTP, DCCP, UDP-lite, etc.--, GRE key ID, MPLS
> entropy label, IPv6 flow label, SPI in AH and ESP, parse over
> extension headers, and also can parse into several encapsulation
> protocols to find L4 information (GRE, IPIP, IPv6/IP). See
> http://lxr.free-electrons.com/source/net/core/flow_dissector.c#L121.
> 
> Even if I accepted that we are pragmatically limited with only ever
> using TCP and UDP without extensions headers on the Internet, I will
> never accept these as constraints in my private networks! We are and
> will using other IP protocols, encapsulation, EH, etc. IPv6 flow label
> is therefore a general solution; it works with any IP protocols we
> might use, extension headers, etc., it is straightforward to add into
> hash computation in devices. With the flow label, none my fabric
> switches need to parse beyond the 40 byte IPv6 header in order to
> provide ECMP.
> 
> Most of the arguments against extension headers seem to be because
> they are difficult to parse, however the point of using flow label is
> that it eliminates the need to parse extension headers in the first
> place for the ECMP use case. It would be nice if this benefit was and
> the need for flow label support were better enunciated in the draft.
> IMO any opportunity we have to get intermediate devices to do less
> deep packet parsing without loss of functionality is a good thing!

Fully agree. Wouldn't it be nice.
I don't see how this particular draft helps here though.

Best regards,
Ole