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

From: Qi Sun <[email-masked]>
Date: Mon, 19 Jan 2015 14:50:25 +0100

Dear authors, 

I have read draft-shen-l2tpext-l2tpv3-yang-model-00, which provides the configuration and management of l2tpv3 tunnels. A few comments below.

The most significant one is that, this YANG model is about managing RFC3931 in general, which does not cover the requirements from draft-ietf-l2tpext-keyed-ipv6-tunnel. Since the essence of draft-ietf-l2tpext-keyed-ipv6-tunnel (as I see) is to simplify L2TPv3 tunnel by taking some parts from RFC3931, the YANG model for L2TPv3 should also be able to cover the YANG model for keyed-v6-tunnel. 

I’ve worked out a YANG diagram tree for keyed-v6-tunnel (and a YANG model). The YANG model makes use of some parts from the l2tpv3-yang-model (especially the “static” case), and also adds some parameters for its own. Since the length of Cookie should always be 64 bits, the following YANG model doesn’t include it as a parameter to configure.

<YANG for keyed-v6-tunnel>
module: keyed-v6-l2tpv3
  +--rw keyed-v6-l2tpv3
     +--rw enabled?                          boolean
     +--rw l2tpv3TunnelInstances   
        +--rw l2tpv3TunnelInstance* [tunnelName]
           +--rw tunnelName                  string 
           +--rw srcIfName                     if:interface-ref // *unique*
           +--rw srcIPv6                         inet:ipv6-address  /* unique *
           +--rw dstIPv6                         inet:ipv6-address   *        */
           +--rw localSessionId?             uint32 
           +--rw remoteSessionId?         uint32 
           +--rw localCookies
           |  +--rw localCookie* [cookieName]
           |     +--rw cookieName            enumeration // "new"/"old"
           |     +--rw localHighCookie       hexBinary
           |     +--rw localLowCookie        hexBinary
           +--rw remoteCookie
           |  +--rw remoteHighCookie         hexBinary
           |  +--rw remoteLowCookie          hexBinary
           +--rw mtu                                 unit16
           +--rw (oam_method)
           |  +--:(ieee8021ag!)
           |  +--:(ituy1731!)
           +--rw vccv_enabled?               boolean
//There is a separate “operational state” subtree, which isn’t shown above. 
</YANG for keyed-v6-tunnel>

I’m thinking if it’s a good idea to merge the two models (with some explanation text or a separate section in the l2tpv3-yang-model draft), since there are some similarities. Otherwise, a separate I-D could be written to document the keyed-v6-tunnel YANG. 

Could you, authors and the WG, share your ideas on this? Thanks a lot!

Here are a few more comments on the content of the draft, detailed as follows.
1) According to RFC3931, the L2TPv3 tunnel should support the mode of “one tunnel, multiple sessions”. However, the current YANG model doesn’t support it. I would suggest the parameter of Sessionid be a list, with corresponding modifications. 
2) The expression of choice-case structure in the diagram tree is not the common style used by other YANG models. Please refer to RFC7277.
3) Typically, there is a separate operational state subtree for those “ro” parameters. Some restructures might be helpful to make the model clearer, if you like. Also refer to RFC 7277.

Hope that helps.

Cheers,
Qi

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 21 Jan 2015 03:12:50 +0000

Hi Qi,

Thanks much for your review and comments. Replies are inline.

> -----Original Message-----
> From: L2tpext [mailto:[email-masked]] On Behalf Of Qi Sun
> Sent: Monday, January 19, 2015 9:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [L2tpext] Comments on l2tpv3-yang-model: Covering
> keyed-v6-tunnel?
> 
> Dear authors,
> 
> I have read draft-shen-l2tpext-l2tpv3-yang-model-00, which provides the
> configuration and management of l2tpv3 tunnels. A few comments below.
> 
> The most significant one is that, this YANG model is about managing
> RFC3931 in general, which does not cover the requirements from
> draft-ietf-l2tpext-keyed-ipv6-tunnel. Since the essence of
> draft-ietf-l2tpext-keyed-ipv6-tunnel (as I see) is to simplify L2TPv3 tunnel by
> taking some parts from RFC3931, the YANG model for L2TPv3 should also be
> able to cover the YANG model for keyed-v6-tunnel.
> 
> I've worked out a YANG diagram tree for keyed-v6-tunnel (and a YANG
> model). The YANG model makes use of some parts from the
> l2tpv3-yang-model (especially the "static" case), and also adds some
> parameters for its own. Since the length of Cookie should always be 64 bits,
> the following YANG model doesn't include it as a parameter to configure.
> 
> //There is a separate "operational state" subtree, which isn't shown
> above.
> I'm thinking if it's a good idea to merge the two models (with some
> explanation text or a separate section in the l2tpv3-yang-model draft), since
> there are some similarities. Otherwise, a separate I-D could be written to
> document the keyed-v6-tunnel YANG.
> 

[Bing] Actually, supporting l2tpext-keyed-ipv6-tunnel is an important goal when we wrote the YANG model. But it was not specifically called out in the draft. Maybe we need to make it clearer in the next version.
I think the essential management objects of l2tpext-keyed-ipv6-tunnel are already in the current draft, just as you said, they are in the "static" case. And we thought it might be better to include it in just one l2tpv3 model.

Some new elements you proposed are:
- rw MTU
We thought it might be good to add this element to current model, since the NMS might need to configure this parameter. Thanks for the suggestion.
- rw (oam_method)
The OAM function is needed. But I'm not sure whether it should be defined in L2TPv3 model? Maybe leave it to the OAM relevant models is a better choice.
- rw vccv_enabled
I don't know what it means. Would you mind explain it? Thanks.

> 1) According to RFC3931, the L2TPv3 tunnel should support the mode of
> "one tunnel, multiple sessions". However, the current YANG model doesn't
> support it. I would suggest the parameter of Sessionid be a list, with
> corresponding modifications.
[Bing] For auto tunnels, we didn't define the session objects in current model, since we thought the sessions are automatically generated by the protocol module thus don't need to be managed. So I think there is no limitation to forbidden multi-sessions-per-tunnel in current model. But your comment triggered me to think of that maybe we need to define read-only objects to allow the NMS to read the automatically generated sessions (and probably reflect the multi-sessions-per-tunnel feature). We'll consider it in the next version. What's your opinion on this?

For l2tpext-keyed-ipv6-tunnel, there is no problem since each keyed IPv6 tunnel has one and only one associated session, there is no problem of it.

> 2) The expression of choice-case structure in the diagram tree is not the
> common style used by other YANG models. Please refer to RFC7277.
[Bing] I don't quite understand. Would you mind elaborating more? Thanks.

> 3) Typically, there is a separate operational state subtree for those "ro"
> parameters. Some restructures might be helpful to make the model clearer, if
> you like. Also refer to RFC 7277.
[Bing] A good suggestion. We'll do it in the next version. Thanks.

Best regards,
Bing

> 
> Cheers,
> Qi
> 
> 
> 
> 
> 
> 
> _______________________________________________
> L2tpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Qi Sun <[email-masked]>
Date: Wed, 21 Jan 2015 10:07:50 +0100

Hi Bing, 

Thanks for response. Please see inline.

Cheers,
Qi

> I think the essential management objects of l2tpext-keyed-ipv6-tunnel are already in the current draft, just as you said, they are in the "static" case. And we thought it might be better to include…

[Qi] I also think it would be good that we just have one model. The question with the current version is that, there is no text mentioning l2tpext-keyed-ipv6-tunnel, neither a reference to that draft, which confusing me how to manage the l2tpext-keyed-ipv6-tunnel if someone only reads this YANG model draft. It would be helpful if some text/section is added for that draft, IMHO. 

