Hi Ron, ECMP and LAG are likely to operate on the (src, dst, flow label)-tuple of encapsulated packets. This means that MTU probing needs to be done on a per (src, dst, flow label) basis where src is that of the tunnel ingress, dst is that of the tunnel egress, and flow label is the value set by the tunnel ingress.
RFC6438 specifies the manners in which the tunnel ingress may set the flow label. But, if the ingress sets the flow label to a uniformly-distributed 20 bit value, the ingress would have to send 2^20 probes to ensure that there are no paths with a too-small MTU in the ECMP/LAG arrangement which is far too many for practical purposes. It would be in keeping with RFC6438 to have your document recommend a more conservative approach. For example, calculate a hash of the payload packet's IP header fields but then map the hash into one of only N values where N is something small like 4, 5, etc. Then, the ingress would only need to send a small number of probes but there would still be some ECMP/LAG benefit gained from using the flow label. Alternatively, your document could set the flow label to a constant value (e.g., 0) in which case only one (src, dst, flow label) value would need to be probed. But, then ECMP/LAG path selection may be hampered by only ever seeing a single constant value. Thanks - Fred [email protected] _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
