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> Sat, 11 January 2014 06:23 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 B120D1AE041; Fri, 10 Jan 2014 22:23:33 -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 toHCxHOIb8YU; Fri, 10 Jan 2014 22:23:32 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1101AE035; Fri, 10 Jan 2014 22:23:32 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,642,1384329600"; d="asc'?scan'208"; a="95450478"
Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 10 Jan 2014 22:23:21 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 22:23:21 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: Scott Brim <scott.brim@gmail.com>
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAAPhcAgAAHp4CAAAGvgIAADFsAgACUVIA=
Date: Sat, 11 Jan 2014 06:23:20 +0000
Message-ID: <AAA47C6B-C06B-4C95-9D7E-4A7BAA40E480@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> <CACKN6JGNAm6KWLohzqaM58jy94wYqmtjJTh4Y8Cx2dcRRqJ_xQ@mail.gmail.com> <CAPv4CP_YiOnKNBgh5Qg2AaLwOGfm6j3FidNQD347+QQhv5MfkA@mail.gmail.com> <52D05C75.3050505@joelhalpern.com> <CAPv4CP_33OU-s+8xt9t5voAtiXMS3pw2+67w9=FxpS2cAOmDeg@mail.gmail.com>
In-Reply-To: <CAPv4CP_33OU-s+8xt9t5voAtiXMS3pw2+67w9=FxpS2cAOmDeg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.104.60.116]
Content-Type: multipart/signed; boundary="Apple-Mail=_F03B8410-331A-4839-BADD-9F7B10C21371"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, IETF <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: Sat, 11 Jan 2014 06:23:33 -0000

Hi,

On 2014-1-10, at 22:32, Scott Brim <scott.brim@gmail.com> wrote:
> OK good point - so we invoke the end-to-end argument on MPLS's behalf.

look at it the other way. From the viewpoint of the rest of the net, you are an application using UDP. Such applications need to follow a set of principles we have IETF consensus on (RFC5405).

By encapsulating MPLS in UDP, you are changing the game. That traffic can now appear on any Internet path, and not just inside provisioned networks. Because of that, you need a mechanism to detect if you are causing congestion, and a mechanism to react to it.

And it *is* a requirement on the encapsulator, because from the perspective of the rest of the net, that is the application that generates the UDP traffic.

Lars

v2.23.0 | Report a Bug | By Email