Re: [Rift] Dear RIFT protocol and RIFT YANG co-author, pls reviewtheupdateofRIFT YANG model

Bruno Rijsman <brunorijsman@gmail.com> Sat, 04 July 2020 16:22 UTC

Return-Path: <brunorijsman@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 5ADC13A0CC6 for <rift@ietfa.amsl.com>; Sat, 4 Jul 2020 09:22:57 -0700 (PDT)
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 5GSMuSQZ87qJ for <rift@ietfa.amsl.com>; Sat, 4 Jul 2020 09:22:55 -0700 (PDT)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 EDC343A0CC5 for <rift@ietf.org>; Sat, 4 Jul 2020 09:22:54 -0700 (PDT)
Received: by mail-ej1-x62d.google.com with SMTP id w16so37581520ejj.5 for <rift@ietf.org>; Sat, 04 Jul 2020 09:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DmC3KsOXVkN9b3kSWDFbuewUJTvRuduaPKjcRppFW4I=; b=e8t58TJPdAeQwKJ3JRww7UgALiqoLdifq/kx5EZLym2FlG0c9D6zJ8o5zGUEQ4/U44 dja6nmp5yB9ViURWz7WLHRH6D2OcwVfq34h4WzfrbZjEH8vf1uWTs/o6VAM6bnK/6WLA Gu7fVyMTUkMZuxxHYrrpIlQgoKGI9lvRmu4iPlaw3wUEsXAWcuM/83SpNVB2tjK5PH/a lXmyRstqYkoKH2oNHmLU5Zo+8lVXoZ7MX81GZkE4O734lRhn/65vz5FOdfonvMh6bTwg KeZHfyD4swG7p2oP+sMJw3pSAaq99LUfG7cFqNcTZ0259d666FysulrPSXiDL2wu0m9a nsfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DmC3KsOXVkN9b3kSWDFbuewUJTvRuduaPKjcRppFW4I=; b=jUeR04SxU5imK5JURMOuApnVBQ+0rrCjcNuLvCMwX74qKLg7lq/Hvv9X1OkBIt3Z6l 7Q2yhqJGr1UUrUpra02TwbUf9/KsnbD2m5ShpphYj0Dzg7/EhoH6/f18vvnnSWICtUq1 NitgZr7lxS6i5N1M5kk3XqPGq56xeKOebcneudaT6oDo/YF7nrGE6EFJebFksJE+HoDc 4ulZ2y61JKgmaorQLwJ4j9sBqDRc+IZCdA+pC3FakZH+4F8ovAXlgo3xoReV02xgirCW o83/E0ay2eKf/0Fp99v6wZvn2RneSsnvW1Fgp8+8BqtGa7UA4HhATKX2FqtmZdw6Hvci 0ZuA==
X-Gm-Message-State: AOAM530EgF0tGNevPYG7V7atcI3FiGusLe9aeDGShptztZpf/Fo4yQbI kpEPozzlSSkl4obPeWSLgkA=
X-Google-Smtp-Source: ABdhPJyw0QQ8eNcnVSqHPiC/nqRpZCwmMTIDbhnP5TVMPwX5gjtROb5C3zFqG5c+F3cLKMSGADU4/w==
X-Received: by 2002:a17:906:add3:: with SMTP id lb19mr28894016ejb.304.1593879773163; Sat, 04 Jul 2020 09:22:53 -0700 (PDT)
Received: from [192.168.178.192] (82-73-48-167.cable.dynamic.v4.ziggo.nl. [82.73.48.167]) by smtp.gmail.com with ESMTPSA id s10sm12625884ejs.91.2020.07.04.09.22.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jul 2020 09:22:52 -0700 (PDT)
From: Bruno Rijsman <brunorijsman@gmail.com>
Message-Id: <1B02CCAE-000D-4EA3-8240-4EA7CFCA3AEF@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9440AC7E-6FDA-4FB4-B38F-C44F7709145A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Sat, 04 Jul 2020 18:22:51 +0200
In-Reply-To: <202007031742272486476@zte.com.cn>
Cc: rift@ietf.org
To: zhang.zheng@zte.com.cn
References: <BF881FFF-9AFC-48F0-BC86-AF8069DE957A@juniper.net, E695E329-C4EC-4AC6-B74F-6E630B4C6D46@gmail.com> <202007031742272486476@zte.com.cn>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/chE9YUwyay-vSTCzEw8ki7e-Fxs>
Subject: Re: [Rift] Dear RIFT protocol and RIFT YANG co-author, pls reviewtheupdateofRIFT YANG model
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, 04 Jul 2020 16:22:58 -0000