Do you think adding some “default” values for some parameters to make it default to act as a keyed-v6-tunnel would helpful to explicitly express the support for keyed-v6-tunnel? Not sure if this is a good idea. 

> The OAM function is needed. But I'm not sure whether it should be defined in L2TPv3 model? Maybe leave it to the OAM relevant models is a better choice.

[Qi] I’m not trying to define management for OAM function here. It’s only a “switch” to turn the function on/off. If you read the code, the it’s only a presence container which conveys the information of whether this function is enabled. 

For more info, please refer to this: http://tools.ietf.org/html/rfc6020#section-7.5.1
There is an example which illustrates the presence container with the “ssh” function. That container doesn’t define management parameters for ssh, just enable ssh or not. 

> I don't know what it means. Would you mind explain it? Thanks.

[Qi] Sorry for not describing it clearly. It is mentioned in https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-01#section-6 :
“
   In addition the Pseudowire Virtual Circuit Connectivity Verfiication
   ( VCCV ) RFC5085 [RFC5085] MAY be used.
"

> [Bing] For auto tunnels, we didn't define the session objects in current model, since we thought the sessions are automatically generated by the protocol module thus don't need to be managed. So I think there is no limitation to forbidden multi-sessions-per-tunnel in current model.

[Qi] It’s only correct for the case os “auto tunnels”. Not true for the “static” branch. I don’t think there is a limitation in _RFC3931_ that the static configuration of l2tpv3 only supports “one session per tunnel”?

> But your comment triggered me to think of that maybe we need to define read-only objects to allow the NMS to read the automatically generated sessions (and probably reflect the multi-sessions-per-tunnel feature). We'll consider it in the next version. What's your opinion on this?

[Qi] Agreed. That’s why I suggested to include a operational state subtree for the model. That subtree should be able to get all information that might be useful for operating the system.

> For l2tpext-keyed-ipv6-tunnel, there is no problem since each keyed IPv6 tunnel has one and only one associated session, there is no problem of it.

[Qi] Right. 

> [Bing] I don't quite understand. Would you mind elaborating more? Thanks.

[Qi] Sure. Please see the following example.

<draft-shen-l2tpext-l2tpv3-yang-model-00>
            +-- rw tunnelType                           enum
            |     +-- rw static:
            |     |   +-- rw localSessionId?            uint32
            |     |   +-- rw remoteSessionId?           uint32
            ...  ...  ...
            |     +-- rw auto:
            |           +-- rw ctrlName            string
            |           +-- rw encapType           enum
</draft-shen-l2tpext-l2tpv3-yang-model-00>

<RFC7277>
           |  +--rw address* [ip]
           |  |  +--rw ip               inet:ipv4-address-no-zone
           |  |  +--rw (subnet)
           |  |     +--:(prefix-length)
           |  |     |  +--rw ip:prefix-length?   uint8
           |  |     +--:(netmask)
           |  |        +--rw ip:netmask?         yang:dotted-quad
</RFC7277>

In your code, the parameter “tunnelType” is a “choice” and both “static” and “auto” are cases. The expression of choice-case in the diagram tree is not typical in other YANG models, e.g. RFC7277, RFC7407, etc. Here I extract the related part from RFC7277, where “subset” is a choice and “prefix-length” and “netmask” are cases.
There are some other “choice"s, which might need improving.

And typically, there is an explanation in those YANG RFCs, saying that:

   o  Brackets "[" and "]" enclose list keys.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write), and "ro" means state data (read-only).

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

Not sure if the practice has changed since I don’t quite follow the netmod WG. Please keep me up-to-date if the netmod WG has decided to use a different pattern. Thanks!

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 22 Jan 2015 09:07:08 +0000

Hi Qi,

