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

Xuxiaohu <xuxiaohu@huawei.com> Mon, 13 January 2014 02:13 UTC

Return-Path: <xuxiaohu@huawei.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 BA6D31ACCE8; Sun, 12 Jan 2014 18:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.55
X-Spam-Level: *
X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 98qSy6Gt0ND8; Sun, 12 Jan 2014 18:12:58 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 227621A1F64; Sun, 12 Jan 2014 18:12:57 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZW40990; Mon, 13 Jan 2014 02:12:44 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 02:11:57 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 13 Jan 2014 02:12:42 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 13 Jan 2014 10:12:39 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "Eggert, Lars" <lars@netapp.com>, Joel Halpern <jmh@joelhalpern.com>
Thread-Topic: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPDJU4xcLOVIDgI0yv/bpzgg7Unpp9UGqw///RhoCAAHJGgIAACUSAgAAlhQCABCkZ8A==
Date: Mon, 13 Jan 2014 02:12:38 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824422A@NKGEML512-MBS.china.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> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7447E4@eusaamb103.ericsson.se>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "mpls@ietf.org" <mpls@ietf.org>, IETF <ietf@ietf.org>
Subject: [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 02:13:01 -0000


> -----邮件原件-----
> 发件人: mpls [mailto:mpls-bounces@ietf.org] 代表 Gregory Mirsky
> 发送时间: 2014年1月11日 2:24
> 收件人: Eggert, Lars; Joel Halpern
> 抄送: mpls@ietf.org; IETF
> 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS
> in UDP) to Proposed Standard
> 
> Hi Lars,
> I think that " The whole point of running MPLS is to create networks in which
> paths are provisionable, so this is usually not an issue." is only partially correct.
> LDP-based MPLS network is not provisionable and LSPs follow IP best route
> selection. Explicit signaling of LSP is achievable in (G)MPLS by using RSVP(-TE)
> signaling.

+1. With the replacement of a LDP-based LSP tunnel by an IP-based tunnel (e.g., MPLS-in-GRE, MPLS-in-IP or MPLS-in-UDP), the path that the traffic travels through is not changed at all.

Best regards,
Xiaohu

> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eggert, Lars
> Sent: Friday, January 10, 2014 8:10 AM
> To: Joel Halpern
> Cc: mpls@ietf.org; IETF
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
> 
> Hi,
> 
> On 2014-1-10, at 16:36, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> > 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?
> 
> we've been rehashing this discussion several times over the years, e.g., for PWE,
> AMT, etc. In order to carry fixed-rate or otherwise non-congestion-controlled
> traffic over unprovisioned general Internet paths, there needs to be some sort of
> basic congestion control mechanism, like a circuit breaker.
> 
> The whole point of running MPLS is to create networks in which paths are
> provisionable, so this is usually not an issue. But if you start sticking MPLS inside
> of UDP, those packets can go anywhere on the net, so you need mechanisms to
> control the rate of that traffic if it causes congestion, or at the very least you
> need to be able to stop the traffic if it creates severe congestion.
> 
> Lars
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls