Northbound Project

“# Northbound Project This page aims to collect on-going project related to northbound. Goal to move all protocols to new nothbound architecture.

Meeting: weekly Friday from 11AM EST.

## Northbound Architecture

github.com/opensourcerouting/frr/wiki/Architecture

## Minutes

## Conclusions

### Usage of leafref

If there exist a leaf which is reference to another table then it must be always leafref. For example if an protocol model has a leaf interface then it should be a leafref to interface model as show in example below. Few of the potential candidate for leafref are 1. Interface 2. VRF

module: frr-staticd

augment /frr-rt:routing/frr-rt:control-plane-protocols/frr-rt:control-plane-protocol:
  +--rw staticd
     +--rw prefix-list* [destination-prefix]
        +--rw destination-prefix      inet:ip-address
        +--rw distance?               frr-rt:administrative-distance
        +--rw tag?                    uint32
        +--rw frr-staticd-next-hop
           +--rw nh-type             nexthop-type
           +--rw gateway?            gateway-address
           +--rw vrf?                string
           +--rw interface?          frr-interface:interface-ref
           +--rw bh-type?            blackhole-type
           +--rw flags?              uint32
           +--rw is-duplicate?       empty
           +--rw is-recursive?       empty
           +--rw is-onlink?          empty
           +--rw is-active?          empty
           +--rw mpls-label-stack
           |  +--rw entry* [id]
           |     +--rw id               uint8
           |     +--rw label?           rt-types:mpls-label
           |     +--rw ttl?             uint8
           |     +--rw traffic-class?   uint8
           +--rw mtu?                uint32

_NOTE: There are cases where leafref may not be used for example show above staticd having nexthop as non-leafref, as nexthop is always associated with route (each route getting copy of its own nexthop) and not an indirect reference. _

### Protocol hierarchy

frr-routing.yang defines common routing hierarchy for all routing protocols. Protocols should augment to routing as show below. All protocols will be keyed by protocol types, vrf name and name (arbitrary name).

augment "/frr-rt:routing/frr-rt:control-plane-protocols/"
      + "frr-rt:control-plane-protocol" {
  container staticd {
    when "../frr-rt:type = 'frr-staticd:static'" {
      description
        "This container is only valid for the 'static' routing
         protocol.";
    }

### IETF yang usage

If IETF yang can be used without any modification. If there is any modification needed then it should be done with deviation only. Any edits to IETF yang should be just renamed or copied to suit FRR requirements.

### Operational/State template

Operational or state attributes must be places under a separate container called “state” and not should be mixed with any configuration container/leaf. This gives a clear separation and ensures easy migration to NDMA (tools.ietf.org/html/rfc8342). An example of state container is as shown below.

module: frr-ripd

+--rw ripd
   +--rw instance* [vrf]
      +--rw vrf                              string
      +--rw allow-ecmp?                      boolean
      +--rw default-information-originate?   boolean
      +--rw default-metric?                  uint8
      +--rw distance
      |  +--rw default?   uint8
      |  +--rw source* [prefix]
      |     +--rw prefix         inet:ipv4-prefix
      |     +--rw distance       uint8
      |     +--rw access-list?   string
      +--ro state
         +--ro neighbors
         |  +--ro neighbor* [address]
         |     +--ro address             inet:ipv4-address
         |     +--ro last-update?        yang:date-and-time
         |     +--ro bad-packets-rcvd?   yang:counter32
         |     +--ro bad-routes-rcvd?    yang:counter32
         +--ro routes
            +--ro route* [prefix]
               +--ro prefix       inet:ipv4-prefix
               +--ro next-hop?    inet:ipv4-address
               +--ro interface?   string
               +--ro metric?      uint8

### General note

libyang mandates to add callback function for all xpath even if leaves are not used in yang model, so all common Yang model like nexthop, routing, interface and VRF will only provide minimum attributes as leaf in main model container. Common attributes/leaves which might be used by multiple other models would be grouped and allowed to augment to main container. This would help other protocols to pick and choose what they want for example in nexthop yang model has config and state, staticd yang uses nexthop yang but does not make use of any state attributes whereas zebra model makes uses of both config and state attributes from nexthop yang model.