Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, July 11, 2016 4:15 PM > To: Templin, Fred L <[email protected]>; [email protected] > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt > > 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.
Not necessarily. The tunnel ingress may need to encapsulate original packets with many different flow labels that are all destined to the same egress. Unless the ingress probes the path *for each distinct flow* multipath can still cause the probes to take different paths than the corresponding data packets. I am also told that some networking gear looks more deeply into the original packet than just the flow label, i.e., even after the original packet has been encapsulated. So, it is not necessarily just the flow label that multipath will operate on. > >>> 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. One alternative would be for the ingress to set the same flow label in the encapsulation headers of all packets regardless of the flow labels in the original packets (i.e., the "pipe" model). But this would either defeat multipath (undesirable) or still not solve the problem if multipath looks more deeply into the packet than just the outer flow label (unfixable). > >>> 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. My understanding is that the network may use information more deeply embedded in the packet than just flow label for multipath decisions. So, yes, it is DPI but if the ingress does it it needs to be very sure that all packets of the same flow get the same treatment. This does not negate my claim. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
