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 16:06 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 C49C71AE110; Tue, 14 Jan 2014 08:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.44
X-Spam-Level:
X-Spam-Status: No, score=-7.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 xvQ2TnPvHlji; Tue, 14 Jan 2014 08:06:35 -0800 (PST)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E1F7E1AE0DC; Tue, 14 Jan 2014 08:06:35 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,658,1384329600"; d="asc'?scan'208"; a="136906970"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx12-out.netapp.com with ESMTP; 14 Jan 2014 08:06:24 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 08:06:23 -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: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAHXQgIAAN0wAgAEJtoCAACSXAIAAC26AgAAH1ACAABCuAIAAAQqAgAABkYCAAAKhAIAAB6KA
Date: Tue, 14 Jan 2014 16:06:21 +0000
Message-ID: <C54B4791-A023-4512-84C6-50869BBE9B66@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> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <CAPv4CP_3DmjZQN=LQmV53-8HsZDHukpdu0Lyuh9KwOgXQ-v=EQ@mail.gmail.com>
In-Reply-To: <CAPv4CP_3DmjZQN=LQmV53-8HsZDHukpdu0Lyuh9KwOgXQ-v=EQ@mail.gmail.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=_5882EB94-8DA2-4AB3-A5E8-C5B083388DB5"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, 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 16:06:38 -0000

Hi,

On 2014-1-14, at 16:39, Scott Brim <scott.brim@gmail.com> wrote:
> Lars, I know we're repeating arguments from the last decade. The
> choice is between (1) specifying congestion control around the
> substrate UDP that can be turned off if it causes problems, or (2)
> specifying nothing at this time and adding it later if operators want
> it.
> 
> I guess if this can be written as a SHOULD, up to the implementor's
> discretion, then okay.

I don't think we can leave this up to implementors discretion. We've had IETF consensus that Internet communication requires congestion control at least since RFC2914. A circuit breaker mechanisms seems straightforward to implement.

As is, I object to this document going forward. The minor benefits of getting some better load balancing for MPLS are far outweighed by the risks.

(I'm also going to shut up now, and let others speak. I think I've said my bit.)

Lars

v2.23.0 | Report a Bug | By Email