Hi Brain, Thanks for your comments and please see my response inline.
> -----Original Message----- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Tuesday, April 21, 2015 12:05 PM > To: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-xu-intarea-ip-in-udp-00.txt > > 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. Agree with your argument that it's virtually the same code for generating the entropy value. > (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.) My guess is that the co-authors of RFC6936 had been fully convinced with the logic of RFC6438 (i.e., including transport-layer information as input keys to a hash may be a problem, especially for the IPv6 case and therefore using the {dest addr, source addr, flow label} 3-tuple of the inner packet would be a future-proof option). As such, in the case where the inner packet use IPv6 with the flow label of zero, to provide good entropy in the flow label field of the outer IPv6 header, the only reasonable way that the co-authors of RFC6936 could think of is to allow the tunnel ingress to create a random flow label value and keep corresponding state so that all packets that were associated with a flow would be consistently given the same flow label. ^_^ > > 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. It's stateless. By the way, I believe the implementers would have enough intelligence to prefer a statelss algorithm to a stateful algorithm unless there was extraordinary reasons. > > 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). Bottom line is flow label is only contained in IPv6 header:) By the way, you may be curious to know why the RTG DP Encapsulation design team has the following assessment in its report (https://tools.ietf.org/html/draft-rtg-dt-encap-01#page-7): "It has been suggested that when IPv6 is used it would not be necessary to add a UDP header for entropy, since the IPv6 flow label can be used for entropy.... While such an approach would save 8 bytes of headers when the underlay is IPv6, it does assume that the underlay routers use the flow label for ECMP, and it also would make the IPv6 approach different than the IPv4 approach. Currently the leaning is towards recommending using the UDP encaps for both IPv4 and IPv6 underlay." Best regards, Xiaohu > Brian > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
