draft-kumar-sfc-nsh-udp-transport & draft-ietf-rtgwg-dt-encap
Xuxiaohu <xuxiaohu@huawei.com> Wed, 22 July 2015 08:38 UTC
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3811B1ACE4F for <rtgwg@ietfa.amsl.com>; Wed, 22 Jul 2015 01:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 S8LiH6T0eIfp for <rtgwg@ietfa.amsl.com>; Wed, 22 Jul 2015 01:38:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB811ACE67 for <rtgwg@ietf.org>; Wed, 22 Jul 2015 01:38:05 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZA51206; Wed, 22 Jul 2015 08:38:04 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Jul 2015 09:38:03 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.210]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 22 Jul 2015 16:37:57 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: draft-kumar-sfc-nsh-udp-transport & draft-ietf-rtgwg-dt-encap
Thread-Topic: draft-kumar-sfc-nsh-udp-transport & draft-ietf-rtgwg-dt-encap
Thread-Index: AdDEWSFvbiu7coO6S1O+4f+tz2o7RQ==
Date: Wed, 22 Jul 2015 08:37:57 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB007D6@NKGEML512-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.65.208]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/vvaeyBP2jdncWayF83pIMCUvLpo>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 08:38:10 -0000
Hi all, First of all, I like the idea of directly encapsulating NSH over UDP since it eliminates the unnecessary VXLAN header encapsulation burden. However, there are still many headaches surrounding any UDP-based encapsulation proposal such as congestion controll, IPv6/UDP checksum, MTU and fragmentation, UDP dest port resource utilization. Since UDP has been selected as a tunnelling technology by more and more encapsulation proposals besides NSH-in-UDP, including but not limited to VXLAN, VXLAN-GPE, MPLS-in-UDP, IP-in-UDP, TRILL-in-UDP, draft-ietf-rtgwg-dt-encap would be more useful in practice if it could give us concrete recommendations regarding the above headaches surrounding the UDP tunnelling usage, IMHO. Best regards, Xiaohu