Subject: [Rift] RIFT YANG datamodel implementation

From: Bruno Rijsman <[email-masked]>
Date: Tue, 9 Mar 2021 14:55:47 +0100

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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 10 Mar 2021 12:28:49 +0100

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rift
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 12 Mar 2021 19:30:25 +0000

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 <[email-masked]> On Behalf Of Tony Przygienda
Sent: Wednesday, March 10, 2021 6:29 AM
To: Bruno Rijsman <[email-masked]>
Cc: [email-masked]
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

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

       }

tof

leaf-only

leaf-with-leaf-2-leaf

numeric

then

overload

overload {

status: true/false

}

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?

same for tide generation

that should be also originating-key-id or something since we need (missing right now) the keys we are willing to accept as RW

SecurityChecking {
   NoChecking,
   Permissive,
   Loose,
   Strict,
}

own pod missing

@ interface level

what is

    +--ro hal?    level

DATABASE

                |  +--ro (type)?

                |  |  +--:(prefix)

                |  |  +--:(external)

                |  |  +--:(pgp)

Rijsman, et al.          Expires August 26, 2021                [Page 7]

Internet-Draft               RIFT YANG Model               February 2021

                |  |  +--ro cost?                         uint32

                |  |     +--ro bfd?                     boolean

missing

On Tue, Mar 9, 2021 at 2:55 PM Bruno Rijsman <[email-masked]<mailto:[email-masked]>> wrote:
I did not attend yesterday's RIFT working group meeting for IETF 110 live, but I did just finish watching the video recording.

-- Bruno
_______________________________________________
RIFT mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: <[email-masked]>
Date: Tue, 16 Mar 2021 10:29:00 +0800 (CST)

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;
抄送人：[email-masked];
日 期 ：2021年03月10日 19:29
主 题 ：Re: [Rift] RIFT YANG datamodel implementation

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? 

so 

 leaf configured-level { type level; description "The configured level value of this node."; }

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 

overload { 
status: true/false

} 

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.

+--rw holdtime?

Sandy> OK.

same for tide generation 

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 

Sandy> OK. I'll add it.
Thanks,
Sandy

-- Bruno

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Mar 2021 11:06:24 +0100

On Tue, Mar 16, 2021 at 3:29 AM <[email-masked]> wrote:

> *发件人：*TonyPrzygienda
> *收件人：*Bruno Rijsman;
> *抄送人：[email-masked];
> *日 期 ：*2021年03月10日 19:29
> *主 题 ：**Re: [Rift] RIFT YANG datamodel implementation*
> 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

> 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

> 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

> should be global-holdtime
ack

> on acceptance we need following variants
ack

> 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

> Sandy> The "pod" is the fourth leaf in node, please check it agin, do I make some mistakes?
maybe I missed

> 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

> Sandy> OK. I can add the systemid which offer the level.
>
>
yepp, there maybe multiple

> Sandy> OK. I'll modify the order according to section 8.2.28.1.
ack

>        (python.immutable = "")                address_families;
ack

---

From: <[email-masked]>
Date: Fri, 19 Mar 2021 17:36:07 +0800 (CST)

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;
抄送人：[email-masked];Bruno Rijsman;
日 期 ：2021年03月16日 18:20
主 题 ：Re: [Rift] RIFT YANG datamodel implementation

Hi tony, 

Much appreciate for it.

Best regards,

Sandy

原始邮件

发件人：TonyPrzygienda
收件人：Bruno Rijsman;
抄送人：[email-masked];
日 期 ：2021年03月10日 19:29

so 

tof
leaf-only
leaf-with-leaf-2-leaf 

numeric

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 

overload { 
status: true/false

} 

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.

+--rw holdtime?

ack

same for tide generation 

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 

ack, basically keep to whatever OSPF does,. I thought ACee abstracted the whole keychain IGP stuff and we should use that 

own pod missing 

maybe I missed 

@ interface level

what is 

 +--ro hal? level 

Sandy1> OK. It will be renamed to ""node-HAL".

Sandy1> OK.  A systemid list will be added for it. 

Thanks,

Sandy

ack

missing 

ack

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 19 Mar 2021 11:44:14 +0100

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 <[email-masked]> wrote:

> <http://www.zte.com.cn/>
> *收件人：*张征00007940;
> *抄送人：[email-masked];Bruno Rijsman;
> *日 期 ：*2021年03月16日 18:20
> 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
>>
> 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.
>>
>>