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

Hi Bing,

Inline, please.

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

> Hi Qi,
>  
> Please see replies inline.
>  
>  
> [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.

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

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