Re: [Rift] RIFT YANG datamodel implementation
zhang.zheng@zte.com.cn Sat, 08 May 2021 08:57 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 59E673A4496 for <rift@ietfa.amsl.com>; Sat, 8 May 2021 01:57:45 -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 Mz3HGJNZ6E7Q for <rift@ietfa.amsl.com>; Sat, 8 May 2021 01:57:41 -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 A27D03A4498 for <rift@ietf.org>; Sat, 8 May 2021 01:57:40 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id D642916F8DA40AE6B88E; Sat, 8 May 2021 16:57:38 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id A5B0FF2BE8ACA90A851A; Sat, 8 May 2021 16:57:38 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id 1488vWOY019795; Sat, 8 May 2021 16:57:32 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Sat, 8 May 2021 16:57:31 +0800 (CST)
Date: Sat, 08 May 2021 16:57:31 +0800
X-Zmail-TransId: 2afb6096527bd4cf50ea
X-Mailer: Zmail v1.0
Message-ID: <202105081657319651159@zte.com.cn>
In-Reply-To: <CA+wi2hMktdYNzPmzn_znxhDMa4Kwj9xsa2jBHQTpe=cyPx6YsA@mail.gmail.com>
References: CA+wi2hM3c2QXA3ZJQ3Z+YvWXouU5pnE_XSozg7aSLOy-eKjpLQ@mail.gmail.com, 202103191736077483710@zte.com.cn, CA+wi2hMktdYNzPmzn_znxhDMa4Kwj9xsa2jBHQTpe=cyPx6YsA@mail.gmail.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: tonysietf@gmail.com
Cc: rift@ietf.org, brunorijsman@gmail.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 1488vWOY019795
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/P9D45wLAgUGBN38zqWHOl03qhdE>
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: Sat, 08 May 2021 08:57:46 -0000
Hi Tony, Thank you very much for your comments! I'd like to do the changes below, please review: About 'hierarchy-indications' and 'configured-level',I'd like to change the 'hierarchy-indications' to be read-write in RIFT instance, and it remains read-only in database. And add the following description for the "configured-level": If the 'hierarchy-indications' is set to 'leaf-only' or 'leaf-only-and-leaf-2-leaf-procedures', this value means the minimum value of leaf level. And the combination of this value and 'hierarchy-indications' can also be used to indicate the maximum level value of 'top-of-fabric-level'. About 'overload', the leaf 'overload' is changed to container 'overload', except the configurable boolean value, time-out and associated timeout value are added. About 'lifetime-dalta', a leaf for 'adjusted-lifetime' are added. The name of holdtime is changed to 'global-holdtime'. About the security key id, it is changed to key-chain referenced to RFC8177, and security-checking enum is added. The 'hal' is changed to 'node-hal', and the system-id list of offered nodes is added. The 'address-family' is added to 'link-id-pair'. The database is changed according to the items order, and the several types of prefix are expanded to be shown directly. Should I update the draft to make these changes more clear? Best regards, Sandy 原始邮件 发件人:TonyPrzygienda 收件人:张征00007940; 抄送人:rift@ietf.org;Bruno Rijsman; 日 期 :2021年03月19日 18:45 主 题 :Re: [Rift] RIFT YANG datamodel implementation _______________________________________________ RIFT mailing list RIFT@ietf.org https://www.ietf.org/mailman/listinfo/rift so that deviates from model. hierarchy indications is where the interesting flags go into. configured level is NOT enough. things like leaf-2-leaf procedures are also configurable and part of the hierind -- tony On Fri, Mar 19, 2021 at 10:36 AM <zhang.zheng@zte.com.cn> wrote: Hi Tony, Thank you very much for your quick response! I have some further questions, please find my question below with Sandy1>. Thanks, Sandy 原始邮件 发件人:TonyPrzygienda 收件人:张征00007940; 抄送人:rift@ietf.org;Bruno Rijsman; 日 期 :2021年03月16日 18:20 主 题 :Re: [Rift] RIFT YANG datamodel implementation _______________________________________________ RIFT mailing list RIFT@ietf.org https://www.ietf.org/mailman/listinfo/rift On Tue, Mar 16, 2021 at 3:29 AM <zhang.zheng@zte.com.cn> wrote: 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? yes, you want to be able to configure that 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? well, you can do that but it's really an enum where the value should not matter Sandy1> The "hierarchy-indications" and "configured-level" are both indicate the node's level. The "hierarchy-indications" isn't configurable because it's the actual node level. The "configured-level" it the configured level which can be set by network administrator. I'd like to keep the "hierarchy-indications" non-configurable. And the two leaves use the same enumeration type and values. The value includes the above three types or any other type. Do you think it's OK? But I have a question about it, it seems like we are not define the range of level value. If the maximum level value needs be defined? 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. timeout is used very often. Basically there should be 2 timeouts on-startup this means node goes into overload until this tiemr expires when starting up immediate it means, set overload (but not on startup, right when configure) and remove after timeout expired Sandy1> Please review my understanding to check if it's right: "on-startup" and "immediate" are value of "yang:date-and-time" type which is configurable. The router will go into overload status when the two parameters expired in different situation. But the two parameters only take effect when the "overload" is set to true. 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. ack 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. ack same @ link level for the security keys Sandy> OK. Once you confirm the security key format, it will be syned to interface. ack, basically keep to whatever OSPF does,. I thought ACee abstracted the whole keychain IGP stuff and we should use that 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? maybe I missed @ 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? well, name the node HAL and the type is level Sandy1> OK. It will be renamed to ""node-HAL". also list of HAL systemid offers is helpful here Sandy> OK. I can add the systemid which offer the level. yepp, there maybe multiple Sandy1> OK. A systemid list will be added for it. Thanks, Sandy 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. ack | | +--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. ack
- [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