Re: Comments on l2tpv3-yang-model: Covering keyed-v6-tunnel?

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:[email protected]] 
Sent: Friday, January 30, 2015 6:47 PM
To: Liubing (Leo)
Cc: [email protected]; [email protected]
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 <[email protected]> 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext