Hi,

> IPv6 flow label has been proposed as an entropy field for load
> balancing in IPv6 network environment [RFC6438].  However, as stated
> in [RFC6936], the end-to-end use of flow labels for load balancing is
> a long-term solution and therefore the use of load balancing using
> the transport header fields would continue until any widespread
> deployment is finally achieved.

That is a false argument. RFC6438 describes a model where the
tunnel end point sets the flow label; that is a much smaller fix
to a tunnel end point that converting it to use a new encapsulation
such as IP-in-UDP. Also, the code to generate the "entropy" value
that you propose as a bogus source port number is no simpler than
the code to generate a pseudo-random flow label; in fact it's virtually
the same code, except that it generates a 16-bit port number instead
of a 20-bit flow label.

(The argument is RFC6936 is also false, since it says you need a stateful
solution, but you don't; 6438 makes it clear that you use a stateless
hash.)

> This field contains a 16-bit entropy value that is generated by
> the encapsulator to uniquely identify a flow.  What constitutes
> a flow is locally determined by the encapsulator and therefore
> is outside the scope of this document.  What algorithm is
> actually used by the encapsulator to generate an entropy value
> is outside the scope of this document.

That is ducking the hard part. I recommend the discussions in
RFC 6437 and 6438, where we tried to avoid completely ducking it.
You don't even discuss whether the algorithm is stateful or
stateless. For a stateless hash, I am quite fond of FNV.

> In case the tunnel does not need entropy, this field of all
> packets belonging to a given flow SHOULD be set to a randomly
> selected constant value so as to avoid packet reordering.

That is very confusing. Yes, of course, all packets that belong to
the same microflow must have the same ECMP hash, therefore in
your model they must carry the same bogus source port number. But
what is the difference between "a randomly selected constant value"
and the result of your unspecified "entropy value"? They are
both pseudorandom values that are held constant for a given
microflow.

Bottom line, I don't understand why the world needs this hack
(pseudorandom source port). It is no easier to deploy than the
correct solution (pseudorandom flow label).

   Brian

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to