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

"Xialiang (Frank)" <frank.xialiang@huawei.com> Fri, 06 December 2013 07:34 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 039091A1F76 for <l2tpext@ietfa.amsl.com>; Thu, 5 Dec 2013 23:34:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 b9Rhnd3ty0xF for <l2tpext@ietfa.amsl.com>; Thu, 5 Dec 2013 23:34:47 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5351C1A1F5F for <l2tpext@ietf.org>; Thu, 5 Dec 2013 23:34:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR42970; Fri, 06 Dec 2013 07:34:41 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 07:33:47 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 07:34:39 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.82]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 15:34:35 +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: Ac7yVZwTFri13v8WQ2CW22pVy1gYCQ==
Date: Fri, 06 Dec 2013 07:34:35 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F10F3AC7D0@SZXEMA502-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.135.42.220]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F10F3AC7D0SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "l2tpext@ietf.org" <l2tpext@ietf.org>
Subject: [L2tpext] 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: Fri, 06 Dec 2013 07:34:50 -0000

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