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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 06 May 2015 19:47 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 1FF951B2E51; Wed, 6 May 2015 12:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 LQZ5_z-DRbxw; Wed, 6 May 2015 12:46:58 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7211A92B5; Wed, 6 May 2015 12:46:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t46JkvCG017194; Wed, 6 May 2015 14:46:57 -0500
Received: from XCH-BLV-508.nw.nos.boeing.com (xch-blv-508.nw.nos.boeing.com [130.247.25.198]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t46JkpDE017113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 May 2015 14:46:52 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.120]) by XCH-BLV-508.nw.nos.boeing.com ([169.254.8.162]) with mapi id 14.03.0235.001; Wed, 6 May 2015 12:46:51 -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//+LwaCAAHsHAP//jdwwgACU9ACAAHdOQIAAsxiA//+gFXA=
Date: Wed, 6 May 2015 19:46:50 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832E5BF0F@XCH-BLV-504.nw.nos.boeing.com>
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> <554A5A45.2040802@isi.edu>
In-Reply-To: <554A5A45.2040802@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/x9tQFk3ESo8CR9UrzEZRyDCoHYw>
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 19:47:00 -0000

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Wednesday, May 06, 2015 11:16 AM
> 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/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

Right.

> 	- packet length

An Equal Cost Multipath algorithm that made forwarding decisions based
on packet length would be difficult to probe.

> 	- traffic class

Traffic Class is in the same category as Flow Label - a single tunnel
could be asked to carry multiple traffic classes, which might cause
ECMP to select different paths for carrying tunneled traffic. This
gets back to whether to copy the inner ToS codepoint into the
outer header or not, and I think there were many RFCs that talk
about this.

> 	- next-header

In this case, next header would be the same for all tunneled
packets so no need for concern here.

> The only things that all tunneled packets have in common are source and
> destination address.

and next-header.

> ANY other field that varies is a potential source
> of path variance.

In which case, probes could take a different path than data,
which is the whole point of concern.

> By your logic, PLMTUD would never work at all,

PLMTUD works because it is based on the actual data packets of the
actual flow that is being sized.

> and PMTUD only ever tells
> you about a specific set of the above fields failing.

PMTUD (when it works) will always converge to the minimum MTU of all
paths that are part of the multipath. When it works, great; when it doesn't,
you need PLMTUD.

> 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*.

Not true for PLMTUD and not applicable for PMTUD (see above).

> The point here is that assuming otherwise is the flaw.

The point for concern is to find a way to ensure that any path
sizing probes sent by the tunnel ingress will follow the same
path as the data packets, which may have come from many
original flows and/or many original sources. I don't think we
have yet figured out how to do that.

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

> Joe
>