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

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?

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.

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

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



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

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



Best regards,
Bing

_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext