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

Hi Bing, 

Thanks for the reply. Please see inline.

Best Regards,
Qi

On Jan 22, 2015, at 10:07 AM, Liubing (Leo) <[email protected]> wrote:

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

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

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

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

[Qi] Agreed.

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

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