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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 05 May 2015 22:15 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 A1E581B2A19; Tue, 5 May 2015 15:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 NGe3UXA4CG8A; Tue, 5 May 2015 15:15:20 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66321B2A13; Tue, 5 May 2015 15:15:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t45MFKP5063632; Tue, 5 May 2015 15:15:20 -0700
Received: from XCH-BLV-105.nw.nos.boeing.com (xch-blv-105.nw.nos.boeing.com [130.247.25.121]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t45MFHBQ063615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 May 2015 15:15:17 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-105.nw.nos.boeing.com ([169.254.5.90]) with mapi id 14.03.0235.001; Tue, 5 May 2015 15:15:16 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>, Dave Dolson <ddolson@sandvine.com>, Xuxiaohu <xuxiaohu@huawei.com>, Donald Eastlake <d3e3e3@gmail.com>, "trill@ietf.org" <trill@ietf.org>
Thread-Topic: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip
Thread-Index: AQHQh3nJyhmZ+Lyhk0iSDo4t2tXKb51uY68A//+LwaA=
Date: Tue, 05 May 2015 22:15:15 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E5AFC1@XCH-BLV-504.nw.nos.boeing.com>
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>
In-Reply-To: <55493D10.90609@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/oFTRdQhX6mL02qGiftYIfy1cnwA>
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:15:23 -0000

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tuesday, May 05, 2015 2:59 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 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.

No, look at Section 5.2 of RFC4821. It acknowledges that MTU needs to be
maintained on a per-flow basis. When the source is the  originator of the
flows, it is easy to keep track of which MTUs are associated with which
flows. When the source is a tunnel ingress, however,  it may be required
to send the data packets of many flows across the tunnel to the egress
and, if the network can distinguish the different flows, the data packets
and probe packets may take different paths. 

What this means is that, for tunnels over IPv6, the ingress would need
to implement a discipline for setting the flow label in the encapsulation
header so that the probes and data packets appear to be part of the
same flow. One way is to simply set a constant value (e.g., 0), but then
ECMP in the path between the ingress and egress would be disabled.

A compromise would be to have the ingress set a finite number of flow
label values (e.g., 4) selected, e.g., based on a hash of the payload
packet headers. But then, each such flow label value would need to
be probed separately.

Thanks - Fred
fred.l.templin@boeing.com

> Joe