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

[Tom Herbert <[e-mail]>]

On Sun, Mar 13, 2016 at 12:52 PM,  <[e-mail]> wrote:
> Tom,
>
>>> - Parsing EHs is and the consequence of having to walk the extension header chain is a well known problem.
>>>  If the premise is that we want this to work well for arbitrary middleboxes, the solution space is empty.
>>> - HBH headers is a well known problem. One draft in 6man as well as changes in 2460bis.
>>> - The ECMP problem is well known. We tried to solve it with flow label, in practice the IP header has evolved to be 24 / 44 bytes respectively.
>>
>> Where are these 24 / 44 byte IP headers described?
>
> in every router / middlebox on the planet. (and somewhat tangential for any RFC describing shared IPv4 addresses)
>

Ole,

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!

Tom

> e.g (from VPP):
>
> /* Compute flow hash.  We'll use it to select which Sponge to use for this
>    flow.  And other things. */
> always_inline u32
> ip6_compute_flow_hash (ip6_header_t * ip, u32 flow_hash_config)
> {
>     tcp_header_t * tcp = (void *) (ip + 1);
>     u64 a, b, c;
>     u64 t1, t2;
>     uword is_tcp_udp = (ip->protocol == IP_PROTOCOL_TCP
>                         || ip->protocol == IP_PROTOCOL_UDP);
>
>     t1 = (ip->src_address.as_u64[0] ^ ip->src_address.as_u64[1]);
>     t1 = (flow_hash_config & IP_FLOW_HASH_SRC_ADDR) ? t1 : 0;
>
>     t2 = (ip->dst_address.as_u64[0] ^ ip->dst_address.as_u64[1]);
>     t2 = (flow_hash_config & IP_FLOW_HASH_DST_ADDR) ? t2 : 0;
>
>     a = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t2 : t1;
>     b = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ? t1 : t2;
>     b ^= (flow_hash_config & IP_FLOW_HASH_PROTO) ? ip->protocol : 0;
>
>     t1 = is_tcp_udp ? tcp->ports.src : 0;
>     t2 = is_tcp_udp ? tcp->ports.dst : 0;
>
>     t1 = (flow_hash_config & IP_FLOW_HASH_SRC_PORT) ? t1 : 0;
>     t2 = (flow_hash_config & IP_FLOW_HASH_DST_PORT) ? t2 : 0;
>
>     c = (flow_hash_config & IP_FLOW_HASH_REVERSE_SRC_DST) ?
>         ((t1<<16) | t2) : ((t2<<16) | t1);
>
>     hash_mix64 (a, b, c);
>     return (u32) c;
> }
>
> Best,
> Ole