Re: [Rift] RIFT YANG datamodel implementation

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Tony, Bruno,

My question about implementation was indeed NOT about implementing YANG model itself, but to confirm that known implementors of RIFT protocol are happy with the YANG model.
And I think I’ve got the answers.

Thanks.
Jeffrey

From: RIFT <[e-mail]> On Behalf Of Tony Przygienda
Sent: Wednesday, March 10, 2021 6:29 AM
To: Bruno Rijsman <[e-mail]>
Cc: [e-mail]
Subject: Re: [Rift] RIFT YANG datamodel implementation

[External Email. Be cautious of content]

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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rift<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rift__;!!NEt6yMaO-gk!S0AWM3IbQZKTIE3K-doU4DpvPqiocIhzhU052mnvskTy1tzWcxkPeMDBYOSdE9lJ$>


Juniper Business Use Only