[L2tpext] FW: comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel

"Xialiang (Frank)" <frank.xialiang@huawei.com> Tue, 17 December 2013 03:19 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: l2tpext@ietfa.amsl.com
Delivered-To: l2tpext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93101AE07C for <l2tpext@ietfa.amsl.com>; Mon, 16 Dec 2013 19:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level:
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 bbTKt67yfqkJ for <l2tpext@ietfa.amsl.com>; Mon, 16 Dec 2013 19:19:15 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8531AE063 for <l2tpext@ietf.org>; Mon, 16 Dec 2013 19:19:14 -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.7-GA FastPath queued) with ESMTP id BBM73527; Tue, 17 Dec 2013 03:19:11 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:18:43 +0000
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 03:19:10 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.128]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 11:19:06 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "maciek@cisco.com" <maciek@cisco.com>, "Giles Heron (giheron)" <giheron@cisco.com>, "rainer.schatzmayr@telekom.de" <rainer.schatzmayr@telekom.de>, "wim.henderickx@alcatel-lucent.com" <wim.henderickx@alcatel-lucent.com>
Thread-Topic: comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel
Thread-Index: Ac7yVZwTFri13v8WQ2CW22pVy1gYCQIgHFeQ
Date: Tue, 17 Dec 2013 03:19:05 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F10F3BE891@SZXEMA502-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.42.220]
Content-Type: multipart/mixed; boundary="_004_C02846B1344F344EB4FAA6FA7AF481F10F3BE891SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "l2tpext@ietf.org" <l2tpext@ietf.org>
Subject: [L2tpext] FW: comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2tpext/>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 03:19:18 -0000

Hi authors,
I have sent this email of comments for a period of time, but don't get response.
So I try to send it again and hope for getting your kindly feedback.
Thanks!

B.R.
Frank

From: L2tpext [mailto:l2tpext-bounces@ietf.org] On Behalf Of Xialiang (Frank)
Sent: Friday, December 06, 2013 3:35 PM
To: maciek@cisco.com; Giles Heron (giheron); rainer.schatzmayr@telekom.de; wim.henderickx@alcatel-lucent.com
Cc: l2tpext@ietf.org
Subject: [L2tpext] comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel

Hi authors,
I have reviewed this draft, and consider it a useful draft for giving a concrete use case of using mature L2TPv3 protocol as a data plane overlay technology. I also have several comments below:

1.       You use a source+des IP pair to identify a L2TP tunnel without tenant id carried on the wire. It increases the complexity when identifying tenant network's traffic using the mapping between tenant network and a large number of source+des IP pairs, especially when tenant network are highly distributed in the real network. While, using tenant id carried on the wire can reduce the complexity largely;

2.       Would you consider more general use cases, e.g., supporting IPv4 underlay network, and different types of services overlaid on it (e.g., Ethernet, PPP, IPv4, IPv6 ,etc)?

3.       I cannot find contents in the draft describing how to implement the multipoint VPN in detail. If you don't use control plane, then data plane flooding or manage plane provision should be supported. Do you follow this way?

B.R.
Frank