For clarification On 7/11/2016 3:10 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Monday, July 11, 2016 2:59 PM >> To: Templin, Fred L <[email protected]>; [email protected] >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >> >> >> >> On 7/11/2016 2:45 PM, Templin, Fred L wrote: >>> Hi Joe, >>> >>> I was unable to parse most of what you said, but one point that requires >>> clarification: >>> >>>> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why >>>> other methods, e.g., directly querying the egress, may be useful. >>> That is not true to my understanding. When the original source uses PLPMTUD, >>> the probes take exactly the same path as the data packets so PLPMTUD works >>> even if there is multipath. >> Only if PLPMTUD is performed within each flow as differentiated by >> multipath routing. > Right; PLPMTUD has to be applied to each flow the source produces > individually - there is no way to share the PMTU information among > different flows even though they may have the same destination. > >> There is no solution if the mutlpathing uses other packet info for context. > My understanding of multipath is that it needs to ensure that all packets > of the same flow follow the same path. Any multipath equipment in the > network that does not honor that requirement is broken, at least to my > understanding.
If that's the case, then PLPMTUD will work just fine with tunneled traffic because the multipath and tunnel will both be operating only on the flow information in the outermost IP header. >>> This is different than for tunnels, because the tunnel ingress is not the >>> source >>> of the original packets - it is only the source of the encapsulated packets. >> It is identical in that the ingress is responsible for fragmentation, >> which the layer at which PLPMTUD is supposed to happen. > This statement makes no sense afaict. To clarify: PLPMTUD operating at the ingress would need to operate on the flows of the IP packets emitted by the ingress into the tunnel. Those flows are defined by the outer header. The fragmentation is defined by how the ingress source fragments (either at the outer IP layer or any other layer within the added encapsulation headers). That would make the ingress no different from any other traffic source. It emits one or more flows, and as long as the flows it emits are respected by multipath routing, PLPMTUD at the ingress on each flow will work correctly. > >>> And, >>> the ingress may need to encapsulate pacekts produced by many original >>> sources which may take very different routes due to multipath within the >>> tunnel. >> Then the tunnel should do what it can to ensure that they do not take >> different routes. > The tunnel has no way of controlling which routes the network will select. Agreed, but if the network uses routes that DPI beyond the encapsulation headers, then *by your claim* that routing is violating multipath routing and all bets are off anyway. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
