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

Joe Touch <touch@isi.edu> Wed, 06 May 2015 00:28 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 94B251B2A98; Tue, 5 May 2015 17:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mYNu2D8sP-x9; Tue, 5 May 2015 17:28:12 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C401B2A27; Tue, 5 May 2015 17:28:12 -0700 (PDT)
Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t460RXSA000400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 17:27:50 -0700 (PDT)
Message-ID: <55495FF4.7000100@isi.edu>
Date: Tue, 05 May 2015 17:27:32 -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+nEHSGYa+1DHzwee+RNgkXfZra_Pa9706vqpTGJV71SmDaw@mail.gmail.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>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E5B040@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t460RXSA000400
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/XvrYM6af9JjYViAwio33EXEZcOU>
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 00:28:13 -0000


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.

Joe