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

[Joe Touch <[e-mail]>]

On 7/12/2016 7:37 AM, Templin, Fred L wrote:
> ...
>>>> 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.
A flow is defined by source, destination, and flow ID when the flow ID
is set.

(otherwise it's defined by whatever DPI is used, which typically
involves source, destination, protocol, source port, and dest port).

So different flow IDs between the same ingress/egress pairs are
different flows. I've already noted that PLPMUTD would need to run
independently for each flow between ingress and egress, *exactly as it
would for different flows between a given pair of endpoints that don't
use tunnels*.

> 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.

That could interfere with multipath between two endpoints as well, e.g.,
if it tries to differentiate between access to different app layer content.

All bets are off of multipoint ignores flow ID and its defining context
- for PLPMTUD for both tunnels and the rest of the Internet.

>
>>>>> 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).

The former may be desirable or not, and it's up to the ingress to decide
(or whomever configures it).

The latter is a problem in multipath that can affect everyone, not just
tunnels, as noted above.


>
>>>>> 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.
Multipath can interfere with any PLPMTUD if this is the case.

> 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.

No, but it renders it a bit moot if it isn't specific to tunnels.

Joe