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

"Eggert, Lars" <lars@netapp.com> Fri, 10 January 2014 16:09 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 4FB821AE0B0; Fri, 10 Jan 2014 08:09:58 -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 Ld306yLTqEvc; Fri, 10 Jan 2014 08:09:56 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id AB2EF1AE074; Fri, 10 Jan 2014 08:09:56 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,639,1384329600"; d="asc'?scan'208"; a="95307383"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 10 Jan 2014 08:09:45 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 10 Jan 2014 08:09:45 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: Joel Halpern <jmh@joelhalpern.com>
Thread-Topic: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQIA=
Date: Fri, 10 Jan 2014 16:09:45 +0000
Message-ID: <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@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>
In-Reply-To: <52D01383.2080509@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=_314DE890-78FD-4040-92CF-9007B2DDAACD"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 10 Jan 2014 10:14:13 -0800
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: Fri, 10 Jan 2014 16:09:58 -0000

Hi,

On 2014-1-10, at 16:36, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> Maybe I am completely missing things, but this looks wrong.
> If the MPLS LSP is carrying fixed rate pseudo-wires, adding congestion
> control will make it more likely that the service won't work.  Is that
> really the goal?
> 
> We do not perform congestion control on MPLS LSPs.
> Assuming that a UDP tunnel is carrying just MPLS and was established
> just for MPLS, why would we expect it to behave differently than an MPLS
> LSP running over the exact same path, carrying the exact same traffic?

we've been rehashing this discussion several times over the years, e.g., for PWE, AMT, etc. In order to carry fixed-rate or otherwise non-congestion-controlled traffic over unprovisioned general Internet paths, there needs to be some sort of basic congestion control mechanism, like a circuit breaker.

The whole point of running MPLS is to create networks in which paths are provisionable, so this is usually not an issue. But if you start sticking MPLS inside of UDP, those packets can go anywhere on the net, so you need mechanisms to control the rate of that traffic if it causes congestion, or at the very least you need to be able to stop the traffic if it creates severe congestion.

Lars