IETF Logo Mail Archive

Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Edward Crabbe <edc@google.com> Tue, 14 January 2014 20:29 UTC

Return-Path: <edc@google.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D981ADFCA for <mpls@ietfa.amsl.com>; Tue, 14 Jan 2014 12:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable
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 IQdXLob3ngf3 for <mpls@ietfa.amsl.com>; Tue, 14 Jan 2014 12:29:08 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1411AE155 for <mpls@ietf.org>; Tue, 14 Jan 2014 12:29:07 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id x13so912977wgg.27 for <mpls@ietf.org>; Tue, 14 Jan 2014 12:28:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=emwcLnFtoLgKjo5q6JqhNprCT2HKexy5UDuof5KMLCw=; b=P/0cr2aG9vjb1ucgDmqqLh3LTuqSGaYCxHEXzPqJ5WXydECk5G/xuLJzxloYT7zyMN J4IS25xX/mE/D/KYPSA9n1gDOL12aWEN36x7SGeKab5oqix59MZUYQoNF5b2AQq7otHM GMRBHCrC46SrauQk+dC/AG3x7Iuq69kfAppD4mXkMAaOc105G2hXtNSYQ/lAhDjLgoCe ujRYi2gwi6oJzm+/Rd3X2EAu42Vt9pRgcfn7pVOXLuWnhjCowa38apGL8ITQ4k8ouGpo 1NaQYMudteB0tMA8KSLPHzy/OvZSGyYh9Awa4R0eVQdMLOt5Bdxolewh8vu3JfnvupBF 7dCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=emwcLnFtoLgKjo5q6JqhNprCT2HKexy5UDuof5KMLCw=; b=YbxpzR4exU+q90gNhNriYa0hFv2a4aamQuPeuM3icY2em4ZdjNWlkH1SZj4iRPwtic y/1nUbAXugtmFcEJ72kNbsxJYFBExdyFpst3We6OHGFaX0Idjdb0+INHICFDlngGad5z nJEXuVXLQRCAPtiBYfgvDEeia3afG/6a6veDUwI8Wbe+4RRYn+ZA88OkZISFMH8tRuaK dpTMP/SBi5sV0Fm3CmUPYi6CZ4/l8T1Treea1zqcsiiECK8x4g+PHKBejLrkpQFRtbnV t+Gq6ZRMoP0VZntrER3DMPzrFXxFcgJ7PjnCcrTURwyQNIIOqWLnj5NEy76Nv7owWVgc wIXA==
X-Gm-Message-State: ALoCoQmsEg3PkpWY1YY4ncewz9olvQdJB4XaX28kGsCibZjYQ//w+UhCpTxIafU9vAonAQWbjH4rvRLRlF6nxlxEo+is3M/7YHS7MU2tS+7oyLtOurnqU4biSh2H4oamySlPlKVEBcEOzDPf2DCDTkZgsCtYlbRsr5yXlHj6lKkV2N6aH7NL1d8uO1baBVlRTDyRUXsnN6i+
X-Received: by 10.180.37.193 with SMTP id a1mr3942567wik.52.1389731336013; Tue, 14 Jan 2014 12:28:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.23.3 with HTTP; Tue, 14 Jan 2014 12:28:14 -0800 (PST)
In-Reply-To: <52D5568F.2070600@joelhalpern.com>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <CAPv4CP-iwoHEiV=xtNAd7qT4r8OYvfE1ZjnKE=wWY5VVcQ3x8w@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <A1F82D9D-F9D0-46C1-B666-0C13DB79A845@netapp.com> <52D40B91.8040101@joelhalpern.com> <CAPv4CP9R-6Dv9O_H8Ox_-uLWMSzqpx7Gn97TF8jceFkVKPLWTw@mail.gmail.com> <52D518D9.7010703@cisco.com> <CAPv4CP-eNJuOKv4vWxGkiUPUTMkYyqY4cbTmj8M4sn+jXzmCkw@mail.gmail.com> <CAPv4CP-DnNdSoVEFTg9N53xP=yOd6pNe97WxmXJeGHBPKC2h6w@mail.gmail.com> <52D547B2.1060302@cisco.com> <DB6CF60F-FFBA-47DA-9FD6-7288CCB260A6@netapp.com> <52D5568F.2070600@joelhalpern.com>
From: Edward Crabbe <edc@google.com>
Date: Tue, 14 Jan 2014 12:28:14 -0800
Message-ID: <CACKN6JG0zP6=XYUxG_F-uczQyRPv3p0t5p8vwK6Sy9AyTtjUnA@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="e89a8f502fa09ddfaf04eff40acb"
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Eggert, Lars" <lars@netapp.com>, IETF discussion list <ietf@ietf.org>, Scott Brim <scott.brim@gmail.com>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 20:29:10 -0000

+100

the same problem would exist with or without the additional encapsulation
(this includes any L2 encaps that may exist in the case of L2 tunelling.)
 The only difference is /reach/.  This same concern exists *most* common
tunnels types in the internet today.



On Tue, Jan 14, 2014 at 7:23 AM, Joel M. Halpern <jmh@joelhalpern.com>wrote:

> Isn't that basically the problem of the inner traffic sender, not the
> problem of the tunnel that is carrying the traffic?
> Asking tunnel's to solve the problem of applications with undesirable
> behavior seems backwards.
>
> Yours,
> Joel
>
>
> On 1/14/14 10:20 AM, Eggert, Lars wrote:
>
>> On 2014-1-14, at 15:20, Stewart Bryant <stbryant@cisco.com> wrote:
>>
>>> Yes, the inner (real) transport header is the only meaningful place
>>> to apply congestion avoidance.
>>>
>>
>> But what if the inner traffic isn't congestion controlled?
>>
>> Lars
>>
>>  _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

v2.23.0 | Report a Bug | By Email