Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip

Joe Touch <touch@isi.edu> Wed, 06 May 2015 18:16 UTC

Return-Path: <touch@isi.edu>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A471B2E0E; Wed, 6 May 2015 11:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krMa5gej3LEl; Wed, 6 May 2015 11:16:29 -0700 (PDT)
Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDD71B2E0B; Wed, 6 May 2015 11:16:28 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t46IFYjY010703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 May 2015 11:15:35 -0700 (PDT)
Message-ID: <554A5A45.2040802@isi.edu>
Date: Wed, 06 May 2015 11:15:33 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Dave Dolson <ddolson@sandvine.com>, Xuxiaohu <xuxiaohu@huawei.com>, Donald Eastlake <d3e3e3@gmail.com>, "trill@ietf.org" <trill@ietf.org>
References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <CAF4+nEFcUL2ieQKCm98_0XxfrrAR0M11irVFfOfqa=92OM1V=A@mail.gmail.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <E8355113905631478EFF04F5AA706E9830BEFC3C@wtl-exchp-2.sandvine.com> <554904B8.9020504@isi.edu> <E8355113905631478EFF04F5AA706E9830BF0165@wtl-exchp-2.sandvine.com> <554931E2.5010101@isi.edu> <2134F8430051B64F815C691A62D9831832E5AF3A@XCH-BLV-504.nw.nos.boeing.com> <55493D10.90609@isi.edu> <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com> <554942C0.4000601@isi.edu> <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com> <55495FF4.7000100@isi.edu> <2134F8430051B64F815C691A62D9831832E5B85B@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E5B85B@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/ACYjtZHrCCnN_QSCz7eKRPvjgss>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2015 18:16:33 -0000


On 5/6/2015 7:37 AM, Templin, Fred L wrote:
> Hi Joe,
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Tuesday, May 05, 2015 5:28 PM
>> To: Templin, Fred L; Dave Dolson; Xuxiaohu; Donald Eastlake; trill@ietf.org
>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org
>> 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