Re: [L2tpext] Comments on l2tpv3-yang-model: Covering keyed-v6-tunnel?
"Liubing (Leo)" <leo.liubing@huawei.com> Wed, 04 February 2015 10:41 UTC
Return-Path: <leo.liubing@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 C9E6A1A8709 for <l2tpext@ietfa.amsl.com>; Wed, 4 Feb 2015 02:41:49 -0800 (PST)
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 o06ZsWIRjaT5 for <l2tpext@ietfa.amsl.com>; Wed, 4 Feb 2015 02:41:38 -0800 (PST)
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 4618A1A1A92 for <l2tpext@ietf.org>; Wed, 4 Feb 2015 02:41:37 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOT46065; Wed, 04 Feb 2015 10:41:35 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 10:41:34 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.150]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 18:41:26 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Qi Sun <sunqi.csnet.thu@gmail.com>
Thread-Topic: [L2tpext] Comments on l2tpv3-yang-model: Covering keyed-v6-tunnel?
Thread-Index: AQHQM+7qYjUO16skOE6TADghGL7RipzJ3o+w///m7ACAAZwjwIAAPbyAgAHWRED//55BgIAK8isAgAhdZaA=
Date: Wed, 04 Feb 2015 10:41:26 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CEA12A7@nkgeml506-mbx.china.huawei.com>
References: <16AF5805-BD81-49E4-A49E-6E8C696B07B8@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CE97C31@nkgeml506-mbx.china.huawei.com> <446EC7DF-6FB7-422B-8355-9171AD2ACC13@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CE99369@nkgeml506-mbx.china.huawei.com> <0AC612BA-5C9A-42F4-98B4-CB831772BEE5@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F457CE9A8E0@nkgeml506-mbx.china.huawei.com> <4BE66EF7-6936-4FED-BD68-4D88A5B1543C@gmail.com> <CAAtO+X=cZWF72=ywF6Pu1AJrJk8H+aVf7733H856y7s24wrEcw@mail.gmail.com>
In-Reply-To: <CAAtO+X=cZWF72=ywF6Pu1AJrJk8H+aVf7733H856y7s24wrEcw@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.28.241]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/l2tpext/IksTxoE7J_3jB2RvW4uwjre8Vcs>
Cc: "draft-shen-l2tpext-l2tpv3-yang-model@tools.ietf.org" <draft-shen-l2tpext-l2tpv3-yang-model@tools.ietf.org>, "l2tpext@ietf.org" <l2tpext@ietf.org>
Subject: Re: [L2tpext] Comments on l2tpv3-yang-model: Covering keyed-v6-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: Wed, 04 Feb 2015 10:41:50 -0000
Hi Qi, Thanks much for your contribution! Please see replies inline. (Tips: using ******to seperate the former mails.) ************************* quoting former mails************************* From: Qi Sun [mailto:sunqi.csnet.thu@gmail.com] Sent: Friday, January 30, 2015 6:47 PM To: Liubing (Leo) Cc: draft-shen-l2tpext-l2tpv3-yang-model@tools.ietf.org; l2tpext@ietf.org Subject: Re: [L2tpext] Comments on l2tpv3-yang-model: Covering keyed-v6-tunnel? Hi Bing, Some further replies. Please see inline. Thanks. On Fri, Jan 23, 2015 at 12:37 PM, Qi Sun <sunqi.csnet.thu@gmail.com> wrote: [Qi] One thing you might miss in the current YANG model is that, the Local session ID should be a list instead of a node. I think it should look like this: [Bing3] If supporting multiple sessions per tunnel, it should be a list. ... +--rw localCookies | +--rw localCookie* [cookieName] | +--rw cookieName enumeration // "new"/“old" | +--rw cookieLength enumeration // 4, 8 | +--rw localHighCookie hexBinary | +--rw localLowCookie hexBinary … (Actually, for keyed-v6-tunnel, the cookieLength is always 8 octets.) [Bing3] It’s true if the static tunnel object is defined dedicated for keyed-ipv6-tunnel, but then the above mentioned Local session ID should be a node? [Qi] Yes, the Local Session ID should be a node, since it’s “one session per tunnel” as you mentioned earlier. [Qi] I was wrong here. As described in the keyed-v6-tunnel draft (https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-01#section-3 , the last paragraph): <quote> The value of the cookie MUST be able to be changed at any time in a manner that does not drop any legitimate tunneled packets - i.e. the receiver must be willing to accept both "old" and "new" cookie values during a change of cookie value. Cookie values SHOULD be changed periodically. </quote> I think as a general point for static tunnel mode, this is necessary for security reasons. So the localCookies should be a list (with only two items at a time, old and new), instead of being a node. Sorry for the confusion. ************************* quoting ends************************* [Bing4] Thanks for your explanation. ************************* quoting former mails************************* Here is the reference for this design: https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-01#section-3 , the last paragraph. I can help to provide some text about the keyed-v6-tunnel, if you like. [Bing3] That would be good, thanks in advance. Here is the suggested text: 1. Section 1, Introduction [OLD] This document defines a YANG [RFC6020] [RFC6021] data model for L2TPv3 tunnels. [NEW] This document defines a YANG [RFC6020] data model for L2TPv3 tunnels [RFC3931], which also covers the management for the Keyed IPv6 Tunnel mechanism [I.D.ietf-l2tpext-keyed-ipv6-tunnel]. //AND, add normal references to both RFC3931 and I.D.ietf-l2tpext-keyed-ipv6-tunnel 2. Section 3.2, l2tpv3TunnelInstances I suggest to add two subsections to this section, describing the automatic tunnel mode and the static tunnel mode, respectively. [NEW] 3.2.1 Automatic tunnel mode L2TPv3 tunnels defined in [RFC3931] are dynamically built, with the Session ID and Cookie dynamically assigned.Tunnel instances working in this mode only need to be configured with the ctrlName refering to related control instances. 3.2.2 Static tunnel mode In the static tunnel mode, the layer 2 attachment circuits are identified through IP addresses. The Session IDs and Cookie are pre-configured so that the parameters in the control plan are not needed for tunnels establishment. The Keyed IPv6 tunnel [I.D.ietf-l2tpext-keyed-ipv6-tunnel] describes such a mechanism. The static mode is designed to manage L2TPv3 tunnel instances following [I.D.ietf-l2tpext-keyed-ipv6-tunnel]. In this mode, tunnel instances are configured to be "one session per tunnel". The Cookie length SHOULD be 64-bit and the Local Cookie is a list so that the tunnel endpoint can accept both "old" and "new" cookies during a change of cookie value [I.D.ietf-l2tpext-keyed-ipv6-tunnel-01#section-4]. //DISCUSS: Would it be reasonable to retrieve the Session ID and Cookie as operational state parameters both in the aotu and static mode? If so, then a separate "state" subtree should include these parameters despite of the modes. ************************* quoting ends************************* [Bing4] Thanks for the texts, I'll try to include them in the next version. For SeesionID&Cookies as operational parameters, we also talked this issue when writing the draft. We didn't have a strong feeling of including them or excluding them, since we didn't figure out whether they would be necessary management objects. Maybe it's no harm to include them? I'll re-consider it in the next version. Best regards, Bing //NOTE: The text should be updated according to the evolving of the YANG model. Hope it helps. And please feel free to re-edit the text if there is any issue there. Best Regards, Qi
- [L2tpext] Comments on l2tpv3-yang-model: Covering… Qi Sun
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Liubing (Leo)
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Qi Sun
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Liubing (Leo)
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Qi Sun
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Liubing (Leo)
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Qi Sun
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Liubing (Leo)
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Qi Sun
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Liubing (Leo)
- Re: [L2tpext] Comments on l2tpv3-yang-model: Cove… Qi Sun