Consider supporting static-route function

[KazuyaAnazawa]

This issue discusses how to support L3 functions on goldstone.
Specifically, as the first step, we want to discuss how to support static-route and how to define yang models for that.

Currently, goldstone native (primitive) models don't have the following models:

1. yang model for representing routing table (refer to this as goldstone-routing.yang).
2. yang model for representing static route configuration (refer to this as goldstone-static-route.yang).
3. yang model for representing next hop attributes (refer to this as goldstone-nexthop.yang)

I think it's better to define these models based on FRR models defined here since south-frr will be introduced in the future #50.
Then, I would like to suggest these models as follows.

1. goldstone-routing.yang yang file

module: goldstone-routing
  +--rw routing
     +--rw control-plane-protocols
        +--rw control-plane-protocol* [type name]
           +--rw type    identityref
           +--rw name    string

• This model should have extensibility to support other routing protocols such as OSPFv2 although the first target is static-route.
• Only necessary attributes for static-route are defined.
  • vrf is not considered in proposed model since the concept of network-instance has not been introduced in goldstone.

2. goldstone-static-route.yang yang file

  augment /gs-rt:routing/gs-rt:control-plane-protocols/gs-rt:control-plane-protocol:
    +--rw static-route
       +--rw route-list* [prefix]
          +--rw prefix       inet:ip-prefix
          +--rw path-list* [table-id distance]
             +--rw table-id       uint32
             +--rw distance       gs-rt:administrative-distance
             +--rw gs-nexthops
                +--rw nexthop* [nh-type gateway interface]
                   +--rw nh-type      nexthop-type
                   +--rw gateway      optional-ip-address
                   +--rw interface    gs-if:interface-ref
                   +--rw bh-type?     blackhole-type
                   +--rw onlink?      boolean

3. goldstone-nexthop.yang yang file

module: goldstone-nexthop
  +--rw gs-nexthop-group
     +--rw nexthop-groups* [name]
        +--rw name           string
        +--rw gs-nexthops
           +--rw nexthop* [nh-type gateway interface]
              +--rw nh-type      nexthop-type
              +--rw gateway      optional-ip-address
              +--rw interface    gs-if:interface-ref
              +--rw bh-type?     blackhole-type
              +--rw onlink?      boolean

Any comments, suggestions, and discussions are welcome.

[ishidawataru]

Though I said

we might take FRR YANG models mostly as is by just changing the model name and prefixes.

in #50, I'd like to keep the OpenConfig config / state structure in all Goldstone native models.

Also, if you want to use identity and not enumeration in the Goldstone models, please check if we can easily gather all identity types by using libyang APIs.

When we use enumeration, we can use the enums() method to gather all candidates of the type.

https://github.com/oopt-goldstone/goldstone-mgmt/blob/master/src/north/cli/goldstone/north/cli/interface.py#L408-L436

It is used to generate completion candidates in the CLI code.

[KazuyaAnazawa]

Thank you for your comments.

I'd like to keep the OpenConfig config / state structure in all Goldstone native models.

I got it, and try to consider the models again to keep the style.

Also, if you want to use identity and not enumeration in the Goldstone models, please check if we can easily gather all identity types by using libyang APIs.
When we use enumeration, we can use the enums() method to gather all candidates of the type.

Thank you for the information.
I will also try to check the above.

[KazuyaAnazawa]

I would like to suggest the models again so that we can keep OpenConfig config / state structure.
Also, I thought it's better to use enum instead of identity by following the traditional goldstone models in current phase.
(If it's better to discuss in PR, I can create a PR for this.)

Any comments, doubt, and discussion are welcome.

1. goldstone-routing.yang yang file

module: goldstone-routing
  +--rw routing
     +--rw control-plane-protocols
        +--rw control-plane-protocol* [type name]
           +--rw type      -> ../config/type
           +--rw name      -> ../config/name
           +--rw config
           |  +--rw type?   control-plane-protocol
           |  +--rw name?   string
           +--ro state
              +--ro type?   control-plane-protocol
              +--ro name?   string

• This model should have extensibility to support other routing protocols such as OSPFv2 although the first target is static-route.
• Only necessary attributes for static-route are defined.
  • vrf is not considered in proposed model since the concept of network-instance has not been introduced in goldstone.

2. goldstone-static-route.yang yang file

module: goldstone-static-route

  augment /gs-rt:routing/gs-rt:control-plane-protocols/gs-rt:control-plane-protocol:
    +--rw static-route
       +--rw route-list* [prefix]
          +--rw prefix       -> ../config/prefix
          +--rw config
          |  +--rw prefix?   inet:ip-prefix
          +--ro state
          |  +--ro prefix?   inet:ip-prefix
          +--rw path-list* [table-id distance]
             +--rw table-id       -> ../config/table-id
             +--rw distance       -> ../config/distance
             +--rw config
             |  +--rw table-id?   uint32
             |  +--rw distance?   gs-rt:administrative-distance
             |  +--rw tag?        uint32
             +--ro state
             |  +--ro table-id?   uint32
             |  +--ro distance?   gs-rt:administrative-distance
             |  +--ro tag?        uint32
             +--rw gs-nexthops
                +--rw nexthop* [nh-type gateway interface]
                   +--rw nh-type      -> ../config/nh-type
                   +--rw gateway      -> ../config/gateway
                   +--rw interface    -> ../config/interface
                   +--rw config
                   |  +--rw nh-type      nexthop-type
                   |  +--rw gateway?     optional-ip-address
                   |  +--rw interface?   gs-if:interface-ref
                   |  +--rw bh-type?     blackhole-type
                   |  +--rw onlink?      boolean
                   +--ro state
                      +--ro nh-type      nexthop-type
                      +--ro gateway?     optional-ip-address
                      +--ro interface?   gs-if:interface-ref
                      +--ro bh-type?     blackhole-type
                      +--ro onlink?      boolean
                      +--ro active?      boolean
                      +--ro fib?         boolean

3. goldstone-nexthop.yang yang file

module: goldstone-nexthop
  +--rw gs-nexthop-group
     +--rw nexthop-groups* [name]
        +--rw name           -> ../config/name
        +--rw config
        |  +--rw name?   string
        +--ro state
        |  +--ro name?   string
        +--rw gs-nexthops
           +--rw nexthop* [nh-type gateway interface]
              +--rw nh-type      -> ../config/nh-type
              +--rw gateway      -> ../config/gateway
              +--rw interface    -> ../config/interface
              +--rw config
              |  +--rw nh-type      nexthop-type
              |  +--rw gateway?     optional-ip-address
              |  +--rw interface?   gs-if:interface-ref
              |  +--rw bh-type?     blackhole-type
              |  +--rw onlink?      boolean
              +--ro state
                 +--ro nh-type      nexthop-type
                 +--ro gateway?     optional-ip-address
                 +--ro interface?   gs-if:interface-ref
                 +--ro bh-type?     blackhole-type
                 +--ro onlink?      boolean
                 +--ro active?      boolean
                 +--ro fib?         boolean

[ipi-claytonpascoal]

Regarding goldstone-nexthop.yang, the groupings that define gs-nexthops container is re-used in goldstone-static-route module but gs-nexthop-group container is not used nor referenced by any other element.
What is the purpose of having gs-nexthop-group defined?

[KazuyaAnazawa]

@ipi-claytonpascoal Thank you for pointing it out.
As you pointed out, gs-nexthop-group is not used nor referred by any other elements and it may not be necessary in current phase (try to support static-route first).
I redefined the model like this.

[ishidawataru]

@KazuyaAnazawa Please create a draft PR so that we can easily review the models.