[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RFC 3697bis Open Issues 10 & 11
From:       Jarno Rajahalme <jarno.rajahalme () nsn ! com>
Date:       2011-01-31 13:14:01
Message-ID: 04AF0A94-FF05-4407-BF79-742C8C9B2513 () nsn ! com
[Download RAW message or body]


> ISSUE 10. Section 2 also says:
> 
> Forwarding nodes such as routers and load balancers MUST NOT depend
> only on Flow Label values being randomly distributed.  In any usage
> such as a hash key for load balancing, the Flow Label bits MUST be
> combined with bits from other sources within the packet, so as to
> produce a suitable distribution of hash values.
> 
> Why is it restricted to "within the packet"? Couldn't the load balancer
> use something else too, especially for a stateful mechanism?
> 
> QUESTION: Should "within the packet" be deleted?
> 

"within the packet" ensures consistency, if it refers to address fields. Also, it \
does not mean ONLY, i.e. other sources (such as a local key) are not excluded. \
However, don't see how a protocol spec could mandate how a router internal hashing is \
implemented. At best we could say "SHOULD".

> --------------
> ISSUE 11. In section 3:
> 
> A node that forwards a flow whose flow label value in arriving
> packets is zero MAY set the flow label value.  In that case, it is
> RECOMMENDED that the forwarding node sets the flow label field for a
> flow to a pseudo-random value.
> 
> QUESTION: Should we suggest how the forwarding node identifies packets belonging
> to the same flow? (draft-ietf-6man-flow-ecmp talks about this.)

Yes. See also my response to issue 9.

  Jarno
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]