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

Edward Crabbe <edc@google.com> Fri, 10 January 2014 20:15 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 E408B1AE1FB for <mpls@ietfa.amsl.com>; Fri, 10 Jan 2014 12:15:17 -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 bU1_r0L4YAmq for <mpls@ietfa.amsl.com>; Fri, 10 Jan 2014 12:15:15 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A53421AE1EE for <mpls@ietf.org>; Fri, 10 Jan 2014 12:15:15 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id q59so4456266wes.41 for <mpls@ietf.org>; Fri, 10 Jan 2014 12:15:05 -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=Hf5/fpB19PPfk+FSGxeMnrQwJZrRFwb9PX8n8bCKxuo=; b=Jfo7uOeRco3InsSCqLhr4qvvgFWpul4/tsxwodTvfR5kbP4Ml8u/1BBnY3TvyDjs/2 coSCoRBk+Uwib2OayM+DhQ1c/RElJPy9WrFTpvAdbcyKjVQD20EB3zRoyzRDVrD1hQsD WcKQKc2hm3ZgQRSYO/G/tXbJHhAwaQks873bHoUjODPN/Nn/CO59nbkvgFB/3s4k7gN8 txCiehehYFKQZG4RN5YsXEsm40crTGplRj7ZOVUA6/sOi30xy/eMtC6nKk6CiCNjIELh wHsZgfAGxkYwtbUEzq/Z6j8XY2wqV1kgH0YEvB06JFPMPElur6mc8kYGoRYbKeDWvEnE da7g==
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=Hf5/fpB19PPfk+FSGxeMnrQwJZrRFwb9PX8n8bCKxuo=; b=KNuuDo16fKmv57jeR6VVNaHLbIncnRDT/f8WuDuQzjo608MY8fQsIgDg0uMPEXNnYv hrN7MNI7FQ0juLnYbEwL3CGZlns57zzkeoOB/8KF3AYFYi51miSMfEXuX8IwGnM/DLzH dYsiBV+a9BMbZLLsKnpUd80zhqr8qClwuKejGDqgrvH0fa8WDkcsMi0pe0dLl/4j3o0X HLAukjs4ZbTzPYn/yR89yJ1fQV+4Vb5oqk6ve9Q2ZgVqvXAabylo3lGA4RyGUcE0aBgY peMsrbh0qGxBDpHGQkry1Hw444NZkyQvnXILLEzzJKeevoIrTzOpIgwqBWLaFBcOAwAW WDkg==
X-Gm-Message-State: ALoCoQn/fJp5WQNd+10tE1YGU88cC5kG+R3L64gK7BL3w7vLViLizec3IBT8E+kt9megLVf6HMDbT59wPZoWOnGAjKBFMlEGJd6RaHSrjBHn2rFPacuYJs3b4lfkPbklDMNLyiO4CEx7Q/dKu6jxW0LIhktDZNT4Brbjf5UNz4/mfhpwxcvqoNvGWy/jVdze1ydRkJyFbgDp
X-Received: by 10.180.93.169 with SMTP id cv9mr4447242wib.3.1389384905056; Fri, 10 Jan 2014 12:15:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.23.3 with HTTP; Fri, 10 Jan 2014 12:14:24 -0800 (PST)
In-Reply-To: <CAPv4CP-iwoHEiV=xtNAd7qT4r8OYvfE1ZjnKE=wWY5VVcQ3x8w@mail.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>
From: Edward Crabbe <edc@google.com>
Date: Fri, 10 Jan 2014 12:14:24 -0800
Message-ID: <CACKN6JGNAm6KWLohzqaM58jy94wYqmtjJTh4Y8Cx2dcRRqJ_xQ@mail.gmail.com>
To: Scott Brim <scott.brim@gmail.com>
Content-Type: multipart/alternative; boundary="f46d043c7fc0b917d704efa361e2"
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Eggert, Lars" <lars@netapp.com>, 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 20:15:18 -0000

+1

Let the encapsulated transport protocols take care of the congestion
end-to-end.


On Fri, Jan 10, 2014 at 8:32 AM, Scott Brim <scott.brim@gmail.com> wrote:

> I don't think it's right to try to solve this in MPLS, because MPLS is
> not a forwarding protocol - it's a connectivity protocol. In any use
> of UDP, congestion control is either left to something above UDP or
> ignored (left to queue management). Similarly, you want the client of
> MPLS to be responsible for managing its traffic. MPLS gives you paths,
> it doesn't push packets over them.
>
> Scott
>
>
> On Fri, Jan 10, 2014 at 11:09 AM, Eggert, Lars <lars@netapp.com> wrote:
> > 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
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>