Re: [Rift] RIFT YANG datamodel implementation
zhang.zheng@zte.com.cn Tue, 16 March 2021 02:29 UTC
Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73F63A17D0 for <rift@ietfa.amsl.com>; Mon, 15 Mar 2021 19:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4exlkYLCOvT for <rift@ietfa.amsl.com>; Mon, 15 Mar 2021 19:29:06 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99103A17CD for <rift@ietf.org>; Mon, 15 Mar 2021 19:29:05 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 08A5497E99EEC0F6DC23; Tue, 16 Mar 2021 10:29:03 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 12G2T0VD065555; Tue, 16 Mar 2021 10:29:00 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Tue, 16 Mar 2021 10:29:00 +0800 (CST)
Date: Tue, 16 Mar 2021 10:29:00 +0800
X-Zmail-TransId: 2afb605017ec15bc929f
X-Mailer: Zmail v1.0
Message-ID: <202103161029002897305@zte.com.cn>
In-Reply-To: <CA+wi2hNvMcAkpz1yp__sKEQ8nW2_+eBbfENNfaXqWYN4h7kKjA@mail.gmail.com>
References: AF13C9C6-8493-45F7-823E-D4C0B57435C9@gmail.com, CA+wi2hNvMcAkpz1yp__sKEQ8nW2_+eBbfENNfaXqWYN4h7kKjA@mail.gmail.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: tonysietf@gmail.com
Cc: brunorijsman@gmail.com, rift@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 12G2T0VD065555
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/mpR8qBFCjxuFTgKV5DH8WHyW6nM>
Subject: Re: [Rift] RIFT YANG datamodel implementation
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 02:29:09 -0000
Hi tony, Sorry for the late response. Thank you very much for your detailed review! About you comments, could you please find my comments/question below with Sandy>? Much appreciate for it. Best regards, Sandy 原始邮件 发件人:TonyPrzygienda 收件人:Bruno Rijsman; 抄送人:rift@ietf.org; 日 期 :2021年03月10日 19:29 主 题 :Re: [Rift] RIFT YANG datamodel implementation _______________________________________________ RIFT mailing list RIFT@ietf.org https://www.ietf.org/mailman/listinfo/rift Just reviewed stuff carefully as well (also based on _real_ implemenation ;-) but not Yang implementation). comment on -02 +--ro hierarchy-indications? enumeration that's bit more complex, we're lacking leaf_only_and_leaf_2_leaf_procedures = 1, which should be configurable Sandy> The type of "hierarchy-indications" is enumeration, and "leaf_only_and_leaf_2_leaf_procedures" is included in it. Now the leaf is not configurable, do you mean this leaf should be changed to configurable? also, observe that level == 24 that can be configued is NOT equivalent to top-of-fabric which is a special flag so leaf configured-level { type level; description "The configured level value of this node."; } should be something much more complex around a union of tof leaf-only leaf-with-leaf-2-leaf numeric Sandy> I'd like to add more description: "The value '0' indicates leaf-only, the value "1" indicates leaf-with-leaf-2-leaf, and the value "2' indicates tof." Do you think it's OK? then overload in configuration sense should be overload { status: true/false timeout: optional timeout on config element } so I'd split between configured-overload and in-overload or just overload Sandy> What's the meaning of "timeout"? Now in the model, the local "overload" is configurable, the "overload" in node TIE isn't configurable. if we allow to configure maximum nonce delta we should probably also allow to configure lifetime delta (both are pretty dangerous since they can break convergence real fast) +--rw holdtime? should be global-holdtime Sandy> OK. since that can be ultimately per link same for tide generation +--rw tie-security-key-id? uint32 that should refer to standard yang security chain as e.g. OSPF uses that should be also originating-key-id or something since we need (missing right now) the keys we are willing to accept as RW Sandy> May I change this to the following, it's borrowed from OSPF YANG model. The crypto-algorithm has many types, does RIFT support all of them, or just some of them? | | | | +--rw tie-security | | | | +--:(auth-key-chain)? | | | | | +--rw key-chain? | | | | | key-chain:key-chain-ref | | | | +--:(auth-key-explicit) | | | | +--rw key-id? uint32 | | | | +--rw key? string | | | | +--rw crypto-algorithm? | | | | identityref on acceptance we need following variants SecurityChecking { NoChecking, Permissive, Loose, Strict, } Sandy> OK.same @ link level for the security keys Sandy> OK. Once you confirm the security key format, it will be syned to interface. look @ YAML model we use in open source RIFT to see further details own pod missing Sandy> The "pod" is the fourth leaf in node, please check it agin, do I make some mistakes? @ interface level what is +--ro hal? level it seems backwards, HAL is of level type, no? Sandy> The "HAL" is "The highest defined level value seen from all valid level offers received." Does the description need to be improved?also list of HAL systemid offers is helpful here Sandy> OK. I can add the systemid which offer the level.also on link add instance-name Sandy> Do you mean the RIFT instance name? The whole model is following an instance, so the interface is also belong the same instance with the node. Different instances are distinguished by the node. DATABASE | +--ro (type)? | | +--:(prefix) | | +--:(positive-disaggregation) | | +--:(negative-disaggregation) | | +--:(external) | | +--:(positive-external-disaggregation) | | +--:(pgp) oder strictly per thrift model since order has meaning here Sandy> OK. I'll modify the order according to section 8.2.28.1. | | +--ro link-id-pair* [remote-id] | | | +--ro local-id? uint32 | | | +--ro remote-id uint32 | | | +--ro if-index? uint32 Rijsman, et al. Expires August 26, 2021 [Page 7] Internet-Draft RIFT YANG Model February 2021 | | | +--ro if-name? if:interface-ref | | +--ro cost? uint32 | | +--ro bandwidth? uint32 | | +--ro flood-reduction? boolean | | +--ro received-link-capabilities | | +--ro bfd? boolean | | +--ro v4-forwarding-capable? boolean missing 14: optional set<common.AddressFamilyType> (python.immutable = "") address_families; Sandy> OK. I'll add it. Thanks, Sandy On Tue, Mar 9, 2021 at 2:55 PM Bruno Rijsman <brunorijsman@gmail.com> wrote: I did not attend yesterday's RIFT working group meeting for IETF 110 live, but I did just finish watching the video recording. At offset 21:17 in the video there is a question about whether my RIFT-Python open source implementation has implemented the proposed YANG data model. The answer is that I have not actually implemented the YANG data model, so I won't be able to submit an implementation report. I did very carefully review the YANG data model. I checked which of the attributes in the YANG data model could be supported by my implementation (or any other reasonable implementation). And also, based on the attributes that are reported / configurable in the open source code I made suggestions about adding new attributes to the YANG data model. My comments on the YANG data model are based “on real implementation” in that narrow sense, it is not based on actually implementing the YANG data model. -- Bruno _______________________________________________ RIFT mailing list RIFT@ietf.org https://www.ietf.org/mailman/listinfo/rift
- [Rift] RIFT YANG datamodel implementation Bruno Rijsman
- Re: [Rift] RIFT YANG datamodel implementation Tony Przygienda
- Re: [Rift] RIFT YANG datamodel implementation Jeffrey (Zhaohui) Zhang
- Re: [Rift] RIFT YANG datamodel implementation zhang.zheng
- Re: [Rift] RIFT YANG datamodel implementation Tony Przygienda
- Re: [Rift] RIFT YANG datamodel implementation zhang.zheng
- Re: [Rift] RIFT YANG datamodel implementation Tony Przygienda
- Re: [Rift] RIFT YANG datamodel implementation zhang.zheng
- Re: [Rift] RIFT YANG datamodel implementation Tony Przygienda
- Re: [Rift] RIFT YANG datamodel implementation zhang.zheng
- Re: [Rift] RIFT YANG datamodel implementation zhang.zheng