Subject: ECMP and flow label

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 17:41:59 +1300

I may have not quite understood the comments about ECMP
and the flow label in 6man today. But here goes:

The flow label spec in RFC3697 says, very carefully and
precisely:

   IPv6 nodes MUST NOT assume any mathematical or other properties of
   the Flow Label values assigned by source nodes.  Router performance
   SHOULD NOT be dependent on the distribution of the Flow Label values.
   Especially, the Flow Label bits alone make poor material for a hash
   key.

This seems to be frightening people. The point is that, although we'd
like the flow labels to be widely scattered across the 2^20 possible
values, we can't be certain that arbitrary sources will generate that
with adequate randomness. Since we didn't know when we wrote RFC3697,
and don't know today, which end-to-end use cases for the flow label
will emerge, we can't make any mathematical assumptions about the
actual randomness. In fact, today, the average value of the flow label
is essentially indistinguishable from zero.

The key word in the above extract is "alone". If you want use a hash
to drive ECMP, don't just hash the flow label, because you'll very
likely always get the same answer.

If you currently use a 5-tuple for an ECMP hash, expand it to a
6-tuple by adding the flow label.

Section 1.2.5 of draft-fairhurst-tsvwg-6man-udpzero-00 says:

   An alternate method could utilise the IPv6 Flow Label to perform load
   balancing.  This would release IPv6 load-balancing devices from the
   need to assume semantics for the use of the transport port field.
   This use of the flow-label is consistent with the intended use,
   although further clarity may be needed to ensure the field can be
   consistently used for this purpose.  Router vendors could be
   encouraged to start using the IPv6 Flow Label as a part of the flow
   hash.

I think the fact is that you can usefully *add* it to the hash, in the
expectation that non-zero flow labels will appear in future, but
initially it will do nothing to improve the distribution of the
hash. So I think that the ports cannot be removed; the second sentence
above is wrong.

    Brian

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 10 Nov 2009 13:42:51 +0000

Brian,

I agree the draft should be updated on this point (and will reference 
RFC 3997).

I have two comments/questions:

1) The draft speaks about tunnel encapsulations, and therefore, the 
intention (as I recall - others please do chime in) was that a tunnel 
ingress performing encapsulating could use a non-zero FL (as you note to 
be COMBINED (hashed) with the address information, etc), to assist the 
network in directing the encpasulated packet/datagram to the correct 
tunnel egress/destination - i.e. load balancing?  I'm looking for good text.

2) IMHO, something like this seems preferable to recommending the IETF 
design a new transport protocol variant/mechanism to solve this 
particular problem. Does this seem within the spirit of RFC ?

Best wishes,

Gorry

P.S. I now have a marker in the draft to update this in the next rev.

Brian E Carpenter wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 2009 12:09:59 +1300

Gorry,

> tunnel egress/destination - i.e. load balancing?  I'm looking for good

I was talking off-line with Joel Halpern, and I think we concluded that
the issue is general enough that it may even need a small draft of its
own. No promises, but watch this space.

> particular problem. Does this seem within the spirit of RFC ?

Yes, especially the spirit of RFC1958 ;-)

   Brian

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 11 Nov 2009 08:50:13 +0000

OK. We'll revise draft-fairhurst-tsvwg-6man-udpzero accordingly.

Do let us know if you are inspired to progress with an I-D on this topic 
- to me this seems like a more general network issue, rather than being 
transport-related, so a separate I-D could be a good idea.

Gorry

Brian E Carpenter wrote:
>> network in directing the encapsulated packet/datagram to the correct

---

From: Brian Haberman <[email-masked]>
Date: Thu, 12 Nov 2009 15:42:53 -0500

Hi Brian,

> likely always get the same answer.

Completely agree.

> 6-tuple by adding the flow label.

In a previous gig, I spent some time looking at the use of the flow 
label for ECMP and came to a slightly different conclusion.  *If* the 
source node set the flow label using some heuristic, the ECMP hash could 
be changed to a 4-tuple of DA, SA, Proto, and Flow Label.  This would 
allow efficient ECMP hashing in situations where the port numbers were 
hidden via encryption.

Of course, that is predicated on the source node setting the flow label...

Regards,
Brian