-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
https://github.com/opensourcerouting/frr/wiki/Architecture
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
- Interface
- 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. _
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."; }
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 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
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.