Re: [mpls] Some question on draft-xu-mpls-in-udp-04

Lucy yong <lucy.yong@huawei.com> Wed, 05 December 2012 20:22 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AAA21F8B9A for <mpls@ietfa.amsl.com>; Wed, 5 Dec 2012 12:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.555
X-Spam-Level:
X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SzspioudPWK for <mpls@ietfa.amsl.com>; Wed, 5 Dec 2012 12:22:38 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 626FE21F89E4 for <mpls@ietf.org>; Wed, 5 Dec 2012 12:22:37 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN25985; Wed, 05 Dec 2012 20:22:36 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 20:22:04 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 20:22:35 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 12:22:28 -0800
From: Lucy yong <lucy.yong@huawei.com>
To: Vivek Kumar <kvivek@broadcom.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Some question on draft-xu-mpls-in-udp-04
Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPAATKWrw
Date: Wed, 05 Dec 2012 20:22:28 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx>
References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com>
In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.83.123]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4485F82Cdfweml505mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [mpls] Some question on draft-xu-mpls-in-udp-04
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 05 Dec 2012 20:22:39 -0000

Hi Vivek,

I share my opinion. Please see below.

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vivek Kumar
Sent: Wednesday, December 05, 2012 5:19 AM
To: mpls@ietf.org
Subject: [mpls] Some question on draft-xu-mpls-in-udp-04

Hi  Authors,

I have some question.


1)      The  draft-xu-mpls-in-udp-04 main purpose seems to be for proving load balancing in IP network for MPLS packets.  Is that the only use case of this new encapsulation method or there can be some more ?
[Lucy] This draft proposes mpls-in-udp format to enable better load balancing in IP network for MPLS payload. In fact, as section 4 states, the udp encapsulation can apply other applications beside MPLS, for example, IP. However, potential for other applications are outside scope of this draft. We plan to have another draft describe the udp encapsulation in general as mentioned in section 4.


2)      The draft says that ingress PE router will calculate entropy and  encapsulate UDP header with src port containing entropy value . Does this mean that only PE routers can do UDP encap since PE router can look deep inside the packet to calculate entropy ?
                What if LSR's want to initiate UDP tunnel ?
[Lucy] Yes, the solution requires PE to support UDP and proposes to reserve two UDP port number to indicate the payload type. PE understands the payload and can get some flow entropy from the payload and insert into UDP src port. Could you elaborate what is the UDP tunnel?

Lucy

Kindly provide your comments .

Regards,
Vivek