Hi Sandy,

Thanks for the quick update to the datamodel.

If you don't mind, I would like to continue with the iterative approach of providing a few more additional feedback comments after each update until we converge.

It works rather nicely for me to send just a few comments in each batch, and then waiting for the next update.

But if that doesn't work for you, and you would rather have all comments in one huge batch, let me know, and I can do that too.

Here is my next batch of comments:

module: ietf-rift
  augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:
    +--rw rift!
       +--rw node
          +--rw name?                         string
          +--ro level?                        level
          +--rw system-id                     system-id
          +--rw pod?                          uint32
          +--rw configured-level?             level
          +--rw overload?                     boolean
          +--ro protocol-minor-version        uint16
          +--ro hierarchy-indications?        enumeration
          +--rw flood-reduction?              boolean
          +--rw nonce-increasing-interval?    uint16
          +--rw maximum-nonce-delta?          uint8 {nonce-delta-adjust}?
          +--rw lie-ipv4-multicast-address?   rt-types:ipv4-multicast-group-address
          +--rw lie-ipv6-multicast-address?   rt-types:ipv6-multicast-group-address
          +--rw global-link-capabilities
          |  +--rw bfd?                     boolean
          |  +--rw v4-forwarding-capable?   boolean
          +--rw flood-port?                   inet:port-number
          +--rw lie-rx-port?                  inet:port-number

Suggest moving this up a few lines, to keep it together with lie-ipv4/6-multicast-address.