[Qi] I also think it would be good that we just have one model. The question with the current version is that, there is no text mentioning l2tpext-keyed-ipv6-tunnel, neither a reference to that draft, which confusing me how to manage the l2tpext-keyed-ipv6-tunnel if someone only reads this YANG model draft. It would be helpful if some text/section is added for that draft, IMHO.
[Bing2] Thanks for pointing this out. Some texts regarding to l2tpext-keyed-ipv6-tunnel in the next version would be good.

Do you think adding some "default" values for some parameters to make it default to act as a keyed-v6-tunnel would helpful to explicitly express the support for keyed-v6-tunnel? Not sure if this is a good idea.
[Bing2] If I understood correctly, the keyed-v6-tunnel is a specific behavior of L2TPv3. So for the "default" values you mentioned, did you mean an/several objects in the model to allow the NMS to configure the device behaving in the keyed-v6-tunnel mode?

[Qi] I'm not trying to define management for OAM function here. It's only a "switch" to turn the function on/off. If you read the code, the it's only a presence container which conveys the information of whether this function is enabled.

For more info, please refer to this: http://tools.ietf.org/html/rfc6020#section-7.5.1
There is an example which illustrates the presence container with the "ssh" function. That container doesn't define management parameters for ssh, just enable ssh or not.

- rw vccv_enabled

[Qi] Sorry for not describing it clearly. It is mentioned in https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-01#section-6 :
"
   In addition the Pseudowire Virtual Circuit Connectivity Verfiication
   ( VCCV ) RFC5085<https://tools.ietf.org/html/rfc5085> [RFC5085<https://tools.ietf.org/html/rfc5085>] MAY be used.
"
[Bing2] Thanks for your explanation. I think the OAM and VCCV objects belong to the same issue that to switch other protocols on/off in the L2TPv3 tunnels configurations. I believe it's a very common configuration style in current devices. So I think it's good to have the switches in the model.

Here are a few more comments on the content of the draft, detailed as
follows.

[Qi] It's only correct for the case os "auto tunnels". Not true for the "static" branch. I don't think there is a limitation in _RFC3931_ that the static configuration of l2tpv3 only supports "one session per tunnel"?
[Bing2] RFC3931 seems not specifically define a "static" mode. The static tunnels in the YANG model were defined for the keyed-ipv6-tunnels. Did you propose to specifically defined a static L2TPv3 mode along with keyed-ipv6-tunnel in the model?

<RFC7277>
           |  +--rw address* [ip]

In your code, the parameter "tunnelType" is a "choice" and both "static" and "auto" are cases. The expression of choice-case in the diagram tree is not typical in other YANG models, e.g. RFC7277, RFC7407, etc. Here I extract the related part from RFC7277, where "subset" is a choice and "prefix-length" and "netmask" are cases.
There are some other "choice"s, which might need improving.

Not sure if the practice has changed since I don't quite follow the netmod WG. Please keep me up-to-date if the netmod WG has decided to use a different pattern. Thanks!

[Bing2] Thanks for the detailed explanation. We'll consider it in the next version.

Best regards,
Bing

---

From: Qi Sun <[email-masked]>
Date: Thu, 22 Jan 2015 14:23:53 +0100

Hi Bing, 

Thanks for the reply. Please see inline.

Best Regards,
Qi

> [Bing2] Thanks for pointing this out. Some texts regarding to l2tpext-keyed-ipv6-tunnel in the next version would be good.

