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

Curtis Villamizar <curtis@ipv6.occnc.com> Tue, 14 January 2014 17:25 UTC

Return-Path: <curtis@ipv6.occnc.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 9E5A81AE16A for <mpls@ietfa.amsl.com>; Tue, 14 Jan 2014 09:25:40 -0800 (PST)
X-Quarantine-ID: <xNAefWFKQATN>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char B4 hex): Subject: Re: \264\360\270\264: [mpls] Las[...]
X-Spam-Flag: NO
X-Spam-Score: -0.573
X-Spam-Level:
X-Spam-Status: No, score=-0.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJECT_NEEDS_ENCODING=0.049, SUBJ_ILLEGAL_CHARS=1.518] 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 xNAefWFKQATN for <mpls@ietfa.amsl.com>; Tue, 14 Jan 2014 09:25:39 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 07C221AE14B for <mpls@ietf.org>; Tue, 14 Jan 2014 09:25:35 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0EHPN6T099308; Tue, 14 Jan 2014 12:25:23 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401141725.s0EHPN6T099308@maildrop2.v6ds.occnc.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
Subject: Re: ��: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
In-reply-to: Your message of "Tue, 14 Jan 2014 03:32:09 +0000." <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08244868@NKGEML512-MBS.china.huawei.com>
Date: Tue, 14 Jan 2014 12:25:23 -0500
Cc: "mpls@ietf.org" <mpls@ietf.org>, IETF <ietf@ietf.org>, "Eggert, Lars" <lars@netapp.com>, Scott Brim <scott.brim@gmail.com>
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.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: Tue, 14 Jan 2014 17:25:40 -0000

In message <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08244868@NKGEML512-MBS.china.huawei.com>
Xuxiaohu writes:
 
> Hi Curtis and Joel,
>  
> Thanks a lot for your detailed comments.
>  
> Hi Lars,
>  
> I wonder whether the following compromised text for the Congestion
> Consideration section of this doc is roughly acceptable to you.
>  
>    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 MPLS 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 MPLS 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 which is outside the scope
>    of this document.
> 
> Best regards,
> Xiaohu

This works for me.  If deployments indicate a need for congestion
control another document can be written.  I doubt it will be needed.
If someone (Lars perhaps) feels a pressing need to wirte a congestion
control for MPLS over UDP document (or for any tunneling over UDP)
regardless of deployment experience, then they can go ahead.

Whether it works for Lars may be the issue.

Curtis