We have to decide whether we want to allow implementations to use different LIE multicast addresses for TX and RX (my implementation allows this, and I think Juniper's also).
If so:
 * I suggest renaming lie-ipv4/6-multicast-address to lie-rx-ipv4/6-multicast-address for the sake of clarity and consistency.
 * I suggest adding lie-tx-ipv4/6-multicast-address and lie-tx-port
 * Distinguish rx-flood-port (and interface attribute) and tx-flood-port (a neighbor attribute since it is dynamically advertised in the LIE)

          +--rw holdtime?                     rt-types:timer-value-seconds16
          +--rw tide-generation-interval?     rt-types:timer-value-seconds16
          +--rw tie-security-key-id?          uint32
          +--rw interface* [name]

We should add the advertised RIFT metric to the interface (and the received RIFT metric as a neighbor attribute -- see longer comment below).

We could consider adding the following attributes to interface:  was the most recently received LIE accepted or rejected, and if rejected, why?

          |  +--ro local-link-id?                  linkid-type
          |  +--rw name                            if:interface-ref
          |  +--rw advertised-lie-tie-addresses

I don't see much value putting this in a separate container

          |  |  +--ro lie-ipv4-source-address?        inet:ipv4-address
          |  |  +--ro lie-ipv6-source-address?        inet:ipv6-address
          |  |  +--ro flooding-ipv4-source-address?   inet:ipv4-address
          |  |  +--ro flooding-ipv6-source-address?   inet:ipv6-address

I suggest renaming this from xxx-ipvx-source-address to rx-xxx-ipvx-address (this is address that the interface uses to receive packets).

          |  +--ro direction-type?                 enumeration
          |  +--ro you-are-flood-repeater?         boolean
          |  +--ro not-a-ztp-offer?                boolean
          |  +--ro you-are-sending-too-quickly?    boolean
          |  +--rw link-capabilities
          |  |  +--rw bfd?                     boolean
          |  |  +--rw v4-forwarding-capable?   boolean

Fields such as you-are-flood-repeater, not-a-ztp-offer, you-are-sending-too-quickly, etc. etc. are all fields that are present in the LIE packet.
For such fields we should make a clear distinction between the value that this node advertised to the neighbor and the values (plural!) that this node received from the neihghbors (plural!).
So, we should have:
 * you-are-flood-repeater as an interface attribute (our advertised value) and you-are-flood-repeater as a neighbor attribute (the value that we received from the neighbor). Or maybe to make it even more clear, we could call them tx-you-are-flood-repeater and rx-you-are-flood-repeater (or advertised-you-are-flood-repeater and received-you-are-flood-repeater).
 * Ditto for not-ztp-offer
 * Ditto for you-are-sending-too-quickly
 * Ditto for link-capabilities (=> this one you already did: we have link-capabilities under interface and received-link-capabilities under neighbor)
 * Etc. etc. etc.

          |  +--ro neighbors

There can only be zero or one neighbor per interface. Thus, you don't need a neighbors (plural) list with neighbor objects indexed by system-id. You just need a single optional neighbor object.

          |     +--ro neighbor* [system-id]
          |        +--ro name?                         string
          |        +--ro level?                        level
          |        +--ro system-id                     system-id
          |        +--ro pod?                          uint32
          |        +--ro protocol-version?             uint16
          |        +--ro address-families
          |        |  +--ro address-family* [address-family]
          |        |     +--ro address-family    iana-rt-types:address-family

I am not a YANG expert, but wouldn't a leaf-list make more sense here?

          |        +--ro received-lie-tie-addresses
          |        |  +--ro lie-ipv4-source-address?        inet:ipv4-address
          |        |  +--ro lie-ipv6-source-address?        inet:ipv6-address
          |        |  +--ro flooding-ipv4-source-address?   inet:ipv4-address
          |        |  +--ro flooding-ipv6-source-address?   inet:ipv6-address
          |        +--ro remote-id?                    uint32
          |        +--ro cost?                         uint32
          |        +--ro bandwidth?                    uint32
          |        +--ro flood-reduction?              boolean
          |        +--ro received-link-capabilities
          |        |  +--ro bfd?                     boolean
          |        |  +--ro v4-forwarding-capable?   boolean
          |        +--ro bfd-up?                       boolean
          |        +--ro outer-security-key-id?        uint8
          |        +--ro state?                        enumeration

The state should be an attribute of the interface, not the neighbor. In state one-way the interface doesn't have a neighbor but it does have a state (namely one-way).

(I stopped reviewing here, will wait for the next iteration)

          +--ro miscabled-links*              linkid-type
          +--rw (algorithm-type)?
          |  +--:(spf)
          |  +--:(all-path)
          +--ro hal?                          level
          +--ro vol-list
          |  +--ro vol* [system-id]
          |     +--ro offered-level?   level
          |     +--ro name?            string
          |     +--ro level?           level
          |     +--ro system-id        system-id
          |     +--ro pod?             uint32
          +--rw instance-label?               uint32
          +--ro database
          |  +--ro ties* [direction-type originator tie-type tie-number]
          |     +--ro direction-type          enumeration
          |     +--ro originator              system-id
          |     +--ro tie-type                enumeration
          |     +--ro tie-number              uint32
          |     +--ro seq?                    uint64
          |     +--ro origination-time?       uint32
          |     +--ro origination-lifetime?   uint32
          |     +--ro node
          |     |  +--ro name?              string
          |     |  +--ro level?             level
          |     |  +--ro system-id          system-id
          |     |  +--ro pod?               uint32
          |     |  +--ro flood-reduction?   boolean
          |     |  +--ro overload?          boolean
          |     |  +--ro startup-time?      uint64
          |     |  +--ro neighbors* [system-id]
          |     |  |  +--ro name?                         string
          |     |  |  +--ro level?                        level
          |     |  |  +--ro system-id                     system-id
          |     |  |  +--ro pod?                          uint32
          |     |  |  +--ro address-families
          |     |  |  |  +--ro address-family* [address-family]
          |     |  |  |     +--ro address-family    iana-rt-types:address-family
          |     |  |  +--ro received-lie-tie-addresses
          |     |  |  |  +--ro lie-ipv4-source-address?        inet:ipv4-address
          |     |  |  |  +--ro lie-ipv6-source-address?        inet:ipv6-address
          |     |  |  |  +--ro flooding-ipv4-source-address?   inet:ipv4-address
          |     |  |  |  +--ro flooding-ipv6-source-address?   inet:ipv6-address
          |     |  |  +--ro remote-id?                    uint32
          |     |  |  +--ro cost?                         uint32
          |     |  |  +--ro bandwidth?                    uint32
          |     |  |  +--ro flood-reduction?              boolean
          |     |  |  +--ro received-link-capabilities
          |     |  |  |  +--ro bfd?                     boolean
          |     |  |  |  +--ro v4-forwarding-capable?   boolean
          |     |  |  +--ro bfd-up?                       boolean
          |     |  |  +--ro outer-security-key-id?        uint8
          |     |  +--ro miscabled-links*   linkid-type
          |     +--ro prefix
          |        +--ro prefix?              inet:ip-prefix
          |        +--ro (type)?
          |        |  +--:(prefix)
          |        |  +--:(positive-disaggregation)
          |        |  +--:(negative-disaggregation)
          |        |  +--:(external)
          |        |  +--:(positive-external-disaggregation)
          |        |  +--:(pgp)
          |        +--ro metric?              uint32
          |        +--ro tags*                uint64
          |        +--ro monotonic-clock
          |        |  +--ro prefix-sequence-type
          |        |     +--ro timestamp         ieee802-1as-timestamp-type
          |        |     +--ro transaction-id?   uint8
          |        +--ro loopback?            boolean
          |        +--ro directly-attached?   boolean
          |        +--ro from-link?           linkid-type
          +--ro kv-store
             +--ro kvs* [kvs-index]
                +--ro kvs-index    uint32
                +--ro kvs-tie
                   +--ro direction-type?         enumeration
                   +--ro originator?             system-id
                   +--ro tie-type?               enumeration
                   +--ro tie-number?             uint32
                   +--ro seq?                    uint64
                   +--ro origination-time?       uint32
                   +--ro origination-lifetime?   uint32
                   +--ro key-value
                      +--ro key?     uint16
                      +--ro value?   uint32

  notifications:
    +---n error-set
       +--ro tie-level-error
       |  +--ro direction-type?         enumeration
       |  +--ro originator?             system-id
       |  +--ro tie-type?               enumeration
       |  +--ro tie-number?             uint32
       |  +--ro seq?                    uint64
       |  +--ro origination-time?       uint32
       |  +--ro origination-lifetime?   uint32
       +--ro neighbor-error
          +--ro neighbor* [system-id]
             +--ro name?                         string
             +--ro level?                        level
             +--ro system-id                     system-id
             +--ro pod?                          uint32
             +--ro protocol-version?             uint16
             +--ro address-families
             |  +--ro address-family* [address-family]
             |     +--ro address-family    iana-rt-types:address-family
             +--ro received-lie-tie-addresses
             |  +--ro lie-ipv4-source-address?        inet:ipv4-address
             |  +--ro lie-ipv6-source-address?        inet:ipv6-address
             |  +--ro flooding-ipv4-source-address?   inet:ipv4-address
             |  +--ro flooding-ipv6-source-address?   inet:ipv6-address
             +--ro remote-id?                    uint32
             +--ro cost?                         uint32
             +--ro bandwidth?                    uint32
             +--ro flood-reduction?              boolean
             +--ro received-link-capabilities
             |  +--ro bfd?                     boolean
             |  +--ro v4-forwarding-capable?   boolean
             +--ro bfd-up?                       boolean
             +--ro outer-security-key-id?        uint8


> On Jul 3, 2020, at 11:42 AM, <zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn> wrote:
> 
> Hi Bruno,
> 
> 
> 
> Thank you very much!
> 
> I updated the model again according to your comments.
> 
> And sorry, I made mistakes for database/neighbor/kv-store level.
> 
> Please review it one more time, thank you very much!
> 
> 
> 
> Best regards,
> 
> Sandy
>