Dan Wing <[email protected]> writes: > Using Geneve VNI doesn't take us towards that goal, though. On a > simple network, there is only one VNI (one virtual network), and if we > used solely VNI for underlay ECMP, all tunneled packets would go over > the same ECMP path. We want each tunneled TCP flow to take one path, > and ideally the next tunneled TCP flow taking another ECMP path.
I'm mixing a number of points here. In order from what I consider most important to least: - It would be desirable to have a Geneve option to contain entropy, so that in situations where outer headers don't provide a good place for entropy, devices don't have to look further than the Geneve header. - There is an unused octet in the Geneve header. It might be useful to define it to contain entropy for ECMP. (Unfortunately, it's only one byte.( - ECMP can use as entropy any field which is "flow identification", that is, where intermediate devices are allowed to disorder packets which have different values of the flow identification field. In particular, any virtual network identifier serves as flow identification. Thus, we can specify in Geneve that any device handling packets with Geneve headers can disorder packets with different values of the VNI field. But a consequence of *that* is that in situations where the VNI field is not used to communicate useful information (presumably the additional options are the reason Geneve is being used), the VNI field can be used for entropy. Dale _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
