Re: [Rift] RIFT YANG datamodel implementation
Tony Przygienda <tonysietf@gmail.com> Wed, 10 March 2021 11:29 UTC
Return-Path: <tonysietf@gmail.com>
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 608833A225A for <rift@ietfa.amsl.com>; Wed, 10 Mar 2021 03:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OA1BpqrdagZc for <rift@ietfa.amsl.com>; Wed, 10 Mar 2021 03:29:26 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5254D3A2259 for <rift@ietf.org>; Wed, 10 Mar 2021 03:29:26 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id f20so17468635ioo.10 for <rift@ietf.org>; Wed, 10 Mar 2021 03:29:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G5JuHyCAoCjt4/R/QXlJeO0jANI2uuveFddCeZAI4CQ=; b=GAtf04NJVR8pRxBopL87qQoDVntV4zwkSYeBkCeMqCqleTk3pgHquChzaYNLiTSt91 hMD8wjX2325GONIoSn3OuLR+D9tWMVPoimWoKnkF7Yb5g2QIydQxwadbZnfuJ17i91hX NbptGumUdyNgLjljsEOEoccbsYURWvSCmNG7KiD6Lgm2urugZ7saZoNaey+iLoY8D71/ Kj9pDq10ffcL4CMeMpJLpRFe9XqqMb7pASjaOZZEiqqfXkW/oyOO6bcOTvYsFaFBSXYK mwQ1TWnu2AHByTvYksx+S311ePQ87W9m9yxaWhKpj7/clNIVSv3Regiz4mM16InVkkz9 tfVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G5JuHyCAoCjt4/R/QXlJeO0jANI2uuveFddCeZAI4CQ=; b=XiIh15fRFA67ykKu1KQrqepGeskD7eY4pZ2cjLG/mu4R2/F6dgRuAiIWyuYOtjCnvY kpzDG6jCrGUrSUi+oXjJZHnBeORLhTF17okx6Oafxmx1M5s1968eWhzxpfVWYGsN1Amh lsD44dZyYWd9eyETOso3dI0A0E20u90DK05cXajTppAM9v3jpauWJ08zaBYJba/a5BwD IIuBB5lYxB3C5iPgxNU7wvsOOzrWmeiwlmcPbg7/no8/dPSMv1uXMWDEu5Cm76KX3DkZ 8IUp1mMS1K2mL98IycGD1AFUlz+BSI9csIt89AOksEZR/bVZ6LWCEliXubPSTKbX/TJU uaJQ==
X-Gm-Message-State: AOAM530t+8L+kcPNZe8quL67wGLXzCbwbOGlnNZiTQeJzYEB2nZ4ixk3 4olLTgAw1G4JFYpVr8CNLtqWYfsFzw0dUrA1lMw=
X-Google-Smtp-Source: ABdhPJx81pWnsrlwzPDB8QMKOxNbApIsCnTNbQSyMNbpGIjDRdu2xqbylL6zvjinyLCQRVDM5wsodvL785OfDe36vKI=
X-Received: by 2002:a5d:8249:: with SMTP id n9mr1987352ioo.31.1615375765066; Wed, 10 Mar 2021 03:29:25 -0800 (PST)
MIME-Version: 1.0
References: <AF13C9C6-8493-45F7-823E-D4C0B57435C9@gmail.com>
In-Reply-To: <AF13C9C6-8493-45F7-823E-D4C0B57435C9@gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Wed, 10 Mar 2021 12:28:49 +0100
Message-ID: <CA+wi2hNvMcAkpz1yp__sKEQ8nW2_+eBbfENNfaXqWYN4h7kKjA@mail.gmail.com>
To: Bruno Rijsman <brunorijsman@gmail.com>
Cc: rift@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a7d89905bd2cfa21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/lcnlAuKpbN1EugCrH_LlAX5__cU>
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: Wed, 10 Mar 2021 11:29:28 -0000
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 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 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 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 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 on acceptance we need following variants SecurityChecking { NoChecking, Permissive, Loose, Strict, } same @ link level for the security keys look @ YAML model we use in open source RIFT to see further details own pod missing @ interface level what is +--ro hal? level it seems backwards, HAL is of level type, no? also list of HAL systemid offers is helpful here also on link add instance-name DATABASE | +--ro (type)? | | +--:(prefix) | | +--:(positive-disaggregation) | | +--:(negative-disaggregation) | | +--:(external) | | +--:(positive-external-disaggregation) | | +--:(pgp) oder strictly per thrift model since order has meaning here | | +--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; 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