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

[Qi Sun <[e-mail]>]

Hi Bing, 

Thanks for responses. 

> 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.

The reason I bring up this is that, for the static mode (keyed v6 tunnel) the NC client knows the SessionID & the Cookies since it configures it. However, for the auto mode, the SessionID & Cookies are generated locally or through negotiation, which might be unknown by the NC client (I think). 

Yes, please consider whether it’s necessary to include the paras as operational paras.

Thanks,
Qi

On Feb 4, 2015, at 11:41 AM, Liubing (Leo) <[e-mail]> wrote:

> 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:[e-mail]] 
> Sent: Friday, January 30, 2015 6:47 PM
> To: Liubing (Leo)
> Cc: [e-mail]; [e-mail]
> 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 <[e-mail]> 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