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

[Qi Sun <[e-mail]>]

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.



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

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