Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt

[Joe Touch <[e-mail]>]

For clarification

On 7/11/2016 3:10 PM, Templin, Fred L wrote:
> Hi Joe,
>
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Monday, July 11, 2016 2:59 PM
>> To: Templin, Fred L <[e-mail]>; [e-mail]
>> 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