On 5/6/2015 7:37 AM, Templin, Fred L wrote:
> Hi Joe,
>
>> -----Original Message-----
>> From: Joe Touch [mailto:[email protected]]
>> Sent: Tuesday, May 05, 2015 5:28 PM
>> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; [email protected]
>> Cc: [email protected]; [email protected]; [email protected]
>> Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip
>>
>>
>>
>> On 5/5/2015 3:43 PM, Templin, Fred L wrote:
>>>> Then what you're saying is that the tunnel ingress - as an app - has
>>>>> flows that are distinguishable by the net. That can happen with any
>>>>> application.
>>>
>>> But, that's just it - when the original source does the probing the data
>>> packets are always part of the same application - always. When the
>>> tunnel ingress probes, it may be asked to encapsulate the data
>>> pacekts of many applications.
>>
>> An "application" is a source of packets.
>>
>> At a tunnel, the ingress arriving packets are that source - they ARE the
>> "application".
>>
>> To correlate flow IDs to behavior within that flow - i.e., to the user
>> programs that generate the packets that arrive at the ingress - requires
>> the ingress to somehow infer those flows, unless they're explicitly
>> marked by the user applications.
>>
>> That's a known limitation of any tunnel ingress. It's equally true of
>> the user application if there are four people using one application, and
>> you want 'flow' to map back to an individual person.
>
> We are still not reaching. The concern is that if some tunneled packets
> take a different network path than others then there is a chance that
> the probes will take a different path than the data. The only way I know
> to prevent that is to always set the Flow Label in the encapsulation
> header to some fixed value (e.g., 0).
You need to track ANY packet difference that could cause a path
difference. That could include:
- flow label
- packet length
- traffic class
- next-header
The only things that all tunneled packets have in common are source and
destination address. ANY other field that varies is a potential source
of path variance.
By your logic, PLMTUD would never work at all, and PMTUD only ever tells
you about a specific set of the above fields failing.
Yes, if you want to avoid that issue, you need to minimize any
differences that could affect path. But that's *already true for all
uses of PLMTUD or PMTUD*.
The point here is that assuming otherwise is the flaw.
Joe
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
