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> Mon, 13 January 2014 09:42 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 6BA901ADF91; Mon, 13 Jan 2014 01:42:25 -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 ISxiETNSJuqI; Mon, 13 Jan 2014 01:42:24 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4961ADE71; Mon, 13 Jan 2014 01:42:24 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,651,1384329600"; d="asc'?scan'208"; a="95688805"
Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx11-out.netapp.com with ESMTP; 13 Jan 2014 01:42:13 -0800
Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.60]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 01:42:13 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
Thread-Topic: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPB81hZzPPQlRcgk6ua2U45NfiYJp7LVMAgAK2KoCAAFQ2gIAAckuAgAAJQICAAAZIAIAD31WAgABWjoCAAAdiAIAAByqA
Date: Mon, 13 Jan 2014 09:42:12 +0000
Message-ID: <B4EBCDAD-CD64-41F9-9D5B-D7FE903AC195@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> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082443DD@NKGEML512-MBS.china.huawei.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=_6A8AC501-152C-4A56-8A49-10A38055B6D9"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, Scott Brim <scott.brim@gmail.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: Mon, 13 Jan 2014 09:42:25 -0000

Hi,

On 2014-1-13, at 10:16, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> No conflict at all. What I meant is: for those clients of MPLS which are not TCP-friendly (case 2&3 as described in Section 3.1.3 of RFC5405), they should never be transported over the unprovisioned path (e.g., the Internet). Insteads, they should only be transported over a provisioned path in a restricted networking environment. As a result, there is no need for the congestion control mechanism for them.

I agree, but I think we need a safety mechanism when such traffic does end up on the general Internet (because operators may not read the RFC, or there may be configuration errors, etc.)

Even when running inside a provisioned domain, you probably want some sort of safety net, like a circuit breaker that detects if your tunnel is experiencing/causing severe congestion, and shut it down.

Lars

v2.23.0 | Report a Bug | By Email