Hi Ron,
> Your document Section 3.2 is asking for probing the IPv6 minMTU of 1280 plus
> the encapsulation overhead. That might work on one path of a multipath but
> actual data packets might take a different path. This does not make me happy
> because I also want to do some probing of my own. But, it seems like
> something we may need to worry about.
I just stumbled across RFC6438 ("Using the IPv6 Flow Label for Equal Cost
Multipath Routing and Link Aggregation in Tunnels") and it seems to be a
proposed standard for ensuring that tunneled packets are assigned an
appropriate flow label according to the traffic flows they encapsulate.
Meaning that ECMP and LAG between the tunnel ingress and egress can
spread tunneled traffic over multiple paths. Meaning that probing the
tunnel to determine if a particular size is supported only tests one path
when there may in fact be many.
Based on that, probing from the source via something like RFC4821 should
be fine because the probes look exactly like ordinary data packets. But,
probing from a tunnel ingress is problematic when there is ECMP/LAG
because the ingress may have to tunnel the data packets of many flows.
AFAICT, the only way around this is for the tunnel to assign the same
flow label for every encapsulated packet (i.e., the "pipe" model). But,
that would defeat the ECMP/LAG function that the network operators
paid good money for.
Sorry I don't have better news,
Thanks - Fred
[email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
