Re: Comments on l2tpv3-yang-model: Covering keyed-v6-tunnel?
"Liubing (Leo)" <[email protected]> Fri, 23 Jan 2015 10:07:25 +0000
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <8AE0F17B87264D4CAC7DE0AA6C406F457CE9A8E0@nkgeml506-mbx.china.huawei.com> |
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?
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?
Thanks.
Best regards,
Bing
_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext