IETF Logo Mail Archive

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

"Eggert, Lars" <lars@netapp.com> Tue, 14 January 2014 15:29 UTC

Return-Path: <lars@netapp.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 A8C861AE0FB; Tue, 14 Jan 2014 07:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, 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 ftKSLCV8Zdhz; Tue, 14 Jan 2014 07:29:51 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id A2B001AE0FA; Tue, 14 Jan 2014 07:29:50 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,658,1384329600"; d="asc'?scan'208"; a="95978130"
Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 14 Jan 2014 07:29:39 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 07:29:39 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: Joel Halpern <jmh@joelhalpern.com>
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAHXQgIAAN0wAgAEJtoCAACSXAIAAC26AgAAH1ACAABCuAIAAAQqAgAABkYA=
Date: Tue, 14 Jan 2014 15:29:38 +0000
Message-ID: <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.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>
In-Reply-To: <52D5568F.2070600@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_366B3B18-1301-40E5-9069-EBD52038CD8A"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, Scott Brim <scott.brim@gmail.com>, IETF discussion list <ietf@ietf.org>
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 15:29:52 -0000

Hi,

On 2014-1-14, at 16:23, 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?

no, because the sender of the inner traffic may be blasting some L2 traffic, for an L2 where that is OK behavior. But that traffic is now being encapsulated inside UDP and can hence go anywhere on the net *without the sender being aware of this*.

> Asking tunnel's to solve the problem of applications with undesirable behavior seems backwards.

It is the *tunnel* that performs the encapsulation and allows that traffic to go places it couldn't before. And so it's the tunnel's responsibility to make sure that the traffic it injects into the Internet complies with the BCPs we have on congestion control.

Lars

v2.23.0 | Report a Bug | By Email