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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 10 January 2014 15:37 UTC

Return-Path: <jmh@joelhalpern.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 7D1A21AE09E; Fri, 10 Jan 2014 07:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.887
X-Spam-Level:
X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 CKGWm1xEdHDa; Fri, 10 Jan 2014 07:37:00 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7312D1AE08E; Fri, 10 Jan 2014 07:37:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D78DB6200B8; Fri, 10 Jan 2014 07:36:50 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E83231C02DA; Fri, 10 Jan 2014 07:36:42 -0800 (PST)
Message-ID: <52D01383.2080509@joelhalpern.com>
Date: Fri, 10 Jan 2014 10:36:35 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "Eggert, Lars" <lars@netapp.com>, Xuxiaohu <xuxiaohu@huawei.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>
In-Reply-To: <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
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 15:37:05 -0000
X-List-Received-Date: Fri, 10 Jan 2014 15:37:05 -0000

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?

Yours,
Joel

On 1/10/14 3:47 AM, Eggert, Lars wrote:
> Hi,
> 
> that sounds good. What congestion control are you going to be specifying for your tunnel?
> 
> Lars
> 
> On 2014-1-10, at 4:46, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
>> Hi Lars,
>>
>> Thanks a lot for your comments.
>>
>> I wonder whether the following modified text for Congestion Consideration section is OK from your point of view:
>>
>> Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels", the congestion control guidelines for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS can carry a number of different protocols as payloads. When the payload traffic is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its own congestion control mechanism, because congestion losses of tunneled traffic will already trigger an appropriate congestion response at the original senders of the tunneled traffic. When the payload traffic is not known to be IP-based, or is known to be IP-based but not congestion-controlled, the UDP tunnel SHOULD employ an appropriate congestion control mechanism. Furthermore, because UDP tunnels are usually bulk-transfer applications as far as the intermediate routers are concerned, the guidelines as defined in Section 3.1.1 of [RFC5405] SHOULD apply.
>>
>> Best regards,
>> Xiaohu
>>
>>> -----邮件原件-----
>>> 发件人: mpls [mailto:mpls-bounces@ietf.org] 代表 Eggert, Lars
>>> 发送时间: 2014年1月8日 18:22
>>> 收件人: IETF
>>> 抄送: mpls@ietf.org
>>> 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
>>> in UDP) to Proposed Standard
>>>
>>> Hi,
>>>
>>> On 2014-1-2, at 16:14, The IESG <iesg-secretary@ietf.org> wrote:
>>>> - 'Encapsulating MPLS in UDP'
>>>> <draft-ietf-mpls-in-udp-04.txt> as Proposed Standard
>>>
>>>
>>> this document needs to describe how it addresses the issues raised in BCP145
>>> (RFC5405). It already contains some text about messages sizes and congestion
>>> considerations, which is great. Unfortunately, the text about congestion
>>> considerations is not fully in line with RFC5405.
>>>
>>> Lars
>