[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:

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

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.

> [Bing2] If I understood correctly, the keyed-v6-tunnel is a specific behavior of L2TPv3. So for the “default” values you mentioned, did you mean an/several objects in the model to allow the NMS to configure the device behaving in the keyed-v6-tunnel mode?

[Qi] That was my intension. However, it seems that the netmod wg would prefer not to have default values in a YANG model, since the YANG model should be generic. So, the current status might be OK. 

> [Bing2] Thanks for your explanation. I think the OAM and VCCV objects belong to the same issue that to switch other protocols on/off in the L2TPv3 tunnels configurations. I believe it’s a very common configuration style in current devices. So I think it’s good to have the switches in the model.

[Qi] Agreed.

> [Bing2] RFC3931 seems not specifically define a “static” mode. The static tunnels in the YANG model were defined for the keyed-ipv6-tunnels. Did you propose to specifically defined a static L2TPv3 mode along with keyed-ipv6-tunnel in the model?

[Qi] Not really. It’s just a little confusing to me, since currently it reads like that part in the tree is intended to manage the static L2TPv3 tunnel, which is not the your purpose according to your response. Note that the draft is titled with “YANG data model for L2TPv3 Tunnel”.

> [Bing2] Thanks for the detailed explanation. We’ll consider it in the next version.
> 
> 
> 
> Best regards,
> Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 23 Jan 2015 10:07:25 +0000

Hi Qi,

Please see replies inline.

[Bing3] If supporting multiple sessions per tunnel, it should be a list.

(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?

I can help to provide some text about the keyed-v6-tunnel, if you like.
[Bing3] That would be good, thanks in advance.

[Qi] That was my intension. However, it seems that the netmod wg would prefer not to have default values in a YANG model, since the YANG model should be generic. So, the current status might be OK.
[Bing3] I also think default values might not be necessary.

[Qi] Not really. It's just a little confusing to me, since currently it reads like that part in the tree is intended to manage the static L2TPv3 tunnel, which is not the your purpose according to your response. Note that the draft is titled with "YANG data model for L2TPv3 Tunnel".
[Bing3] For auto tunnels, we defined the model according to RFC3931; for static tunnels, we followed the keyed-ipv6-tunnel. Does it make sense to you?

Thanks.

Best regards,
Bing

---

From: Qi Sun <[email-masked]>
Date: Fri, 23 Jan 2015 12:37:11 +0100

Hi Bing,

Inline, please.

On Jan 23, 2015, at 11:07 AM, Liubing (Leo) <[email-masked]> wrote:

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

> [Bing3] For auto tunnels, we defined the model according to RFC3931; for static tunnels, we followed the keyed-ipv6-tunnel. Does it make sense to you?

[Qi] Yes. Then here comes another question: is the subtree “l2tpv3CtrlInstances” used for both the “auto” mode and the “static” mode? I assume it to be “NO”. But the current structure makes it confusing, at least to me. 

Would it be reasonable to use two “features", one for auto tunnels with “CtrlInstances” and the other for the static tunnels (keyed-v6-tunnel)? So the devices only supporting “keyed-v6-tunnel” function don’t necessary implement the control plan parameters.

Best Regards,
Qi

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 26 Jan 2015 09:30:55 +0000

Hi Qi,

>> [Bing3] For auto tunnels, we defined the model according to RFC3931; 
>> for static tunnels, we followed the keyed-ipv6-tunnel. Does it make sense to you?

> [Qi] Yes. Then here comes another question: is the subtree "l2tpv3CtrlInstances" 
> used for both the "auto" mode and the "static" mode? I assume it to be "NO". 
> But the current structure makes it confusing, at least to me. 
[Bing] You're right. The CtrlInstances only applies for "auto" mode. The ctrlName node under the auto tunnel list references the relevant CtrlInstance.
We'll make it clearer in the next version.

> Would it be reasonable to use two "features", one for auto tunnels 
> with "CtrlInstances" and the other for the static tunnels (keyed-v6-tunnel)? 
> So the devices only supporting "keyed-v6-tunnel" function don't necessary implement the control plan parameters.
[Bing] Personally, I think it's a good idea. Let's hear others' opinions when update the next version. Thank you.

Best regards,
Bing

---

From: Qi Sun <[email-masked]>
Date: Fri, 30 Jan 2015 11:46:32 +0100

Hi Bing,

Some further replies. Please see inline. Thanks.

On Fri, Jan 23, 2015 at 12:37 PM, Qi Sun <[email-masked]> 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] 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] 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 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