Skip to content
Santosh P K edited this page Oct 23, 2020 · 27 revisions

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

https://github.com/opensourcerouting/frr/wiki/Architecture

FRR centralized server

https://docs.google.com/presentation/d/1214l5e7fdWK7NjCl-PjXt2zVsot_z0LTUlwUQXE5It0/edit#slide=id.g65669c5d35_0_131

Minutes

06/03/2020 - https://anotepad.com/notes/whf5ap7k

20/03/2020 - https://anotepad.com/notes/nqp6wbnm

27/03/2020 - https://anotepad.com/notes/wnnwdwcx

03/04/2020 - https://anotepad.com/notes/4ib2jpjr

17/04/2020 - https://anotepad.com/notes/mt82gthh

24/04/2020 - https://anotepad.com/notes/jgjyn3ry

08/05/2020 - https://anotepad.com/notes/c96tedy5

15/05/2020 - https://anotepad.com/notes/t7gxapdr

29/05/2020 - https://anotepad.com/notes/c4qn5hb5

05/06/2020 - https://anotepad.com/notes/e344xcss

19/06/2020 - https://anotepad.com/notes/gbgkydf6

Tracking Issue

https://github.com/FRRouting/frr/issues/5428

Work In Progress

Work Item Status Tracking PR Comments
Static config Completed https://github.com/FRRouting/frr/pull/5996 Yang and backend code is completed
PIM config Completed https://github.com/FRRouting/frr/pull/6145 Yang and backend code is completed
RIB operational Ongoing https://github.com/FRRouting/frr/pull/6250 Yang completed and backend ongoing
BGP config Ongoing https://github.com/FRRouting/frr/pull/5702 Yang completed and backend ongoing
OSPF config Ongoing https://github.com/FRRouting/frr/pull/6055 Yang ongoing
Password encrypt Ongoing N/A ongoing

Work Pending

Work Item Status
PIM operational No one looking at it
BGP operational No one looking at it
OSPF operational No one looking at it

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 (https://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.


Clone this wiki locally