IETF Logo Mail Archive

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

Stewart Bryant <stbryant@cisco.com> Fri, 10 January 2014 09:16 UTC

Return-Path: <stbryant@cisco.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 B24341ADBE5; Fri, 10 Jan 2014 01:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.25
X-Spam-Level:
X-Spam-Status: No, score=-7.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 F5WWUgbbWk6U; Fri, 10 Jan 2014 01:16:07 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A9D201ACCFF; Fri, 10 Jan 2014 01:16:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2578; q=dns/txt; s=iport; t=1389345357; x=1390554957; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uMgQFsVuArum1DXQg86uzbpQK6+XtgZVztJ0skbJ8SA=; b=L7EBd4RK/Ix02bMXEM0Om7A3xKzA2PBWu6EwOnFvbQXBa/PCCZgwuGLA AsbCmzWQ6gakTD2yx2DT76g0Qv5NCmwJiWyDXP9wItGaW+J/ejVrAli/4 1HOYQEl2NKpy6FqJMo+rysYlUNwdw8VdPhO0yeP+Snh1KWXy8ta8bx3v2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8FABm5z1KQ/khM/2dsb2JhbABZgws4g1S2QoEHFnSCJQEBAQQBAQFrCgEQCQIYBAUWBAQFAgkDAgECARUfEQYBCQMBBQIBAYgADYxGm2sImngXgSWNLTMHgmuBTASJEI8HkhWBb4E+
X-IronPort-AV: E=Sophos;i="4.95,637,1384300800"; d="scan'208";a="2762080"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 10 Jan 2014 09:15:56 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0A9Ftdp015696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 09:15:55 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s0A9Frcj006408; Fri, 10 Jan 2014 09:15:54 GMT
Message-ID: <52CFBA49.8070500@cisco.com>
Date: Fri, 10 Jan 2014 09:15:53 +0000
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Xuxiaohu <xuxiaohu@huawei.com>, "Eggert, Lars" <lars@netapp.com>, IETF <ietf@ietf.org>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Cc: "mpls@ietf.org" <mpls@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
Reply-To: stbryant@cisco.com
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 09:16:10 -0000

RFC3985/6.5.  Congestion Considerations
may have some useful text. 

We have a lot of deployment experience with
PWs and frankly I have never seen a congestion
complain raised from the field.

Stewart



On 10/01/2014 03:46, Xuxiaohu 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
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

v2.23.0 | Report a Bug | By Email