IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Tue, 05 May 2015 22:00 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 1D1BD1A700D; Tue, 5 May 2015 15:00: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 LPDoTXAazXjV; Tue, 5 May 2015 15:00:11 -0700 (PDT)
Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584C71A6FFC; Tue, 5 May 2015 15:00:11 -0700 (PDT)
Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t45Lwg8v008590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 14:58:52 -0700 (PDT)
Message-ID: <55493D10.90609@isi.edu>
Date: Tue, 05 May 2015 14:58:40 -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>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AF3A@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/zMwSNm8_6WFHtnD26h8VmfP5ojw>
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: Tue, 05 May 2015 22:00:13 -0000


On 5/5/2015 2:23 PM, Templin, Fred L wrote:
> Hi Joe,
> 
>> The better solution would be RFC 4821-style probing by the tunnel
>> ingress to the tunnel egress.
> 
> As you know, I agree with this (per Section 3.13 of AERO) but it is not
> exactly like RFC4821. With RFC4821, since the source of the probes is
> also the original source of the data packets (and, since the probes are
> actually data packets themselves) the probes are guaranteed to travel
> the same network path as the data packets.

That depends on how you implement the tunnels. You can easily use the
data packets as probes if you design a way for the egress to indicate
which probes get through.

T> When the tunnel probes, however, it may be probing on behalf of many
> original sources and it becomes more difficult to ensure that the probes
> travel the same network path as the data packets.

That's true only if the network looks into the tunnel packets and treats
them differently - which could have happened for any application packets
too.

Joe

v2.23.0 | Report a Bug | By Email