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

Joe Touch <touch@isi.edu> Wed, 22 January 2014 01:05 UTC

Return-Path: <touch@isi.edu>
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 4C7021A0266; Tue, 21 Jan 2014 17:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level:
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 yFUgIdWtgmu1; Tue, 21 Jan 2014 17:05:25 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id ECEDA1A024F; Tue, 21 Jan 2014 17:05:24 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s0M14Inb000306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jan 2014 17:04:18 -0800 (PST)
Message-ID: <52DF1911.8040806@isi.edu>
Date: Tue, 21 Jan 2014 17:04:17 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Eggert, Lars" <lars@netapp.com>, Scott Brim <scott.brim@gmail.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> <AAA47C6B-C06B-4C95-9D7E-4A7BAA40E480@netapp.com>
In-Reply-To: <AAA47C6B-C06B-4C95-9D7E-4A7BAA40E480@netapp.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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: Wed, 22 Jan 2014 01:05:26 -0000

+1

Edward Crabbe is right - the encapsulated protocols ought to take care 
of congestion control when using UDP.

When they do NOT - e.g., when using MPLS to transfer traffic that either 
isn't IP or is IP but isn't congestion controlled, then some other 
mechanism needs to be employed.

It's not enough to assume "someone else, somewhere else" will handle this.

I agree with Lars - this needs to be part of the encapsulation protocol, 
because it's not enforced by MPLS, and not provided by UDP.

Joe

On 1/10/2014 10:23 PM, Eggert, Lars wrote:
> 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
>